[Robustness] Call Clearing related

Orit Levin orit at radvision.com
Fri Nov 5 17:09:30 EST 1999

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.

Orit Levin
RADVision Inc.
575 Corporate Drive Suite 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 529 3516
orit at radvision.com

More information about the sg16-avd mailing list