This has been discussed at lenght many times.
Q.931 is in direct conflict with H.225.0 on many points, including mundate tasks like clearing a call. DISCONNECT and RELEASE messages for example are mandatory in Q.931 and forbitten in H.225.0. That is a trivial example. The bottom line, is that there is some sort of common understanding that Q.931-like procedures are used, with a lot of implied exceptions and divergences. The "call control" procedures are not formally described in H.225.0. There was even a suggestion to add them to a further version of H.323. Be my guess...
-----Original Message----- From: Dave Walker [mailto:drwalker@SS8NETWORKS.COM] Sent: Thursday, June 01, 2000 11:49 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
I'm not sure this is correct. H.323 section 7.3.1 mandates the use of Q.931 Annex D procedures. In turn, that Annex uses Q.931 clause 5. So *that* is what applies in the absence of any overriding provisions in H.323. So I think that Q.931/5.8.6.2 *should* apply.
But to re-iterate what Paul asked earlier, if we had a description of the problem that this was intended to solve, perhaps a less contentious solution could be found.
Regards,
Dave Walker SS8 Networks Ottawa, Canada
Francois Audet wrote:
Except that the section that Paul quotes is in Q.931 and
NOT in H.225.0.
It has nothing to do with H.225.0. In fact, it talks about a message that is not even supported in H.225.0 (i.e., RELEASE).
To reiterate: H.323v2 does not describe how an endpoint
receiving both
elements shall behave themselves. It just says that the
sender shall not
include both since it would cancel fast start. This
particular case (wich
apparently is not supported by any implementation) would
result (if you
follow the logic of H.323v2) in ignoring fast start and
proceeding with
H.245 tunnelling. That is NOT a backward compatibility
problem, and it
does't break anything.
Rejecting the call with cause value 100 is definitively NOT
what H.323v2 says.
In Q.931, the user-user IE is typically optional, so the
clause that
Paul Long's been quoting wouldn't apply. However, since
H.323 makes
the UUIE mandatory, it *does* apply in the case under discussion. I think that the statement contained in TD-26, that it preserves backwards compatibility, is completely wrong. The
correct statement
should have been that it doesn't break implementations
known to the
authors. I agree with Paul that we should try to develop a better solution.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com