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

# Eingehende und ausgehende Anrufe

> Wie Anrufe Assistenten erreichen – und wie Assistenten Anrufe tätigen

## Eingehend

Leite eine beliebige Nummer – gekauft im [Marktplatz](/telephony/phone-numbers) oder per [eigenem Trunk (BYO)](/telephony/sip-trunks) mitgebracht – an einen Assistenten weiter:

1. **Telefonnummern → Nummer auswählen → Assistenten zuweisen.**
2. Eingehende Anrufe werden von diesem Assistenten beantwortet, je nach Begrüßungsmodus (zuerst sprechen oder auf den Anrufer warten).
3. Aufzeichnung (mit [Einwilligungsverwaltung](/assistants/conversation-quality#consent--conditional-recording), falls aktiviert), Transkription und Anruf-Events laufen automatisch ab.

Die Zuordnung Nummer → Assistent wird pro Anruf neu aufgelöst – du kannst Nummern also jederzeit anders zuweisen, ohne die Nummer selbst anzufassen.

## Ausgehend

Drei Wege, um Anrufe zu tätigen:

* **Einzelanruf über die Oberfläche** – Gib auf einer Assistenten-Seite eine Nummer ein und ruf an: ideal zum Testen.
* **API / MCP** – `make_call` mit `assistant_id` und `to_number`, plus optionalen Lead-Daten, die der Assistent im Gespräch nutzen kann (Name, benutzerdefinierte Felder). Siehe die [API-Referenz](/api-reference/introduction).
* **Kampagnen** – Massenausgang über eine Lead-Liste mit Dialer-Logik; siehe [Kampagnen](/campaigns/overview).

Details zum Verhalten bei ausgehenden Anrufen:

* Der Assistent begrüßt **erst, wenn der Angerufene abgenommen hat** (kein Sprechen ins Klingeln).
* Unbeantwortete Anrufe werden auf eindeutige Status abgebildet: `busy`, `no_answer`, `failed` – die Retry-Logik von Kampagnen baut darauf auf.
* Im **Begrüßungsmodus: Gesprächspartner spricht zuerst** wartet der Assistent auf das „Hallo?" des Angerufenen – spürbar natürlicher bei Kaltakquise.
* Die optionale **Anrufbeantworter-Erkennung (AMD)** klassifiziert, wer abgenommen hat (Mensch / Voicemail / IVR), und kann eine hinterlegte Voicemail-Nachricht hinterlassen; siehe [Dialer & Compliance](/campaigns/dialer-and-compliance#amd--voicemail).

### Hinweise bei Fehlern

`POST /calls` liefert den Anruf sofort mit Status `queued`. Frage anschließend
`GET /calls/{id}` oder `get_call` ab oder verarbeite `call.completed`, um das
endgültige Ergebnis zu erhalten. Fehlgeschlagene ausgehende Anrufe enthalten
ein anbieterneutrales `failure`-Objekt:

```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"
}
```

Häufige Codes sind `busy`, `declined`, `no_answer`,
`temporarily_unavailable`, `invalid_destination`,
`authentication_failed`, `destination_forbidden`, `trunk_unavailable` und
`no_outbound_trunk`. Das Objekt enthält niemals rohe SIP-Antworten,
Zugangsdaten, Infrastruktur-IDs oder SDK-Fehlertexte.

`retryable` ist ein Hinweis für deine Integration und verändert die
Retry-Einstellungen einer Kampagne nicht.

Schlägt ein Cold- oder Warm-Transfer fehl, während der ursprüngliche Anruf
weiterläuft, enthält das Event-Log `call_transfer_failed` beziehungsweise
`warm_transfer_failed`. Diese Events verwenden denselben `failure`-Vertrag mit
`operation: cold_transfer` oder `warm_transfer`.

## Webanrufe

Jeder Assistent lässt sich auch **aus dem Browser** anrufen – genutzt vom eingebauten Testanruf und dem einbettbaren [Web-Widget](/web-widget). Webanrufe erscheinen im Anrufverlauf mit der Richtung `web`.

## Anrufergebnisse

Jeder Anruf – unabhängig von der Richtung – liefert: ein Transkript, Dauer und Status, bei Bedarf anbieterneutrale Fehlerhinweise, Latenz-Metriken pro Turn, ein Event-Log (Tool-Aufrufe, Übergaben, Einwilligung, Node-Übergänge), optionale Aufzeichnung und einen `call.completed`-[Webhook](/api/tools-and-webhooks#webhooks).