ITSP failover between SP's from CUBE

[Ben Rodriguez]

Hello,

We are trying to figure out the best method for failing over to providers if one is down. We have CM 11.5 with a SIP trunk to a pair of 4K routers in HA. The users calling number are using their DID. The issue I see is if their ITSP (ITSP-A) is down that hosts their DID, failover would be an issue since ITSP's (ITSP-B)  wouldn't allow a DID they didn't own to pass through their network. If the call fails to the dial peer(s) does the call get brought back to the CM to try the next entry in the route list? If so I can use a mask (For ITSP-B) on the next dial peer for the call to pass. A limitation we have is each site only has one gateway for outbound calls to the ITSP's. I am aware of the calling number outbound dial peer matching but is that scalable with DID's? Thanks in advance for any help. I have done a lot of research on the subject but couldn't find much out there.

[Chris Deren]

ITSPs usually have redundant SBCs on their side, so that if one SBC fails the other one takes over, so in your configuration you should create connection to each SBC they give you.

As you point out if you have different ITSPs they cannot provide inbound DID failover between each other as the DIDs are owned only by one ITSP.

If your question is about outbound dialing and caller ID masking then you can certainly get creative and under secondary dial-peers for example include diversion header class that adds diversion header that is associated with he carrier, this typically resolves issues with ANI screening and is what ITSPs recommend.

[Ben Rodriguez]

Thanks Chris.  Yes we do have redundant IP's for dialing out via their network. My design question is how would I allow calls out if their network was down entirely. So if carrier A was down how do I call from a carrier A DID via carrier B. Would a 404 SIP code (or similar reject message) allow the call to go back to CM and try the next entry in the route list? 

[Chris Deren]

Options PING should be configured on the CUBE and it would busy out your ITSP A when there are no responses to option ping messages and then your redundant dial peer to ITSP B would be active. 404 is only returned when the destination is invalid which would not be the case here.

[Ben Rodriguez]

Got it. ITSP A does support ping options and we do have them enabled. We are waiting on the activation for carrier B. My question about the route list is if ITSP A is down the call via the ITSP would most likely fail because of the IP phone mask if for ITSP A wouldn't be allowed over ITSP B. I was hoping to use a generic DID mask for call out of ITSP B in the case of an outage on A. I will do some testing and reply back here. I'm sure the case if a full outage would be a rare one but I would like the insurance of failing over to B. I will look into the diversion header config that you suggested. Thanks again Chris. 

[Ayodeji Okanlawon]

In addition to Chris contributions which I have rated helpful for you :).... 

When your ITSP is down, CUBE should either receive a 503 service unavailable or no response for options ping and will mark the dial peer as down. In this scenario the call does not go back to cucm. 

There are two options here.. 

1. Create sip profile to modify remote party ID for any DDI matching old ITSP number and replace with the pilot number of the DDI range

2. Use diversion header as Chris suggests.. This will allow you to present the correct ANI on the new ITSP sip trunk.  The only challenge with this is that you will have to add the diversion header since this will not be present in the original sip INVITE because diversion headers are usually present for forwarded calls. 

So play with both and see what you are happy with. If you need help yoy know where we are :)  

[Chris Deren]

+5 Deji, 

Do you have an example of the sip profile for option1 you've used in the past?

[Ayodeji Okanlawon]

Hi Chris,

Yes here is an example. We take any number in the range 44183123 and replace it with the pilot number..

44163427000

request INVITE sip-header Remote-Party-ID modify "<sip:44183123(.*)@10.10.10.200>" "<sip:441634270000@10.10.10.20>