No concensus for ASN.1 extension support (was: Re: APC-1265)
plong at SMITHMICRO.COM
Thu Sep 4 21:40:45 EDT 1997
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
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
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
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
> 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.
Smith Micro Software, Inc.__________http://www.smithmicro.com/
More information about the sg16-avd