OK
The textbook answer. Far end processed the request.
up// sip options monitoring
A 405 is not an outage, and your monitor should know that.
SIP OPTIONS is the closest thing SIP has to a ping: a request that asks a server what it supports, which any live SIP element will answer even when it refuses to do anything else. The trick is not sending it — sipsak can do that — it is interpreting the answer without paging someone for a firewall policy.
response codes
What each answer actually tells you
Monitors that demand a 200 OK generate their first false alarm the moment they meet an SBC with a sensible OPTIONS policy. This is the rule SIP Sentry applies instead.
Forbidden
Your source address is not allowlisted. SIP works; policy says no.
upNot Found
The Request-URI user does not exist. The proxy still answered.
upMethod Not Allowed
Common on SBCs configured not to serve OPTIONS. Perfectly healthy.
upBusy Here
Answered by a UA at capacity. Signalling path is intact.
upServer Internal Error
Something inside the far end is broken. Genuine incident.
downService Unavailable
Overload, CPS limit, or all channels busy. Calls are failing now.
downno answer
Could be down, could be a firewall dropping unknown sources. Not a page on its own.
degraded# one options transaction
→ OPTIONS sip:sbc.example.net SIP/2.0
Via: SIP/2.0/TLS 185.x.x.x;branch=z9hG4bK…
Max-Forwards: 70
User-Agent: SIPSentry/1.0
← SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
rtt=11 ms · transport=TLS · timer B not reached
transaction timers
Real SIP timers, not a socket timeout
SIP retransmits. A UDP OPTIONS request that gets no answer is resent at T1, then 2×T1, up to timer B — and a monitor that gives up after one datagram will report an outage that a real phone would have ridden out without noticing.
SIP Sentry probes run a proper client transaction with RFC 3261 timers, so a single lost packet on a congested link is a retransmission statistic rather than an incident. What you see in the result is the response that a real user agent would have seen.
questions
Straight answers
What is a SIP OPTIONS ping?
A SIP OPTIONS ping is an out-of-dialog SIP OPTIONS request sent to a SIP server to check that it is reachable and processing signalling. The server replies with a SIP response code and usually an Allow header listing the methods it supports. Because it never creates a call, an OPTIONS ping is safe to send continuously, which is why it is the standard keepalive mechanism between SBCs, PBXs and carriers — Cisco CUBE calls it options-keepalive, Asterisk calls it qualify.
Which SIP OPTIONS response codes mean the server is up?
Any response below 500 means the server is alive and processing SIP, including 403 Forbidden, 404 Not Found, 405 Method Not Allowed and 486 Busy Here. Those codes indicate policy or routing decisions, not failure — the server had to be working in order to send them. Response codes in the 5xx range, such as 500 Server Internal Error and 503 Service Unavailable, indicate a real problem, and so does no response at all, though a silent drop is more ambiguous because many SBCs discard SIP from unknown source addresses by design.
How is a SIP OPTIONS check different from a ping or a port check?
ICMP ping tests whether the host responds to network-layer echo requests, and a TCP port check tests whether something accepts a connection on port 5060. Neither proves that a SIP stack is running, that it is registered upstream, or that it will accept a call. A SIP process can be deadlocked, out of licences, or answering every INVITE with 503 while the host still pings and the port still accepts connections. An OPTIONS check exercises the application layer, so it fails when SIP fails.
Should I send OPTIONS over UDP, TCP or TLS?
Send it over the transport your calls actually use, and ideally monitor each one separately. UDP and TCP can behave very differently through a NAT or firewall, and TLS adds certificate validity and handshake negotiation as extra failure modes that UDP monitoring will never reveal. If you terminate calls on 5061 over TLS, an OPTIONS check on 5060 over UDP tells you almost nothing about whether those calls will complete.
How often can I send OPTIONS without upsetting my carrier?
Every 30 to 60 seconds per endpoint is normal and widely expected. Some carriers rate-limit or blocklist sources that probe much faster than that, and a monitoring system that probes aggressively from multiple locations at once can look like the beginning of a scan. SIP Sentry probes at 60-second intervals by default, backs off when an endpoint is unstable rather than probing harder, and publishes its probe addresses so you can allowlist them.
Point one check at it and find out
Three monitors free, forever. No card, no sales call, first result inside a minute.