Subject: Re: Tonegen Package

From: Madhu Babu <[email-masked]>
Date: Mon, 3 Jul 2000 17:24:18 +0530

Tom  list,
Why are we going for two different possiblities for specifying items in a
package. One which uniquely identify a given item as pkg_name/idem_id. and the
other only with item_id (assuming this item_id is unique.)
why are we not going for fully specified items with package identifiers and make
grammar consistent for doing the same?
-Madhubabu

Tom-PT Taylor <[email-masked]> on 06/28/2000 01:19:50 AM

Please respond to Tom-PT Taylor <[email-masked]>

To:   [email-masked]
cc:    (bcc: Madhu B Babu/HSS)

Subject:  Re: Tonegen Package

> -----Original Message-----
> From: Chuong Nguyen [SMTP:[email-masked]]
> Sent: Tuesday, June 27, 2000 10:24 AM
> To:   [email-masked]
> Subject:      Re: Tonegen Package
>
> Tom-PT Taylor wrote:
>
>               Can someone show a real world scenario and syntax on how
> tonegen package is used?
>
> <cnn> Sorry I meant an example of tonegen and cg being used together.
>             I think your example 2 could have been done w/o using tonegen.
>
        [PTT]
        I can't think of a realistic example using the specific tones in cg.
Assuming that some new package provides "stutter dial tone" (toneId sdt)
which indicates a waiting message, then one could imagine a Signals
descriptor like
                  Signals { tonegen/pt {tl = { sdt, dt}, ind = 10} }
        The assumption is that the durations of the respective tones are
provisioned.

        Again, I don't see this as realistic -- a signal list would work
better.
>
>
>
>       [PTT]
>       Two cases:
>
>               Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a
> PBX trunk), with 10 ms gaps between the individual tones.
>
>                  Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2},
> ind=10} }
>
>               Case 2: Play ringing tone for a maximum of 3 minutes.
> Notify the MGC if the tone terminates abnormally or by timeout.  (No
> notification is needed if the tone is interrupted by an event or
> replacement.)  If any signals remain active when the signal completion
> event is recognized, allow them to continue.
>
>                  Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to,
> or} },
>          Events = 666 { g/sc{ka} }
>
> <cnn>  Maybe it is just me but this look pretty challenging and time
> consuming to parse.
>              How would one knows that tl, ind, sy, nc and ka represent
> package parameter name
>              versus Megaco token name?
        [PTT]
        Per the syntax for signals, your parser should be primed to look for
sy, nc, ka, and one or two others, because these are defined in Annex B.
Anything else is package dependent.  It's exactly as you say, but you may be
able to stick all the toneIDs into a single working database, since the
package they come from is irrelevant so long as the other party also
supports that package.

>              One would have to make sure that it is not a Megaco token
> name first.
>              Then search through all package databases that extend tonegen
> package.
>
>
>              tonegen package: signal type = Brief and duration =
> Provisioned.
>              cg package          : signal type = Timeout and duration =
> Provisioned
>
>              Does cg package (cg) override tonegen signal type, etc?
>              So in general does extension package overide package that it
> extends?
        [PTT]
        Leaving aside the thought that defining cg as an extension of
tonegen may have been wasted effort, we have two possibilities: you are
using signal tonegen/pt, or you are using a signal in the cg package.  These
are different signals, and may therefore be of different types.  If you are
using tonegen/pt with a toneID from cg, then the fact that cg supports TO
signals is irrelevant.

>              Is there any restriction that "tl" can only contain tone from
> one package or multiple
>              packages as long as these packages extend tonegen?
        [PTT]
        Not so long as we ensure that toneIDs are unique across all
packages.
>
>              Do you know where I can find all the packages defined so far.
>
>              One would have to build some kind of tree to keep track of
> these package extension.
>              It would be a nightmare if one is looking at binary values of
> these package
>              parameter Ids in hex.
        [PTT]
        I published a list a little while back, but can't find the message
at the moment.  It's about time I set up the IANA tabulations.

> Thanks
> Chuong
>
>
> --
>   Alcatel USA, Inc             Internet: [email-masked]
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

---

From: Vikas Salota <[email-masked]>
Date: Wed, 5 Jul 2000 17:04:21 +0530

Sorry for the late comments. Please see embedded comments.

Tom-PT Taylor wrote:

> Sorry to take so long to answer this.  If you check out the ABNF, you see
> that signal parameter syntax reduces to
>
> NAME parmValue
>
> As a result, the toneIDs themselves are NOT prefixed by package name.  The
> square bracket syntax denotes a sublist (from the alternativeValue
> production).  I think that's wrong: the package defines the parameter as a
> list, not a sub-list.  Thus curly brackets should be used, and the
> interpretation is "list of values" rather than "list of alternatives"
> because the package definition says so.

Vikas> I don't think it's a good idea to overload the alternatives list to be
interpreted as
"list of values" for this particular case. If we have a requirement for an
ordered list
(as in this case), why not define an ordered list on the similar lines which can
be probably
be demarcated using '(', ')' pair.
This may have significant implications on the existing definitions of the
packages having
list type elements. We'll have to reclassify them in the light of new type list
being defined.
Even if this particular case of Tonegen Pkg looks like a special case and not
many lists
of these type are expected, shouldn't it be sub-list that is "overloaded" as
"list of values"
rather than the alternatives list which is choosing a value from a list of
values.

>
>
> The fact that toneIDs are not prefixed by package name leads to potential
> ambiguity.  Either toneIDs have to be unique, which may implying an IANA
> registration process, or else we indicate which package the toneIDs come
> from by using the package name for the toneIDs instead of tonegen to prefix
> the pt signal.  The latter mechanism would restrict the playing of tones in
> one signal to a single package, so I think we have to go with unique
> toneIDs.  Therefore the correct syntax for your example is

Vikas> Why can't we allow the toneId be qualified with a package name in Tone id

list. Grammer already supports it.
Moreover having a package name with the toneId would greatly simplify the lookup

for any toneId in the list. Otherwise the ToneId would have to be looked for in
all the
defined packages or atleast among the packages extending ToneGen
directly/indirectly(assuming that the toneId would always be from such a
package).
This puts an extra requirement of a special handling of toneIds in the tone Id
list and a
need to keep information (per package) about what all packages extend the given
package (which was not needed till now).

>
>
> Signals { tonegen/pt {tl = {rt, cw}, ind = 100} }
>
> The example is really not very appealing -- one would have to assume that
> the durations of rt and cw are provisioned.  (Note that tonegen is
> characterized as BR by default.)
>
> The fact that we define toneIDs in packages implies that they come in
> closely related sets, which must be supported on an all-or-nothing basis.
>
> Further comments below.
>
> > Sent: Saturday, June 17, 2000 1:12 PM
> > Subject:      Tonegen Package
> > Hi
> > Can soneone help me w/the syntax involving tonegen Package and cg package?
> >
> >
> > Say I want to use tonegen/pt with tl (tone id list) of cg/rt and cg/cw
> > (just as an example)
> >
> > Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} }
> >
> > Does this look right?
> >
> > Can someone show a real world scenario and syntax on how tonegen package
> > is used?
>         [PTT]
>         Two cases:
>
>         Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a PBX
> trunk), with 10 ms gaps between the individual tones.
>
>            Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2}, ind=10}
> }
>
>         Case 2: Play ringing tone for a maximum of 3 minutes.  Notify the
> MGC if the tone terminates abnormally or by timeout.  (No notification is
> needed if the tone is interrupted by an event or replacement.)  If any
> signals remain active when the signal completion event is recognized, allow
> them to continue.
>
>            Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to, or} },
> > In the description of tonegen, "interdigit" time delay was given as the
> > definition for "ind".
> > What does "interdigit time delay" really mean here?
> > Later in Section E.3.3 "ind" is defined as inter signal duration which
> > seems to make
> > some sense of how "ind" is supposed to be used.
>         [PTT]
>         The "interdigit" is in quotes in the description because the tones
> aren't necessarily digits.  However, as you can see, the most natural use of
> the "list of tones" feature is for digit outpulsing.
>
> > ---
> > Since Call Progress Tones Generator (cg) Package extends tonegen package,
> > it does not really mean that you have to use the following syntax to use
> > cg:
> >         Signals {tonegen/pt {tl = cg/dt}}
> >
> > One can just do        Signals{cg/dt}
>         [PTT]
>         Sorry, no.  "dt" is not a signal, merely a possible value of a
> signal  parameter.
>
> > ----
> > E.7.3 under "Additional Values"
> >           "dt (0x0030) is defined as a tone id for playtone"
> >
> > Does this imply one can do the following?
> >              Signals {tonegen/pt {tl = dt}}
> >
> > In E.3.3 "tl" is defined as a list of tone ids.
> > Is tone id "dt" or "cg/dt"?
>         [PTT]
>         Answered above.  The ABNF for signal parameter value forces us to
> use "dt".
>
> > Thanks
> > Chuong
> >
> > --