cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3149
Views
0
Helpful
4
Replies

SIP to Unity Connection Down

RAustin70
Level 1
Level 1

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)

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

4 Replies 4

Jaime Valencia
Cisco Employee
Cisco Employee

did you try a reset on the CUC side as well? or only on CUCM?

HTH

java

if this helps, please rate

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.

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.

tonypearce1
Level 3
Level 3

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.