[Robustness] Call Clearing related

Paul E. Jones paul.jones at ties.itu.int
Fri Nov 5 02:06:17 EST 1999


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 at radvision.com>
To: <ITU-SG16 at 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 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
>



More information about the sg16-avd mailing list