Subject: RE: [Megaco] Embedded Events Behaviour

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 1 Dec 2003 17:03:53 -0500

Well... You caught me!  Indeed, for non-reliable transports then the MG has
to wait for the ACK between Notifies.  I would point out that for most call
processing functions, however, the speed at which things like this have to
be processed would produce the "event holding" scenario rarely, if at all.

Well, unless you're trying to run the control association over the wilds of
the internet or some other lossy, low reliability network. :)

While awaiting transmission of a Notify, the MG would be queuing subsequent
ObservedEvents based upon the current Events descriptor awaiting the next
opportunity to send a Notify.  If EventBuffering is enabled, then the MG
would be buffering Events based on the current EB descriptor to see if the
next Events descriptor would cause any matches and, therefore, Notifies.

Kevin

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]] 
Sent: Monday, December 01, 2003 11:55 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]
Subject: Re: [Megaco] Embedded Events Behaviour

Kevin Boyle wrote:

> Your description is correct -- all events must be reported when 
> detected, regardless of whether the event has signals and/or events 
> embedded on it.  I believe others have described the text where this is
stated.
> 
> I would point out that there are many differences between MGCP and 
> H.248 -- this being one of the smaller differences.  As for why, it is 
> illegal to send a single Notify command with two Events descriptors.  
> This means that the MG would have to build messages with two commands, 
> and so really isn't saving much over sending one message at the time of
each event detection.
> Further, I cannot understand why it is good practice for the MG to 
> hold onto event notifications for any length of time.

Here's one:  Section 9.1 says that (for UDP) there should be at most one
outstanding Notify per Termination.  This is in order to guarantee that the
events reach the MGC in the right order.  This implies waiting for an ACK
before transmitting the next Notify.

What is the MG doing with events during this time?  Are the Notifies queued
for transmission regardless of whatever RequestedEvent descriptors are
received before they are transmitted?

-troy

> If the MGC wants to know an
> event occurred, then why wouldn't the MG send the event right away? 
> The MGC may want to take action based upon the event, even if it had 
> already embedded the next processing step.  By holding onto the 
> notification, the MG is limiting the MGC's abilities.

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 1 Dec 2003 17:03:53 -0500

Kevin

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]] 
Sent: Monday, December 01, 2003 11:55 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]
Subject: Re: [Megaco] Embedded Events Behaviour

stated.
each event detection.

-troy