Trunk stops answering
Carrier maintenance, SBC restart, route withdrawn upstream
OPTIONSseconds// sip trunk monitoring
Your trunk answers OPTIONS and still can't complete a call.
A SIP trunk has at least six independent ways to fail, and a ping tests none of them. SIP Sentry runs the checks that map to real failure modes — signalling, registration, TLS, DNS and audio — from outside your network and, when your SBC filters SIP, from inside it.
failure modes
Six ways a trunk dies, and what catches each one
Every one of these has happened to a trunk that was, at the time, green in a conventional network monitor.
Registration silently expires
Credential rotation, expires negotiated down, NAT binding lost
REGISTERone intervalCalls fail only over TLS
Certificate expired or chain incomplete after a renewal
TLS30 days earlyHalf your capacity vanishes
One SRV target dead, weight sending calls into a black hole
NAPTR/SRVone intervalFast busy at peak hour
CPS or channel limit hit — carrier answers 503
OPTIONS + test callsecondsConnected, but nobody hears anything
RTP blocked one way, NAT pinhole, transcoder out of resources
RTP / MOSone intervalregistration
Registration-based trunks fail quietly
An OPTIONS check keeps returning 200 long after a registration has lapsed, because the far end is perfectly happy to talk to you — it just won't send you any calls. Inbound simply stops, and nobody notices until a customer rings in on their mobile to ask why nobody can reach them.
The REGISTER check performs a real registration against a dedicated test extension, including the digest challenge with MD5 or SHA-256, then unregisters itself. It exercises the authentication path — which is the part that breaks when someone rotates a password or a carrier changes realm — and leaves no binding behind.
# register check, one cycle
→ REGISTER sip:pbx.example.net
← 401 Unauthorized (challenge)
→ REGISTER (digest, SHA-256)
← 200 OK expires=60
→ REGISTER Expires: 0
← 200 OK binding removed
auth path verified · 41 ms · no binding left
dns
Half a trunk is worse than no trunk
When a carrier publishes two SRV targets and one stops answering, you lose roughly half your calls and every dashboard stays green. A phone picks a target by priority and weight and never tells you about the one it skipped.
The DNS check walks the full RFC 3263 chain — NAPTR, then SRV per service, then A and AAAA for every target rather than the one a client would happen to choose — and alerts when any leg of it breaks. It is the cheapest check to run and the one that most often explains an intermittent complaint that nobody can reproduce.
questions
Straight answers
What is SIP trunk monitoring?
SIP trunk monitoring is the continuous testing of a SIP trunk using the SIP protocol itself rather than generic network probes. In practice that means periodically sending an OPTIONS request to the trunk endpoint and checking the response code, verifying that a registration can still be established where the trunk is registration-based, checking TLS certificate validity on port 5061, resolving the NAPTR and SRV records that route calls to the trunk, and optionally placing a test call to measure audio quality. A monitor that only checks whether TCP port 5060 accepts a connection will report a healthy trunk during most real outages.
How often should you send SIP OPTIONS to a trunk?
Once every 30 to 60 seconds per trunk is the normal range, and it is what most SBCs expect from an OPTIONS keepalive. Faster than every 30 seconds risks being treated as abusive by carriers who rate-limit signalling; slower than a couple of minutes means an outage can run longer than your customers will tolerate before you hear about it. SIP Sentry defaults to 60 seconds and offers 30 seconds on paid plans.
Does a non-200 response mean the trunk is down?
No. Plenty of healthy SBCs answer OPTIONS with 405 Method Not Allowed, 403 Forbidden, or 486 Busy Here, because answering at all is what proves the signalling path works. The useful rule is that any SIP response below 500 means the far end is alive and processing SIP, while 5xx responses and timeouts indicate a genuine problem. SIP Sentry applies exactly that rule, and treats a timeout as degraded rather than down when a firewall policy is the more likely explanation.
Can you monitor a SIP trunk that only accepts traffic from known IP addresses?
Yes, in two ways. You can allowlist SIP Sentry cloud probe addresses, which are published and stable, or you can run a private probe as a single binary or container inside your own network. A private probe connects outbound over WebSocket, so it needs no inbound firewall rule, no VPN and no port forward, and it tests the trunk from the same vantage point as your PBX.
Will monitoring a trunk with REGISTER disturb production registrations?
It will not, provided you point the check at a dedicated test extension rather than a live one. SIP Sentry registers with a low expiry, verifies the digest authentication challenge and the 200 OK, then removes its own binding with an Expires: 0 unregister so no call is ever routed to the monitor. Never point a REGISTER check at an extension that a real phone uses, because the platform may treat the second registration as a replacement and route calls to the monitor.
Point one check at it and find out
Three monitors free, forever. No card, no sales call, first result inside a minute.