Subject: Re: FW: Re: Stopping of Dial Tone

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 1 Feb 2000 12:03:24 -0500

The syntax involved in use of the digit map requires specification of the
class of events which are to be mapped (e.g. dd/*).  The optional KeepActive
parameter can be set for dd/* if continuation of signals is desired.
Otherwise the usual rule for detected events applies: the signal(s) stop.

In other words, events are detected while the digit map matching is in
progress, and have their usual effect on signals.  I will add text to my
"Issue Scorecard" under the "clarifications" heading, against the digit map
section.

> -----Original Message-----
> From: Madhu Babu [SMTP:[email-masked]]
> Sent: Tuesday, February 01, 2000 11:36 AM
> To:   [email-masked]
> Subject:      Re: FW: Re: Stopping of Dial Tone
>
>
>
>
> I think that Murat has correctly expressed my concern. As far as I
> understand,
> the event digit map is
>   said to have occurred when there is a match found not when any digit is
> received. If that is the case
>   then every digit would have to be treated as an event occurred. Please
> note
> that the MG does not have
>   the awareness of whether it is acting as a residential gateway or a
> trunking
> gateway or whatever. The
>   processing that a dial tone is to be stopped when the first digit is
> detected
> is specific to the residential
>   gateway. A similar behaviour may not be expected in other scenarios i.e.
> it
> may not always be required to stop
>   an ongoing signal when the first digit is received. How does the MG
> distinguish between these two scenarios ?
>   Kindly elaborate.
>
> Regards
> -Madhubabu
> Hughes Software Systems.
>
>
>
>
> Murat Bog <[email-masked]> on 02/01/2000 05:34:23 AM
>
> Please respond to Murat Bog <[email-masked]>
>
> To:   [email-masked]
> cc:    (bcc: Madhu B Babu/HSS)
>
> Subject:  Re: FW: Re: Stopping of Dial Tone
>
>
>
>
> Unless I have missed some obvious points, I don't see this as a non-issue
> and I share the concern with Madhu Babu.  Although we all know what the
> desired behavior is, neither the current definition of the ce event in the
> dd package nor that of the DigitMap descriptor in section 7.1.14 supports
> that behavior.  The dd/ce event is detected by the MG when the
> digits/timers
> match the dial plan.  We want the dial tone to stop immediately after the
> detection of the first digit.  At that time, however, there is no match
> against the dial plan (unless the dial plan is something like "x") and a
> dd/ce event which should stop the dial tone does not exist yet.
>
> I don't know of any other place in the protocol specification where this
> issue is explicitly addressed.  The ABNF changes regarding the event
> descriptor, introduced in v13 and retained in v14, show the eventDM as
> possible a parameter of a requestedEvent, but nothing is said about the
> handling of signals if eventDM is used; i.e. stop signals after the first
> digit.  If this were the intent, I think it should be made explicit in the
> text.  If not, I am not sure it would be a good idea to change the
> definition of dd/ce event to the same effect since it would create an
> exception to the general model.
>
> It also seems to me that there may be other ways of expressing the desired
> behaviour.  One example that I remember have been discussed on the list
> before used the embedding capability as follows (assume event buffering is
> off):
>
> Events = 2223 {
>   al/on,
>   dd/etd {
>      tl = *,
>      Embed {
>        Events = 2224 {
>          dd/ce {
>             DigitMap = DialPlan0
>          }
>      }
>   }
> }
> Signals {
>   cg/dt
> }
>
> I am assuming that if embedding is used in a requestedEvent, the
> processing
> is such that a notify command is not sent when that event is detected but
> rather the event is applied against the embedded event descriptor (if
> there
> is one).  Otherwise, two notify commands will be sent: one when the first
> digit is detected and the second when the following digits/timers match
> the
> digit map.  This may or may not be the desired behavior but in any case
> this
> could be another area for the text to benefit from some clarification.
>
>
> Murat Bog.
> CopperCom Inc.
>
>  -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Monday, January 31, 2000 6:52 AM
> To: [email-masked]
> Subject: Re: FW: Re: Stopping of Dial Tone
>
>
>
> I'm happy to accept this as the common understanding.
>
>         -----Original Message-----
> From:   Selvam Rengasami [SMTP:[email-masked]]
> Sent:   Monday, January 31, 2000 8:17 AM
> To:     [email-masked]
> Subject:        Re: FW: Re: Stopping of Dial Tone
>
>         John,
>
>         This was also my working assumption and I agree that I don't
> really
> see this as
> a problem either.
>
>         -Selvam Rengasami
> Telcordia Technologies
>
>         Tel:  +1 732 758 5260
> E-mail:  [email-masked]
>
>
>
>
>
>         John Segers <[email-masked]> on 01/31/2000 06:33:41 AM
>
>         Please respond to John Segers <[email-masked]>
>
>         To:   [email-masked]
> cc:    (bcc: Selvam Rengasami/Telcordia)
> Subject:  Re: FW: Re: Stopping of Dial Tone
>
>
>
>
>         Tom,
>
>         Is it really a problem?  The way I always understood this, is that
> detection of an event stops an active signal.  It doesn't matter how the
> event is detected or reported.  So an event that leads to a partial
> match in a digit map (the first digit) would stop dialtone.
>
>         Is my thinking flawed?
>
>         John
>
>         Tom-PT Taylor wrote:
> >
> > Resend -- first attempt got swallowed.
> >
> > > -----Original Message-----
> > > From: Taylor, Tom-PT [CAR:B904:EXCH]
> > > Sent: Wednesday, January 26, 2000 12:46 PM
> > > To:   'Megaco'
> > > Subject:      Re: Stopping of Dial Tone
> > >
> > > The problem is real.  The question is what event detection mechanism
> to
> > > use to stop dial tone.  It doesn't matter whether we define a new
> start
> of
> > > dialling event or simply use the existing dd/* ("detect any DTMF
> digit"):
> > > there is a problem of potential interaction with the digit map.  The
> most
> > > straightforward solution is that the MGC has to ask that the first
> digit
>
> > > be reported, and only after that it can send down a digit map for
> > > everything else.  Alternatively we have to modify section 7.1.8 to
> make
> it
> > > clear that it is possible to request digit detection in parallel with
> > > digit mapping (i.e. dd/* in combination with dd/ce {...} means that
> > > individual digit events are detected, but the same digits are also
> > > processed by the digit map.
> > >
> > > Comments?
> > >
> > >
> > >                     From:         Madhu Babu <[email-masked]>
> > >                     Subject:      Stopping of Dial tone
> > >
> > >
> > >                     Hi all,
> > >
> > >                     According to the example in the Appendix A.1.2
> when
> > > MGC request
> > >                     MG to apply dial tone and check for digit events
> it
> is
> > > specified
> > >                     as
> > >
> > >                     Events = 2223 {
> > >                     al/on, dd/ce {DigitMap=Dialplan0}
> > >                     }
> > >                     Signals {cg/dt},
> > >
> > >                     According to the protocol an signal is stopped
> > > Whenever any
> > >                     event occurs. and here the event requested by MGC
> is
>
> > > digitmap
> > >                     completion,that means dial tone will be stopped
> when
>
> > > we get
> > >                     all the digits (as implied by the name digitmap
> > > completion).
> > >                     What I suggest is that a new event like
> > > "firstdigitcompletion"
> > >                     should also  be specified, otherwise how can the
> first
> > > digit itself
> > >                     stops the dialtone.
> > >
> > >                     regards
> > >                     -Madhubabu
> > >
> > > Tom Taylor
> > > Advisor -- IPConnect Standards
> > > E-mail: [email-masked] (internally, Tom-PT Taylor)
> > > Phone and FAX: +1 613 736 0961
> > >
>
>         --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>
>  << File: Internet HTML >>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 1 Feb 2000 17:54:17 -0500

I'm traveling, so this may reach you after someone else said (hopefully the
same) thing.

It's all in how you interpret how digitmaps work.  The way we have been
looking at them is that they
modify the behavior of the event mechanism to not cause Notify's for every
digit detection.  If you use
that interpretation, the digit events still occur, they simply don't cause a
Notify.  If you accept that, then
the first digit is an event, and it turns off signals (unless they are
marked KeepActive).

Having said that, it would be easy, and proper to add a line to the dd/ce
event that explicitly states that
the detection of the first digit defines the BEGINNING of event detection,
thus stopping signals, and
detection of the end digit is the end of event detection, and causes the
Notify.

Would that be satisfactory?

-----Original Message-----
From: Murat Bog [mailto:[email-masked]]
Sent: Monday, January 31, 2000 7:04 PM
To: [email-masked]
Subject: Re: FW: Re: Stopping of Dial Tone

that behavior.  The dd/ce event is detected by the MG when the digits/timers

Events = 2223 {
  al/on,
  dd/etd {
     tl = *,
     Embed {
       Events = 2224 {
         dd/ce {
            DigitMap = DialPlan0
         }
     }
  }
}
Signals {
  cg/dt
}

I am assuming that if embedding is used in a requestedEvent, the processing
is such that a notify command is not sent when that event is detected but
rather the event is applied against the embedded event descriptor (if there
is one).  Otherwise, two notify commands will be sent: one when the first
digit is detected and the second when the following digits/timers match the
digit map.  This may or may not be the desired behavior but in any case this
could be another area for the text to benefit from some clarification.

Murat Bog.
CopperCom Inc.

        -----Original Message-----
From:   Selvam Rengasami [SMTP:[email-masked]]
Sent:   Monday, January 31, 2000 8:17 AM
To:     [email-masked]
Subject:        Re: FW: Re: Stopping of Dial Tone

        John,

        This was also my working assumption and I agree that I don't really
see this as
a problem either.

        -Selvam Rengasami
Telcordia Technologies

        Tel:  +1 732 758 5260

        Tom,

        Is my thinking flawed?

        John

        Tom-PT Taylor wrote:
> > The problem is real.  The question is what event detection mechanism to
> > use to stop dial tone.  It doesn't matter whether we define a new start
of
most
> > straightforward solution is that the MGC has to ask that the first digit

> > everything else.  Alternatively we have to modify section 7.1.8 to make
it
> >                     According to the example in the Appendix A.1.2 when
> > MGC request
> >                     MG to apply dial tone and check for digit events it
is
> >                     event occurs. and here the event requested by MGC is

> > digitmap
> >                     completion,that means dial tone will be stopped when

first