Subject: [Fwd: On 7.1.14]

From: Flemming Andreasen <[email-masked]>
Date: Wed, 5 Apr 2000 20:14:18 -0700

Hi Tom

Resending this one with the items I think are still open (the ones we
left open last time and/or I didn't see in your latest issues summary
list).

Flemming Andreasen wrote:

>
>
> Tom-PT Taylor wrote:
>
>>
>>
>> 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.
>>
> 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.

>>
>>
>>      >
>>
>>      >
>>      > > 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.
>>
> Even that may not be entirely accurate (although it in practice is
> probably not a big deal), e.g. consider "S.xLF".

<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.
>
>>
>>
>>      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.
>>
> Agreed, however LockStep doesn't do that, so you have a problem.
>
>>
>>
>>      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.
>>
> 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:
>>
>>       - dd/* reports only individual digit events
>>       - dd2/* reports only the digit map completion event.
>>
> 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
>

Regards

            Flemming
--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839