Subject: Re: Dialed Digit Collection

From: Brian Rosen <[email-masked]>
Date: Thu, 23 Sep 1999 10:29:31 -0400

I think you can have an embedded event descriptor that
would apply the dialtone and the digitmap.

Event=3345a4{generic/offhook:Accumulate:Event=3345a5
{dtmf/tone:DigitMap=NAstd:Signals{generic/dialtone}}

I think that is the right syntax, but others should check
me.

I have made up package and itemIDs.  When we agree on
the default package definitions, this would change.

Brian

> -----Original Message-----
> From: Eric Cooper [mailto:[email-masked]]
> Sent: Thursday, September 23, 1999 9:43 AM
> To: [email-masked]
> Subject: Dialed Digit Collection
>
>
> 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: Brian Rosen <[email-masked]>
Date: Thu, 23 Sep 1999 11:23:48 -0400

I could see having a dialtone signal that turned off
if DTMF was detected.  I'm not in favor (you knew that)
of having the setting of an EventDescriptor have
side effects.

That would fix my problem.  The off-hook has an embedded
event that has the dialtone-till-digit signal, and the
digitmap accumulate event.

If you want to have MGC interaction between the off hook and
the dialtone/collect digits, then you don't use the embedded
event.

My solution did show a problem.  Notice that I created this
event with an eventID that I don't (necessarily) want to
be Notified.  There is no action that is "use the embedded
eventsdescriptor, but otherwise don't do anything".  I
specified Accumulate, where I would expect to discard
the event as not being in the eventsdescriptor when the
embedded event terminal digit was found.  Not a pretty
answer.  Probably need to have a "Discard" or at least
"EmbeddedEvent" action.

Brian

> From: Al Varney [mailto:[email-masked]]
> Sent: Thursday, September 23, 1999 11:11 AM
> Subject: Re: Dialed Digit Collection
>
>
> At 16:43 09/23/1999 +0300, Eric Cooper wrote:
>    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
>    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]
>