cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1531
Views
15
Helpful
9
Replies

CUCM SIP trunk failover technique in ITSP trunk outage

Paul Morgan
Level 1
Level 1

Hey all,

 

I think I am missing something obvious.

I am trying to configure failover for my SIP trunks from CUCM to my CUBEs in the event that an ITSP SIP trunk fails.

In terms of call flow and layout;

Phone <> CUCM <> trunk-I <> CUBE <> trunk-E <> ITSP SBC

SIP OPTIONS are enabled on both sides but only feed back a trunk failure to the nearest device. If Trunk-E fails, the CUBE learns about it but how do I pass that failure info to the CUCM so it can tear down Trunk-I and failover to a secondary trunk and begin forwarding calls to another CUBE?

 

thanks for any help offered

1 Accepted Solution

Accepted Solutions

The SBC would report to the CM that it failed to route the call and based on this the route group logic would kick in and route the call via the second option in the RG. If you do not see that you would likely have to modify service parameters to get the CM to do this. I can look up the parameters once I’m in front of a CM.



Response Signature


View solution in original post

9 Replies 9

Steven L
Spotlight
Spotlight

A couple things here. From your mapping, is the CUCM pointed to both CUBEs? Or is it just pointing to the first CUBE? From your description, it seems it is pointing to just one of them.

 

Either way, what you are describing is basic dial peer preference from the first CUBE. From the CUCM it is the same. You simply make the Trunk-I the higher preference in the route list/group.

 

 

This information would not be passed from the "E" to "I" trunk. If you have independent setup routers that act as a SBC for each of your trunks to your service provider you have a few options at hand. If you have these defined as trunks in CM and put them into a route group with Top Down routing algorithm it would always first try the SBC that is first in the list. If that fails because of the E trunk is marked as down the hunting distribution in the route group will try the next in list. This is often quite enough as the added time for the call setup is usually not relevant.

If you really want to get the I trunk to also go down you could be inventive and write a EEM script that runs on the router to check if it has reach ability to the service provider and if it doesn't shutdown the inbound dial peer that is used for the connection from CM. That would indicate the trunk to be down in CM as it to can be setup to use SIP option ping.



Response Signature


Hi Roger,

 

In the event that the trunk-E to the provider is down, trunk-I would remain up, so there would be no re-routing done by CUCM to the second member of the Route Group. As far as CM is seeing, it can still send and receive from CUBE which is the furthest it can see. I dont know any way to have CUCM monitor the trunk to the provider from the CUBE out. 

It seems to me that CUBE should have a feedback mechanism for SIP Options that is much easier than EEM scripts no?

Alternatively, is there no path failure check for SIP in CUCM akin to TCP ?

The SBC would report to the CM that it failed to route the call and based on this the route group logic would kick in and route the call via the second option in the RG. If you do not see that you would likely have to modify service parameters to get the CM to do this. I can look up the parameters once I’m in front of a CM.



Response Signature


0h really? well, I think that is what I didnt know. I can test that and let you know

 

thanks

FYI these would from what I know be the SPs that you should look at.

image.png



Response Signature


So that was the missing piece. I did not know that a failed call (path) would cause the RG to search for the next trunk when the primary trunk was still up.

All working now.

many thanks

Glad to hear that. ':-)'



Response Signature


Sorry to resurrect this but I have a couple clarifying questions. Is there another option outside of changing the service parameters since this may introduce some unknown side effects of existing call flows?

What is the default mechanism that CUBE uses to respond to CUCM SIP Options Ping (with a 200 OK)? And how can we prevent this from happening when the service provider trunk goes down? Even if we use an EEM script to monitor the service provider and force the CUCM inbound dial peer to busy out, that would not stop the CUBE from sending 200 OK to CUCM Options messages. I understand it would stop CUCM from sending invites since that DP would be down, but the Options message it seems would still succeed.

Thought on this sir?