CUBE SIP-to-SIP Options Ping block?

[Ingo de Jager]

Is there a feature on a CUBE to disable Option Ping responses to the SP if the Option Pings to the internal CUCM server fails?

I am trying to busy out my external Dial-Peer, and stop responding to the SP Option Pings, if connectivity to my internal CUCM server fails. Normally the CUCM would reroute calls to my redundant CUBE but the SP can still 'see' the primary CUBE and send calls that way.

CUCM - sip trunk - CUBE - new sip trunk - SP/SBC

Thanks,

Ingo

[Ayodeji Okanlawon]

Hi Ingo,

If I get you correctly, you are trying to simulate a failover to your secondary CUBE. If that is the case then you can disable the sip process completely and your SP should no longer see the CUBE. CUBE will no longer respond to OPITONS ping from either CUCM or SP and failover should happen

Do the following.

Conf t
voice service voip
sip
call service stop

once you are done you then re-enable the sip process with

no call service stop

[Ingo de Jager]

Yes, that would do the trick but I want to automate this. If there is an intermediate failure on the CUCM - to - CUBE connection I want the CUBE to stop processing SIP packets to the SP and force a failover on the SP side.

Ingo

[Ayodeji Okanlawon]

In that case you will have to look into the possibility of using EEM.

A similar configuration is shown below for EEM when the ISDN interface is down. The challenge will be how to get the gateway to know when the connectivity between CUCM and CUBE is down. Once that condition is known, you will then need to know what syslog message will be generated.etc..Its a little tricky.

event manager applet SHUTDOWN_SIP
 event syslog pattern "Line protocol on Interface Serial0/0/0:15, changed state to down" period 1
 action 1.0 cli command "enable"
 action 1.1 cli command "config t"
 action 1.2 cli command "voice service voip"
 action 1.3 cli command "sip"
 action 1.4 cli command "call service stop forced"
 action 1.5 syslog msg "SIP Services Brought Down by EEM"

[Ingo de Jager]

Now that is an interesting concept. Reading your suggestion I realised I would probably want this in both ways so it will get complicated but is probably doable. Perhaps I need to look at Routing and see if I can setup a Dial-Peer from primary CUBE to redundant CUBE rather with some priority changes on a failure or even shut|unshut DPs using EEM...

Thanks for the suggestion, you got me thinking outside the box now.

[Amit Sharawat]

Hi Ingo,

Could we set-up a secondary dial-peer from CUBE 1 to CUBE 2, in case there is a network connectivity between the CUBE 1 and CUCM, it will route the call to CUBE 2.  This is one solution.

We could also have only one dial-peer, and if that is not available( due to connectivity issues ), CUBE can send an error to the ITSP, and then ITSP should be able to send the call to CUBE 2. This could be another.

You could try the solution provided by Ayodeji, but you need to think of initial programming for the trigger condition.

~Amit

[Ingo de Jager]

Hi Amit,

My thoughts exactly. There is connectivity between CUBE1 and CUBE2. I am interested in your comment 'an 'error to the ITSP'. What kind of error message are we talking about? EG. a standard SIP 503 or something saying the service is unavailable? The SP guy said if we can stop responding to Option Pings they would take the link OOS and route calls to the other one until such time we start to respond again. That unfortunately has a 60s delay but could be the easiest if possible.

Ingo

[Amit Sharawat]

Hi Ingo,

So, if we have Option Ping configured on the CUBE for the CUCM and if the CUBE looses connectivity with CUCM, it will mark the dial-peer as "down".

So, if the call comes from ITSP which is suppose to go through that dial-peer, and if the CUBE sees if down, it will send 500 Service unavailable to ITSP. Now, it is the responsibility of the ITSP to accept that error and try to route the call through our 2nd CUBE.

~Amit

Please rate if helpful.

[Ingo de Jager]

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

[Ayodeji Okanlawon]

Ingo,

How did you simulate the outage between the CUBE and CUCM? What happens if you change the destination ip address of CUCM on CUBE to a an unreachable one? What message does CUBE send to ITSP.

[Ingo de Jager]

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.

[Ayodeji Okanlawon]

Having an ACL may not neccesarily simulate an outage. Using a wrong ip address may be better. This will simulate a network failure. 403 shouldnt be sent in scenarios like this.

The options ping to the ITSP will not be affected even in this scenario. What this will achieve is that your ITSP will notice that there is a failure on the node based on what CUBE sends to it and it should re-route the traffic. I would disable options ping to ITSP totally once you can successfully get calls re-routed because options ping work on a different concept. As long as your CUBE is reachable from ITSP you will always get 200 Okay sent to options ping and in that case your ITSP will always send traffic down to the router.

Even if you get CUBE to send 503 service unavailable for a call, that will not translate to CUBE sending 503 for options ping. They are two different things.

[Ingo de Jager]

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

[Ayodeji Okanlawon]

I am surprised that you provider cant re-route calls based on a non successful response from primary CUBE. I have a similar setup with two cubes and when there is failure on one, or if the ITSP doesnt receive a response from the chosen CUBE, calls are rerouted to the other CUBE automatically. I don't even have options ping to the ITSP. I had to take one of the CUBE completely our of operation a while ago and I just stopped the sip process on it and my ITSP automatically rerouted all traffic to the backup CUBE

[Ingo de Jager]

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