Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!!

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 15 Jun 2005 16:37:42 -0400

While editing the doc and thinking some more about this discussion, I have
found that I must concede.  I believe you are correct, and that the
buffering does not occur until the current Events Descriptor has matched.
The text in particular that got my attention is:
 
"The EventBufferControl Property specifies whether events are buffered
following detection of an event in the Events Descriptor, or processed
immediately. See 7.1.9 for details."

This text is in section 7.1.5, "TerminationState Descriptor".  So the intent
is there that the enforcement of buffering not occur until the currently
active Events Descriptor matches.  You are right, and I was wrong.
 
I will see if I can get some better wording put around this to make it clear
that the buffering only comes into effect while there is not an active
Events Descriptor.
 
Kevin

  _____  

From: Jon Rowland [mailto:[email-masked]] 
Sent: Thursday, April 21, 2005 12:44 PM
To: Jon Rowland; Boyle, Kevin [NCRTP:3Z40:EXCH]; Rajkumar Nair;
[email-masked]
Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!!

Kevin,

I'm not proposing there should be exceptions in particular cases. I'm trying
to define how the interaction of the event descriptor and the event buffer
descriptor works in general. I can see nothing in the spec that backs up
your assertion that the event buffer filters events while there is an active
event descriptor.

Indeed, I can see statements suggesting the opposite:

-          Paragraph 5 of 7.1.9 says "... following detection of such an
event [as per the mechanism in the previous paragraph] normal handling of
events is suspended. [i.e. prior to this, when there is an active events
descriptor, handling of events _is_ normal] Any event which is
_subsequently_ detected and occurs in the eventbuffer descriptor is added to
the end of the eventbuffer FIFO queue..."

-          Same section, case 1, 1) says "If the eventbuffer is empty [no
events detected and put on FIFO queue], the MG waits for detection of events
based on the new events descriptor..."

This is all self-consistent. The eventbuffer buffers events while there is
no active event descriptor. When a new event descriptor is applied, if there
are buffered events, then they instantaneously match the events descriptor
and the event descriptor is instantly disabled. There is logically no period
when there is an active events descriptor when new events can be detected,
so the issue of whether they should match the event descriptor is
irrelevant. In this case, until the FIFO is empty, all events that match the
event buffer will be buffered, because there is never an active events
descriptor when a new event is detected. When the FIFO is empty, then there
can be a persistent active event descriptor, and so newly detected events
will be matched directly against that - the event buffer does not come into
play in this case.

The spec is quite clear that the event buffer only comes into play once
normal event detection has been suspended. My assertion and example below
therefore stands, and is not a special case - note that this is not
necessarily the point where event detection enters lockstep mode - in my
first bullet point in the example below, there could already have been an
active events descriptor in lockstep mode. This is in line with all the
H.248 implementations I have experienced.

The fact that we are arguing this suggests the spec is poorly worded here,
so some clarifications in the next version might be a good idea! :-)

Jon.

  _____  

From: Kevin Boyle [mailto:[email-masked]] 
Sent: 21 April 2005 15:44
To: Jon Rowland; Rajkumar Nair; [email-masked]
Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!!

The text states how the Events descriptor functions when the value of the BF
property is SP or OFF.  I do not see anything that would support the
assertion that the application of the EB descriptor is delayed due to the
presence of an active Events descriptor at the time BF is set to SP.  The
paragraph that seems to be the main point of contention is describing
behavior at all times when BF is SP, not just when it is first set.   It is
also a natural follow-on from the previous paragraph talking about the
methodology by which events are matched by the Events descriptor.

If the MGC wishes to be predictive of the events it wishes to match in the
next Events descriptor, it certainly can do that -- via embedding.  The EB
descriptor is meant to filter the event input to the recognition/reporting
process controlled by the Events descriptor.  I stand by the position that
the EB descriptor takes effect immediately upon the transition of BF from
OFF to SP.  I do not believe there is, or should be, an exception in the
particular case you describe.

Kevin

  _____  

From: Jon Rowland [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2005 5:24 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Rajkumar Nair; [email-masked]
Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!!

Kevin,

I think we may actually be in sync in most of the below. I agree, that when
you activate a new event descriptor, in order to report events that have
been detected in the meantime, those events must also be present in the
eventbuffer descriptor. That's fine.

The key scenario that I think is in confusion is as follows:

-          No events have been detected or buffered.

-          A new event descriptor is programmed by the MGC.

-          An event matching that event descriptor is detected.

-          The event is reported to the MGC

-          The event descriptor is disabled because we're in lockstep mode.

-          Subsequent events are matched against the eventbuffer descriptor.

-          When the MGC programs a new event descriptor, any buffered event
that also matches the new event descriptor is reported to the MGC.

-          Repeat.

The key thing here is the start of the sequence. If there have been no
events detected and buffered before the active event descriptor is
programmed, then the value of the eventbuffer descriptor is irrelevant. An
event is detected and there is an active event descriptor that matches it,
so it is reported. The eventbuffer descriptor only comes into play for
events detected while the MG is waiting for a new active event descriptor.

Agree? It has to be this way. There are situations where you simply don't
want the eventbuffer descriptor to match the same set of events as the
active event descriptor - instead it's predicting the set of events you
might want to detect in the _next_ active event descriptor.

Cheers,

Jon.

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco