The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
|
|
|
---|---|---|
|
||
|
||
|
Creates a network and puts you into network command mode. In this case, the network that is being created is called “service provider”. |
|
|
The following example creates a network called “service-provider”:
You create trigger conditions to allow Cisco Unified SIP Proxy to respond with the appropriate action for various call flows. In general, the more complex the call flow is, the more complex the trigger must be.
3. trigger condition trigger-condition-name
In this example, Cisco Unified SIP Proxy only reacts based on the network the call came in on, so the triggers are simple.
Server groups define the elements that Cisco Unified SIP Proxy interacts with for each network. The server group name that is used is inserted into the SIP URI of the outgoing request. Some devices, such as Cisco Unified Communications Manager, validate the URI of requests before processing, which means that the end device might need to be configured with a Fully Qualified Domain Name (FQDN) to allow for this.
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, 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. You can change the weights and q-values to configure a different priority or load-balancing scheme.
3. server-group sip group server-group-name network
4. element ip-address ipaddress port {udp | tcp | tls} [q-value q-value ] [weight weight ]
5. lb-type {global | highest-q | request-uri | call-id | to-uri | weight }
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. For example, each key might represent the prefix of a phone number dialed.
4. key key response response-code
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.
3. policy normalization policy_name
4. uri-component update request-uri {user | host | host-port | phone | uri} {all | match-string } replace-string
5. uri-component update header {first | last | all} {user | host | host-port | phone | uri} {all | match-string} replace-string
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.
4. sequence sequence-number table-name field { in-network | local-ip-address | local-ip-port | remote-ip-address | remote-ip-port} | header { p-asserted identity| from | to | diversion| remote-party-id } | request uri [uri component { param| user | phone | host| host-port| uri } ]
5. rule {exact | prefix | subdomain | subnet | fixed length } [case-insensitive]
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.
3. trigger routing sequence sequence-number {by-pass | policy policy } [condition trigger-condition ]
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. Similar to routing policies, a special policy bypasses normalization on mid-dialog messages.
3. trigger pre-normalization sequence sequence-number { by-pass | policy policy } [ condition trigger-condition ]
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.
3. sip record-route network_name {tcp | tls | udp} ip_address [port]
4. sip listen network_name {tcp | tls | udp} ip_address port
If the upstream element is using DNS SRV for routing to the two Cisco Unified SIP Proxies in a network, you must configure the two Cisco Unified SIP Proxies to have the same FQDN by entering the sip alias command in Cisco Unified SIP Proxy configuration mode on both Cisco Unified SIP Proxies.
|
|
|
---|---|---|
|
||
|
||
|
Cisco Unified SIP Proxy supports TLS, Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). Establishing TLS connections requires some extra steps because the connections require authentication using signed certificates.
You need an SFTP server or HTTP to import certificate requests.
2. crypto key generate [rsa {label label-name | modulus modulus-size } | default]
3. crypto key certreq label label-name url {sftp: | http:}
4. crypto key import rsa label label-name {der url {sftp: | http: } | pem { terminal | url {sftp: | http: }} [default]
1. vim <filename> (This is an example only. You can use any text editor as such.)
2. openssl req -new -newkey rsa:2048 -nodes -keyout <key> -out <csr> -config <configuration file name>
3. openssl x509 -req -days <days> -in <csr> -signkey <key> -out <certificate>
5. crypto key import trustcacert label <label_name> terminal
Note Execute the steps 4 and 5 on the Unified SIP Proxy CLI command. Use a different host to run the steps 1 through 3, such as Linux, where OpenSSL is available.
On a Linux server, execute the following commands:
distinguished_name = req_distinguished_name
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = California
localityName = Locality Name (eg, city)
localityName_default = San Jose
organizationName = Organization Name (eg, company)
organizationName_default = Cisco Systems, Inc.
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Cisco Webex
commonName = Common Name (eg, YOUR name)
emailAddress_default = csg-avops@cisco.com
openssl req -new -newkey rsa:2048 -nodes -keyout me90sjvce001.webex.com.key -out me90sjvce001.webex.com.csr -config abc
openssl x509 -req -days 720 -in me90sjvce001.webex.com.csr -signkey me90sjvce001.webex.com.key -out me90sjvce001.webex.com.cer
Log in to the Cisco Unified SIP Proxy and execute the following commands:
se-10-0-0-0> configure terminal
se-10-0-0-0(config)# crypto key import trustcacert label sample_cert terminal
MIIDLjCCAhagAwIBAgIBATANBgkqhkiG9w0BAQUFADAwMS4wLAYDVQQDEyVJT1Mt
U2VsZi1TaWduZWQtQ2VydGlmaWNhdGUtMzc4ODk3MTYzMB4XDTE3MDExODA2MzYy
N1oXDTIwMDEwMTAwMDAwMFowMDEuMCwGA1UEAxMlSU9TLVNlbGYtU2lnbmVkLUNl
cnRpZmljYXRlLTM3ODg5NzE2MzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAI/k+Jl/RdXkUu3aBp8qIMVA7ifpRehG9AXJKlqOafc9Ly92hwNxeLGV/U8k
Xlo/fuoyaNyLIu9GwS1BfvM3yHOthhX+T5RHgcj3s1Yctl6HUW93M/EJYluo5RDE
NAXJ2UXa/Utl9ZGjCvat8h3N4QduP2ulIsK1IqyYLDRwD1fiSNFrdZB2zzIE1M7g
eeitn4n1INHiVtH0jOmO4En/FjUa3YPCFEyB1/U17YGWN/GOHguCsZluL8WywAT5
Pq1uaipVxWoCzXCb74BSxTJiHs/tmPGkIHi57RvLKxgqr5vHXCOsWsQ6/C9z6My3
tvE6dtLHuP2RgR6r+3xOhKdqcHECAwEAAaNTMFEwDwYDVR0TAQH/BAUwAwEB/zAf
BgNVHSMEGDAWgBSIzQOOrJrnxzR8LEQ2VIIfVFpO2DAdBgNVHQ4EFgQUiM0Djqya
58c0fCxENlSCH1RaTtgwDQYJKoZIhvcNAQEFBQADggEBABhYrhWv9DZ0sZZt7Smc
o5pgIIFFOtGQYc+ei7H6QNzW5iNSZbSPBAIpmVMQWHVS6cOvJ/N63ayQ+1TN3rZm
wmOU9tFExBzjge0nX+Go+0KdWNNQG4XO8SU7BKwM8iWTsM1jT1j6cb9Bv1kMgXW0
5K5AzVYTbaTP/OMoMCsuOJts+GI/Q82H7tlIbdJFbbu3iVEN+gf3coUrHa4X2jLr
K3EVLniCLedkcXdy5TppTvQM9j1FzkGMIrWAlFlp/Vh2CTigJy8GZ4pWt5QzjO6m
KuP6FZxGPNe8F5BsFCWNM5aHPa8MUqlFKZMuUb50w43SZRT3xfI2WLv1yd49f65T
From Cisco Unified SIP Proxy Release 10.1 onwards, HTTPS is enabled by default. You need not manually generate a crypto key and pass it to the web session security to enable HTTPS. However, you should be able to import a signed certificate that you generated externally, and update the web session with this new key label.
2. crypto key import rsa label label-name { der url {sftp: | http: } | pem { terminal | url {sftp: | http: }} [default]
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.
4. sip tls trusted-peer { peer’s-hostname }
Note From Cisco Unified Proxy Release 10.1 onwards, HTTPS is enabled by default. You need not manually generate a crypto key and pass it to the web session security to enable HTTPS. Cisco Unified Proxy Release 10.1 supports only TLS v1.2 for HTTPS. If you delete the certificate from the web session security and try to login through HTTP, you will be redirected to HTTPS. Only the latest connection is retained and the remaining connections are logged out.
One of the ways you can configure the performance of the Cisco Unified SIP Proxy is to switch the module to Lite Mode. In Lite Mode, which requires you to disable record-route, the module’s performance is boosted. In standard mode, the module processes calls up to the licensed limit.
By default, the module is in standard mode.
For information on the performance difference when using Lite Mode versus standard mode, see the Release Notes for Cisco Unified SIP Proxy Release 10.1.
|
|
|
---|---|---|
|
||
|
||
|
The following example puts the module into Lite Mode:
One of the ways you can configure the performance of the Cisco Unified SIP Proxy is to restrict the number of calls that the Cisco Unified SIP Proxy can handle.
|
|
|
---|---|---|
|
||
|
||
|
Sets the maximum call rate that the Cisco Unified SIP Proxy can handle. |
The following example limits the number of calls that the system can process to 50:
Now you must commit the configuration. Committing the configuration serves two purposes: the configuration becomes active, and is persisted.