cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
3169
Views
0
Helpful
2
Replies
Highlighted
Contributor

SIP Options PING (CVP SIP Server Groups - Heartbeat)

The CVP Operations Console has a feature to enable SIP ping Options.

If you configure a SIP server group and enable heartbeats, the CVP Call Server sends a SIP ping option ever X seconds.

We have a SIP Server group for the CUCM servers and a group for the VXML Gateways.

The Cisco CUCM replies with a SIP 200 OK to these SIP 'ping' Options.

However the VXML Gateway does not. Does anyone know why not and if its possible to enable a gateway to reply to these SIP options?

 

Below is documentation on how to configure the Cisco Gateway to SEND ping options, but we don't that. We just need it to reply to the Ping OPTIONS sent by CVP.

For calls that originate from CUCM to CVP, they need to use the VXML Gateway SIP server group, (as it cannot route to the originator for VXML treatment).

http://www.cisco.com/c/en/us/td/docs/ios/voice/cube/configuration/guide/vb_book/vb_book/vb_9321.html

See screen shot where you can see replies from the CUCM servers (.200, .201) but NOT from VXML Gateway (.250).

Regards,

Gerry

 

2 REPLIES 2
Highlighted
Cisco Employee

Hello Gerry,

You may need to enable the SIP Traces in the voice Gateway and have a look how exactly gateway is processing and why 200 OK is not sent.

Can you share the IOS Version on the Gateway ?

Look at the below link and list of Resolved Caveats in 15.2(4)M, one of the caveat looks like your scenario. But i would recommend first look into Sip traces.

http://www.cisco.com/c/en/us/td/docs/ios/15_2m_and_t/release/notes/15_2m_and_t/152-4MCAVS.html

CSCtx79318

Symptoms: OGW fails to send 200 OK response for OPTION.

Conditions: The symptom is observed with 200 OK response for OPTION in Cisco IOS interim Release 15.2(02.16)T.

Workaround: There is no workaround.

 

Regards,

Senthil

Highlighted

Senthil,

Thanks for your response. It was my error. The responses were been sent after all.

I had a filter on my wireshark (WinPCAP) trace of port 5060 (for SIP traffic).

Filter: "Port 5060". When I changed this to filter by IP address "host 10.201.11.250" I could see traffic.

What I did not realize was that the SIP OPTIONS source UDP port (from the sender) was not port 5060 and the responses were sent back to this address (port 5067 in this case).

So by filtering for on only viewing traffic to/from port 5060, it meant I did not see the SIP 200 OKs.

So it was just an error on my side by filtering the WinPCAP.

Attached is screen shot showing responses OK.

Gerry

Content for Community-Ad