No concensus for ASN.1 extension support (was: Re: APC-1265)

Paul Long plong at SMITHMICRO.COM
Fri Sep 5 10:38:54 EDT 1997


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/



More information about the sg16-avd mailing list