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

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 24 Aug 1999 01:39:08 -0400

Surely one package does for all line types.  The logical events are the same
(e.g. off-hook) and the MG can (should) hide the physical realities from the
MGC.  The only thing the MGC should know about are differences in procedure
and timing which require its intervention, and awareness of these
differences will be provisioned in the MGC as a logical signalling type for
the termination concerned.  Am I being naive?

> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Monday, August 23, 1999 2:13 PM
> To:   [email-masked]
> Subject:      CAS packages (Re: Aspect of IP and Sat digital telephony not
> considered by sigt ran)
>
> Actually, LoopStart and GroundStart are the simplest cases of CAS.
>
> They are easily modeled as an analog line interface, because they were
> designed as a digital analog of an analog line.  :-)
>
> Loop Start/Ground Start have basically the same events and signals as an
> analog line:
>          Off-hook (Seizure)
>          On-hook
>          Ringing
>          In-band Dial Tone
>          in-band DTMF or pulse dialing (one way only)
>          etc.
>
> Someone needs to write up a package for this.  We should probably take the
> line package (when it is finished) and modify it for a LS/GS CAS FXO/FXS
> package.
>
> At some point someone will have to write a package for the various E&M
> (and
> Reverse Battery) signaling types.
>
> Someone has proposed an R2 package, but it hasn't garnered much comment.
>
> BTW, I don't believe anyone is proposing.
>
> Chip
>
> At 07:04 PM 8/23/99 +0530, [email-masked] wrote:
> >Al,
> >          Are you trying to suggest in the mail below that information
> like
> >Loopstart, Groundstart etc can be controlled by the MGC rather than
> >provisioned
> >in the MG ? If yes, kindly explain how because MEGACO does not have any
> such
> >mechanism.
> >
> >Regards,
> >
> >Vikas Bajaj
> >Gateway Development Team
> >  Hughes Software Systems Ltd.
> >
> >
> >
> >
> >
> >Al Varney <[email-masked]> on 08/20/99 11:25:59 PM
> >
> >Please respond to Al Varney <[email-masked]>
> >
> >To:   [email-masked]
> >cc:    (bcc: Vikas Bajaj/HSS)
> >
> >Subject:  Re: Aspect of IP and Sat digital telephony not considered by
> sigt
> >       ran
> >
> >
> >
> >
> >At 09:58 08/18/1999 -0500, Tom-PT Taylor wrote:
> >
> > >Leaving aside the GPS case, the only instance in which the MG could add
> more
> > >information on location than the MGC already has is when the call is
> coming
> > >in on an analogue line.  The TerminationID covers that one.  The
> relevance
> > >to SIGTRAN comes in when ISDN is involved, and SIGTRAN might be the
> place
> > >where the specific signalling interface originating the call is
> identified.
> >
> >    I don't understand how the MG would know more about an analog(ue)
> line
> >than the MGC.  Wouldn't any location-related information regarding a line
> >be provisioned at the Call Agent, rather than in a Gateway?  The MGC
> would
> >also be the place for billing information, line restrictions, etc.  The
> MG
> >should be required to have very little line-related information
> (loop-start
> >vs. ground-start, in-service vs. out-of-service) and even that could be
> >controlled by the MGC rather than provisioned in the MG.
> >
> >    SIGTRAN should be capable of identifying an instance of a signalling
> >interface (a D-channel of a BRI/BRA interface, for example) using
> something
> >similar to MEGACO's TerminationID.  SIGTRAN itself should not be expected
> >to know/care about the "location" of that interface, any more than an MG
> >should know/care about the "location" of a line port.
> >
> > >> From: Brian Rosen [SMTP:[email-masked]]
> > >> Sent: Wednesday, August 18, 1999 9:25 AM
> > >> To:   [email-masked]
> >
> > >> I don't think this thread has much to do with sigtran.
> > >> It does have relevance to megaco, and maybe others.
> >
> >    I disagree.  MEGACO should not internally generate or send location
> >information.  Any signalling by or about those interfaces may send such
> >information, but that's "transparent" to MEGACO.  If there is ever an
> >access interface requiring special procedures to query a location
> >(at a wireless gateway, perhaps), then that mechanism should be part of
> >the "package" supporting that interface.
> >
> > >> Can someone dig out the format of this parameter?  Maybe
> > >> we should add it to the localDescriptor.
> >
> >    I believe it's in ISUP 2000 -- ITU-T Study Group 11 sent in out for
> >determination in March (?) and had been discussing it for a year or so.
> >Note that ISUP only "transports" the information; other procedures are
> >needed to generate it and deliver the Geodetic Location information.
> >
> >It is also in the process of being added to ANSI ISUP (T1S1.3 effort) and
> >to ANSI ISDN (T1S1.7 effort on T1.628) for delivery to an ISDN user
> (PSAP).
> >This is for emergency services (E911 in the USA).  Also, wireless
> standards
> >in TIA (TR45.2) are developing documents:
> >   PN3890, Enhanced Wireless 9-1-1 Phase 2, and
> >   PN4288, Beyond Enhanced Wireless 9-1-1 Phase 2
> >for delivery of location information from wireless networks to emergency
> >service providers.
> >
> >    Where the location information comes from, and when, is an evolving
> story.
> >
> >
> >
> >
> >
> >
> >Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]
>
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 25 Aug 1999 12:33:42 -0500

That's clearly a vendor's decision, not a standards issue.  R2 and MFare
equally valid packages, but it's up to the vendor whether they get used.

> From: Matt Holdrege [SMTP:[email-masked]]
> Sent: Wednesday, August 25, 1999 12:55 PM
> Subject:      Re: CAS packages (Re: Aspect of IP and Sat digital telephony
> not  considered by sigt ran)
>
> At 09:51 AM 8/25/99 +0530, [email-masked] wrote:
>
>
> >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.
>
> 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: Boris Bekkerman <[email-masked]>
Date: Wed, 25 Aug 1999 16:58:44 -0500

Matt,

Your assumption is that MGC already supports backhauling of PRI D-channel. This
may not be always the case for PRI gateways. For example, I can create a PRI
package that defines events and signals sufficient enough to pass all signaling
information between MG and MGC. In fact, MEGACO architecture promotes this
option instead of relying on the yet another protocol. The same argument, I
think, is applicable to R2 signaling.

Boris Bekkerman

Matt Holdrege <[email-masked]> on 08/25/99 11:55:17 AM

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

Sent by:  Matt Holdrege <[email-masked]>

To:   [email-masked]
cc:    (Boris Bekkerman/MW/US/3Com)
Subject:  Re: CAS packages (Re: Aspect of IP and Sat digital telephony not
      considered by sigt ran)

At 09:51 AM 8/25/99 +0530, [email-masked] wrote:

>Matt,
>        Given that the major part of R2 signaling protocol will have to be
>    below or using the concept of packages defined by the MEGACO protocol.
>
>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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 25 Aug 1999 18:26:20 -0400

You CAN do a lot of things with the MEGACO protocol.
That doesn't mean you SHOULD do them!

Defining a package for PRI is a good example.  Yes, you
can do this.  But should you?  I don't think so.
The assumption so far is that the MGC terminates CCS,
using SIGTRAN for transport.

We want ONE way to do this, not 2 ways.  2 ways means incompatibility
unless I force everyone to implement both (or at least the
MGC).  In this case, I would argue strenuously that it would
be a BAD idea to have two ways to do Q.931.

We have been having the CAS debate for a long time.
I have been in favor of translation to Q.931 with SIGTRAN,
but more than anything I want ONE way to do CAS.

If we do CAS with a package, then:
        That is the ONLY way we should do CAS
        The package should cover all national variants
                or be easily extendable to do so.

There have been several people who have offered the opinion
that unless there is a short, guaranteed roundtrip time
between MG and MGC, that doing CAS with events is impossible.
Others believe that, with ONE level of embedding, it can be
done.  I have yet to see the latter, but I allow that it
might be possible.  There is certainly not a guaranteed,
relatively short round trip MG-MGC time.

Brian

> From: Boris Bekkerman [mailto:[email-masked]]
> Sent: Wednesday, August 25, 1999 5:59 PM
> To: [email-masked]

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 27 Aug 1999 08:25:10 -0500

You should bear in mind that the "high-level" messages you want to extract
from Q.931 are defined by the SDL in Q.931 Annex A.  Looking at those, I'd
judge there's going to be a huge amount of work required to say exactly what
data is carried by them and how it should be encoded.

> From: Boris Bekkerman [SMTP:[email-masked]]
> Sent: Thursday, August 26, 1999 1:48 PM
> Brian,
> We are talking about two different scenarios. I believe, you are assuming
> very
> primitive MG that is only capable of tunnelling signaling information to
> the
> master MGC. In this case it makes perfect sense to backhaul everything
> you've
> got via SIGTRAN. The MGC then would terminate the Q.931 and feed the Call
> Control Agent with all signaling information.
>
> In my case, however the MG is fully capable of terminating Q.931 and only
> needs
> a "high level" signaling assistance from the MGC. There is no need to pass
> every
> parameter from Q.931 message between MG and MGC. The package I was
> thinking
> about, would describe only parameters that are of end-to-end significance,
> which
> my MGC is interested in. My thoughts are that this can be easily
> accomplished
> within the package framework. In fact, such package could possibly support
> both
> Q.931 and R2 requirements. The alternative to using MEGACO's
> events/signals
> mechanism would be, after terminating the Q.931 in the MG once, to
> backhaul it
> again to the MGC, which will have to implement yet another instance of
> Q.931
> stack. I do not see any advantage of doing that.
>
> I don't see any saving in round trip time ether. How does the SIGTRAN's
> version
> of the transport would work faster then MEGACO's?
> However, the call setup time is definitely faster when using MEGACO's
> events/signals. For example, In my case after MG receives a Q.931 "Setup"
> it can
> respond right away to the switch with Q.931 "Call Proceeding" and then
> send a
> Notify transaction to MGC. There is only one network transaction needed.
> How
> does backhauling that "Setup" message to MGC helps me to achieve shorter
> round
> trip time?
>
> Boris.
>
>
>
>
>
> [email-masked] on 08/26/99 07:09:21 AM
>
> Please respond to [email-masked]
>
> Sent by:  [email-masked]
>
>
> Brian,
>            Since it is very important that  "We have one way to do this",
> it is
> time now that we thrash this issue
>    and decide on it.
>
> Regards,
>
> Vikas Bajaj
> Gateway Development Team
> Brian Rosen <[email-masked]> on 08/26/99 04:56:20 AM
>
> Please respond to Brian Rosen <[email-masked]>
>

---

From: [email-masked]
Date: Sat, 28 Aug 1999 18:36:50 +0530

Mike,
         None of the packages have yet been standardised. The current version of
H.248/MEGACOP contains
    no package definition. The plan is to define the packages as separate RFCs.
Except for the IP Phone,
    audio package and R2 package drafts  (kindly excuse me if I have missed a
couple of them) there are no
    proposals for other packages. This does not imply that we find alternate
methods to achieve what is achieved
    by the packages that MEGACO plans to define.

  Regards,

Vikas Bajaj
Gateway Development Team
Hughes Software Systems Ltd

Michael Thomas <[email-masked]> on 08/27/99 02:06:21 AM

Please respond to Michael Thomas <[email-masked]>

 > 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