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

From: "Jon Rowland" <[email-masked]>
Date: Tue, 19 Apr 2005 10:23:42 +0100

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.

________________________________

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

I don't see where anything I have stated conflicts with that final
paragraph.  The last paragraph of 7.1.9 describes the special case of an
empty EB descriptor in Lockstep mode.  I completely disagree with your
assessment.

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 
From: Jon Rowland [mailto:[email-masked]] 
Sent: Monday, April 18, 2005 7:07 AM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Rajkumar Nair; [email-masked] 
Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!! 

Chaps, 

I must disagree, I'm afraid (assuming I've understood what I think
you're saying correctly). 

You're saying that in order for an even to be reported in lockstep mode
then that event must be present in both the evenbuffer descriptor and
the event descriptor because the eventbuffer descriptor filters the
events that are processed by the event descriptor.

[KJBII] Yes.  That is exactly what I am saying. 

This is just wrong. The eventbuffer descriptor lists the events that
will be buffered once the active event descriptor has been matched. When
this happens in lockstep mode, the event descriptor becomes inactive
(and implicitly absent) until a new event descriptor is programmed by
the MGC. Until a new event descriptor is programmed the events in the
eventbuffer descriptor are queued by the MG, any other detected events
are discarded.

[KJBII] Yes... I am failing to see the conflict so far -- other than the
mandate that events only be buffered while there is no active Events
descriptor.  Take the following scenario:  There are a long list of
buffered events in the event buffer awaiting a new events descriptor.
The MGC sends a new events descriptor that matches an item in the event
buffer some way down the list.  While walking through the buffer looking
for the match, more events occur.  Given your description, these events
would not get buffered because there is an active Events descriptor.
The Events descriptor the matches, reports an OE, and then deactivates.
(Note that being inactive is not the same as being absent.  Auditing the
Events descriptor at this time would still report the value of the
descriptor, and it would not be empty.) Per your description, only now
would events start being buffered again.  This cannot work in a
real-world system.  The EB descriptor, therefore, must act as a filter
whenever LockStep is set, otherwise the MG is in very real danger of
losing what would otherwise be valid events.

The list of events in the eventbuffer descriptor is totally independent
of the event descriptor - there need be no overlap. The 'filtering'

described in your email below should not occur. 

[KJBII] This statement has no valid backing in the spec.  The whole
point of buffering events is to collect those that might be of interest
when the next Events descriptor arrives.  By definition, then, they are
not independent -- reporting of events relies on BOTH.  If an event is
never buffered, how can it be reported?  If a buffered event is never
matched to an Events descriptor, how can it be reported.  There is an
inherent relation between the two descriptors when in LockStep.

It is totally valid to have an event descriptor in lockstep mode with no
eventbuffer descriptor programmed - this simply means that only one
event will be matched and then all subsequent events will be discarded
until the MGC programs a new event descriptor.

See in particular the last paragraph of 7.1.9/H.248.1(01/2004) for
confirmation of this. 

[KJBII] Yes, in the special case where there is no EB descriptor, there
is certain behavior described for that case alone.  I do not see a
conflict with anything else stated.

Hope this helps! 

Cheers, 
Jon. 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kevin Boyle 
Sent: 15 April 2005 21:57 
To: Rajkumar Nair; [email-masked] 
Subject: RE: [Megaco] EventBufferDescriptor and EventDescriptor!! 

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rajkumar Nair 
Sent: Friday, April 15, 2005 2:41 PM 
To: [email-masked] 
Subject: Re: [Megaco] EventBufferDescriptor and EventDescriptor!! 

Kevin, 
  Thanks for the clarification.  Please see my comment/query inline. 

> 
> The EventBuffer descriptor never indicates what is to be reported -- 
> only what is to be collected into the event buffer.  The Events 
> descriptor is the only descriptor that indicates what will be reported

> to the MGC via the ObservedEvents descriptor. 
> 
> In normal circumstances, the Events descriptor remains in effect until

> it is replaced and operates against whatever events occur.  Lockstep 
> changes that behavior -- the Events descriptor will be compared 
> against the list of items in the event buffer, and when a match 
> occurs, the event is reported and the Events descriptor is disabled. 
> Event reporting then halts until a new Events descriptor is provided, 
> either via embedding or being sent from the MGC. 
> 
> Essentially, there are several different operations here that 
> interwork with each other: 
> 
> 1. Lockstep indicates that the Events descriptor operates only on 
> events collected in the event buffer, and that it only reports a 
> single event to the MGC. 
> 2. The EB descriptor indicates what events to append to the event 
buffer. 
> It does *not* indicate what events to report to the MGC. 
> 3. The Events descriptor indicates which events out of the event 
> buffer are to be reported to the MGC, when in Lockstep. 
> 
> LockStep takes effect the instant it is set.  At that time, the Events

> descriptor must compare against the event buffer. 
> For instance, say I have 
> placed al/fl in the EB descriptor, and al/on in the Events descriptor.

> I then set BF to SP.  I then go onhook.  The event will *not* be 
> reported to the MGC, because the al/on event will not be added to the 
event buffer. 
> This is because the EB descriptor filtered it.  Similarly, flashing 
> the set will also not be reported.  Although it appears in the EB 
> descriptor and is added in the event buffer, it does not match the 
> Events descriptor, and is therefore discarded. 
> 

[RAJ] - Does it mean that the event al/fl gets added to the event buffer
since it matches EB descriptor, but immediately gets removed from the
buffer as it does not match the Events Descriptor?

[KJBII] Yes. 

[RAJ] -  Let me summarize what I understood with an example. Please
correct me if I am wrong: 
     1. Currently active Events Descriptor (ED) has requested events A
and B . 
     2. BF is set to SP along with a EventBuffer Descriptor (EBD) having
events B and C. 
     3. From that moment, any observed event gets filtered by EBD, and
gets added to the event buffer. ED still remains active, but it looks at
events that get added to the event buffer.

    4.Observed event A will get filtered out and discarded by EBD. 
    5. Observed event C will be added to the event buffer since it
matches EBD , but it will immediately be removed from the buffer since
it doesn't match ED.

   6. Observed event B will be added to the buffer as it matches EBD,
and since it matches ED also, it will get notified to MGC ( and removed
from the buffer !!).

   7. At this point, the ED is deactivated. Until a new ED is received,
all observed events of type B and C will get added to the event buffer,
since they match EBD.

[KJBII] Exactly correct. 

> Kevin 

Thanks, 
Raj. 

-- 
"The trouble with the rat race is that even if you win you're still a
rat ! 
" - Lily Tomlin 

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

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

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

---

From: Rajkumar Nair <[email-masked]>
Date: Tue, 19 Apr 2005 17:52:47 +0530

Hi,
As understand, the only unresolved issue is regarding - when does the
EventBuffer Descriptor get activated:
       - the moment Buffer Control is set to LockStep,  or
       - following the first event detection after  the Buffer Control is set ? 

It will be interesting to know how the existing implementations behave.
Also, what are the practical scenarios where we need to have Event
Buffering rather than immediate notification of events?

Regards,
Raj.

On 4/19/05, Jon Rowland <[email-masked]> wrote:
> 
> 
> 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 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.
> 
>  
> 
> 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.
> 
>  
> 
>  
> I must disagree, I'm afraid (assuming I've understood what I think you're
> saying correctly). 
> 
> You're saying that in order for an even to be reported in lockstep mode then
> that event must be present in both the evenbuffer descriptor and the event
> descriptor because the eventbuffer descriptor filters the events that are
> processed by the event descriptor.
> 
> This is just wrong. The eventbuffer descriptor lists the events that will be
> buffered once the active event descriptor has been matched. When this
> happens in lockstep mode, the event descriptor becomes inactive (and
> implicitly absent) until a new event descriptor is programmed by the MGC.
> Until a new event descriptor is programmed the events in the eventbuffer
> descriptor are queued by the MG, any other detected events are discarded.
> 
> descriptor.  Take the following scenario:  There are a long list of buffered
> events in the event buffer awaiting a new events descriptor.  The MGC sends
> a new events descriptor that matches an item in the event buffer some way
> down the list.  While walking through the buffer looking for the match, more
> events occur.  Given your description, these events would not get buffered
> because there is an active Events descriptor.  The Events descriptor the
> matches, reports an OE, and then deactivates. (Note that being inactive is
> not the same as being absent.  Auditing the Events descriptor at this time
> would still report the value of the descriptor, and it would not be empty.)
> Per your description, only now would events start being buffered again. 
> This cannot work in a real-world system.  The EB descriptor, therefore, must
> act as a filter whenever LockStep is set, otherwise the MG is in very real
> danger of losing what would otherwise be valid events.
> 
> The list of events in the eventbuffer descriptor is totally independent of
> the event descriptor - there need be no overlap. The 'filtering'
> 
> [KJBII] This statement has no valid backing in the spec.  The whole point of
> buffering events is to collect those that might be of interest when the next
> Events descriptor arrives.  By definition, then, they are not independent --
> reporting of events relies on BOTH.  If an event is never buffered, how can
> it be reported?  If a buffered event is never matched to an Events
> descriptor, how can it be reported.  There is an inherent relation between
> the two descriptors when in LockStep.
> 
> eventbuffer descriptor programmed - this simply means that only one event
> will be matched and then all subsequent events will be discarded until the
> MGC programs a new event descriptor.
> 
> [KJBII] Yes, in the special case where there is no EB descriptor, there is
> certain behavior described for that case alone.  I do not see a conflict
> with anything else stated.
> 
> Hope this helps! 
> 
> Cheers, 
> Jon. 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kevin Boyle 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rajkumar Nair 
> since it matches EB descriptor, but immediately gets removed from the buffer
> as it does not match the Events Descriptor?
> 
> [KJBII] Yes. 
> 
> [RAJ] -  Let me summarize what I understood with an example. Please correct
> me if I am wrong: 
>      1. Currently active Events Descriptor (ED) has requested events A and B
> . 
>      3. From that moment, any observed event gets filtered by EBD, and gets
> added to the event buffer. ED still remains active, but it looks at events
> that get added to the event buffer.
> 
>     5. Observed event C will be added to the event buffer since it matches
> EBD , but it will immediately be removed from the buffer since it doesn't
> match ED.
> 
>    6. Observed event B will be added to the buffer as it matches EBD, and
> since it matches ED also, it will get notified to MGC ( and removed from the
> buffer !!).
> 
>    7. At this point, the ED is deactivated. Until a new ED is received, all
> observed events of type B and C will get added to the event buffer, since
> they match EBD.
> 
> [KJBII] Exactly correct. 
> 
>  
> 
> > Kevin 
> > 
> 
> Thanks, 
> Raj. 
> 
> -- 
> "The trouble with the rat race is that even if you win you're still a rat ! 
> " - Lily Tomlin 
> 

rat ! " - Lily Tomlin