Signaling (Signalgebung) ist im WebRTC-Kontext der Austausch von Steuerinformationen zwischen zwei Peers, bevor und während Medien direkt übertragen werden. WebRTC legt bewusst kein eigenes Signalisierungsprotokoll fest – Entwickler wählen den Transport selbst, üblich sind WebSocket, SIP, XMPP oder eine eigene Server-API. Das Signaling übernimmt drei Aufgaben: Peers einander bekannt machen, SDP-Angebote und -Antworten austauschen und ICE-Kandidaten weiterleiten.
Der Ablauf eines Verbindungsaufbaus
Typischerweise läuft das Signaling nach dem Angebot-Antwort-Muster (Offer/Answer) ab:
- Peer A erzeugt über die Browser-API ein Angebot (createOffer) und sendet die resultierende SDP-Beschreibung an einen Signaling-Server.
- Der Server leitet das Angebot an Peer B weiter (Relais-Funktion, kein Medien-Relais).
- Peer B antwortet mit einer eigenen SDP-Beschreibung (Answer), die zurück zu Peer A wandert.
- Beide Peers tauschen zusätzlich ICE-Kandidaten aus (Trickle ICE, RFC 8838), damit der beste Transportpfad gefunden wird – unterstützt durch ICE mit STUN und TURN.
Der Signaling-Kanal bleibt auch nach dem Verbindungsaufbau offen: Er dient der Neuverhandlung (Re-Negotiation), wenn sich Medien ändern, und dem kontrollierten Beenden der Sitzung. Über denselben Kanal kündigt ein Peer an, dass er Simulcast unterstützt oder eine neue Medien-Spur hinzufügen möchte.
Signaling-Server und Alternativen
Ein Signaling-Server ist oft ein einfacher WebSocket-Server, der Nachrichten zwischen verbundenen Clients weiterreicht – die Mediendaten fließen danach direkt zwischen den Peers (P2P) oder über einen SFU/Selective Forwarding Unit. In SIP-Umgebungen wird Signaling über SIP mit WebSocket-Transport (RFC 7118) realisiert; XMPP nutzt das Jingle-Protokoll. Entscheidend ist: Signaling ist kein Medienpfad, sondern nur der Steuerkanal für den Verbindungsaufbau.