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