Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Francois,
The UUIE _is_ a Q.931 IE, 5.8.6.2/Q.931 does not exclude this IE, and neither H.225.0 or H.323 address the issue of how to handle a UUIE--or any other IE, for that matter--with invalid content, therefore the behavior defined in Q.931 is normative for H.323.
An "invalid coding" for an information element does NOT include the content of a User-User information element. By definition, a Q.931 User-user IE can include whatever you feel like. A proper implementation will not reject a call because of the content of the User-user IE.
_All_ of Q.931 is an "ISDN thing," so what's your point?
Finally, there is much in Q.931 that H.323 does not reference, but that does not invalidate the parts of Q.931 that H.323 references.
H.323 does not use Q.931. H.225.0 recycled some of the messages (but not all of them). More importantly, it doesn't explicitly use the PROCEDURES of Q.931. There are some stringent timer requirements for example in Q.931 that not used use by H.323. The DISCONNECT and RELEASE messages are not even used. We are not even setting up a bearer channel in H.323 when doing a call setup.
In summary, H.225.0 is NOT Q.931.
Francois,
Time to wade in...
Whatever the advantages may be, given that a Setup message containing both fastStart and Tunnelling is expressly forbidden up to and including at least v3, it is extremely unsafe to second-guess what those implementations may do. They may work in the way you desire. They may immediately send RELEASE COMPLETE. They may crash irrecoverably. They may act non-deterministically. Maybe it would be a poor implementation to react badly: maybe it wouldn't. The fact of reacting badly would not stop it being a COMPLIANT implementation. There are major implementations from people who do not watch this list, so it isn't even safe to assume that anyone whose implementation will break will see these emails.
Enough problems come about with endpoints which are non-compliant or at the edge of compliance: please let's not make things worse by introducing something where this sort of problem has been forseen!
In summary, allowing something expressly forbidden in earlier versions of the standard breaks the principle of backward compatibility and would mean a new recommendation (ie it would no longer be H.225.0).
Regards, Chris
Francois Audet wrote:
Francois,
The UUIE _is_ a Q.931 IE, 5.8.6.2/Q.931 does not exclude this IE, and neither H.225.0 or H.323 address the issue of how to handle a UUIE--or any other IE, for that matter--with invalid content, therefore the behavior defined in Q.931 is normative for H.323.
An "invalid coding" for an information element does NOT include the content of a User-User information element. By definition, a Q.931 User-user IE can include whatever you feel like. A proper implementation will not reject a call because of the content of the User-user IE.
_All_ of Q.931 is an "ISDN thing," so what's your point?
Finally, there is much in Q.931 that H.323 does not reference, but that does not invalidate the parts of Q.931 that H.323 references.
H.323 does not use Q.931. H.225.0 recycled some of the messages (but not all of them). More importantly, it doesn't explicitly use the PROCEDURES of Q.931. There are some stringent timer requirements for example in Q.931 that not used use by H.323. The DISCONNECT and RELEASE messages are not even used. We are not even setting up a bearer channel in H.323 when doing a call setup.
In summary, H.225.0 is NOT Q.931.
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Chris Wayman Purvis -
Francois Audet