Subject: Re: CAS packages (Re: Aspect of IP and Sat digital telephony not considered by sigt ran)

From: [email-masked]
Date: Wed, 25 Aug 1999 09:51:45 +0530

Matt,
       Given that the major part of R2 signaling protocol will have to be
handled at the MG (to reduce the call
  setup time and to keep the country variants out of the MGC), only the
significant events necessary for call
   control need to be reported to the MGC. This can be done either by
backhauling as suggested in your mail
   below or using the concept of packages defined by the MEGACO protocol.

   The latter of the two approaches is consistent with the basic MEGACO
philosophy that all media related
   stuff should be handled by the MEGACO protocol. This will also avoid
unnecessary complexity at the MG of inetrworking/translation from R2 to DSS1.
When ISDN terminates at the MG, it is easy to decouple the
SG functionality (signaling info can easily be passed to the SG module) from the
MG functionality. This will not
 hold true if you try to backhaul R2 signaling as DSS1 signaling. A strong
coupling between the SG and MG
  functionalities may result. This may be an implementation issue but if an
approach can lead to a
  cleaner implementation, then it should be adopted.

 Regards,

Vikas Bajaj
 Gateway Development Group
 Hughes Software Systems Ltd.

Matt Holdrege <[email-masked]> on 08/25/99 01:14:32 AM

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

To:   [email-masked]
cc:    (bcc: Vikas Bajaj/HSS)

Subject:  Re: CAS packages (Re: Aspect of IP and Sat digital telephony not
      considered by sigt ran)

At 11:15 AM 8/24/99 +0530, [email-masked] wrote:
>       BTW, R2 package was proposed by us and there were a few queries on it
>initially. There have not been
>      any comments lately (???).

I think that is because most people plan to translate R2 to DSS1 at the MG
and backhaul that to the MGC. Since DSS1 backhaul is already a SIGTRAN work
item, no new standardization is required.

For MG vendors, we will have to support DSS1 backhaul in the case of PRI
anyway. So it's a small matter to translate R2 signals into an existing
module. This also eliminates any homologation issues at the MGC.

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 25 Aug 1999 09:55:17 -0700

>unnecessary complexity at the MG of inetrworking/translation from R2 to DSS1.

How is R2 to DSS1 any harder than an R2 to MEGACO/R2 package? It's the same
messages coming in and going out. It's just one format versus another.
Since the MGC already is digesting DSS1 messages from a PRI D channel, it
is easier for the MGC to do the same for R2. By sending R2 messages in
MEGACO, you have lost that coupling and have to implement yet another
scheme in the MGC.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Aug 1999 13:36:21 -0700

> MEGACO, you have lost that coupling and have to implement yet another

  One very simple reason is that the MEGACO R2
package has not been defined yet, whereas Q.931
already has. That means that designers of a R2
package for MEGACO would not have to retrofit an
existing protocol -- with the inherent square
peg/round hole issues.

                Mike