Relationship of H.323 and H.245 versions

[Paul Long]

Chris,

In ASN.1-speak, being able to pass an ASN.1 value, typically transparently, is
called "relaying" [1]. Luckily, the PER encoding used by both H.245 and
H.225.0 are relay-safe [2]. An H.323 entity is therefore technically able [3]
to route a message originally encoded using an abstract syntax other than the
one it uses itself.

Frankly, I don't see how it could be otherwise. Are you saying, for example,
that a v4 EP and a v5 EP routed via a v2 GK are both relegated to using v2?
Will the GK modify all protocol identifiers to indicate this reduction, or
will the EPs continue to think they can use v4 signaling? It's a real shame if
the GK becomes the weakest link when there is no normative reason for this.
Our stack can support relaying, but then I wrote it myself... :-) Maybe you
should have a talk with your stack vendor.

[1] 3.8.23/X.691(1994): "relay-safe encoding: A complete encoding of an
abstract syntax value which can be decoded (including any embedded encodings)
without knowledge of the presentation layer defined context set that formed
the environment in which the encoding was performed."

[2] 7.3/X.691(1994): "PER encodings are always relay-safe provided the
abstract values of the types EXTERNAL, EMBEDDED PDV and CHARACTER STRING are
constrained to prevent the carriage of presentation context identifiers."

[3] C.2(Non-normative)/X.691(1994): "Where an abstract syntax value contains
embedded material that is encoded using a transfer or abstract syntax
different from that associated with the abstract syntax value, it is strongly
recommended that the embedded material be encoded in a relay-safe manner."

Paul Long
Smith Micro Software, Inc.

        -----Original Message-----
        From:   Chris Purvis [SMTP:CPurvis at MADGE.COM]
        Sent:   Friday, January 22, 1999 1:55 AM
        To:     ITU-SG16 at MAILBAG.INTEL.COM
        Subject:        Re: Relationship of H.323 and H.245 versions

        Paul,

        The problem with this is that with the way certain stacks work an
        application (such as a gatekeeper) can not necessarily get hold of
things
        that weren't fully decoded ASN.1-wise, and therefore can not relay
them
        onwards.  What would happen when, for instance, the Madge gatekeeper
        (H.323v2), received a message from (say) a v4 endpoint containing
"new"
        mandatory fields, is that it would be able to forward only that part
of the
        message which is understood in the (v2) ASN.1 of which it is aware.
        To do anything different for future versions may or may not be
possible (my
        understanding of PER encoding isn't quite up to being definitive on
this)
        but if it is possible it would require many stack vendors and people
with
        their own stacks to do some significant rewriting.

        I think Jim's right, much as it would be nice to be cleverer.

        Chris

        > -----Original Message-----
        > From: Paul Long [mailto:Plong at SMITHMICRO.COM]
        > Sent: 21 January 1999 10:21
        > To: ITU-SG16 at MAILBAG.INTEL.COM
        > Subject: Re: Relationship of H.323 and H.245 versions
        >
        >
        >                 From:   Jim Toga [SMTP:jim.toga at INTEL.COM]
        >                 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?
        >
        > I thought I addressed this in the last sentence, "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." This is
        > for intermediate entities such as gatekeepers that relay, or
        > route, call
        > signaling and control messages between entities. My company
        > is not in the
        > gatekeeper business, so with my lack of familiarity I could
        > be off base here,
        > but I believe this statement is necessary to mitigate the
        > earlier statement,
        > "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 last
sentence
        > sanctions, for example, a v1 gatekeeper relaying v2 messages.
        > I assume this is
        > a requirement and that we can indeed mandate it.
        >
        > Was I not clear, or did I simply not address your concern?
        >
        > Paul Long
        > Smith Micro Software, Inc.
        >