The call was placed but it never went live: your Call stayed in dialing or ringing and then landed on no_answer or failed, and audio never bridged. Every one of these means the same thing — the call never reached in_progress, the only status that guarantees a live media path. This page is a symptom → cause → fix map for that window, from “the trunk isn’t registered” to “the carrier rejected the number,” plus the Q.850 cause codes that tell you exactly why. Work it outcome-first: identify which status the call ended on, then find that row below. no_answer and failed fail for different reasons, so the status you land on already narrows it by half.
This page is about calls that never connect. If the call reaches in_progress but you can’t hear anything, that’s a media problem, not a signalling one — go to one-way audio. If the trunk itself won’t come up at all, start at SIP trunk issues.

​
First, read the ending status

Before anything else, look at where the call ended. The call lifecycle explains how each status maps to a SIP moment; for triage, this is the short version:
Ended onWhat it meansLook at
dialingThe INVITE never got past the gateway — no route, or trunk down.Trunk registration, number format, routing.
ringingFar end alerted but never answered.Ring timeout, no_answer causes.
no_answerRing timeout, busy, or unavailable before any answer.Ring timeout, Q.850 16/17/18/19.
failedRejected outright, or media setup failed.SIP auth, ACL, number format, Q.850 1/21/28/34/38.
completed means the call did connect and then ended — that’s not this page. no_answer and failed both mean never connected, and the split matters: failed is almost always a rejection you can fix (auth, format, ACL), while no_answer is usually the far end (busy, nobody home, ring timeout).

​
Symptom → cause → fix

You don’t read raw SIP off the wire in normal use — the gateway speaks it for you and collapses it into CallStatus. The SIP codes below appear in the per-call event timeline and CDR (via the cleared event’s Q.850 cause), which you read in call traces. Use them to pinpoint the row, not as something you handle in code.
SymptomLikely causeFix
Outbound call falls straight to failed, no ring. CDR shows no route.Trunk not registered / down. A register-mode trunk lost its registration, so there’s no path to the carrier.Confirm the trunk is up and registered on SIP trunking; check credentials and register_expires_sec. IP-authenticated trunks don’t register — verify the carrier has your gateway’s source IP allow-listed instead.
failed immediately; trace shows 401/407 then give-up.SIP digest auth failing. Wrong sip_username/sip_password, or a stale nonce.Re-check the trunk’s SIP username and password (stored sealed — re-enter, don’t guess). The registrar rejects replayed nonces, so a client reusing an old challenge also 401s; make sure the trunk re-authenticates on each challenge.
Inbound call from your carrier is dropped; you never see it.Source-IP ACL / spam filter. The gateway only accepts INVITEs from configured trunk source IPs; unknown sources are refused before routing.Add the carrier’s signalling IP to the trunk source-IP list / SIP ACL. Trunk INVITEs bypass the registrar ACL, but the source IP still has to match a known trunk.
failed with a 4xx on the very first response. Trace shows 484/404.Wrong number format. The dialed number isn’t E.164, or the carrier expects a different digit string.Dial full E.164 (+ and country code, e.g. +15551234567). Some carriers want no +, or a specific technical prefix — set that on the trunk’s dial rules, don’t hand-mangle in your app.
Inbound INVITE arrives but routes nowhere → failed.No trunk/DID match, or no route decision. The gateway couldn’t resolve the trunk (by DID then source IP) or the routing engine returned no destination.Confirm the DID is provisioned and mapped to a trunk and an agent/flow — see number provisioning. Check the inbound rule points at a real agent, skill, or VDN.
Call rings, then no_answer at a fixed number of seconds.Ring timeout hit. No 200 OK arrived before ringTimeoutSec elapsed.Expected when nobody picks up. If it’s too aggressive, raise ringTimeoutSec (server-clamped 5–120, default 30). If it’s always exactly the timeout, the far end may be black-holing the INVITE — check routing and the destination.
no_answer well before the timeout; trace shows 486.Far end busy (Q.850 17).Nothing to fix at the gateway — the callee is on another call. Retry with backoff, or route to voicemail/callback.
no_answer; trace shows 480.Callee unavailable / not registered (Q.850 18/20). For an agent leg, the SIP phone isn’t registered.For carrier legs, retry later. For a human-agent SIP phone, confirm it’s registered (its AOR is live) — see PBX & ACD.
Answer happens (200 OK) but the call drops instantly at pickup.180-without-SDP carrier teardown, or SDP/codec mismatch. Some carriers send an unsolicited BYE if early media wasn’t offered correctly.The gateway answers with 183 Session Progress carrying SDP (not a bare 180) precisely to avoid this. If you’re bridging your own carrier and see this, confirm your SBC/carrier isn’t stripping the 183+SDP. See the warning in call lifecycle.
Outbound campaign calls fail in bulk but single calls work.Concurrency / pacing limits, or per-trunk channel cap. Too many simultaneous INVITEs for the trunk’s licensed channels.Lower calls_per_second / max_concurrent_calls on the paced dialer; confirm the carrier’s channel limit. Individual no_answer/busy within a campaign are normal.

​
Q.850 cause codes

When a call clears, the gateway records an ITU-T Q.850 cause code alongside the status. It’s the single most precise “why” you have, and it rides the cleared lifecycle event and the CDR — read it in call traces. These are the codes you’ll see on a call that never connected:
Q.850NameWhat it tells youTypical CallStatus
1Unallocated numberThe dialed number doesn’t exist / isn’t routable at the carrier.failed
16Normal clearingClean hang-up — you see this on a call that did connect, not a failure.completed
17User busyCallee is on another call.no_answer
18No user respondingINVITE reached the far end but got no reply (black hole).no_answer
19No answer (alerted)It rang, nobody picked up before timeout.no_answer
20Subscriber absentEndpoint not registered / device off (common for agent SIP phones).no_answer
21Call rejectedFar end actively refused (403/603) — often policy or auth.failed
28Invalid number formatNumber wasn’t in the form the carrier expects (E.164 / prefix).failed
34No circuit / channel availableTrunk out of channels — concurrency cap.failed
38Network out of orderCarrier-side network fault.failed
41Temporary failureTransient carrier issue — safe to retry.failed
Q.850 17 / 18 / 19 / 20 are all “the far end didn’t answer” and surface as no_answer — retry logic is the right response. Q.850 1 / 21 / 28 / 34 are rejections that surface as failed — retrying the same call the same way won’t help; fix the number, the auth, the ACL, or the channel cap first.

​
Step-by-step: isolate a call that won’t connect

1

Read the ending status and Q.850 cause

Pull the call’s timeline in call traces (or the cleared event / CDR). Note the terminal CallStatus and the Q.850 cause. That pair alone points you at a row above: failed + cause 21/28 → your side (format or auth); no_answer + 17/18/19 → the far end.
2

Confirm the call left the building

If it never got past dialing, the INVITE didn’t route. For outbound, verify the trunk is registered / IP-authed and the trunk resolved. For inbound, verify the DID is provisioned and the source IP matches a known trunk (unknown sources are refused before routing).
3

Check the number format

Dial E.164 (+<country><number>). A 484/404/28 almost always means the digit string was wrong for that carrier. Set any technical prefix or +-stripping on the trunk’s dial rules rather than editing the number in your app.
4

Rule out auth and ACL

A 401/407 loop that ends in give-up is digest auth: re-enter the trunk sip_username / sip_password (they’re sealed — re-set, don’t read back). An inbound INVITE that vanishes with no response is usually the source-IP ACL — add the carrier’s signalling IP. See SIP trunk issues.
5

Right-size the ring timeout

If the call rings and dies at a fixed second count, that’s ringTimeoutSec (default 30, clamp 5–120). Raise it for slow-to-answer destinations; if it hits the timeout every time, the far end is black-holing the INVITE — go back to routing, not the timeout.
6

For campaigns, back off the pacing

Bulk failed with cause 34 (no channel) is a concurrency ceiling. Lower calls_per_second and max_concurrent_calls on the paced dialer to stay under the trunk’s licensed channels.

​
Setting a sane ring timeout

ringTimeoutSec caps the ringing stage. If no 200 OK arrives in time, the gateway stops waiting and the call lands on no_answer instead of ringing forever — so you get a deterministic terminal status you can branch on. 
import { Voice } from "@telequick/sdk/voice";

const v = new Voice({
  baseUrl: "https://engine.telequick.dev",
  apiKey:  process.env.TELEQUICK_CREDENTIALS!,
  orgId:   "org_abc",
});

const call = await v.calls.originate({
  to:      "+15557654321",   // E.164 — full country code, no hand-mangling
  from:    "+15551234567",
  trunkId: "trunk_default",
  agent:   "sales-qualifier",
  ringTimeoutSec: 45,        // clamp 5–120; → no_answer if unanswered in 45s
});

console.log(call.status);    // "dialing" — not yet connected

const now = await v.calls.get({ sid: call.sid });
if (now.status === "in_progress") {
  // connected — media is live
} else if (now.status === "no_answer") {
  // rang out / busy — retry with backoff or route to voicemail
} else if (now.status === "failed") {
  // rejected — read the Q.850 cause before retrying the same way
}
Don’t retry a failed call with cause 21 (rejected), 28 (bad format), or 1 (unallocated) unchanged — it’ll fail identically. Fix the underlying cause first. Cause 34 (no channel) and 41 (temporary) are safe to retry with backoff, as is any no_answer.

Call lifecycle

How SIP signalling maps to each CallStatus and where media comes up.

SIP trunk issues

When the trunk won’t register, authenticate, or route.

One-way audio

The call connected but audio only flows one direction.

Number provisioning

Provision a DID and map it to a trunk, agent, or flow.

SIP trunking

Bring your own trunk or use a managed one; registration and IP auth.

Call traces

Read the per-call event timeline and Q.850 cause after the fact.