Subject: Re: Cisco SG16: Keep Active

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 14:42:05 -0500

Coming out of Red Bank there was NO consensus on Events,
there was in fact wide disagreement on events.  Coming out of
Washington, there was NO consensus on events, there was in fact
wide disagreement on events.  The proposal we have in V13 was
an attempt to fix what people saw as problems in the event
mechanism.

In Red Bank, no one could explain how the MGCP mechanism works.
In Washington, several people attempted to explain how it works
(Christian Huitema was not there for that session).  Today in
fact, I'll bet you if you ask 10 people who claim they understand
how the MGCP mechanism works, you would get several answers,
although I would grant you that there is not a lot of variation
in the implementations.  The V13 mechanism was not comprehensible
to anyone in the design meetings in Washington or Red Bank.

I still have never been given any semblance of a reason why
the variables in the MGCP exist, and what you do with them.
I can, and have, provided same for the current mechanism.  So far
we have not, save the confusion over the digitmap/keep active
confusion, found a problem.

So far, I have found people who want the MGC to sort out events,
and they want them as fast as the MG finds them.  I also found
people who want a simple state machine, with the MG and MGC in
lock step over what should happen.  We cater to both of those.
You seem to want something in between, something where the MG
has more knowledge about what the MGC wants, and when it wants it
than I can figure out.  I can't understand how anything in between
gimme all of them, and gimme the next one can work; please
enlighten me.

Brian

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, February 04, 2000 2:11 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Cisco SG16: Keep Active
>
>
> Hi Brian
>
> Some comments below
>
> Regards
>
>             Flemming
>
> "Rosen, Brian" wrote:
>
> > We have just had a discussion on this issue, and I believe it
> > addresses it: digitmaps on dtmf optimizes reporting
> > of dtmf detection, but is otherwise the same as individual dtmf
> > events being enabled.  By that definition, KeepActive works the
> > way you wanted it; without it, signals stop with first detected
> > digit.  With it, signals continue while digits are detected.
> > So your IVR app would specify KeepActive on the digitmap completion
> > event, and use an embedded signal to turn it off if you wanted to.
> > The old mechanism doesn't work any differently; if you had specified
> > keepactive on the digits, whether or not they were accumulate by
> > digitmap actions, you still would not be able to treat the initial
> > digit differently from the terminating digit.  The only way you
> > could make this better would be to have the digitmap completion
> > event entirely separate from the dtmf detection events, so you
> > could have KeepActive separately on the digits from the completion.
> > I think embedded signals is a better answer, but I'm on record as
> > thinking that digitmaps should be a package and not a basic
> > protocol.
> >
> > I'll deal with any problems we still have with the current text,
> > but a "everything changed" complaint without a problem is a no-op.
>
> I beg to differ. A change without a problem is
> counterproductive and what
> gets into these situations. We had something perfectly fine
> after the Red
> Bank meeting which for some reason was changed. Exactly *what* was the
> problem that prompted this massive change (I'll spare you the ITU-T
> procedural arguments here). If there were no compelling
> reasons, then I
> suggest that the text is simply brought back in line with the
> agreement from
> Red Bank, and then we can close this (big) one and move along.
>
> If you really want to, we can start a debate about the
> relative merits,
> trade-offs, and shortcomings of one scheme versus the other.
> A couple of
> topics off the top of my head
> - Reduced number of messages and resultant reduced load on network and
> entities
> - Effective event arrival rate not limited by MGC-MG round-trip time
> - Support for scripting
>
>
>
> >
> >
> > brian
> >
> > > -----Original Message-----
> > > From: Chip Sharp [mailto:[email-masked]]
> > > Sent: Friday, February 04, 2000 12:12 AM
> > > To: [email-masked]
> > > Subject: Re: Cisco SG16: Keep Active
> > >
> > >
> > > At 03:22 PM 2/3/00 -0500, Tom-PT Taylor wrote:
> > > >
> > > >
> > > >I think the primary need here is for clarifying text in
> > > section 7.1.14
> > > >indicating that events mapped into a digit map do not generate
> > > >notifications, but do terminate ongoing signals unless the
> > > KeepActive flag
> > > >is set.
> > > Not really. The fundamental problem is the complete rework of
> > > the agreed
> > > upon event handling mechanism that for some reason was done
> > > after the Red
> > > Bank meeting.
> > >
> > > >
> > > >-----Original Message-----  From:  Chip Sharp
> > > >[SMTP:[email-masked]]  Sent:  Tuesday, January 25, 2000 7:43
> > > >PM  To:    [email-masked]  Subject:
> > >   Cisco SG16:
> > > >Keep Active
> > > >
> > > >Section:        7.1.9, "Event Actions"
> > > >table  Category:       Technical  Issue:          The draft
> > > text specifies
> > > >that "KeepActive:      As Notify, but  production of signals
> > > continues (if
> > > >any signals were active)".The above  definition is overly
> > > restrictive in
> > > >that it prevents events from being  accumulated (either with
> > > or without
> > > >digit map) and at the same time keeping  a signal active.
> > > For example an
> > > >IVR application accumulating a string of  user input and
> playing an
> > > >announcement until the entire string is  accumulated cannot
> > > be supported
> > > >with the above behaviour.  Proposal:       It is
> recommended, that
> > > >"KeepActive" does not generate a "Notify"  and that it
> > > becomes possible to
> > > >specify multiple actions such that  "KeepActive" can be
> > > combined with,
> > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> the particular
> > > >application.
> > > >
> > > >v13 Status:     OPEN. Event actions table has been removed and
> > > >extensive  modification of entire event processing taken place.
> > > >
> > > >Section:        7.1.9  Category:       Technical  Issue:
>          The
> > > >draft text specifies that "When KeepActive is specified
> as the  event
> > > >action, the media gateway shall send a Notify message to the
> > >  controller
> > > >upon detection of the event. Furthermore, the controller
> shall  not
> > > >interrupt any signals active on the Termination on which
> the event
> > > >is  detected" The above definition is overly restrictive
> in that it
> > > >prevents  events from being accumulated (either with or
> > > without digit map)
> > > >and at the  same time keeping a signal active. For example an IVR
> > > >application  accumulating a string of user input and playing an
> > > >announcement until the  entire string is accumulated cannot
> > > be supported
> > > >with the above behaviour.  Proposal:       It is
> recommended, that
> > > >"KeepActive" does not generate a "Notify"  and that it
> > > becomes possible to
> > > >specify multiple actions such that  "KeepActive" can be
> > > combined with,
> > > >e.g. "Notify" or "AccumulateByDigitMap"  depending on
> the particular
> > > >application.
> > > >
> > > >v13 Status:     OPEN. Extensive modifications of event
> handling has
> > > >taken  place. Events now always reported immediately on
> detection.
> > >
> > > Support NetAid!  http://www.netaid.org
> > > --------------------------------------------------
> > > Chip Sharp                 Consulting Engineering
> > > Cisco Systems              Telco Bio-region
> > > Reality - Love it or Leave it.
> > > --------------------------------------------------
> > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 7 Feb 2000 19:49:05 -0500

Brian

This turned out to be a somewhat lengthy e-mail but there doesn't seem to be
another way, so...

Below I've tried to explain in more detail some of the problems I see with
the event handling mechanism specified in H.248 v14. I hope this clarifies
the issue and also illustrates why the TD-58 solution from the Red Bank is
better.

The current event handling mechanism in Megaco/H248 v14 can be viewed as
three processes that all interact. Events can be viewed as always being
added to an event buffer (a FIFO queue) by an Event Detection process.
Another Event Processing process then removes these events from the FIFO
queue. When a notification is sent, this process may block, waiting for a
new EventsDescriptor to be received. Events detected meanwhile will simply
be added to the FIFO queue. Finally, whenever a new EventsDescriptor is
received the third process runs. This process determines the fate of events
of events sitting in the FIFO queue, and installs a new EventsDescriptor.

The processes are illustrated in pseudo-code below

Process 1: Event Detection
===================
do {
<wait for new event>
if < event in current EventsDescriptor> then   /* current EventsDescriptor
*/
  <add event to event buffer>
 else
  <discard>
} forever

Process 2: Event Processing
===================
do {
 < wait for event in event buffer>
 < remove first event from event buffer>
 if <event in current EventsDescriptor> then {
  Notify(event)
  if  (Eventbuffer = “on”) then  /* current EventsDescriptor */
   <wait for new EventsDescriptor>
 }
} forever

Process 3: New Event Descriptor
=======================
if <Eventbuffer = “off”>   /* new EventsDescritpr */
 <clear event buffer>
<activate new EventsDescriptor>

Unfortunately, this mechanism suffers from some drawbacks, especially when
compared to the mechanism that was specified in TD-58 after the Red Bank
meeting:

1. Events to be detected in process 1 are always determined by the current
EventsDescriptor. This is an unfortunate restriction which may prevent
detection of events that arrive more rapidly than the round-trip +
processing time. For example, an application may initially wish to detect
seizure, and subsequently detect a wink or unseizure. Unless all events are
requested at the same time (which would effectively prevent glare detection)
detection of all these events could not be guaranteed.

What is needed, is an extra parameter to specify what events to detect (as
opposed to process) during event buffering. Preferably, this set of events
would be determined based on the union of this parameter and the current
EventsDescriptor.

2. Hardcoding Notify in process 2 limits throughput, as there shall normally
only be one outstanding Notify per termination. A queue of Notify to be sent
may consequently build up at the sender side thereby
- Incurring event delivery delay when the event arrival rate exceeds the
MG-MGC roundtrip time.
- Limiting the average event arrival rate to the MG-MGC roundtrip time (best
case).

TD-58 from Red Bank did not have this limitation. First of all, the MGC had
the various “accumulate” actions that were designed to prevent this problem
and limit bandwidth and CPU overhead. Secondly, (assuming MGCP semantics) it
would be possible for the MG to try and empty the EventBuffer in a single
message based on the current EventsDescriptor (arguably, a parameter to
explicitly allow/disallow this behavior would be beneficial).

3. There is a dual use of the Eventbuffer parameter which is unfortunate.
Following a Notify where the Eventbuffer was “on”, there is no way for the
MGC to subsequently request that
a) All the currently buffered events should be processed
b) Future events should not be buffered events but simply sent immediately

A simple solution to this problem would be to separate the parameter into
two, which is precisely what the BufferedEventProcessingMode in TD-58 did.

Finally, from a design perspective, the above solution contains some
fundamentally undesirable properties. Most problematic is the hard-coded
Notify of events which effectively provides a stimulus based approach to
event handling with none or little future support for scripting. It
effectively prevents us from taking advantage of more powerful and
sophisticated MGs that are able to do some amount of local processing
thereby
- reducing bandwidth requirements
- reducing MGC processing requirements (and complexity)
- improves responsiveness as the network round-trip does not become a
bottleneck
Opponents to this point of view may claim, that packages with new events,
signals, and properties can be defined that effectively achieve the above,
as e.g. was done for digitmaps/DTMF detection. While that is indeed the case
(and there are valid use cases for such), the point that needs to be made,
is that the mechanisms are basic and of such high value that they should be
supported natively rather than only by higher level mechanisms which may or
may not be able to interact with each other. Consider for example the
current DTMF detection scheme. As a consequence of the higher layer approach
taken, it is not able to report incoming DTMF digits and other inter-twined
events in the correct order, since the DTMF detection mechanism must itself
be exactly one event (digit map completion). Another example is the
interaction with signal interruption, e.g. dial-tone. Again, special
consideration (define it to take place on the first digit) is needed to
achieve the desired behavior although the event really has not occurred yet.

Such requirements for special treatment and consideration are simply
evidence of lack of generality that should not show up at this stage. The
solution specified in TD-58 from Red Bank did not suffer from these
drawbacks.

Some additional comments below

> to anyone in the design meetings in Washington or Red Bank.

If understanding the MGCP mechanism is the real problem, then I'm sure we
can get the right people to clarify. Having spent a lot of time on this
(admittedly confusing) aspect myself, I can certainly offer my help if
needed. As for a general lack of understanding of the mechanism I think you
are exagerating. There may be small details here and there that people
interpret differently, but I bet you any mechanism you specify will suffer
from this, including yours.

> confusion, found a problem.

If you can be more specific I will do my best to try and explain.

> gimme all of them, and gimme the next one can work; please

Scripting! It comes in many shapes and forms (although not as many and not
as powerful as you might want right now). You have already defined one
yourself; digit maps. What accumulate, etc. gives you is essential the
foundation to build on here. It can even be used natively in some cases,
e.g. for MF trunking if you so desire.

Regards

        Flemming