Absolutely right. The ITSP however suggested we send 503 which in turn tells me they are happy with being reactive. Perhaps a future IOS will have a feature to disable Options Ping on detection of an internal failure so that the ITSP only has to 'reroute on 503' for the time the Options Ping times out. Thanks for all the good suggestions, they went straight to my  'things to use' folder. ... View more

Just for everyone's benefit. We tested a redundant scenario in our lab with 2 x CUCMs to two CUBEs. Each CUCM SIP trunk has two destination IP's to loadbalance to the two CUBES and the two CUBEs each have a Dial-Peer to our two CUCM servers. We failed one CUCM-CUBE1 SIP trunk and inbound calls from the ITSP were routed by the CUBE1 to the second CUCM server as expected. We then failed the second Dial-Peer from CUBE1 to CUCM so that the CUBE doesn't have any outgoing DPs to the CUCM. On receipt of an INVITE from the ITSP the CUBE sent back a 503 and the ITSP immediately rerouted the call to the second CUBE. This means that the CUBE can detect a failure on the CUCM/CUBE side and reply back to the ITSP a 503 message. This is exactly what we needed so there is no complicated redundant configurations required on the CUBEs. Ingo ... View more

Agreed, that is simple enough and normal SIP Options pings will just timeout on the ITSP side and they will reroute. ... View more

Yes, that can work but it would require manual intervention when the CUCM side trunk comes back up. Because you stop SIP altogether the Option Pings to the inside will also fail once the trunk is up. You could probably do the same with IP SLA service tests to port 5060 to check connectivity and then re-enable the SIP process exactly the reverse of what you have above to shut it down. What I've decided for now is to do the Dial-Peer option between the CUBEs and reroute the call if the one CUBE cannot get to the CUCM server. I did a quick test in my lab and it works well. I just have to think of all the different failure scenarios possible but so far its the easiest to implement and support. BUT: I like the EEM option with possibly IP SLA and will test it in my lab once I have some spare time. ... View more

I think we are talking about the same thing here. Your ITSP probably mapped the 403 Forbidden message to reroute on their side. Ours just wanted us to send a 503 Service Unavailable instead. The Forbidden message might point to a problem further down the line and doesn't really mean all destinations on that trunk is Forbidden. The 503 message makes it clear that the whole trunk service is down hence they will reroute. I will however discuss it with them again to see if they can reroute on 403 Forbidden and then have something like our Huntstop on the second trunk and if that one is also 403 Forbidden to not try and send calls in a possible endless loop. The alternative with a DP between the CUBEs works fine as well as long as you have the CUCM side configured to both CUBE as destination IPs. It will however load-balance outbound but there are ways around that as well if you don't want that behaviour. Ingo ... View more

An unreachable IP has the same effect. The reason I started this thread was because the ITSP SBC has the ability to send back 503 on it's outside DP if an internal DP fails. I was hoping we had the same feature. Even just blocking SIP altogether would achieve th3e same as their Option Pings would take the trunk OOS. Anyway, not being able to influence the outside DP on an internal failure I am left with a redundant DP between the two CUBEs so inbound calls will reroute around the failure. Thanks for all the suggestions. Ingo ... View more

I put an ACL on the interface towards CUCM blocking (inbound) port 5060 from reaching me. This simulated the Options Pings being sent but no replies received. My two CUCM DPs were then in a busyout state. Options Ping from the ITSP were still replied upon with a 200 OK. Inbound calls then reached my CUBE but because there is no path to CUCM the 403 Forbidden is sent back to the ITSP. I could have put a non-reachable IP on the CUBE but it would have been the same results. ... View more

Amit, I tried this in my lab and all I can see is a 403 Forbidden sent back to the ITSP for inbound calls. Option Pings on the ITSP trunk replies 200 OK as per usual. The SP guy suggests we send back a 503 message on his Options Ping when the inside DP is marked as Busyout due to a connection failure. He can map that to a Trunk OOS and reroute on his side. Would that be possible to reply 503 when the connection to the internal CUCM trunk is down? Ingo ... View more