Cisco Support Community
Community Member

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).

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




Everyone's tags (1)
Cisco Employee

Hello Gerry,You may need to

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.


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.




Community Member

Senthil,Thanks for your


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" 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.


CreatePlease to create content