cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
618
Views
0
Helpful
5
Replies

Does CUCM fail to other CUBE is ITSP is down?

Ess Emque
Level 1
Level 1

Hello Team,

In our company we have a single CUBE to SIP provider and want to introduce a second CUBE and SIP trunk. We are planning to use route group and use the SIP OPTIONS PING so if CUCM see the CUBE down, it will send the invite to the other CUBE and the call will proceed on the other SIP trunk.

One thing I'm not sure on is, if the ITSP interface goes down (say on CUBE 1), from CUCM, CUBE 1 is still up, so I guess it would send the invite there. I also guess the CUBE will send back a timeout message to CUCM. In this case, will the CUCM then send out an invite to CUBE 2? Or will the call just fail? If it won't re-send the invite again, how can we make sure we have redundancy there? Do we need to start using SLA?

Thanks for all your help

Ess

5 Replies 5

Les Pruden
Level 4
Level 4

Hi -

This is possible.  If you add something like the code I've included below on your egress dial peers in CUBE then if the CUBE is up but the SIP trunk to your service provider is down the CUBE will reject the call and CUCM will try the next CUBE in your route list / route group. 

dial-peer voice 20119 voip

voice-class sip options-keepalive up-interval 12 down-interval 60 retry 3

You can see the dial peer state with the command

sh dial-peer voice sum

20119  voip  up   up             91[2-9].........   1  syst ipv4:67.10.11.12            active

Regards,

Les

What you need is CUBE HA instead of options ping. Options ping isn't the right approach for CUBE redundancy.

Please go through this doc. It has very good information about CUBE HA

http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-00.html

Thanks Mohammed, but due to the nature of the network setup between the two CUBEs, we can't run HSRP between them, so HA is not an option for us. In the case that we can't run HA, what would happen in my original scenario? Would the route lists / route groups on the SIP trunk make the call "failover" to the second CUBE, even though the first CUBE is up, but the ITSP is down?

It depends on the cause code sent from cube to CUCM and the cause of failure. Therefore, I recommended to go for CUBE HA. You can't guarantee failover with options ping. 

Options ping will work only when the SIP trunk is dead such as 503 error or 480 error.

Thank you Mohammed. I know we definitely cannot do CUBE HA. Will the CUCM ever redirect the call to the second CUBE if it receives a 408 timeout? (Rather than using the OPTIONS ping, because I need to check to make sure the provider will be supporting that) Thanks Ess
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: