Skip to content

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

OPTIONS

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
REGISTER

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→200
TLS

Certificate 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 d
NAPTR/SRV

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

ok
ICMP

Network baseline

Round-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 ms
RTP / MOS

Test 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.312

Built for the 3 AM shift

A 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 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 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 IPs published for SBC allowlisting

# 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

SIP trunkUp
RegistrarUp
TLS certificateUp

A status page for every customer you manage

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.

how MSPs run this across customers

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

Will a monitoring system page me for a firewall rule?

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.

How much does SIP monitoring cost?

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.

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.