06-09-2009 02:28 AM - edited 08-29-2017 08:43 AM
Four options are possible
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>
Essentially same as above. But the SRV functionality is handled by DNS Server now. In CVP configure a static route pointing towards the DNS SRV Server
You can use SIP Proxy Server for load balancing and failover. CUPS SIP Proxy support priority and weight options.
In the dial-peer you could configure the preference value. So if CVP1 for example failed, the call could go to CVP2 after the first try times-out
Configure local SRV records in the gateway. It could point to a SIP Proxy Server or a CVP server.
GW-Local-SRV---->CVP1
|------>CVP2
OR
GW-Local-SRV---->CUP1-------CVP1
| |--------CVP2
|
|----->CUP2-------CVP1
|--------CVP2
GW can point towards the DNS based SRV records.
GW--->DNS-SRV----CVP1
|------CVP2
OR
GW-->DNS-SRV----CUP1-------CVP1
| |--------CVP2
|
|-----CUP2-------CVP1
|--------CVP2
GW-->CUP---->CVP1
|----->CVP2
Consider following failover scenario (Load balancing and mid-call SIP failure scenario would behave the same way)
<host name="vxml-gw.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>
Question:
Is CVP going to retry the next destination with priority=2 route automatically, if it receives one of the above SIP error messages? And would it happen after some timeout or immediately?
Answer:
If the other SIP end-point responds with a 4XX responses like 480 or 486, this indicates to CVP that the final endpoint was reached and that this is the final disposition. Therefore, the failover does not occur. The CVP Local SRV implementation is such that it only rolls over to the next element in the SRV table if it gets a 503 service unavailable rejection or an timeout occurs. The CVP will not roll over with a 500 rejection either. Unlike the proxy servers (Unified SIP Server SIP Proxy and Unified Proxy Server), CVP local SRV does not have the SRV configurability to specify more rollover codes beside 503
SRV rollover is only applicable to initial INVITE requests. It does not apply to mid call requests such as reinivtes.
On the Question above, the last sentence is incorrect. The sentence that reads "This is the behavior even for a mid-call sip failures as well." should be removed.
The correction should read "SRV rollover is only applicable to initial INVITE requests. It does not apply to mid call requests such as reinivtes."
Thanks Paul for clarifiying it and reviewing it. I have made the changes based on your comment.
I would like to share the following.
Configuring DNS SRV for failover and redundancy on a SIP call flow.
In this scenario we configured 2 SRV records on the ingress gateway for the CVPA and CVPB
Test Scenario 1:
1. Shutdown call server process on CVPA which brings down the CVPA PIM
2. Place 10 calls in queue
3. All 10 routed successfully to CVPB.
This test was repeated by shutting down CVPB and bringing CVPA back online and same results as above
.
Test Scenario 2:
1. Shutdown switchport connected to CVPA which brings down the CVPA PIM
2. Place 10 calls in queue
3. 50% routed successfully after 2 seconds and 50% routed successfully after a delay of approx 63 seconds to CVPB.
This test was repeated by shutting switch port connected to CVPB and bringing CVPA back online and same results as above
The difference in the 2 scenarios is that in scenario 1 the pim was inactive but the IP Address was pingable while in scenario 2, the IP Address was not pingable.
SOLUTION:
Set the following sip-ua parameters.
sip-ua
retry invite 2 -- default 6
timers trying 100 -- default 500
After these values were set calls were routed 100% of the times within 2 seconds.
Hi Courtland,
Thanks for sharing your experience and taking time to document it here.
With CVP 8.0 since SIP OPTION is implement both on the CVP Call Server and Gateway side, now the gateway and CVP server will know the availability of the SIP destination in advance. So the call won't be routed to the failed or down server. So now you dont have this issue of long delays before reaching to the working Call Server
Shahzad
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: