cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1447
Views
6
Helpful
5
Replies

CVP SIP Options

Gerry O'Rourke
Spotlight
Spotlight

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 )

Capture.JPG

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

1 Accepted Solution

Accepted Solutions

Cisco have documented above as a bug and its already been fixed in CVP 11.5 ES19

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh73759

View solution in original post

5 Replies 5

ptindall
Cisco Employee
Cisco Employee

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

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

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

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

Cisco have documented above as a bug and its already been fixed in CVP 11.5 ES19

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh73759

Getting Started

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: