WebRTC (Web Real-Time Communication) ist eine Open-Source-Technologie, die Echtzeitkommunikation direkt im Browser ermöglicht — Audio, Video und Daten, ohne Plugins und ohne zusätzliche Software. Statt über einen zentralen Server zu laufen, können sich Browser direkt miteinander verbinden (Peer-to-Peer), was Latenz reduziert und die Übertragungsqualität verbessert.
WebRTC wurde 2011 von Google als Open-Source-Projekt initiiert und ist heute ein offizieller W3C- und IETF-Standard. Alle großen Browser unterstützen WebRTC: Chrome, Firefox, Safari, Edge und Opera. Anwendungen wie Google Meet, Facebook Messenger, Discord und Digital Samba basieren auf WebRTC.
In diesem Artikel erfährst du, wie WebRTC technisch funktioniert, welche Architekturmodelle es gibt, wofür es eingesetzt wird und welche Vor- und Nachteile die Technologie hat.
Inhaltsübersicht
- Was ist WebRTC?
- Wie funktioniert WebRTC?
- WebRTC-Architekturen: P2P, SFU und MCU
- Wofür wird WebRTC verwendet?
- Was sind die Vor- und Nachteile von WebRTC?
- WebRTC und Digital Samba
- Häufig gestellte Fragen
Was ist WebRTC?
WebRTC ist ein Set von JavaScript-APIs und Protokollen, das Browsern die Fähigkeit gibt, in Echtzeit Audio, Video und beliebige Daten direkt auszutauschen — ohne Umweg über einen zentralen Medienserver. Die Kommunikation erfolgt verschlüsselt (DTLS und SRTP sind standardmäßig aktiviert), was WebRTC zu einer der sichersten Methoden für Echtzeitkommunikation macht.
Drei Kern-APIs bilden das Fundament:
getUserMedia — Greift auf Kamera und Mikrofon des Nutzers zu. Der Browser fragt den Nutzer um Erlaubnis, bevor Audio- oder Videostreams aktiviert werden.
RTCPeerConnection — Die zentrale API für den Aufbau und die Verwaltung von Peer-to-Peer-Verbindungen. Sie handhabt die gesamte Komplexität: Codec-Verhandlung, Netzwerk-Traversierung (NAT/Firewall), Verschlüsselung und adaptive Bitrate.
RTCDataChannel — Ermöglicht den Austausch beliebiger Daten zwischen Peers — Text, Dateien, JSON-Objekte. Nützlich für Chat, Dateifreigabe und kollaborative Tools.
Wie funktioniert WebRTC technisch?
Der Verbindungsaufbau zwischen zwei Browsern ist ein mehrstufiger Prozess:
1. Signalling — die Verhandlung
Bevor zwei Browser direkt kommunizieren können, müssen sie Informationen austauschen: Welche Codecs werden unterstützt? Wie lauten die Netzwerkadressen? Welche Medienformate sind verfügbar?
Dieser Informationsaustausch heißt Signalling. WebRTC definiert bewusst kein Signalling-Protokoll — Entwickler können WebSocket, HTTP, SIP oder jedes andere Protokoll nutzen. Das Signalling läuft über einen Server, der die Nachrichten zwischen den Peers weiterleitet, aber keine Mediendaten verarbeitet.
2. SDP — Session Description Protocol
Die ausgetauschten Informationen werden im SDP-Format (Session Description Protocol) beschrieben. Ein SDP-Angebot (Offer) enthält:
- Unterstützte Audio- und Video-Codecs
- Verschlüsselungsparameter
- Netzwerk-Kandidaten (ICE Candidates)
- Medienrichtung (senden, empfangen, beides)
Peer A erstellt ein Offer (createOffer()), Peer B antwortet mit einem Answer (createAnswer()). Beide setzen die jeweilige Beschreibung als Local/Remote Description. Mehr dazu: ICE und SDP in WebRTC
3. ICE — Interactive Connectivity Establishment
ICE ist der Mechanismus, der eine direkte Verbindung zwischen zwei Peers herstellt — auch wenn einer oder beide hinter einem NAT (Network Address Translation) oder einer Firewall sitzen.
ICE sammelt Verbindungskandidaten aus drei Quellen:
Host Candidates — lokale IP-Adressen des Geräts. Funktioniert nur in lokalen Netzwerken.
Server Reflexive Candidates — über einen STUN-Server (Session Traversal Utilities for NAT) ermittelte öffentliche IP-Adressen. In ~80 % der Fälle reicht STUN für eine direkte Verbindung.
Relay Candidates — wenn keine direkte Verbindung möglich ist (z.B. bei symmetrischem NAT), leitet ein TURN-Server (Traversal Using Relays around NAT) die Medien weiter. TURN ist der Fallback — er funktioniert immer, verbraucht aber mehr Bandbreite und erhöht die Latenz.
4. DTLS und SRTP — Verschlüsselung
Alle WebRTC-Verbindungen sind standardmäßig verschlüsselt:
- DTLS (Datagram Transport Layer Security) — verschlüsselt den Signalling-Kanal und den Data Channel
- SRTP (Secure Real-time Transport Protocol) — verschlüsselt Audio- und Videostreams
Diese Verschlüsselung ist nicht optional — sie ist in den Standard eingebaut. Das macht WebRTC grundsätzlich sicherer als viele proprietäre Videolösungen, bei denen Verschlüsselung erst nachträglich implementiert wird. Mehr dazu: Ende-zu-Ende-Verschlüsselung in WebRTC, der wichtigsten Bausteine moderner Echtzeitkommunikation.
WebRTC-Architekturen: P2P, SFU und MCU
Für 1:1-Gespräche ist Peer-to-Peer ideal. Aber sobald mehr als zwei Teilnehmer in einem Call sind, stößt reines P2P an Grenzen — jeder Teilnehmer müsste seinen Stream an jeden anderen senden. Bei 10 Teilnehmern wären das 9 gleichzeitige Uploads pro Person.
Deshalb nutzen professionelle WebRTC-Plattformen Medienserver:
P2P (Peer-to-Peer)
Direkte Verbindung zwischen zwei Browsern. Kein Medienserver dazwischen. Minimale Latenz, maximale Privatsphäre (E2EE by default), geringste Infrastrukturkosten.
Geeignet für: 1:1-Gespräche, einfache Videochats.
Limitierung: Skaliert nicht über 3–4 Teilnehmer hinaus. Upload-Bandbreite wird bei jedem zusätzlichen Teilnehmer multipliziert.
SFU (Selective Forwarding Unit)
Ein Medienserver, der Videostreams von Teilnehmern empfängt und an die anderen weiterleitet — ohne die Streams zu dekodieren oder zusammenzumischen. Jeder Teilnehmer sendet seinen Stream nur einmal an den SFU, der ihn an alle anderen verteilt.
Geeignet für: Gruppenvideokonferenzen, Webinare, virtuelle Klassenzimmer.
Vorteil: Deutlich geringerer Upload-Bedarf pro Teilnehmer. Unterstützt Simulcast — mehrere Qualitätsstufen gleichzeitig, sodass der SFU für jeden Empfänger die passende Qualität wählen kann.
Digital Samba nutzt eine SFU-Architektur für maximale Skalierbarkeit und Bandbreiteneffizienz.
MCU (Multipoint Conferencing Unit)
Ein Medienserver, der alle eingehenden Streams zu einem einzigen Stream zusammenmischt (mixing). Jeder Teilnehmer empfängt nur einen komponierten Stream.
Geeignet für: Szenarien mit sehr vielen Teilnehmern und limitierter Client-Bandbreite.
Nachteil: Extrem hohe Serverlast (Dekodierung + Komposition + Re-Kodierung für jeden Stream), signifikant höhere Infrastrukturkosten und höhere Latenz. In der Praxis wird MCU nur noch selten eingesetzt.
In der Praxis dominiert SFU die professionelle WebRTC-Landschaft, weil es den besten Kompromiss zwischen Skalierbarkeit, Kosten und Qualität bietet.
Wofür wird WebRTC eingesetzt?
Videokonferenzen
Der prominenteste Anwendungsfall. Google Meet, Zoom (teilweise), Discord und Digital Samba nutzen WebRTC als Grundlage für Browser-basierte Videocalls. Der Vorteil: Kein Download, kein Plugin — einfach einen Link klicken und teilnehmen.
Telemedizin
Sichere, verschlüsselte Videokonsultationen zwischen Arzt und Patient — direkt im Browser. WebRTCs eingebaute Verschlüsselung macht es besonders geeignet für DSGVO-konforme Telehealth-Anwendungen.
Online-Bildung
Virtuelle Klassenzimmer mit Echtzeit-Video, Bildschirmfreigabe und interaktiven Tools. WebRTC ermöglicht niedrige Latenz, was für Live-Unterricht entscheidend ist.
Live-Streaming mit Ultra-Low-Latency
Traditionelle Streaming-Protokolle (HLS, DASH) haben 10–30 Sekunden Latenz. WebRTC ermöglicht Sub-Sekunden-Latenz — entscheidend für interaktive Live-Events, Auktionen und Sport-Streaming.
Peer-to-Peer-Dateifreigabe
Über RTCDataChannel können Dateien direkt zwischen Browsern übertragen werden — ohne Upload auf einen Server. Schnell, privat und verschlüsselt.
IoT und Embedded Devices
WebRTC wird zunehmend für die Kommunikation mit IoT-Geräten genutzt: Überwachungskameras, Smart-Home-Geräte, industrielle Sensoren. Der Browser wird zur universellen Steuerungsoberfläche.
Was sind die Vor- und Nachteile von WebRTC?
Vorteile von WebRTC
-
Open Source: WebRTC ist ein offener Standard, gepflegt von einer großen Community. Keine Lizenzkosten, keine Vendor-Lock-In.
-
Browserübergreifend: Chrome, Firefox, Safari, Edge — WebRTC funktioniert in allen modernen Browsern, auf Desktop und Mobile.
-
Kein Plugin nötig: Nutzer klicken einen Link und sind im Call. Keine Installation, kein Download — die niedrigste mögliche Einstiegshürde.
-
Verschlüsselung by Default: DTLS und SRTP sind standardmäßig aktiviert. Alle Daten, Audio und Video sind verschlüsselt — nicht optional, sondern eingebaut.
-
Niedrige Latenz: Peer-to-Peer-Verbindungen und effiziente Codecs sorgen für Echtzeit-Erlebnisse mit minimaler Verzögerung.
-
Adaptive Qualität: WebRTC passt Bitrate und Videoqualität automatisch an die Netzwerkbedingungen an. Zusammen mit Simulcast wird so für jeden Teilnehmer die bestmögliche Qualität gewährleistet.
Herausforderungen von WebRTC
-
Signalling muss selbst implementiert werden: WebRTC liefert kein fertiges Signalling — Entwickler müssen den Mechanismus zur Verbindungsverhandlung selbst bauen. Das erhöht die Komplexität, bietet aber maximale Flexibilität.
-
NAT-Traversierung: Nicht alle Netzwerke erlauben direkte P2P-Verbindungen. STUN reicht in ~80 % der Fälle, aber für den Rest braucht man TURN-Server, die zusätzliche Infrastruktur und Kosten bedeuten.
-
Browser-Unterschiede: Obwohl WebRTC in allen großen Browsern unterstützt wird, gibt es Implementierungsunterschiede. Safari hat historisch langsamer neue Features übernommen als Chrome oder Firefox.
-
Skalierung: Reines P2P skaliert nicht für Gruppenvideokonferenzen. Professionelle Anwendungen brauchen SFU/MCU-Infrastruktur. Mehr dazu: Die 10 häufigsten WebRTC-Probleme und wie Digital Samba sie löst.
WebRTC und Digital Samba
Digital Samba ist ein WebRTC-Unternehmen mit über 20 Jahren Erfahrung in Videokonferenz-Technologie. Unsere gesamte Plattform basiert auf WebRTC — vom Audio/Video-Streaming über Bildschirmfreigabe bis hin zu Echtzeit-Datenkanälen.
Was Digital Samba technisch auszeichnet:
-
SFU-Architektur für optimale Skalierbarkeit — von 1:1-Gesprächen bis zu Konferenzen mit hunderten Teilnehmern.
-
Simulcast — jeder Teilnehmer sendet mehrere Qualitätsstufen, der Server wählt für jeden Empfänger die passende Qualität basierend auf dessen Bandbreite.
-
Ende-zu-Ende-Verschlüsselung — nicht nur DTLS/SRTP (Transport-Verschlüsselung), sondern echte E2EE, bei der selbst unsere Server keinen Zugriff auf die Medieninhalte haben.
-
EU-Infrastruktur — Hosting in der EU, DSGVO-konform, ohne US-Hyperscaler-Abhängigkeit.
-
SDK + REST API — Integration per npm install @digitalsamba/embedded-sdk. Dokumentation: docs.digitalsamba.com
→ Features ansehen | Preise vergleichen | Digital Samba Embedded
Häufig gestellte Fragen
