NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE

This email could not be delivered. Please resend to try again.

NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE -- NOTICE

Received: from mx10.netvision.net.il ([194.90.1.52]) by 199.203.164.18 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sun, 07 Nov 1999 06:45:30 0000 (GMT) Received: from mailbag.cps.intel.com (mailbag.cps.intel.com [192.102.199.72]) by mx10.netvision.net.il (8.9.3/8.9.3) with ESMTP id AAA14583 for roni_e@ACCORD.CO.IL; Sat, 6 Nov 1999 00:10:18 +0200 (IST) Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id OAA29715; Fri, 5 Nov 1999 14:10:48 -0800 (PST) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 170771 for ITU-SG16@MAILBAG.INTEL.COM; Fri, 5 Nov 1999 14:10:48 -0800 Received: from hvmta01-stg.us.psimail.psi.net ([38.202.36.29]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id OAA29711 for ITU-SG16@mailbag.cps.intel.com; Fri, 5 Nov 1999 14:10:47 -0800 (PST) Received: from software_1 ([38.150.216.23]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <19991105220816.QQGV4501.hvmta01-stg@software_1> for ITU-SG16@mailbag.cps.intel.com; Fri, 5 Nov 1999 17:08:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <00e801bf27da$6f1d2cc0$17d89626@software_1.radvision.com> Date: Fri, 5 Nov 1999 17:09:30 -0500 Reply-To: Orit Levin orit@radvision.com Sender: Mailing list for parties associated with ITU-T Study Group 16 ITU-SG16@mailbag.cps.intel.com From: Orit Levin orit@radvision.com Subject: Re: [Robustness] Call Clearing related Comments: To: ITU-SG16@mailbag.cps.intel.com To: ITU-SG16@mailbag.cps.intel.com

Hello Paul, Tzvi and all others!

Yes, once again I am "in complete agreement with his proposal in Red Bank to strike the text in the current version that allows for the closure of the call signaling channel". This point of view is alignment with (a) in my previous mail. Just to add to it: If we decide to keep in the Standard the possibility to signal an intentional closure of Q.931 logical connection by dropping its TCP connection, we make the future Recovery procedures much more complicated. And I ask everybody on this list: Who knows about H.323 existing commercial implementations that intentionally close Q.931 TCP connection and expect the Call to be kept by the other side? Based on RADVision's internal resources and being participants in all interoperability events, we don't know of any!

In regards to (b): Tzvi! To recover from a GK crash (for all types of calls) should be one of the first topics of Robustness Work. There is no question about it!!! My point (b) was that in order to achieve the solution, the "passive" behavior of EP (a sort of implying in the Standard today) would not help. Additional new procedures have to be added to H.323 in the context of Robustness work. Today's Endpoints don't support these future procedures, therefore their passive behavior (or T.O.) will not solve the problem even if the other side supports the new Robustness Procedures.

Why passive behavior /T.O. doesn't help:

(1) When an application (such as H.323) gets a notification from TCP layer about the failure of specific TCP connection (port+IP), the connection is already closed by the TCP layer. The only way to revive Q.931 connection is to LISTEN for a NEW incoming connection, accept it and somehow (such as by callID) to logically attach the new TCP connection to the old Call. If it had been the only problem in the puzzle (which is not: see (2) below) technically it could have been defined, but it is NOT today. (This is definitely a job for our Robustness group.) Therefore NO H.323v1-3 compliant EP implements such a procedure!

(2) The more difficult problem is that upon TCP channel failure, the TPKT connection above gets out of synch. It means that the application layer doesn't know automatically what part of information got lost. In this case, in order to synchronize H.323 Call state between the two sides, application level handshake must be introduced. This is also definitely a job for our Robustness group.

Cheers, 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