Subject: Re: [Fwd: On 7.1.14]

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Apr 2000 22:52:33 -0500

The issue in this dialogue is handling the extra digit in the case of a
partial digit map match.

If the initial digit map is supposed to provide the complete story, the MGC
can embed a new Events descriptor in the digit map completion event,
containing no event related to digit collection.  This is guaranteed to
clear out the extra digit, since under the current rules that extra digit is
the first event to be processed after the digit map completion is reported.

If, on the success path, more digits will be collected after the first digit
map completion event is reported, the MGC has to examine the reason for the
completion and then send down a Modify with an Events descriptor devoid of
any event related to digit collection followed by a Modify with a repeat of
the first digit map (along, presumably, with the necessary prompting
signals).

There's also a question of when the extra digit event exerts its side
effects.  According to the text I already have in the errata document I sent
out last week, that won't be until the event is recognized according to the
Events descriptor which is active once the digit map completion event is
reported.  Corner case: the mismatch occurs on the first digit.  Issue: does
this mean dial tone doesn't get broken by the dialled digit?  Answer: no
problem -- the digit map completion event does the job.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:[email-masked]]
> Sent: Wednesday, April 26, 2000 7:06 PM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:   'Brian Rosen'; 'John Segers'; Flemming Andreasen
> Subject:      Re: [Fwd: On 7.1.14]
>
> Hi Tom
>
> I snipped the ones we are in sync on.
>
> Should this one have gone to the Megaco list as well ?
>
>
> Tom-PT Taylor wrote:
>
>
>
>       Responses below.
>
>               -----Original Message-----
>       From:   Flemming Andreasen [SMTP:[email-masked]]
>       Sent:   Wednesday, April 05, 2000 11:14 PM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> [email-masked]
>       Subject:        [Fwd: On 7.1.14]
>       <snip>
>                       >
>                       > > 11) 7.1.14, numbered list, item 5:    It is
> entirely unclear why an
>                       > > event triggering a partial match is not reported
> as part of the
>                       > matched
>                       > > string. In the absence of a compelling argument,
> the triggering
>                       > event
>                       > > should be included in the string as it otherwise
> may be processed
>                       > twice,
>                       > > which is hardly what the user had in mind.
>                       >         [[TomT]]  I had it that way in the first
> place (with the
>                       > triggering
>                       > event distinguished by being placed in an "extra
> event" parameter) and
>                       >
>                       > consensus was to change it to what it is now.
> Have to overrule you on
>                       > this
>                       > one unless you get more support.
>
>                                       Well, I think it would be more
> appropriate that those who argue against
>                       explain why. There's got to be a reasonable
> explanation here, or
>                       reviewing this stuff is a waste of everybody's time.
>
>                       [[TomT]]
>                       The reasoning was that when you activate a digit map
> it's what the digit map matches that is of interest -- anything left over
> needs to be handled in a separate processing step.  The typical situation
> in our experience is that digit collection happens in multiple stages.
> The MGC doesn't want to receive that extra digit because it wants the
> digit to be processed against the next map to be activated.
>
>               Agreed, but only in the case where the first stage did not
> contain an error, i.e. mismatch. You want to consume the "error" input.
>
>               [PTT]
>       The MGC can do that in advance by embedding the appropriate Events
> descriptor in the digit map completion event, or after the fact by sending
> down the appropriate descriptor.
>
>
> I don't think you can do it in advance as you only want to consume the
> extra event on mismatch. Sending down two EventsDescriptors (two commands)
> introduces a race as you cannot be guaranteed that the first command will
> execute and consume the extra event prior to the second command being
> processed. I still cannot think of a single reason as to why you would not
> want to consume the event that causes a mismatch and it furthermore seems
> far simpler to me so my comment still stands.
>
>
>
>
>
>
>                                       I'll have to think about the "double
> processing" question.  Events have side effects, such as stopping signals,
> and clearly we only want those side effects to happen once.  It may be
> that we need language to make sure this is what happens.
>
> [PTT]
> ... and I now have the necessary language, I think.
>
>
> Did I miss it somewhere ?
>
>
>
>                                       > I'm also not clear how you get
> duplicate
>                       > processing -- the situation is logically
> equivalent to the triggering
>                       > event
>                       > (a non-matching digit) happening just after the
> digit completion event
>                       > has
>                       > been notified.
>
>                                       Consider an IVR menu where input
> consists of two or more digits. For
>                       sake of argument, let's say the only valid choice is
> "12", and I
>                       erroneously enter "13". Upon entering "3" we get a
> mismatch and I
>                       probably hear a recording telling me that "13" is an
> invalid choice and
>                       I should try again.
>                       [[TomT]]
>                       More likely you'll get a recording telling you what
> the valid choices are.  Under our current rules, of course, the MGC
> doesn't know about the 3 when the digit map completion event is reported.
>
>                                       When digit map processing resumes
> for renewed input,
>                       "3" will now be processed and I get another
> mismatch.
>                       [[TomT]]
>                       Seems clear in this case that the MGC should ensure
> that the event buffer is cleared before resuming the operation.
>
>               Agreed, however LockStep doesn't do that, so you have a
> problem.
>       [PTT]
>       It does if you precede your real command with one that has an empty
> Events descriptor.
>
> Ahh, very clever :-)
>
> -- Flemming
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839
>