cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9053
Views
25
Helpful
23
Replies

CUBE SIP-to-SIP Options Ping block?

Ingo de Jager
Level 1
Level 1

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

2 Accepted Solutions

Accepted Solutions

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.

Please rate all useful posts

View solution in original post

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"

Please rate all useful posts

View solution in original post

23 Replies 23

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

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

Please rate all useful posts

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

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"

Please rate all useful posts

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.

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

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

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.

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

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.

Please rate all useful posts

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.

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.

Please rate all useful posts

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

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

Please rate all useful posts

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: