Subject: [Megaco] Meaning of "support" for signals and events

From: Tom Taylor <[email-masked]>
Date: Wed, 28 Apr 2004 14:37:53 -0400

I'm at an MSF meeting at the moment, and discussion of a proposed Interoperability 
Agreement has added urgency to the question: what does it mean to "support" a 
signal or event in Megaco/H.248?  This relates to the requirement to support all 
signals and events in a supported package.

Would it be a fair statement of consensus to say that a Media Gateway supports an 
event or signal if it does not return an error and fail the rest of the 
transaction when the MGC identifies that event or signal in a descriptor?

I actually see at least one requirement beyond that for signals that are in a 
supported package but not implemented physically for the specified termination. 
Suppose the signal completion event has been enabled for such a signal.  Something 
should be reported, but what and when?

Tom Taylor

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

---

From: Troy Cauble <[email-masked]>
Date: Wed, 28 Apr 2004 15:24:18 -0400

Tom Taylor wrote:

> I'm at an MSF meeting at the moment, and discussion of a proposed 
> Interoperability Agreement has added urgency to the question: what does 
> it mean to "support" a signal or event in Megaco/H.248?  This relates to 
> the requirement to support all signals and events in a supported package.
> 
> Would it be a fair statement of consensus to say that a Media Gateway 
> supports an event or signal if it does not return an error and fail the 
> rest of the transaction when the MGC identifies that event or signal in 
> a descriptor?
> 
> I actually see at least one requirement beyond that for signals that are 
> in a supported package but not implemented physically for the specified 
> termination. Suppose the signal completion event has been enabled for 
> such a signal.  Something should be reported, but what and when?
> 
> Tom Taylor

There a discussion relatively recently that established that supporting 
a package didn't mean you had to support ALL of a packege. (I remember 
being pleasantly surprised and asking for a supporting IG entry.)

Given that, what is the benefit of pretending to support a signal or 
event that you don't really implement?  Wouldn't it be more "honest" to
return the error?

But assuming you have a reason ("Interoperability Agreement"?), it seems 
that a pretend signal completion event would be like any other pretend 
event.  The MG wouldn't choke on the request; but it can't ever send the 
event because it's just pretending.  Yeah, this could cause problems 
with an MGC's expectations, but that's true for any pretend event.

I'm not sure it's possible to generalize the best pretend behavior.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 28 Apr 2004 15:24:18 -0400

-troy

---

From: Christian Groves <[email-masked]>
Date: Thu, 29 Apr 2004 08:57:59 +1000

Hello Tom,

I didn't realise the MSF was on at the moment...

As Troy said we discussed this recently on the list and it was agreed to add 
something to the IG.

Below is the text which I propose to clarify the issue:
6.2.3 Packages
…
To support a particular package the MG must support all properties, signals, 
events and statistics defined in a package. It must also support all Signal and 
Event parameters. If the functionality behind these properties, signals, events 
and statistics is not implemented the MG shall not return a syntax error or 
unknown ID for any of these elements but should return response 501 “Not 
implemented”. The MG may support a subset of the values listed in a package for 
a particular Property or Parameter.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 29 Apr 2004 08:57:59 +1000

Hello Tom,

Regards, Christian

---

From: Tom Taylor <[email-masked]>
Date: Thu, 29 Apr 2004 09:39:14 -0400

Hi.

I assume this 501 error response means that the transaction fails, as usual.

Christian Groves wrote:

> As Troy said we discussed this recently on the list and it was agreed to 
> add something to the IG.
> 
> To support a particular package the MG must support all properties, 
> signals, events and statistics defined in a package. It must also 
> support all Signal and Event parameters. If the functionality behind 
> these properties, signals, events and statistics is not implemented the 
> MG shall not return a syntax error or unknown ID for any of these 
> elements but should return response 501 “Not implemented”. The MG may 
> support a subset of the values listed in a package for a particular 
> Property or Parameter.
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 29 Apr 2004 09:39:14 -0400

Hi.

---

From: Christian Groves <[email-masked]>
Date: Fri, 30 Apr 2004 08:46:26 +1000

Hello Tom,

Yes 501 is subject to the usual error handling procedures.

Regards, Christian

Tom Taylor wrote:
>> As Troy said we discussed this recently on the list and it was agreed 
>> to add something to the IG.
>>
>> these properties, signals, events and statistics is not implemented 
>> the MG shall not return a syntax error or unknown ID for any of these

---

From: Christian Groves <[email-masked]>
Date: Fri, 30 Apr 2004 08:46:26 +1000

Hello Tom,

Regards, Christian