C40 registration times out

[Yan Simkin]

Hi all,

I have a customer with C40 (TC6.2.1) registering with our VCS (X7.1). Once in a while, for some reason, the registration times out and is not refreshed and the only way to get it back on-line is to reboot the system. While unregistered, the C40 is perfectly accessible through the WEB etc. The following message appears in the VCS logs:

Oct 22 13:48:31    tvcs: Event="Registration Removed" Reason="Endpoint unresponsive" Service="H323" Dst-ip="10.226.130.19" Dst-port="1719" Dst-alias-type="H323" Dst-alias="MID_CLH_0514_CTN_02" Dst-alias-type="E164" Dst-alias="705526051402" Detail="Registration was not refreshed in time and endpoint failed to respond to IRQ" Protocol="UDP" Level="1" UTCTime="2013-10-22 17:48:31,637"

This is not the only case, we have some other endpoints behaving the same way and the only common denominator is being C40.

Any help would be much appreciated.

Thanks,

Yan

[Martin Koch]

Is there a firewall / nat in place?

Sounds like a tcp timeout or some other l3 h323 "feature" which generate your customers issue.

Please remember to rate helpful responses and identify helpful or correct answers.

[Yan Simkin]

There's no Firewall or NAT, we're all on the same network topologically speaking, in this case, other than basic IP Routing.

Thanks.

[Martin Koch]

6.2.1 is more fresh, so I do not want to rule out any problem there.

Do a tcpdump on both sides and see if what one sends is what the other gets.

But my crystal ball still tells me its your network :-)

Please remember to rate helpful responses and identify helpful or correct answers.

[Yan Simkin]

Oh well... Doing a tcpdump on a VCS with 150 active calls and more than 1000 registrations is kinda risky. Will do off-hours, most probably.

Thanks.

[Martin Koch]

Doing tracing off hours is always a good idea (at least on a non peak hour related issue ;-)

If you can predict somehow when it fails it might be a good idea (+ tracing 2 hours upfront to see what happens).

Anyhow, if your switch/network support is you could use a monitor port, so less invasive.

Or you simply set a filter towards the src/destination ip(s) and maybe icmp to see some errors.

And sure, if the endpoint is often in calls you might want to exclude the media ports as well.

Please remember to rate helpful responses and identify helpful or correct answers.

[Yan Simkin]

Thanks Martin.

I forgot to mention though that it always happens when the system is in a "sleeping beauty" mode. Once you wake it up  through the WEB (Call Control screen), it comes alive. The unresponsiveness can happen anytime. Last one happened after 4 days of proper work...

[christopherrsappctr]

did you ever find a solution to this issue?  We are having the same thing going on for the past 3 months and are stumped.  Our Cisco tech who has been helping us is also stumped.

Thanks