> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Where to look first when an outbound call fails

> A decision tree for outbound voice-call failures: read the live-console failure badge, the call log's terminal disposition, wallet posture, caller-ID posture, route health, carrier rejections, dialer callbacks, Jambonz control-plane signals, and when to escalate.

# Where to look first when an outbound call fails

This guide turns the scattered signals for an outbound voice-call failure into one debugging order. Start at the live console's failure badge, confirm the terminal disposition, then follow the decision tree to wallet, caller-ID, route, carrier, dialer, or Jambonz layers.

The companion surfaces are documented in their own pages:

* [Reading the Voice → Calls console](/guides/voice-calls-call-logs) — call logs, detail sheets, and timelines.
* [Delivery log](/guides/delivery-log) and [Developer → Delivery Logs](/guides/developer-delivery-logs) — cross-channel search and API-level delivery detail.
* [Run an outbound dialer campaign live](/guides/dialer-live-console) — live campaign widgets, pause/abort, and AMD/outcome counters.

## What the inbox receives on a failed outbound call

A failed outbound call lands in **Voice → Calls** as a row with a terminal status badge. The most common terminal dispositions are:

| Disposition | What it means | First check |
| - | - | - |
| `busy` | The destination line returned a busy signal. | Redial later or schedule a callback. |
| `no-answer` | The call rang for the configured timeout without an answer. | Open the timeline to see whether it ever reached ringing. |
| `canceled` | The call was canceled before completion — by the caller, a pacing rule, or a campaign abort. | Confirm whether the cancellation was intentional. |
| `failed` | The call failed before a conversation could start. | Read the per-row failure reason and timeline last event. |

The row's **failure reason** narrows the cause:

| Failure reason | Points to | Typical fix |
| - | - | - |
| `routing_error` | No route could be selected for the destination. | Destination capability, route health, or carrier routing table. |
| `rejected_by_carrier` | The downstream carrier refused the call. | Caller ID, attestation, ANI block, or destination restriction. |
| `no_route_available` | No healthy route is available for this destination/country. | Route-quality circuit breaker, provider suspension, or wallet. |

The timeline tells you *where* in the flow the failure happened. A `failed` row whose last event is `initiated` usually failed at origination (carrier rejected the setup). A `no-answer` row whose timeline stops at `queued` never rang — the failure is capacity-side, not destination-side.

## Step 1: Wallet posture — distinguish a platform pause from a carrier rejection

Before chasing carriers, confirm the account can spend. Outbound voice is gated by wallet balance. A campaign whose wallet is empty pauses at the platform layer, so calls fail with no carrier signal at all.

Check the wallet in one call:

```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/billing/wallet \
  -H "X-API-Key: dv_live_sk_..."
```

```json theme={null}
{
  "data": {
    "currency": "USD",
    "balance_minor": 123400,
    "available_minor": 123400,
    "status": "active"
  }
}
```

* `balance_minor` is the ledger balance; `available_minor` is what can be spent after holds.
* A `status` other than `active` — for example `paused` or `blocked` — is a platform spend gate, not a carrier problem.
* If the balance is low, set up [wallet auto-top-up](/guides/billing-auto-topup) so unattended campaigns do not stall.

How to tell the two apart: carrier rejections usually show a `rejected_by_carrier` reason on a call row, while wallet-driven failures cluster across *all* outbound calls at once and often coincide with a campaign pause notice in the live console.

## Step 2: Caller-ID posture — 403-class failures and unverified IDs

A 403-class failure or a carrier rejection of an unverified caller ID means the number presented on the outbound call is not allowed.

Common caller-ID failure patterns:

* **Unverified caller ID used where verification is required.** Some destinations require the caller ID to be a verified number in your account. Use [outbound caller IDs](/guides/voice-caller-ids) to register and confirm numbers you control.
* **Ownership mismatch.** The carrier believes you do not own or cannot prove control of the presented number. Verify the number, or switch to an Orbit-hosted number that already attests at level A.
* **Caller ID blocked by the destination.** The receiving operator or a downstream carrier blocks the ANI. Rotate to a verified pool of numbers or use local-presence matching if your campaign supports it.

In the dialer live console, the **Caller-ID coverage** widget shows whether your caller-ID pool covers the destination NPAs your leads are in. A red coverage gap does not cause failures directly, but it flags that you may be presenting out-of-region numbers the destination treats as suspicious.

The fix route:

1. Verify the caller ID in **Voice → Outbound caller IDs** or via `POST /api/v1/voice/caller-ids/verify`.
2. If the destination rejects the verified ID, rotate to another verified ID or an Orbit-hosted number.
3. For persistent blocks, open a support ticket with example call IDs and the rejected caller ID.

## Step 3: Destination-carrier rejections

Carrier rejections that are not wallet- or caller-ID-related usually fall into one of three buckets:

### Stir/Shaken attestation mismatch

US outbound calls carry a Stir/Shaken attestation level. An A-level attestation requires an Orbit-hosted number with a verified identity. If the call presents a B- or C-level attestation, some downstream carriers downgrade or block it. Read the call-detail attestation field and compare it to the [Stir/Shaken posture guide](/compliance/stir-shaken-posture-guide).

### ANI-blocked destinations

Some destinations block calls from specific ANI ranges or from numbers that do not match a local geographic pool. If rejections cluster on one destination prefix, check whether the carrier or regulator blocks the presented caller ID. The route-quality surface is SMS/MMS-focused, but the same investigative habit applies: cluster failures by destination network and look for a pattern.

### Route-quality circuit breaker

For SMS/MMS routes, the [route-quality circuit breaker](/guides/route-quality-circuit-breaker-runbook) auto-suspends a failing route. Voice routes do not yet run the same breaker, but the dashboarding pattern is identical: when a destination operator shows a spike in `rejected_by_carrier` rows, check whether a route or provider health incident is active and fail over to an alternative route if one is configured.

## Step 4: Jambonz-side failures

Voice calls route through the Jambonz control plane. Failures here show up as control-plane errors, missing call legs, or AMD/dialer callback mismatches.

### `dialer-amd-callback` unknown call\_sid

If the dialer posts an AMD callback (`amd`, `human`, `machine`, etc.) but the platform cannot find the call SID, the callback likely arrived after the call record was cleaned up, or the SID in the callback does not match the SID in the originating request. Check:

* The campaign's AMD callback URL and timeout.
* Whether the call row in Voice → Calls still exists for the SID in the callback.
* Whether the callback payload matches the expected schema (`call_sid`, `status`, `event`, `reason`).

### Control-plane redirect

When a call is redirected or transferred through the Jambonz control plane, a mismatch between the redirect target and the registered application can cause the call to drop. The test fixture for control-plane redirect is the reference shape: a redirect must target an application that exists and is reachable from the same tenant context.

### Reading Sentry and counter spikes

When Jambonz-side failures spike, look at two signals together:

1. **Error counters** for the voice gateway — `voice_gateway_control_plane_errors`, `dialer_amd_callback_mismatches`, or similar.
2. **The Sentry trace** for the failed call, linked from the call detail's request id.

A spike in only the counter suggests a provider-side shape change (for example, a new AMD reason string). A spike in both counter and Sentry suggests a platform regression. Open an incident ticket when both move together.

## Step 5: Campaign pacing self-heals

The platform applies back-pressure to campaigns that hit spend gates, compliance windows, rate limits, or abandon-rate ceilings. When this happens, the live console shows a pause badge and an explanatory banner. In most cases you should leave the campaign paused until the gating condition clears:

* **Wallet empty** → top up or wait for auto-top-up.
* **Abandon rate above ceiling** → the dialer pauses claiming to protect against TCPA exposure; review agent staffing or pacing ratio before resuming.
* **Compliance window closed** → the campaign will resume in the next allowed window.
* **Rate limit hit** → pause is temporary; wait for the bucket to drain.

The action bar on the dialer campaign page shows **Resume** only when the gating condition is resolvable in-console. If the button is disabled, read the banner for the exact gate.

## Triage matrix: live-console failure badge to fix route

| Console signal | Next check | Likely fix route |
| - | - | - |
| Failure badge across all outbound calls | Wallet status (`GET /api/v1/billing/wallet`) | Top up or enable auto-top-up. |
| Failure badge on one campaign only | Campaign pause banner / dialer live console | Wait for back-pressure to clear, or adjust pacing. |
| `rejected_by_carrier` with caller-ID warning | Caller-ID verification and coverage widget | Verify or rotate caller IDs. |
| `routing_error` / `no_route_available` | Route health and destination capability | Check route-quality scores, provider health, destination blocks. |
| `failed` with last event `initiated` | Jambonz control-plane logs / Sentry | Investigate control-plane redirect or callback mismatch. |
| `no-answer` timeline stops at `queued` | Dialer capacity / agent availability | Raise concurrent-call cap or widen agent pool. |
| `busy` | Per-destination redial policy | Schedule callback. |

## Escalation path: in-console fix vs. support ticket

Most failures resolve in-console. Escalate to Devotel Orbit support when:

* A `rejected_by_carrier` cluster points to a carrier-side block you cannot lift by rotating caller IDs.
* A `routing_error` cluster suggests a provider routing table issue.
* Jambonz-side errors spike and the call-detail request ids point to platform traces.
* Wallet is active and funded, but all outbound calls still fail.

Open the ticket from **Support → Timeline** with:

* Example call IDs (`call_...`) from Voice → Calls.
* The terminal disposition and failure reason.
* The caller ID presented and whether it is verified.
* The destination number or prefix cluster affected.
* The request id from the call detail, if available.

For day-to-day workflow guidance on Support → Timeline, see the [support timeline operator guide](/guides/support-timeline-operator-guide).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.