Relationship of H.323 and H.245 versions

Paul Long Plong at SMITHMICRO.COM
Fri Jan 22 17:44:11 EST 1999

                -----Original Message-----
                From:   Paul Long [SMTP:Plong at SMITHMICRO.COM]
                Sent:   Wednesday, January 20, 1999 8:15 PM
                To:     ITU-SG16 at
                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.

More information about the sg16-avd mailing list