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

# Inbound & outbound calls

> How calls reach assistants — and how assistants place calls

## Inbound

Route any number — bought in the [marketplace](/telephony/phone-numbers) or brought via [BYO trunk](/telephony/sip-trunks) — to an assistant:

1. **Phone numbers → select number → assign assistant.**
2. Incoming calls are answered by that assistant, using its greeting mode (speak first, or wait for the caller).
3. Recording (with [consent handling](/assistants/conversation-quality#consent--conditional-recording) if enabled), transcription, and call events happen automatically.

The number → assistant mapping resolves per call, so you can reassign numbers at any time without touching the number itself.

## Outbound

Three ways to place calls:

* **Single call from the UI** — on an assistant page, enter a number and call: ideal for testing.
* **API / MCP** — `make_call` with `assistant_id` and `to_number`, plus optional lead data the assistant can use in conversation (name, custom fields). See the [API Reference](/api-reference/introduction).
* **Campaigns** — bulk outbound over a lead list with dialer logic; see [Campaigns](/campaigns/overview).

Outbound behavior details:

* The assistant greets **only after the callee picks up** (no talking into ringing).
* Unanswered outcomes map to clean statuses: `busy`, `no_answer`, `failed` — campaign retry logic builds on these.
* With **greeting mode: user speaks first**, the assistant waits for the callee's "Hello?" — noticeably more natural for cold calls.
* Optional **answering machine detection (AMD)** classifies who picked up (human / voicemail / IVR) and can drop a configured voicemail message; see [Dialer & compliance](/campaigns/dialer-and-compliance#amd--voicemail).

### Failure guidance

`POST /calls` returns the queued call immediately. Poll `GET /calls/{id}`, use
`get_call`, or consume `call.completed` to receive the final result. Failed
outbound calls include a provider-neutral `failure` object:

```json theme={null}
{
  "operation": "outbound_call",
  "code": "no_answer",
  "message": "The destination did not answer before the call timed out.",
  "retryable": true,
  "action": "retry_later"
}
```

Common codes are `busy`, `declined`, `no_answer`,
`temporarily_unavailable`, `invalid_destination`,
`authentication_failed`, `destination_forbidden`, `trunk_unavailable`, and
`no_outbound_trunk`. The object never contains raw SIP responses, connection
credentials, infrastructure identifiers, or SDK error text.

`retryable` is guidance for your integration. It does not modify campaign retry
settings.

If a cold or warm transfer fails while the original call remains active, the
call's event log contains `call_transfer_failed` or `warm_transfer_failed`.
Those events use the same `failure` shape with `operation: cold_transfer` or
`warm_transfer`.

## Web calls

Every assistant can also be called **from the browser** — used by the built-in test call and the embeddable [web widget](/web-widget). Web calls appear in the call history with direction `web`.

## Call results

Every call — regardless of direction — produces: a transcript, duration and status, provider-neutral failure guidance when applicable, per-turn latency metrics, an event log (tool calls, transfers, consent, node transitions), optional recording, and a `call.completed` [webhook](/api/tools-and-webhooks#webhooks).