This document describes how the Cisco Unified Session Initiation Protocol (SIP) Proxy makes call routing decisions.
Cisco recommends that you have knowledge of Cisco Unified SIP Proxy (CUSP).
This document is not restricted to specific software and hardware versions.
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.
CUSP Processing Model
This section describes the concept of network used in the CUSP call processing flow.
The network contains a logical collection of local interfaces that are treated the same for general routing purposes.
SIP messages, upon arrival, are associated with the network on which the messages are received (incoming network).
The outgoing network is set as a part of the routing logic of CUSP and the messages are forwarded/sent to the set network.
Each SIP network has these properties:
Listen Points - can have multiple listen points per network
Server Groups - elements in the Server Groups (SGs), such as Cisco Unified Communications Manager (CUCM) clusters
SIP Timers - retransmission counts
Ping Options - monitors the health of each element in the SG and is configured per network
Record Route - call states are not stored because there are routing tables
Via Header Stripping - in order to hide the topology
This section describes what triggers are and how they are used.
A trigger is a set of conditions used in order to determine which routing and normalization policy is applied to an SIP request.
A trigger condition defines matching rules against certain headers or fields within an SIP message, network, and transport type (UDP, TCP, Transport Layer Security (TLS)).
A trigger is evaluated as either true or false for each received request.
If the condition is true, then preset behaviors are invoked.
The AND operation is achieved by specifying headers or fields in a single trigger-condition command.
The OR operation is achieved with several trigger-conditions, each identified by a sequence number.
The conditions are evaluated in ascending order based on sequence number.
The mid-dialog condition is the first one, so that the policy step is skipped for mid-dialog messages.
Here is an example:
trigger condition TC-from-CUCM sequence 1 in-network Net-CUCM method INVITE end sequence sequence 2 in-network Net-PSTN local-port 5060 end sequence end trigger condition
Routing Lookup Policy
This section describes the routing lookup policy for the CUSP call processing flow.
Each routing policy is expressed as a sequence of steps and each is specified in order to perform a lookup in a table.
CUSP executes each step in order:
Each step has a selectable key.
If the step produces a route, that route is used.
If the step results in a "no-match," the next step is attempted.
An SIP request can be routed to a single destination or to a Route Group (RG).
The policy has Multi-layer Route Advance within a RG, and has configurable failover SIP response codes.
Policy-based request rejection is incorporated (4xx responses and above).
Nested policies are allowed.
Table-based routing is used, which has these properties:
It supports a large number of routes in a table (10,000+).
Routes in a table are populated via CLI or a route file.
Lookup keys are used, such as calling and called party number, carrier codes, and location routing numbers.
Flexible rule matching is used, such as "longest prefix matching."
This section describes the CUSP call processing flow normalization policy.
SIP headers are normalized based on a configured policy.
Normalization involves the addition, modification, and removal of SIP headers.
It is applicable to both SIP requests and responses.
It is used in order to solve incompatibilities or interoperation issues between different SIP servers.
It can be performed before or after routing logic is executed (Pre-Normalization and Post-Normalization).
Normalization Policy - Defines what changes must be made to the SIP message.
Normalization Triggers - Define how a normalization policy is chosen.
The policy consists of steps, and each step specifies a single change to the SIP message. For example:
Here is a flow chart that shows the process:
CUSP Pre-Normalization Flow
Pre-Normalization is the modification of SIP messages after an SIP request is received and before routing decisions are made.
In this example, the user portion of the SIP Uniform Resource Identifier (URI) Request is replaced by 4082022222 if the value that exists is 2022222.
!trigger pre-normalization sequence 1 policy CUCM-Prefix-408 condition TC-from-CUCM ! policy normalization CUCM-Prefix-408 uri-component update request-uri user 20222224082022222 end policy !
Here is a Pre-Normalization flow chart:
CUSP Routing Flow
This section illustrates the CUSP routing flow. Here is a CUSP routing flow chart:
CUSP Route Group Flow
This section describes the CUSP RG flow.
The RG specifies multiple routes that an SIP request might take (similar to a CUCM RG).
Each route is configured as an element.
When a routing trigger condition is evaluated as true, the lookup policy that corresponds to it is used in order to create a list of applicable routing tables.
Each entry in the routing table points to a particular RG, SG, or specific destination.
Routes are advanced between elements until successful. For example, if you want to route a call to a CUCM cluster, the Subscriber can be one element while the Publisher is the second.
Route advances between elements are controlled on the SIP response received (failover response).
Elements of the RG are heterogeneous. For example, one route heads toward CUCM and another to the Public Switched Telephone Network (PSTN).
A RG element can point to a SG.
SIP requests are routed based on the time of day.
CUSP supports these actions:
Time-based routing within a RG
Percentage/weight-based routing within a RG or SG
This allows for load-balancing of traffic among downstream elements, based on the preset weight.
It provides q-values for priority/least cost-based routing.
Here is an example of a RG with a SG configured as the target destination:
! route group RG-UC520 element target-destination SG-UC520 Net-UC520 q-value 1.0 failover-codes 502 - 503 weight 0 end element end route ! server-group sip group SG-UC520 Net-UC520 element ip-address 184.108.40.206 5060 udp q-value 1.0 weight 0 failover-resp-codes 503 lbtype global ping end server-group !
Here is a CUSP Route Group flow chart:
CUSP Server Group Flow
This section describes the CUSP SG flow.
A SG is a cluster of downstream elements that CUSP treats as a single logical route.
Members of the SG are homogeneous, such as stack/cluster of Cisco Unified Border Elements (CUBEs).
Requests are load-balanced among members.
The priority of each member (element) in a SG is assigned by q-values (0.0 ? 1.0), with 1.0 as the highest.
The SG allows for member health monitoring (ping).
The SG allows for automatic restoration on member recovery.
Here is an example of a SG with two elements (CUCM Publisher and Subscriber)
! server-group sip group SG-CUCM.ajeet.com Net-CUCM element ip-address 220.127.116.11 5060 udp q-value 1.0 weight 50 element ip-address 18.104.22.168 5060 udp q-value 1.0 weight 100 failover-resp-codes 503 lbtype global ping end server-group !
Here is a Server Group flow chart:
CUSP Post-Normalization Flow
Post-Normalization is the modification of SIP messages before they are forwarded to the next hop.
In this example, the user portion of the SIP URI Request is replaced by 85224044444 if the value that exists is 4444: