Relationship of H.323 and H.245 versions

Jim Toga jim.toga at INTEL.COM
Thu Jan 21 16:38:22 EST 1999


Time for me to jump in :-0

This is getting close.   One potential problem surrounds intermediaries
(for example GKs in a GK-routed call).  We need to indicate what exactly is
the expected behaviour of 'M' entities when they get 'N' type messages
(that look like 'M' messages with extentions.)

I would contend that the reality of the situation is that all we can
stipulate, is that the 'M' entities don't crash in the presense of 'N'
messages.  We can't mandate that 'M's  pass new
(uninterpreted/not-understood) data on.  Obviously if there is an existing
opaque field defined, this _shall_ be forwarded.

comments?

jimt.
At 08:15 PM 1/20/99 -0800, you wrote:
>Dave, Pete, et al.,
>
>We need to be very clear about how products of different versions can be
>interoperable.  Terms such as "compatible," "backward compatible," and
>"supports" are too ambiguous to be useful in normative text.  Here's my
>attempt at splitting hairs.  The first paragraph is taken straight from
Dave's
>email.
>
>
>Products claiming compliance with Version 2 of H.323 shall comply with all of
>the mandatory requirements of this document, H.323 (1998), which references
>H.225.0 (1998) and H.245 (1998).  The protocol identifiers used in messages
>defined in H.225.0 (1998) and H.245 (1998) are specified in those
>recommendations.
>
>Interoperability between products of possibly different versions is
assured by
>the following.  Note that what is commonly referred to as a "message" is an
>ASN.1 component of a choice type of typically the first or second level of an
>ASN.1 syntax tree. Therefore, in the following paragraph, a "message" that is
>not a component of the extension root is treated the same as any other choice
>extension addition.
>
>Assume that an H.323vM product and an H.323vN product are in communication
>with each other, where M and N are version numbers and M <= N.  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 and shall
>assume that the H.323vN product also behaves according to H.323vM, with these
>two exceptions:
>*       the H.323vN product encodes values for the protocolIdentifier fields
>for H.323vN, not H.323vM, and
>*       the H.323vN product encodes ASN.1 sequence and choice extension
>additions defined in H.323vN that may not be defined in H.323vM.
>Although the H.323vM product shall parse extension additions defined in later
>versions of H.323 (as prescribed by ASN.1), it shall not recognize or
>otherwise act upon them.  Therefore, the H.323vN product shall not rely on
>behavior in the H.323vM product that is based on the value or presence of
>extension additions defined in H.323vN but not H.323vM.  This in effect
forces
>the H.323vN product to behave like an H.323vM product.  In addition, if a
>product is relaying an ASN.1 value, it shall encode the same value that it
>decoded, regardless of its own version or the version of the value's sender.
>
>Paul Long
>Smith Micro Software, Inc.
>
+1-503-264-8816(voice)              Intel - Hillsboro, OR
 mailto:jim.toga at intel.com         mailto:james.toga at ties.itu.int
 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