12-06-2019 12:58 PM
Hello
I have two SIP gateways (GW1 and GW2 in this order) in a route group configured for Circular distribution algorithm. What do i need to configure to make sure that when GW1 LAN or SIP trunk to ITSP is down, outgoing call that were bound to use GW1 will now used GW2 with the shortest amount of delay possible to route the call.
Thank you
Solved! Go to Solution.
12-06-2019 02:51 PM
You can also configure options ping on the dial-peers if your telco supports it.
12-06-2019 05:34 PM
12-10-2019 12:09 AM - edited 12-10-2019 12:10 AM
Service Parameters, Callmanager, "Clusterwide Parameters (Device - SIP)". I tweak INVITE retries, for example down to 2 which mean three tries in total. The relevant timer is "SIP Trying Timer" which determines how long CUCM waits to receive a Trying response after sending an Invite. Bear in mind a couple of things. Firstly the timer is doubled on each retry, so for example at the default 500ms it will retry after 500ms, then next retry at 1 second, then 2 seconds etc. The other thing is that if you're using TCP it doesn't actually retransmit if the initial Invite went OK at the TCP level, it just waits the equivalent time.
If you set these timers and retries to suit, you should get a system where if the gateway goes down you only add a couple of seconds delay to outbound calls for the first minute or so, then once the option polling timers and retries expire and the trunk is seen as down, there'll be no delay at all.
12-06-2019 02:51 PM
You can also configure options ping on the dial-peers if your telco supports it.
12-09-2019 01:21 PM
Thanks Jamie, will check out the links
12-06-2019 05:34 PM
12-09-2019 03:50 AM
In addition it's worth reducing the SIP timeouts and retries. The default values of 6 retries and 500ms initial timeout mean a delay of over 30 seconds before CUCM realised a gateway is not responding. That can be reduced to a few seconds which will permit nearly normal operation until options ping timeouts set the trunk out of service.
12-09-2019 12:52 PM
Where do you reduce these timeouts, is it service parameters > Callmanager?
12-10-2019 12:09 AM - edited 12-10-2019 12:10 AM
Service Parameters, Callmanager, "Clusterwide Parameters (Device - SIP)". I tweak INVITE retries, for example down to 2 which mean three tries in total. The relevant timer is "SIP Trying Timer" which determines how long CUCM waits to receive a Trying response after sending an Invite. Bear in mind a couple of things. Firstly the timer is doubled on each retry, so for example at the default 500ms it will retry after 500ms, then next retry at 1 second, then 2 seconds etc. The other thing is that if you're using TCP it doesn't actually retransmit if the initial Invite went OK at the TCP level, it just waits the equivalent time.
If you set these timers and retries to suit, you should get a system where if the gateway goes down you only add a couple of seconds delay to outbound calls for the first minute or so, then once the option polling timers and retries expire and the trunk is seen as down, there'll be no delay at all.
12-09-2019 12:51 PM
I have option ping configured on CUCM. I will test call routing. Thanks
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