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
Here is an example:
sip listen Net-PSTN udp 184.108.40.206 5060
sip network Net-PSTN standard
retransmit-count invite-client-transaction 3
retransmit-count invite-server-transaction 5
retransmit-count non-invite-client-transaction 3
retransmit-timer T1 500
retransmit-timer T2 4000
retransmit-timer T4 5000
retransmit-timer TU1 5000
retransmit-timer TU2 32000
retransmit-timer clientTn 64000
retransmit-timer serverTn 64000
tcp connection-setup-timeout 1000
udp max-datagram-size 1500
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
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 logic:
- 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:
- Number normalization
- TEL/SIP conversions
- Domain conversions
- Regular-expression processing
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 2022222 4082022222
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 RG 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
server-group sip group SG-UC520 Net-UC520
element ip-address 220.127.116.11 5060 udp q-value 1.0 weight 0
Here is a CUSP RG flow chart:
CUSP SG 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 18.104.22.168 5060 udp q-value 1.0 weight 50
element ip-address 22.214.171.124 5060 udp q-value 1.0 weight 100
Here is a SG 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:
trigger post-normalization sequence 1 policy UC520-Four-to-Full
policy normalization UC520-Four-to-Full
uri-component update request-uri user 4444 85224044444
Here is a Post-Normalization flow chart: