contributions uploaded
Glen Freundlich
ggf at lucent.com
Fri Feb 5 11:21:35 EST 1999
Jim,
I do support this position. Thanks.
-santo
> -----Original Message-----
> From: Jim Toga [SMTP:jim.toga at INTEL.COM]
> Sent: Thursday, February 04, 1999 6:29 PM
> To: ITU-SG16 at 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 at SMITHMICRO.COM]
> >> Sent: 29 January 1999 8:09
> >> To: ITU-SG16 at 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 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 delta-info.com
> >> ------------------------------------------------------
> >>
> >
> +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