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

From: [email-masked]
Date: Tue, 24 Aug 1999 11:15:41 +0530

Chip,
       Will the new CAS package need to distinguish between the different
variants of CAS signaling i.e. LS/GS,
       FXS/FXO ? Will not the set of events and signals be the same for the
different variants ? The procedures are
       of course different but they need to be handled by the MGC and may not
fall under the scope of the MG.

      BTW, R2 package was proposed by us and there were a few queries on it
initially. There have not been
     any comments lately (???).

     Regards,

    Vikas Bajaj
     Gateway Development Team
     Hughes Software Systems Ltd.

Chip Sharp <[email-masked]> on 08/23/99 11:42:53 PM

To:   Vikas Bajaj/HSS@HSS, [email-masked]
cc:

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: Chip Sharp <[email-masked]>
Date: Mon, 23 Aug 1999 23:08:20 -0700

I don't know for sure.
LS/GS are line signaling protocols and E&M is a trunk signaling
protocol.  I just think of them as different.  I don't think there needs to
be a separate package for FXO and FXS (or GS and LS).

It might make sense for a separate package for E&M.

Chip

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 24 Aug 1999 11:44:32 -0700

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