SIP Significant Digits - SigDigits

Configuration of Unified CVP SIP Service:
The Unified CVP SIP Service does not currently have a configuration field for setting the significant digits that should be stripped. Instead, you must edit the sip.properties file. The sip.properties file is located in the C:\Cisco\CVP\conf directory by default. Add the following line to the end of the sip.properties file (to strip four digits from the DNIS number):
SIP.SigDigits = 4

Configuration of VoiceXML gateway:
Configure the VXML gateway to match the DNIS string, including the prepended digits:
dial-peer voice 3000 voip
incoming-called number 33335551000T
service bootstrap
...
Configure the Unified CVP bootstrap.tcl application with the sigdigits parameter, telling it how many digits to strip off of the incoming DNIS string:
application
service bootstrap flash:bootstrap.tcl
param sigdigits 4
...

Cisco Unified CM configuration (if used):
Configure Unified CM to strip the prepended digits, either by using the Significant Digits configuration on the SIP Trunk configuration page or by using translation patterns.

SIP Proxy configuration:
Define static routes on the SIP Proxy, with the prepended digit present, to be sent to the appropriate VoiceXML gateway. Because transfers to agents on a Unified CM cluster will also have the digits prepended, the static routes for agent phones must also contain the prepended digits.

IOS Gateway Configuration for SIP-Proxy Redundancy

With Cisco IOS gateways, dial-peers are used to match phone numbers, and the destination can be a SIP Proxy Server, DNS SRV, or IP address. The following example shows a Cisco IOS gateway configuration to send calls to a SIP Proxy Server using the SIP Proxy's IP address.
sip-ua
sip-server ipv4:10.4.1.100:5060
dial-peer voice 1000 voip
session target sip-server
...
The sip-server command on the dial-peer tells the Cisco IOS gateway to use the globally defined
sip-server that is configured under the sip-ua settings. In order to configure multiple SIP Proxies for redundancy, you can change the IP address to a DNS SRV record, as shown in the following example. The DNS SRV record allows a single DNS name to be mapped to multiple servers.
sip-ua
sip-server dns:cvp.cisco.com
dial-peer voice 1000 voip
session target sip-server
...
Alternatively, you can configure multiple dial-peers to point directly at multiple SIP Proxy servers, as shown in the following example. This configuration allows you to specify IP addresses instead of relyingon DNS.
dial-peer voice 1000 voip
session target ipv4:10.4.1.100
preference 1
...
dial-peer voice 1000 voip
session target ipv4:10.4.1.101
preference 1
...
In the preceding examples, the calls are sent to the SIP Proxy server for dial plan resolution and callrouting. If there are multiple Unified CVP Call Servers, the SIP Proxy server would be configured with multiple routes for load balancing and redundancy.

DNS SRV records allow an administrator to configure redundancy and load balancing with finer
granularity than with DNS round-robin redundancy and load balancing. A DNS SRV record allows you to define which hosts should be used for a particular service (the service in this case is SIP), and it allowsyou to define the load-balancing characteristics among those hosts. In the following example, the
redundancy provided by the three dial-peers configured above is replaced with a single dial-peer using a DNS SRV record. Note that a DNS server is required in order to do the DNS lookups.
ip name-server 10.4.33.200
dial-peer voice 1000 voip
session target dns:cvp.cisco.com


With Cisco IOS gateways, it is possible to define DNS SRV records statically, similar to static host records. This capability allows you to simplify dial-peer configuration while also providing DNS SRV load balancing and redundancy. The downside of this method is that, if the SRV record needs to be changed, it must be changed on each gateway instead of on a centralized DNS server. The following example shows the configuration of static SRV records for SIP services handled by cvp.cisco.com, and the SIP SRV records for cvp.cisco.com are configured to load-balance across three servers.
ip host cvp4cc2.cisco.com 10.4.33.132
ip host cvp4cc3.cisco.com 10.4.33.133
ip host cvp4cc1.cisco.com 10.4.33.131
(SRV records for SIP/TCP)
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com
(SRV records for SIP/UDP)
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com
Cisco highly recommends the use of UDP instead of TCP for SIP signaling. TCP stack timeout delays can cause significant delays to the caller during failures.

DTMF Relay for SIP

DTMF tones are the tones that are generated when a telephone key is pressed on a touchtone phone. Sometimes the called endpoint needs to hear those tones, such as when you enter digits during the call in response to a menu. Low-bandwidth codecs can distort the sound, however. DTMF relay allows that tone information to be reliably passed from one endpoint to the other. By default, SIP uses in-band signaling, sending the DTMF information in the voice stream. However, you can configure it to use RTP-NTE, SIP INFO messages, SIP NOTIFY messages, or KPML for transmitting DTMF tone information.

RTP-NTE is an in-band DTMF relay method, which uses RTP Named Telephony Event (NTE) packets to carry DTMF information instead of voice. If RTP-NTE is configured, SDP is used to negotiate the payload type value for NTE packets and the events that will be sent using NTE.

RTP-NTE can cause problems communicating with SCCP phones, which use only out-of-band DTMF relay. In a CallManager 4.x network with SCCP phones, you must provision an MTP for calls that traverse the SIP trunk. This MTP translates between in-band and out-of-band DTMF signals. You must configure a separate MTP for each side of the SIP trunk. You can do this MTP in hardware, or in software on CallManager.

Cisco has two out-of-band procedures for DTMF relay. One uses SIP INFO methods, and the other uses SIP NOTIFY methods. The SIP INFO method sends DTMF digits in INFO messages. It is always enabled. When a gateway receives an INFO message containing DTMF relay information, it sends the corresponding tone.

NOTIFY-based out-of-band DTMF relay is negotiated by including a Call-Info field in the SIP INVITE and response messages. This field indicates an ability to use NOTIFY for DTMF tones and the duration of each tone in milliseconds. Using this method can help SIP gateways interoperate with Skinny phones. You can also use it for analog phones that are connected to Foreign Exchange Station (FXS) ports on the gateway.

CVP Static Route for SIP Proxy Redundancy

When configuring static routes on CVP call servers to route to two SIP Proxy servers for redundancy, there are two ways to do it.

One is to add SRV DNS records in your DNS server, and the other one is to use local DNS SRV records.
• Static routes using DNS SRV records on a DNS Server
– Advantages:
Weighted load balancing and redundancy.
– Disadvantages:
Might not be able to use an existing DNS server, depending on the location of the DNS server.
The ability to share or delegate DNS server administration rights might not be possible in
some organizations.
Dial-plan configuration needs to be configured on each device individually (Cisco Unified
Communications Manager, Unified CVP, and gateways).
DNS SRV lookup is performed for each and every call by Unified CVP. If the DNS server is
slow to respond, is unavailable, is across the WAN, or so forth, this will affect performance.
• Static routes using local DNS SRV records
– Advantages:
Weighted load balancing and redundancy.
Does not depend on an external DNS Server, thus eliminating a point of failure, latency, and
DNS Server performance concerns.
– Disadvantages:
Dial plan must be configured on each device individually (Cisco Unified Communications
Manager, Unified CVP, and gateways).

Below is an example local SRV configuration file. It must be named in a text file named srv.xml and manually placed in the c:\cisco\cvp\conf directory of the Call Server where the SIP Service is running.

<?xml version="1.0" encoding="UTF-8" ?><locater>

<host name="cups.cisco.com">
<record weight="30" priority="1" destination="10.86.129.1" port="5060"/>
<record weight="30" priority="2" destination="10.86.129.2" port="5060"/>
</host>


<host name="vxml-gateway.cisco.com">
<record weight="30" priority="1" destination="10.86.129.23" port="5060"/>
<record weight="30" priority="2" destination="10.86.129.109" port="5060"/>
</host>


<host name="vgw.cisco.com">
<record weight="30" priority="1" destination="10.86.129.100" port="5060"/>
<record weight="30" priority="1" destination="10.86.129.101" port="5060"/>

</host>

</locater>

• So in example above (host with cups.cisco.com), SIP request will always go to 10.86.129.1 and if 129.1 is failed it will go to .2
  
• Because the priority is different (when priority is different, the weight is ignored)
  
• CVP is going to wait till the SIP timer expires and then send it to 129.2
  

• In the second example above (one with the vxml-gw.cisco.com) first record is on the top priority
  
• So all calls will be routed always to 10.86.129.23.
  
• Only when first host goes down, then the call will be sent to 10.86.129.109
  
• But in this case CVP has no way of knowing about 10.86.129.23 going down dynamically
  
• And after SIP retry timer kicks in, then it will send it to 10.86.129.109
  
• So each and every call will have to wait before the timer expires and then it will be sent to 10.86.129.109
  

• In the third example above (one with the vgw.cisco.com)
  
• Since the priority and weight both are same, that means all calls will go into round-robin fashion
  
• Lets assume that the first host is down, then every second call will have to wait till SIP timer expires and then it will switch to 10.86.129.109