Subject: Re: Aspect of IP and Sat digital telephony not considered by sigt ran

From: [email-masked]
Date: Mon, 23 Aug 1999 19:04:56 +0530

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]

---

From: Al Varney <[email-masked]>
Date: Mon, 23 Aug 1999 15:07:13 -0500

>in the MG ? If yes, kindly explain how because MEGACO does not have any such

   I didn't mean to confuse the main point (MGs don't know about location).

   MEGACO does not have any mechanism for detecting line off-hook at all; only
packages can do so.  Thus one could develop a package that supported 2 events,
loopStartOffhook and groundStartOffhook, allowing the MGC to determine which
event should be detected by the MG.  The EXAMPLES in MEGACO assume a single
offhook event, requiring the MG to either "know" which lines are GroundStart
or be wired differently from LoopStart (and thus the MG would not "know" the
difference).  In either case, the MGC will probably need this information,
since timing/flash/disconnect/etc. requirements differ for the two types of
line.

   I'm not advocating a particular mechanism -- in fact, I think it likely
that many line gateways will not support GroundStart lines at all.  I was
just suggesting that it was possible to imagine a gateway that ONLY knew
the TerminationID of a line, and nothing else.  A line gateway can either:
   - ONLY support one style of line, one style of balancing network, etc.,
   - support a provisioning interface outside MEGACO,
   - require a package supporting receipt of the information from MEGACO
      (this could be a "line test/maintenance" package) or
   - require manual configuration of the line interface.

   All of these require some form of TerminationID, which could be a physical
port number on the MG (and thus be implicitly provisioned).  Note that these
options don't result in an MG being able to "tell" an MGC any non-hardware
characteristics of a line -- such as Telephone Number, location, dialing
plan, tone vs. pulse dialing or subscribed features.

---

From: Chip Sharp <[email-masked]>
Date: Mon, 23 Aug 1999 11:12:53 -0700

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

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