> ## Documentation Index
> Fetch the complete documentation index at: https://docs.famulor.io/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

## Eingehende Anrufe

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

1. **Phone numbers → select number → assign assistant.**
2. Eingehende Anrufe werden von diesem Assistenten beantwortet, je nach Begrüßungsmodus (zuerst sprechen oder auf den Anrufer warten).
3. Aufzeichnung (mit [Einwilligungsverwaltung](/de/assistants/conversation-quality#wofür-die-einwilligung-gilt), 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.

## Ausgehende Anrufe

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](/de/api-reference/introduction).
* **Campaigns** – Massenausgang über eine Lead-Liste mit Dialer-Logik; siehe [Kampagnen](/de/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 **greeting mode: user speaks first** wartet der Assistent auf das „Hallo?“ des Angerufenen – spürbar natürlicher bei Kaltakquise.
* Die optionale **answering machine detection (AMD)** klassifiziert, wer abgenommen hat (Mensch / Voicemail / IVR), und kann eine hinterlegte Voicemail-Nachricht hinterlassen; siehe [Dialer & Compliance](/de/campaigns/dialer-and-compliance#amd--voicemail).

### Hinweise bei Fehlern

`POST /api/v1/calls` liefert den Anruf sofort mit Status `queued`. Frage anschließend
`GET /api/v1/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`.

`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](/de/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](/de/api/tools-and-webhooks#anrufergebnisse-per-webhook-erhalten).