Cisco Unified SIP Proxy Call Processing
Document ID: 116251
Contributed by Ajeet Singh, Cisco TAC Engineer.
Aug 26, 2013
Contents
Introduction
Prerequisites
Requirements
Components Used
CUSP Processing Model
Network
Triggers
Routing Lookup Policy
Normalization Policy
CUSP Pre−Normalization Flow
CUSP Routing Flow
CUSP Route Group Flow
CUSP Server Group Flow
CUSP Post−Normalization Flow
Related Information
Introduction
This document describes how the Cisco Unified Session Initiation Protocol (SIP) Proxy makes call routing
decisions.
Prerequisites
Requirements
Cisco recommends that you have knowledge of Cisco Unified SIP Proxy (CUSP).
Components Used
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
Network
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 14.128.100.169 5060
!
sip network Net−PSTN standard
no non−invite−provisional
allow−connections
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
end network
!
Triggers
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."
Normalization Policy
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
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 14.128.100.161 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 14.128.64.191 5060 udp q−value 1.0 weight 50
element ip−address 14.128.64.192 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:
!
trigger post−normalization sequence 1 policy UC520−Four−to−Full
condition TC−UC520−to−PSTN
!
policy normalization UC520−Four−to−Full
uri−component update request−uri user 4444 85224044444
end policy
!
Here is a Post−Normalization flow chart:
Related Information
• CUSP Configuration Example − Cisco Network Modules
• CLI Configuration Guide for Cisco Unified SIP Proxy Release 8.5
• GUI Administration Guide for Cisco Unified SIP Proxy Release 8.5
• Technical Support & Documentation − Cisco Systems
Updated: Aug 26, 2013
Document ID: 116251