Subject: Re: R2 Package Last Call

From: Kushanava Laha <[email-masked]>
Date: Wed, 12 Jul 2000 18:03:31 +0530

Hi Matt,
     Please find my comments embedded................[kL]

regards,
Kushanava Laha,
VoIP Team,
Hughes Software systems

Matt Holdrege <[email-masked]> on 07/12/2000 04:22:05 AM

To:   Kushanava Laha/HSS@HSS
cc:   [email-masked]

Subject:  Re: R2 Package Last Call

At 12:26 PM 7/11/00 +0530, Kushanava Laha wrote:
>[HSS] The packages have been deviced in such a way that all protocol timing
>sensitive issues while interfacing with a PSTN switch have been taken
>care in the MG, keeping the MGC transparent. In this way all latency
>related problems introduced in MG-MGC communication which may affect the
>time critical signals on the CAS signaling path have been best managed at MG.

It's true that the MG must respond to the time critical tones. But you
still have to get some info from the MGC to process the call and that is
where the timing of using MEGACO with this package could get hairy.

>> [kL] If you are referring to the time critical tones involved in address/
register signaling - both the R1 and R2 packages gives the flexibility to the
MG. In case of R1 the MGC sends the digits enbloc to the MGC as the "Address"
signal without bothering about the digit duration or the interdigit duration.
It is the MG which is provisioned with these timing information. And it is the
MG
which runs the statemachine for attaching the pre and post-ambles (ST and KP
signals)
and running the timers. The state machines for the line signaling (e.g.
running the debounce timers, timers associated with Delay-dial and start-dial
and interpretation of the bit patterns) are also run at MG. For R2 again the
"time critical tones" are encapsulated in one single signal/event in the
package which is once again the "Address" signal/event. However in case of
R2 (unlike R1) the "Address" signal/event now has additional parameters that
help the MG/MGC to partition conveniently the detailed information that is
exchanged between the MG and the PSTN switch during the course of compelled
signaling. At the line signaling end, such a timing issue did crop up while
handling the Release Guard sequence....However this also has also been
conveniently
packaged in the "Clear" event/signal which not only does not distinguish
between "Clear-back" and "Clear-forward" signals (leaves the interpreation to MG
which actually maintains the direction of the call as a part of maintaing the
state machine functionality) but also leaves the statemachine for the release
guard sequence to the MG (the "icrgtim" and ogrgtim" parameters only specifies
the
release guard timeout, if the MGC wishes to override).
The MGC-MG interface is therefore kept unaware of the time sensitive issues.
A time sensitive signal from the PSTN side shall never time out because of delay
incurred on the MG-MGC link as the handling is done at MG. Only relevant
information
that needs to be really conveyed to the Call Control has been packaged.
However we would really appreciate if you can point out at signal or parameter
level any discrepancy you may find in the package, which we may have overlooked.

Another case is Protocol State Machine malfunction in the Failure message. What
happens when an MGC wishes to convey that information to a switch or vice
versa?

>>[kL] I doubt whether either the R1 and R2 protocol gives the provision to
indicate
protocol state machine failures from one end-point to the other either through
line or address signaling. Hence what is MG supposed to do with the "State
Machine
Failure" message, if at all incorporated in the packages?

Could it be a problem to have open-ended strings in these messages?
Shouldn't we set some bounds? Also, could native descriptors be used
instead to give some bounding?

>>[kL]I fail to understand the scope of open-ended strings in the packages.
If the mode through which digits are reported to MGC, is what is being referred
to
the packages do talk about a string. The bound field is not needed as Megaco
does impose an upper restriction on the number of characters in a string.

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 12 Jul 2000 15:35:38 -0700

Please see my comments below...

>level any discrepancy you may find in the package, which we may have

Wow. The above missive contains some very useful information that should be
in the draft. In fact, I would remove the R2 tutorial since anyone can read
the ITU spec and put the above information in with the proper phrasing.

>Failure" message, if at all incorporated in the packages?

I don't understand. If it is not used, then why is it in your draft?

>does impose an upper restriction on the number of characters in a string.

For performance reasons bounding is a good idea in general.