Relationship of H.323 and H.245 versions

[Pete Cordell]

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 at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Chris Purvis[SMTP:CPurvis at MADGE.COM]
>Reply To:      Mailing list for parties associated with ITU-T Study Group 16
>Sent:  12 February 1999 11:17
>To:    ITU-SG16 at 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 at RADVISION.RAD.CO.IL]
> Sent: 10 February 1999 7:20
> To: ITU-SG16 at 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 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
> =================================
>
>>