I have a SIP trunk built and the other building has their SIP trunk and we are able to call using the SIP trunk. I have a route pattern that strips all but the last 4 digits to ring the extension. This works every other time. When it doesn't work there is about an 8 second delay and then a fast busy.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Works every other time
- Thread starter NateRD25
- Start date
Is it busy going to or from the CUCM? You didn't mention what the other building is running.
My guess is you don't have the SIP trunk on the CUCM enabled to be active on all nodes if it's busy going to the CUCM. This means calls can only go to the first CUCM listed in the CUCM group specified in the device pool. If a SIP call is sent to another server in the cluster, they ignore it because the first server in the list is active and should be processing all calls. So if the other end is rotating calls between two CUCMs, the active one will accept the call and the other will ignore it. By making it active on all nodes, any CUCM in the cluster will accept the call.
Also note, that having it active on all nodes already could also cause this if the busy signals are happening when calling the other building. When active on all nodes, any CUCM in the cluster can send the call out. If the other end doesn't have all the CUCMs in the cluster configured, it may ignore the call because it doesn't recognize the CUCM IP as being part of that SIP trunk.
My guess is you don't have the SIP trunk on the CUCM enabled to be active on all nodes if it's busy going to the CUCM. This means calls can only go to the first CUCM listed in the CUCM group specified in the device pool. If a SIP call is sent to another server in the cluster, they ignore it because the first server in the list is active and should be processing all calls. So if the other end is rotating calls between two CUCMs, the active one will accept the call and the other will ignore it. By making it active on all nodes, any CUCM in the cluster will accept the call.
Also note, that having it active on all nodes already could also cause this if the busy signals are happening when calling the other building. When active on all nodes, any CUCM in the cluster can send the call out. If the other end doesn't have all the CUCMs in the cluster configured, it may ignore the call because it doesn't recognize the CUCM IP as being part of that SIP trunk.
- Thread starter
- #3
It is busy when I call to the other building. Inbound to me works fine. The other building is also running a CUCM. So I should ask the other to make sure the SIP trunk is enabled to be active on all of the nodes. I believe my side I only have 1 node under my CUCM Group.
- Thread starter
- #4
Here is the some of the config of the Device Pool that my SIP trunk is associated with
Device Pool Name: 1Primary
CUCM Group: CCMNNODE1 - That is my only option
CSS for Auto-registration: Restricted
.
.
.
Roaming Sensitive Settings
Would the SRST Reference have anything to do with it? Currently mine is set to Disable.
Device Pool Name: 1Primary
CUCM Group: CCMNNODE1 - That is my only option
CSS for Auto-registration: Restricted
.
.
.
Roaming Sensitive Settings
Would the SRST Reference have anything to do with it? Currently mine is set to Disable.
SRST shouldn't make an issue as that's used for phones. If there is only a single CUCM sub in that group, then I would leave the box unchecked for active on all nodes. Then make sure the other building has the same box unchecked and only your single sub configured in that sub group. I suspect they have another IP address (your pub maybe) in there and its sending calls to that server. Since it's not in your CUCM group, SIP calls to it will be ignored.
gnrslash4life
MIS
If you run a debug ccsip messages on the gateway, you will most likely see a 503 error and what IP address its trying to hit. CUCM traces will show this as well.
Certifications:
A+
Network+
CCENT
CCNA Voice
Certifications:
A+
Network+
CCENT
CCNA Voice
- Status
Similar threads