cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2182
Views
5
Helpful
7
Replies

Route Group distribution Algorithm

Nkechi Latunji
Level 1
Level 1

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 

3 Accepted Solutions

Accepted Solutions

tgaur
Cisco Employee
Cisco Employee

Hi

you can configure option ping on CUCM, so that the moment CUCM not getting replies of option message it will treat the gateway is down and not even attempt to send setup out to the gateway, and will skip to next member in RG immediately.

Regards
Tarun

View solution in original post

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.

View solution in original post

7 Replies 7

Thanks Jamie, will check out the links

tgaur
Cisco Employee
Cisco Employee

Hi

you can configure option ping on CUCM, so that the moment CUCM not getting replies of option message it will treat the gateway is down and not even attempt to send setup out to the gateway, and will skip to next member in RG immediately.

Regards
Tarun

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.

Where do you reduce these timeouts, is it service parameters > Callmanager? 

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.

I have option ping configured on CUCM. I will test call routing. Thanks