Chris,
A technical question on the second paragraph of your mail: how do endpoints KNOW that they're connected directly rather than through a gatekeeper, in order to decide whether they can (under the current system) drop the call-signalling channel?
First of all... sorry for the delayed response. I am a bit behind :-) I, too, noticed this funny little sentence in the standard. In theory, the GK would signal that the call is being routed, but that may not necessarily be the case. I believe it is clear that we must address this issue. I would like to strike the text as I proposed. I also believe it might be wise to add a paragraph to V4 noting that V3 and older terminals may close the call signaling channel, along the lines of your e-mail. Another issue we have at hand is that of "what is a call signaling channel?" There used to be a one to one mapping between TCP connections and call signaling channels. This is not the case any longer-- one may have multiple calls over the same call signaling channel and one may not even use TCP. Making this distinction will be important for the robustness work being started, as the "logical" connection (the call signaling channel) and the "physical" connection (the TCP or UDP connection) must be referred to independently. (I'm quite open to new terms for here...). It is important to recognize whether an endpoint has closed the call signaling channel (as we understand it today) or if the physical connection has failed. Since we do not signal that we are going to close the call signaling channel today-- we just close the socket-- it makes this problem more difficult. Paul