Signaling Server: Was es ist, wie es funktioniert und wo es eingesetzt wird

Was ist ein Signaling Server

Signaling Server — ist ein Netzwerkdienst, der für die Koordinierung des Aufbaus einer WebRTC-Verbindung zwischen zwei oder mehr Peers verantwortlich ist. Er überträgt keine Mediendaten (Audio, Video, DataChannel-Daten), sondern nur die Steuerinformationen, die für die Peer-Erkennung und die Aushandlung von Verbindungsparametern erforderlich sind. Nach erfolgreichem Aufbau eines P2P-Kanals wird der Signaling Server möglicherweise nicht mehr benötigt, aber in einigen Architekturen bleibt er für den nachfolgenden Signalaustausch (z. B. Anrufbeendigung, Hinzufügen von Teilnehmern) erhalten.

Die Signalisierungsarchitektur umfasst drei Komponenten: Signaling Server, Signal Channel (Transportprotokoll zwischen Client und Server) und Client-API (normalerweise in den WebRTC-Stack des Browsers integriert). Die WebRTC-Spezifikation (W3C, 2024) standardisiert das Signalisierungsprotokoll bewusst nicht — Entwickler können jedes für ihre Anwendung geeignete Transportmittel wählen. Dieser flexible Ansatz ermöglicht die Verwendung von WebSocket für Webanwendungen, XMPP für Chat-Systeme oder SIP für die Integration mit Telekommunikationsinfrastruktur.

Signalisierungsprozess: Überblick auf hoher Ebene

Vor dem Aufbau einer WebRTC-Verbindung müssen Peers drei Arten von Nachrichten austauschen: Sitzungsbeschreibungen (offer und answer), ICE-Kandidaten und Informationen zur Sitzungsbeendigung/-änderung. Der Signaling Server routet diese Nachrichten zwischen den Peers unter Verwendung von Raum- oder Benutzerkennungen zur Adressierung. Das Standardmuster ist die Erstellung eines „Raums“, in dem sich zwei Teilnehmer verbinden, und der Server leitet Nachrichten von jedem Teilnehmer nur an seinen Gesprächspartner weiter.

Wie Signalisierung in WebRTC funktioniert

Signaling Server implementiert das folgende typische Protokoll zum Aufbau einer WebRTC-Verbindung. Peers verbinden sich über WebSocket (oder ein anderes Transportmittel) mit dem Server und registrieren sich in einem Raum. Peer A (der Initiator) erstellt ein Angebot (SDP-Beschreibung des ausgehenden Medienstreams) über RTCPeerConnection.createOffer(), setzt es als lokale Beschreibung und sendet es an den Signaling Server. Der Server leitet das Angebot an Peer B weiter. Peer B empfängt das Angebot, setzt es als entfernte Beschreibung, erstellt eine Antwort über createAnswer(), setzt sie als lokale Beschreibung und sendet sie über den Server zurück. Dieser Prozess wird als SDP Offer/Answer bezeichnet.

Parallel zum SDP-Austausch sammelt jeder Peer ICE-Kandidaten (host, srflx, relay) und sendet sie über den Signaling Server an den anderen Peer. Der entfernte Peer fügt die empfangenen Kandidaten über RTCPeerConnection.addIceCandidate() hinzu. Der ICE-Prozess testet alle Kombinationen von Kandidaten, um einen funktionierenden Pfad zu finden. Sobald ein funktionierender Pfad gefunden wurde (normalerweise innerhalb von 1–5 Sekunden), beginnt der Medienverkehr direkt zwischen den Peers zu fließen, und der Signaling Server ist nicht mehr an der Datenübertragung beteiligt — seine Rolle ist bis zum nächsten Steuerungsereignis (Anrufbeendigung, Änderung der Stream-Qualität) beendet.

Raummechanismus und Registrierung

Für die Nachrichtenadressierung verwendet der Signaling Server einen Raum- oder Kanalmechanismus. Jede neue WebRTC-Sitzung erstellt einen eindeutigen Raum mit einer Kennung (normalerweise UUID). Der Initiator erstellt den Raum und wartet auf die Verbindung des zweiten Peers. Der zweite Peer tritt dem Raum mit der ID bei, die er über einen externen Kanal (z. B. einen Einladungslink) erhalten hat. Der Server verwaltet eine Karte von Räumen, wobei jede ID einer Liste verbundener Clients entspricht. Wenn die Anzahl der Teilnehmer zwei erreicht, beginnt der Server, Signalisierungsnachrichten zwischen ihnen weiterzuleiten.

WebRTC-Signalisierungsprotokolle

Signaling Server kann verschiedene Transportprotokolle verwenden, jeweils mit eigenen Vor- und Nachteilen. Die Wahl des Protokolls hängt vom Anwendungstyp, den Infrastrukturbeschränkungen und den Kompatibilitätsanforderungen ab. Nachfolgend sind die gängigsten Protokolle und ihre Eigenschaften aufgeführt.

WebSocket ist das beliebteste Protokoll für Signaling Server in Webanwendungen. Es bietet Vollduplex-Kommunikation, die für den asynchronen Austausch von SDP- und ICE-Kandidaten wichtig ist, und wird von allen modernen Browsern nativ über die WebSocket-API unterstützt. Serverseitige WebSocket-Implementierungen sind auf allen gängigen Plattformen (Node.js, Python, Java, Go) verfügbar. Für Anwendungen mit Millionen von Benutzern werden skalierbare WebSocket-Lösungen auf Basis von Redis Pub/Sub oder Kafka zur Synchronisation zwischen Signaling Server-Instanzen verwendet.

Beispielimplementierung eines Signaling Servers

Betrachten wir eine einfache Implementierung eines Signaling Servers in Node.js unter Verwendung der ws-Bibliothek (WebSocket) und des integrierten HTTP-Servers. Der Server unterstützt Benutzerregistrierung, Raumerstellung und Nachrichtenweiterleitung zwischen Teilnehmern.

const WebSocket = require("ws");
const server = new WebSocket.Server({ port: 8080 });
const rooms = new Map();

server.on("connection", (ws) => {
    ws.roomId = null;

    ws.on("message", (data) => {
        const msg = JSON.parse(data);

        switch (msg.type) {
            case "join":
                handleJoin(ws, msg.roomId);
                break;
            case "offer":
            case "answer":
            case "ice-candidate":
                relayToPeer(ws, msg);
                break;
            case "leave":
                handleLeave(ws);
                break;
        }
    });

    ws.on("close", () => handleLeave(ws));
});

function handleJoin(ws, roomId) {
    if (!rooms.has(roomId)) {
        rooms.set(roomId, []);
    }

    const room = rooms.get(roomId);
    room.push(ws);
    ws.roomId = roomId;

    if (room.length === 2) {
        room[0].send(JSON.stringify({ type: "peer-joined" }));
        room[1].send(JSON.stringify({ type: "peer-joined" }));
    }
}

function relayToPeer(sender, msg) {
    const room = rooms.get(sender.roomId);
    if (!room) return;

    room.forEach(peer => {
        if (peer !== sender && peer.readyState === WebSocket.OPEN) {
            peer.send(JSON.stringify(msg));
        }
    });
}

function handleLeave(ws) {
    if (!ws.roomId) return;
    const room = rooms.get(ws.roomId);
    if (!room) return;

    const idx = room.indexOf(ws);
    if (idx !== -1) room.splice(idx, 1);
    if (room.length === 0) rooms.delete(ws.roomId);
}

Dieser Signaling Server implementiert die grundlegende Funktionalität: Verbindung zu einem Raum, Weiterleitung von WebRTC-Nachrichten (offer, answer, ice-candidate) zwischen zwei Peers und Verwaltung von Trennungen. Der Server verwendet eine Map, um Räume mit verbundenen WebSocket-Clients zu speichern. Die Funktion relayToPeer sendet eine Nachricht an alle Teilnehmer des Raums außer dem Absender. Für die Produktion müssen Sie die Validierung von Nachrichtentypen, die Behandlung von JSON-Parsing-Fehlern und einen Heartbeat-Mechanismus zur Erkennung unterbrochener Verbindungen hinzufügen.

Client-Integration mit Signaling Server

Auf der Client-Seite wird der Signaling Server über die WebSocket-API des Browsers integriert. Der Client stellt eine Verbindung zum Server her, sendet eine Anfrage zum Beitritt zu einem Raum und verarbeitet dann eingehende WebRTC-Nachrichten, indem er sie über setRemoteDescription() und addIceCandidate() an die RTCPeerConnection übergibt. Der Client-Code sendet auch seine eigenen SDP- und ICE-Kandidaten an den Server, die er über das onicecandidate-Ereignis und nach der Erstellung von offer/answer von der RTCPeerConnection erhält.

Rolle von SDP und ICE in der Signalisierung

Signaling Server überträgt zwei Hauptarten von Metadaten: SDP (Session Description Protocol) und ICE-Kandidaten. SDP beschreibt die Parameter des Medienstreams — Codecs, Abtastrate, Anzahl der Kanäle, Übertragungsrichtung (sendrecv, sendonly, recvonly, inactive). ICE-Kandidaten enthalten Netzwerkadressen (lokal, von STUN bezogen, Relay von TURN), über die ein Peer für die Verbindung erreichbar ist.

SDP wird in einem Textformat präsentiert, das Sitzungs- und Medienabschnitte enthält. Der Sitzungsteil beschreibt allgemeine Parameter (Sitzungs-ID, Version, Name), während die Medienabschnitte jeden Medienstream (Audio, Video, DataChannel) mit seinem Codec, Port und Protokoll beschreiben. ICE-Kandidaten enthalten Foundation (Gruppierungskennung), Priorität, IP-Adresse, Port, Typ (host, srflx, relay) und Protokoll (UDP, TCP). Jeder Kandidat enthält auch ein ufrag-Attribut (Benutzernamenfragment), das ihn mit einem bestimmten ICE-Prozess verbindet.

• SDP Offer — Der Initiator erstellt eine Beschreibung seiner Medienfähigkeiten und sendet sie über den Signaling Server an den entfernten Peer.
• SDP Answer — Der entfernte Peer antwortet mit seiner eigenen Beschreibung und bestätigt oder passt Medienformate und Codecs an.
• ICE Candidate — Jeder Peer sendet seine Netzwerkkandidaten an den Signalisierungsserver, sobald sie vom ICE-Framework entdeckt werden.
• Trickle ICE — Eine moderne Optimierung, bei der Kandidaten einzeln gesendet werden, sobald sie entdeckt werden, anstatt alle auf einmal nach Abschluss der Sammlung.
• Neuverhandlung — Wenn sich Medienparameter ändern (Video aktivieren/deaktivieren, Teilnehmer hinzufügen), initiieren die Peers einen neuen SDP-Austausch über den Signaling Server.

Trickle ICE beschleunigt den WebRTC-Verbindungsaufbau erheblich. Anstatt auf die vollständige Sammlung aller ICE-Kandidaten zu warten (was in komplexen Netzwerken 2–10 Sekunden dauern kann), wird jeder Kandidat sofort nach der Entdeckung an den Signaling Server gesendet. Der entfernte Peer empfängt den Kandidaten und beginnt sofort mit dem Verbindungstest über das ICE-Framework. Dies reduziert die Verbindungsaufbauzeit in den meisten Fällen auf 500–1500 ms.