This is a good explanation how to solve IP video calls being dropped by H.225 timeout and TCP keepalive 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.