Subject: DTMF and Signals descriptor

From: Jo Friedman <[email-masked]>
Date: Mon, 24 Jan 2000 15:41:43 -0700

Please tell me if I'm correct in assuming that there are at least
two ways for the MGC to request the MG to signal DTMF digits on a
physical termination. I also have some V13 comments related to
the signal descriptor below.

Are both of these correct for dialing '125'?

Signals {
   dg/pt {
      ind=100,         ; interdigit duration
      tl=[d1,d2,d5]   ; dtmf digits 125
   }
}
In this case how is the signal duration specified?

or

SignalList = 10 {
   SignalType=Timeout,
   Duration=250,
   dg/d1,
   dg/d2,
   dg/d5
}

V13 comments:
In 7.1.11 the last sentence of the 1st paragraph refers to
"sequential play lists". I assume that is the same as "sequential
signal lists" so it should be replaced to avoid confusion.

In the ABNF for signalListParm the preceding comments contains
the phrase "at most once duration and every signal parameter". I
understand "at most once duration" but I don't understand what is
meant to be conveyed by the rest of the phrase.

In the ABNF for signalListParm if SigSignalType=Timeout is
sigDuration required? The description of timeout in 7.1.11
implies if there is no duration the signal is played until it is
turned off. In a signal list this doesn't make sense because the
first signal in the list would be the only signal played,
wouldn't it?

Thanks for any clarifications!
Jo

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Jan 2000 15:58:23 -0500

Right, but are you in agreement that signal lists don't have
signal type or duration parameters?

Brian

> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2000 8:22 AM
> To: [email-masked]
> Subject: Re: DTMF and Signals descriptor
>
>
> "Rosen, Brian" wrote:
> >
> > This doesn't make sense to me; why would you be able to change the
> > SignalType but not the duration.  If you want signal lists
> to not have
> > duration, they should not have signal type.  That is okay
> with me, the
> > signal type is then always defined by the last signal.
>
> Not by the last signal.  It's a little more complicated:
> - only the last in the sequence can be on/off.  If so, the type of the
> list is on/off;
> - if the last in the sequence is not on/off, and there is an
> element in
> the sequence with type timout, the type of the list is timeout;
> - if all elements of the sequence are type brief, then the
> list is type
> brief.
>
> John
>
> > Brian
> >
> > > -----Original Message-----
> > > From: John Segers [mailto:[email-masked]]
> > > Sent: Tuesday, January 25, 2000 3:16 AM
> > > To: [email-masked]
> > > Subject: Re: DTMF and Signals descriptor
> > >
> > >
> > > Jo, Brian,
> > >
> > > I changed the occurrence of "sequential play list" to
> > > "sequential signal
> > > list".
> > >
> > > It doesn't make sense to me to define the duration of a
> seq. signal
> > > list. So in the paragraph on sequential signal lists, I
> propose to add
> > > the following sentence: "The duration of a sequential
> signal list with
> > > type timeout is equal to the sum of the durations of the
> signals it
> > > contains."
> > >
> > > John
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > See comments below
> > > >
> > > > > -----Original Message-----
> > > > > From: Jo Friedman [mailto:[email-masked]]
> > > > > Sent: Monday, January 24, 2000 5:42 PM
> > > > > To: [email-masked]
> > > > > Subject: DTMF and Signals descriptor
> > > > >
> > > > >
> > > > Since the default SignalType for dtmf digits is BRief, the
> > > duration is
> > > > fixed (or provisioned) it could be overriden by using the
> > > duration parameter
> > > >
> > > > to specify something else.  SignalType and Duration are
> > > available for every
> > > > signal.
> > > >
> > > > >
> > > > > or
> > > > >
> > > > > SignalList = 10 {
> > > > >    SignalType=Timeout,
> > > > >    Duration=250,
> > > > >    dg/d1,
> > > > >    dg/d2,
> > > > >    dg/d5
> > > > > }
> > > > Yes
> > > >
> > > > > V13 comments:
> > > > Yes, we should fix this
> > > > I think it means that a parameter to a signal can only
> > > occur once per
> > > > signal instance in the list (but signal can occur more than
> > > once, and
> > > > in each case signal parameters can be included (once).
> > > >
> > > > >
> > > > I don't think we talked about this.  A normal signal has a
> > > default duration
> > > > and if not specified, that is what you use.  A signal list
> > > does not have
> > > > a default duration.  At the moment, I'd say it's an
> error to specify
> > > > SignalType = TimeOut and not specify Duration.
> > > >
> > > > >
> > > > Brian
> > > --
> > > 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
> > >
>
> --
> 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
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Jan 2000 16:12:26 -0500

Woops, this should be fixed.  We've just frozen a version, so
it will have to go on a list for the next one.

Brian

> Sent: Tuesday, January 25, 2000 10:58 AM
> Brian,
> You made two statements below that aren't explicitly stated
> in the spec and
> probably would have helped me understand signals better.
>
> "Since the default SignalType for dtmf digits is BRief, the
> duration is
> duration parameter"
> "A normal signal has a default duration ...."
>
> Since signalType and duration are optional  should the
> default signalType and
> duration  values be specified in the package? This is
> actually stated in 12.1.4,
> but the packages in Annex E (e.g., basic DTMF generator)
> don't define these
> default values. I think this is where I got confused.
>
> Jo
>
> "Rosen, Brian" wrote:
>
> > See comments below
> >
> > a default duration.  At the moment, I'd say it's an error to specify

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 11:41:47 -0600

The intention was that the default duration for DTMF be provisioned (or
designed) in the MG.  If we put values into the package as it stands, it
will have to be reworked to operate outside of North America.

> From: Jo Friedman [SMTP:[email-masked]]
> To:   [email-masked]
> You made two statements below that aren't explicitly stated in the spec
> and
> "Since the default SignalType for dtmf digits is BRief, the duration is
> fixed (or provisioned) it could be overriden by using the duration
> parameter"
>
> Since signalType and duration are optional  should the default signalType
> and
> duration  values be specified in the package? This is actually stated in
> 12.1.4,
> but the packages in Annex E (e.g., basic DTMF generator) don't define
> these
> > Since the default SignalType for dtmf digits is BRief, the duration is
> > fixed (or provisioned) it could be overriden by using the duration
> parameter
> >
> > to specify something else.  SignalType and Duration are available for
> every
> > signal.
> >
> > >
> > > or
> > >
> > > SignalList = 10 {
> > >    SignalType=Timeout,
> > >    Duration=250,
> > >    dg/d1,
> > >    dg/d2,
> > >    dg/d5
> > > }
> > Yes
> >
> > > V13 comments:
> > I think it means that a parameter to a signal can only occur once per
> > signal instance in the list (but signal can occur more than once, and
> > I don't think we talked about this.  A normal signal has a default
> duration
> > and if not specified, that is what you use.  A signal list does not have