No subject

Sun Nov 7 02:51:20 EST 1999

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 at 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 at 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 at 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 at software_1> for
          <ITU-SG16 at 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 at software_1.radvision.com>
Date:         Fri, 5 Nov 1999 17:09:30 -0500
Reply-To: Orit Levin <orit at radvision.com>
Sender: Mailing list for parties associated with ITU-T Study Group 16
              <ITU-SG16 at mailbag.cps.intel.com>
From: Orit Levin <orit at radvision.com>
Subject:      Re: [Robustness] Call Clearing related
Comments: To: ITU-SG16 at mailbag.cps.intel.com
To: ITU-SG16 at 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 at radvision.com