Subject: Re: R2 Package Last Call

From: Kushanava Laha <[email-masked]>
Date: Tue, 11 Jul 2000 12:26:06 +0530

Hi Matt, List

please see responses embedded.........[HSS]

There is a need for base R1/R2 signaling package which can be extended to
support any country variant using package extension concept, so we feel that
these proposed packages can be frozen and as implementations start using them
extensions can be defined.

In case anybody sees any basic/important stuff missing from these drafts,
we can work on that.

regards,
Kushanava Laha
VoIP Team,
Hughes Software Systems

Matt Holdrege <[email-masked]> on 07/10/2000 10:56:56 PM

Please respond to Matt Holdrege <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sunil Mahajan/HSS)

Subject:  Re: R2 Package Last Call

Just curious, but are there any implementations of this package? Has anyone
tried transmitting a real R2 stream from a real public switch (not a
simulator) up to an MGC? In other words, has anyone actually tested this
package to see if it works? Or is it just theory at this point?

[HSS] Both the R1 and R2 packages have been implemented by HSS as per the
proposed package drafts. Testing with protocol simulators (AM8E) have been
done satisfactorily for some of the variants. Testing with real life switch
is on the way and we will share the results with the list as soon as the
testing goes through.
We are targetting few of the country variants for initial testing by
extending the base package definition for these variants.

There are a lot of sensitivities with R2 and it's multitude of variants to
make any alterations of it's architecture suspect. It would be nice to
understand this better before we make a Proposed Standard out of it. I
apologize for the interruption if this has already been done.

I'm also concerned that some of the values of variant parameters may not
fit in the fields. Caller-ID is one such parameter that varies country by
country. Has anyone done the research to make sure they will fit OK?

[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.
The R2 package though define the ITU-T flavour of R2 line and register
signaling,
is flexible enough to be extended by country specific packages that implement
the country variations. The extended packages may introduce non-ITU-T CAS
signals
in the form of additional signals and events. They may also introduce new values
for the signal/event parameters that satisfies the country specific requirements
in keeping with package extension philosophy.

In fact we are in the process of submitting a few of the country specific
extensions as well to supplement the concept.

At 09:24 AM 7/10/00 -0400, Tom-PT Taylor wrote:
>I hereby invoke WG Last Call on
>
>draft-ietf-megaco-r2package-01.txt
>
>with a view to making it a Standards Track RFC.
>
>I also request that any objections to making the HSS R1 package an official
>work item of the Megaco WG be stated.  If none appear by Thursday, I will
>make that package a WG work item.
>
>Tom Taylor
>Lead Standards Developer
>Phone and FAX: +1 613 736 0961
>E-mail: [email-masked]

---

From: Michael Brown <[email-masked]>
Date: Tue, 11 Jul 2000 10:39:52 -0400

I think that there is a definite problem with going last call on this package. Sorry
for not having brought this back up to the attention of the list sooner, but I
figured that discussion of proposed packages was somewhat on the back burner and was
a bit surprised by the Last Call announcement.

At any rate, the issue I have is with the way the packages for R1 and R2 as proposed
are defined architecturally. That is, when you take the two packages side by side it
is immediately apparent that there is very significant overlap in the packages
(signals and events). Based on the philosophy of creating packages as a hierarchical
tree structure where common functions are represented at the higher level and
variant specific functions are represented as extension packages, there needs to be
a base package representing those common functions and extension packages as
appropriate to reflect signaling and regional/market variants.

This is the basis of a proposal that I presented in Adelaide for PSTN trunking, to
support  robbed bit signaling. The proposal describes a high level package which
reflects the common functions as seen in the R1 and R2 proposals. It is described in
section 4 of the I-D, draft-brown-megaco-supplpkgs-00.txt.

I think this is the approach that we need to use in creating these packages to avoid
a proliferation of packages that contain definitions for the same signals and events
over and over again.

Given that, I believe that Last Call on the R1 package is premature.

Michael Brown

---

From: rahnkp <[email-masked]>
Date: Tue, 11 Jul 2000 10:30:58 -0600

Please PLEASE Please Take me off these lists. I feel as if I'm being
spammed!!!!!

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 11 Jul 2000 15:52:05 -0700

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

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?

---

From: Panditha Govindraj <[email-masked]>
Date: Wed, 12 Jul 2000 10:20:31 +0530

What does Modification of Gateway Out side the Context mean , When does this
scenario Occur.

---

From: Panditha Govindraj <[email-masked]>
Date: Wed, 12 Jul 2000 10:23:30 +0530

I correct my doubt

Modification of Termination outside of Context

govindaraj wrote:

>   ------------------------------------------------------------------------
>                           Name: govinda.rajp.vcf
>    govinda.rajp.vcf       Type: VCard (text/x-vcard)
>                       Encoding: 7bit
>                    Description: Card for govindaraj

---

From: Michael Brown <[email-masked]>
Date: Wed, 12 Jul 2000 12:05:44 -0400

A quick example would be to modify an idle line physical termination to look for
an off hook event.

Michael