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

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 14 Apr 2005 11:09:51 -0400

This is not correct.  If the BF property is set to SP and there are no
events in the EventBuffer descriptor, then any events that are detected are
*discarded* -- in this case processing of events does NOT depend upon the
Events descriptor.  When in LockStep, the processing of events is always
dependent upon the value of the EventBuffer descriptor.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, April 14, 2005 5:14 AM
To: Mudit Gupta
Cc: [email-masked]
Subject: Re: [Megaco] EventBufferDescriptor and EventDescriptor!!

Hi

      The buffering of the events depends on two things:

1) The EventBufferControl property in the TerminationState Descriptor equals
LockStep
2) There is a valid EventBuffer descriptor which contains the events
detected by MG.

If any one of the above is not present then there will be no event buffering
and the event processing depends on the active Event descriptor and events
are reported to MGC unless it is absorbed in the the current dial string of
an active digit map.
For reference check protocol section: H248.1V2(section 7.19 para 5).

regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone:  +91-124-2455555 Extn 3620
Fax: +91-124-2455345
web: www.hssworld.com

"Mudit Gupta" <[email-masked]>@ietf.org on 04/14/2005 09:26:26 AM

Sent by:    [email-masked]

To:    <[email-masked]>
cc:

Subject:    [Megaco] EventBufferDescriptor and EventDescriptor!!

Hi

I have a query, please help me in that. The query is as follows:

I have an active EventBufferDescriptor and eventDescriptor containg the same
event. Now, an event

is recognized by the MG. The question is whether this event is notified to
MGC immediately or

simply buffered till the new eventDescriptor is loaded at MGC.

Regards

Mudit

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

IMPORTANT: HUGHES SOFTWARE SYSTEMS LTD. (HSS) IS NOW FLEXTRONICS SOFTWARE
SYSTEMS LTD. (FSS)

*****************    FSS-Restricted    *************

"DISCLAIMER: This message is proprietary to Flextronics Software

Systems Limited (FSS) and is intended solely for the use of the 

individual to whom it is addressed. It may contain  privileged or

confidential information and should not be circulated or used for

any purpose other than for what it is intended. If you have received

this message in  error, please notify the originator immediately.

If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing the
contents of this message.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted by this email
including damage from virus."

_______________________________________________
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: Sat, 16 Apr 2005 00:11:19 +0530

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?

[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.

> Kevin

Thanks,
Raj.

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 15 Apr 2005 16:57:29 -0400

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,

> 
> 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.
> 3. The Events descriptor indicates which events out of the event 
> buffer are to be reported to the MGC, when in Lockstep.
> 
> 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.

Thanks,
Raj.

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

---

From: "Jon Rowland" <[email-masked]>
Date: Mon, 18 Apr 2005 12:06:42 +0100

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.

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.

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.

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.

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,

event buffer.

[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.

Thanks,
Raj.

rat !
" - Lily Tomlin

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 18 Apr 2005 14:30:58 -0400

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.

[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-----
Kevin Boyle

Comments inline. [KJBII]

Kevin 

-----Original Message-----

Kevin,

event buffer.

[KJBII] Yes.

[KJBII] Exactly correct.

Thanks,
Raj.

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 21 Apr 2005 10:43:38 -0400

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.

  _____  

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!!

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 
From: Jon Rowland [mailto:[email-masked]
<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, 

Hope this helps! 

Cheers, 
Jon. 

-----Original Message----- 
From: [email-masked] [mailto:[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]
<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, 

event buffer. 

[KJBII] Yes. 

[KJBII] Exactly correct. 

Thanks, 
Raj. 

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

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

---

From: "Jon Rowland" <[email-masked]>
Date: Thu, 21 Apr 2005 17:43:48 +0100

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 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.