Subject: RE: [Megaco] Call Progress Tones Generator Pkg

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 14 Dec 2001 14:50:43 -0500

Comments inline.

Kevin

 -----Original Message-----
From: 	Terry L Anderson [mailto:[email-masked]] 
Sent:	Friday, December 14, 2001 1:37 PM
To:	Boyle, Kevin [NCRTP:3Z30:EXCH]
Cc:	Megaco Mailing List
Subject:	Re: [Megaco] Call Progress Tones Generator Pkg

 << File: Card for Terry L Anderson >> Unfortunately for the call waiting
case, this distinction between
cadence and repetition interval is ambiguous.  E.180 uses the term
cadence when specifying the 8-10 sec of silence:

"and with a cadence (frequency sequence) as follows:
a) f on 300 to 500 ms, silence 8 to 10 s (f = 300 ms is preferable to
the longer tone since the ongoing conversation would be interrupted for
a briefer interval); or
b) f on 100 to 200 ms, silence 100 to 200 ms, f on 100 to 200 ms (the
total to be no more than 500 ms); 8 to 10 s silence."

So we agree that the '100-200 on, 100-200 off, 100-200 on' is cadence
but the sentence also states that the '300-500 ms on, 8-10 s off' is
"cadence".

Perhaps this is just a poor definition and we could accept the 8-10 sec
of silence as NOT part of the cadence and hence NOT part of cg/cw
signal.  But we still have a difficulty implementing the repetition in
H.248.

I grant that the wording of the spec may be misleading.  I know that when I
was developing the tones draft, there were several instances where tones
that conveyed the exact same information to the end user had different
names.  We tried our best to get a consistent definition amongst all the
standards bodies, geared to tone USE, rather than tone SOUND.  So, I
understand that the specs may have language that is muddy at best.

Method 1:
    Send cg/cw in a signal descriptor and set the signal completion
event to Notify when it completes.  MGC then sets a timer for 8-10 s
after receiving Notify and repeats cg/cw if desired.  The problem is
that I don't like MGC attempting "real time" control to meet a defined
standard.  Processing and message propogation delays make it difficult
to guarantee we meet the 8-10 window, although I admit this is long
enough and wide enough to reduce the  difficulty.  Other tones with
specified repeat intervals could be more difficult to meet.

Generally, repeat intervals on tones are fairly wide, mostly on the order of
seconds.  If the repeat interval is particularly short, perhaps the silent
interval should be considered part of the tone definition.  I can't think of
any tones off the top of my head that would fit the latter case, however.

As with all things packet, there are no guarantees.  However, in a
well-engineered and well-managed network, latency should be minimal, and the
MGC should be capable of providing timing to within the defined tolerances
for tone application.  Re-application of CWT is really a sort of red herring
here... it should only be reapplied if certain conditions are met at the
time the 10 seconds are up.  Because the MG cannot know whether or not the
conditions are fulfilled, it should be the MGC's call as to whether or not
to reapply the signal.

Method 2:
    Send a SignalList containing cg/cw, silence, cg/cw.  The silence
could be a signal defined to have a length between 8 and 10 sec.  The
2nd cg/cw can still be cancelled, if desired, by sending a new
SignalDescriptor without KeepActive (probably empty).  The only
difficulty here is that there is no standard "silence" tone defined (or
any other way to introduce the delay in the SignalList).  Of course we
could add silence to cg or to a new package, but E.180 also suggests
that the tone is not intended to interfere with the existing
conversation.  This means that voice should be heard during the 8-10
sec.  So we really need a "transparent silence" tone.  It cannot be
implemented as other tones might be using a recorded file, say 8 sec of
0's.  Again harder but this would permit more careful regulation of the
8-10 sec interval.  But if this technique is to be interoperable, we
need to add such a standard tone.

Doesn't this strike you as somewhat... backwards?  An MGC would send one
Signals descriptor to apply TWO tones, and TWO Signals descriptors to apply
ONE tone.  And then there's the "not-a-tone" tone... which is actually just
a timer, because we can't interfere with the speech path in between the
tones.  Further, the MGC is going to have to run a timer here anyway, to be
able to cancel the second tone if appropriate!  Since the MGC will already
be doing the work, I really don't see the benefit here.

Kevin

Kevin Boyle wrote:

>
>
> "Silence periods" is a bit misleading.  Any cadenced tone (such as
> busy) has silent periods in it.  Several alternative call waiting
> tones are also cadenced.  However, the 10 second interval is NOT part
> of the cadence.  The switch alerts the phone by applying CWT tone.
> Ten seconds later, the switch re-alerts the phone by applying CWT
> tone.  It is two separate applications of the same tone.
>
> I believe that if the MGC wants to re-apply a tone, then it should do
> so, and not depend on what might be a regional definition of
> "cycles".  There are scenarios, defined by regional specs, where CWT
> tone shall only be applied ONCE, due to interactions with other
> features, or line configurations.  The same tone would be applied
> TWICE in the normal case.  It is outside the scope of Megaco to define
> the number of cycles for which a tone should be applied.  There are
> constructs in the grammar to allow for repeated cycling of a tone...
> or define the tone as a timeout tone.  If there needs to be spaced
> application of the tone, such as with call wait, then the MGC should
> be responsible for applying the tone at the appropriate intervals, by
> reapplying the tone.
>
> To sum up, cadence for a discrete tone is part of the definition of
> that tone, and should be provisioned.  The number of cycles to apply
> should be handled by making the tone a timeout tone, or by having the
> MGC reapply the tone at appropriate intervals.
>
> I do not see a problem with the text.
>
> Kevin
>
>  -----Original Message-----
> From:   Terry L Anderson [mailto:[email-masked]]
> Sent:   Thursday, December 13, 2001 12:31 PM
> To:     Megaco Mailing List
> Subject:        [Megaco] Call Progress Tones Generator Pkg
>
>  << File: Card for Terry L Anderson >> The Call Progress Tones
> Generator pkg in Annex E.7 has little
> information about the tones and simply points to ITU E.180 in the
> procedures section.  This is sufficient for simple tones like dial
> tone,
> but it leave a bit of ambiguity about more complex tones like Busy or
> Call Waiting that have cadence.  Does the defined tone include silence
>
> periods for the cadence or is it simply the tone for the "on" phase?
>
> For example, the Call Waiting tone is "one or more cycles" of a tone
> 400-450 Hz with a cadence of
>     on 300-500 ms, followed by silence for 8-10 sec, or
>     on 100-200 ms, silence for 100-200 ms, on 100-200ms (total to be
> no
> more than 500 ms), followed by silence for 8-10 sec
>
> So does tone=cw simply give the 400-450 Hz tone leaving the cadence to
>
> be controlled by MGC using duration and interleaved silence tones?
> Or,
> should the entire tone, choice of cadence and "one or more cycles" be
> provisioned in MG as a signal and simply truncated if the specified
> duration expires?
>
> One complication is that the ITU intent is that voice be heard during
> the 8-10 sec silence gap.  I am not sure how many MGs continue to
> transfer media packets mid signal playout.  If not, they would not
> play
> voice if the 8-10 s of silence were implemented as part of the signal.
>
> It seems that the package should define whether tones include the
> cadence and repetitions.
>
> --
>
> ------------------------------------------------------------
> Terry L Anderson             mailto:[email-masked]
> Tel:908.582.7013   Fax:908.582.6729
> Lucent Technologies/INS/Voice Over IP Access Networks
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 14 Dec 2001 15:48:30 -0500

I am ready to concede that for cw or others with multi-sec intervals its
acceptable for MGC to control the interval (my previous method 1).  So I
won't belabor arguments for method 2 unless/until I come up with a
telephony tone with shorter or very precise repeat intervals.  I'll just
add one comment to your comment below.

Kevin Boyle wrote:

>  << File: Card for Terry L Anderson >> Unfortunately for the call
> waiting case, this distinction between
> I grant that the wording of the spec may be misleading.  I know that
> when I was developing the tones draft, there were several instances
> where tones that conveyed the exact same information to the end user
> had different names.  We tried our best to get a consistent definition
> amongst all the standards bodies, geared to tone USE, rather than tone
> SOUND.  So, I understand that the specs may have language that is
> muddy at best.
>
> Method 1:
> Generally, repeat intervals on tones are fairly wide, mostly on the
> order of seconds.  If the repeat interval is particularly short,
> perhaps the silent interval should be considered part of the tone
> definition.  I can't think of any tones off the top of my head that
> would fit the latter case, however.
>
> well-engineered and well-managed network, latency should be minimal,
> and the MGC should be capable of providing timing to within the
> defined tolerances for tone application.  Re-application of CWT is
> really a sort of red herring here... it should only be reapplied if
> certain conditions are met at the time the 10 seconds are up.  Because
> the MG cannot know whether or not the conditions are fulfilled, it
> should be the MGC's call as to whether or not to reapply the signal.
>
> Method 2:
> Doesn't this strike you as somewhat... backwards?  An MGC would send
> one Signals descriptor to apply TWO tones, and TWO Signals descriptors
> to apply ONE tone.  And then there's the "not-a-tone" tone... which is
> actually just a timer, because we can't interfere with the speech path
> in between the tones.  Further, the MGC is going to have to run a
> timer here anyway, to be able to cancel the second tone if
> appropriate!  Since the MGC will already be doing the work, I really
> don't see the benefit here.

I didn't think that the MGC needed a timer to "cancel the second tone if
appropriate".  This would be triggered by another event like DTMF or
PSTN signaling.  For example, for call waiting, if the notified party
chooses to go to the other incoming call the second tone is supposed to
be omitted.  But here MGC needs to send messages to accomplish this
anyway and would simply include an empty Signals Descriptor to also
cancel the rest of the tones.

But as I said above, I'll concede that the first method is simpler and
adequate.

--

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 14 Dec 2001 15:48:30 -0500

--

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 14 Dec 2001 15:48:30 -0500

--

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 14 Dec 2001 15:48:30 -0500

--