----- Original Message -----

From: Francois Audet

To: ITU-SG16@mailbag.cps.intel.com

Sent: Thursday, June 01, 2000 8:49 AM

Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4

> Paul,
>
> We agreed at the Osaka meeting to allow a SETUP to contain both the
> fastStart and h245Control, but it has not been officially
> approved by the
> ITU.
>
> As it stands right now, I don't think I can agree to include
> it in H.323v4
> on the grounds that it breaks backward compatibility with
> V2-- I just don't
> see a clean solution here.

It doesn't "break" anything. The call will still proceed.

It does break things.  If I have a version 2 endpoint and you send it a SETUP message containing both an H.245 tunneled message and fastStart, the SETUP UUIE is invalid.  What will an endpoint do?  Endpoints may select either one or the other or both, but we have no way of knowing.  That is the problem.  If we knew predictably what was going to happen, I'd be OK with this change.  Unfortunately, we have no idea what the result will be for every vendors endpoint.

> I'm opening to hearing more suggestions, but as you pointed
> out, there are
> two issues:
>   1) H.323v2 states explicitly that it is illegal

There are a lot of things that changed from v2 to v4. That's the role of
versions.

Since this goes in the SETUP, we have no chance to make a decision based on the version number.  However, one possible alternative is for H.323v4 devices to put H.245 tunneled messages into a different, new field in SETUP in H.225.0v4.  We could create a new field called "earlyH245"-- that would be a compatible way based on versioning.  The called endpoint, if it is V4 or higher, shall not ignore this field and shall process the H.245 messages in parallel to the fastStart.  That I could live with.

How about that approach?

>   2) There is no way to know what version to destination EP is before
>      sending this illegal message

That would apply to any single change that we do on H.225.0 and H.245.

It does not apply to newly created fields-- they are ignored by endpoints that do not understand them.  However, when you change the meaning of an existing field or the behavior associated with a field, you introduce backward compatibility problems.

How about the approach I suggest above-- adding an "earlyH245" field?