Guest

Cisco Network Modules

CUSP Call Processing

CUSP Call Processing

Document ID: 116251

Updated: Aug 26, 2013

Contributed by Ajeet Singh, Cisco TAC Engineer.

   Print

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 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
  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 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 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 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
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

Updated: Aug 26, 2013
Document ID: 116251