Orit,
It sounds like you are in complete agreement with my proposal in Red Bank to strike the text in the current version that allows for the closure of the call signaling channel.
Some have argued that changing this text will mean we are not backward compatible, but I argue that most implementations in the field will drop the call when the call signaling channel is closed anyway-- that's just the way it is. I pointed out in a separate e-mail on the implementers mailing list earlier tonight that I have been *strongly* urging implementers for the past two years to *never* close the call signaling channel. Most folks do not and I suspect 95% of the implementations out there will just end the call if it is closed.
If we clean the slate, we can the properly address how to handle failure conditions in the robustness work. Otherwise, I believe allowing this will just complicate the work even more.
In either case, closing the call signaling channel is bad as you then lose the capability to use supplementary services, send proprietary signaling, or other messages during the call over the call signaling channel.
Paul
----- Original Message ----- From: Orit Levin orit@radvision.com To: ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, November 03, 1999 11:29 PM Subject: [Robustness] Call Clearing related
Hello all! I completely agree that after multiplexing of H.323 calls is possible over the same TCP connection, we have to speak (and upgrade the H.323 specification) explicitly using separate terms: Q.931 logical Connection, H.245 logical Connection and the their TCP channel(s) below. Any better names are welcomed. I would vote for H.323v4 to strike out the old text and rewrite the rules using "new" explicit terminology. I understand that part of this
rules
are going to be based on the new Robustness work. This is why this Robustness work is so urgent and part of it should be done for H.323v4
i.e.
for Feb. 00. So... as a part of this Robustness work and using this new
terminology,
I would like to start from cleaning up "relatively" simple issues.
According
to current state of the standard, it is not explicitly mandated to clean H.323 Call if its Q.931 TCP connection is reported to be lost from any reason. There are two reasons being claimed against complete closure of
the
Call in this situation: (a) May be the other side (or the GK) intentionally closed the Q.931 logical Connection and its corresponding TCP channel in order to free up
its
internal resources, but still wants the H.245 logical Connection and the Call to stay in place. (b) May be it is a real TCP connection failure, but future Robustness Specification will define a way to recover from TCP connection failure without dropping the Call.
As a result, in practice upon TCP connection failure (which may be a part
of
other side failure) H.323 calls are being hanging up without local resources freeing so essential for H.323 users (and networks)!!!
I think that considering (a) and (b) as a general case is a mistake. I
will
try to explain myself below:
(a) If we look in Implementers Guide V.1 (see the attachment) text
(which
has been lost on its way to V.2), the problem was identified long ago. It was recommended to keep the Q.931 logical Connection open. My question is: Do we know about any commercial H.323v1-v3 implementations that intentionally close Q.931 TCP channel but still expect the Call to be maintained? I suggest to find the practical answer and then debate how to keep these implementations happy.
(b) If the case is a real TCP connection failure, the future possible
way
to recover is adding application (i.e. H.323) layer means (i.e. messages/parameters) and procedures to open an alternate TCP connection between the parties and associate it to the previous Q.931 logical connection. Therefore if one of the parties is of H.323v1-3, there is no
way
in the future to find a remedy for such a Call.
The bottom line: If one of the parties in H.323 call doesn't support RobustnessV.1 and
Q.931
TCP connection failure has been reported from TCP layer, the call shall be cleared and resources freed.
Any comments? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: Paul E. Jones paul.jones@TIES.ITU.INT To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@MAILBAG.INTEL.COM Date: Tuesday, November 02, 1999 11:44 PM Subject: Re: [Robustness] Re: Call Clearing related
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