Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
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
Francois,
Although this is an important question, answering it one way or another does not necessarily answer the question of mixed fast start & tunnelling. The basic point is that what you are advocating the allowance of is expressly forbidden in earlier versions of H.323. The BEST answer from this would be that Q.931 applies (it's my personal feeling that it applies everywhere it is not specifically over-ridden in H.225.0 or H.323) and the receiving (early-version) endpoint rejects the call immediately. This is the best answer because it at least means behaviour is well-defined. The alternative is that Q.931 does not apply in this area, and the behaviour of the receiving endpoint is undefined - some will work, but we have no sure way of knowing how many will not - at which point I refer you to Mr Long's words about a standard being a contract of sorts. This is the ITU, where there is a requirement that new versions interoperate with old ones.
To put things another way, I have nothing against putting these two things into setup messages together. What I do object to is calling the resulting standards H.225.0 and H.323 (with whatever version number). If, however, you want to put them together in a new pair of standards, called (say) H.225.1 and H.323.1 (for which you'll need the approval of lots of people) it might be an idea to clean up the whole thing a bit, learning from some of the mistakes made in H.225.0/H.323...
Regards, Chris
Francois Audet wrote:
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
-- 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