Re-send: [Robustness] Call Clearing related

Orit Levin orit at
Sun Nov 7 17:02:47 EST 1999

I am re-sending my previous message upon getting an indication about network
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
-----Original Message-----
From: Orit Levin <orit at>
To: ITU-SG16 at <ITU-SG16 at>
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
>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
>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
>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
>EP implements such a procedure!
>(2)    The more difficult problem is that upon TCP channel failure, the
>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

More information about the sg16-avd mailing list