[Robustness] Call Clearing related

[Orit Levin]

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 at radvision.com
-----Original Message-----
From: Paul E. Jones <paul.jones at TIES.ITU.INT>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ImpGuideV1.zip
Type: application/x-zip-compressed
Size: 54781 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19991103/8adde3ee/attachment-0003.bin>