Cvp Nic Unplugging problem

Question

Hi
   I am presently facing a problem with a NRFU Test case in which when the nic of CVP(Active lic server) is unplugged the new calls placed are not failing over to the CVP (Redundant port server).We are running on a comprehensive setup with multi site env.The same cases with services got down(Call and Vxml) on active server the failover is happening fine.Some other scenarious like shutting the active dial-peer and checking if calls are serviced at 2nd CVP too works fine.
The ICM is on 7.5(7),CVP on 7.0(2) with ES of CVP7.0.2_ES22,CVP7.0.2_ES27 and CVP7.0.2_ES29 upgraded,CVP  OPS Console 7.0(2) and gateway is IOS c3845-ipvoicek9-mz.124-24.T3.Can't really find a reason on this not functioning.I do see the Label of 7777777777 + corelation id reaching my gateways when the nic is got down and new call is placed.However the VXML Session just does not seem to get invoked after that and it only tries to GET the active server on http request.
A tac case is open for this but it is taking a bit long.Can anybody suggest if any idea?
Thanks
Ganesh

Answer 1

hari.kanan wrote:Looking into your architecture which has branched locations with co located Ingress and VXML gateways it would have been a better idea to have used Sip.Sig digits where in you can have the VXML diaglouges played local to the site as where the call had originally originated.Using the Send to call originator function would also be a better idea, but all these holds good only until you have the VXML being played out.
There is no need for SIP.sigdigits in a branch office design. Send To Originator deals with this perfectly. It ensures that the VRU leg runs on the ingress gateway. I don't know what you mean by "all these holds good until you have the VXML being played out".
Once the call needs to be transffered to an agent you might have to make use of DNS SRV records to load balance between the Different CUCM which does the call processing.The reason being i dont think  using two or more static route for different call processing CUCM would really work coz CVP sip agent doesnt have the capability to send a SIP re- invite to make use of the second Static route in case the first one has failed.The local DNS-SRV really solves the issues related to the CUCM.
I want to be sure that you know this for a fact. Have you indeed confirmed this?
You say that the CVP SIP Back-To-Back User Agent does not have the capability to retry an INVITE if the first one fails. If this is the case, using SRV will not work either. It does not matter if there are two static routes, one to each Sub - or there is a single route on the cluster name being resolved by entries in a DNS SRV or local SRV - if the B2BUA cannot retry on failed INVITE, nothing will work.
I personally think a production SIP CVP without a Proxy is not a viable design.
you cannot use the send to the call originator function in this scenario because the the call is ideally originated fromthe CUCM and the the 77777! label used for queuing purpose would be send back from the CVP to the CUCM, which CUCM does not know wat it needs to be done with it.
You don't know that at all.
The OP has not told us what the VRU label on the CUCM routing client is. Normally it is not the same as the label on the CVP RC. Whatever this label is, it's not sent by CVP - it's returned to the CUCM through the PG.
CUCM MUST know what to do with it - typically it's a Route Pattern that finds a CVP. Then CVP needs to find a gateway - and you are correct that it cannot use "Send To Originator" - so there must be a static route to find a gateway using 7777777777.
So - you simply need to configure both items. You add the 777777777> to the Send to Originator and you also add a pair to the Static Route section for the gateways in Warm Transfer. CVP will optimize.
So in case of the Warm transfers i again reiterate the fact that SIP.sig didgits should have been used to maintian Queue or transfer back to IVR local to the site as the where the called had originated.
OK, this part is true - although the design is complex. In a branch-office design, with a number of branches, SIP.sigdigits is the only way to ensure that the gateway found by CVP to queue the call in a warm transfer (or any CUCM-originated call) ia at the branch. The OP has not told us whether there will be multiple branches - he does not have them at the moment.
Adding SIP.sigdigits adds a layer of complexity that takes a while to work through. If you have the bandwidth between sites you can simplify a multi-branch design by choosing one gateway (or one pair of gateways) to queue the call for CUCM-generated calls.
Using a static route for the Warm transfers and maintaining it to only one gateway your redudancy may not achieved. Again i doubt whether the re-invires are sent and the other static routes if made use of.if i was in your place and in an architecture with branched loactions and no Sip proxy server  i would have made use of SIP.sig digits and local DNS SRV  records. The local DNS SRV functionality does the work of the proxy servers in deployments where no proxies are used. Based on the weights and the priorities defined on the XML file it load balances and the does the failover as expected to be done by the proxy server.i would rather suggest you to re visit the design of this and make use of SIP.sig digits in combination with local DNS SRV records.
You would not have a static route to one gateway - you would put both there. Once again, you say you "doubt whether the re-invites are sent and other static routes if (sic) made use of" but you provide no proof. Cisco certainly don't say this limitation exists.
As I said before, if the B2BUA cannot retry, it makes no difference if you use a pair of static routes, or a single static route with a cluster name being resolved by SRV (either DNS or local file) , you are screwed. Adding SIP.sigdigits does not solve the problem if the B2BUA cannot retry.
I always like to use the simplest solution. I don't know enough about the future plans or the inter-branch bandwidth to clearly say that SIP.sigdigits is useful.
Regards,
Geoff