WebRTC: Was es ist, Architektur und Funktionsprinzip

Was ist WebRTC

WebRTC (Web Real-Time Communication) ist ein von Google im Jahr 2011 gestartetes Open-Source-Projekt, das von W3C (JavaScript API) und IETF (Protokolle) standardisiert wurde. Hauptziel ist die Bereitstellung von Kommunikation mit niedriger Latenz zwischen Browsern und Anwendungen ohne Installation von Plugins oder Drittanbieter-Software.

Im Gegensatz zu traditionellen Lösungen (RTMP, HLS), bei denen Video über einen Server läuft, verwendet WebRTC eine Peer-to-Peer-Architektur: Daten werden direkt zwischen den Teilnehmern übertragen. Dies bietet eine Latenz von 200-500 ms im Vergleich zu 3-10 Sekunden bei HLS — ein entscheidender Unterschied für Sprach- und Videoanrufe, Game-Streaming und Remote-Chirurgie.

Laut Google WebRTC Team (2025) wird die Technologie in Anwendungen mit insgesamt über 5 Milliarden Installationen verwendet: Google Meet, WhatsApp, Discord, Telegram, Zoom (teilweise). Mehr als 85% der Venture-Startups im Bereich Telehealth und EdTech wählen WebRTC als ihren Basis-Echtzeit-Transport.

Die mobile Entwicklung erhielt 2013 mit der Veröffentlichung von libjingle_peerconnection volle WebRTC-Unterstützung — eine native Implementierung für Android und iOS. Heute haben beide Plattformen stabile SDKs mit Unterstützung für Hardware-Kodierung von H.264 und VP8, Kamera, Mikrofon und Gerätelautsprecher.

WebRTC-Architektur und -Protokolle

Die WebRTC-Architektur besteht aus drei Schichten. Die oberste Schicht ist die JavaScript API (oder native API für mobile Plattformen), die mittlere sind die Transportprotokolle, die unterste sind Codecs und Sicherheit. Jede Schicht löst ihre eigene Aufgabe, aber alle sind für den Verbindungsaufbau erforderlich.

Wichtige WebRTC-APIs

MediaStream (getUserMedia) — erfasst Audio und Video von Mikrofon und Kamera des Geräts. RTCPeerConnection — verwaltet die P2P-Verbindung: Kodierung, Transport, Bitratenanpassung. RTCDataChannel — überträgt beliebige Daten (Text, Dateien, Binärnachrichten) über denselben Kanal.

// WebRTC JavaScript API (Browser-Beispiel)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Echtzeit-Protokolle

WebRTC verwendet SRTP (Secure Real-Time Transport Protocol) für Audio und Video — eine gesicherte Version von RTP mit AES-128-Verschlüsselung. Die Sitzungsverwaltung erfolgt über SCTP (Stream Control Transmission Protocol) über DTLS. Jeder Datenstrom wird obligatorisch verschlüsselt: WebRTC hat keinen ungesicherten Modus.

• SRTP/SRTCP — verschlüsselte Übertragung von Medienströmen mit Schutz vor Replay-Angriffen
• DTLS-SRTP — Verschlüsselungsschlüssel-Etablierung über Datagram TLS über UDP
• SCTP — zuverlässige oder teilweise zuverlässige Datenzustellung für DataChannel
• ICE (Interactive Connectivity Establishment) — Framework zum Finden eines Netzwerkpfads zwischen Peers
• Trickle ICE — inkrementelle Version von ICE, bei der Kandidaten bei Entdeckung gesendet werden, was den Verbindungsaufbau beschleunigt

NAT-Traversal: ICE, STUN und TURN

Die größte technische Herausforderung von WebRTC ist die Herstellung einer P2P-Verbindung zwischen Geräten, die sich hinter NAT (Network Address Translation) befinden. Ohne spezielle Mechanismen können Geräte einander nicht direkt erreichen, da ihre lokalen IP-Adressen aus dem Internet nicht sichtbar sind.

STUN — Ermittlung der öffentlichen Adresse

STUN (Session Traversal Utilities for NAT) — ein Server, der die Frage „‪Wie lauten meine öffentliche IP und mein Port?‬“ beantwortet. Der Client sendet eine Anfrage an den STUN-Server, der Server sieht seine öffentliche Adresse und gibt sie an den Client zurück. Google betreibt öffentlich den STUN-Server stun:stun.l.google.com:19302.

// WebRTC auf iOS — ICE-Server-Konfiguration
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — Relay-Verbindung

TURN (Traversal Using Relays around NAT) — ein Relay-Server für Fälle, in denen STUN nicht hilft (symmetrisches NAT oder Unternehmensfirewalls). In diesem Modus passieren alle Daten den TURN-Server — dies reduziert die Geschwindigkeit und erhöht die Latenz, garantiert aber Verbindung in 99% der Fälle.

TURN ist die teuerste Komponente der WebRTC-Infrastruktur, da der Server den gesamten Medienverkehr durch sich selbst leitet. Laut Coturn Project (2025) verarbeitet ein typischer TURN-Server mit 8 vCPU und 16 GB RAM etwa 200 gleichzeitige Audioanrufe oder 40 HD-Videoanrufe.

ICE-Prozess

ICE sammelt alle möglichen Kandidaten (lokale IP, öffentliche IP über STUN, Relay über TURN) und versucht, eine Verbindung in der Reihenfolge der Priorität herzustellen. Sobald mindestens ein Kandidatenpaar (lokal-remote) die Konnektivitätsprüfung besteht, gilt die Verbindung als hergestellt.

• Host candidates — lokale IP-Adresse des Geräts im Subnetz (schnellste, funktioniert aber nicht hinter NAT)
• Server Reflexive candidates — öffentliche IP, die über einen STUN-Server ermittelt wurde
• Relay candidates — TURN-Server-Adresse, über die das Relay erfolgt (langsamste, zuverlässigste)

WebRTC in mobilen Apps

Für die mobile Entwicklung pflegt Google libWebRTC — eine native Bibliothek für Android (AAR) und iOS (XCFramework). Die Bibliothek enthält den gesamten Protokollstapel, Codecs (VP8, VP9, H.264, AV1) und Hardwarebeschleunigung für Kodierung/Dekodierung.

WebRTC auf Android

Das Android SDK bietet die Klassen PeerConnectionFactory, PeerConnection, MediaStream. Die App erstellt eine Factory, konfiguriert Video-Codecs, erfasst den Kamerastream über VideoCapturer und stellt die Peer-Verbindung über SDP Offer/Answer her.

// Android WebRTC — Initialisierung
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC auf iOS

Das iOS SDK verwendet eine Objective-C-API mit Wrappern RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Hardware-H.264-Kodierung ist über VideoToolbox verfügbar. Zur Videoanzeige wird RTCMTLVideoView (Metal) oder RTCVideoRenderer verwendet.

// iOS WebRTC — Videoaufnahme von Kamera
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Kameraauswahl (vorne/hinten)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Aufnahme mit maximaler FPS starten
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Für Produktions-Videoanrufe verwenden mobile Apps normalerweise SDK-Wrapper über libWebRTC: Twilio Video, Agora, Daily.co. Diese SDKs vereinfachen die Signalisierung, Raumverwaltung und bieten vorgefertigte UI-Komponenten zur Anzeige des Teilnehmer-Videorasters.

Signalisierung und Verbindungsaufbau

WebRTC spezifiziert kein Signalisierungsprotokoll — den Austausch von SDP (Session Description Protocol)-Nachrichten zwischen Peers. Der Entwickler wählt den Transport für die Signalisierung: WebSocket, MQTT, SIP, XMPP oder REST API. Die Signalisierung übermittelt Offer, Answer und ICE-Kandidaten von einem Peer zum anderen.

SDP Offer/Answer-Austausch

Der Prozess beginnt mit der Erstellung eines Offer (der Initiator beschreibt seine Medienfähigkeiten), wird über die Signalisierung an den zweiten Peer übermittelt, der mit einem Answer antwortet. Nach dem SDP-Austausch startet jeder Peer ICE und initiiert DTLS-SRTP zur Stromverschlüsselung.

// Android — Erstellen und Senden von Offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Sdp.description an Signalisierungsserver senden
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Signalisierungsprotokolle

Für mobile Apps ist die gängigste Signalisierung über WebSocket — ein bidirektionaler Kanal über TCP, der eine dauerhafte Verbindung zum Server aufrechterhält. Der Signalisierungsserver ist oft ein separater Mikroservice (Node.js, Golang, Elixir), der Nachrichten zwischen Raumteilnehmern weiterleitet.

• WebSocket — dauerhafte bidirektionale Verbindung, minimaler Overhead, Standardwahl für Signalisierung
• SIP über WebSocket — Standard-VoIP-Protokoll, integriert sich in bestehende Telefonieinfrastruktur
• MQTT — leichtes Pub/Sub-Protokoll für IoT und schwache Netzwerke, aber mit höherer Latenz
• Matrix / XMPP — dezentrale Protokolle für datenschutzorientierte Anwendungen

Nach Abschluss von ICE und DTLS-SRTP nimmt die Signalisierung nicht mehr an der Datenübertragung teil — der gesamte Medienverkehr fließt direkt P2P (oder über ein TURN-Relay). Der Signalisierungsserver kann heruntergefahren werden, ohne aktive Anrufe zu unterbrechen. Dies ist der Hauptvorteil der dezentralen Architektur von WebRTC.