SIP OPTIONS is the ping of VoIP. Sending OPTIONS to a SIP endpoint and waiting for 200 OK is the standard way to check if a trunk or endpoint is alive. Every production SIP deployment should use OPTIONS-based health monitoring.
The SIP OPTIONS method, defined in RFC 3261, queries a SIP server or endpoint about its capabilities. The response includes the methods and features the server supports. But in practice, OPTIONS is used primarily as a health check and keepalive ping — a lightweight way to verify a SIP endpoint is alive without placing a real call.
Most SIP PBX platforms and SBCs send periodic OPTIONS requests to SIP trunks to monitor their health. If the trunk stops responding, the system marks it as unavailable and can fail over to a backup trunk automatically.
Carriers also send OPTIONS pings to your SBC or PBX to verify it is reachable before routing calls. Microsoft Teams Direct Routing, Zoom BYOC, and most SIP trunk providers require your SBC to respond to OPTIONS.
| Response | Meaning | Action |
|---|---|---|
| 200 OK | Endpoint alive and ready | Mark trunk as healthy |
| 486/480/403 | Alive but cannot accept calls now | Trunk reachable, call may still fail |
| 503 | Temporarily unavailable | Back off and retry |
| No response / timeout | Endpoint unreachable | Mark trunk as down, failover |
Behind NAT, UDP port mappings expire if no traffic flows through them. After 30-60 seconds of silence, the NAT device closes the mapping and incoming SIP traffic can no longer reach the endpoint.
OPTIONS requests serve as keepalives — they maintain the NAT UDP binding open by sending periodic traffic. Without keepalives, registrations expire from the NAT side even if the SIP registration is still valid on the server.
No response to OPTIONS: The endpoint is unreachable — firewall blocking, server down, or NAT binding expired. If your SBC stops responding to OPTIONS from a carrier, the carrier will mark you as unavailable and stop sending calls.
200 OK but calls still fail: The endpoint is reachable but something is wrong with call handling — codec issues, authentication failures, or dialplan errors. OPTIONS only checks reachability, not call capability.
High OPTIONS response time: Latency between endpoints. OPTIONS RTT is a good proxy for SIP signaling latency. If OPTIONS RTT exceeds 500ms, call setup will feel slow.
A SIP OPTIONS ping is a lightweight health check that sends an OPTIONS request to a SIP endpoint and waits for a 200 OK response. It is used to monitor SIP trunk availability, maintain NAT keepalives, and verify SBC reachability. Most SIP platforms (Asterisk qualify, Kamailio dispatcher ping) use OPTIONS-based health monitoring. Carriers like Microsoft Teams require SBCs to respond to OPTIONS pings.
In Asterisk PJSIP, set qualify_frequency=30 and qualify_timeout=3.0 in the AOR section of pjsip.conf. This sends OPTIONS every 30 seconds and marks the endpoint unreachable if no response in 3 seconds. Check status with pjsip show contacts. In chan_sip, set qualify=yes and qualifyfreq=60 in the peer definition, then check status with sip show peers.
SBC not responding to OPTIONS is usually caused by: firewall blocking UDP 5060 inbound from the carrier IP range, the SBC not configured to handle OPTIONS on the listening interface, or the SBC returning 403 because the source IP is not in the allowlist. Check that your SBC responds to OPTIONS from all carrier IP ranges and that your firewall allows bidirectional UDP 5060.
Paste your SIP trace into SIPSymposium. The analyzer identifies OPTIONS ping failures, measures response times, and flags trunks that are not responding to health checks.