Subject: Dialed Digit Collection

From: Eric Cooper <[email-masked]>
Date: Thu, 23 Sep 1999 16:43:22 +0300

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

If the protocol does allow this, what would the message look like?
Presumably it would involve modifying all terminations in the null context
to look for an off-hook event, then accumulate digits according to some
digitmap.   After this I get a bit fuzzy.  Is it possible to embed the
dialtone and clear signals appropriately, or do I have to use a script?

Any insight appreciated,

Eric.

---

From: Al Varney <[email-masked]>
Date: Thu, 23 Sep 1999 10:11:18 -0500

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

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

---

From: robert biskner <[email-masked]>
Date: Thu, 23 Sep 1999 09:24:19 -0700

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

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