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