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
Know before your customer calls.
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.
sipsentry-probe · eu-westoptions over tls
probesbc01.acme-telecom.nl:5061
OPTIONS sip:acme-telecom.nl
Via: SIP/2.0/TLS · SNI acme-telecom.nl · Max-Forwards: 70
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS · Server: SBC/9.2
up11 mscert 58 dSRV oknext check in 60 s
checks
Checks that speak SIP, not just TCP
A port being open tells you nothing about whether calls complete. Each check exercises the protocol layer where telephony really fails.
Registration path
A 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→200Certificate expiry
Handshake with correct SNI, expiry countdown, chain and hostname verification. Still reports expiry on self-signed SBC certs instead of choking on them.
58 dDNS discovery chain
Validates 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.
okNetwork baseline
Round-trip latency and packet loss to your edge. On a probe that cannot send ICMP, such as an unprivileged container, it times a TCP connect instead and records which one it measured.
4 msTest calls with quality scoring
Places 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.312Every OPTIONS, REGISTER and test-call result keeps the SIP messages behind it. Open one in the app and read the exchange as a ladder, headers included.
Built for the 3 AM shift
A monitoring product earns exactly one thing: trust. These rules are wired into the code, not written on a values page.
timeout ≠ down
SBCs drop OPTIONS from unknown sources by policy. Each OPTIONS monitor decides whether a timeout means down or degraded, and new ones start at degraded. Rules pick their events, so degraded can go to chat and only down to the pager.
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 probe ≠ 1 verdict
When a check fails, the other probes in the region re-run it straight away and the majority decides. A probe that starts disagreeing with the fleet across several customers at once is taken out of the vote automatically.
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.
stored ≠ readable
SIP passwords are encrypted with AES-256-GCM on arrival, returned by no endpoint, and decrypted only to hand to a probe over WSS for the length of one check.
probes
Probes that run anywhere, including inside your network
Probes connect outbound over WebSocket. No inbound ports, no VPN, no firewall tickets. Use our vantage points, or, on Pro and MSP, run the same single binary next to the SBC that only accepts SIP from known addresses.
- One static binary or container, no local state, no stored credentials
- Results buffered through connection loss, deduplicated on arrival
- Cloud probe addresses for SBC allowlists, on the Probes page and at /api/v1/probe-addresses
# run a private probe
$ docker run -d --restart unless-stopped \
-e API_URL=wss://app.sipsentry.net/probe/v1/connect \
-e PROBE_TOKEN=••••••••••••• \
sipsentry/probe
probe connected · region=ams-dc2 · checks=6
app.sipsentry.net/status/acme-telecom
All systems operational
SIP trunkUp
RegistrarUp
TLS certificateUp
A status page for every customer you manage
From Pro, group monitors per customer and give each one a public status page with 90 days of uptime history. On the MSP plan you also route alerts per customer, and the page carries your title and logo and drops our footer, so your customers see their voice platform, not your tooling.
Alerts go where your team lives: email and HMAC-signed webhooks on every plan, and from Pro Slack, plus Telegram and SMS through your own bot and SMS gateway.
questions
What SIP monitoring actually means
What is SIP monitoring?
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.
Why is a ping or port check not enough for a phone system?
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.
Do I have to open firewall ports to be monitored?
No. Cloud probes reach your infrastructure over the public internet exactly as a carrier would. If your SBC filters SIP by source address, allowlist them: the current list is on the Probes page in the app and at https://app.sipsentry.net/api/v1/probe-addresses. 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.
Will a monitoring system page me for a firewall rule?
It should not, and SIP Sentry is built so that it does not have to. SBCs drop SIP from unknown sources by policy, so each OPTIONS monitor chooses whether a timeout counts as down or degraded, and new ones start at degraded. Alert rules choose which events they carry, so degraded can go to a team channel while only down reaches the pager. A failed check is re-run straight away from the other probes and the majority decides, and an alert needs N consecutive failed rounds before firing and M successes before clearing. If the probes themselves lose coverage, monitors go to unknown and no customer alert fires at all.
How much does SIP monitoring cost?
SIP Sentry is free for three monitors at a five-minute interval, with no time limit. The Pro plan is €29 per month for 50 monitors at a one-minute interval, and the MSP plan is €99 per month for 250 monitors with white-label status pages. Every plan includes all six check types, every alert channel, customer groups, public status pages and private probes. Pricing is per monitor rather than per user or per customer.
Your first monitor is two minutes away
Three monitors free, forever. Point one at your trunk and see the first OPTIONS result before your coffee is done.