Table Of Contents
Configuring Cisco Unified SIP Proxy Version 1.1.2 for an Enterprise Network
Configuring Network Connectivity
Attaching the Cisco Unified SIP Proxy to the Cisco ISR
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
Creating and Importing a Signed Certificate
Configuring TLS on Cisco Unified SIP Proxy
Configuring the Cisco Unified SIP Proxy Module
Configuring Trigger Conditions
Configuring Normalization Policies
Configuring Normalization Triggers
Configuring Listen and Record-Route Ports
Configuring a Hostname (Optional)
Configuring Cisco Unified SIP Proxy Version 1.1.2 for an Enterprise Network
First Published: February 11, 2009
Last Updated: June 2, 2009Contents
Configuring Network Connectivity
Configuring the Cisco Unified SIP Proxy Module
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:
http://www.cisco.com/en/US/docs/voice_ip_comm/cusp/rel1_0/command/reference/cuspcmdref_Book.html
Prerequisites
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
•
–
–
–
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.
Conventions
See Cisco Technical Tips Conventions for information on document conventions.
Configure
This section describes the information you need to configure the features described in this document.
Note
•
•
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
This section contains the following procedures:
•
•
•
•
•
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.
•
•
•
•
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.
•
•
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 0ip address 10.50.50.10 255.255.255.0duplex autospeed auto!interface GigabitEthernet0/0ip address 10.10.10.99 255.255.255.0duplex autospeed automedia-type rj45!interface GigabitEthernet0/1ip address 10.10.20.99 255.255.255.0duplex autospeed automedia-type rj45!interface GigabitEthernet1/0ip address 192.168.10.99 255.255.255.0duplex autospeed automedia-type rj45!interface GigabitEthernet1/1ip address 192.168.20.99 255.255.255.0duplex autospeed automedia-type rj45!interface Integrated-Service-Engine2/0ip unnumbered Loopback0service-module ip address 10.50.50.1 255.255.255.0service-module ip default-gateway 10.50.50.10!interface Integrated-Service-Engine2/0.1encapsulation dot1Q 1 nativeip unnumbered GigabitEthernet0/0!interface Integrated-Service-Engine2/0.2encapsulation dot1Q 2 nativeip unnumbered GigabitEthernet0/1!interface Integrated-Service-Engine2/0.3encapsulation dot1Q 3 nativeip unnumbered GigabitEthernet1/0!interface Integrated-Service-Engine2/0.4encapsulation dot1Q 4 nativeip unnumbered GigabitEthernet1/1!ip route 10.50.50.1 255.255.255.255 interface Integrated-Service-Engine2/0ip route 10.10.10.99 255.255.255.255 interface Integrated-Service-Engine2/0.1ip route 10.10.20.99 255.255.255.255 interface Integrated-Service-Engine2/0.2ip route 192.168.10.99 255.255.255.255 interface Integrated-Service-Engine2/0.3ip route 192.168.20.99 255.255.255.255 interface Integrated-Service-Engine2/0.4Turning on NETCONF
Cisco Unified SIP Proxy performs basic platform validation when it boots up. In order for this validation to pass, the Network Configuration Protocol (NETCONF) feature in Cisco IOS software must be enabled. To turn on NETCONF, enter these commands on the Cisco ISR in Cisco IOS software global configuration mode.
!sasl profile SASLmechanism anonymous!netconf beep listener 831 sasl SASLIn Cisco IOS software, a NETCONF over Blocks Extensible Exchange Protocol (BEEP) configuration allows you to enter any port. The network module side is hardcoded to use port 831, the Internet Assigned Numbers Authority (IANA) standard port for NETCONF over BEEP, so Cisco IOS software must be configured to use it too.
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:
interface Integrated-Service-Engine2/0 sessionIf 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.
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 platformFailure to meet any other rule results in the following message:
Violation: CONFIGURATION LINERemove 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 providerip address 10.10.10.2 255.255.255.0end interfaceinterface GigabitEthernet 0.2 ! Connection to Cisco Unified Border Element stackip address 10.10.20.2 255.255.255.0 (Public side)end interfaceinterface GigabitEthernet 0.3 ! Connection to Cisco Unified Border Element stackip address 192.168.20.2 255.255.255.0 (Enterprise side)end interfaceinterface GigabitEthernet 0.4 ! Connection to Enterprise networkip address 192.168.10.2 255.255.255.0end interfaceConfiguring TLS
This section contains the following procedures:
•
•
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.
Step 1
crypto key generate rsa label mykey modulus 512 defaultKey generation in progress. Please wait...The label name for the key is mykeyStep 2
crypto key certreq label mykey url ftp:Address or name of remote host? 192.168.202.216Username (ENTER if none)? anonymousPassword (not shown)?Destination path? netmod/mykey.csrUploading CSR file succeedStep 3
crypto key import trustcacert label rootCA url ftp:Import certificate file...Address or name of remote host? 192.168.202.216Source filename? netmod/rootCA/cacert.pem1212 bytes received.Step 4
crypto key import cer label mykey url ftp:Import certificate file...Address or name of remote host? 192.168.202.216Source filename? netmod/mycert.cer952 bytes received.Import succeededStep 5
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> cuspnetmod(cusp)> configurenetmod(cusp-config)> sip tlsnetmod(cusp-config)> sip tls trusted-peer {peer's-hostname} ! This command is optionalConfiguring the Cisco Unified SIP Proxy Module
This section contains the following procedures:
•
•
•
•
•
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> cuspnetmod(cusp)> configureFor detailed information about Cisco Unified SIP Proxy command modes and commands, see the Cisco Unified SIP Proxy Command Reference:
http://www.cisco.com/en/US/docs/voice_ip_comm/cusp/rel1_0/command/reference/cuspcmdref_Book.html
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-providernetmod(cusp-config-network)> end networknetmod(cusp-config)> sip network cube-spnetmod(cusp-config-network)> end networknetmod(cusp-config)> sip network cube-esnetmod(cusp-config-network)> end networknetmod(cusp-config)> sip network enterprisenetmod(cusp-config-network)> end networkConfiguring 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-providernetmod(cusp-config-trigger)> sequence 1netmod(cusp-config-trigger-seq)> in-network service-providernetmod(cusp-config-trigger-seq)> end sequencenetmod(cusp-config-trigger)> end trigger conditionnetmod(cusp-config)> trigger condition call-from-cube-spnetmod(cusp-config-trigger)> sequence 1netmod(cusp-config-trigger-seq)> in-network cube-spnetmod(cusp-config-trigger-seq)> end sequencenetmod(cusp-config-trigger)> end trigger conditionnetmod(cusp-config)> trigger condition call-from-cube-esnetmod(cusp-config-trigger)> sequence 1netmod(cusp-config-trigger-seq)> in-network cube-esnetmod(cusp-config-trigger-seq)> end sequencenetmod(cusp-config-trigger)> end trigger conditionnetmod(cusp-config)> trigger condition call-from-enterprisenetmod(cusp-config-trigger)> sequence 1netmod(cusp-config-trigger-seq)> in-network enterprisenetmod(cusp-config-trigger-seq)> end sequencenetmod(cusp-config-trigger)> end trigger conditionnetmod(cusp-config)> trigger condition mid-dialognetmod(cusp-config-trigger)> sequence 1netmod(cusp-config-trigger-seq)> mid-dialognetmod(cusp-config-trigger-seq)> end sequencenetmod(cusp-config-trigger)> end trigger conditionConfiguring 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-providernetmod(cusp-config-sg)> element ip-address 10.10.10.3 5060 udp q-value 1.0netmod(cusp-config-sg)> end server-groupnetmod(cusp-config)> server-group sip group cube-sp.example.com cube-spnetmod(cusp-config-sg)> element ip-address 10.10.20.3 5060 tls q-value 1.0netmod(cusp-config-sg)> element ip-address 10.10.20.4 5060 tls q-value 1.0netmod(cusp-config-sg)> end server-groupnetmod(cusp-config)> server-group sip group cube-es.example.com cube-esnetmod(cusp-config-sg)> element ip-address 192.168.20.3 5060 tls q-value 1.0netmod(cusp-config-sg)> element ip-address 192.168.20.4 5060 tls q-value 1.0netmod(cusp-config-sg)> end server-groupnetmod(cusp-config)> server-group sip group cucm.example.com enterprisenetmod(cusp-config-sg)> element ip-address 192.168.10.3 5060 tls q-value 1.0 weight 100netmod(cusp-config-sg)> element ip-address 192.168.10.4 5060 tls q-value 1.0 weight 50netmod(cusp-config-sg)> element ip-address 192.168.10.5 5060 tls q-value 1.0 weight 50netmod(cusp-config-sg)> lbtype weightnetmod(cusp-config-sg)> end server-groupnetmod(cusp-config)> server-group sip group cme.example.com enterprisenetmod(cusp-config-sg)> element ip-address 192.168.10.6 5060 tls q-value 1.0netmod(cusp-config-sg)> end server-groupConfiguring 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-tablenetmod(cusp-config-rt)> key * response 404netmod(cusp-config-rt)> key 510 target-destination cube-sp.example.com cube-spnetmod(cusp-config-rt)> end route tablenetmod(cusp-config)> route table cube-sp-tablenetmod(cusp-config-rt)> key * target-destination sp.example.com service-providernetmod(cusp-config-rt)> end route tablenetmod(cusp-config)> route table cube-es-tablenetmod(cusp-config-rt)> key * response 404netmod(cusp-config-rt)> key 5101 target-destination cme.example.com enterprisenetmod(cusp-config-rt)> key 510 target-destination cucm.example.com enterprisenetmod(cusp-config-rt)> end route tablenetmod(cusp-config)> route table enterprise-tablenetmod(cusp-config-rt)> key * response 404netmod(cusp-config-rt)> key 5101 target-destination cme.example.com enterprisenetmod(cusp-config-rt)> key 510 target-destination cucm.example.com enterprisenetmod(cusp-config-rt)> key 91 target-destination cube-es.example.com cube-esnetmod(cusp-config-rt)> end route tableConfiguring 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-policynetmod(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 policyConfiguring 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-policynetmod(cusp-config-lookup)> sequence 1 service-provider-table request-uri uri-component usernetmod(cusp-config-lookup-seq)> rule prefixnetmod(cusp-config-lookup-seq)> end sequencenetmod(cusp-config-lookup)> end policynetmod(cusp-config)> policy lookup cube-sp-policynetmod(cusp-config-lookup)> sequence 1 cube-sp-table request-uri uri-component usernetmod(cusp-config-lookup-seq)> rule prefixnetmod(cusp-config-lookup-seq)> end sequencenetmod(cusp-config-lookup)> end policynetmod(cusp-config)> policy lookup cube-es-policynetmod(cusp-config-lookup)> sequence 1 cube-es-table request-uri uri-component usernetmod(cusp-config-lookup-seq)> rule prefixnetmod(cusp-config-lookup-seq)> end sequencenetmod(cusp-config-lookup)> end policynetmod(cusp-config)> policy lookup enterprise-policynetmod(cusp-config-lookup)> sequence 1 enterprise-table request-uri uri-component usernetmod(cusp-config-lookup-seq)> rule prefixnetmod(cusp-config-lookup-seq)> end sequencenetmod(cusp-config-lookup)> end policyCommitting the Configuration
Now you must commit the configuration. Committing the configuration serves two purposes: the configuration becomes active, and is persisted.
•
•
•
netmod(cusp-config)> commitConfiguring 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-dialognetmod(cusp-config)> trigger routing sequence 2 policy service-provider-policy condition call-from-service-providernetmod(cusp-config)> trigger routing sequence 3 policy cube-sp-policy condition call-from-cube-spnetmod(cusp-config)> trigger routing sequence 4 policy cube-es-policy condition call-from-cube-esnetmod(cusp-config)> trigger routing sequence 5 policy enterprise-policy condition call-from-enterpriseConfiguring 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-dialognetmod(cusp-config)> trigger pre-normalization sequence 2 policy outgoing-norm-policy condition call-from-cube-spConfiguring 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. 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.99 5060netmod(cusp-config)> sip record-route cube-sp tls 10.10.20.99 5060netmod(cusp-config)> sip record-route cube-es tls 192.168.20.99 5060netmod(cusp-config)> sip record-route enterprise tls 192.168.10.99 5060netmod(cusp-config)> sip listen service-provider udp 10.10.10.99 5060netmod(cusp-config)> sip listen cube-sp tls 10.10.20.99 5060netmod(cusp-config)> sip listen cube-es tls 192.168.20.99 5060netmod(cusp-config)> sip listen enterprise tls 192.168.10.99 5060Configuring 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 hostnameConfiguration
This example uses the following configuration:
netmod(cusp-config)> show configuration activeBuilding CUSP configuration...!server-group sip global-load-balance call-idserver-group sip retry-after 0server-group sip element-retries udp 3server-group sip element-retries tls 1server-group sip element-retries tcp 1sip alias myhostnamesip dns-srvenableno naptrend dns!no sip header-compactionno sip logging!sip max-forwards 70sip network cube-es standardno non-invite-provisionalallow-connectionsretransmit-count invite-server-transaction 9retransmit-count non-invite-client-transaction 9retransmit-count invite-client-transaction 5retransmit-timer clientTn 64000retransmit-timer serverTn 64000retransmit-timer T4 5000retransmit-timer T2 4000retransmit-timer T1 500retransmit-timer TU2 32000retransmit-timer TU1 5000end network!sip network cube-sp standardno non-invite-provisionalallow-connectionsretransmit-count invite-server-transaction 9retransmit-count invite-client-transaction 5retransmit-count non-invite-client-transaction 9retransmit-timer T4 5000retransmit-timer T2 4000retransmit-timer T1 500retransmit-timer TU2 32000retransmit-timer TU1 5000retransmit-timer clientTn 64000retransmit-timer serverTn 64000end network!sip network enterprise standardno non-invite-provisionalallow-connectionsretransmit-count invite-client-transaction 5retransmit-count invite-server-transaction 9retransmit-count non-invite-client-transaction 9retransmit-timer serverTn 64000retransmit-timer T4 5000retransmit-timer T2 4000retransmit-timer T1 500retransmit-timer TU2 32000retransmit-timer TU1 5000retransmit-timer clientTn 64000end network!sip network service-provider standardno non-invite-provisionalallow-connectionsretransmit-count invite-server-transaction 9retransmit-count non-invite-client-transaction 9retransmit-count invite-client-transaction 5retransmit-timer serverTn 64000retransmit-timer TU1 5000retransmit-timer TU2 32000retransmit-timer T1 500retransmit-timer T2 4000retransmit-timer T4 5000retransmit-timer clientTn 64000end network!sip overload reject retry-after 0!no sip peg-counting!sip privacy servicesip queue messagedrop-policy headlow-threshold 80size 2000thread-count 20end queue!sip queue radiusdrop-policy headlow-threshold 80size 2000thread-count 20end queue!sip queue requestdrop-policy headlow-threshold 80size 2000thread-count 20end queue!sip queue responsedrop-policy headlow-threshold 80size 2000thread-count 20end queue!sip queue st-callbackdrop-policy headlow-threshold 80size 2000thread-count 10end queue!sip queue timerdrop-policy nonelow-threshold 80size 2500thread-count 8end queue!sip queue xcldrop-policy headlow-threshold 80size 2000thread-count 2end queue!route recursion!sip tcp connection-timeout 240sip tcp max-connections 256sip tls!trigger condition call-from-cube-essequence 1in-network cube-esend sequenceend trigger condition!trigger condition call-from-cube-spsequence 1in-network cube-spend sequenceend trigger condition!trigger condition call-from-enterprisesequence 1in-network enterpriseend sequenceend trigger condition!trigger condition call-from-service-providersequence 1in-network service-providerend sequenceend trigger condition!trigger condition mid-dialogsequence 1mid-dialogend sequenceend trigger condition!accountingno enableno client-sideno server-sideend accounting!server-group sip group cme.example.com enterpriseelement ip-address 192.168.10.6 5060 tls q-value 1.0 weight 0failover-resp-codes 503lbtype globalpingend server-group!server-group sip group cube-es.example.com cube-eselement ip-address 192.168.20.4 5060 tls q-value 1.0 weight 0element ip-address 192.168.20.3 5060 tls q-value 1.0 weight 0failover-resp-codes 503lbtype globalpingend server-group!server-group sip group cube-sp.example.com cube-spelement ip-address 10.10.20.3 5060 tls q-value 1.0 weight 0element ip-address 10.10.20.4 5060 tls q-value 1.0 weight 0failover-resp-codes 503lbtype globalpingend server-group!server-group sip group cucm.example.com enterpriseelement ip-address 192.168.10.4 5060 tls q-value 1.0 weight 50element ip-address 192.168.10.5 5060 tls q-value 1.0 weight 50element ip-address 192.168.10.3 5060 tls q-value 1.0 weight 100failover-resp-codes 503lbtype weightpingend server-group!server-group sip group sp.example.com service-providerelement ip-address 10.10.10.3 5060 udp q-value 1.0 weight 0failover-resp-codes 503lbtype globalpingend server-group!route table cube-es-tablekey * response 404key 5101 target-destination cme.example.com enterprisekey 510 target-destination cucm.example.com enterpriseend route table!route table cube-sp-tablekey * target-destination sp.example.com service-providerend route table!route table enterprise-tablekey * response 404key 5101 target-destination cme.example.com enterprisekey 91 target-destination cube-es.example.com cube-eskey 510 target-destination cucm.example.com enterpriseend route table!route table service-provider-tablekey * response 404key 510 target-destination cube-sp.example.com cube-spend route table!policy normalization outgoing-norm-policyuri-component update TO all user ^91 ""uri-component update request-uri user ^91 ""end policy!policy lookup cube-es-policysequence 1 cube-es-table request-uri uri-component userrule prefixend sequenceend policy!policy lookup cube-sp-policysequence 1 cube-sp-table request-uri uri-component userrule prefixend sequenceend policy!policy lookup enterprise-policysequence 1 enterprise-table request-uri uri-component userrule prefixend sequenceend policy!policy lookup service-provider-policysequence 1 service-provider-table request-uri uri-component userrule prefixend sequenceend policy!trigger routing sequence 5 policy enterprise-policy condition call-from-enterprisetrigger routing sequence 4 policy cube-es-policy condition call-from-cube-estrigger routing sequence 3 policy cube-sp-policy condition call-from-cube-sptrigger routing sequence 2 policy service-provider-policy condition call-from-service-providertrigger routing sequence 1 by-pass condition mid-dialogtrigger pre-normalization sequence 2 policy outgoing-norm-policy condition call-from-cube-sptrigger pre-normalization sequence 1 by-pass condition mid-dialog!no server-group sip global-ping!sip listen service-provider udp 10.10.10.99 5060sip listen cube-sp tls 10.10.20.99 5060sip listen cube-es tls 192.168.20.99 5060sip listen enterprise tls 192.168.10.99 5060!sip record-route cube-es tls 192.168.20.99 5060sip record-route service-provider udp 10.10.10.99 5060sip record-route cube-sp tls 10.10.20.99 5060sip record-route enterprise tls 192.168.10.99 5060!endnetmod(cusp-config)>Verify
Use this section to confirm that your configuration works properly. Use the following command to verify your Cisco Unified SIP Proxy configuration:
•
For more information on this command, see the Cisco Unified SIP Proxy Command Reference.
Troubleshoot
Use this section to troubleshoot your configuration.
Troubleshooting Procedure
Follow the instructions in this section to troubleshoot your configuration.
Validation Failure
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 voipsession protocol defaultephone phone-tagvoice-port platform-specific-informationSee 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:
•
•
•
•
For more information on these commands, see the Cisco Unified SIP Proxy Command Reference.
Related Information
•
CCDE, CCSI, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0903R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2009 Cisco Systems, Inc. All rights reserved.
Guest
