05-02-2018 07:07 AM
If a CVP Call Server no longer has a Connection with the A or B side VRU PG, it's ICM Stats changes to Partial Service as per below screenshot. ( Screen shot taken from http://<cvpserver>:8000/cvp/diag )
What I am surprised about is that while in this state the SIP Service continues to stay in service and continues to reply back with 200 OK to SIP options Pings from the Gateways / CUBEs.
Yet the CVP CallServer Server is not available to take any calls and any calls that it receives will get a sip refer to the error DN of 92929292
These calls are then handled by the CVP Survivability script.
A better solution would be if the CVP server went off line if its ICM state was "In Service" stopped responding to the SIP options pings and stating it was healthy (200).
Is there any configuration available today - where you can change this behavior so that CVP SIP Service goes off line / does not reply to the SIP options etc. under this scenario?
Regards,
Gerry
Solved! Go to Solution.
05-29-2018 02:00 AM
Cisco have documented above as a bug and its already been fixed in CVP 11.5 ES19
05-04-2018 08:34 AM
Gerry,
The Call Server doesn't answer calls which it would have to do in order to then send a REFER. It will be returning a a 4xx or 5xx to the incoming INVITE. You should get a Wireshark trace and see exactly what the SIP messaging is. Survivability will kick in if all codec preferences fail.
Paul
05-04-2018 09:14 AM
Paul,
I had done a wiresharki. It sends a 302 to the error script - 92929292.
And then the survivability script kicks in.
But would it not be better if in this state that the CVP CallServer stopped telling the Gateway or CUBE it was OK (via its 200 OK SIP option responses).
Then the gateway and CUBE which would be sending it a SIP option ping woudl not send the Call Server at all.
And you coudl use a differnet dial-peer with lower priority to route somewhere else (e.g. to the other CVP server or somwhere else).
If want survivability to kick it - you could easily allow it to do so.
Example.
A side CVP server network between Gateway is OK, but Network between the CVP Call Server and PG is down. while the B side CVP Server is OK and reachable by the Gateways and can talk to the PG so is 100% in service.
We have 50% call failures / survivability scripts.
Maybe not likely to happen but it is possible...
Gerry
05-04-2018 10:08 AM
Gerry,
I totally agree on the OPTIONS PING responses; it makes absolutely no sense at all to be getting a healthy indication back. That sounds like defective working to me and maybe needs a TAC case.
When I tried a test earlier to check what happens when a call hits a CVP with no ICM behind it I did get an error response back and the alternate preference dial-peer is used. This was the behaviour I expected although I did expect to see a 503 rather than the 404 that was sent back to the ingress gateway. Not sure how you're getting the 302 redirect.
Paul
05-21-2018 03:09 AM
Paul,
thanks - I agree and I am opening a TAC case to see if I can get this corrected.
Below is the SIP 302 when CVP is in "ICM Partial Service" and below that - is a sample SIP Option Ping from a CUBE to CVP with the 200 OK.
-------------------------------------------------------------------------------------------------------
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 10.247.0.7:5060;branch=z9hG4bK4C58BE578
To: <sip:18297052@10.1.0.17>;tag=ds74e87715
From: "anonymous" <sip:anonymous@10.0.0.7>;tag=84A02B35-2282
Call-ID: CA904D70-5C0F11E8-8E8DB180-3AFB2768@10.0.0.7
CSeq: 101 INVITE
Content-Length: 0
Cisco-Guid: 3398414511-1544491496-2391257472-0989538152
Contact: <sip:92929292@10.0.0.7:5060>
Cisco-Gucid: CA8FB0AF5C0F11E88E87B1803AFB2768
Session-ID: 00000000000000000000000000000000;remote=8204f3ad100001632818bed1c67088d6
--- SIP OPTION ---
OPTIONS sip:10.1.0.17:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK4C58C2634
From: <sip:10.0.0.7>;tag=84A04016-15AF
To: <sip:10.1.0.17>
Date: Mon, 21 May 2018 10:25:58 GMT
Call-ID: CDBFE346-5C0F11E8-8E91B180-3AFB2768@10.0.0.7
User-Agent: Cisco-SIPGateway/IOS-15.5.3.S6
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact: <sip:10.0.0.7:5060>
Content-Length: 0
--- SIP OPTIONS 200 OK Responds ---
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 10.0.0.7:5060;branch=z9hG4bK4C58C2634
To: <sip:10.1.0.17>;tag=dsc11d8bf5
From: <sip:10.0.0.7>;tag=84A04016-15AF
Call-ID: CDBFE346-5C0F11E8-8E91B180-3AFB2768@10.0.0.7
CSeq: 101 OPTIONS
Content-Length: 0
-------------------------------------------------------------------------------------------------------
Regards,
Gerry
05-29-2018 02:00 AM
Cisco have documented above as a bug and its already been fixed in CVP 11.5 ES19
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide