Subject: [Megaco] Embedded Events Behaviour

From: "Wayne Cutler" <[email-masked]>
Date: Tue, 25 Nov 2003 11:06:25 +0000

I would like to seek clarification as to when an "off-hook" event is
reported when requested with a related Embedded Descriptor, e.g.
something like the following (from the Call Flows document) :-

      Events = 1111 {al/of , Embed { signals {cg/dl}, Events=1112 { al/on},
{dd/ce {Dmap1}}}

The Megaco Call Flows document shows the off-hook being reported to the MGC
on detection followed by a subsequent notification to the MGC
when the received/dialled digits match the digit map in the embedded
request. Can it be confirmed that this is the correct behaviour? If so,
where in the
RFC is this behaviour explicitly described ?

If this behaviour is correct, then it is noted that there is a difference
between MGCP and MEGACO. MGCP would, when using an  embedded request,  have
sent a single notification to the MGC containing botht the "off-hook" and
dialled digits. Is there any historical reason for this difference
between MGCP & MEGACO ?

Reagards,
Wayne.

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 28 Nov 2003 10:58:00 -0500

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

Kevin

-----Original Message-----
From: Wayne Cutler [mailto:[email-masked]] 
Sent: Tuesday, November 25, 2003 6:06 AM
To: [email-masked]
Subject: [Megaco] Embedded Events Behaviour

The Megaco Call Flows document shows the off-hook being reported to the MGC
on detection followed by a subsequent notification to the MGC when the
received/dialled digits match the digit map in the embedded request. Can it
be confirmed that this is the correct behaviour? If so, where in the RFC is
this behaviour explicitly described ?

If this behaviour is correct, then it is noted that there is a difference
between MGCP and MEGACO. MGCP would, when using an  embedded request,  have
sent a single notification to the MGC containing botht the "off-hook" and
dialled digits. Is there any historical reason for this difference between
MGCP & MEGACO ?

Reagards,
Wayne.

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 28 Nov 2003 10:58:00 -0500

Kevin

-----Original Message-----
From: Wayne Cutler [mailto:[email-masked]] 
Sent: Tuesday, November 25, 2003 6:06 AM
To: [email-masked]
Subject: [Megaco] Embedded Events Behaviour

Reagards,
Wayne.

---

From: "Wayne Cutler" <[email-masked]>
Date: Fri, 28 Nov 2003 16:09:00 +0000

Thanks for the info.

I agree that it is better practice for the MG not to hold onto
notifications for any length of time. I was just trying to get to the
bottom of why there was such a
difference between MGCP & H248.

Regards,
Wayne