Cisco Unified Communications Manager (CallManager)

Failover Timer on SIP Trunks with CallManager Configuration Example

Document ID: 82250

Updated: Apr 07, 2008



This document provides a procedure to determine the timer interval that CallManager uses in order to verify that a Session Initiation Protocol (SIP) device is no longer present when utilizing a SIP trunk in a route list. The information provided in this document enables you to change certain CallManager parameters in order to minimize the time that it takes to failover to the next trunk/gateway in the routelist and attempt completion of the call. This procedure applies only to SIP trunks.



There are no specific requirements for this document.

Components Used

The information in this document is based on Cisco CallManager 5.0(4a).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.


Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Overview of SIP

SIP is an application layer control protocol that can be used to establish, maintain, and terminate calls between two or more end points. SIP is designed to address the functions of signaling and session management within a packet telephony network.

SIP is a peer-to-peer protocol. The peers in a session are called User Agents (UAs). A user agent can function in one of these roles:

  • User Agent Client (UAC)—A client application that initiates the SIP request.

  • User Agent Server (UAS)—A server application that contacts the user when a SIP request is received and that returns a response on behalf of the user.

Typically, a SIP end point can function as both a UAC and UAS, but functions only as one or the other per transaction. Whether the end points function as a UAC or UAS depends on the UA that initiated the request.

From an architecture standpoint, the physical components of a SIP network can be grouped into two categories: clients (phones and gateways) and servers (proxy servers, redirect servers, registrar servers). The network diagram illustrates the architecture of the SIP network used for this document.

This is the way SIP works:

  1. When a user initiates a call, a request invite is sent to a server (proxy or redirect), which determines the path.

  2. The request sent includes the address of the caller and the address of the callee.

  3. Then the server (proxy or redirect) establishes a point-to-point call.


CallManager has certain parameters that can be modified in order to reduce the failover time between the first and the second route in the route list. In CallManager, a route group designates the order in which the two gateways are selected. In other words, it allows you to prioritize a list of gateways and ports for the outgoing trunk selection. With this feature, you can set your primary and secondary route.

A route list associates the route groups in a specified order. In this case, there is only one route group that contains the two gateways. These two gateways have been given an order of priority. However, a route list then associates with one or more route patterns and determines the order in which those route groups are accessed. A route pattern is simply a set of digits that route the call to the gateway. If you dial a certain number, the number has to match one of the route patterns specified in your CallManager. Then, the number has to be checked by the the route list in order to verify its priority. If the number does not have a priority of going through the primary gateway, a failover time exists. After the failover time expires and the second gateway is found, then the call can go through.

This explains the behavior that CallManager takes in its communication with your SIP end points:

  1. Initial SIP invite request to first gateway

  2. 1st invite retry to first gateway (delay to retry: ~500ms)

  3. 2nd invite retry to first gateway (delay to retry: ~1sec)

  4. 3rd invite retry to first gateway (delay to retry: ~2sec)

  5. 4th invite retry to first gateway (delay to retry: ~4sec)

  6. 5th invite retry to first gateway (delay to retry: ~8sec)

  7. 6th invite retry to first gateway (delay to retry: ~16sec)

  8. Failover time to second gateway (delay to failover: ~32)

The total time to failover is 63.5 seconds. As you can see, the delay to retry increases as a geometric progression with a common ratio of 2 and a scale factor equal to the initial failover time. You can use this formula in order to find the total time:

  • n = number of retries + 1

  • k = instance of retry in the summation (1st retry, 2nd retry, etc)

  • r = common ratio (2 in this situation)

  • a = initial delay to retry (scale factor)

  • Total time to failover:


This works as designed and there is not a service parameter that you can change to alter the common ratio. However, you can change the initial delay to retry and the number of retries. This will lower the overall time to failover.

Network Diagram

This document uses this network setup:



This is the configuration to achieve a much lower failover time:

  1. Click System in the Cisco Unified CallManager Administration window.


  2. Choose Service Parameters.


  3. Choose the Server being used with the SIP from the Server* drop-down list.


  4. Choose Cisco CallManager (Active) from the Service* drop-down list.


  5. Scroll down to the section for Device - SIP.


  6. These are the two parameters you can change in order to alter the number of retries and the initial delay:

    • Number of retries is altered by the Retry Count for SIP Invite parameter. Set it to 3.

    • Initial delay to retry is altered by the SIP Trying Timer (msec) parameter. Set it to 200.


    This configuration lowers the overall time to failover to ~3 sec. You can use this formula and these parameters to set the failover time to what you want.


There is currently no verification procedure available for this configuration.


There is currently no specific troubleshooting information available for this configuration.

Related Information

Updated: Apr 07, 2008
Document ID: 82250