For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Hauptnavigation

Telefonie und SIP

Wähle für Telefonanrufe eine SIP-Verbindung oder eine Audiobrücke über deine Anwendung.

Wähle die API, die deine Anwendung verwendet. Jede API hat eigene Vorgaben für Authentifizierung, Sitzungserstellung und Ereignisse.

Telefonieverbindung auswählen

Ein Telefonanruf kann GPT-Live über einen SIP-Trunk oder eine Anwendung erreichen, die Audio weiterleitet. Wähle den Weg, der zu deinem bestehenden Telefonsystem passt. Berücksichtige dabei, wo deine Anwendung Audio verarbeiten muss.

VerbindungZuständigkeiten für Audio und Anwendungslogik
Direkte SIP-VerbindungDer Anbieter tauscht das Anrufaudio mit OpenAI aus. Deine Anwendung kümmert sich um Webhooks, Sitzungskonfiguration, Entscheidungen über Anrufe und Geschäftslogik.
Serverseitige AudiobrückeDeine Anwendung leitet Audio vom Anbieter oder aus einem Raum über WebSocket an GPT-Live weiter. Sie verwaltet beide Verbindungen, die Umwandlung der Ereignisse, die Wiedergabe und den Anruflebenszyklus.

Die Verbindung eines Anbieters zu deiner Anwendung und die Verbindung deiner Anwendung zu OpenAI sind voneinander getrennt. Beispielsweise kann eine anrufende Person einem Raum über SIP beitreten, während sich ein Agent in diesem Raum über WebSocket mit GPT-Live verbindet.

Verwendest du Twilio, Telnyx, LiveKit oder Daily/Pipecat? Unter GPT-Live-Partnerintegrationen findest du anbieterspezifische Anleitungen.

Direkte SIP-Verbindung

Bei einer direkten SIP-Verbindung bleibt das Anrufaudio auf dem Medienpfad zwischen Anbieter und OpenAI. Die SIP-Signalisierung verwendet TLS, und GPT-Live setzt für das Anrufaudio SRTP voraus. Dein Backend ist weiterhin für die Entscheidung über eingehende Anrufe, die Sitzungskonfiguration, die Autorisierung und die Geschäftslogik zuständig.

Verwende eine Sideband-Verbindung, wenn dein Backend Sitzungsereignisse empfangen oder Befehle senden muss. Sie verbindet sich mit dem bestehenden Gespräch, während SIP das Audio überträgt. Weise jeder Aktion genau einen Handler zu, damit mehrfach zugestellte Webhooks oder auf mehreren Verbindungen beobachtete Ereignisse Werkzeuge nicht doppelt ausführen.

Verwalte SIP-Routing und Anbieterkonfiguration zusammen mit der Integration, die sie verwendet. Realtime-Webhook-Ereignisse, Anrufkennungen und Nutzdaten zur Anrufannahme gehören zur Realtime API. Verwende für eine Live-Sitzung die Vorgaben von GPT-Live.

Anruflebenszyklus verwalten

Vergewissere dich vor der Nutzung dieses Ablaufs, dass die SIP-Unterstützung von GPT-Live für dein Projekt aktiviert ist und der SIP-Trunk deines Anbieters an dieses Projekt weitergeleitet wird. Die Realtime-Webhook-Nutzdaten und die Nutzdaten zur Anrufannahme im anderen Tab folgen anderen API-Vorgaben.

Eingehenden Anruf empfangen

Konfiguriere den Webhook-Endpunkt deines Projekts für live.transport.incoming. Überprüfe die Webhook-Signatur und entferne doppelte Zustellungen, bevor du über den Anruf entscheidest. Eine Zustellungsbestätigung nimmt den Anruf nicht an.

Der Webhook kennzeichnet einen SIP-Anruf mit data.type: "sip" und liefert data.session_id. Verwende diese Sitzungs-ID unverändert für jede Live-Anrufaktion. Behandle data.sip_headers als nicht vertrauenswürdige Metadaten der anrufenden Person, nicht als Autorisierung.

Bestehende Integrationen können weiterhin das veraltete Ereignis live.call.incoming empfangen, das kein data.type enthält. Verarbeite während der Migration beide Ereignisnamen und behalte das alte Abonnement bei, bis alle ausstehenden Zustellungen und Wiederholungsversuche für das alte Ereignis abgeschlossen sind. Derselbe ausstehende Anruf kann auch einen Realtime-Webhook auslösen. Weise die Entscheidung über Annahme oder Ablehnung genau einem Handler zu, statt den Anruf über beide APIs anzunehmen.

Anruf annehmen oder ablehnen

Wende die Autorisierungs- und Routingregeln deiner Anwendung an. Um den Anruf anzunehmen, sende eine authentifizierte Anfrage an POST /v1/live/sessions/{session_id}/accept mit einem session-Objekt auf oberster Ebene:

{
  "session": {
    "type": "live",
    "model": "gpt-live-1",
    "instructions": "You are answering an inbound support call.",
    "audio": { "output": { "voice": "marin" } },
    "delegation": { "type": "client" }
  }
}

Verwende für Anfragen zur Anrufsteuerung aus deinem vertrauenswürdigen Backend Authorization: Bearer $OPENAI_API_KEY. Wähle bei der Annahme die Stimme und den Delegationsmodus aus. SIP handelt das Audioformat aus, lass daher audio.format weg. Das Beispiel wählt die Delegation an den Client. Dein Backend muss die delegierten Aufgaben bearbeiten. Konfigurationen für den Client und Responses findest du unter Delegation und Werkzeuge.

Bei erfolgreicher Annahme wird nach der Initialisierung der Sitzung 200 OK mit einem leeren Antworttext zurückgegeben. Behandle HTTP-Fehler, bevor du den Anruf als angenommen betrachtest.

Um den Anruf abzulehnen, sende eine Anfrage an POST /v1/live/sessions/{session_id}/reject mit einem SIP-Status, beispielsweise { "status_code": 486 } für „besetzt“. Der Status muss eine ganze Zahl von 300 bis einschließlich 699 sein. Die erste Entscheidung über Annahme oder Ablehnung gilt. Eine spätere konkurrierende Entscheidung gibt decision_already_made zurück.

Backend verbinden

Stelle nach der Annahme eine Sideband-WebSocket-Verbindung zu wss://api.openai.com/v1/live/sessions/{session_id}/attach her. Verwende die ID der angenommenen Sitzung sowie dieselbe Projektauthentifizierung und dieselben Verbindungsheader. Sende session.start nicht erneut.

SIP überträgt das Anrufaudio. Verwende die Sideband-Verbindung für Transkripte, Delegation, Werkzeuge, Befehle und gespiegeltes Audio. Lege für jeden Seiteneffekt genau eine zuständige Instanz fest, auch wenn mehrere Verbindungen ein Ereignis beobachten.

Tastenereignisse beobachten

Die Sideband-Verbindung empfängt transport.dtmf.received, wenn die anrufende Person eine Taste drückt, und transport.dtmf.send, nachdem ein gehostetes Werkzeug erfolgreich einen Ton gesendet hat. Das Feld event des Ereignisses enthält einen der folgenden Werte: 09, *, # oder AD.

Dies sind Benachrichtigungen für Beobachter, keine Client-Befehle. Sende transport.dtmf.send nicht, um einen Ton anzufordern, und gehe nicht davon aus, dass der Datenkanal des Browsers Tastenereignisse empfängt.

Anruf weiterleiten oder beenden

Um den Anruf weiterzuleiten, sende eine Anfrage an POST /v1/live/sessions/{session_id}/refer mit { "target_uri": "sip:agent@example.com" } für dein Ziel. Um aufzulegen, sende eine Anfrage an POST /v1/live/sessions/{session_id}/hangup ohne Anfragetext. Beide geben bei Erfolg 200 OK mit einem leeren Antworttext zurück.

Halte deine Sideband-Verbindung für abschließende Ereignisse und Nutzungsdaten offen, bevor du Anwendungsressourcen freigibst. Eine erfolgreiche Anfrage zum Auflegen oder ein unerwarteter Verbindungsabbruch ersetzt session.closed nicht. Informationen zum Abschluss und zu den Gründen für das Schließen findest du unter Nutzung und geordnetes Schließen.

Dieser Ablauf nimmt eingehende Anrufe an. Das Erstellen eines ausgehenden SIP-Anrufs über POST /v1/live/sessions wird nicht unterstützt. Verwende für ausgehende Anrufe, die der Anbieter steuert, die entsprechende Partnerintegration.

Serverseitige Audiobrücken

Verwende die WebSocket-Verbindung zu GPT-Live, wenn deine Anwendung einen Audiostream von einem Telefonieanbieter oder einem Agenten-Framework empfängt. Die Anwendung authentifiziert beide Verbindungen, wandelt die Hüllstrukturen ihrer Ereignisse um und leitet Audio in beide Richtungen weiter.

GPT-Live unterstützt rohe G.711-μ-law- und A-law-Audiodaten mit 8 kHz über WebSocket. Wenn der Stream des Anbieters denselben Codec, dieselbe Abtastrate und dieselbe Kanalanzahl verwendet, kann deine Anwendung die rohen Audiobytes weiterleiten, ohne sie in PCM umzuwandeln. Behalte die Reihenfolge der Audiodaten bei und verwende das von der jeweiligen Verbindung geforderte Nachrichtenformat. Übereinstimmende Audioformate machen die beiden Ereignisprotokolle nicht austauschbar.

Die Audiobrücke ist auch für alle Audiodaten verantwortlich, die sie zur Wiedergabe in eine Warteschlange stellt. Berücksichtige beim Entwurf deiner Anwendung die Pufferung durch den Anbieter, Unterbrechungen und das Beenden des Anrufs. Informationen zum Lebenszyklus einer Live-Sitzung findest du unter Sitzungen verwalten. Änderungen am Sprecherwechsel und an der Wiedergabesteuerung werden unter Zu GPT-Live migrieren beschrieben.

Speichere die Anruf- oder Raumkennung des Anbieters zusammen mit der OpenAI-Sitzungs-ID, damit du ein Gespräch über beide Systeme hinweg nachverfolgen kannst.

Nächste Schritte mit GPT-Live