SIP, Media Streams und Realtime: Was bei KI-Telefonie tatsächlich miteinander spricht
Ein Telefonat besteht nicht aus „einem Stream“. Signalisierung, Audio, Gesprächslogik und Geschäftssysteme laufen über verschiedene Wege – und fallen unterschiedlich aus.
Das Wichtigste
- SIP signalisiert Aufbau, Änderung und Ende einer Sitzung; der eigentliche Audiopfad ist davon zu unterscheiden.
- Media Streams transportieren Audio zu einer Anwendung, während Realtime-Sessions Gesprächszustand und Modellereignisse verwalten.
- Monitoring folgt den Grenzen der Komponenten und korreliert sie über gemeinsame Gesprächsreferenzen.
Der Anruf ist eine kleine verteilte Anwendung
SIP ist ein Signalisierungsprotokoll zum Erstellen, Ändern und Beenden von Sitzungen wie Internet-Telefonaten. Es findet Teilnehmer, verhandelt Sitzungseigenschaften und steuert Zustände wie Einladung oder Beendigung. Audio wird typischerweise über eigene Medienprotokolle transportiert. Diese Trennung erklärt, warum ein Gespräch klingeln kann, obwohl noch kein nutzbares Audio ankommt.[1]
Für KI-Telefonie kommt eine weitere Schicht hinzu: Live-Audio wird an eine Anwendung oder Realtime-Schnittstelle gegeben, dort verstanden und als neue Sprache zurückgesendet. OpenAI dokumentiert einen direkten SIP-Weg zur Realtime API; Telefonieplattformen wie Twilio bieten bidirektionale Media Streams über WebSockets. Welche Route passt, hängt von Rufaufbau, Steuerungsbedarf und vorhandener Infrastruktur ab.[2][3]
Fünf Schichten, fünf andere Fehlerbilder
| Schicht | Aufgabe | Typisches Symptom |
|---|---|---|
| Rufsignalisierung | anrufen, annehmen, übertragen, beenden | klingelt nicht oder Transfer scheitert |
| Medienpfad | Audio transportieren und codieren | Stille, Einweg-Audio, Verzerrung |
| Realtime-Dialog | Turns, Kontext, Antwort und Tools | falsches Timing oder kein neuer Turn |
| Tool-Schicht | Kalender, CRM, Ticket und Wissen | Antwort da, Aktion fehlt |
| Betrieb | Monitoring, Routing, Freigaben, Fallback | Fehler bleibt unbemerkt oder ohne Eigentümer |
Ohne gemeinsame Referenz gibt es nur fünf halbe Wahrheiten
Telefonie hat eine Call-ID, der Media-Stream eine Verbindung, die Realtime-Session eine eigene Kennung und das CRM wiederum eine Vorgangsnummer. Diese IDs müssen in einem Korrelationsdatensatz zusammengeführt werden. Erst dann lässt sich beantworten, ob ein Tool-Timeout zur hörbaren Pause führte oder ein Gespräch bereits beendet war, als die Aktion zurückkam.
- Zeitstempel in einer gemeinsamen Zeitzone speichern und Uhrenabweichungen beobachten.
- Ruf-, Stream-, Session- und Vorgangs-ID an Übergängen protokollieren.
- Inhalt und Metadaten trennen: Für Diagnose reichen oft Status, Dauer und Fehlerklasse.
- Webhooks authentifizieren und wiederholbar verarbeiten; Zustandsereignisse können verspätet eintreffen.
Die richtige Architektur beginnt beim Betriebsmodell
Wer bereits eine Telefonanlage und SIP-Trunks betreibt, bewertet andere Integrationspunkte als ein kleines Team mit gehosteter Rufnummer. Wichtig sind nicht nur Latenz und Funktionsumfang, sondern Verantwortlichkeit für Rufrouting, Notrufgrenzen, Regionen, Signaturprüfung, Failover und Support. Eine Architekturzeichnung sollte jeden Übergang mit Eigentümer und Ersatzpfad versehen.
Quellen und Prüfstand
Primärquellen der Anbieter, zuletzt geprüft am 19. August 2026.
- [1]RFC 3261 – SIP: Session Initiation Protocol · RFC Editor · abgerufen am 19. August 2026
- [2]Realtime API with SIP · OpenAI Developers · abgerufen am 19. August 2026
- [3]Media Streams Overview · Twilio · abgerufen am 19. August 2026
