Re: Relationship of H.323 and H.245 versions

5 Feb 1999


      Jim,
I do support this position. Thanks.
-santo
...
-----Original Message-----
From: Jim Toga [SMTP:jim.toga@INTEL.COM]
Sent: Thursday, February 04, 1999 6:29 PM
To:   ITU-SG16@mailbag.cps.intel.com
Subject:      Re: Relationship of H.323 and H.245 versions
Chris (and others)
I'm penning up text (proposed) for the implementers guide. (Which I will
post here for comments by tommorow) At this point I'm going to go with
Paul's suggestion below even in light of your comments.  Here's the
reasoning:
If the GK is routing H.225.0 and _not_ H.245 (which is for further study,
btw) then is should _not_ be messing with any syntax/encoding that it
absolutely does not understand (for exactly this reason).  If it is
routing
both, then it can 'proxy' and give what-ever 'face' revision to the
protocol that it wants (as long as it is consistent).
I think what we gain by constraining the mix'n-match is consistency and
predictability.  The cost is that, as we revise the 'umbrella' H.323
Recommendation - products may have to support 'sets' of H.225.0/H.245 to
play in multiple worlds.  I don't see any great _system_ advantage to
allowing vendors to provide a complete hodge-podge of stack revisions.
(This is orthogonal to allowing vendors to provide a hodge-podge of stack
support - H.235, annex E, annex G etc...)
Regards,
jimt.
At 12:36 PM 2/1/99 -0000, you wrote:
...
Paul (and others),
Consider the case of a v1 gatekeeper routing H.225.0 and NOT H.245 in a
call
between two v2 endpoints.  The gatekeeper certainly MAY relegate the
H.225.0
messages to v1.  This may be a policy decision, or it may be due to stack
capabilities.  Note that the gatekeeper may not always desire to relay
messages entirely transparently, and is entirely within its rights to
make
this sort of alteration (although people writing H.323 stacks for
gatekeepers would probably be well advised to implement relaying of
messages
or message fragments).  Certainly the standard should not mandate that
message relay should be entirely transparent.  Anyway, the upshot of this
is
that all H.225.0 messages in the call will be relegated to v1 by the
gatekeeper.  The H.245 session runs directly end-to-end and will hence be
version 3, so both endpoints in the call need to be able to cope with an
H.245 session of a different version from that implied by the H.225.0
session.
Similar discrepancies may occur in the opposite direction (later version
of
H.225.0 than H.245) for similar, but marginally more complex reasons.
So what do we gain by insisting on an endpoint supporting EXACTLY version
3
of H.245 if it happens to be EXACTLY version 2 of H.225.0 and vice versa?
Although I agree that it is what is currently specified I'm unconvinced
it
buys us anything.
Regards,
Chris
...
-----Original Message-----
From: Paul Long [mailto:Plong@SMITHMICRO.COM]
Sent: 29 January 1999 8:09
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: Relationship of H.323 and H.245 versions
Gary,
You be the judge:
Summary/H.323v2: "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). Version 2
products can be
identified by H.225.0 messages containing a
protocolIdentifier = {itu-t (0)
recommendation (0) h (8) 2250 version (0) 2} and H.225.0
messages containing a
protocolIdentifier = {itu-t (0) recommendation (0) h (8) 245
version (0) 3}."
Assuming this text is normative, H.323v2 uses H.225.0v2 and
H.245v3. Period.
IMO, we will be asking for big trouble if we at some point
decide that one can
mix and match versions and even use subsets or supersets of a
particular
version. Whatever interoperability problems we have now will
be magnified many
times over if we head down that slippery slope.
Paul Long
Smith Micro Software, Inc.
-----Original Message-----
        From:   Gary A. Thom [SMTP:gthom@DELTA-INFO.COM]
        Sent:   Friday, January 29, 1999 1:37 PM
        To:     ITU-SG16@MAILBAG.INTEL.COM
        Subject:        Re: Relationship of H.323 and H.245 versions
One more question????
> Dave,
        >
        > Sorry, but I won't be in Monterey.
        >
        > I agree with what you say, except that I would go
further and state
that there
        > is always a one-to-one mapping between H.225.0 and H.245
protocolIdentifiers
        > via H.323. For example,
        >
        >     H.225.0v1 => H.323v1 => H.245v2 and H.245v2 =>
H.323v1 =>
H.225.0v1
        >     H.225.0v2 => H.323v2 => H.245v3 and H.245v3 =>
H.323v2 =>
H.225.0v2
        >
        > This is already implied by the Summary section of
H.323 starting
with version
        > 2. I think it's clear, but you could add
clarification text if you
like. IOW,
        > for example, an EP cannot use H.245v2 and H.225.0v2
in the same
call.
        >
But can H.225.0 V2 (H.323 V2) and H.245V4 (or 5) be
used in the same
call???
Gary
------------------------------------------------------
        Name   : Gary A. Thom
        Company: Delta Information Systems, Inc.
        Address: 300 Welsh Rd., Bldg 3
                 Horsham, PA 19044 USA
        Phone  : +1-215-657-5270         Fax : +1-215-657-5273
        E-mail : gthom@delta-info.com
        ------------------------------------------------------
+1-503-264-8816(voice)              Intel - Hillsboro, OR
 mailto:jim.toga@intel.com         mailto:james.toga@ties.itu.int
 PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41

Santo Wiryaman

tags

participants (1)