Per SIP ins KI-Zeitalter: So verbindet man eine Telefonanlage mit der OpenAI Realtime API

Wenn die Telefonanlage plötzlich selbst denkt

Stell dir vor, du rufst eine Nummer an, und am anderen Ende hebt eine KI ab, die nicht nur versteht, was du sagst, sondern in Echtzeit antwortet. Kein Warteton, kein „Drücken Sie die 1 für…", einfach ein Gespräch. Genau das haben wir mit einer FreePBX-Telefonanlage und OpenAIs Realtime API zum Laufen gebracht.

Die Idee klingt simpel: Telefonanlage trifft KI. Die Umsetzung hatte ihre Tücken. Hier ist, was wir gelernt haben.

Die Ausgangslage

Die Komponenten: Eine bestehende FreePBX-Installation als SIP-Telefonanlage, OpenAIs Realtime API mit dem Modell gpt-realtime-1.5 für die Sprachverarbeitung, und ein Node.js Webhook-Server als Bindeglied. Kein teures KI-Telefonie-Gateway, keine proprietäre Hardware.

Das Ziel: Einen SIP-Trunk so konfigurieren, dass eingehende Anrufe direkt an OpenAI weitergeleitet werden. Die KI übernimmt das Gespräch und tauscht Audio in Echtzeit über eine WebSocket-Verbindung aus.

Schritt 1: Der SIP-Trunk

OpenAI bietet seit der GA-Phase der Realtime API nativen SIP-Support an. Man registriert eine Telefonnummer über das OpenAI Dashboard und verknüpft sie mit einem Realtime-Projekt. Die Konfiguration auf Seiten der Telefonanlage ist dann Standard-SIP: Ein PJSIP-Trunk, der auf sip.api.openai.com zeigt.

Der eigentliche Trick steckt in der Webhook-Architektur: Sobald ein Anruf über den SIP-Trunk eingeht, sendet OpenAI einen HTTP-POST an die konfigurierte Webhook-URL. Der Webhook-Server entscheidet dann, ob der Anruf angenommen wird, und baut die WebSocket-Verbindung auf.

Schritt 2: Der Webhook-Server

Der Webhook-Server (ca. 650 Zeilen Node.js) übernimmt drei Kernaufgaben:

1. Accept: Eingehende Anrufe annehmen und die Session konfigurieren (Modell, Stimme, System-Prompt, verfügbare Tools)
2. Connect: WebSocket-Verbindung zu OpenAI aufbauen und Realtime-Events verarbeiten
3. Functions: Tool-Aufrufe der KI entgegennehmen und gegen interne Systeme ausführen (Zammad, Mailcow, QMS, NIDA)

Der Server läuft als systemd-Service hinter einem Nginx Reverse Proxy mit Let’s Encrypt Zertifikat.

Schritt 3: TLS und Zertifikate

Zwei Stolpersteine, die den Großteil der Debugging-Zeit gefressen haben:

TLS-Version: SIP über TLS funktioniert nur, wenn beide Seiten die gleiche Protokollversion sprechen. Die Telefonanlage verwendete standardmäßig TLS 1.1, OpenAI verlangt mindestens TLS 1.2. Das Ergebnis war Stille: Kein Audio, kein Fehler, einfach nichts. Die Lösung war ein Custom Transport mit tls_method=tlsv1_2 in der PJSIP-Konfiguration.

Zertifikatsvalidierung: OpenAI prüft das TLS-Zertifikat des Webhook-Servers streng. Selbst-signierte Zertifikate werden abgelehnt, ebenso Zertifikate für die falsche Domain. Die pragmatische Lösung: Den Webhook-Server hinter den bestehenden Nginx Reverse Proxy mit gültigem Let’s Encrypt Zertifikat schalten.

Lektion: Bei SIP-TLS-Problemen immer als Erstes die Protokollversion prüfen. Nicht den Server, nicht die Firewall, nicht das NAT.

Schritt 4: Die Session-Konfiguration

Die Realtime API hat eine neue Struktur für Session-Parameter eingeführt (gegenüber der älteren gpt-4o-realtime-preview):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

// Accept: Modell + Instructions + Tools
{
  type: 'realtime',
  model: 'gpt-realtime-1.5',
  instructions: systemPrompt,
  tools: functionDefinitions,
}

// Session Update: Stimme + Transkription
{
  type: 'session.update',
  session: {
    type: 'realtime',
    audio: {
      input: { transcription: { model: 'whisper-1' } },
      output: { voice: 'shimmer' },
    },
  },
}

Ein subtiler Unterschied zur älteren API: Parameter wie voice und input_audio_transcription sind unter audio.input bzw. audio.output verschachtelt, nicht mehr auf Top-Level. Wer das übersieht, bekommt Unknown parameter: session.voice und die gesamte Session-Konfiguration wird verworfen, inklusive der Whisper-Transkription.

Schritt 5: Function Calling

Die KI soll nicht nur reden, sondern handeln. Über das Tools-Array in der Session-Konfiguration bekommt sie Zugriff auf interne Systeme:

• Mitarbeiter-Verifizierung: Personalnummer gegen die HR-Datenbank prüfen, optional mit Name und Geburtsdatum für sicherheitskritische Aktionen
• Störungstickets: Direkt im Ticketsystem (Zammad) anlegen, mit automatischer Kundenzuordnung über PNr → E-Mail-Lookup → Zammad-User
• Passwort-Resets: E-Mail-Passwörter über Mailcow zurücksetzen, inklusive automatischer QMS-Benachrichtigung an den Mitarbeiter
• NIDA-Resets: Passwörter für das Einsatzdokumentationssystem zurücksetzen (läuft asynchron im Hintergrund, weil der Selenium-basierte Reset 30-60 Sekunden dauert)
• Nachrichten: Telefonische Nachrichten aufnehmen und per E-Mail an die richtige Person weiterleiten

Jeder Tool-Aufruf wird geloggt und in der Anruf-Zusammenfassung per E-Mail dokumentiert.

Der erste Anruf

Nummer gewählt, SIP-Trunk geht durch, WebSocket verbindet sich, und dann:

Die KI hebt ab.

„Hallo, hier ist Tami, die persönliche KI-Assistentin vom QM-Team der Rettungsdienst Rheinhessen-Nahe, was kann ich für Sie tun?"

Die Reaktion im Raum war unbezahlbar. Echtzeit-Antworten, natürliche Gesprächsführung, korrekte Ticket-Erstellung im Hintergrund. Der gesamte Aufbau, vom ersten Konfigurationsfile bis zum funktionierenden Live-Call mit Function Calling, hat einen Abend gedauert.

Was dahinter steckt

Die Realtime API nutzt ein bidirektionales WebSocket-Protokoll. Audio wird als PCM-Stream übertragen. Die KI verarbeitet Spracheingaben nicht über die klassische Pipeline (Speech-to-Text → LLM → Text-to-Speech), sondern in einem einzigen multimodalen Modell. Das erklärt die niedrige Latenz und die natürliche Gesprächsführung.

Für die Telefonie-Seite übernimmt die Telefonanlage das klassische SIP-Protokoll mit allen Vorzügen: Rufnummernzuweisung, Weiterleitung, Warteschleifen, Voicemail-Fallback. Die KI wird wie ein normaler SIP-Endpoint behandelt.

Beidseitige Transkription über Whisper liefert nach jedem Anruf eine vollständige Zusammenfassung per E-Mail: Was gesagt wurde, welche Aktionen ausgeführt wurden und ob sie erfolgreich waren.

Sicherheit

Ein Voice-Agent mit Zugriff auf interne Systeme braucht Schutzmaßnahmen:

• Zwei-Stufen-Verifizierung: Für Störungstickets reicht die Personalnummer. Für Passwort-Resets werden zusätzlich Name und Geburtsdatum abgeglichen.
• Admin-Schutz: Bestimmte Accounts (IT-Administratoren) können telefonisch nicht zurückgesetzt werden. Der Code prüft das unabhängig von den KI-Instructions, als zweite Sicherheitsebene.
• Fallback bei Fehlern: Wenn die Ticket-Erstellung fehlschlägt, werden alle Anrufdaten per E-Mail an das Team geschickt. Es geht nichts verloren.

Ausblick

Der Proof of Concept läuft produktiv. Function Calling, Ticket-Erstellung und Passwort-Resets funktionieren. Was als Nächstes kommt:

• MCP-Integration: Das Model Context Protocol könnte der KI strukturierten Zugriff auf weitere interne Systeme geben
• Mehrere Endpunkte: Verschiedene Rufnummern für verschiedene Fachbereiche oder Organisationseinheiten
• Caller-ID: Die Rufnummer des Anrufers aus den SIP-Headern extrahieren (aktuell zeigt OpenAI nur die Projekt-ID)
• Monitoring: Anrufstatistiken, Gesprächsqualität, Fehlerquoten

Fazit

Der Aufwand, eine Telefonanlage mit einer KI zu verbinden, ist überschaubar. Die SIP-Konfiguration ist Standard, der Webhook-Server passt in eine einzelne Datei, und die OpenAI-API macht den Großteil der Arbeit. Die eigentliche Herausforderung lag in den Details: TLS-Versionen, Zertifikatsvalidierung, die neue API-Struktur für Session-Parameter, und Shell-Escaping bei der Tool-Ausführung.

Das Ergebnis: Eine Telefonnummer, unter der eine KI Anrufe entgegennimmt, Störungen aufnimmt, Passwörter zurücksetzt und Nachrichten weiterleitet. Kein IVR-Menü, keine Warteschleife, einfach ein Gespräch.

Für Organisationen mit Bereitschaftsnummern, IT-Hotlines oder Erreichbarkeitsproblemen außerhalb der Bürozeiten ist das ein Ansatz, der sich lohnt.