APC-1261 (H.323 Annex C) uploaded.

Greg Kisor Greg_Kisor at CCM.JF.INTEL.COM
Thu Sep 4 18:02:00 EDT 1997


Just a note of clarification - H.225.0 (both Q.931 derived messages and
RAS) includes a protocol identifier for versioning......

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
compatiblity).  This is not to say that a new version cannot have required
additional functionality.

In terms of 'version 2' compliance, I believe that when interopability
trials a run to test this, any non-conforming implementation will be
high-lighted.  It is curious that anyone would implement v2 when it isn't
finalized.  For that matter, much of v1 isn't implemented by most of the
vendors currently showing their products.

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.

Regards,

jimt.

At 07:26 PM 9/3/97 -0500, you wrote:
>Toby Nixon wrote:
>> Paul Long wrote:
>> >> 1. It shall be mandatory for all H.323 V2 terminals to promote
>> >> interoperability.
>> >
>> >Please, Mr. Nilsson or Mr. Toga, correct me if I'm wrong, but I don't
>> >believe it can be made mandatory at this time. A newer version of a
>> >Recommendation can augment and clarify but cannot constrain previous
>> >versions.
>>
>> But a new version of a recommendation CAN add new mandatory requirements
>> on terminals claiming compliance to that new version. For example, if
>> "X" was optional in Version 1, version 2 could make "X" mandatory for
>> terminals claiming compliance to version 2. Or, if "X" was mandatory in
>> version 1, and version 2 specifies an improved technique "XX", version 2
>> could require that two version 2 terminals communicating with each other
>> use "XX" instead of "X" even though both implement "X" for backward
>> compatibility with version 1. A new version should always require
>> backward compatibility by continuing to mandate fallback to mechanisms
>> required in previous versions.
>
>Because the only version information currently exchanged between all
>endpoints is the H.245 protocol identifier--in particular, the version
>of the H.323 Recommendation is not exchanged--I assume you are referring
>to the version of the H.245 Recommendation "in use." And there's the
>rub. The protocol identifier is practically useless because extensions
>not in the root extension may be implemented at the vendor's discretion,
>"shall" or not.
>
>Case in point: Hasn't at least one vendor released product based on the
>Determined H.245 version 2 syntax, which is different than the Decided
>syntax? That means that even though this vendor's terminal advertises
>"version 2," it does not recognize the extension additions that were
>added after being Decided. Some may not need to be recognized, such as a
>new field in a capability; others _shall_ be recognized and processed,
>such as a new command. Therefore, an endpoint cannot assume that another
>endpoint will recognize (and therefore process) _any_ extension
>additions and must take this possible lack of behavior into
>consideration. And this is not just the behavior of an obscure
>implementation ;-). Correct me if I'm wrong, Dave, but I believe this is
>also Dave Lindbergh's interpretation.
>
>I talked with Bancroft Scott about this, and he said that a system that
>uses ASN.1 usually requires implementations to encode all extension
>additions in a particular version of the syntax for that system. IOW, an
>implementor can't just encode the first 5 of a possible 9 extension
>additions in a given version of a syntax tree. However, version
>information about the syntax tree is not typically presented to the
>receiver; therefore, the receiver cannot _expect_ a particular number of
>extension additions to be present. (In addition to sequence fields, this
>also applies to choices not in the root extension.) In other words, all
>extension additions are in a sense optional (of course, there cannot be
>a gap in a sequence of fields), and all implementations must be able to
>handle this. Transmitters must not assume that a message (a choice) or
>field (a choice or sequence component) not in the root extension will be
>recognized by the receiver, and receivers must not treat the absence of
>an extension addition as an error.
>
>I don't like this. I would prefer that if an endpoint advertises that it
>supports version N syntax, it supports _all_ of version N syntax, and
>other endpoints can rely on that support. For example, if an endpoint
>receives only 5 of the 9 extension additions defined in the version of
>the H.245 syntax tree that the transmitting endpoint advertised that it
>supports, it shall treat it as an error--a malformed message. Likewise,
>a transmitting endpoint can assume that a receiver that advertises
>support for version N syntax will recognize and process, according to
>the applicable Recommendations, all extensions defined in that version
>of the tree.
>
>I believe that there is a serious ommission in the Recommendations about
>what to do about extensions. We must come to some concensus about what
>the rules are and document them. Soon. I meant to prepare a contribution
>for Sunriver about this; however, I have not had the time due to
>circumstances beyond my control.
>
>Back to the original problem, since the only version information
>exchanged between terminals is for H.245 and since receiving terminals
>are free to implement whatever extensions they wish to, I go back to my
>original assertion. A newer version of the H.245 Recommendation can
>augment and clarify but cannot constrain previous versions.
>
>--
>Paul Long___________________________http://www.cmpu.net/public/plong
>Smith Micro Software, Inc.__________http://www.smithmicro.com/
>
>

*************************************************************************
***  +1-503-264-8816(voice)             +1-503-264-3485(fax)          ***
***  jtoga at ibeam.intel.com              Intel - Hillsboro, OR.        ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***
*************************************************************************



More information about the sg16-avd mailing list