Paul,

I think I'm going to puke. :-@

Let me move out of the way.

Built-in, purposeful non-backwards compatibility! Alright! We've come close in the past, but this time we hit it on the nail:

This is why we have a few police officers reviewing the text :-) (That's a complement, actually-- I appreciate it.)

8.1.7.2 "An H.323 Version 4 or higher entity that uses Fast Connect in a call shall use H.245 tunneling when an H.245 Control Channel is required

and

shall always set the h245Tunneling field to TRUE. The process for

switching

to a separate H.245 connection is described in 8.2.3 and may be used by Version 3 or older entities or by newer H.323 entities when communicating with Version 3 or older entities for the purpose of maintaining backward compatibility."

First of all, "...when an H.245 Control Channel is required..." is

redundant

and should be removed because an H.245 channel is _always_ required: 6.2.8/H.323v4: "The endpoint shall establish exactly one H.245 Control Channel for each call that the endpoint is participating in."

I would not be opposed to removing the "when .. required" text. However, there are some endpoints that do not initiate H.245, because there's no need. For example, if two audio terminals call each other with fast connect and the user never sends DTMF and no codecs are changed, is there a need to open the H.245 channel?

The "shall establish exactly one" text has been there since v1, which pre-dates the Fast Connect call flows. We should probably ammend that to say "0 or 1".

But mainly, v4 and post-v4 EPs are not interoperable with pre-v4 EPs that do not support Fast Connect. Wave goodbye to NetMeeting! :-)

I may be missing something here-- if there is an interop problem, I definitely want to address that before the meeting next week. In v4, we require that if an endpoint uses Fast Connect, it shall use tunneling. However, if the other endpoint does not use tunneling, a separate H.245 connection is still a possibility. Also, Fast Connect is still entirely optional.

We also added a sentence in 8.2.1 that says that an endpoint "should" support use H.245 tunneling (period). I had proposed "shall" and it was agreed in the meeting to use the word "shall". However, RADVision pointed out some good reasons why they do not want to insert such a restriction on their equipment, so the word "should" is there now.

Paul

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com