Subject: [Megaco] Re: Megaco Digest, Vol 12, Issue 13

From: Rajkumar Nair <[email-masked]>
Date: Fri, 15 Apr 2005 10:08:46 +0530

Kevin,
    We have found different conflicting interpretations about Event
Buffering in this mailing list itself.
Here is a quote from the H.248 Section 7.1.9:
" Unless the Events Descriptor is replaced by another 
      Events Descriptor, it remains active after an event has been 
      recognized. 

      If the value of the EventBufferControl property equals LockStep, 
      following detection of such an event, normal handling of events is 
      suspended. Any event which is subsequently detected and occurs in the 
      EventBuffer descriptor is added to the end of the EventBuffer (a FIFO 
      queue), along with the time that it was detected. The MG SHALL wait 
      for a new EventsDescriptor to be loaded."

Can this be interpreted as following:
  - Even if EventBufferControl property is LockStep, and there is a
valid EventBuffer Descriptor, the first observed event will be matched
against the Events Descriptor and NOT against the EventBuffer
Descriptor.
 - Following the recognition of this event ( ie. this event is present
in Events Descriptor), Events Descriptor is no longer active. Any
further observed events will be matched against the EventBuffer
Descriptor and NOT against the Events Descriptor.
- When the new Events Descriptor is loaded, the buffered events will
be matched against this new Events Descriptor.

Regards,
Raj.

> 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
> 
> End of Megaco Digest, Vol 12, Issue 13
> **************************************
> 

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 15 Apr 2005 11:37:17 -0400

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.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rajkumar Nair
Sent: Friday, April 15, 2005 12:39 AM
To: [email-masked]
Subject: [Megaco] Re: Megaco Digest, Vol 12, Issue 13

Kevin,

Can this be interpreted as following:
  - Even if EventBufferControl property is LockStep, and there is a valid
EventBuffer Descriptor, the first observed event will be matched against the
Events Descriptor and NOT against the EventBuffer Descriptor.
 - Following the recognition of this event ( ie. this event is present in
Events Descriptor), Events Descriptor is no longer active. Any further
observed events will be matched against the EventBuffer Descriptor and NOT
against the Events Descriptor.
- When the new Events Descriptor is loaded, the buffered events will be
matched against this new Events Descriptor.

Regards,
Raj.

> *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
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> 1) The EventBufferControl property in the TerminationState Descriptor 
> equals LockStep
> 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.
> 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
> 
> IMPORTANT: HUGHES SOFTWARE SYSTEMS LTD. (HSS) IS NOW FLEXTRONICS 
> SOFTWARE SYSTEMS LTD. (FSS)
> 
> 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."
> 

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