RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Francois,
----- 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:
- 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?
- 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?