I am re-sending my previous message upon getting an indication about network problems. 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 -----Original Message----- From: Orit Levin orit@radvision.com To: ITU-SG16@mailbag.cps.intel.com ITU-SG16@mailbag.cps.intel.com Date: Friday, November 05, 1999 5:09 PM Subject: Re: [Robustness] Call Clearing related
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