OpenAI hat seinen WebRTC-Stack rund um ein zustandsloses Relay neu aufgebaut, das anhand des ICE-Ufrag routet

Der Zwang zur Neugestaltung: WebRTCs Port-Modell versus Kubernetes

Das Team von OpenAI beschreibt das Problem eher operativ als produktbezogen. Bei mehr als 900 Millionen wöchentlich aktiven Nutzern passte das klassische WebRTC-Deployment-Muster – ein öffentlicher UDP-Port pro Session – nicht mehr zur eigenen Infrastruktur.

Sie erläutern auch, warum. Bei hoher Nebenläufigkeit zwingt ein Port pro Session dazu, sehr große öffentliche UDP-Portbereiche offenzulegen und zu verwalten. Cloud-Load-Balancer und Kubernetes-Services sind nicht für Zehntausende öffentliche UDP-Ports ausgelegt. Diese Angriffsfläche lässt sich schwer absichern, schwer auditieren und steht dem Autoscaling im Weg, da Pods ständig hinzukommen, entfernt und neu geplant werden und jeder von ihnen einen stabilen Portbereich reservieren und bekanntgeben müsste.

Die naheliegende Lösung – ein einzelner UDP-Port pro Server mit Demultiplexing auf Anwendungsebene – löst das Problem der Portanzahl, schafft aber ein zweites Problem. ICE und DTLS sind zustandsbehaftet, daher muss genau der Prozess, der eine Session erstellt hat, weiterhin deren Pakete empfangen. Über eine load-balancierte Flotte hinweg kann das erste Paket trotzdem auf der falschen Instanz landen.

Routing über ein Feld, das im Handshake bereits existiert

OpenAIs Lösung trennt Paket-Routing von Protokoll-Terminierung. Ein schlankes Go-Relay mit kleinem öffentlichem Footprint sitzt vor einem zustandsbehafteten Transceiver, der die vollständige WebRTC-Session verwaltet – ICE-Konnektivitätsprüfungen, den DTLS-Handshake, SRTP-Schlüssel und den Lebenszyklus. Das Relay entschlüsselt niemals Medien und betreibt keine ICE-Zustandsmaschinen; es liest nur so viele Paket-Metadaten, wie nötig sind, um ein Ziel auszuwählen.

Der clevere Kniff liegt darin, wo der Routing-Hinweis untergebracht ist. Statt einen zusätzlichen Lookup-Dienst im Hot Path einzuführen, kodiert OpenAI Routing-Metadaten in das ICE-Username-Fragment (ufrag), einen kurzen Identifikator, der bereits beim Setup ausgetauscht und in STUN-Binding-Requests zurückgespiegelt wird. Der Transceiver erzeugt ein serverseitiges Ufrag, das genügend Informationen enthält, um den Zielcluster und den zuständigen Transceiver zu identifizieren.

Das erste Medienpfad-Paket des Clients – meist ein STUN-Binding-Request an eine gemeinsame Relay-VIP wie 203.0.113.10:3478 – wird also vom Relay ausgewertet, das das Ufrag decodiert und an den richtigen Transceiver weiterleitet. Nachfolgende DTLS-, RTP- und RTCP-Pakete fließen ohne erneute Entschlüsselung. Startet ein Relay neu, baut das nächste STUN-Paket die Zuordnung anhand des Ufrag wieder auf; ein Redis-Cache hält zusätzlich die Zuordnung von Client-IP zu Transceiver, damit die Wiederherstellung noch früher greifen kann.

Was der Browser nie zu spüren bekommt

Für einen Frontend-Entwickler liegt die entscheidende Eigenschaft dieser Arbeit im Negativen: Der Client bemerkt nichts Neues. OpenAI stellt ausdrücklich klar, dass sich aus Sicht des Clients an der WebRTC-Session nichts ändert. Der Transceiver zeigt weiterhin einen normalen WebRTC-Ablauf und verwaltet weiterhin den gesamten Protokollzustand; geändert hat sich nur das interne Routing.

Für uns bedeutete das, die Form unseres WebRTC-Deployments zu ändern, ohne zu ändern, was Clients von WebRTC selbst erwarten.Montana Labs

Das ist ein bewusstes Designprinzip, das sie als „Protokollsemantik am Edge bewahren“ bezeichnen. Da Clients weiterhin Standard-WebRTC sprechen, bleibt die Interoperabilität mit Browsern und mobilen Geräten erhalten – das Team kann seine eigene Infrastruktur umgestalten, ohne individuelles Client-Verhalten auszuliefern oder die Unterstützung über Plattformen hinweg zu fragmentieren. Die Komplexität wurde in eine schlanke Routing-Schicht verschoben, nicht in jeden Backend-Dienst und nicht in den Client.

Der Beitrag würdigt zudem das WebRTC-Ökosystem, auf dem er aufbaut, und merkt an, dass Justin Uberti, einer der ursprünglichen WebRTC-Architekten, und Sean DuBois, Schöpfer der Pion-Go-Implementierung, inzwischen Kollegen bei OpenAI sind. Die erste Transceiver-Implementierung war ein einzelner Go-Dienst auf Basis von Pion.

Die unspektakuläre Wahl: kein SFU, kein Kernel-Bypass

Zwei Entscheidungen fallen durch ihre Zurückhaltung auf. Erstens lehnte OpenAI die SFU (Selective Forwarding Unit) ab, auf die viele Teams standardmäßig setzen. Eine SFU ist sinnvoll für Mehrparteien-Anrufe, aber der Traffic bei OpenAI ist größtenteils 1:1 – ein Nutzer zu einem Modell – und bei jedem Austausch latenzsensibel. Ihr Ergebnis aus Relay plus Transceiver, so schreiben sie, habe bestätigt, dass ein Design ohne SFU die richtige Standardlösung war und Inferenzdienste dadurch wie gewöhnliche Dienste skalieren können, statt als WebRTC-Peers zu agieren.

Zweitens verzichteten sie auf Kernel-Bypass. Das Relay läuft vollständig im Userspace als gewöhnlicher Go-Prozess, abgestimmt mit SO_REUSEPORT, um Pakete über mehrere Worker zu verteilen, mit runtime.LockOSThread, um Flows für Cache-Lokalität an CPU-Kerne zu binden, sowie mit vorallozierten Puffern, um Garbage-Collection-Overhead zu vermeiden. Das reichte aus, um globalen Echtzeit-Medienverkehr mit einem relativ kleinen Relay-Footprint zu bewältigen, weshalb sie beim einfacheren Design blieben.

Die geografische Komponente kommt zusätzlich hinzu: Global Relay platziert Ingress-Punkte nahe an den Nutzern, um den ersten Hop zu verkürzen, und das Geo- und Proximity-Steering von Cloudflare leitet Signaling an einen nahegelegenen Transceiver-Cluster, wobei das Ufrag sicherstellt, dass Medien weiterhin beim verankerten Transceiver ankommen.

Die Erkenntnis: Routing-Metadaten gehören in das Protokoll, das man bereits nutzt

Die konkrete Erkenntnis dieser Ankündigung ist, dass das ICE-Ufrag zugleich als deterministischer Router für das erste Paket dienen kann. Indem Routing-Hinweise in ein Feld eingebettet werden, das WebRTC bereits mitführt, erreichte OpenAI session-stabiles Forwarding über eine ganze Flotte hinweg – ohne Abhängigkeit von einem Lookup im Hot Path und ohne das Standard-Client-Verhalten zu brechen.

Für Teams, die Echtzeit-Voice auf Basis von WebRTC aufbauen, liegt die übertragbare Lektion nicht im Transceiver oder Relay als solchem – sondern in der Reihenfolge des Vorgehens. Lösen Sie den Deployment-Konflikt (UDP-Ports versus Kubernetes) mit einer schlanken, zustandslosen Weiterleitungsschicht, halten Sie die schwierigen zustandsbehafteten Teile an genau einer Stelle, und greifen Sie erst dann zu exotischen Werkzeugen wie Kernel-Bypass, wenn der Regelfall es tatsächlich verlangt. OpenAIs Weg legt nahe, dass das meist nicht der Fall ist.