Cisco VCS random disconnects

[djrodb]

Hi

We have a Cisco VCS-C on the inside network and a rule created on our PA to allow all traffic to the VCS-E which sits on the public facing network. I'm finding my calls to H323 or IP addresses are randomly disconnecting after a period of 50 minutes.

I've checked with Cisco and they've said to check my Firewall

Has anyone any experience with PA's dropping VC traffic? are there specific settings I should look for in the PA to ignore H323 or SIP based VC traffic?

Thanks

Rod

[rmonvon · Accepted solution]

Rod...You can check the traffic log and verify the elapsed time for those sessions.  If the elapsed time is consistently the same, it may be due to timeouts.  Go in Objects tab ==> Applications, check the timeouts for those apps and extend them as necessary.  Thanks.

[djrodb]

Thanks.

This was the problem. My H.323 traffic was getting blocked due to the default time-outs associated to the H.323, H.225 and H.245 to the maximum 604800. I've documented why this happens below.

(Courtesy of Rocketfire on vctalk)

Once a call has been established, the signaling session on TCP port 1720 goes idle even though there's a VC in session. This is normal behaviour.

Firewalls track individual sessions and will consider them dead after a short period of time if there's no traffic, typically 30 minutes for TCP. Firewalls don't give any indications to the endpoints that their session is now blocked. The endpoints could establish a new TCP session on port 1720, but they don't even know their old session is now longer working through the firewall.

The TCP drivers in the endpoints will send a keepalive every so often. How often depends on the TCP drivers and how the sessions was opened. I know HDX's used to wait two hours before sending a heartbeat!

Once the TCP driver in the codec fails to get a keep-alive acknowledgment, it will tear the session down, much to the surprise of the VC application. HDX's will drop back to their home screen without any error message when this happens. What other endpoints do is anyone guess. The clue is the repetitive timing of the failure, for example n x 30+13 minutes.

Ideally endpoints will send TCP keepalives more often than the firewall timeouts. But this is rarely a configurable item. Usually people just wind-up the timeouts on the firewall "to eleven", particularly for TCP:1729. The problem with this is not everyone else has done the same to their firewalls, so timeouts could still happen in calls with them.

Some firewalls will try to understand H.323 and make allowances for it, others will fudge up a TCP keepalive on behalf of an endpoint as a check before blocking the session. IMHO relying on firewall VC awareness isn't a good approach, as they are never fully VC aware.