Skip to main content

​
Troubleshooting: SIP trunk down or calls failing

A trunk that cannot register, or one that keeps completing fewer calls than you expect, shows up in three places: the SIP settings table in the dashboard, the registration diagnostic stored on the trunk itself, and the route-quality view. This page works through the checks in order, then covers what the platform does on its own when a trunk stops answering. Every API response below rides the standard envelope — data carries the payload, and meta.request_id is the correlation ID support asks for when you open a ticket:

​
Check the trunk’s registration status

Each trunk carries a cached registration verdict — registered, unregistered, or unknown — with the ISO timestamp of the last check. The cached verdict feeds the dispatch gate: a trunk whose registration check stays stale or failing stops being offered new calls. Confirm the current state either way:
  • Dashboard: open Settings → SIP trunks; the table marks unregistered trunks and shows the last recorded registration error inline per row.
  • API:
A healthy trunk answers with the verdict and the last-good registration metadata on the row:
lastRegisteredAt keeps the timestamp of the last successful register even while a trunk is currently failing, so compare it against lastRegistrationCheckAt — the streak fields (registrationFailureCount, registrationFailingSince) tell you how long the current failing run has been going. A wrong ID from another tenant is indistinguishable from one wrong in your own — ownership is never leaked across tenants — and reads 404:

​
Rank every trunk, needs-attention first

The snapshot ranks every trunk so the one that needs attention lands first, and the counts block totals by severity for a dashboard-style triage:
Severity ladder is down (unregistered) → degraded (failing streak without a down verdict) → active → unknown (no probe data yet); within the same severity the longest failing streak sorts first. Read the recorded registration error on the trunk first — most unregistered rows are one of four causes: DNS failing to resolve the host, a firewall blocking the SIP port, a digest username/password mismatch, or codec/TLS mismatch on the REGISTER handshake.

​
Force a fresh registration probe

The platform re-checks each enabled trunk on a cadence of about five minutes, running a real SIP REGISTER with the trunk’s stored credentials and persisting the verdict back onto the trunk row. To force a fresh check after you change something, run the trunk’s own test from the dashboard (“Test trunk”) or:
A passing probe answers reachable with the REGISTER round-trip latency, and the step checklist confirms the whole pipeline ran:
A still-failing probe returns unreachable and names the step that broke — DNS resolution, credentials, probe provisioning, the SIP gateway, or the REGISTER itself — with failed on the breaking step and skipped after it (on a timeout the hanging step reads pending):
The probe also records the outcome on the trunk row — the error string here is the same text the dashboard row and the trunk detail’s lastRegistrationError field carry afterward.

​
Common causes and how to fix them

​
What happens when a trunk fails

A failed trunk does not take its calls down with it.
  • When the primary trunk’s cached registration status is anything other than registered, the dispatch path walks the trunk’s failover chain — the backup trunk(s) you designate in the dashboard’s trunk settings — picking the first healthy candidate. The chain is guarded against loops and hops are bounded, so a miswired chain cannot recurse on itself.
  • When no usable failover exists — or none is configured — outbound calls still terminate: they land on the Devotel wholesale softswitch, the platform’s default outbound path, exactly as they would with no trunk configured at all.
  • Across your outbound trunk pool, keep capacity and quality spread: each trunk’s route-quality view scores its answer ratio (ACR) and capacity utilization and flags a saturated cap as blocked rather than failed, so you can tell “carrier is dropping the route” apart from “the trunk is full.”
Query the per-trunk route-quality snapshot:
Each ranked row carries the attempt/completion aggregates and their derived bands — acr is the answer-completion ratio, sdr the successful-delivery ratio with capacity-blocked attempts removed from the denominator, and qualityBand / capacityBand the verdicts the dashboard tiles color from:
Read the first row as the troubleshooting signal: capacityBand: blocked means the per-trunk concurrency guard IS dropping dispatches — raise capacityCap or spread traffic; qualityBand: bad with a low sdr means the carrier route is dropping calls independent of the cap. A trunk with no cap configured reads capacityBand: unconfigured, and one with no traffic in the window reads qualityBand: unknown — an empty window, not a healthy route. The window accepts 24h or 7d. Use the ranking to spot the trunk that should be taken out of rotation while you fix it.

​
Inbound trunk signals: the auth ledger

For incoming trunks — where your carrier originates calls toward the platform — each failed digest or allowlist attempt is recorded against the trunk for seven days. That is the first place to check when inbound calls stop arriving but the trunk row looks healthy: a burst of source IPs you have not allowlisted, a digest realm that never matches because the password rotated, or an ip_allowlist-only trunk queried from a carrier SBC whose egress IP changed. Read the ledger via the trunk detail surface in the dashboard, or:
Entries are newest-first — each carries the offending source IP, the SIP method, and the reason the attempt was rejected:
window accepts 24h, 7d, 1h, or a raw millisecond integer (clamped at the 7-day ledger retention). The ledger only exists on incoming trunks — ask for it on an outgoing trunk and the request fails 422:
And while call routing itself is unaffected, a temporarily unreadable ledger is surfaced honestly rather than painted as a clean window — that condition answers 503:

​
When to escalate

If you worked through the list, the trunk still shows unregistered, and the recorded error text has stopped matching anything on this page, open a support ticket with the trunk ID (trunk_…), the recorded registration error string from the row, and the timestamp of the last successful registration if the trunk previously registered. For calls that register and connect but sound wrong — one-way audio, dead air, choppy audio, or long post-dial delay — see Troubleshooting: voice call quality.