Contributions to the Monterey meeting

Sakae OKUBO okubo at GITI.OR.JP
Thu Feb 4 18:47:01 EST 1999

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...)


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
>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.
>> -----Original Message-----
>> From: Paul Long [mailto:Plong at SMITHMICRO.COM]
>> Sent: 29 January 1999 8:09
>> 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 at DELTA-INFO.COM]
>>         Sent:   Friday, January 29, 1999 1:37 PM
>>         To:     ITU-SG16 at 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 at
>>         ------------------------------------------------------
+1-503-264-8816(voice)              Intel - Hillsboro, OR
 mailto:jim.toga at         mailto:james.toga at
 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