10-23-2013 08:45 AM - edited 03-18-2019 02:01 AM
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
10-23-2013 09:06 AM
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.
Please remember to rate helpful responses and identify
10-23-2013 09:09 AM
There's no Firewall or NAT, we're all on the same network topologically speaking, in this case, other than basic IP Routing.
Thanks.
10-23-2013 09:31 AM
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.
Please remember to rate helpful responses and identify
10-23-2013 09:55 AM
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.
10-23-2013 01:29 PM
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.
Please remember to rate helpful responses and identify
10-23-2013 01:54 PM
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...
02-21-2014 09:09 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide