On TD26 - Fast TCS and M/S negotiation in H.323v4

[Paul E. Jones]

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 at mailbag.intel.com