Mark Reid wrote:

A H.323 Version 2 terminal will use H.225.0 Version 2 which does have a protocol identifier which is carried in all of the Q.931 messages. A terminal which is H.323 Version 2 will use H.245 Version 3 and will have to support H.245 features which are called out in H.323 as mandatory.

So are you saying that an endpoint can deduce the H.323 version of the remote endpoint based on the version of the underlying H.225.0 or H.245? The last time I looked, H.323 version 1 does not specify which version of H.245 it requires. We all know (out-of-band, of course) that it has to be at least version 2, but one cannot deduce the H.323 version based on the H.245 version--a version-1 H.323 endpoint could use any version of H.245. I believe that this is also the case for H.225.0.

Assuming that an endpoint cannot know the H.323 version of the remote endpoint, consider this theoretical requirement added to H.323 version 2: "An endpoint shall do X in response to message Y," and Y is represented as an ASN.1 choice extension of UserInputIndication in H.245. What if the sending endpoint relies on the X behavior, a special form of DTMF signaling via Y? The endpoint has no way of knowing whether the remote endpoint will in fact do X, because it doesn't know the H.323 version of the remote endpoint. If it knew that the remote endpoint was in fact a version-1 H.323 endpoint, it might have used fall-back DTMF signaling via message Z which is in the root extension and therefore recognized by all endpoints. And, for several reasons, the endpoint cannot rely on receiving a FunctionNotSupported indication to tell it that the remote endpoint didn't recognize Y.

H.323 is the document which says what parts of H.245 are mandatory ... not H.245 ... as it is used by H.310, H.324 ....etc.

Now for the second problem. There is not sufficient detail in these prescriptions. For example, "H.323 endpoints shall support the syntax, semantics, and procedures of ... Logical Channel Signaling." Okay, that's clear, but what if the following happens between two version-2 H.323 terminals: A terminal specifies a capability represented by a field is not in the root extension (let's say one of those for H.263+) in an OpenLogicalChannel request, the remote terminal does not recognize extension additions up to that field and acks the open even though it does not support that capability. Whoops! The channel is established and the endpoint transmits a stream that the remote terminal cannot decode. These kinds of things will happen unless we require that endpoints support all of the ASN.1 syntax of the version of H.245 that it indicates in its protocolIdentifier field.

Version 2 lives!

The sky is falling! :-)

-- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/