Subject: Re: Dialed Digit Collection

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 24 Sep 1999 09:24:45 -0400

This thread is bringing out some good points for further work.  If I may
summarize, the events/actions we have been considering so far may have been
too granular, and may have to be consolidated into pieces which reduce the
exposure of the call setup sequence to MG-MGC round-trip times.  We need to
strike an appropriate balance between consolidation and the need for the MGC
to intervene and provide more information at particular points in the
sequence.

In the specific area of digit collection, there are probably three stages,
with the third one being repeated as necessary:

(1) The MG alerts the MGC to an initial offhook/seizure.

(2) The MGC allocates internal resources for the call and sends instructions
to create a new context and perform the first stage of digit collection.
The MGC will include an appropriate digit map for this purpose based on the
identity of the termination on which this event has occured.  In response to
the requested action, the MG provides dial tone or responds to the seizure
and collects a certain number of digits before reporting them to the MGC.
If digits are dialled/signalled after iut makes its report, it buffers them
awairting further instructions.

(3) If the MGC determines that it is not expecting any more digits, it
proceeds with the next stages of call processing.  If it appears that more
digits are required, it sends instructions to the MG to do so, possibly
including a new digit map.  This stage is repeated as required until digit
collection is complete.  On trunks, that may include collection of calling
number information (ANI) either before or after the called number.

We need to specify action primitives and accompanying notifications
appropriate to each of these three stages.

> -----Original Message-----
> From: robert biskner [SMTP:[email-masked]]
> Sent: Thursday, September 23, 1999 12:24 PM
> To:   [email-masked]
> Subject:      Re: Dialed Digit Collection
>
> Al,
>         Your answer brings up several very interesting topics related to
> the
> timeliness of CAS signaling on the CAS link connected to the MGW and the
> RTT on the control loop between the MGW and the MGC.
>         Suffice it to say, that today's switches, which presumably would
> at
> least be partially replaced by the new packet network being here
> proposed by MEGACO and others, have considerable  flexibility with
> regards to the timing of certain response events (e.g. application of
> wink, or dialtone after seizure), as well as to the length of their
> duration etc. The granularity of the current flexibiility on these
> incumbant switches is often on the order of 10ms (which may be
> overkill). (see for example Telcordia's (Bellcore's) "NOTES ON THE
> NETWORK" for a descriptionof existing switches capabilities). On the CPE
> side of CAS connections, the transistion from existing switches to new
> packet switches should (as a goal) involve as little CPE distrubance as
> possible - e.g. reprogramming (tweeking) of CPE equipment signaling
> parameters to accomodate new looser or tighter packet switch timings. It
> is unlikely, however, that the control loop between MGW and MGC will
> ever admit consistent short timing of these CAS response signals.
> Conversely, if one believes that the control loop can be made extremely
> fast, then there arise problems wrt to minimum signal durations etc.
> This suggests to some folks that a more autonomous treatment of these
> signaling events is necessary at the MGW. The content of that local
> autonomous treatment (e.g. packages) is certainly open to discussion,
> but IMHO, packages will be necessary. In fact, a stronger statement is
> possible. I suspect that some of the listed call flows  between MGW and
> MGC contain mostly anecdotal information about the CAS call. In some
> cases the ACTUAL CAS responses will be autonomously derrived and applied
> by the packages residing in the MGW before (or in some cases, perhaps,
> after) the command request received from the MGC.
>         It seems to me, that most of the MEGACO treatment of CAS signaling
> attempts to parallel the simple black phone (on/off hook) paradigm. That
> is to say that it attempts to coerce the CAS signaling into a simple
> phone model. I believe this is done mostly for historical reasons where
> an early attempt was made to make the MGW as "stateless" as possible.
> What might be interesting at this stage is to assume apriori that the
> MGW has packages, and hence state, which allow it to act autonomously
> wrt to CAS signaling. What then is the necessary and sufficient MEGACO
> information flow between MGC and MGW to control and complete a call?
> Would the MGC, indeed, need to request dialtone, or would it rather just
> request dialed number?
>         Another interesting topic is  failure scenarios. Who cleans up the
> CAS
> signaling link when the network connection fails, or when the MGW-MGC
> connection fails, or when the MGC fails? In the simple black phone case,
> the user presumably eventually hangs up. Life may not be quite so simple
> with a PBX or switch.
>
> bob
>
> Al Varney wrote:
> >
> > At 16:43 09/23/1999 +0300, Eric Cooper wrote:
> > >I was wondering if the protocol permits a Media Gateway Controller to
> > >atomically request the Media Gateway handle all the usual aspects of
> dialed
> > >digit collection (dialtone 'till first digit detection, silence
> thereafter),
> > >and just notify the MGC when dialing is complete?
> >
> >    The protocol permits almost anything.  The question is "What does a
> > particular PACKAGE in a particular MG actually do?".
> >
> > >The example in the draft shows several MGC-MG interactions to
> accomplish
> > >this task, but it does not include dialtone.  I am curious if the job
> could
> > >be done without involving the MGC until the digits were collected.
> >
> >    There are only 2 interactions (4 commands) involving digits in Annex
> G:
> > No. 3 (request offhook event) and No. 6 (notification of offhook) and
> > No. 8 (request digit collection) and No. 10 (notification of digits).
> > >From the context of the example, one must ASSUME that "Package1" will,
> > when asked to detect the "onhook" event with an ACTION {DigitMap=...}
> > [Section 7.1.10 shows a different syntax for this -- it seems to me the
> > last 2 paragraphs of 7.1.10 should be reconsidered in light of the
> > example, or the example should utilize Embedded Signals.  I prefer
> > the former, because linking signals with the offhook event can lead to
> > problems.  (my opinion).]
> >
> >    Part of my (unfinished) comments to Nancy Greene on the Annex G
> Examples
> > include more words around this issue.  Unfortunately, without a real
> > description of "Package1", one must guess at the MGs behavior.
> > I've assumed:
> >
> >  - The "Package1/offhook" event in Step 3 only looks for off-hook, and
> >    provides no tip/ring/bearer change as part of event detection.  In
> >    particular, dial-tone Signal is not applied as an Embedded Signal.
> >    [This is desired because dial-tone implies, in todays switches, that
> >    the switch is prepared to receive digits.  Having dial-tone occur
> >    as part of event detection creates a problem if the user dials prior
> >    to the MGC setting up the digit map.]
> >
> >  - The "Package1/onhook" event request in Step 8 must either
> automatically
> >    offer dial-tone (and remove it after the first digit) OR
> >    Step 8 must have a Signal added (Package1/dialtone) and an
> >    Embedded Signal (Package1/dialtone off or Package1/Clear) to remove
> >    dial-tone after the first digit.
> >    It's not obvious how DigitMaps interact with Embedded Signals or
> >    Embedded Events -- if the signal/event only occurs at the time of
> >    Notify, then there is no way to do dialtone correctly via a DigitMap.
> >
> >    It seems to me that, given dial-tone/digit-collection is such a very
> > common procedure for line/residential GWs, the package supporting the
> > procedure should be optimized for it.  Thus something like
> "Package1/collect"
> > should be added to the "Package1/onhook" event list (since we need to
> > always be watching for onhook).  The "collect" event REQUEST triggers
> the
> > MG to offer dial-tone (and turn it off appropriately).  The Notify of
> the
> > "collect" event occurs only after digits are collected or a timeout
> occurs.
> > (I'm assuming the "onhook" event continues to be on the event list after
> > the "collect" Notify is sent.)
> >
> >    The "collect" event also needs a package-specific parameter to modify
> > the type of tone presented to the caller (recall dial tone, confirmation
> > tone, etc.).
> >
> >    I was planning on working this out with Nancy rather that involving
> > the entire list, but perhaps a wider discussion is needed.  In
> particular,
> > the idea that the REQUEST of an event could trigger actions beyond
> detection
> > of the event may find some objection.
> >
> >    Now I know why Nancy has been asking for help on Annex G....
> >
> > Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]
>
> --
> __________________________________________________________________
> Robert Biskner  Cisco Systems Inc.      email: [email-masked]
>                 Systems Architecture MSSBU
> BLD 3                                   150 Castillian Dr.
> San Jose, Ca. U.S.A.                    Santa Barbara, Ca. U.S.A.
> Tel: (408) 525-7547                     Tel: (805) 961-3632
> FAX: (408) 525-xxxx                     FAX: (805) 961-3606
> __________________________________________________________________

---

From: robert biskner <[email-masked]>
Date: Fri, 24 Sep 1999 09:39:28 -0700

Tom-PT Taylor wrote:
Tom,

        Your decomposition looks about right. I've added some comments below to
your text, but I certainly don't KNOW the answers. It would be nice to
hear from some experts.

bob

> (1) The MG alerts the MGC to an initial offhook/seizure.
COMMENT (RB): The MG additionally probably acknowledges the seizure, and
prepares to gather dialed digits. It is interesting to question whether
or not the MG should indeed acknowledge automatically or if it should
rather do a sanity check to make sure it can indeed support another call
before acknowledging. Also should the MG flush the current digit map
(assuming that it belongs to a previous call's second or further stage
mapping) or should it begin immediately to match against the existing
digit map? Other possibilities abound! My vote (certainly worthless) is
for the MGC to make sure that the correct digit map is in place. This
happens first at registration, and second at the end of the previous
call.
> to create a new context and perform the first stage of digit collection.
COMMENT RB: requesting digit collection is probably not useful since it
may in some cases already have occured. In a way the old concept of
"quarantine buffer" applies here. If the MGC wishes to abort digit
collection (perhaps because it is too busy to support another call right
now)  the lack of an explicit command to the MG (an "add" ? with or
without a new digit map ?) will cause the MG to simply gather and buffer
the digits. Either the MGC will eventually get around to sending the
"add" or the call will time out. I am really not sure about this one
(certainly don't pretend to be a CAS expert here). BUT, some of the
seizure acknowledge timings seem short. Post dial delay will be
affected, certainly, even if the seizure acknowledgement can be extended
to the MAXIMUM. I guess what seems appropriate here is a closer look at
what the MGC REALLY NEEDS to tell the MG to do.
> awairting further instructions.
COMMENT RB: I agree with the last part of this section, and again
suggest that similar behavior wrt digit collection could be always
applied by the MG - namely "collect them, buffer them, and await further
instructions".
> number information (ANI) either before or after the called number.
COMMENT RB: Is the collection (or presence and sequence) of ANI and DNIS
(access codes etc.) a function of the line protocol or of the calling or
called party number? If it is a function of line protocol (my quess?),
it MIGHT be appropriate to put this processing knowledge into the
"package" and simply allow the MGC to request these items by name???
> appropriate to each of these three stages.
COMMENT RB: Agreed. Indeed, IN MANY CASES one of the short comings of
the previous SGCP and MGCP offerings was that they only described the
line "protocol" and not the expected behavior (e.g. action primitives
and accompanying notifications) of the entities on either end of that
line wrt providing a system service. This made it virtually impossible
to construct a MG and a MGC independently to provide a particular
service.

bob