Relationship of H.323 and H.245 versions
Ami Amir
amir at RADVISION.RAD.CO.IL
Wed Feb 10 14:19:40 EST 1999
Pete,
It seems to me that your idea is great, and the right approach.
I might be asking something out of context - but doesn't this neat model
break down once we decided to do fast connect - and in essence convey
bearer control inside the call control? Can we now assume that the versions
can gallop along independently.
Regards
Ami
-----Original Message-----
From: Pete Cordell [SMTP:pete.cordell at BT-SYS.BT.CO.UK]
Sent: Tuesday, February 09, 1999 5:05 PM
To: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: Relationship of H.323 and H.245 versions
Dear All,
Just to clarify why the original question was asked,....
It can be readily observed that functionality can be added to H.245
without affecting H.225. (For example, object oriented caps which
enables H.RDC etc) They are also functionally separate items. In telco
parlance (sorry!) H.225 is call control (or user invitation etc) and
H.245 is bearer control (or media control). It is quite legitimate for
them to evolve at different paces as to a large degree they are
orthogonal items.
At a technical level I can see no benefit from inferring the version
number of one from the version number of the other (any examples
welcome) as these are basically two functional sub-systems working
autonomously with only loose coupling (e.g. start, stop etc). Also, as
a gatekeeper can do call re-routing as defined in H.450 - assuming that
the gatekeeper wants to relay messages as much as possible to allow the
full functionality of the attached endpoints to be realised and not
dumb-down the messaging to its level - an endpoint may well receive
different versions of H.245 as the life of the call evolves (e.g. first
connect to IVR, then route to agent, then connect to sales etc). In
this case inferring the H.245 version of the endpoint that you are
connected to, say, third in a set of re-routes from the H.225 version of
the first endpoint you are connected to is totally bogus.
However, to make life easier, if for marketing/procurement purposes
alone, it does make sense for an H.323 version to require a minimum
level of support from H.225 and H.245. As H.323 and H.225 are
intimately linked, saying that the H.323 version is one and the same as
the H.225 version is no problem. However, in a technology that is in
its infancy and still trying to find its feet in terms of how people
want to use it, it seems unreasonable to link H.245 versions explicitly
in with the H.225 issue cycle if modifying H.245 allows more timely
adaptation to perceived evolving market needs.
For this reason I believe that the relationship of the H.245 version
should be of the "or later" type so that exploitation of enhancements to
H.245 do not need to wait for a new issue of H.323. As an example of
why this is attractive, it may be the case that there are no changes
needed to justify an H.225 version 4. However, enhancements may be made
to H.245 after H.225 version 3 is issued. What would we do with
H.323/H.225 in this case?
Regards,
Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================
>----------
>From: Santo Wiryaman[SMTP:swiryaman at VIDEOSERVER.COM]
>Reply To: Mailing list for parties associated with ITU-T Study Group
16
>Sent: 05 February 1999 13:36
>To: ITU-SG16 at MAILBAG.INTEL.COM
>Subject: Re: Relationship of H.323 and H.245 versions
>
>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