Skip to main content

​
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:

​
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: The row’s failure reason narrows the cause: 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:
  • 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 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 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.

​
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 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

​
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.