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