Paul,
BTW, relying on version-specific behavior creates insurmountable
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
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
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 problems the 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