WebRTC vs. SIP – was verwende ich für einen Browser oder einen KI-Agenten?

Ein Browser und ein Tischtelefon können die beiden Enden desselben Anrufs sein, obwohl sie Medien unterschiedlich verarbeiten.

Zwischen ihnen zu wählen behandelt Funktionen, die bewusst einer Schicht zugewiesen sind, als gehörten sie zur anderen.

Sind sie Alternativen?

Nein. Sie liegen auf verschiedenen Schichten, und jede lässt die Aufgabe der anderen unerledigt.

SIP ist Signalisierung. Es findet die Gegenstelle, handelt aus, welche Medien ausgetauscht werden, klingelt, verbindet und baut ab. Es überträgt kein Audio. RFC 3261 zieht die Grenze: "SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture."

WebRTC ist der Media-Stack, den ein Browser mitbringt. Er überträgt Audio und Video zwischen zwei Endpunkten. Er durchquert Network Address Translation, was einen direkten Browser-zu-Browser-Pfad schwierig macht. Er verschlüsselt außerdem die Medien. Die eigene Spezifikation, RFC 8825, ein IETF-Standards-Track-Dokument vom Januar 2021, gibt RTP als Medienformat an. Sie verlangt SRTP: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".

SIP arrangiert Anrufe, ohne Medien zu übertragen. WebRTC überträgt Medien, ohne Anrufe zu arrangieren.

Was lässt WebRTC aus und warum?

WebRTC lässt die Signalisierung aus, und zwar bewusst: Die Spezifikation stuft die Wahl des Signalisierungsprotokolls als außerhalb ihres eigenen Geltungsbereichs ein.

RFC 8825 beschreibt die Anordnung als Trapez. Die Medien fließen direkt zwischen den beiden Browsern. Die Signalisierung läuft über Server, die "can modify, translate, or manipulate the signals as needed". Die Spezifikation legt kein Signalisierungsprotokoll fest:

The choice of protocols for client-server and inter-server signaling, and the definition of the translation between them, are outside the scope of the WebRTC protocol suite described in this document.

Das ist keine Lücke, die noch geschlossen werden muss. Es ist das, was einer Chat-Anwendung erlaubt, über eigene WebSocket-Nachrichten zu signalisieren, während eine Telefonieplattform über SIP signalisiert, mit demselben Media-Stack darunter. Dasselbe Dokument benennt die Telefonieoption direkt und beschreibt ein Deployment, das "a standardized signaling mechanism (e.g., SIP over WebSockets)" zwischen Browser und Server nutzt.

SIP über WebSocket ist in RFC 7118 vom Januar 2014 spezifiziert, das "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments" definiert. Es ändert, wie SIP-Nachrichten transportiert werden, nicht was sie sagen, und deshalb können ein Browser und ein Tischtelefon die beiden Enden eines gewöhnlichen Anrufs sein.

Wie sieht das bei Bird aus?

Um einen Browser über Bird anzubinden, verwenden Sie SIP über einen WebSocket.

Das Telefon im Dashboard ist das Praxisbeispiel. Der Browser fungiert als SIP-Client. Das Dashboard erstellt dafür ein kurzlebiges Session-Credential, statt ein langlebiges Secret in eine Seite zu laden. Die API beschreibt handshake_token des Credentials als "Short-lived token required when upgrading the WebSocket connection". Es "authorizes the connection only; each call still authenticates with password". Das Handshake-Token autorisiert die Verbindung, während das Passwort jeden Anruf authentifiziert.

Die Browserkompatibilität hängt von den Digest-Algorithmen des Trunks ab. Browser beantworten eine SIP-Digest-Challenge mit MD5 und nichts anderem. Ein Trunk akzeptiert nur die Algorithmen, die er anbietet. Ein Trunk, der ausschließlich SHA-256 anbietet, lehnt daher jeden Browseranruf ab, einschließlich des Dashboard-Telefons. MD5 im Angebot zu behalten ist das, was einen Trunk vom Browser aus erreichbar macht, und SIP-Trunks behandelt die Einstellung.

Der Anruf landet ansonsten auf demselben Trunk, prüft dieselbe verifizierte Anrufer-ID, befolgt dieselben freigegebenen Ziele und erzeugt denselben Datensatz wie ein Anruf von einer PBX, der Telefonanlage, die die Anrufe eines Unternehmens vermittelt.

Was verwende ich also?

Entscheiden Sie anhand des Laufzeitorts Ihres Endpunkts, und rechnen Sie in jedem Fall mit SIP.

WebRTC verlangt verschlüsselte Medien. Der TLS-Transport eines SIP-Trunks verschlüsselt die Signalisierung während der Übertragung, nicht das Audio. Eine Verschlüsselungsprüfung muss daher beide Pfade abdecken.

1. Ein Browser. Eine Webseite nutzt den WebRTC-Stack des Browsers für die Medien, damit ist diese Hälfte erledigt. Sie wählen, wie signalisiert wird. SIP verbindet den Browser mit dem Telefonnetz, nicht nur mit anderen Browsern.
2. Ein Tischtelefon, eine PBX oder ein Session Border Controller (SBC), der Anrufe an einer Netzgrenze steuert. Normales SIP über UDP, TCP oder TLS. WebRTC hat Geräten, die bereits RTP sprechen, nichts zu bieten.
3. Ein Voice-KI-Agent. Was auch immer Ihre Laufzeitumgebung bereits implementiert. Ein Agent im Browser oder auf einer Laufzeitumgebung, die auf Browser-Media-APIs aufbaut, spricht WebRTC und braucht Signalisierung dazu. Ein Agent auf einem Telefonie-Stack spricht SIP und RTP direkt. Was ist ein Voice-KI-Agent behandelt den Rest dieses Pfads, einschließlich des Teils, in dem der Agent das Audio terminieren muss und nicht nur die Signalisierung.