SIP Trunk Failover Using Separate CUBE's

[simon hester]

Hi

Looking for some help on possible options to solve the following scenario.

I've attached an outline diagram. 

Normal call flow is CUCM >> Internal SIP trunk 2 >> CUBE 1 >> External SIP Trunk 1 >> SIP provider (PSTN)

We can have a situation where SIP Trunk 1 could go down for a couple of reasons lets say internet provider outage or SIP provider outages. In those cases SIP trunk 1 is marked as down. Yet SIP trunk 2 between the CUCM and CUBE is still up. 

My understanding of the existing configuration/set up is that given SIP trunk 2 is up calls from CUCM would be sent to CUBE 1 and then fail?

I wanted to explore how we can mark SIP Trunk 2 down when SIP Trunk 1 drops and vice versa. So it forces the calls to go via CUBE 2? Is this possible? 

I found this guide  here . but it states we can't use this method across multiple dial-peers when those dial-peers have different bound interfaces. In our case the SIP trunk 1 and SIP trunk 2 are bound on separate interfaces of our 4300 CUBE. 

We are also limited by the fact our CUBE are in geographically different Data centres so they do not run in HA. 

For another customer use interface tracking to help however technically the SIP trunk could go down but the interface are still up and operation so it doe snot feel ideal to use that. 

If it helps our CUCM config uses a route list / route group that has both CUBE 1 (trunk 2) and CUBE 2 (trunk 4)available with the preference for CUBE 1 first. But again my understanding is CUCM would still choose SIP trunk 2 and then when the call fails on CUBE 1 it would not try CUBE 2. Or have i got that wrong. 

Thanks in advance for any comments and help. 
 

[ryabenne]

Simon, 

The best thing we currently have from what you are stating is OPTIONS ping to allow for an "Up / Down" action on the SIP trunk. Also if the SIP trunk is up but the call isn't functioning there are often times where the call won't fail as expected and doesn't failover like you are requesting, we've seen that internally time to time. From there it is going to become a manual intervention of you shutting down dial-peers / trunks to get the outcome you desire. 

You can also definitely work with your account team to request a new feature like you are describing. They will be able to build out a case for you and get that sent over to the developers for review and possible action. 

[Roger Kallberg]

On your very last paragraph, you can have a setup with multiple SBC referenced by CM and get calls to use the secondary if the call fails via the first one. For this you’ll need to change a couple of service parameters for CM to try the second SBC when it gets the call failed to route via the first SBC. I’ll go back to this post and add a picture of which parameter you’ll need to touch.

About using SIP option ping, that’s something that you should use on all your SIP dial peers that are used in the outbound direction. The note about different bound interfaces is not that you can’t use SIP option ping in that case, it’s about that these are independent monitoring entities, where it won’t carry over a state seen on one dial peer to another. So as you stated initially if the state of the dial peer to the service provider is down that wouldn’t be carried over to the side that interfaces with CM. What you should do is to use different SIP option ping option-keepalive profiles, otherwise you’ll get mixed up statuses.

[Elliot Dierksen]

Big +1 to what @Roger Kallberg said about the 'stop routing' service parameters. You can have all kinds of redundancy, but it does you no good if CM doesn't decide to use it. I would suggest you list out some failure scenarios and how you could force those conditions to occur. Then test those cases during a maintenance window. Prior to doing that, you should test the route list(s) that have multiple destinations by moving them up/down in the route list priority. Then test and make sure the call took the path you expected. Once you know all your different paths work, then set the route order back to normal and do your tests.