Subject: Re: R2 Package Last Call

From: Matt Holdrege <[email-masked]>
Date: Mon, 10 Jul 2000 10:26:56 -0700

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?

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?

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: Sunil Mahajan <[email-masked]>
Date: Tue, 11 Jul 2000 09:06:23 +0530

hi Christian, it is

"draft-hss-megaco-r1package-00.txt"

regards,
Sunil Mahajan
VoIP Group
Hughes Software Systems

Christian Groves <[email-masked]> on 07/10/2000 10:52:02 PM

Please respond to Christian Groves <[email-masked]>

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

Subject:  Re: R2 Package Last Call

G'Day Tom,

What's the reference to the HSS R1 package that we are meant to be
agreeing to?

Cheers, Christian

---

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

(Embedded image moved to file: pic04527.pcx)  Kushanava Laha /HSS
----------------------------------------------------------------------------------------

From: Kushanava Laha@HSS on 12/07/2000 06:50 PM

To:   [email-masked]
cc:
Subject:  Re: R2 Package Last call

Hi Michael,
     The common functions that you are referring to are very limited in
number....It
is limited only to seizure, seizure acknowledge (which is achieved by a
combination of
delay-dial and start-dial at signaling level in MG) and answer. Even the release
signals in the packages cannot be abstracted at a common level, because as
indicated
by a difference in the signal parameters, what they achieve at signaling level
is very
different in the two signaling systems. The most interesting point is the
difference
in which address digits are send. Both the packages define an "address"
parameter, but
their scopes are different as because the signaling systems are different. One
is compelled
and the other is non-compelled. In R1 package, address limits to sending the
digits
flatly. Whereas R2 package extensively covers all possible information as
parameters
that may be required by MG during the compelling sequence. Further R2 package
defines
"blocking", unblocking", "Network congestion" , "subscriber line status", "dual
seizure"
etc as signals/events which are exploitation of the capabilities supported by
the R2 signaling
system and not possible in R1.
     In fact we had done a detailed analysis of exploiting the package
inheritance
concept before deciding on two different packages as we were left only with a
very few
options for commonality. And I feel the options would be further limited while
considering
other signaling systems.
     The concept of dedicating a package to a signaling system therefore makes
more sense
to me than breaking a signaling system into multiple packages. Further an
attempt to
filter a common base trunk signaling package runs a danger of landing into a
package that
has disjoint bits and pieces of each signaling system. This essentially means
that a MG
intending to implement only one signaling system, in its attempt to support the
common
package has to support fragments from other signaling systems - which is not at
all
desirable.

regards,
Kushanava Laha,
VoIP Team,
Hughes Software Systems.

Michael Brown wrote :

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

**Cheers**

-------------------------------------------------------------------------------
Be the change that you want to see in the world