-----Original Message----- From: Paul Long [SMTP:Plong@SMITHMICRO.COM] Sent: Wednesday, January 20, 1999 8:15 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Relationship of H.323 and H.245 versions

The H.323 version number shall be taken to be the same as the version number indicated in the H.225.0 protocolIdentifier field. Each product shall encode and decode the H.245 and H.225.0 ASN.1 syntax trees defined in their respective version of H.323. The H.323vM product shall behave according to H.323vM...

Didn't anyone notice? I thought this would be the most provocative part of my little proposal. It says that one cannot implement a subset or superset of the H.323 version indicated by the transmitted protocol identifiers. Subsetting results in incomplete, unpredictable, non-compliant, I'd even say, "broken," implementations. Examples of subsetting include

* An H.323v2 EP not recognizing the H.323v2/H.245v3 extension addition, openLogicalChannel....h263VideoCapability.h263Options. Such a terminal might mistakenly acknowledge a request for a video channel using these options because it chose to ignore the h263Options component. As a result, it would likely receive a video stream that it cannot decode. (This kind of thing quite concerns me.) * Any terminal not responding to RequestMode. (This is common.) * Any terminal not supporting "the transmission of user input characters 0-9, '*', and '#'" via userInputIndication. (This is common, too.)

On the other hand, supersetting produces an incorrect encoding of the abstract syntax for the indicated H.323 version. Examples of supersetting:

* An H.323v1 EP encoding the H.323v2/H.225.0v2 fastStart field, even if it is in communication with an H.323v2 EP. (Sounds like some may have already done this or are contemplating it.) * An H.323v1 EP encoding the H.323v2/H.245v3 h235SecurityCapability component in its terminalCapabilitySet. (Just another example.)

Here's the normative text for encoding.

8.3/X.691(1994): "Implementations are not required to mirror the procedure specified, provided the bit string produced as the complete encoding of an abstract syntax value is identical to one of those specified in this Recommendation | International Standard for the applicable transfer syntax."

The "applicable transfer syntax" is the ASN.1 syntax tree defined in the version of the Recommendation indicated by the protocol identifier. An entity is violating X.691 and therefore H.323 if it transmits an ASN.1 value not specified in the version of the Recommendation that it indicates in the protocol identifier field. It is a violation to transmit a value for an ASN.1 component that is defined in a subsequent version, such as a v1 EP transmitting fastStart. It is also a violation to transmit an incomplete value, such as a v1 EP not transmitting a representation of the slow*MPI and errorCompensation fields of H263VideoCapability (I've seen this one).

And here's the normative text for decoding.

8.4/X.691(1994): "Implementations performing decoding are required to produce the abstract syntax value corresponding to any received bit string which could be produced by a sender conforming to the encoding rules identified in the transfer syntax associated with the material being decoded."

I'm frankly not sure to which transfer syntax the word, "associated," refers-the encoder's or decoder's-but I believe that this means that an entity must decode and recognize all ASN.1 components defined in the syntax tree for its version of H.323/H.245/H.225.0. If I'm right, the entity cannot choose to not decode or otherwise ignore a component defined in its syntax tree. The h263Options example, above, illustrates this.

Paul Long Smith Micro Software, Inc.