Skip to content

Getting started

SIP Sentry watches your SIP infrastructure from the outside: real OPTIONS, REGISTER, TLS, DNS and RTP test-call checks against your trunks, registrars, and SBCs, with alerting designed not to cry wolf.

1. Create your first monitor

Sign up, press New monitor, and pick a check type. A new monitor starts at the fastest interval your plan allows: every minute on Pro and MSP, every five minutes on Free.

  • SIP OPTIONS — the default. Point it at your SBC or trunk endpoint, pick a transport (UDP, TCP, or TLS). Any SIP answer below 500 counts as alive; 5xx and 6xx count as down. A timeout counts as degraded unless you set the monitor to treat it as down.
  • TLS certificate — point it at your SIP-over-TLS port (usually 5061). Set the SNI to your SIP domain, not the IP. Expiry warnings start 30 days out by default.
  • SIP REGISTER — create a dedicated test extension on your platform first (see REGISTER check safety), then give the monitor its credentials. Credentials are shared per customer, so REGISTER and RTP checks against one PBX can use the same record.
  • DNS SRV — point it at your SIP domain. It validates NAPTR (opt-in), SRV per service, and that every SRV target resolves.
  • Ping — ICMP latency and loss. On a probe that cannot send ICMP, it times a TCP connect instead and says so in the result.
  • RTP / MOS — 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. Read RTP / MOS check safety before you point it at anything.

2. Allowlist the probes (if your SBC filters SIP)

Good SBCs drop SIP from unknown sources. Two options:

  1. Allowlist the cloud probe addresses. The current list is on the Probes page in the app and at app.sipsentry.net/api/v1/probe-addresses, or
  2. On Pro or MSP, run a private probe inside your network — one container, outbound-only. Create it on the Probes page, which shows the exact command with your token filled in:
docker run -d --restart unless-stopped \
  -e API_URL=wss://app.sipsentry.net/probe/v1/connect \
  -e PROBE_TOKEN=<token from the Probes page> \
  sipsentry/probe:latest

If you can do neither and your SBC drops unsolicited OPTIONS, keep the monitor’s timeout behavior at degraded rather than down. That is what the setting is for.

3. Route the alerts

Signing up creates an email channel to your address and an org-wide rule pointing at it, so the first real alert reaches you without any setup.

Add more channels under Alerting: webhooks on every plan (signed with HMAC-SHA256 when you set a secret, see Security), and on Pro and MSP also Slack, Telegram with your own bot token, or SMS through your own HTTP SMS gateway. Then add rules: org-wide or per monitor on every plan, and per customer on MSP, each with the events it should carry. Use the test button on every channel. An alert channel you’ve never tested is a channel that doesn’t exist.

4. Group monitors by customer

On Pro and MSP, create a customer per client and assign monitors to it. Each customer can get a public status page (app.sipsentry.net/status/your-slug) with live states and 90 days of uptime. On MSP, per-customer alert routing gets the right engineer paged for the right client.

How alerting decides

  • When a check fails, the other probes in the region re-run it straight away and the majority decides. A probe that disagrees with the rest across several customers is taken out of the vote.
  • A monitor goes down only after N consecutive failed rounds (default 3) and recovers after M consecutive successes (default 2).
  • A timeout counts as down or degraded depending on the monitor’s setting; new OPTIONS monitors start at degraded.
  • If our probes lose coverage, monitors go unknown, which never fires customer alerts.

That’s it. Your first result lands within one check interval.

Next