H323mobility: Summary of discussion

[Jaakko Sundquist]

Orit,

In an event of a restart/crash in a Gatekeeper using gatekeeper routed
signaling, I would assume that the preferred behavior of the system would be
that existing stable calls will not drop. The Gatekeeper as it recovers will
learn about the existing calls by its internal data and by sending IRQ's to
the endpoints and then restore the Q.931 and H.245 connections. This will
reduce the impact of such an event compared to dropping all the calls.

If I understand you suggestion correctly it seems to me that this would be
moving toward dropping all the calls.

Please correct me if I am wrong.

Thanks

Tzvi Kasten
Networking Infrastructures Group Manager
Research & Development
VCON Ltd.
Tel: 09-9590020 ( 972-9-959-0020)
Email: zvik at vcon.co.il
http://www.vcon.com




> -----Original Message-----
> From: Orit Levin [SMTP:orit at radvision.com]
> Sent: Thursday, November 04, 1999 6:30 AM
> To:   ITU-SG16 at mailbag.cps.intel.com
> Subject:      [Robustness] Call Clearing related
>
> eSafe Protect Gateway (tm) has scanned this mail for viruses, vandals and
> suspicious attachments and has found it to be CLEAN.
>
> File: ImpGuideV1.zip (54,781 bytes)
> Encoding: Base64
> Result: Archive is clean.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> 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 << File: ImpGuideV1.zip >>