Problem with timeout on H323 connection (TCP 1720)

[orba00001]

I have searched the web and timeout issues with video conferencing seems to be common. The workaround that is most commonly suggested is to increase timeout values on firewalls etc.

In our case we see that an H323 connection is opened on the default TCP-port 1720, a call is negotiated and after that this TCP connection is left unused while the video traffic continues on other ports. After 5 minutes the H323 connection times out on one of the devices in the traffic path which sends resets packets to both endpoints. The call is then torn down because it has lost its control connection.

Is there any way to get the gateway to send TCP-keepalives or some other traffic to keep the H323 connection active? Our gateway is a Cisco Telepresence VCS Gateway running software version X7.2.2.

To me as a network guy the root cause here is that the application does not take into account TCP timeout. We can increase timeout values on the relevant devices in our network. That will solve the problem in most cases, but any network devices in external networks might need the same workaround.

[Randy Valverde Rojas]

Hello,

SIP and h323 both work very different when it comes to keep-alives, for SIP, a refresh timer is configured and negotiated, then a re-invite will be sent every certain amount of minutes and requires a response to refresh the call on the units involved, the firewall should recognize this as traffic through the signaling ports and refresh the time-out. That way the call can keep going and going as long as the re-invites are sent and responded every certain amount of time. and consequently, the firewall should never drop the session until the devices involved hang up.

For h323 the way it works is that after the call is connected, both ends will send a round trip delay request, the receiving end needs to reply with a round trip delay response, these are sequenced and the sequence is individual per direction.

For example, endpoint 1 will send RTDR sequences 1,2,3,4,5 and will expect a response to those. At the same time, endpoint 2 will send RTDR sequences 1,2,3,4,5 as well and expect a response. The response to each one of those needs to have the proper sequence to it.

Now, the round-trip delay request/response dynamic is optional, both ends will always send the request but will only expect a response if it has been responded before. So if there is never a round trip delay response, the call will never drop due to a timeout, but, if there is at least one response, all other requests after that need to be responded as well, otherwise the call will drop.

The important part, these roundtrip delay request/response dynamic is done through the h245 port negotiated so the timeout for 1720 doesn't really take effect, what the timeout needs to be modified for is for the port range for h245, that port range will vary depending on where the firewall is and between which units. For the specific range, I would recommend going to the link below which is specifically for VCS.

So, you should not need to extend the timeout to a huge amount of time, rather it should be extended only enough for the renegotiation or keep alive to happen, this should restart the timeout timer on the firewall and allow it to happen over and over.

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-7/Cisco-VCS-IP-Port-Usage-for-Firewall-Traversal-Deployment-Guide-X8-7.pdf 

Hope this helps.

[Christian Chacon Solano]

Randy,

Prior to TC6, there was no TCP keepalive used for the H225 session. Starting with TC6, a 7200 second (120 minute) TCP timer was enabled which is not configurable.

It is documented at:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCub20591/?reffering_site=dumpcr