Call Does Not Connect

The call was placed but it never went live. Your Call stayed in dialing or ringing, then landed on no_answer or failed. Audio never bridged. Each of these outcomes means the same thing: the call never reached in_progress. That is the only status that guarantees a live media path. This page is a symptom → cause → fix map for that window. It covers causes from “the trunk is not registered” to “the carrier rejected the number”. It also lists the Q.850 cause codes that tell you exactly why. Start from the outcome. Identify the status the call ended on. Then find that row below. no_answer and failed have different causes, so the ending status already cuts the search in half.

This page is about calls that never connect. If the call reaches in_progress but you cannot hear anything, that is a media problem, not a signalling problem. Go to one-way audio. If the trunk itself does not 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 on	What it means	Look at
`dialing`	The `INVITE` never got past the gateway. There was no route, or the trunk was down.	Trunk registration, number format, routing.
`ringing`	The far end alerted but never answered.	Ring timeout, `no_answer` causes.
`no_answer`	Ring timeout, busy, or unavailable before any answer.	Ring timeout, Q.850 16/17/18/19.
`failed`	The call was rejected, 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 is not this page. no_answer and failed both mean the call never connected, and the split matters. failed is almost always a rejection that you can fix (auth, format, ACL). no_answer is usually the far end (busy, no person there, ring timeout).

Symptom → cause → fix

You do not read raw SIP off the wire in normal use. The gateway speaks SIP 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). Read them in call traces. Use them to find the correct row, not as something you handle in code.

Symptom	Likely cause	Fix
The outbound call falls straight to `failed`, with no ring. The CDR shows no route.	The trunk is not registered, or it is down. A register-mode trunk lost its registration, so there is no path to the carrier.	Check that the trunk is up and registered on SIP trunking. Check the credentials and `register_expires_sec`. IP-authenticated trunks do not register — check that the carrier allow-listed your gateway’s source IP instead.
`failed` immediately. The trace shows `401`/`407`, then a give-up.	SIP digest auth fails. The `sip_username`/`sip_password` is wrong, or the nonce is stale.	Check the trunk’s SIP username and password again. They are stored sealed, so enter them again — do not guess. The registrar rejects replayed nonces, so a client that reuses an old challenge also gets `401`. Make sure the trunk authenticates again on each challenge.
An inbound call from your carrier is dropped. You never see it.	The source-IP ACL or spam filter blocks it. The gateway accepts INVITEs only from configured trunk source IPs. It refuses unknown sources 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 must match a known trunk.
`failed` with a `4xx` on the first response. The trace shows `484`/`404`.	The number format is wrong. The dialed number is not E.164, or the carrier expects a different digit string.	Dial full E.164 (`+` and country code, for example `+15551234567`). Some carriers want no `+`, or a specific technical prefix. Set that on the trunk’s dial rules. Do not change the number in your app.
An inbound INVITE arrives but routes nowhere → `failed`.	No trunk/DID match, or no route decision. The gateway could not resolve the trunk (by DID, then by source IP), or the routing engine returned no destination.	Check that the DID is provisioned and mapped to a trunk and an agent/flow — see number provisioning. Check that the inbound rule points at a real agent, skill, or VDN.
The call rings, then goes to `no_answer` at a fixed number of seconds.	The ring timeout fired. No `200 OK` arrived before `ringTimeoutSec` elapsed.	This is the expected result when no person answers. If it fires too early, raise `ringTimeoutSec` (server-clamped 5–120, default 30). If the call always ends exactly at the timeout, the far end possibly black-holes the INVITE — check the routing and the destination.
`no_answer` well before the timeout. The trace shows `486`.	The far end is busy (Q.850 17).	There is nothing to fix at the gateway. The callee is on another call. Retry with backoff, or route to voicemail/callback.
`no_answer`. The trace shows `480`.	The callee is unavailable or not registered (Q.850 18/20). For an agent leg, the SIP phone is not registered.	For carrier legs, retry later. For a human-agent SIP phone, check that it is registered (its AOR is live) — see PBX & ACD.
The answer occurs (`200 OK`) but the call drops instantly at pickup.	A `180`-without-SDP carrier teardown, or an SDP/codec mismatch. Some carriers send an unsolicited `BYE` if early media was not offered correctly.	The gateway answers with `183 Session Progress` that carries SDP (not a bare `180`) to prevent this. If you bridge your own carrier and see this, check that your SBC/carrier does not strip the `183`+SDP. See the warning in call lifecycle.
Outbound campaign calls fail in bulk, but single calls work.	Concurrency or pacing limits, or the per-trunk channel cap. There are too many simultaneous INVITEs for the trunk’s licensed channels.	Lower `calls_per_second` / `max_concurrent_calls` on the paced dialer. Check the carrier’s channel limit. Individual `no_answer`/busy results in a campaign are normal.

Q.850 cause codes

When a call clears, the gateway records an ITU-T Q.850 cause code with the status. It is the most precise “why” you have. It rides the cleared lifecycle event and the CDR. Read it in call traces. These are the codes you will see on a call that never connected:

Q.850	Name	What it tells you	Typical `CallStatus`
1	Unallocated number	The dialed number does not exist, or the carrier cannot route it.	`failed`
16	Normal clearing	A clean hang-up. You see this on a call that did connect, not on a failure.	`completed`
17	User busy	The callee is on another call.	`no_answer`
18	No user responding	The INVITE reached the far end but got no reply (black hole).	`no_answer`
19	No answer (alerted)	The call rang, and no person answered before the timeout.	`no_answer`
20	Subscriber absent	The endpoint is not registered, or the device is off (common for agent SIP phones).	`no_answer`
21	Call rejected	The far end refused the call (`403`/`603`) — often policy or auth.	`failed`
28	Invalid number format	The number was not in the form the carrier expects (E.164 / prefix).	`failed`
34	No circuit / channel available	The trunk is out of channels — a concurrency cap.	`failed`
38	Network out of order	A carrier-side network fault.	`failed`
41	Temporary failure	A transient carrier issue. It is safe to retry.	`failed`

Q.850 17 / 18 / 19 / 20 all mean “the far end did not answer” and show as no_answer. Retry logic is the correct response. Q.850 1 / 21 / 28 / 34 are rejections that show as failed. A retry of the same call in the same way does not help. Fix the number, the auth, the ACL, or the channel cap first.

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

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.

Confirm the call left the building

If the call never got past dialing, the INVITE did not route. For outbound, check that the trunk is registered / IP-authed and that the trunk resolved. For inbound, check that the DID is provisioned and that the source IP matches a known trunk. The gateway refuses unknown sources before routing.

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 a technical prefix or +-stripping on the trunk’s dial rules. Do not edit the number in your app.

Rule out auth and ACL

A 401/407 loop that ends in a give-up is digest auth. Enter the trunk sip_username / sip_password again. They are sealed — set them again, you cannot read them 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.

Right-size the ring timeout

If the call rings and dies at a fixed second count, that is ringTimeoutSec (default 30, clamp 5–120). Raise it for destinations that answer slowly. If the call hits the timeout every time, the far end black-holes the INVITE. Go back to routing, not the timeout.

For campaigns, back off the pacing

Bulk failed results with cause 34 (no channel) mean 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 the wait, and the call lands on no_answer instead of a ring that never ends. You get a deterministic terminal status that you can branch on.

TypeScript
Python

import { Voice } from "@clutchcall/sdk/voice";

const v = new Voice({
  baseUrl: "https://engine.clutchcall.dev",
  apiKey:  process.env.CLUTCHCALL_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
}

from clutchcall.voice import Voice

v = Voice(
    base_url="https://engine.clutchcall.dev",
    api_key=os.environ["CLUTCHCALL_CREDENTIALS"],
    org_id="org_abc",
)

call = v.calls.originate(
    to="+15557654321",         # E.164
    from_="+15551234567",
    trunk_id="trunk_default",
    agent="sales-qualifier",
    ring_timeout_sec=45,       # clamp 5–120; → no_answer if unanswered
)

print(call.status)             # "dialing"

now = v.calls.get(sid=call.sid)
if now.status == "in_progress":
    ...                        # connected
elif now.status == "no_answer":
    ...                        # rang out / busy — retry or voicemail
elif now.status == "failed":
    ...                        # rejected — check Q.850 cause first

Do not retry a failed call with cause 21 (rejected), 28 (bad format), or 1 (unallocated) without a change. It fails in the same way. Fix the cause first. Cause 34 (no channel) and 41 (temporary) are safe to retry with backoff. Any no_answer is also safe to retry with backoff.

Call lifecycle

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

SIP trunk issues

When the trunk does not register, authenticate, or route.

One-way audio

The call connected, but audio flows in one direction only.

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.

Overview

Quickstart

Core Concepts

Build Guides

Agent Runtime

Transport to Web & Apps

Transport to Telephony

CTI (CSTA)

High Availability

Comparison & Benchmarks

Migration

Integrations

Observability

SDK Reference

API Reference

Troubleshooting

Cookbooks

Recipes

Call Does Not Connect

First, read the ending status

Symptom → cause → fix

Q.850 cause codes

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

Setting a sane ring timeout

Call lifecycle

SIP trunk issues

One-way audio

Number provisioning

SIP trunking

Call traces

​First, read the ending status

​Symptom → cause → fix

​Q.850 cause codes

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

​Setting a sane ring timeout

​Related

Call lifecycle

SIP trunk issues

One-way audio

Number provisioning

SIP trunking

Call traces

First, read the ending status

Symptom → cause → fix

Q.850 cause codes

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

Setting a sane ring timeout

Related