05-16-2013 10:50 AM - edited 03-16-2019 05:21 PM
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
Solved! Go to Solution.
05-16-2013 10:59 AM
05-16-2013 10:59 AM
sip-ua
retry invite 1
05-16-2013 11:04 AM
Thanks Paolo,
MK
05-16-2013 11:21 AM
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!
05-16-2013 02:41 PM
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"
05-16-2013 05:53 PM
+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.
05-17-2013 04:32 AM
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"
05-17-2013 04:45 AM
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.
09-29-2015 11:18 PM
+5 Jonthan! Thanks for the input!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide