WebRTC im großen Maßstab: Wie Mandraki riesige Gruppenanrufe bewältigt

Gruppenvideoanrufe sind eine jener Funktionen, die für Benutzer einfach erscheinen, aber unter der Oberfläche erhebliche technische Komplexität beinhalten. Ein Einzelgespräch ist relativ unkompliziert — zwei Peers tauschen Medien direkt aus. Doch sobald Sie einen dritten Teilnehmer hinzufügen, vervielfachen sich die Architekturentscheidungen, und wenn Sie fünfzig Teilnehmer über mehrere gleichzeitige Sitzungen erreichen, haben Sie es mit einem wirklich harten Problem verteilter Systeme zu tun.

Dieser Beitrag erklärt, wie Mandrakis Echtzeit-Medienarchitektur für massiven Maßstab konzipiert ist — ohne Kompromisse bei Verschlüsselung oder Datensouveränität.

Warum nicht Peer-to-Peer

In einer Peer-to-Peer-Mesh-Topologie sendet jeder Teilnehmer seinen Medienstream direkt an jeden anderen Teilnehmer. Bei einem Anruf mit N Teilnehmern sendet jede Person N-1 Streams und empfängt N-1 Streams. Die Gesamtzahl der Verbindungen beträgt N*(N-1), und der Upload-Bandbreitenbedarf jedes Teilnehmers skaliert linear mit der Anzahl der Teilnehmer.

Das funktioniert für drei oder vier Teilnehmer mit guten Internetverbindungen ausreichend. Darüber hinaus bricht es zusammen. Ein Teilnehmer mit 5 Mbit/s Upload, der einen 1,5-Mbit/s-Videostream sendet, kann nur drei Peers bedienen, bevor sein Upload gesättigt ist. Die CPU-Auslastung für das Encoding mehrerer Streams steigt schnell. Und die Netzwerkbedingungen zwischen beliebigen Teilnehmerpaaren sind unvorhersehbar.

Mesh-Topologie ist theoretisch elegant und in der Praxis unpraktisch für Skalierung.

Der SFU-Ansatz

Eine Selective Forwarding Unit (SFU) sitzt im Zentrum der Anruftopologie. Jeder Teilnehmer sendet einen einzigen Upload-Stream an die SFU. Die SFU leitet diesen Stream dann an alle anderen Teilnehmer weiter. Die Upload-Bandbreite des Teilnehmers ist konstant, unabhängig von der Anzahl der Teilnehmer — er sendet immer einen Stream. Die SFU übernimmt das Fan-Out.

Der „selektive” Teil ist wichtig. Die SFU überträgt nicht einfach jeden Stream an jeden Teilnehmer. Sie trifft intelligente Weiterleitungsentscheidungen basierend auf Netzwerkbedingungen, Teilnehmersichtbarkeit und verfügbarer Bandbreite. Wenn die Download-Verbindung eines Teilnehmers eingeschränkt ist, kann die SFU Schichten in niedrigerer Auflösung weiterleiten. Wenn ein Teilnehmer in der Benutzeroberfläche derzeit nicht sichtbar ist (zum Beispiel in einem großen Anruf, in dem nur der aktive Sprecher in voller Größe gezeigt wird), kann die SFU die Weiterleitung seines Streams reduzieren oder pausieren.

Dies unterscheidet sich grundlegend von einer Multipoint Control Unit (MCU), die alle eingehenden Streams dekodiert, sie zu einem einzigen gemischten Stream zusammensetzt, neu kodiert und das Komposit an jeden Teilnehmer sendet. MCUs sind CPU-intensiv, fügen Encoding-Latenz hinzu und — entscheidend — benötigen Zugriff auf die Klartextmedien, was sie mit Ende-zu-Ende-Verschlüsselung inkompatibel macht.

Eine SFU leitet verschlüsselte Pakete weiter, ohne sie zu dekodieren. Genau das macht SFrame-basierte Ende-zu-Ende-Verschlüsselung in einem Gruppenanruf möglich. Die SFU routet Chiffretext.

Mandrakis SFU-Architektur

Mandraki verwendet eine Open-Source-SFU-Bibliothek, die direkt in unsere Infrastruktur integriert ist. Anstatt uns auf einen monolithischen Drittanbieter-Medienserver zu verlassen, betten wir die SFU als Bibliothek in unsere eigene Codebasis ein. Dies gibt uns volle Kontrolle darüber, wie sie sich in unsere Anwendungsschicht, unser Signalisierungsprotokoll und unser Authentifizierungssystem integriert.

Die SFU verwendet eine Multi-Worker-Architektur. Jeder Worker ist ein separater nativer Prozess, der das tatsächliche Medien-Routing nahezu nativ ausführt. Die Koordinationsschicht verwaltet Worker, Transporte und Schnittstellen mit unserer Anwendungslogik. Diese Trennung hält den Medienpfad schnell, während der Kontrollpfad flexibel bleibt.

Die SFU unterstützt Simulcast und SVC (Scalable Video Coding), die für bandbreitenadaptives Forwarding unerlässlich sind. Die Browser der Teilnehmer kodieren ihr Video gleichzeitig auf mehreren Qualitätsstufen. Die SFU wählt die geeignete Stufe für jeden Empfänger basierend auf seiner verfügbaren Bandbreite und dem UI-Kontext.

Skalierung auf Hunderte von Sitzungen

Für groß angelegte Bereitstellungen ist die Architektur auf horizontale Skalierung mit intelligentem Sitzungsrouting ausgelegt.

Multi-Instanz-SFU-Bereitstellung. Mehrere SFU-Instanzen laufen über Verfügbarkeitszonen hinweg. Jede Instanz registriert ihre Kapazität bei einer Koordinationsschicht. Wenn ein neuer Anruf erstellt wird, wählt das System die SFU-Instanz mit der größten verfügbaren Kapazität aus. Teilnehmer im selben Anruf werden immer auf dieselbe SFU-Instanz geleitet, um optimales Medien-Routing zu gewährleisten.

Parallelität auf Worker-Ebene. Jeder SFU-Prozess erzeugt mehrere native Worker — typischerweise passend zur Anzahl der verfügbaren CPU-Kerne. Jeder Worker kann mehrere Anrufräume unabhängig handhaben. Das bedeutet, ein einzelner SFU-Server mit 16 Kernen kann effizient Dutzende gleichzeitiger Anrufe verwalten, jeweils mit bis zu 50 Teilnehmern.

Bandbreitenadaptives Forwarding. Bei Anrufen mit vielen Teilnehmern werden mehrere Optimierungen automatisch aktiviert. Die Erkennung aktiver Sprecher reduziert die Anzahl der hochwertigen Streams, die weitergeleitet werden müssen. Die Simulcast-Schichtauswahl wird aggressiver und bevorzugt niedrigere Schichten für nicht sichtbare Teilnehmer. Audio-only-Fallback ist für Teilnehmer mit stark eingeschränkter Bandbreite verfügbar.

Europäische Multi-Zonen-Bereitstellung. Mandrakis Infrastruktur läuft über mehrere Verfügbarkeitszonen innerhalb der EU auf europäischer Hyperscale-Infrastruktur. SFU-Instanzen werden in Benutzernähe bereitgestellt, was die Round-Trip-Latenz für Medienpakete reduziert. Alle Medien-Routings bleiben innerhalb europäischer Grenzen — kein Medienverkehr wird jemals über Nicht-EU-Infrastruktur weitergeleitet.

NAT-Traversal

WebRTCs größte Stärke — direkte Peer-to-Peer-Konnektivität — ist auch seine größte Herausforderung. Die meisten Geräte befinden sich hinter NAT-Firewalls (Network Address Translation), die direkte eingehende Verbindungen verhindern. WebRTC verwendet ICE (Interactive Connectivity Establishment), um einen praktikablen Netzwerkpfad zu entdecken, indem es nacheinander direkte Verbindung, STUN-vermittelte Verbindung und TURN-Relay versucht.

Mandraki betreibt dedizierte TURN-Server neben der SFU-Infrastruktur. TURN fungiert als letztes Relay — wenn ein Teilnehmer keine direkte Verbindung zur SFU herstellen kann (aufgrund restriktiver Firewalls, symmetrischem NAT oder Unternehmens-Proxy-Servern), fließen die Medien durch den TURN-Server. Dies fügt etwas Latenz hinzu, gewährleistet jedoch die Konnektivität.

Die TURN-Server unterstützen sowohl UDP als auch TCP plus TLS für Umgebungen, die nur HTTPS-Verkehr zulassen. Wie alles andere in unserem Stack laufen sie vollständig innerhalb der EU.

Ende-zu-Ende-Verschlüsselung im großen Maßstab

Die SFU-Architektur wurde gezielt gewählt, weil sie die Kompatibilität mit Ende-zu-Ende-Verschlüsselung bewahrt. Mit WebRTC Encoded Transforms und dem SFrame-Protokoll (RFC 9605) werden Medien-Frames auf dem Gerät des Senders verschlüsselt, bevor sie die SFU erreichen. Die SFU leitet die verschlüsselten Frames an die Empfänger weiter, die sie lokal entschlüsseln.

Die SFU hat niemals Zugriff auf Klartextmedien. Sie routet Chiffretext. Das bedeutet, dass selbst im großen Maßstab — mit Dutzenden von Teilnehmern und mehreren gleichzeitigen Anrufen — die Verschlüsselungsgarantien gewahrt bleiben. Kein Server in unserer Infrastruktur sieht oder verarbeitet jemals unverschlüsseltes Audio oder Video.

Dies ist eine grundlegende architektonische Entscheidung. Viele Plattformen behaupten Verschlüsselung, verwenden jedoch MCU-basierte Architekturen, die serverseitige Dekodierung erfordern. Mandrakis SFU-Ansatz bedeutet, dass Verschlüsselung nicht nur ein Feature ist — sie ist eine strukturelle Garantie.

Überwachung und Zuverlässigkeit

WebRTC-Probleme sind notorisch schwer zu diagnostizieren. Wir sammeln client-seitige Telemetrie, einschließlich ICE-Verbindungsstatusübergängen, ausgewählten Kandidatenpaartypen, Round-Trip-Time-Schätzungen, Paketverlustraten und Bandbreitenschätzungen. Diese Metriken werden gestapelt und an unseren Telemetrie-Endpunkt zur Aggregation gesendet.

Serverseitig protokolliert die SFU Transportereignisse, Producer- und Consumer-Lebenszyklen sowie Bandbreitenschätzungen. Kombiniert mit der client-seitigen Telemetrie liefert dies eine umfassende Sicht auf die Anrufqualität, die es uns ermöglicht, Probleme systematisch zu identifizieren und zu beheben.

Echtzeitkommunikation in massivem Maßstab ist eine tiefgreifende technische Herausforderung. Wir investieren weiterhin in die Medieninfrastruktur, die Mandrakis Anrufe zuverlässig, latenzarm und Ende-zu-Ende-verschlüsselt macht — alles innerhalb souveräner europäischer Infrastruktur.