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]

Ingo,

Here is what we can do to try and automate the process using EEM

! Note: The number (10) in the “track” statement below must match

! the dial-peer number
conf t

track 10 stub-object

!

dial-peer voice 10 voip

  destination-pattern .T

  voice-class sip options-keepalive

  session protocol sipv2

  session target ipv4:10.x.x.x

  session transport tcp

  codec g711ulaw

!

event manager environment dial_peer_number 10
event manager environment check_interval 30
event manager applet siptrunk_down
event track 10 state down
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"

event manager applet siptrunk_up
event track 10 state up
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 "no call service stop"
action 1.5 syslog msg "SIP Services Brought UP by EEM"

So when the dial-peer to CUCM is down, we stop the SIP process on the gateway and we can then send 503 to your ITSP for the OOD.

[Ingo de Jager]

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.

[Ayodeji Okanlawon · Accepted solution]

Good point. I totally missed that. Yes you could just do what you are comfortable with. But we could also just shut down the dial-peer to the ITSP  rather than shutting down the sip process. In essence we can modify the EEM script to do what we want it to do.

[Ingo de Jager]

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

[Ingo de Jager]

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

[Ayodeji Okanlawon]

Ingo,(+5)

Thank you for the update. However the advantage that an EEM script gives you is that your ITSP will not send the call to you once it doesn't get a response from OPTIONS PING. It is more proactive than sending the call and getting a 503 from CUBE which to me is reactive. I mean there is no point sending a call to a device that cant process it after all :)

[Ingo de Jager]

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.

[Ayodeji Okanlawon · Accepted solution]

Something like this where dial-peer 11 is the one to the ITSP

event manager environment dial_peer_number 10
event manager environment check_interval 30
event manager applet siptrunk_down
event track 10 state down
action 1.0 cli command "enable"
action 1.1 cli command "config t"
action 1.2 cli command "dial-peer voice 10 voip"
action 1.3 cli command "shut"
action 1.4 syslog msg "SIP Trunk to ITSP Brought Down by EEM"

event manager applet siptrunk_up
event track 10 state up
action 1.0 cli command "enable"
action 1.1 cli command "config t"
action 1.2 cli command "dial-peer voice 10 voip"
action 1.3 cli command "no shut"
action 1.4 syslog msg "SIP Services Brought UP by EEM"

[Amit Sharawat]

Hi Ingo,

No, at this point CUBE does not have this functionality.

~Amit

Please rate if helpful.