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. 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.

Version 2 lives!

Mark

To: ITU-SG16@MAILBAG.INTEL.COM cc: (bcc: Mark Reid/PicTel) From: plong@SMITHMICRO.COM Date: 09/04/97 08:40:45 PM Subject: Re: No concensus for ASN.1 extension support (was: Re: APC-1265)

Jim Toga wrote:

You are correct in that a newer version of the protocol shall not require older versions to comply with new functionality (and must provide

backward

compatiblity).

Of course. I think this is obvious.

This is not to say that a new version cannot have required additional functionality.

I am referring to H.245. The version of H.323 is not exchanged between endpoints. Therefore, there is no such thing as an H.323 version-2 (or -3 or -4, etc.) endpoint as far as another endpoint can descern, and the version of H.245, Q.931, or RAS that an endpoint advertises does not imply which H.323 version the endpoint has implemented. Therefore, how can something be mandatory in one version of H.323 but not in another if the version is not observable? But that's really a different, but just as important, issue. What I'm trying to say is that an implementation may signal support for any H.245 version and yet support whatever extensions it wishes or none at all. And remember that all _messages_ added after version 1 are extensions. There is no correlation between an endpoint's behavior and the value of the protocolIdentifier field in its termCapSet--this field is therefore useless. Don't depend on an endpoint that advertises support for H.245 version 3, for example, to exhibit any behavior required by H.245 version 3. This is because--and I wish it weren't true--an endpoint is not required to process all or any of the sequence extension additions or choice extensions defined in the version of H.245 for which it indicates support. Mr. Skran's proposal in APC-1265 that a certain form of H.245 DTMF signaling be made mandatory for H.323v2, where it is not mandatory for v1, is a case in point of the problems with versioning and ASN.1 extensions in H.245. Let's take a pont-to-point call, for example. If a terminal cannot know upon what version of H.323 the remote terminal is based and if the advertised H.245 version of the remote terminal is meaningless, how can it depend on the remote terminal recognizing and processing a particular form of H.245 DTMF signaling? The remote terminal may ignore the new syntax either because it was not defined for the version of H.245 that it supports or because the implementors simply chose not to recognize the extension additions upon which it is based.

In terms of 'version 2' compliance, I believe that when interopability trials a run to test this, any non-conforming implementation will be high-lighted

Right, but we are informally signaling version information out-of-band at interops. In the field, however, there is no such thing as "version 2." Entities cannot depend on any version-specific behavior because, in H.323's case, the version is not available, and in H.245's case, the version is available but meaningless. Therefore, Recommendations shall be augmented or clarified in subsequent versions, but shall not be constrained. Version N+1 may include additional requirements relative to version N but shall not further constrain any version-N behavior, because N is either not known or is meaningless to another entity.

It is curious that anyone would implement v2 when it isn't finalized.

I agree.

For that matter, much of v1 isn't implemented by most of the vendors currently showing their products.

Again, it sounds like you are talking about the H.323, not H.245, although the same thing can be said about H.245.

If vendors want to utilize some of the constructs from v2 in their v1 implementations (and other entities recognize and respond to them) there

is

no 'rule' against this.

Precisely--there are no rules. I'd much prefer rules to the interoperability problems I foresee when we start having implementations out there of different versions trying to talk to each other. We tried it, already, with H.324, using H.245 version 2 in a world of version-1's. We backed off because of the differing interpretations as to what was required of both the transmitting and receiving terminals. I would be happier if we required that an endpoint signaling support for version N of H.245, truely supported Decided version N of H.245. Specifically, it did not encode any extensions defined in a subsequent version, it encoded all extension additions defined in version N for a particular sequence, and it treated missing extension additions as a semantic error. I believe we would have a lot fewer problems in the months ahead if this would happen. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/