cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2789
Views
45
Helpful
8
Replies

Voice Class SIP

mightyking
Level 6
Level 6

Hi NetPro,

We are using SIP to control our Voice Gateways. How do we do fallback from primary CCM to Secondary CCM in SIP environment?

Do we have anything similar to:

Voice class h323 1

h225 timeout tcp establish 3

in SIP environment?

Thanks,

MK             

1 Accepted Solution

Accepted Solutions

paolo bevilacqua
Hall of Fame
Hall of Fame

sip-ua

retry invite 1

View solution in original post

8 Replies 8

paolo bevilacqua
Hall of Fame
Hall of Fame

sip-ua

retry invite 1

Thanks Paolo,

MK

There are also timers setting under sip-ua, but I don't think need to be changed.

Thank you for the nice rating and good luck!

Hi, In addition to Paolo's excellent post...You also need to change the default timer on your CUBE. The default T timer is 500msec..So the gateway will wait 500 msec before it sends a re-invite. So you want to adjust this timer as below

sip-ua

retry invite 2
timers trying 150

another option you can use is OOD (out of dialog) options ping. When the gateway sends an options ping to cucm and doesnt get any response it will busy out the dial-peer and use the second dial-peer if one is configured

dial-peer voice 100 voip

voice-class sip options-keepalive

up-interval 20 down-interval 20 retry 3

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

+5 aokanlawon: SIP Options Ping is a fantastic command. CUCM supports it as well starting in 8.5 which can help with Route Group member failover timing as well.

One related point to be aware of is that IOS/CUBE does not stop hunting through dial-peers if CUCM responds with a 404 Not Found or similar error. Instead, it will match the next dial-peer and send another INVITE for the same call. In most designs where CUBE is only connected to a single CUCM cluster this is pointless (adds overhead) and really confusing (duplicate calls in traces). The SDL link should afford the same answer regardless of which node you query. You can alter this behavior with the following commands:

conf t

no voice hunt unassigned-number

no voice hunt invalid-number

If you follow the SRND and have a strict active:standby CallManager Group design, you can use 'preference 1' and 'preference 2' combined with the global 'dial-peer hunt 2' command to enforce observation of the preferences for equally-matched dial-peers. This ensures that IOS always contacts the primary node in the CMG if available and lowers the SDL activity between nodes. When combined with the 'voice-class sip options-keepalive' command and 'no voice hunt' commands you get a very precise integration: talk to the primary CUCM node unless it's down, then talk to the secondary.

Please remember to rate helpful responses and identify helpful or correct answers.

Jonathan (+5) as usual excellent post. Havent even considered this before. It does make a lot of sense to have this in ones default CUBE template config. There is no point hunting on for an invalid number. Imagine if you have about 5 subscribers in a cluster, then CUBE will have to send 5 different invites for an invalid number..Really good point. Thanks

On this point...

If you follow the SRND and have a strict active:standby CallManager Group design, you can use 'preference 1' and 'preference 2' combined with the global 'dial-peer hunt 2' command to enforce observation of the preferences for equally-matched dial-peers.

I am not sure we need to change the default dial-peer hunt algorithm from 0...Because this matches first on longest match and then preference. As long as we have preference defined on each dial-peer this should ensure that the dial-peer with the lower preference is selected first...

Can you clarify this point please..

This ensures that IOS always contacts the primary node in the CMG if available and lowers the SDL activity between nodes

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

What I witnessed during a previous project was that IOS was round-robin between the dial-peers and not always choosing the more-preferred dial-peer. It was several years ago so I don't recall whether I changed the hunt logic on my own or if TAC told me to try that. Either way that was what fixed it and I haven't removed it from my default since. I start at one instead of zero so that SRST-registered phones take preference zero and match as long as they are registered, even if options ping just brought the voip dial-peer back up.

I agree that it doesn't seem like a logical solution. If you have the time perhaps try giving it a spin in the lab (I wish; I barely have the time to type this!) and see if you can prove me right/wrong. If memory serves the test that failed was IOS wasn't returning to the more-preferred dial-peer after 'show dial-peer voice sum' showed it up/up. The 'show call active voice bri' would continue to show the pid of the secondary CUCM node.

Please remember to rate helpful responses and identify helpful or correct answers.

+5 Jonthan!  Thanks for the input!