Subject: Tonegen Package

From: Chuong Nguyen <[email-masked]>
Date: Sat, 17 Jun 2000 12:12:09 -0500

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?

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.

---
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}

----
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"?

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: Hussain F Mohammad <[email-masked]>
Date: Wed, 21 Jun 2000 05:38:26 -0700

Interesting query! Any responses?
-MFH
--

--------- Forwarded Message ---------

DATE: Sat, 17 Jun 2000 12:12:09
From: Chuong Nguyen <[email-masked]>
To: [email-masked]

Hi

Does this look right?

---

----

Thanks
Chuong

--------- End Forwarded Message ---------

Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct

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)

Does this look right?

In the description of tonegen, "interdigit" time delay was given as
the definition for "ind".

---

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}}

----

"dt (0x0030)
is defined as a tone id for playtone"

Thanks

Chuong

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 26 Jun 2000 20:55:25 -0400

In my case 2 example below, I forgot to set the timeout interval.  The
correct Signals descriptor is:
 Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, dr=1800, nc= {to, or} }

> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> Sent: Monday, June 26, 2000 8:45 PM
> Subject:      Re: Tonegen Package
>
> 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.
>
> 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
>
> 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.
>
> > -----Original Message-----
> > From: Chuong Nguyen [SMTP:[email-masked]]
> > Sent: Saturday, June 17, 2000 1:12 PM
> > Subject:      Tonegen Package
>         [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} }
>
>         [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.
>
> > ---
>         [PTT]
>         Sorry, no.  "dt" is not a signal, merely a possible value of a
> signal  parameter.
>
> > ----
>         [PTT]
>         Answered above.  The ABNF for signal parameter value forces us to
> use "dt".
>
> > Thanks
> > Chuong
> >
> > --

---

From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <[email-masked]>
Date: Tue, 27 Jun 2000 07:45:24 -0500

And my comments after yours.

> Sent: Monday, June 26, 2000 9:20 PM
> Thanks for the reply.
> See comments below
> 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.
>
>
> <cnn> I agreed w/you about the curly bracket.  But I think you meant the
> square bracket syntax denotes
> an alternatives list.
        [PTT]
        No, check the alternativeValue production (reproduced below):

       alternativeValue     = ( VALUE
                                / LSBRKT VALUE *(COMMA VALUE) RSBRKT
                         ; sublist (i.e. A AND B AND ...)
                                / LBRKT VALUE *(COMMA VALUE) RBRKT
                                 ; alternatives (i.e. A OR B OR ...)
                                /  LSBRKT VALUE COLON VALUE RSBRKT )
                                         ; range

> So are you also saying that the ABNF needs to be clarified that sublist is
> the same thing as
> "list of values"?
        [PTT]
        I don't think it is, for two reasons: sublist doesn't imply ordering
(but of course, we should have specified "ordered list"or "sequence" in the
package description), and I'm not sure that sublist would allow repeated
values.  We had better be clear on this, so people should jump in if they
disagree that "list of values" for a parameter value implies the use of
curly brackets.
>
>
>
>
>       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
>
>
> VALUE = quotedString / 1*(SafeChar)
> So why can't VALUE = "cg/rt" instead of just "rt"?
        [PTT]
        Primarily because the package defines the name to be "rt".  And I
really hope no one puts a slash where it doesn't belong.  At first
opportunity we should add that restriction to the rules for parameter
naming.

> But of course all these could get pretty hairy
> if we have several levels of extension.
> Does VALUE has a limit on # of characters?
>
> I guess this also depends on how the ASN deals with this.
>
>
>
>       [PTT]  ...
>
>
>       ---
> <cnn>  I don't know about this because the cg package defines dt as either
> a signal id/tone id.
> In Appendix A, example cg/dt is used as
>             Signals {cg/dt}                Step 8, page 158
        [PTT]
        Oops, you're absolutely right.  So as you say, one can simply do
Signals { cg/dt }.  Not sure it was worth the bother to define the toneIDs
in the cg package, given that the signal list mechanism will play them in
sequence if absolutely necessary.

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 27 Jun 2000 15:49:50 -0400

> Sent: Tuesday, June 27, 2000 10:24 AM
>               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.
>
> 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.
>
> <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.