Subject: RE: Additional supervisory signals for analog lines

From: Martin Taylor <[email-masked]>
Date: Wed, 21 Feb 2001 03:15:36 -0800

Michael

Thank you for your detailed response to my question on supervisory signals.
I'm aware of the excellent work that is being done on alerting,
supplementary tones and caller ID.  I believe that the supervisory signals
issue is the last remaining area of work that needs to be completed to
enable MGs to provide the full set of line-side features available from
current switches.

I agree that the level of detail involved in debating the solution to this
may not be appropriate for this exploder, and I'd certainly support your
suggestion to convene a group of interested parties to work on this.  Please
count me in.

Regarding the ATMF packages, it is worth pointing out that these are aimed
at a very specific and non-typical use of Megaco as a means of supporting
supervisory signaling to VoDSL IADs that implement the Loop Emulation
Service.  The requirement in this case is to support the full set of PSTN
service needs of both North American and ETSI markets, and to provide a
clean and efficient mapping to both CAS (for GR-303) and to V5 PSTN.  The
parameter-driven approach to the package design was inspired by the V5 PSTN
protocol.  The subtle distinction between events like "on-hook" and "loop
open" is that on-hook is notified only after the phone has been on-hook for
around a second (so you know that this is not the start of a flash) whereas
loop open is notified as soon as the loop impedance goes high.  We need this
distinction to support a mapping to CAS signaling for GR-303 that meets the
signaling timing requirements of TR-57.  Hence the reasons for not using the
"al" package from RFC3015 are twofold: first, some of the supervisory states
that we need are missing, such as LCFO and RLCF; and secondly, the signaling
timing requirements for mapping to CAS can't be met with the existing
definitions of the signals "on", "of" and "fl".

Martin Taylor

> -----Original Message-----
> From: Michael Brown [mailto:[email-masked]]
> Sent: Tuesday, February 20, 2001 6:40 pm
> To: Martin Taylor
> Cc: [email-masked]'
> Subject: Re: Additional supervisory signals for analog lines
> 
> 
> Martin,
> 
>    Sorry for the delayed response. My email server was 
> apparently holding
> messages so I just saw the post.
> 
>    The quick answer to your message is that there is indeed 
> some other ongoing
> work which relates to analog line supervision. Nortel has a 
> proposal/draft for
> an enhanced alerting package which provides support for 
> distinctive ringing/call
> waiting as well as for both on-hook and off-hook callerid 
> display. In addition,
> there is a package (Robbed Bit Signaling Package) defined in 
> a recent draft
> (draft-manyfolks-megaco-caspackage-00.txt) from a Megaco 
> design subteam for CAS
> which defines a mechanism to provide support for metering. As 
> an aside, it is
> also used to generate North American MF Winks.
> 
>    I assume that your post is driven by comments from the 
> recent MSF meeting
> where I had suggested that I would like to see us (Megaco WG, 
> SG16, ATM Forum,
> among others) work together to normalize the development of 
> the the ATMF
> packages with work ongoing in Megaco WG.   As you point out, there are
> additional functions, such as loop current feed open, which 
> are not reflected by
> these packages. As you point out, there may be some types of 
> functions which are
> NOT reflected in the existing/in progress packages. Certainly 
> the AL package was
> a "starter kit" view of meeting the requirements for analog 
> lines. What I'm
> suggesting is that where there are existing definitions that 
> they be used and
> extended as per Megaco package extension mechanisms rather 
> than creating new
> definitions for those packages.
> 
>    I do also have some concerns about the way in which the 
> packages are
> constructed in the ATMF proposal. A couple of areas of concern are the
> specification of signals as parameters to a set of  
> overarching signals and
> there are some instances where I believe properties are 
> defined which would be
> better suited to be statistics.
> 
>    At any rate, the point of this response is simply to 
> indicate that I believe
> there is common ground in defining signaling for analog lines 
> that we can and
> should take advantage of.
> 
>    A question I would ask as a starting point for discussion 
> is why the analog
> lines package in 3015 was not used as a basis for the ATMF 
> packages. I believe
> that the AL package does provide the capability to handle 
> on-hook, off-hook,
> flash hook, and basic ringing in the same way as defined in 
> the ATMF packages
> and therefore redefining those signals/events isn't necessary.
> 
>   One more quick comment is that I'm not certain whether this 
> discussion might
> be better taken "off the list" and carried on between 
> specifically interested
> parties from the various fora involved in this work and then 
> brought back to the
> list after working out the issues/questions. Perhaps include 
> a conference call
> to kick off and try to accelerate the work? Opinions? If this 
> is viewed to be a
> good way to go forward, I would be willing to collect the 
> list of people
> interested in participating and to coordinate a kick off 
> conference call for
> late this week or early next week.
> 
> Michael Brown
> 
> Martin Taylor wrote:
> 
> > The only package I have been able to find for supervisory 
> signaling on
> > analog line terminations is the "al" package in RFC3015.  
> The only signal
> > supported by "al" is "ring".  This package therefore does 
> not cover the full
> > range of North American requirements for analog line 
> signaling.  To do this
> > it would be necessary to define additional signals, for 
> example "reverse
> > loop current feed" and "."
> >
> > Am I missing something here?  Is there any work in progress 
> on enhanced
> > analog supervisory packages?
> >
> > Martin
> >
> > ========================
> > Martin Taylor
> > CopperCom
> > 3651 FAU Boulevard, Suite 300
> > Boca Raton, FL 33431
> > 561 239 6694
>