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