Cisco VCS random disconnects

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Cisco VCS random disconnects

L3 Networker

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

1 accepted solution

Accepted Solutions

L6 Presenter

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.

View solution in original post

2 REPLIES 2

L6 Presenter

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.

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.

  • 1 accepted solution
  • 4058 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!