Chris, Ami,

I don't think that your (Chris's) solution 1 is any worse that adapting to any remote H.245 version. Perhaps we can say that for H.323 V2, the fast start structures shall conform to H.245 V4(?), but if its over an H.245 channel then H.245 version negotiation is via TCS. Alternatively, H.245 fast start version information could go into the H.225 SETUP/CALL PROCEEDING/ALERTING/CONNECT messages. I feel this is better than adding this information to the OLCs.

We also need to work through whether things will work out when we have an H.323 version 3 endpoint with, say, H.245 version 6 fast start structures talking to an H.323 version 2 endpoint. My off the top of my head analysis suggests it does work out, but perhaps somebody that it more intimately familiar with it could also check (and explain).

Regards,

Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

---

From: Chris Purvis[SMTP:CPurvis@MADGE.COM] Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: 12 February 1999 11:17 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Relationship of H.323 and H.245 versions

Ami,

So in order to Make Things Work we probably need to do one of the following:

1. Bind tightly for messages in fast connect, but loosely otherwise (which may lead to implementations having to use different ASN for encoding/decoding OLCs depending on whether or not they came in via fast connect!).

2. Add versioning information to OLCs (and possibly elsewhere while we're at it).

3. Bind versions tightly, as currently specified.

4(the controversial one). Obselete fastStart

Regards, Chris

-----Original Message----- From: Ami Amir [mailto:amir@RADVISION.RAD.CO.IL] Sent: 10 February 1999 7:20 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Relationship of H.323 and H.245 versions

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@BT-SYS.BT.CO.UK] Sent: Tuesday, February 09, 1999 5:05 PM To: ITU-SG16@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@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

...