06-27-2018 06:56 AM - edited 03-17-2019 01:06 PM
I was cruising CAR Device >> Trunk >> Utilization Reports the other day and saw that SIP_to_UC1 was hitting 100% utilization at 1100 & 1200. So I checked SIP_to_UC2, and it was all zeroes. Hmmmm
Went into CUCM Device >> Trunk and saw that While UC1 was Full Service for 153 Days, UC2 was No Service for 152 days 23 hours with remote=503 reason code. I reset the trunk with no success. I then walked back through the entire creation process, comparing both trunk configs along the CUCM side as well as the UC side. Everything is Kosher. On the UC Side the Telephony Integrations Settings are all correct and Check Telephony Configuration comes back with No problems detected.
thoughts? We are running 11.5 CUCM & UC, been up and running for over 14 months now (well except the last 153 days lol)
Solved! Go to Solution.
06-27-2018 09:16 AM
Ended up going with rebooting UC2 to see if that did anything. Went Cluster MgMt, stop taking calls, verified dbrepl was completed, and rebooted. After it came up and all services started, the trunk came up.
HuH. This is something.
06-27-2018 07:06 AM
did you try a reset on the CUC side as well? or only on CUCM?
06-27-2018 07:10 AM
Right now only CUCM side, CUC showed "port reset not needed", and I don't know if a port reset will mess with the active ports.
06-27-2018 09:16 AM
Ended up going with rebooting UC2 to see if that did anything. Went Cluster MgMt, stop taking calls, verified dbrepl was completed, and rebooted. After it came up and all services started, the trunk came up.
HuH. This is something.
10-10-2018 01:44 AM - edited 10-10-2018 01:58 AM
I also had this problem. In the end I believe the reboot fixed it.
I'll explain:
I migrated CUCM skinny integration to SIP integration. SIP trunk to both Pub and Sub were up as showing by the trunk status with options ping. However the call to CUC was failing with a busy signal. The call was trying the Sub node. I noticed that the call was successful when the Route List was configured to try to connect to the Pub node.
Spent a couple of hours checking configs, services, replications etc - no issues.
Rebooted the Sub node.
At this point, CUCM saw the trunk go down and so calls into CUC were successful from this point, because the Route List although configured to connect to CUC Sub, it is connecting to CUC Pub due to Sub being down.
A reboot took a while and RTMT showed CUC Sub CPU 100% for a long time. Throughout this time, although I could access CUC admin pages and CLI, CUCM SIP trunk to the Sub was still not up. Once the CPU came down to normal, SIP trunk came up and calls into CUC working fine. Confirmed successful calls to CUC Sub via RTMT
My CUC version is 11.5.1.13902-2
If this is a problem I may raise a case. Looks like a bug to me.
Would like to add that during all of my checks, I did successfully telnet to cuc sub on port 5060, so the cuc sub was accepting connections. I was going to try restarting a cuc sub service but was not sure which service managed the SIP communications on the Sub. If anyone knows that, please could you share?
EDIT:: while voicemail access is again working on the Sub, visual voicemail is not. To work around this, I've made the Pub the first member in the Route List. I'll log a case in the morning.
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