Guest

Cisco Unified SIP Proxy Software

Configuring Cisco Unified SIP Proxy Version 1.1.3 for an Enterprise Network

  • Viewing Options

  • PDF (536.3 KB)
  • Feedback
Configuring Cisco Unified SIP Proxy Version 1.1.3 for an Enterprise Network

Table Of Contents

Configuring Cisco Unified SIP Proxy Version 1.1.3 for an Enterprise Network

Contents

Introduction

Prerequisites

Requirements

Product Compatibility

Components Used

Conventions

Configure

Network Diagram

Configuring Network Connectivity

Attaching the Cisco Unified SIP Proxy to the Cisco ISR

Turning on NETCONF

Entering the Cisco Unified SIP Proxy Module

Booting Up Cisco Unified SIP Proxy for the First Time

Validating the Platform on Bootup

Configuring Virtual Interfaces for Cisco Unified SIP Proxy

Configuring TLS

Creating and Importing a Signed Certificate

Configuring TLS on Cisco Unified SIP Proxy

Configuring the Cisco Unified SIP Proxy Module

Configuring Logical Networks

Configuring Trigger Conditions

Configuring Server Groups

Configuring Route Tables

Configuring Normalization Policies

Configuring Lookup Policies

Committing the Configuration

Configuring Routing Triggers

Configuring Normalization Triggers

Configuring Listen and Record-Route Ports

Configuring a Hostname (Optional)

Configuration

Verify

Troubleshoot

Troubleshooting Procedure

Troubleshooting Commands

Related Information


Configuring Cisco Unified SIP Proxy Version 1.1.3 for an Enterprise Network


First Published: May 19, 2009
Last Updated: January 6, 2012

Contents

Introduction

Prerequisites

Requirements

Product Compatibility

Components Used

Conventions

Configure

Network Diagram

Configuring Network Connectivity

Configuring TLS

Configuring the Cisco Unified SIP Proxy Module

Configuration

Verify

Troubleshoot

Troubleshooting Procedure

Troubleshooting Commands

Related Information

Introduction

Cisco Unified SIP Proxy is designed to simplify the deployment of multiple Cisco Session Initiation Protocol (SIP) elements. Cisco Unified SIP Proxy provides name resolution and routing between these elements and other services. This document is a template for configuring Cisco Unified SIP Proxy to provide these features for a sample enterprise network. A typical Cisco Unified SIP Proxy deployment is shown in Figure 1.

Figure 1 Typical Cisco Unified SIP Proxy Deployment in an Enterprise Environment

The Configure section of this document contains three parts. The first part describes the architecture and call flow of the network. The second part, describes how to configure Transport Layer Security (TLS) on Cisco Unified SIP Proxy because many of the connections in this system use TLS transport. The third part is a step-by-step guide on how to configure Cisco Unified SIP Proxy.

Use this document with the Cisco Unified SIP Proxy Command Reference.

Prerequisites

Requirements

Product Compatibility

Components Used

Conventions

Requirements

Ensure that you meet these requirements before you attempt this configuration:

Cisco 3800 Series Integrated Services Router (Cisco ISR) running Cisco IOS Release 12.4(22)T or a later release

NME-CUSP-522-K9 (Cisco Unified SIP Proxy) module with:

2 GB of RAM

160 GB hard disk

Gigabit Ethernet connectivity to router backplane

Cisco Unified SIP Proxy is a network module that you can install in any slot in the router.

Product Compatibility

The Cisco Unified SIP Proxy network module operates on the Cisco 3800 series of platforms. Multiple integrated services routing applications may be employed at the same time. However, Cisco Unified SIP Proxy may not coreside in the same router when Cisco Unified Communications Manager Express or Cisco Unified Survivable Remote Site Telephony is configured for SCCP phones. Nor, may Cisco Unified SIP Proxy coreside in the same router with time division multiplex (TDM) gateways or configuration of H.323 dial peers (including Cisco Unified Border Element). Cisco Unified Communications Manager Express, Cisco Unified Survivable Remote Site Telephony, and Cisco Unified Border Element configured for SIP may coreside in the same router. Other voice and router functions are also available for use in the same router with Cisco Unified SIP Proxy.

Components Used

The example configuration in this document was tested with the software shown in Table 1. The software releases and versions shown in Table 1 represent what was tested and are not the only software that is compatible with Cisco Unified SIP Proxy.

The information in this document was created from the devices in a specific lab environment. All devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Table 1 Cisco Software Tested 

Software
Release or Version

Cisco IOS software hosting
Cisco Unified SIP Proxy

Cisco IOS Release 12.4(22)T with K9 feature set

Cisco Unified SIP Proxy

1.1.3

Cisco IOS software hosting
Cisco Unified Border Element

Cisco IOS Release 12.4(20)T

Cisco Unified Border Element

1.2

Cisco Unified Customer Voice Portal

4.1

Cisco Unified Communications Manager

5.1, 5.1.2, 7.0.1

Cisco IOS software hosting
Cisco Unified Communications Manager Express

Cisco IOS Release 12.4(20)T

Cisco Unified Communications Manager Express

7.0

Cisco Unified Intelligent Contact Management

7.2


Conventions

See Cisco Technical Tips Conventions for information on document conventions.

Configure


Note Use the Command Lookup Tool (registered customers only) and the Cisco IOS Master Command List, Release 12.4T for more information on the Cisco IOS commands used in this document.


Network Diagram

Configuring Network Connectivity

Configuring TLS

Configuring the Cisco Unified SIP Proxy Module

Network Diagram

This document uses the network setup shown in Figure 2, which has two Cisco Unified SIP Proxies in the center. On one side of it, there is a public switched telephone network (PSTN) connected to the Cisco Unified SIP Proxies. On the other side is a cluster of Cisco Unified Communications Managers and a Cisco Unified Communications Manager Express connecting each Cisco Unified SIP Proxy to the enterprise's intranet. All calls go through a cluster of Cisco Unified Border Elements which has separate interfaces for the internal and external networks. In this way, the Cisco Unified Border Elements act as a logical boundary between the public and enterprise networks. Note that in this example all telephone numbers for the enterprise begin with the 510 area code. From inside the enterprise network, users must dial 91 to call the public network.

Figure 2 Sample Network Setup

Configuring Network Connectivity

Attaching the Cisco Unified SIP Proxy to the Cisco ISR

Turning on NETCONF

Entering the Cisco Unified SIP Proxy Module

Booting Up Cisco Unified SIP Proxy for the First Time

Validating the Platform on Bootup

Configuring Virtual Interfaces for Cisco Unified SIP Proxy

Attaching the Cisco Unified SIP Proxy to the Cisco ISR

Figure 3 shows how the network elements attach to the Cisco Unified SIP Proxy and how calls flow through the network.

Calls come from the service provider network to the Cisco Unified SIP Proxy over User Datagram Protocol (UDP).

If the call is destined for the enterprise network, the call is routed to the external interface of one of the Cisco Unified Border Elements over a TLS connection.

The call then goes out the internal interface of the Cisco Unified Border Element and reconnects to Cisco Unified SIP Proxy via another TLS connection.

Finally, a TLS connection is used to route the calls to either the Cisco Unified Communications Manager cluster or the Cisco Unified Communications Manager Express on the enterprise network.

Figure 3 Call Flow Through Cisco Unified SIP Proxy

In this configuration, and throughout this document, the configuration given is the configuration for Cisco Unified SIP Proxy 2 in Figure 3. The configuration for Cisco Unified SIP Proxy 1 must be very similar, although some of the IP addresses can be different.

Connecting the Cisco Unified SIP Proxy into the network is a two-part process because the Cisco Unified SIP Proxy sits on top of a Cisco 3800 Series ISR.

First, you must configure the Cisco ISR to connect to the Cisco Unified SIP Proxy blade sitting in one of the module slots. In this example the Cisco Unified SIP Proxy is in slot 2.

Second, you must configure the Cisco Unified SIP Proxy to connect to the other elements in the network. You must configure four networks for communication between the Cisco ISR and the Cisco Unified SIP Proxy module as shown in Figure 4. The reason that four networks are required is explained in the "Configuring Virtual Interfaces for Cisco Unified SIP Proxy" section. Each of the physical interfaces on the Cisco ISR must be tied to a virtual interface on the module itself. You create these interfaces in the "Configuring Virtual Interfaces for Cisco Unified SIP Proxy" section. Additionally, use a loopback interface for the actual connection to the service module.

Figure 4 Creating Internal Networks on the Cisco ISR

To configure the four networks shown in Figure 4, enter the following commands on the Cisco ISR in Cisco IOS software global configuration mode.

interface Loopback 0
 ip address 10.50.50.10 255.255.255.0
 duplex auto
 speed auto
!
interface GigabitEthernet0/0
 ip address 10.10.10.99 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/1
 ip address 10.10.20.99 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet1/0
 ip address 192.168.10.99 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet1/1
 ip address 192.168.20.99 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface Integrated-Service-Engine2/0
 ip unnumbered Loopback0
 service-module ip address 10.50.50.1 255.255.255.0
 service-module ip default-gateway 10.50.50.10 
!
interface Integrated-Service-Engine2/0.1
 encapsulation dot1Q 1
 ip unnumbered GigabitEthernet0/0
!
interface Integrated-Service-Engine2/0.2
 encapsulation dot1Q 2
 ip unnumbered GigabitEthernet0/1
!
interface Integrated-Service-Engine2/0.3
 encapsulation dot1Q 3
 ip unnumbered GigabitEthernet1/0
!
interface Integrated-Service-Engine2/0.4
 encapsulation dot1Q 4
 ip unnumbered GigabitEthernet1/1
!
ip route 10.50.50.1 255.255.255.255 interface Integrated-Service-Engine2/0
ip route 10.10.10.2 255.255.255.255 interface Integrated-Service-Engine2/0.1
ip route 10.10.20.2 255.255.255.255 interface Integrated-Service-Engine2/0.2
ip route 192.168.10.2 255.255.255.255 interface Integrated-Service-Engine2/0.3
ip route 192.168.20.2 255.255.255.255 interface Integrated-Service-Engine2/0.4

Turning on NETCONF

Cisco Unified SIP Proxy performs basic platform validation when it boots up. This validation is performed using the Network Configuration Protocol (NETCONF) over Secure Shell (SSH). Therefore, both the NETCONF feature in Cisco IOS software and the SSH protocol must be enabled.

For information about how to turn on SSH, see Configuring Secure Shell on Routers and Switches Running Cisco IOS.

To turn on NETCONF, enter this command on the Cisco ISR in Cisco IOS software global configuration mode:

netconf ssh
 
   

For more information on the validation feature, including possible failure reasons, see the "Validating the Platform on Bootup" section and the "Troubleshoot" section. If the module fails to boot up because of a validation failure, the following message appears:

Validating host platform ........ [FAILED]

Entering the Cisco Unified SIP Proxy Module

Enter the service-module (the Cisco Unified SIP Proxy module) using the following command:

service-module integrated-Service-Engine 2/0 session
 
   

If this is the first time that the module is booted up, continue to the next section "Booting Up Cisco Unified SIP Proxy for the First Time" for more information. If this is not the first time that the module is booted up, continue to the "Configuring Virtual Interfaces for Cisco Unified SIP Proxy" section.

Booting Up Cisco Unified SIP Proxy for the First Time

The first time Cisco Unified SIP Proxy is booted up, you are prompted for information about your Cisco Unified SIP Proxy. The first prompt is for the license SKU. See your packing slip, invoice, or order confirmation for your SKU. After confirming the license, you are asked if you want to configure the module. Answer yes. Answer the questions that follow which include questions about time zone, NTP servers, and other details about your configuration.

Validating the Platform on Bootup

Each time the Cisco Unified SIP Proxy module boots up, it performs basic platform validation by checking the running configuration. Table 2 shows the rules you must verify before the system continues booting up.

Table 2 Platform Validation Rules 

Rule
Configuration Line

Must exist

interface integrated-service-engine slot/port
 service-module ip address nm-side-ip-addr subnet-mask
 service-module ip default-gateway gw-ip-addr

Must not exist

dial-peer voice tag voip
 session protocol default

Must not exist

ephone phone-tag

Must not exist

voice-port platform-specific-information

For the first rule, the default gateway address must match the address of one of the local addresses of the Cisco ISR. Failure to turn on NETCONF or meet the first condition results in the following message:

Error: Failed to connect to host platform
 
   

Failure to meet any other rule results in the following message:

Violation: CONFIGURATION LINE
 
   

Remove the erroneous configuration lines to enable Cisco Unified SIP Proxy to boot up.

Configuring Virtual Interfaces for Cisco Unified SIP Proxy

Cisco Unified SIP Proxy must have four interfaces configured for this example. One interface each is dedicated to the PSTN and the enterprise network. In addition, one interface is dedicated to the internal and external side of each Cisco Unified Border Element. In Figure 3, the interfaces on the left (public) side of the network have public addresses, and interfaces on the right (enterprise) side have private addresses. To configure these interfaces, enter these commands in network module configuration mode.

interface GigabitEthernet 0.1         ! Connection to service provider
 ip address 10.10.10.2 255.255.255.0
 end interface
 
   
interface GigabitEthernet 0.2         ! Connection to Cisco Unified Border Element stack 
 ip address 10.10.20.2 255.255.255.0    (Public side)
 end interface
 
   
interface GigabitEthernet 0.3          ! Connection to Cisco Unified Border Element stack 
 ip address 192.168.20.2  255.255.255.0  (Enterprise side)
 end interface
 
   
interface GigabitEthernet 0.4          ! Connection to Enterprise network
 ip address 192.168.10.2 255.255.255.0
 end interface

When using multiple interfaces, the Cisco Unified SIP Proxy module needs to be configured with static IP routes to ensure that IP packets are routed across the correct interfaces.

 
   
netmod(config)#ip route 10.10.10.0 255.255.255.0 GigabitEthernet 0.1
netmod(config)#ip route 10.10.20.0 255.255.255.0 GigabitEthernet 0.2
netmod(config)#ip route 192.168.10.0 255.255.255.0 GigabitEthernet 0.3
netmod(config)#ip route 192.168.20.0 255.255.255.0 GigabitEthernet 0.4

Configuring TLS

Creating and Importing a Signed Certificate

Configuring TLS on Cisco Unified SIP Proxy

Creating and Importing a Signed Certificate

Cisco Unified SIP Proxy supports TLS, Transmission Control Protocol (TCP), and UDP, however in this configuration most of the connections between the elements in this example are made using TLS. Establishing TLS connections requires some extra steps because they require authentication using signed certificates. Cisco Unified SIP Proxy provides a way to export certificate requests and import the signed certificates. You need an FTP server or HTTP to export certificate requests. Enter these commands in network module configuration mode.

Procedure


Step 1 To set up the keystore, first create an RSA private key:

crypto key generate rsa label mykey modulus 512 default 
Key generation in progress. Please wait...
The label name for the key is mykey
 
   

Step 2 Create a certificate request to be signed:

crypto key certreq label mykey url ftp: 
Address or name of remote host? 192.168.202.216
Username (ENTER if none)? anonymous
Password (not shown)?
Destination path? netmod/mykey.csr
Uploading CSR file succeed
 
   

Step 3 After the certificate request is signed, import the trusted certificate authority (CA) certificate that you used to sign the request:

crypto key import trustcacert label rootCA url ftp: 
Import certificate file...
Address or name of remote host? 192.168.202.216
Source filename? netmod/rootCA/cacert.pem
1212 bytes received.
 
   

Step 4 After the root CA is imported, import the signed certificate:

crypto key import cer label mykey url ftp: 
Import certificate file...
Address or name of remote host? 192.168.202.216
Source filename? netmod/mycert.cer
952 bytes received.
Import succeeded
 
   

Step 5 Import the trusted CA certificates for any of the TLS peer elements.


Configuring TLS on Cisco Unified SIP Proxy

After you import the certificates, you must enable TLS connections. If you want more security, you can create a list of trusted peers. If you create such a list, only connections from those peers are accepted. The peer's hostname entry must be the peer's subjectAltname in its certificate. If subjectAltName is not used in the certificate, the peer's hostname entry must be CN. Enter these commands in network module EXEC mode:

netmod> cusp
netmod(cusp)> configure
netmod(cusp-config)> sip tls 
netmod(cusp-config)> sip tls trusted-peer {peer's-hostname} ! This command is optional

Configuring the Cisco Unified SIP Proxy Module

Configuring Logical Networks

Configuring Trigger Conditions

Configuring Server Groups

Configuring Route Tables

Configuring Normalization Policies

Configuring Lookup Policies

Configuring Routing Triggers

Committing the Configuration

Configuring Normalization Triggers

Configuring Listen and Record-Route Ports

Configuring a Hostname (Optional)

Enter all the commands in this section in Cisco Unified SIP Proxy configuration mode. To enter Cisco Unified SIP Proxy configuration mode, enter these commands in network module EXEC mode:

netmod> cusp
netmod(cusp)> configure
 
   

For detailed information about Cisco Unified SIP Proxy command modes and commands, see the Cisco Unified SIP Proxy Command Reference.

Send your questions concerning configuration in Cisco Unified SIP Proxy configuration mode and any of its submodes to ask-cusp-config@external.cisco.com.

Configuring Logical Networks

Each interface on the Cisco Unified SIP Proxy is associated with a logical network. Logical networks are used to organize server groups, listen points, and other properties. SIP messages are associated with the network on which they arrive. To configure logical networks for this example, enter the following commands:

netmod(cusp-config)> sip network service-provider
netmod(cusp-config-network)> end network
 
   
netmod(cusp-config)> sip network cube-sp
netmod(cusp-config-network)> end network
 
   
netmod(cusp-config)> sip network cube-es 
netmod(cusp-config-network)> end network
 
   
netmod(cusp-config)> sip network enterprise
netmod(cusp-config-network)> end network

Configuring Trigger Conditions

Trigger conditions are created that allow the Cisco Unified SIP Proxy to respond with the appropriate action for various call flows. In general, the more complex the call flows required the more complex the triggers must be. In this example, Cisco Unified SIP Proxy only reacts based on the network the call came in on, so the triggers are simple. The mid-dialog trigger is a special trigger you use to bypass routing policies on mid-dialog messages. To configure trigger conditions, enter the following commands:

netmod(cusp-config)> trigger condition call-from-service-provider 
netmod(cusp-config-trigger)> sequence 1
netmod(cusp-config-trigger-seq)> in-network service-provider
netmod(cusp-config-trigger-seq)> end sequence
netmod(cusp-config-trigger)> end trigger condition
 
   
netmod(cusp-config)> trigger condition call-from-cube-sp 
netmod(cusp-config-trigger)> sequence 1
netmod(cusp-config-trigger-seq)> in-network cube-sp
netmod(cusp-config-trigger-seq)> end sequence
netmod(cusp-config-trigger)> end trigger condition
 
   
netmod(cusp-config)> trigger condition call-from-cube-es 
netmod(cusp-config-trigger)> sequence 1
netmod(cusp-config-trigger-seq)> in-network cube-es
netmod(cusp-config-trigger-seq)> end sequence
netmod(cusp-config-trigger)> end trigger condition
 
   
netmod(cusp-config)> trigger condition call-from-enterprise 
netmod(cusp-config-trigger)> sequence 1
netmod(cusp-config-trigger-seq)> in-network enterprise
netmod(cusp-config-trigger-seq)> end sequence
netmod(cusp-config-trigger)> end trigger condition
 
   
netmod(cusp-config)> trigger condition mid-dialog 
netmod(cusp-config-trigger)> sequence 1
netmod(cusp-config-trigger-seq)> mid-dialog
netmod(cusp-config-trigger-seq)> end sequence
netmod(cusp-config-trigger)> end trigger condition

Configuring Server Groups

Server groups define the elements that Cisco Unified SIP Proxy interacts with for each network. In this example, the sp.example.com server-group has the service provider network address. The cube-es.example.com and cube-sp.example.com server groups have the internal and external addresses of the Cisco Unified Border Element elements. The cucm.example.com server group has the addresses of the Cisco Unified Communications Managers in a cluster. The cme.example.com server group has the address of the Cisco Unified Communications Manager Express.

Two of the fields for each individual element, q-value and weight, are important to use to specify the priorities of elements, and also for load-balancing. Calls are routed to specific elements based on q-value. The element with the highest q-value receives all traffic routed to that server group. If multiple elements have the same q-value, then traffic is distributed between them based on the load-balancing option used. The default load-balancing is based on call-id, but weight can also be used. If weight is used, the percentage of traffic that an element receives is equal to its weight divided by the sum of up elements with the same q-value's weights. The sum of their weights does not need to equal 100. In the following configuration this means that one of the elements in the cucm.example.com server group receives 50 percent of the traffic; the other two elements receive 25 percent. You can change the weights and q-values to configure a different priority or load-balancing scheme. To configure server groups for this example, enter the following commands:

netmod(cusp-config)> server-group sip group sp.example.com service-provider
netmod(cusp-config-sg)> element ip-address 10.10.10.3 5060 udp q-value 1.0
netmod(cusp-config-sg)> end server-group
 
   
netmod(cusp-config)> server-group sip group cube-sp.example.com cube-sp
netmod(cusp-config-sg)> element ip-address 10.10.20.3 5060 tls q-value 1.0
netmod(cusp-config-sg)> element ip-address 10.10.20.4 5060 tls q-value 1.0 
netmod(cusp-config-sg)> end server-group
 
   
netmod(cusp-config)> server-group sip group cube-es.example.com cube-es
netmod(cusp-config-sg)> element ip-address 192.168.20.3 5060 tls q-value 1.0
netmod(cusp-config-sg)> element ip-address 192.168.20.4 5060 tls q-value 1.0
netmod(cusp-config-sg)> end server-group
 
   
netmod(cusp-config)> server-group sip group cucm.example.com enterprise
netmod(cusp-config-sg)> element ip-address 192.168.10.3 5060 tls q-value 1.0 weight 100
netmod(cusp-config-sg)> element ip-address 192.168.10.4 5060 tls q-value 1.0 weight 50
netmod(cusp-config-sg)> element ip-address 192.168.10.5 5060 tls q-value 1.0 weight 50
netmod(cusp-config-sg)> lbtype weight
netmod(cusp-config-sg)> end server-group
 
   
netmod(cusp-config)> server-group sip group cme.example.com enterprise
netmod(cusp-config-sg)> element ip-address 192.168.10.6 5060 tls q-value 1.0 
netmod(cusp-config-sg)> end server-group

Configuring Route Tables

You must configure route tables to direct SIP requests to their appropriate destinations. Each route table consists of a set of keys that are matched based on the lookup policy. In this example, each key represents the prefix of the phone number dialed. The service-provider-table is designed to respond to calls with a 404 message (not found) unless the phone number dialed begins with the 510 area code. In the following configuration, all numbers for the enterprise are of the form 510-XXX-XXXX. The enterprise-table is designed to respond to calls with a 404 message (not found) unless the phone number dialed begins with the 510 area code or the escape sequence (91) is dialed. Calls with phone numbers that begin with 5101 are routed to the Cisco Unified Communications Manager Express. Calls with a phone number that begins with 510 are routed to the Cisco Unified Communications Manager. Calls with phone numbers that begin with 91 are routed to Cisco Unified Border Element. To configure route tables for this example, enter the following commands:

netmod(cusp-config)> route table service-provider-table
netmod(cusp-config-rt)> key * response 404
netmod(cusp-config-rt)> key 510 target-destination cube-sp.example.com cube-sp
netmod(cusp-config-rt)> end route table
 
   
netmod(cusp-config)> route table cube-sp-table
netmod(cusp-config-rt)> key * target-destination sp.example.com service-provider
netmod(cusp-config-rt)> end route table
 
   
netmod(cusp-config)> route table cube-es-table
netmod(cusp-config-rt)> key * response 404
netmod(cusp-config-rt)> key 5101 target-destination cme.example.com enterprise
netmod(cusp-config-rt)> key 510 target-destination cucm.example.com enterprise
netmod(cusp-config-rt)> end route table
 
   
netmod(cusp-config)> route table enterprise-table
netmod(cusp-config-rt)> key * response 404
netmod(cusp-config-rt)> key 5101 target-destination cme.example.com enterprise
netmod(cusp-config-rt)> key 510 target-destination cucm.example.com enterprise
netmod(cusp-config-rt)> key 91 target-destination cube-es.example.com cube-es
netmod(cusp-config-rt)> end route table

Configuring Normalization Policies

Normalization policies modify SIP messages to account for incompatibilities between networks. In this case, the service provider cannot handle phone numbers with the escape sequence "91," so the sequence must be removed from the request-uri and TO header. To configure normalization policies for this example, enter the following commands:

netmod(cusp-config)> policy normalization outgoing-norm-policy
netmod(cusp-config-norm)> uri-component update request-uri user ^91 ""
netmod(cusp-config-norm)> uri-component update TO all user ^91 ""
netmod(cusp-config-norm)> end policy

Configuring Lookup Policies

Lookup policies decide how the keys in the route tables are used. Each key represents the beginning of the phone number dialed because each policy states to match the user component of the request-uri against the keys in its route table. The user component of the request-uri is the phone number called. The rule used to match is prefix, which means that the longest prefix match in the route table is used. So if the dialed number is 510-1XX-XXXX, the call is sent to the cme.example.com server group. If the dialed number is 510-XXX-XXXX, the call is sent to the cucm.example.com server group. The four policies in the following example are identical, except that they each refer to their specific table. To configure lookup policies for this example, enter the following commands:

netmod(cusp-config)> policy lookup service-provider-policy
netmod(cusp-config-lookup)> sequence 1 service-provider-table request-uri uri-component 
user
netmod(cusp-config-lookup-seq)> rule prefix
netmod(cusp-config-lookup-seq)> end sequence
netmod(cusp-config-lookup)> end policy
 
   
netmod(cusp-config)> policy lookup cube-sp-policy
netmod(cusp-config-lookup)> sequence 1 cube-sp-table request-uri uri-component user
netmod(cusp-config-lookup-seq)> rule prefix
netmod(cusp-config-lookup-seq)> end sequence
netmod(cusp-config-lookup)> end policy
 
   
netmod(cusp-config)> policy lookup cube-es-policy
netmod(cusp-config-lookup)> sequence 1 cube-es-table request-uri uri-component user
netmod(cusp-config-lookup-seq)> rule prefix
netmod(cusp-config-lookup-seq)> end sequence
netmod(cusp-config-lookup)> end policy
 
   
netmod(cusp-config)> policy lookup enterprise-policy
netmod(cusp-config-lookup)> sequence 1 enterprise-table request-uri uri-component user
netmod(cusp-config-lookup-seq)> rule prefix
netmod(cusp-config-lookup-seq)> end sequence
netmod(cusp-config-lookup)> end policy

Committing the Configuration

Now you must commit the configuration. Committing the configuration serves two purposes: the configuration becomes active, and is persisted.

To see the current active configuration, enter the show configuration active command.

To see what the active configuration will be after you commit your changes, enter the show configuration candidate command.

To commit the configuration for this example, enter the following command:

netmod(cusp-config)> commit

Configuring Routing Triggers

Routing triggers correlate trigger conditions with lookup policies. A single policy is chosen based on which corresponding condition is matched. 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. Based on the following configuration, after the INVITE message is successfully routed, all subsequent messages (which are mid-dialog) bypass routing policies. To configure routing triggers for this example, enter the following commands:

netmod(cusp-config)> trigger routing sequence 1 by-pass condition mid-dialog
 
   
netmod(cusp-config)> trigger routing sequence 2 policy service-provider-policy condition 
call-from-service-provider
 
   
netmod(cusp-config)> trigger routing sequence 3 policy cube-sp-policy condition 
call-from-cube-sp
 
   
netmod(cusp-config)> trigger routing sequence 4 policy cube-es-policy condition 
call-from-cube-es
 
   
netmod(cusp-config)> trigger routing sequence 5 policy enterprise-policy condition 
call-from-enterprise

Configuring Normalization Triggers

Normalization triggers correlate trigger conditions with normalization policies. There are two types of triggers: pre-normalization, which occurs before routing, and post-normalization, which occurs after routing. In this case, the outgoing-norm-policy is being invoked on all calls going to the service-provider network. An "outgoing" policy is invoked on calls leaving the enterprise network. Similarly to routing-policies, a special policy bypasses normalization on mid-dialog messages. To configure normalization triggers for this example, enter the following commands:

netmod(cusp-config)> trigger pre-normalization sequence 1 by-pass condition mid-dialog
netmod(cusp-config)> trigger pre-normalization sequence 2 policy outgoing-norm-policy 
condition call-from-cube-sp

Configuring Listen and Record-Route Ports

You must configure listen and record-route ports for each network. For the listen and record-route ports, the actual addresses of the Cisco Unified SIP Proxy module are used. The sip record-route command inserts the record-route header into outgoing requests. The sip listen command allows for Cisco Unified SIP Proxy to accept incoming requests on that port.


Note The IP addresses used in the listen and record-route commands are the IP addresses configured within the Cisco Unified SIP Proxy module.


To configure listen and record-route ports for this example, enter the following commands:

netmod(cusp-config)> sip record-route service-provider udp 10.10.10.2 5060
netmod(cusp-config)> sip record-route cube-sp tls 10.10.20.2 5060
netmod(cusp-config)> sip record-route cube-es tls 192.168.20.2 5060
netmod(cusp-config)> sip record-route enterprise tls 192.168.10.2 5060
 
   
netmod(cusp-config)> sip listen service-provider udp 10.10.10.2 5060
netmod(cusp-config)> sip listen cube-sp tls 10.10.20.2 5060
netmod(cusp-config)> sip listen cube-es tls 192.168.20.2 5060
netmod(cusp-config)> sip listen enterprise tls 192.168.10.2 5060

Configuring a Hostname (Optional)

If the upstream element is using DNS SRV for routing to the two Cisco Unified SIP Proxies in a network such as this example, you must configure the two Cisco Unified SIP Proxies to have the same fully qualified domain name (FQDN) by entering the following command in Cisco Unified SIP Proxy configuration mode on both Cisco Unified SIP Proxies:

netmod(cusp-config)> sip alias hostname

Configuration

This example uses the following configuration:

netmod(cusp-config)> show configuration active
Building CUSP configuration...
!
server-group sip global-load-balance call-id
server-group sip retry-after 0
server-group sip element-retries udp 3
server-group sip element-retries tls 1
server-group sip element-retries tcp 1
sip alias myhostname
sip dns-srv
 enable
 no naptr
 end dns
!
no sip header-compaction
no sip logging
!
sip max-forwards 70
sip network cube-es standard
 no non-invite-provisional
 allow-connections
 retransmit-count invite-server-transaction 9
 retransmit-count non-invite-client-transaction 9
 retransmit-count invite-client-transaction 5
 retransmit-timer clientTn 64000
 retransmit-timer serverTn 64000
 retransmit-timer T4 5000
 retransmit-timer T2 4000
 retransmit-timer T1 500
 retransmit-timer TU2 32000
 retransmit-timer TU1 5000
 end network
!
sip network cube-sp standard
 no non-invite-provisional
 allow-connections
 retransmit-count invite-server-transaction 9
 retransmit-count invite-client-transaction 5
 retransmit-count non-invite-client-transaction 9
 retransmit-timer T4 5000
 retransmit-timer T2 4000
 retransmit-timer T1 500
 retransmit-timer TU2 32000
 retransmit-timer TU1 5000
 retransmit-timer clientTn 64000
 retransmit-timer serverTn 64000
 end network
!
sip network enterprise standard
 no non-invite-provisional
 allow-connections
 retransmit-count invite-client-transaction 5
 retransmit-count invite-server-transaction 9
 retransmit-count non-invite-client-transaction 9
 retransmit-timer serverTn 64000
 retransmit-timer T4 5000
 retransmit-timer T2 4000
 retransmit-timer T1 500
 retransmit-timer TU2 32000
 retransmit-timer TU1 5000
 retransmit-timer clientTn 64000
 end network
!
sip network service-provider standard
 no non-invite-provisional
 allow-connections
 retransmit-count invite-server-transaction 9
 retransmit-count non-invite-client-transaction 9
 retransmit-count invite-client-transaction 5
 retransmit-timer serverTn 64000
 retransmit-timer TU1 5000
 retransmit-timer TU2 32000
 retransmit-timer T1 500
 retransmit-timer T2 4000
 retransmit-timer T4 5000
 retransmit-timer clientTn 64000
 end network
!
sip overload reject retry-after 0
!
no sip peg-counting
!
sip privacy service
sip queue message
 drop-policy head
 low-threshold 80
 size 2000
 thread-count 20
 end queue
!
sip queue radius
 drop-policy head
 low-threshold 80
 size 2000
 thread-count 20
 end queue
!
sip queue request
 drop-policy head
 low-threshold 80
 size 2000
 thread-count 20
 end queue
!
sip queue response
 drop-policy head
 low-threshold 80
 size 2000
 thread-count 20
 end queue
!
sip queue st-callback
 drop-policy head
 low-threshold 80
 size 2000
 thread-count 10
 end queue
!
sip queue timer
 drop-policy none
 low-threshold 80
 size 2500
 thread-count 8
 end queue
!
sip queue xcl
 drop-policy head
 low-threshold 80
 size 2000
 thread-count 2
 end queue
!
route recursion
!
sip tcp connection-timeout 240
sip tcp max-connections 256
sip tls
!
trigger condition call-from-cube-es
 sequence 1
  in-network cube-es
  end sequence
 end trigger condition
!
trigger condition call-from-cube-sp
 sequence 1
  in-network cube-sp
  end sequence
 end trigger condition
!
trigger condition call-from-enterprise
 sequence 1
  in-network enterprise
  end sequence
 end trigger condition
!
trigger condition call-from-service-provider
 sequence 1
  in-network service-provider
  end sequence
 end trigger condition
!
trigger condition mid-dialog
 sequence 1
  mid-dialog
  end sequence
 end trigger condition
!
accounting
 no enable
 no client-side
 no server-side
 end accounting
!
server-group sip group cme.example.com enterprise
 element ip-address 192.168.10.6 5060 tls q-value 1.0 weight 0
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!
server-group sip group cube-es.example.com cube-es
 element ip-address 192.168.20.4 5060 tls q-value 1.0 weight 0
 element ip-address 192.168.20.3 5060 tls q-value 1.0 weight 0
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!
server-group sip group cube-sp.example.com cube-sp
 element ip-address 10.10.20.3 5060 tls q-value 1.0 weight 0
 element ip-address 10.10.20.4 5060 tls q-value 1.0 weight 0
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!
server-group sip group cucm.example.com enterprise
 element ip-address 192.168.10.4 5060 tls q-value 1.0 weight 50
 element ip-address 192.168.10.5 5060 tls q-value 1.0 weight 50
 element ip-address 192.168.10.3 5060 tls q-value 1.0 weight 100
 failover-resp-codes 503
 lbtype weight
 ping
 end server-group
!
server-group sip group sp.example.com service-provider
 element ip-address 10.10.10.3 5060 udp q-value 1.0 weight 0
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!
route table cube-es-table
 key * response 404
 key 5101 target-destination cme.example.com enterprise
 key 510 target-destination cucm.example.com enterprise
 end route table
!
route table cube-sp-table
 key * target-destination sp.example.com service-provider
 end route table
!
route table enterprise-table
 key * response 404
 key 5101 target-destination cme.example.com enterprise
 key 91 target-destination cube-es.example.com cube-es
 key 510 target-destination cucm.example.com enterprise
 end route table
!
route table service-provider-table
 key * response 404
 key 510 target-destination cube-sp.example.com cube-sp
 end route table
!
policy normalization outgoing-norm-policy
 uri-component update TO all user ^91 ""
 uri-component update request-uri user ^91 ""
 end policy
!
policy lookup cube-es-policy
 sequence 1 cube-es-table request-uri uri-component user
  rule prefix
  end sequence
 end policy
!
policy lookup cube-sp-policy
 sequence 1 cube-sp-table request-uri uri-component user
  rule prefix
  end sequence
 end policy
!
policy lookup enterprise-policy
 sequence 1 enterprise-table request-uri uri-component user
  rule prefix
  end sequence
 end policy
!
policy lookup service-provider-policy
 sequence 1 service-provider-table request-uri uri-component user
  rule prefix
  end sequence
 end policy
!
trigger routing sequence 5 policy enterprise-policy condition call-from-enterpri
se
trigger routing sequence 4 policy cube-es-policy condition call-from-cube-es
trigger routing sequence 3 policy cube-sp-policy condition call-from-cube-sp
trigger routing sequence 2 policy service-provider-policy condition 
call-from-service-provider
trigger routing sequence 1 by-pass condition mid-dialog
trigger pre-normalization sequence 2 policy outgoing-norm-policy condition 
call-from-cube-sp
trigger pre-normalization sequence 1 by-pass condition mid-dialog
!
no server-group sip global-ping
!
sip listen service-provider udp 10.10.10.99 5060
sip listen cube-sp tls 10.10.20.99 5060
sip listen cube-es tls 192.168.20.99 5060
sip listen enterprise tls 192.168.10.99 5060
!
sip record-route cube-es tls 192.168.20.99 5060
sip record-route service-provider udp 10.10.10.99 5060
sip record-route cube-sp tls 10.10.20.99 5060
sip record-route enterprise tls 192.168.10.99 5060
!
end
netmod(cusp-config)>

Verify

Use the show configuration active command to verify that your Cisco Unified SIP Proxy configuration works properly.

For more information on this command, see the Cisco Unified SIP Proxy Command Reference.

Troubleshoot

Troubleshooting Procedure

Troubleshooting Commands

Troubleshooting Procedure

Cisco Unified SIP Proxy performs basic platform validation when it boots up. If the Cisco Unified SIP Proxy module fails to boot up because of a validation failure, the following message appears:

Validating host platform ........ [FAILED]
 
   

Following this message, a more specific message points to a specific line in the Cisco IOS software configuration that must be changed or removed. For example, having any of the following lines in the running configuration causes validation to fail:

dial-peer voice tag voip
 session protocol default
 
   
ephone phone-tag
 
   
voice-port platform-specific-information
 
   

See the "Product Compatibility" section for information about products and configurations that are invalid for use with Cisco Unified SIP Proxy. See the "Validating the Platform on Bootup" section for more information on validation errors.

Troubleshooting Commands

Use the following commands to troubleshoot your Cisco Unified SIP Proxy configuration:

show status queue

show status server-group radius [server-group-name]

show status server-group sip [server-group-name]

show status sip

For more information on these commands, see the Cisco Unified SIP Proxy Command Reference.

Related Information

Cisco Unified SIP Proxy Command Reference

Configuring Secure Shell on Routers and Switches Running Cisco IOS

Support- Cisco Systems