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.
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
Technical Tips Conventions for more information on document
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
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
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:
When a user initiates a call, a request invite is sent to a server
(proxy or redirect), which determines the path.
The request sent includes the address of the caller and the address
of the callee.
Then the server (proxy or redirect) establishes a point-to-point
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:
Initial SIP invite request to first gateway
1st invite retry to first gateway (delay to retry:
2nd invite retry to first gateway (delay to retry:
3rd invite retry to first gateway (delay to retry:
4th invite retry to first gateway (delay to retry:
5th invite retry to first gateway (delay to retry:
6th invite retry to first gateway (delay to retry:
Failover time to second gateway (delay to failover:
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,
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
This document uses this network setup:
This is the configuration to achieve a much lower failover
Click System in the Cisco Unified CallManager
Choose the Server being used with the SIP from the Server*
Choose Cisco CallManager (Active) from the
Service* drop-down list.
Scroll down to the section for Device -
These are the two parameters you can change in order to alter the
number of retries and the initial delay:
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
There is currently no specific troubleshooting information available
for this configuration.