WebRTC-Routing wird entscheidend für Voice AI, wo die Kontinuität des Audiostreams und minimale Latenz wichtig sind. Wir analysieren, wie die Überarbeitung der Routing-Strategie das Verhalten des Systems unter Last verändert.
Das Problem zeigt sich nicht sofort — bis das System auf globalen Echtzeitverkehr skaliert. In dem klassischen WebRTC-Modell „ein Port pro Sitzung“ entsteht Druck auf die Infrastruktur: Ein großer Bereich von UDP-Ports wird benötigt, der schwer in Kubernetes zu exponieren und zu sichern ist. Gleichzeitig bleiben ICE und DTLS zustandsbehaftet, und jede Sitzung benötigt einen stabilen Besitzer. An diesem Punkt kommt ein dritter Faktor hinzu — globale Routing. Der erste Hop beginnt, die Benutzererfahrung zu bestimmen: Überflüssige Millisekunden verwandeln sich in Pausen, Unterbrechungen und einen „ruckelnden“ Dialog.
Die Wahl der Architektur hängt von der Form der Last ab. SFU (Selective Forwarding Unit) funktioniert gut für Multiparty-Szenarien, in denen Streams, Codecs und RTCP zentral verwaltet werden müssen. Aber bei 1:1-Interaktionen, bei denen jeder RTT das Gefühl eines „lebendigen“ Gesprächs beeinflusst, fügt SFU eine zusätzliche Schicht hinzu. In diesem Kontext wurde der Transceiver-Ansatz gewählt: WebRTC endet am Edge-Service, wonach das Medium in interne Protokolle für Inferenz umgewandelt wird. Dies ist eine Kompromisslösung. Sie entfernt die WebRTC-Komplexität aus den Backend-Services, erfordert jedoch eine sorgfältige Paket-Routing und Zustandsverwaltung am Edge.
Die Implementierung begann mit einem monolithischen Go-Service auf Basis von Pion, der Signalisierung und Medienbeendigung verarbeitete. Das Modell „ein Port pro Sitzung“ wurde jedoch schnell zum Engpass. Eine Alternative — ein Port pro Server — löst das Problem der Ports, jedoch nicht das Routing-Problem in einer verteilten Umgebung: Das erste Paket kann nicht in die richtige Instanz gelangen. Die Lösung besteht darin, die Rollen zu trennen. Stateless Relay ist verantwortlich für den Empfang von Paketen und deren Routing, während der stateful Transceiver der einzige Punkt des Besitzes der Sitzung bleibt (ICE, DTLS, SRTP).
Ein entscheidender Punkt ist das deterministische Routing des ersten Pakets. Hier wird ICE ufrag (username fragment) als eingebauter Routing-Mechanismus verwendet. Im ufrag wird minimale Information über den Zieltransceiver kodiert. Das Relay liest das erste STUN-Paket, extrahiert ufrag und leitet den Verkehr an das entsprechende Backend weiter. Danach wird eine leichte In-Memory-Sitzung erstellt, und die nachfolgenden RTP/RTCP-Pakete folgen dem bereits festgelegten Pfad ohne erneute Analyse. Bei einem Ausfall des Relays kann der Pfad über das nächste STUN-Paket oder über den Cache (Redis), in dem die Zuordnung client IP:port → transceiver gespeichert ist, wiederhergestellt werden.
Ein solches Schema verändert die Wirtschaftlichkeit der Infrastruktur. Anstelle von Tausenden offenen UDP-Ports bleibt eine kleine feste Anzahl von Endpunkten. Dies vereinfacht die Sicherheit und Lastverteilung. Darüber hinaus entsteht die Möglichkeit eines globalen Ingress über eine verteilte Relay-Schicht. Das Paket gelangt näher zum Benutzer in das Netzwerk, wodurch Latenz, Jitter und Paketverlust vor dem Erreichen des Backbones reduziert werden. Dabei wird die Signalisierung geografisch verteilt, was es ermöglicht, die Sitzung an einen bestimmten Cluster zu binden und die Verbindungsaufbauzeit zu verkürzen.
Die Ergebnisse sind eher architektonischer Natur. Konkrete Metriken werden nicht angegeben, aber es wird eine Verringerung der Latenz beim ersten Hop und ein stabileres Verhalten der Echtzeitsitzungen beschrieben. Wichtiger ist etwas anderes: Backend-Services müssen nicht mehr WebRTC-Peers sein. Dies vereinfacht das Skalieren von Inferenz, Orchestrierung und Sprach-Pipelines. Das System nähert sich einem gewöhnlichen Microservice-Modell, in dem WebRTC auf die Edge-Schicht beschränkt ist.
Die allgemeine Schlussfolgerung erscheint pragmatisch. Die Komplexität verschwindet nicht — sie wird in eine dünne Schicht des Routings verlagert. Aber genau dort wird sie besser kontrolliert. Die Verwendung eines protocol-native Mechanismus (ICE ufrag) ermöglicht es, externe Lookups zu vermeiden und das Routing auf dem Paketpfad zu halten. Infolgedessen behält das System das standardmäßige Verhalten von WebRTC für Clients bei, arbeitet jedoch intern nach Regeln, die besser zu hochbelasteten und cloud-nativen Infrastrukturen passen.