Subject: Re: On 7.1.4

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 16 Mar 2000 05:24:59 -0500

Responses below.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:[email-masked]]
> Sent: Saturday, March 11, 2000 11:47 AM
> To:   [email-masked]
> Subject:      On 7.1.4
>
> Tom Taylor wrote:
>
> >
> > > 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x'
> > is
> > > used as a wildcard..." specifies that "As a consequence of the thrid
> >
> > > timing rule above, inter-event timing while matching the dot symbol
> > uses
> > > the short timer by default." is incorrect. The grammar may continue
> > past
> > > the dot symbol implying the dot could only possibly produce a
> > partial
> > > match which furthermore implies that the short timer may not be the
> > > right one to use. The sentence should simply be removed.
> >         [[TomT]]  Agreed that the grammar may continue past the dot,
> > but
> > until you get that far you have an ambiguous situation -- you don't
> > know how
> > many events will be mapped into the dot.  The sentence is correct
> > AFAIK.
>
> That's not entirely accurate, e.g. consider "x.#" Now, if what follows
> the dot has a non-empty intersection with what precedes the dot
> (ignoring timers), you have an ambigous situation. In that case you
> could then apply the short timer, or alternatively simply leave the
> timing rules undefined then (since you can always rewrite the digit map
> to avoid this, well at least in most cases).
        [[TomT]]
        The term "ambiguous" is used in this section to mean that multiple
patterns in the digit map match the current dial string.  The pattern "x.F"
(not "x.#") is a short way of specifying a whole series of patterns: "xF" |
"xxF" | "xxxF" | ...  This is why I say that the dot creates an ambiguous
situation which calls for the use of the short timer.  At any point in the
dialling process short of receiving the final #, there is an indefinite
number of patterns which the current dial string may match.

> >
>
> >
> > > 8) 7.1.14, next paragraph specifies that "A timer specified
> > following a
> > > dot specifies inter-event timing for all events matching the dot as
> > well
> > > as for subsequent events". It's unclear why the timer couldn't
> > simply be
> > > put in front of the dot and thereby be consistent with digit map
> > timers
> > > in general. In the absence of a compelling argument the sentence
> > should
> > > simply be removed.
> >         [[TomT]]  Same problem as with the previous remark -- you
> > don't know
> > when you've gone past the dot until it's too late.  If there is a
> > timer both
> > before and after the dot, a timer after the dot never gets used.  It
> > may be
> > better just to say that, I suppose, leaving it up to the MGC to set a
> > timer
> > before the dot if it wants.
>
> You could have have "S.xL", but otherwise I agree.
        [[TomT]]
        At this point I see that my remarks were a little imprecise: if
there is a timer both before and IMMEDIATELY after the dot, the timer after
the dot doesn't get used to detect the event that indicates that the dot has
been passed.  It may apply to events subsequent to that point.
> >
> >
> > > 9) 7.1.14, numbered list, item 4:    The second sentence and the
> > last
> > > sentence seem to contradict each other. While absence of
> > long-duration
> > > may prevent a match from occurring, existence of long-duration
> > should
> > > not. Consequently, the second sentence is what should be modified.
> >         [[TomT]]  I assume you mean the last sentence of the
> > paragraph.  You
> > will reach this case only if all of the alternatives specifying a
> > long-duration event at this point have been discarded.  Thus duration
> > becomes irrelevant, but only after it has been taken into account in
> > the
> > cases where it mattered.
>
> OK, I think I understand now, however the rule then seems to be
> incorrect. Consider the digit map "Zx1 | x2" with input "Z1". The way I
> read rule 4, the second sentence would lead us to discard alternative
> "x2" which doesn't seem like the right thing to do, since "x2" doesn't
> prevent us from having a long event, right ?
        [[TomT]]
        My reasoning in putting the rules together was that by specifying a
long-duration event in a given position you were saying that duration really
mattered at that point and should be used as a discriminator between
candidate patterns.  I think the logic of that position is still reasonable,
but quite theoretical.  It really comes down to whether the rule prevents
you from doing the right thing in practical situations.

> >
> >
> > > 10) 7.1.14, numbered list, item 5 specifies that "If exactly one
> > > candidate remains, a completion event is generated indicating an
> > > unambiguous match". This seems to imply that even a partial match
> > (as
> > > long as there is only one) will result in a digit map completion
> > event,
> > > which of course is incorrect.
> >         [[TomT]]  Good catch.  This really is an error.  We should
> > change
> > that to "If exactly one candidate remains and it is fully matched,
> > ..."
> >
> > > 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.

        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.

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

> The event was
> processed twice which is the problem (a "process"/"discard" parameter in
> event handling would of course be a general cure for such problems, but
> alas, that was not to happen)
>
>
>
> >
> >
> > > 12) 7.1.14, second last paragraph states that "Regardles of whether
> > a
> > > digit map is activated, this form of event specification will cause
> > the
> > > individual events to be reported to the MGC as they are detected".
> > Some
> > > clarification is requested here.
> >         [[TomT]]  This paragraph gives the interpretation of e.g. the
> > "dd/*"
> > event specification.  Using the example digit map which immediately
> > follows,
> > a dialled "1" will be reported immediately and also accumulated into
> > the
> > digit map.  Of course, if EventBufferControl is set to LockStep, the
> > digit
> > map will never complete because a new Event Descriptor will be loaded
> > before
> > completion can be reported.  (There is a corner case with a dialled
> > "0" and
> > short timer expiry before the new Event descriptor is loaded, but
> > let's not
> > go into that.)
>
> I can, to some extent, understand that, although I think this dual
> processing does little but underscore the lack of generality in the
> event handling scheme (interesting case when you have EventBufferControl
> off). At a bare minimum I think you should define that an event detected
> can at most match or be consumed by a single "event" specified in the
> EventsDescriptor.
>
> What I don't understand in the above sentence is, that it seems to imply
> that the name by which we refer to an event impacts the reporting of
> that event. With the current "dd" package, you may request digit map
> matching without by only requesting the "Digit Map Completion" event,
> i.e. do not request DTMF digits (correct ?). Thus I might define another
> package, call it "dd2" that only consists of this particular event. What
> the above sentence now implies is, that when I request "dd/ce", I will
> process according to the digit map, but when I request "dd/*", which can
> only expand to "dd/ce", I will report the digits invidually. Doesn't
> seem right.
        [[TomT]]  It seems like you typed this one a bit quickly.  The
problem is that dd/* currently includes within its scope both the individual
digit events and the digit map completion event.  If you moved the latter
off to an extension package dd2, then I think we would have:
         - dd/* reports only individual digit events
         - dd2/* reports only the digit map completion event.

> -- Flemming
> --
> Flemming Andreasen
> Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 16 Mar 2000 15:59:31 -0800

Tom-PT Taylor wrote:

>      The term "ambiguous" is used in this section to mean that
>      multiple patterns in the digit map match the current dial
>      string.  The pattern "x.F" (not "x.#") is a short way of
>      specifying a whole series of patterns: "xF" | "xxF" | "xxxF" |
>      ...  This is why I say that the dot creates an ambiguous
>      situation which calls for the use of the short timer.  At any
>      point in the dialling process short of receiving the final #,
>      there is an indefinite number of patterns which the current dial
>      string may match.
>
That still doesn't sound right as it would imply that if I had say "12 |
13" in my digit map then upon entering 1, I would apply short interdigit
timing. The only thing that makes ambigouity interesting, is when you
*cannot* determine whether there is a match or not. The way you
determine that is then to apply a short interdigit timer, otherwise a
long timer is applied.

>      there is a timer both before and IMMEDIATELY after the dot, the
>      timer after the dot doesn't get used to detect the event that
>      indicates that the dot has been passed.  It may apply to events
>      subsequent to that point.
>
Even that may not be entirely accurate (although it in practice is
probably not a big deal), e.g. consider "S.xLF".

>      My reasoning in putting the rules together was that by specifying
>      a long-duration event in a given position you were saying that
>      duration really mattered at that point and should be used as a
>      discriminator between candidate patterns.  I think the logic of
>      that position is still reasonable, but quite theoretical.  It
>      really comes down to whether the rule prevents you from doing the
>      right thing in practical situations.
>
Fair enough. I think you are right that it will not be an issue in
practice.

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

>
>
>      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.
>
>      choices are.  Under our current rules, of course, the MGC doesn't
>      know about the 3 when the digit map completion event is reported.
>
>      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.

>      [[TomT]]  It seems like you typed this one a bit quickly.
>
Yes, the example should of course have referred to "dd2" instead of
"dd".

>      The problem is that dd/* currently includes within its scope both
>      the individual digit events and the digit map completion event.
>      If you moved the latter off to an extension package dd2, then I
>      think we would have:
>
Agreed (report most specific event). The current sentence does not seem
to imply this though unless you qualify it to specifically only
reference the "dd" package.

-- Flemming