Subject: Re: Washington Issue 4 - Events

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Nov 1999 10:06:47 -0500

The problem with the simple solution (no buffering) is that
the EventsDescriptor contains events that are of interest
at the moment.  When one of those events happens, the events
that may be interesting could (often would) change.  The problem
is that the MG doesn't know what the MGC wants it to look for
next.

Embedded events could help, but they are only one level.  That
significantly limits what can be done with them.

The MGCP experience is that the quarantine buffer is required.
The (revised) proposal allows you to use it, or not, as the
MGC deems fit.

Keep Alive as an embedded signals descriptor has the same problem
of one level.  

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 8:57 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Washington Issue 4 - Events
> 
> 
> Hi Brian,
> 
> Interesting to see the same problems repeating :-).  Anyway, 
> I wasn´t at the meeting and I was interested in what the 
> problems with the proposal were that you indicated in your 
> note below.  I am rather keen on something simple, but 
> something that works.
> 
> In addition, would it be cleaner to consider the "keep alive" 
> as something which is achieved using the embeded descriptor instead??
> 
> Thanks,
> 
> ..//Steve
> 
> Brian Rosen wrote:
> 
> > A number of issues were raised in the Washington meeting 
> that were "send to
> > the
> > list".  This is one of these issues, with the problem and 
> my suggested fix.
> >
> > Problem
> > Events have issues associated with the "Event Buffer", and 
> how it interacts
> > with the DigitMap mechanism.  The basic issue is when 
> events get into the
> > buffer,
> > and exactly how do they get out.
> >
> > Note: A proposal was presented in the meeting the totally 
> eliminated the
> > event buffer except for the digitmap mechanism that was 
> moved to a package.
> > Several WG members in the Friday session pointed out 
> problems with this
> > proposal.
> >
> > Proposed Solution:
> > a) KeepActive is a parameter(boolean) to every event.  If 
> set, this event
> > will
> > not cause signals to stop.
> > b) TerminationState has a boolean property: Quarantine.
> > If Quarantine is off:
> >         Any events in the Quarantine Buffer are discarded.
> >         All events in the event descriptor are Notified to 
> the MGC when they
> >                 are detected.  Events not in the 
> EventsDescriptor are
> > discarded.
> >
> > If Quarantine is on:
> >         When an event in the EventsDescriptor is detected, and the
> > Quarantine
> >                 Buffer is empty, it is Notified to the MGC. 
>  All subsequent
> > events
> >                 (whether they are in the event descriptor 
> or not), are
> > buffered in
> >                 the Quarantine Buffer.
> >         A Modify command (which might contain a new 
> EventsDescriptor) starts
> > a
> >                 process which looks through the Quarantine 
> Buffer in FIFO
> > order:
> >                         Events not in the EventsDescriptor 
> are discarded
> >                         The first event in the 
> eventsDescriptor is Notified,
> >                                 and the process stops.
> > C) A flag in EventsDescriptor (Discard) clears the 
> Quarantine Buffer.
> >
> > D) The "Action" indicator is not needed anymore.
> >
> > Please Note:
> > The "no quarantine" mode is the simplest mechanism - the 
> MGC gets all the
> > events it asks for until it changes EventsDescriptor.  In 
> Quarantine mode,
> > the assumption is that the MG doesn't know what events the 
> MGC might want
> > between the time one event is detected, and it responds.  
> So, it keeps
> > all events, sends the first one it finds that is in the 
> current ED (in the
> > buffer if there is one there), and then waits to see what 
> the MGC asks for
> > next.
> > The only events it discards are the ones not in the ED 
> before it finds one
> > that is in the ED.
> >
> > E) DigitMap can either stay pretty much as is, with a 
> simple change in
> > Events Descriptor syntax - there is a DigitMap event, that 
> has a parameter
> > "Map" which enables the DigitMap.  This event is notified, 
> with a string
> > result
> > which is the digits matched.
> >
> > Another possibility is to define a more generalized 
> DigitMap mechanism.
> > In the base protocol, we define the DigitMapDescriptor, 
> which is renamed
> > "PatternMap", and generally has the same syntax.  A package 
> defines specific
> > use for the base mechanism by defining:
> >         On ordered list of events that are detected (DTMF digits)
> >         A one character symbol for each that will occur in 
> the pattern map
> >         An event which is enabled by specifying the name of 
> an existing
> >                 pattern map, or a pattern map value, as a parameter.
> > Events in the list of events that are detected are 
> processed through the
> > pattern map mechanism.  The event returns a string which is 
> the pattern that
> > was matched.  If any other event is detected, the pattern 
> is returned with
> > a "|" suffix indicating that an event terminated pattern matching.
> >
> > The intention is that, except for the name change, and a 
> required package,
> > digitmap works just as defined now, with the same syntax in the
> > DigitMapDescriptor, but with the different syntax in the 
> EventsDescriptor
> > (something like Events{DTMFMap{Map=NANP}}
> >
> > Brian
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Nov 1999 13:59:21 -0500

> Hello Brian,
> 1. Why is the process of scanning the Quar. Bfr linked with
> Modify command ? The
> process can also be started when the command is Move or Add.
> Shouldn't the
> process get started whenever a new EventsDesciptor (it might
> be the same as the
> previous one) is sent, irrespective of the command ?
Yes, it should also be an Add or Move as well as Modify.  You should
not have to load a new EventsDescriptor if you don't need to.

> 2. If no new EventsDesciptor is present in the Modify
> command, then is the
> previous Events Descriptor used ?
Yes

> > events it asks for until it changes EventsDescriptor.
>
> Does this mean that in "no quarantine" mode the
> EventsDescriptor remains active
> (in the sense that MG still looks for the events specified in
> EventsDescriptor)
> even after an event has got detected and notified ?
Yes

> And in
> "Quaratine" mode, the
> EventsDescriptor is valid for first event and after that all
> events are
> detected.
No, the point of the Quarantine mode is that the EventsDescriptor is not
necessarily valid following the detection of the event so the mechanism
allows the MGC to change it before subsequent events are processed.

> The concept of PatternMap is not clear. Can you please
> explain it with the help
> of an example of a package ?
Think of digit map applied to situations other than detecting DTMF.
An easy example is keys from a keypad, but any sequence of detectable
events where the MGC is not needed to alter state between the events
in the sequence would be usable with this mechanism.

I'm at another meeting this week, so a worked out example will have to wait.

Brian