WebRTC, SFUs und Sprach-Codecs erklärt
Wie WebRTC Audio überträgt, wie Opus Sprache komprimiert und wann Gruppenvideo einen SFU braucht. Ein Entwicklerleitfaden mit Voxals Architektur und RFC-Verweisen.
WebRTC überträgt Audio und Video zwischen Browsern, ein Codec wie Opus komprimiert Sprache, damit sie über die Leitung passt, und eine Selective Forwarding Unit (SFU) ist ein Server, der in größeren Anrufen das Video jedes Teilnehmers an alle anderen weiterleitet. Diese drei Bausteine erklären das meiste von dem, was zwischen einem Mikrofon und einem entfernten Lautsprecher passiert.
Dieser Leitfaden richtet sich an Entwickler und neugierige Leser, die die Mechanik verstehen wollen: Signalisierung, ICE, STUN und TURN, RTP, Opus und den Kompromiss zwischen einem Peer-to-Peer-Mesh und einem SFU. Am Ende zeigt er, wie Voxal sie kombiniert: Sprache bleibt Peer-to-Peer, während Kamera und Bildschirmfreigabe einen SFU nutzen können. Wenn Sie nur das Konzept verstehen möchten, beginnen Sie mit Was ist Peer-to-Peer-Sprachchat.
1. Was ist WebRTC?
WebRTC ist eine Sammlung von Standards und Browser-APIs für Audio-, Video- und Datenkommunikation in Echtzeit.
Damit können Anwendungen Medienverbindungen zwischen kompatiblen Geräten aufbauen, ohne dass Entwickler jeden Transport- und Sicherheitsmechanismus selbst von Grund auf implementieren müssen.
WebRTC ist kein einzelnes Protokoll. Mehrere Komponenten arbeiten zusammen.
Signalisierung
Bevor zwei Geräte eine Medienverbindung aufbauen können, müssen sie Informationen über die Sitzung und ihre Verbindungsfähigkeiten austauschen.
Dieser Vorgang heißt Signalisierung. Anwendungen wählen ihren Signalisierungsmechanismus selbst; WebRTC schreibt weder einen universellen Signalisierungsserver noch ein universelles Signalisierungsprotokoll vor.
Voxal nutzt die Signalisierung, um die Raummitgliedschaft und den Verbindungsaufbau zu koordinieren. Der Signalisierungspfad ist vom Medienpfad getrennt.
ICE, STUN und TURN
Geräte befinden sich häufig hinter Routern, Firewalls oder Network Address Translation (NAT). Einen funktionierenden Verbindungsweg zu finden, kann daher komplizierter sein, als zwei öffentliche IP-Adressen zu verbinden.
WebRTC verwendet Interactive Connectivity Establishment (ICE), um mögliche Verbindungspfade zu sammeln und zu testen.
- STUN hilft einem Gerät herauszufinden, wie es aus dem öffentlichen Netz erscheint.
- TURN stellt einen Relay-Pfad bereit, wenn keine geeignete direkte Verbindung hergestellt werden kann.
Ein TURN-Relay leitet verschlüsselten Medienverkehr weiter. Es ist nicht dasselbe wie ein SFU, der Medienverbindungen terminiert und Medienströme selektiv weiterleitet.
Eine direkte Verbindung ist oft wünschenswert, aber ein Relay kann für die Konnektivität unverzichtbar sein.
RTP und sicherer Medientransport
Echtzeitmedien werden üblicherweise über das Real-time Transport Protocol (RTP) transportiert, begleitet von RTCP für Steuerung und Berichte.
WebRTC verwendet Secure RTP (SRTP) zum Schutz der Medien. Die Transportschicht hilft bei der Zustellung der Pakete, während der Codec festlegt, wie das Audio oder Video selbst dargestellt wird.
Das sind getrennte Zuständigkeiten: Ein Codec baut keine Netzwerkverbindung auf, und eine Netzwerkverbindung bestimmt nicht, wie Ton komprimiert wird.
2. Was ist ein Sprach-Codec?
Ein Codec kodiert und dekodiert Medien. Bei der Sprachkommunikation besteht seine Aufgabe darin, Sprache effizient darzustellen und dabei Verständlichkeit und eine akzeptable Audioqualität zu bewahren.
Ohne Kompression kann die Übertragung von Roh-Audio deutlich mehr Bandbreite verbrauchen, als eine Sprachanwendung benötigt.
Ein Codec wägt mehrere Faktoren gegeneinander ab:
- Audioqualität und Sprachverständlichkeit.
- Bitrate und Bandbreitenverbrauch.
- Komplexität von Kodierung und Dekodierung.
- Verzögerung und Framedauer.
- Verhalten bei wechselnden Netzwerkbedingungen.
Es gibt nicht den einen besten Codec für jede Anwendung. Musik-Streaming, Telefonate, Gaming-Chat und Gruppengespräche in Echtzeit haben unterschiedliche Prioritäten.
Warum Opus so weit verbreitet ist
Opus ist ein interaktiver Audio-Codec, der für Anwendungen wie Voice over IP, Videokonferenzen und In-Game-Chat entwickelt wurde.
Er unterstützt eine große Bandbreite an Bitraten, Abtastraten und Framedauern. Diese Flexibilität macht ihn sowohl für Sprache als auch für anspruchsvollere Audioanwendungen geeignet.
Opus ist außerdem ein Audio-Codec, dessen Implementierung für WebRTC-Endpunkte gemäß den WebRTC-Anforderungen an Audio-Codecs verpflichtend ist.
Das bedeutet nicht, dass jede WebRTC-Verbindung immer Opus verwendet. Welcher Codec tatsächlich gewählt wird, hängt von den Fähigkeiten ab, die die beteiligten Endpunkte aushandeln.
In Voxal verwendet die WebRTC-Audio-Pipeline des Browsers in der dokumentierten Architektur standardmäßig Opus. Der Browser übernimmt einen Großteil der zugrunde liegenden Kodierung, Übertragung und Dekodierung.
Für eine Echtzeit-Sprachanwendung ist der Codec nur ein Teil des Erlebnisses. Mikrofonqualität, Audioverarbeitung, Paketverlust, Netzwerklatenz, Jitter-Buffering und die Wiedergabe auf dem Gerät spielen ebenfalls eine Rolle.
3. Was ist ein SFU?
SFU steht für Selective Forwarding Unit.
Ein SFU ist ein Medienserver, der häufig für Gruppen-Videoanrufe eingesetzt wird. Statt von jedem Teilnehmer zu verlangen, einen eigenen Videostrom direkt an jeden anderen Teilnehmer zu senden, kann jeder Teilnehmer seine Medien an den SFU schicken, der die passenden Ströme an die übrigen Teilnehmer weiterleitet.
Stellen Sie sich einen Raum mit sechs Personen vor, die jeweils einen Kamerastrom senden.
In einem vollständigen Peer-to-Peer-Mesh muss jeder Teilnehmer sein ausgehendes Video möglicherweise an fünf andere Teilnehmer hochladen. In einer Topologie mit serverseitiger Weiterleitung kann jeder Teilnehmer einen Strom an den SFU senden, der die Verteilung übernimmt.
Das kann die Anzahl der getrennten ausgehenden Videoströme, die ein Teilnehmer aufrechterhalten muss, deutlich verringern.
Was macht ein SFU eigentlich?
Ein SFU empfängt in der Regel kodierte Medienströme und leitet sie selektiv weiter. Je nach Implementierung und ausgehandelten Funktionen kann er auswählen, welche Ströme oder Qualitätsstufen er an welchen Empfänger sendet.
Ein Teilnehmer, der nur eine kleine Vorschau betrachtet, braucht zum Beispiel nicht dieselbe Videoqualität wie jemand, der einen Sprecher im Vollbild anzeigt.
Ein SFU kann helfen, diese unterschiedlichen Anforderungen zu bewältigen, ohne dass jeder Sender unabhängig für jeden Empfänger einen eigenen Strom übertragen muss.
Ein SFU ist jedoch nicht kostenlos. Er bringt Infrastruktur, Serverbandbreite, Betriebskosten und eine weitere Komponente im Medienpfad mit sich.
Ein SFU hat außerdem ein anderes Datenschutzmodell als ein TURN-Relay. Da ein SFU den Medientransport terminiert und Medien selektiv weiterleitet, kann er technisch auf die empfangenen Medien zugreifen. Die Verschlüsselung zwischen einem Teilnehmer und einem SFU bietet für sich genommen keine Ende-zu-Ende-Vertraulichkeit gegenüber diesem SFU.
4. Peer-to-Peer-Mesh vs. SFU
Die beiden Architekturen lösen verwandte, aber unterschiedliche Probleme.
Peer-to-Peer-Mesh
Jeder Teilnehmer baut Medienverbindungen zu den anderen Teilnehmern auf.
Vorteile:
- Direkte Medienpfade sind möglich.
- Es wird kein zentraler Medienserver zur Weiterverteilung der Medien benötigt.
- Kleine Räume können ohne Dienst zur Medienweiterleitung funktionieren.
Nachteile:
- Jeder Sender muss möglicherweise einen eigenen Strom an jeden anderen Teilnehmer hochladen.
- Die Zahl der Medienverbindungen wächst mit der Raumgröße.
- Upload-Bandbreite und Verbindungsverwaltung können zu begrenzenden Faktoren werden.
SFU-basierte Verteilung
Jeder Teilnehmer sendet Medien an einen zentralen Weiterleitungsdienst, der sie an die anderen Teilnehmer verteilt.
Vorteile:
- Effizientere Verteilung in vielen Gruppenvideo-Szenarien.
- Weniger Bedarf, dass jeder Sender separate Kopien an jeden Empfänger hochlädt.
- Mehr Kontrolle darüber, welche Videoströme und Qualitätsstufen Empfänger erhalten.
Nachteile:
- Zusätzliche Server-Infrastruktur und Bandbreitenkosten.
- Ein Vermittler tritt in den Medienpfad ein.
- Das Datenschutz- und Vertrauensmodell unterscheidet sich von direkter Peer-to-Peer-Kommunikation.
Entscheidend ist, nicht davon auszugehen, dass für jeden Medientyp dieselbe Topologie verwendet werden muss. Audio und Video haben unterschiedliche Verkehrsmuster und Anforderungen.
5. Warum Voxal Sprache Peer-to-Peer hält, für Video aber einen SFU nutzen kann
Voxal trennt Sprach-Audio von Kamera- und Bildschirmfreigabe-Video.
Sprach-Audio bleibt immer Peer-to-Peer. Es wird nie über den optionalen Video-SFU geleitet.
Das ist eine bewusste Architekturentscheidung: Sprache ist die zentrale Kommunikationsfunktion, und Voxal nutzt den SFU nicht als zentralen Dienst zur Audioverteilung.
Kamera- und Bildschirmfreigabe-Video sind anders. In größeren Räumen kann ein vollständiges Peer-to-Peer-Mesh erfordern, dass jeder Teilnehmer mehrere Videoströme hochlädt. Das wird mit wachsender Teilnehmerzahl immer anspruchsvoller.
Voxal kann daher den Realtime-SFU von Cloudflare für Video und Bildschirmfreigabe verwenden, wenn die konfigurierte Routing-Einstellung es erlaubt und der Raum die praktischen Grenzen des Mesh überschreitet.
Die Routing-Einstellung ist entscheidend:
- Allow relay for large rooms: Voxal kann den SFU nutzen, wenn der Raum über eine komfortable Peer-to-Peer-Videotopologie hinauswächst.
- Prefer direct: Voxal versucht zuerst Peer-to-Peer und fragt nach, bevor es ein Relay zulässt, wenn das Mesh ungeeignet wird.
- Direct only: Video und Bildschirmfreigabe nutzen nie den SFU, auch wenn ein großer Raum Mühe hat, alle direkten Verbindungen aufzubauen.
Diese Einstellungen betreffen Video und Bildschirmfreigabe, nicht das Sprach-Audio.
Warum nicht alles über denselben Server leiten?
Weil die beste Topologie von dem Verkehr abhängt, der transportiert wird.
Ein Sprachstrom ist in der Regel viel kleiner als ein Kamerastrom. Sprache über einen zentralen Weiterleitungsdienst zu schicken, würde einen anderen Kompromiss bei Infrastruktur und Datenschutz mit sich bringen, ohne für Voxals gewählte Spracharchitektur notwendig zu sein.
Video hat ein anspruchsvolleres Bandbreitenprofil und kann mit wachsender Gruppengröße erheblich von serverunterstützter Verteilung profitieren.
Die Trennung beider erlaubt es Voxal, sein Peer-to-Peer-Sprachmodell beizubehalten und zugleich eine skalierbarere Option für Gruppenvideo anzubieten.
6. Was das für den Datenschutz bedeutet
Netzwerkbegriffe werden manchmal so verwendet, als garantierten sie automatisch ein bestimmtes Datenschutzniveau. Das tun sie nicht.
Peer-to-Peer-Audio bedeutet, dass Sprachmedien nicht über einen zentralen Medienserver laufen, aber Signalisierungsserver können weiterhin Verbindungen koordinieren und zugehörige Metadaten verarbeiten.
Ein TURN-Relay leitet verschlüsselte Medien weiter, ohne sie zu dekodieren. Ein SFU dagegen terminiert den Medientransport, um Ströme selektiv weiterzuleiten, und kann technisch auf das empfangene Video zugreifen.
Deshalb ist Voxals Unterscheidung wichtig:
- Sprache bleibt Peer-to-Peer, optional über ein verschlüsseltes TURN-Relay.
- Kamera- und Bildschirmfreigabe-Video können in größeren Räumen je nach Routing-Einstellung einen SFU nutzen.
- Die lokale Verarbeitung virtueller Hintergründe findet auf dem Gerät des Senders statt, bedeutet aber allein nicht, dass jede Videoverbindung direkt ist.
Den tatsächlichen Medienpfad zu verstehen ist nützlicher, als eine Anwendung einfach als serverlos zu beschreiben.
7. Alles zusammengefasst
Eine Echtzeit-Kommunikationsanwendung kombiniert mehrere unabhängige Schichten:
- Signalisierung koordiniert Teilnehmer und Verbindungsaufbau.
- ICE, STUN und TURN helfen beim Aufbau eines tragfähigen Netzwerkpfads.
- WebRTC und sicherer RTP-Transport übertragen Echtzeitmedien.
- Ein Codec wie Opus stellt das Audio effizient dar.
- Die Netzwerktopologie bestimmt, ob Medien direkt zwischen Peers oder über einen Weiterleitungsdienst fließen.
Voxals Design wendet diese Entscheidungen getrennt auf Sprache und Video an. Das Ergebnis ist eine sprachzentrierte Architektur, in der Audio Peer-to-Peer bleibt, während Video und Bildschirmfreigabe optional serverunterstützte Weiterleitung nutzen können, wenn größere Räume es erfordern.
Diese Unterscheidungen sind beim Entwurf jedes Echtzeit-Kommunikationssystems wichtig. Ziel ist nicht, einfach Server zu minimieren oder direkte Verbindungen zu maximieren, sondern bewusste Abwägungen zwischen Latenz, Bandbreite, Zuverlässigkeit, Skalierbarkeit und Datenschutz zu treffen.
Voxal ausprobieren
Voxal vereint Peer-to-Peer-Sprachchat, Push-to-Talk (Sprechtaste), Freisprechmodus, Rauschunterdrückung sowie optionales Video und Bildschirmfreigabe.
Probieren Sie Voxal in Ihrem Browser aus oder erkunden Sie die Implementierung im Open-Source-Repository von Voxal.
Weiterführende Artikel: Was ist Peer-to-Peer-Sprachchat? · Was ist Push-to-Talk? Ein praktischer Leitfaden · Voxals Dokumentation zum Video-Routing
