Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Call disconnects after exactly 1 hour

Hi All,

I have a strange issue, maybe some of you have encountered it or have some further troubleshooting clues.

The setup is as follows - 2 locations, in Location1 there are different endpoints and a VCS Control. Location2 has one endpoint.

The call setup protocol is H.323. Every endpoint is registered to VCS.

If the call is setup from Location1 to Location2 everything is ok.

If the call is setup in the other direction (Location2 -> Location1) the call gets disconnected exactly after 1 hour.

This behaviour is the same regardless of the endpoint type and software version.

It seems to be a network problem but there are no firewalls in the middle and the IT team states that nothing gets cut out.

The log on VCS shows a TCP Connection Closed message:

2013-09-11 10:30:05,104 Module="network.tcp" Level="DEBUG":  Src-ip="Endpoint in Location2" Src-port="11094" Dst-ip="VCS Control" Dst-port="1720" Detail="TCP Connection Closed"

The endpoint in Location2 before the call gets disconnected has the following error:

Sep 11 10:30:05.062 ppc eventlog[2648]: Warning (H245LO-0:Ready): Unexpected message H323MCS_EndSessionCommand from H323MCS-0

Any ideas for further troubleshooting or what could the issue be?

It looks to me like some kind of timer expires but not sure how to locate it.

Kind regards

Maciej Wilk


Call disconnects after exactly 1 hour

Hi Maciej,

what is your network setup is ? do you have any firewalls in the call path?

can you post more details about your network?



New Member

Call disconnects after exactly 1 hour

Hi Alok,

Please see the network diagram below. The red line is the dynamic VPN tunnel.

Cisco Employee

Call disconnects after exactly 1 hour

Yes, this would typically indicate that something is blocking the h225 traffic from the endpoint to the vcs and that there appears to be some control and more likely keepalive packet on that session. 

Now, why an hour?  The default behavior for TC based endpoints is that in there is no h225 keepalive prior to TC6 and in TC6 and later, it defaults to two hours.  The keepalive for these devices is on the H245 session and is sent ever 30 seconds.  You can see this information in the release-note for CSCub20591.

You do not specify what the endpoints are but the output snippet you have for the H323MCS_EndSessionCommand output is from a TC based codec at location 2.  You could run a tcpdump on that endpoint to look at the tcp exchange with the vcs; something like this "tcpdump -s0 -w /tmp/h323.pcap host and tcp" to get a better idea of what is happening.

Now, it does not have to be a firewall.  There are other tcp aware devices that could be in the path.  For example, WAAS.  One clue may be that if the tcp ack in the packet exchange from the location 2 device seems to be much quicker than what you expect for the RTT to the vcs, than that would indicate likely something again in the middle that is tcp aware.  You can get an idea of the expected RTT from the codec through the "systemtools network traceroute" command.

Happy hunting.

New Member

Call disconnects after exactly 1 hour

Well, I'm seeing a TCP RST packet:

  • on the VCS coming from the endpoint at Location 2
  • on the endpoint at Location 2 coming from the VCS

I thought there would be one RST packet..

Cisco Employee

Call disconnects after exactly 1 hour

Yes, you are seeing something in the middle which is generating the TCP RST towards both ends.  I would say there is your proof that there is a TCP/H225 aware device in the middle that is timing out the session after an hour.  Since it thinks that the session is no longer active, it appears to be cleaning it up on both sides as it removes the TCP information from its table.

Since you have captures from both side, you may be able to tell on which side of the tunnel is this possibly coming from based upon the response time of the TCP ACKs during the session.

If you can find out what it may be there is likely a way to tune it to either ignore the h225 traffic.  Or extend the timeout to something greater than 2 hours while running TC6.0 or later on the codecs.


New Member

Call disconnects after exactly 1 hour

Just before the TCP RST packet (0,1s) I can see a RAS IRR packet coming from the endpoint at Location 2 to the VCS.

Could that be a clue?

Call disconnects after exactly 1 hour

Hi Maciej,

IRQ and IRR are used between gatekeeper and endpoint to get status of active calls.

so if you see a IRR message coming thats completely normal.

as said earlier there is device seating in between which is doing a TCP RST, if you have firewall or something please make sure that its not doing tcp/sip/h.323 packet inspection.