Signaling Server: co to je, jak funguje a kde se používá

Co je Signaling Server

Signaling Server — je síťová služba odpovědná za koordinaci procesu navazování WebRTC spojení mezi dvěma nebo více peery. Nepřenáší mediální data (audio, video, data kanálu DataChannel), ale pouze servisní informace nezbytné pro objevování peerů a dohodu na parametrech spojení. Po úspěšném navázání P2P kanálu již Signaling Server nemusí být potřeba, ale v některých architekturách zůstává pro pozdější výměnu signálů (např. ukončení hovoru, přidání účastníků).

Architektura signalizace zahrnuje tři komponenty: Signaling Server, Signal Channel (transportní protokol mezi klientem a serverem) a klientské API (obvykle vestavěné do WebRTC zásobníku prohlížeče). Specifikace WebRTC (W3C, 2024) záměrně nestandardizuje signalizační protokol — vývojáři si mohou vybrat jakýkoli transport vhodný pro jejich aplikaci. Toto flexibilní řešení umožňuje použít WebSocket pro webové aplikace, XMPP pro chatovací systémy nebo SIP pro integraci s telekomunikační infrastrukturou.

Proces signalizace: vysoká úroveň

Před navázáním WebRTC spojení si musí peery vyměnit tři typy zpráv: session description (offer a answer), ICE candidates a informace o ukončení/změně relace. Signaling Server tyto zprávy směruje mezi peery pomocí identifikátorů místností nebo uživatelů pro adresaci. Standardní vzor — vytvoření „místnosti“, do které se připojí dva účastníci, a server přeposílá zprávy od každého účastníka pouze jeho partnerovi.

Jak funguje signalizace ve WebRTC

Signaling Server implementuje následující typický protokol navazování WebRTC spojení. Peery se připojí k serveru přes WebSocket (nebo jiný transport) a zaregistrují se v místnosti. Peer A (iniciátor) vytvoří offer (SDP popis odchozího mediálního toku) přes RTCPeerConnection.createOffer(), nastaví jej jako local description a odešle na Signaling Server. Server přepošle offer peeru B. Peer B obdrží offer, nastaví jej jako remote description, vytvoří answer přes createAnswer(), nastaví jej jako local description a odešle zpět přes server. Tento proces se nazývá SDP Offer/Answer.

Současně s výměnou SDP každý peer shromažďuje ICE candidates (host, srflx, relay) a odesílá je přes Signaling Server druhému peeru. Vzdálený peer přidá obdržené kandidáty přes RTCPeerConnection.addIceCandidate(). Proces ICE kontroluje všechny kombinace kandidátů, aby našel fungující cestu. Po nalezení fungující cesty (obvykle během 1–5 sekund) začne mediální provoz proudit přímo mezi peery a Signaling Server se již neúčastní přenosu dat — jeho role končí do další servisní události (ukončení hovoru, změna kvality toku).

Mechanismus místností a registrace

Pro adresaci zpráv používá Signaling Server mechanismus místností (rooms) nebo kanálů. Každá nová WebRTC relace vytváří jedinečnou místnost s identifikátorem (obvykle UUID). Iniciátor vytvoří místnost a čeká na připojení druhého peeru. Druhý peer se připojí k místnosti pomocí ID získaného externím kanálem (např. odkazem na pozvánku). Server udržuje mapu místností, kde každému ID odpovídá seznam připojených klientů. Když počet účastníků dosáhne dvou, server začne přeposílat signalizační zprávy mezi nimi.

Protokoly signalizace WebRTC

Signaling Server může používat různé transportní protokoly, z nichž každý má své výhody a nevýhody. Výběr protokolu závisí na typu aplikace, infrastrukturních omezeních a požadavcích na kompatibilitu. Níže jsou uvedeny nejběžnější protokoly a jejich charakteristiky.

WebSocket je nejoblíbenějším protokolem pro Signaling Server ve webových aplikacích. Poskytuje plně duplexní komunikaci, důležitou pro asynchronní výměnu SDP a ICE kandidátů, a je nativně podporován všemi moderními prohlížeči přes WebSocket API. Serverová implementace WebSocket je dostupná na všech populárních platformách (Node.js, Python, Java, Go). Pro aplikace s miliony uživatelů se používají škálovatelná WebSocket řešení založená na Redis Pub/Sub nebo Kafka pro synchronizaci mezi instancemi Signaling Server.

Příklad implementace Signaling Server

Podívejme se na jednoduchou implementaci Signaling Server v Node.js s použitím knihovny ws (WebSocket) a vestavěného HTTP serveru. Server podporuje registraci uživatelů, vytváření místností a přeposílání zpráv mezi účastníky.

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);
}

Tento Signaling Server implementuje základní funkcionalitu: připojení k místnosti, přeposílání WebRTC zpráv (offer, answer, ice-candidate) mezi dvěma peery a správu odpojení. Server používá Map pro ukládání místností s připojenými WebSocket klienty. Funkce relayToPeer odesílá zprávu všem účastníkům místnosti kromě odesílatele. Pro produkci je třeba přidat potvrzení typů zpráv, zpracování chyb parsování JSON a mechanismus heartbeat pro detekci přerušených spojení.

Klientská integrace se Signaling Server

Na straně klienta se Signaling Server integruje přes WebSocket API prohlížeče. Klient naváže spojení se serverem, odešle požadavek na připojení k místnosti a poté zpracovává příchozí WebRTC zprávy, předávajíc je do RTCPeerConnection přes setRemoteDescription() a addIceCandidate(). Klientský kód také odesílá na server své SDP a ICE kandidáty získané z RTCPeerConnection přes události onicecandidate a po vytvoření offer/answer.

Role SDP a ICE v signalizaci

Signaling Server přenáší dva klíčové typy metadat: SDP (Session Description Protocol) a ICE candidates. SDP popisuje parametry mediálního toku — kodeky, vzorkovací frekvenci, počet kanálů, směr přenosu (sendrecv, sendonly, recvonly, inactive). ICE candidates obsahují síťové adresy (lokální, získané ze STUN, relay z TURN), na kterých může být peer dosažitelný pro spojení.

SDP je prezentováno v textovém formátu obsahujícím relace a mediální sekce. Část relace popisuje obecné parametry (identifikátor relace, verze, název), mediální sekce — každý mediální tok (audio, video, DataChannel) s jeho kodekem, portem a protokolem. ICE kandidáti obsahují foundation (identifikátor pro seskupování), priority, IP adresu, port, typ (host, srflx, relay) a protokol (UDP, TCP). Každý kandidát také obsahuje atribut ufrag (username fragment), který jej spojuje s konkrétním ICE procesem.

• SDP Offer — iniciátor vytvoří popis svých mediálních schopností a odešle jej vzdálenému peeru přes Signaling Server.
• SDP Answer — vzdálený peer odpoví svým popisem, potvrzujíc nebo korigujíc mediální formáty a kodeky.
• ICE Candidate — každý peer odesílá signalizačnímu serveru své síťové kandidáty, jak jsou objevovány frameworkem ICE.
• Trickle ICE — moderní optimalizace, při které jsou kandidáti odesíláni jeden po druhém, jak jsou objevováni, ne všichni najednou po dokončení sběru.
• Re-negotiation — při změně mediálních parametrů (zapnutí/vypnutí videa, přidání účastníka) iniciují peery opakovanou výměnu SDP přes Signaling Server.

Trickle ICE výrazně urychluje navazování WebRTC spojení. Místo čekání na úplný sběr všech ICE kandidátů (což může ve složitých sítích trvat 2–10 sekund) je každý kandidát odeslán na Signaling Server ihned po objevení. Vzdálený peer obdrží kandidáta a okamžitě zahájí kontrolu spojení přes framework ICE. To zkracuje dobu navazování spojení na 500–1500 ms ve většině případů.