SIP reachability
OPTIONS pings over UDP, TCP, and TLS with real transaction timers. Any answer below 500 counts as alive: SBCs reply 405 or 486 by design, and we know that.
200// SIP monitoring, done by SIP people
Generic uptime tools can't read a 503. SIP Sentry speaks real SIP to your trunks, registrars, and SBCs, and pages you only when something is actually wrong.
checks
A port being open tells you nothing about whether calls complete. Each check exercises the protocol layer where telephony really fails.
OPTIONS pings over UDP, TCP, and TLS with real transaction timers. Any answer below 500 counts as alive: SBCs reply 405 or 486 by design, and we know that.
200A real REGISTER with digest auth (MD5 and SHA-256) against a dedicated test extension. Exercises the auth path that actually breaks, then removes its own binding.
401→200Handshake with correct SNI, expiry countdown, chain and hostname verification. Still reports expiry on self-signed SBC certs instead of choking on them.
58 dValidates the full RFC 3263 chain: NAPTR, SRV per service, and A/AAAA for every target, not just the one a phone would pick. Broken SRV kills trunks silently.
okRound-trip latency and packet loss to your edge. When ICMP is filtered, it measures TCP connect time instead, and tells you which one it measured.
4 msPlaces a real call to a dedicated echo extension, streams G.711, and scores the returning audio with the ITU-T G.107 E-model from measured jitter, loss and round-trip delay. Catches one-way audio, which signaling never sees.
4.312A monitoring product earns exactly one thing: trust. These rules are wired into the state machine, not written on a values page.
timeout ≠ down
SBCs drop OPTIONS from unknown sources by policy. Every monitor chooses whether a timeout means down or degraded, so a firewall rule never pages your on-call.
unknown ≠ down
If our probes lose coverage, your monitors go unknown and no customer alert fires. You will never page a customer because our infrastructure had a bad night.
1 flap ≠ 1 page
N consecutive failures before an alert, M successes before recovery, per monitor. One lost UDP datagram is a statistic, not an incident.
delayed ≠ deleted
Every notification is queued in the same transaction as the state change and retried with backoff. A crash mid-send delays an alert; it never deletes one.
probes
Probes connect outbound over WebSocket. No inbound ports, no VPN, no firewall tickets. Use our vantage points, or run the same single binary next to the SBC that only accepts SIP from known addresses.
# run a private probe
$ docker run -d \
-e API_URL=wss://api.sipsentry.net/probe/v1/connect \
-e PROBE_TOKEN=••••••••••••• \
sipsentry/probe
probe connected · region=ams-dc2 · checks=5
status.acme-telecom.nl
All systems operational
Group monitors per customer, route alerts per customer, and give each one a public status page with 90 days of uptime history. White-label it with their name and logo on the MSP plan. Your customers see their voice platform, not your tooling.
Alerts go where your team lives: email, signed webhooks, Slack, Telegram, and SMS.
questions
SIP monitoring is the continuous testing of voice infrastructure using the SIP protocol itself, rather than with generic network checks. A SIP monitor sends real SIP requests — OPTIONS to prove an endpoint is processing signalling, REGISTER to prove the authentication path works, and sometimes a full INVITE to place a test call — and interprets the SIP response codes that come back. It also covers the layers SIP depends on: TLS certificate validity on the SIP TLS port, and the NAPTR and SRV records that route calls to the platform. This matters because a host can respond to ping, accept connections on port 5060, and still fail every call.
Because almost every way a phone system fails leaves the host reachable and the port open. A registration can expire, so inbound calls stop while the trunk answers everything you send it. A TLS certificate can expire, so every encrypted device drops off while port 5061 still accepts TCP connections. One SRV target can die, so half your calls disappear into a black hole. A platform can hit its calls-per-second limit and answer every INVITE with 503. None of those change the result of an ICMP ping or a TCP connect.
No. Cloud probes reach your infrastructure over the public internet exactly as a carrier would, and their addresses are published so you can allowlist them on an SBC that filters SIP. If you would rather test from inside the network, a private probe runs as a single static binary or container and connects outbound over WebSocket, which needs no inbound rule, no VPN and no port forward.
It should not, and SIP Sentry is built so that it does not. A timeout is classified as degraded rather than down, because SBCs drop SIP from unknown sources by policy and that is not an outage. Alerts require N consecutive failures before firing and M consecutive successes before clearing, so a single lost UDP datagram is a statistic rather than an incident. If the probes themselves lose coverage, monitors go to unknown and no customer alert fires at all.
SIP Sentry is free for three monitors at a five-minute interval, with every check type included and no time limit. The Pro plan is €29 per month for 50 monitors at a one-minute interval, and adds customer groups, public status pages, private probes and the full set of alert channels. Pricing is per monitor rather than per user or per customer.
Three monitors free, forever. Point one at your trunk and see the first OPTIONS result before your coffee is done.