This is a good explanation how to solve IP video calls being dropped by H.225 timeout and TCP keep-alive packets.

Basic troubleshoot steps:

- Verify that the timeouts/keep alives on the endpts and Cisco are not set to one hour.

- VSX - maximum time in call under call settings.

- Make sure H.225 timeout is set to higher than 2 hrs.

Description:

Per H.323, TCP 1720 is used for initial call setup and call clearing (H.225) with no further exchange necessary during the call (with the rare exception for call forwarding etc.). TCP 1720 is used again at the completion of a call, when sending H.225 "Release Complete". The issue we find during lengthy H.323 calls is that firewalls interpret the idle TCP 1720 connection as inactive and will close the connection. It is typical firewall protocol to "clean up and close down" inactive ports in order to help maintain a higher level of security. A closed TCP 1720 port can have an adverse affect on an H.323 call and will typically result in a premature disconnection.

In order to avoid TCP 1720 from closing, the Polycom VSX, VSFX and VS all send a keep-alive packet at approximately 2 hours. The keep-alive is a TCP ACK message with a decremented sequence number to TCP 1720 and is initiated by the calling endpoint. A closed TCP 1720 port on a firewall will cause an ICMP port unreachable response to the TCP ACK message. If a response to the keep-alive is not received, the calling endpoint will assume the far-end is in trouble and terminate the call prematurely. This TCP keep-alive method is per RFC 1122 Sec.4.2.3.6.

The iPowers do not send keep-alive to TCP 1720. Rather, they determine far-end state by sending Round-Trip Delay Request over the established H.245 connection. For iPowers, a prematurely closed TCP 1720 is usually not an issue unless the firewall sends (TCP RST) at the time of port closure.

Some firewalls are configured to shut down an "idle" port AND send a (TCP RST) packet to the originating endpoint. In this scenario, the endpoint will terminate the call when it receives the (TCP RST) packet. If the "timeout for idle ports" is set on the firewall for 1 hour, the endpoint may disconnect at 1 hour. If the timeout is set for 90 minutes, the endpoint may disconnect at 90 minutes.

Some firewalls are configured to shut down an "idle" port with no notification sent out to the originating endpoint. In this scenario, the originating endpoint will not know that TCP 1720 had been closed until it tries to access... typically when it sends the TCP keep-alive described above, at the two hour mark....or when sending a "Release Complete" message at the end of the call.

**************************************************************

H.323 sec. 8.6 describes "Protocol Failure Handling":

The Call Signaling Channel also uses an underlying reliable protocol. Depending on the routing of the Call Signaling Channel, either the Gatekeeper or an endpoint may detect the protocol failure. If the Gatekeeper detects the failure, it shall attempt to re-establish the Call Control Channel. This implies that the endpoint shall always have the ability to establish a channel on its Call Signaling Channel Transport Address. Failure of the Call Signaling channel shall not change the call state. After re-establishment of the Call Signaling Channel, the Gatekeeper may send a Status message to request the call state of the endpoint to assure that they are in synchronization.

If the endpoint detects the failure, the endpoint may choose to terminate the call as described in Phase E, or it may attempt to re-establish the Call Signaling Channel as described above.

H.323 sec. 8.5 Phase E - "Call termination"

Either endpoint or an intermediate call signaling entity may terminate a call. Call termination shall be accomplished by either Procedure A or Procedure B:

Procedure A:

A-1) It should discontinue transmission of video at the end of a complete picture, when applicable.

A-2) It should discontinue transmission of data, when applicable.

A-3) It should discontinue transmission of audio, when applicable.

A-4) It shall transmit a Release Complete message and close the H.225.0 call signaling channel and, if open separately, the H.245 Control Channel without sending any H.245 message. Note that closing the media channels is implied.

A-5) Endpoints shall clear the call by using the procedures defined in 8.5.1 or 8.5.2.

Procedure B:

B-1) It should discontinue transmission of video at the end of a complete picture and then close all logical channels for video, when applicable.

B-2) It should discontinue transmission of data and then close all logical channels for data, when applicable.

B-3) It should discontinue transmission of audio and then close all logical channels for audio, when applicable.

B-4) It shall transmit the H.245 endSessionCommand message in the H.245 Control Channel, indicating to the far end that it wishes to disconnect the call and then discontinue H.245 message transmission.

B-5) It shall then wait to receive the endSessionCommand message from the other endpoint and then shall close the H.245 Control Channel.

B-6) It shall transmit a Release Complete message and close the H.225.0 call signaling channel.

B-7) Endpoints shall clear the call by using the procedures defined in 8.5.1 or 8.5.2.

***************************************************************

Resolution:

A simultaneous packet trace (Ethereal / WireShark) taken on both sides of the firewall should show the reason for premature disconnect. If it is determined that the firewall has closed TCP 1720 prematurely, configure the firewall timeout for a value greater than 2 hours to allow the TCP keep-alive method (RFC 1122 Sec. 4.2.3.6) to function appropriately. If a longer timeout value is not acceptable as a global setting, explore the possibility of applying a longer timeout value to H.323 application inspection (if available) or specifically to TCP port 1720. If neither of these options are acceptable, an alternative H.323 firewall traversal device (Polycom V2IU) is recommended.