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.
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.
- 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.
Francois,
At worst, it will indeed "'break'" things" ("...a RELEASE COMPLETE message...shall be returned"); at best, the behavior will be implementation-dependent because H.323 disallows it ("...shall not include both a fastStart element and encapsulated H.245 messages...").
(sigh) H.323 was intended to be extensible and backwards compatible. All versions of H.323 are inherently compatible with all other versions of H.323. Every single change that is considered for a new version of the Recommendation must be considered in this light. So far, we've done a pretty good job. Let's not create v4 as an isolated Recommendation that is not backward compatible.
Setup is unique in that the transmitting EP cannot know the version of the receiving EP before it sends it. Therefore, we cannot define purely version-specific behavior for Setup. For other messages, e.g., Alerting and OpenLogicalChannel, we can because, by the time these messages can be transmitted, the transmitting EP knows the version of the receiving EP. That's how we are generally able to make version-specific changes to H.225.0 and H.245.
BTW, relying on version-specific behavior creates insurmountable problems with GKs that use the routed model, i.e., all GKs. Over time, as there are more and more entities of different versions out in the field, and the versioning-GW aspect of a GK becomes more critical, we will find that we have painted ourselves into a corner unless we address the problem now. The only solution I can see is to _never_ define purely version-specific behavior--always signal/negotiate it. (Paul?)
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Sent: Thursday, June 01, 2000 7:49 AM To: ITU-SG16@MAILBAG.INTEL.COM 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.
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.
- 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul, list,
I have some relevant questions:
Is there today an implementation of the H.323 v2 which will break if it receive both tunneled H.245 message and fast start element in the SETUP? Does anyone plan to produce purposefully such an implementation? Does anyone checks specifically for this combination in order to ignore such SETUP message? I would assume most of the implementations will pick one or another (I think fast start has an advantage here), and some of them will be happy with both. I think this "full SETUP" has the big advantage and we should go ahead with this.
Anatoli
Paul Long wrote:
Francois,
At worst, it will indeed "'break'" things" ("...a RELEASE COMPLETE message...shall be returned"); at best, the behavior will be implementation-dependent because H.323 disallows it ("...shall not include both a fastStart element and encapsulated H.245 messages...").
(sigh) H.323 was intended to be extensible and backwards compatible. All versions of H.323 are inherently compatible with all other versions of H.323. Every single change that is considered for a new version of the Recommendation must be considered in this light. So far, we've done a pretty good job. Let's not create v4 as an isolated Recommendation that is not backward compatible.
Setup is unique in that the transmitting EP cannot know the version of the receiving EP before it sends it. Therefore, we cannot define purely version-specific behavior for Setup. For other messages, e.g., Alerting and OpenLogicalChannel, we can because, by the time these messages can be transmitted, the transmitting EP knows the version of the receiving EP. That's how we are generally able to make version-specific changes to H.225.0 and H.245.
BTW, relying on version-specific behavior creates insurmountable problems with GKs that use the routed model, i.e., all GKs. Over time, as there are more and more entities of different versions out in the field, and the versioning-GW aspect of a GK becomes more critical, we will find that we have painted ourselves into a corner unless we address the problem now. The only solution I can see is to _never_ define purely version-specific behavior--always signal/negotiate it. (Paul?)
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Sent: Thursday, June 01, 2000 7:49 AM To: ITU-SG16@MAILBAG.INTEL.COM 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.
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.
- 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.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Anatoli,
There is no way to know how many implementations will break. The only question that can be answered is, Does anyone _know of_ an implementation that will break? and, IMO, this is not good enough. As I said, some vendors will not get asked the question due to being away from the office, etc., some will not respond for whatever reason, e.g., they don't know the answer, and some will be out of the loop--it is well advised but definitely not a requirement for a vendor to monitor this email reflector in order to build a compliant H.323 entity. Surely there is another way to solve whatever problem we're trying to solve without knowingly creating or at least risking interoperability problems. BTW, would someone please tell me what we are trying to fix?
Paul
-----Original Message----- From: Anatoli Levine [mailto:alevine@RADVISION.COM] Sent: Thursday, June 01, 2000 1:29 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, list,
I have some relevant questions:
Is there today an implementation of the H.323 v2 which will break if it receive both tunneled H.245 message and fast start element in the SETUP? Does anyone plan to produce purposefully such an implementation? Does anyone checks specifically for this combination in order to ignore such SETUP message? I would assume most of the implementations will pick one or another (I think fast start has an advantage here), and some of them will be happy with both. I think this "full SETUP" has the big advantage and we should go ahead with this.
Anatoli
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
BTW, relying on version-specific behavior creates insurmountable problems with GKs that use the routed model, i.e., all GKs. Over time, as there are more and more entities of different versions out in the field, and the versioning-GW aspect of a GK becomes more critical, we will find that we have painted ourselves into a corner unless we address the problem now.
The
only solution I can see is to _never_ define purely version-specific behavior--always signal/negotiate it. (Paul?)
Routing the call signaling through a GK can be a problem. For example, if a V1 devices calls a V3 GK to connect to a V2 endpoint, what version does the GK use when it sends messages to either the V1 or V2 endpoint? I would argue that the only safe thing to do is for the GK to report the min(other_ep_version, gatekeeper_version) to the endpoint. The Gatekeeper must then concern itself with properly populating fields mandatory for the version of the protocol it reported to the other endpoint.
I often see people use the GK version. That's bad, because in this case the V2 endpoint might send an empty capability set (TCS=0) to the V1 endpoint and there's nothing the GK can do to gracefully handle this problem. There may be other examples of problems like this, but this is the most notable.
I completely agree that some "generic" mechanism for capability exchange is necessary. Fortunately, we now have such a feature on H.323v4! I have not looked at it to see how it might be utilized for "early H.245", but I suspect it could be used.
Perhaps somebody might want to propose how we might use this new mechanism of H.323v4 to allow for early H.245? Pete, would you like to address this option?
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
It would be very easy to define a package for use in the H323-UU-PDU to contain H.245 that could be tunnelled in parallel with fastConnect.
It would simply involve a package that included a single parameter of the raw type.
For simplicity, I would suggest that an endpoint can indicate support for the feature by sending a parallel H.245 package in the fastConnect message, even if they are empty ones.
If it was successfully determined that the parallel H.245 tunnel was supported by both endpoints, then you would use the package based H.245 tunnel from then on in preference to the existing H.245 tunnel (this is to avoid any sequencing issues that may result if both tunnels were used. Alternatively you could say 'you may use one or the other channel, but not both at the same time.')
I would then suggest that the tunnel thus negotiated would be controlled by the same boolean flags that control the continuing existence of the existing H.245 tunnel. This is very efficient, and allows re-use of the existing procedures.
Personally I would prefer this to adding a new parallel H.245 tunnel in the H323-UU-PDU.
If other people will let me have their comments on the principle I can refine the ideas, and perhaps in collaboration with other, define some text.
Pete.
============================================= Pete Cordell pete@tech-know-ware.com =============================================
----- Original Message ----- From: Paul E. Jones paulej@packetizer.com To: Mailing list for parties associated with ITU-T Study Group 16 ITU-SG16@mailbag.cps.intel.com Cc: pete@TECH-KNOW-WARE.COM Sent: 03 June 2000 02:33 Subject: Re: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
BTW, relying on version-specific behavior creates insurmountable
problems
with GKs that use the routed model, i.e., all GKs. Over time, as there
are
more and more entities of different versions out in the field, and the versioning-GW aspect of a GK becomes more critical, we will find that we have painted ourselves into a corner unless we address the problem now.
The
only solution I can see is to _never_ define purely version-specific behavior--always signal/negotiate it. (Paul?)
Routing the call signaling through a GK can be a problem. For example, if
a
V1 devices calls a V3 GK to connect to a V2 endpoint, what version does
the
GK use when it sends messages to either the V1 or V2 endpoint? I would argue that the only safe thing to do is for the GK to report the min(other_ep_version, gatekeeper_version) to the endpoint. The Gatekeeper must then concern itself with properly populating fields mandatory for the version of the protocol it reported to the other endpoint.
I often see people use the GK version. That's bad, because in this case
the
V2 endpoint might send an empty capability set (TCS=0) to the V1 endpoint and there's nothing the GK can do to gracefully handle this problem.
There
may be other examples of problems like this, but this is the most notable.
I completely agree that some "generic" mechanism for capability exchange
is
necessary. Fortunately, we now have such a feature on H.323v4! I have
not
looked at it to see how it might be utilized for "early H.245", but I suspect it could be used.
Perhaps somebody might want to propose how we might use this new mechanism of H.323v4 to allow for early H.245? Pete, would you like to address this option?
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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?
participants (5)
-
Anatoli Levine -
Francois Audet -
Paul E. Jones -
Paul Long -
Pete Cordell