Joerg Ott wrote:

I am wondering whether you are missing the point here.

Hey, it could happen. :-)

• H.225.0 signaling carries a protocol identifier in the mandatory part of all relevant PDUs (RAS as well as call signaling channel)

You're right. However, this is a tenuous relationship that should perhaps be documented. Even though H.225.0 is integral to H.323, we need to be extra careful with future versions of these Recommendations to assure that the numbers of associated versions are always the same. The only mention I could find in either H.323 or H.225.0 is editorial, not normative. 6.1/H.225.0: "...both the discovery and registration sequences contain an H.245 style OBJECT IDENTIFIER that allows the vintage to be determined in terms of the version of H.323 implemented." I don't know, maybe such a thing cannot be normative.

• H.323/H.225.0 describe in each revesion explicitly which version of H.245 to use

When I first started on H.323 last year, I asked Jim Toga which version of H.245 to use. He said to use version 2 but that this wasn't documented anywhere. I see now that it is.

and which features of this to implement.

As I said in my previous email, H.323 does not specify which ASN.1 extension fields are required. It states which messages and procedures are required but not which extensions are required. This is still a big problem and the principal one that I was addressing in this thread. An endpoint has no way of knowing whether the remote endpoint will recognize a particular extension. This _will_ cause problems like the one I described concerning opening a logical channel.

(And, for clarity, this is *NOT* done in the ASN.1, but in the references section of the document!)

I justed looked, and versions 1 and 2 of both Recommendations cite H.245 version 1--not version 2--in terms of the year of decision (1995 vs 1997). I assume this should be fixed.

Hence you can deduce the H.245 version from the H.225.0 version number which is determined IN-BAND in the first PDU exchange between any two H.323 systems.

I see this now. Thanks.

And, of course, you cannot add anything to H.245 without this being appropriate reflected in the H.323/H.225.0 specification.

Maybe I misunderstood him, but it sounded like Jim was saying just the opposite, that an H.323 endpoint could use H.245 constructs in a version of H.245 after the version identified in the H.323 Recommendation. See for yourself. What do you think? "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."

Also: you are talking about no H.323 version signaling? H.225.0 and H.323 go together at all times! H.225.0 defines the protocol syntax and H.323 the procedures; so there is no difference between an H.225.0 and an H.323 version number!

Well, there is a difference, because they are separate Recommendations. However, as long as we have people like you around that know that they must have the same version number, we'll be okay, but there is technically nothing preventing them from having different version numbers.

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