Subject: [Megaco] Support of a H.248 package

From: "Jan Lindquist (AL/EAB)" <[email-masked]>
Date: Fri, 19 Mar 2004 09:04:25 +0100

Hello Megaco fans,

I need clarification on the statement in section 6.2.3 in the H.248 version 2 standard, more specifically on the 4th paragraph.

"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. The MG may support a subset of the values listed in a package for a particular Property or Parameter."

Our interpretation is that as long as the MG recognises the property, signal or event (ie. doesn't response with a syntax error, 451, 452, 453, 454 etc) then a property, signal or event is supported. If the functionality behind the property, signal or event is not implemented then error code 501 is returned.  However some have mentioned that this may not be correct? Can anyone clarify the behaviour?

Best regards,
Jan Lindquist

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: "CHATRAS Bruno FTRD/DAC/ISS" <[email-masked]>
Date: Tue, 23 Mar 2004 09:19:33 +0100

Hello Christian,

I think it would be useful to include such an explanation in the IG and/or H.248 V3 as I believe that the "must support" statement has already been misunderstood in a number of occasions. For example, ITU-T Rec J.171 Annex B defines an ISUP Trunk Tones Generator package that contains only two tones (Ringback tone and a Congestion Tone), both of which are already defined - with different signal Ids - in H.248 Annex E (Call Progress Tone Generator Package).

Regards,
Bruno

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Groves
Envoyé : lundi 22 mars 2004 23:58
À : Jan Lindquist (AL/EAB)
Cc : [email-masked]'
Objet : Re: [Megaco] Support of a H.248 package

Hello Jan,

"Must Support" is a little different from "it is mandatory to implement all the 
functionality in the package." So I believe we put these words in so that the MG 
had to support the reception of properties, signal, events and statistics. By 
this I mean that it must not return a syntax error or unknown ID for any of 
these elements. However the MG could give a meaningful response such as 501 not 
implemented. This shows that the MG has at least considered the complete 
package. Of course it is encouraged to support the complete functionality of a 
package however it is better to return 501 and using an existing package rather 
than creating new packages with the functionality contained in existing 
packages. We have tried to prevent duplicate packages in Megaco. So you are 
correct in supporting 501.

Regards, Christian

Jan Lindquist (AL/EAB) wrote:

> Hello Megaco fans,
> 
> I need clarification on the statement in section 6.2.3 in the H.248 
> version 2 standard, more specifically on the 4th paragraph.
> 
> "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. The MG may support a subset 
> of the values listed in a package for a particular Property or 
> Parameter."
> 
> Our interpretation is that as long as the MG recognises the property, 
> signal or event (ie. doesn't response with a syntax error, 451, 452, 
> 453, 454 etc) then a property, signal or event is supported. If the 
> functionality behind the property, signal or event is not implemented 
> then error code 501 is returned.  However some have mentioned that 
> this may not be correct? Can anyone clarify the behaviour?
> 
> Best regards,
> Jan Lindquist
> 
> 
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we 
> only send and receive e-mails on the basis that we are not liable for 
> any such corruption, interception, amendment, tampering or viruses or 
> any consequences thereof.
> 
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Mar 2004 14:39:43 -0500

All,

I also believe that sending 501 is OK.  However, this does not open the door
for MG implementors to be lazy.  I know that I have had some real problems
with MGs implementing portions of packages that they find convenient and
skipping the rest.  That selective behavior is just as damaging to
interoperability as the tendency to pick existing, well-known packages apart
and reconstruct them into new packages.

For example, I had one MG in our interop parade some years ago claim it
supported the dd package, but when I asked it to look for the dd/d1 event,
it choked.  It was expecting dd/* (which, of course, is illegal without a
Digitmap due to the dd/ce event).  So, in reality, the MG didn't really
support the dd package (it turned out that the only events it would accept
by itself were dd/ce and dd/* -- all the other events would be rejected if
explicitly requested).  By having them send back 501, this problem isn't
solved -- now it's acceptable.  This is behavior that must be restricted.
MGs need to implement the functions they support in the "right" way and not
take the lazy way out.  In this particular case, the MG clearly needed to
implement the various digit events, but chose not to in order to save
development time/cost/whatever.

That aside, I believe that the creation of "specialty packages" by everyone
who fancies themselves some kind of H.248 expert will be a devastating blow
to the interoperability capabilities of H.248.  Making region-specific
packages the replicate the capabilities of other packages is an especially
bad practice.  We have to do something to keep it under control.
Ultimately, though, we can't stop anyone from making a new package -- the
best we can do is prevent it from becoming "standard".  However, by allowing
MG implementors to legitimately skip pieces that clearly do not apply, we
reduce the number of packages that will appear.

So, we need to make some value statements around what acceptable and
unacceptable package "support" is in relation to function.  Generally
speaking, packages designed more recently are fairly well-segmented in their
functions.  An MG that is implementing particular functions would want to
implement the entire package.  It is the older packages that pose the
biggest problem, with one of the most egregious offenders being the ctyp
package in H.248.2.  It may be that the best way to solve some of these
problems is to rewrite the worst packages and retire their predecessors.

Either way, I agree that there needs to be text in V3 and the IGs regarding
this to define what support means and what is acceptable and not acceptable
with regards to implementation of packages.

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, March 22, 2004 5:58 PM
To: Jan Lindquist (AL/EAB)
Cc: [email-masked]'
Subject: Re: [Megaco] Support of a H.248 package

Hello Jan,

"Must Support" is a little different from "it is mandatory to implement all
the functionality in the package." So I believe we put these words in so
that the MG had to support the reception of properties, signal, events and
statistics. By this I mean that it must not return a syntax error or unknown
ID for any of these elements. However the MG could give a meaningful
response such as 501 not implemented. This shows that the MG has at least
considered the complete package. Of course it is encouraged to support the
complete functionality of a package however it is better to return 501 and
using an existing package rather than creating new packages with the
functionality contained in existing packages. We have tried to prevent
duplicate packages in Megaco. So you are correct in supporting 501.

Regards, Christian

> "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. The MG may support a subset of the values
listed in a package for a particular Property or Parameter."
> Our interpretation is that as long as the MG recognises the property,
signal or event (ie. doesn't response with a syntax error, 451, 452, 453,
454 etc) then a property, signal or event is supported. If the functionality
behind the property, signal or event is not implemented then error code 501
is returned.  However some have mentioned that this may not be correct? Can
anyone clarify the behaviour?
> This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you.
> E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If
you believe this message has been sent to you in error, please notify the
sender by replying to this transmission and delete the message without
disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Mar 2004 14:39:43 -0500

All,

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Monday, March 22, 2004 5:58 PM
To: Jan Lindquist (AL/EAB)
Cc: [email-masked]'
Subject: Re: [Megaco] Support of a H.248 package

Hello Jan,

Regards, Christian