WebRTC

WebRTC: Echtzeit-Kommunikation im Browser

WebRTC (Web Real-Time Communication) ist ein offener Standard und eine Sammlung von Browser-APIs, mit denen zwei Browser Audio, Video und beliebige Daten direkt miteinander austauschen können — Peer-to-Peer — ohne das Medium über einen Server zu leiten und ohne jegliches Plugin. Es ermöglicht Videokonferenzen, Sprachanrufe, Bildschirmfreigabe, live übertragene Spielzustände und latenzarme Dateiübertragungen.

Dieses Kapitel erklärt, was WebRTC bietet, die drei APIs, auf denen es aufbaut, die Signalisierungs- und NAT-Traversal-Konzepte, die die meisten Einsteiger verwirren, sowie ein vollständiges, funktionsfähiges Datenkanal-Beispiel, das Sie auf dieser Seite ausführen können.

Was WebRTC tatsächlich tut

Der Browser kann bereits mit einem Server kommunizieren (siehe Fetch API und WebSockets). WebRTC ergänzt das fehlende Stück: eine Möglichkeit für zwei Clients, miteinander zu sprechen. Sobald eine Peer-Verbindung geöffnet ist, fließen Medien und Daten auf dem kürzestmöglichen Weg — oft direkt zwischen den beiden Rechnern — weshalb die WebRTC-Latenz so viel niedriger ist als das Weiterleiten aller Daten über Ihr Backend.

Typische Anwendungsfälle:

• Audio- und Videoanrufe — Echtzeit-Sprach-/Videoverbindungen, wie Zoom oder Google Meet.
• Bildschirmfreigabe — Bildschirm oder Fenster mit getDisplayMedia() erfassen und an einen Peer streamen.
• Echtzeit-Daten — Spielzustände, Chat, Cursor-Positionen oder Datei-Chunks über einen RTCDataChannel.

Warum WebRTC verwenden

• Peer-to-Peer, geringe Latenz. Medien fließen direkt zwischen Peers, nicht über Ihren Server, sodass Roundtrips kurz sind und Ihre Bandbreitenkosten niedrig bleiben.
• Plugin-frei. In jedem modernen Browser eingebaut — kein Flash, keine native App, kein Download.
• Standardmäßig verschlüsselt. Medien nutzen SRTP und Datenkanäle DTLS; Verschlüsselung ist verpflichtend und kann nicht deaktiviert werden.
• Plattformübergreifend. Funktioniert auf Desktop- und mobilen Browsern sowie in nativen Apps über denselben Standard.
• Offener Standard. Gepflegt von W3C und IETF, sodass er sich ohne Vendor-Lock-in kontinuierlich verbessert.

Die drei Kern-APIs

WebRTC besteht eigentlich aus drei APIs, die zusammenarbeiten:

1. MediaStream API (getUserMedia) — erfasst Audio/Video vom Mikrofon, der Kamera oder dem Bildschirm als MediaStream.
2. RTCPeerConnection — das Herzstück von WebRTC. Es verhandelt, verschlüsselt und pflegt die Verbindung zwischen zwei Peers und überträgt die Medien-Tracks.
3. RTCDataChannel — ein bidirektionaler Kanal zum Senden beliebiger Daten (Strings oder Binärdaten) Peer-to-Peer, ähnlich wie WebSockets, aber ohne Server dazwischen.

Signalisierung: der Teil, den WebRTC nicht übernimmt

Zwei Browser können sich nicht aus dem Nichts heraus finden. Bevor eine Peer-Verbindung geöffnet werden kann, müssen die Peers zwei Arten von Informationen austauschen:

• SDP (Session Description Protocol) — ein "Angebot" und eine "Antwort", die Codecs, Medienformate und Verbindungsparameter beschreiben.
• ICE-Kandidaten — mögliche Netzwerkadressen (IP/Port-Paare), unter denen jeder Peer erreichbar ist.

WebRTC definiert nicht, wie dieser Austausch stattfindet — das ist Ihre Aufgabe, und er wird als Signalisierung bezeichnet. Sie bauen einen Signalisierungskanal mit dem Server-Transport Ihrer Wahl auf; WebSockets ist die häufigste Wahl. Der Ablauf ist immer:

1. Der Anrufer erstellt ein Angebot und sendet es über den Signalisierungsserver.
2. Der Angerufene empfängt das Angebot, erstellt eine Antwort und sendet sie zurück.
3. Beide Peers tauschen ICE-Kandidaten aus, sobald sie entdeckt werden.
4. Die direkte Peer-to-Peer-Verbindung wird hergestellt; der Signalisierungsserver wird nicht mehr benötigt.

STUN und TURN: Firewalls überwinden

Die meisten Geräte sitzen hinter NAT (Network Address Translation) und Firewalls, sodass ein Peer seine eigene öffentliche Adresse selten kennt. Zwei Servertypen lösen dieses Problem:

• STUN-Server — teilt einem Peer seine öffentliche IP/Port mit, damit Peers eine direkte Verbindung versuchen können. Kostengünstig und zustandslos; Google betreibt kostenlose öffentliche Server.
• TURN-Server — leitet Medien weiter, wenn eine direkte Verbindung nicht möglich ist (strenge Unternehmensfirewalls). Er kostet Bandbreite und ist daher ein Fallback, nicht der Standard.

Diese Server werden in der iceServers-Konfiguration angegeben, die an RTCPeerConnection übergeben wird:

const configuration = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    // A TURN server is added for hard-to-reach networks:
    // { urls: 'turn:turn.example.com', username: 'user', credential: 'pass' }
  ],
};

const peerConnection = new RTCPeerConnection(configuration);

Beispiel: Kamera mit getUserMedia erfassen

Der erste Schritt bei jedem Videoanruf ist das Abrufen des lokalen Streams. getUserMedia gibt ein Promise zurück, sodass Sie async/await verwenden können:

<video id="localVideo" autoplay playsinline muted></video>

const localVideo = document.getElementById('localVideo');

async function startCamera() {
  try {
    const stream = await navigator.mediaDevices.getUserMedia({
      video: true,
      audio: true,
    });
    localVideo.srcObject = stream; // show the live camera feed
    return stream;
  } catch (error) {
    console.error('Could not access camera/microphone:', error.message);
  }
}

startCamera();

getUserMedia funktioniert nur in einem sicheren Kontext (HTTPS oder localhost) und fordert den Benutzer zur Erlaubniserteilung auf — man kann jemanden nie stillschweigend aufnehmen.

Beispiel: ein vollständiger Datenkanal zwischen zwei Peers

Der anschaulichste Weg, WebRTC in Aktion zu sehen, ist, zwei RTCPeerConnection-Objekte in einem einzigen Skript miteinander zu verbinden. Hier befinden sich beide Peers auf derselben Seite, sodass wir ihre Signalisierung direkt verdrahten können, anstatt über einen Server zu gehen — der SDP/ICE-Austausch entspricht genau dem, was ein echter Signalisierungsserver übertragen würde. Fügen Sie dies in eine Browser-Konsole auf einer beliebigen HTTPS-Seite ein und beobachten Sie die Ausführung:

// Two peers, normally on different machines.
const caller = new RTCPeerConnection();
const callee = new RTCPeerConnection();

// --- Signaling: hand each peer's ICE candidates to the other.
// In production this travels over WebSockets; here we call directly.
caller.onicecandidate = (e) => e.candidate && callee.addIceCandidate(e.candidate);
callee.onicecandidate = (e) => e.candidate && caller.addIceCandidate(e.candidate);

// The callee listens for the channel the caller opens.
callee.ondatachannel = (event) => {
  const channel = event.channel;
  channel.onmessage = (e) => {
    console.log('Callee received:', e.data);
    channel.send('pong'); // reply over the same channel
  };
};

// The caller creates the data channel.
const channel = caller.createDataChannel('chat');
channel.onopen = () => channel.send('ping');
channel.onmessage = (e) => console.log('Caller received:', e.data);

// --- Offer / answer negotiation.
async function connect() {
  const offer = await caller.createOffer();
  await caller.setLocalDescription(offer);
  await callee.setRemoteDescription(offer);

  const answer = await callee.createAnswer();
  await callee.setLocalDescription(answer);
  await caller.setRemoteDescription(answer);
}

connect();
// Logs:
// Callee received: ping
// Caller received: pong

Das Muster ist für Video dasselbe: Anstatt createDataChannel aufzurufen, rufen Sie peerConnection.addTrack(track, stream) für jeden Track von getUserMedia auf und lesen eingehende Medien in einem ontrack-Handler:

const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
stream.getTracks().forEach((track) => peerConnection.addTrack(track, stream));

// The remote peer's media arrives here:
peerConnection.ontrack = (event) => {
  document.getElementById('remoteVideo').srcObject = event.streams[0];
};

Häufige Fallstricke

• HTTPS ist erforderlich. getUserMedia und getDisplayMedia schlagen außerhalb eines sicheren Kontexts (HTTPS oder localhost) fehl.
• Ein Signalisierungsserver wird weiterhin benötigt. WebRTC verwaltet die Medien, aber Sie müssen den Angebot/Antwort/ICE-Austausch selbst aufbauen — normalerweise über WebSockets.
• Erstellen Sie Angebot/Antwort immer in der richtigen Reihenfolge. setLocalDescription muss vor setRemoteDescription für die entsprechende Seite ausgeführt werden, sonst schlägt die Aushandlung fehl.
• Vergessen Sie keinen TURN-Server in der Produktion. STUN allein schlägt in restriktiven Netzwerken fehl; ohne TURN werden ~10–20 % der realen Verbindungen nicht hergestellt.
• Berechtigungen können verweigert werden. Umschließen Sie getUserMedia mit try/catch und behandeln Sie die Ablehnung elegant.

Zusammenfassung

WebRTC gibt dem Browser echte Peer-to-Peer-Audio-, Video- und Datenfähigkeiten. Verwenden Sie getUserMedia zum Erfassen von Medien, RTCPeerConnection zum Aushandeln und Aufrechterhalten der Verbindung und RTCDataChannel für beliebige Daten. WebRTC stellt keine Signalisierung bereit — Sie tauschen SDP-Angebote/Antworten und ICE-Kandidaten selbst aus, typischerweise über WebSockets, und konfigurieren STUN/TURN-Server für die NAT-Traversal. Mit diesen Bausteinen können Sie Videoanrufe, Bildschirmfreigabe und Echtzeit-Zusammenarbeit vollständig im Browser realisieren.

Übungen