Signaling Server: vad är det, hur fungerar det och var används det

Vad är Signaling Server

Signaling Server — är en nätverkstjänst som ansvarar för att samordna processen att upprätta en WebRTC-anslutning mellan två eller flera peers. Den överför inte mediadata (ljud, video, DataChannel-data) utan endast tjänsteinformation som behövs för att upptäcka peers och förhandla om anslutningsparametrar. Efter att P2P-kanalen framgångsrikt upprättats kan Signaling Server inte längre behövas, men i vissa arkitekturer kvarstår den för efterföljande signalutbyte (till exempel avsluta samtal, lägga till deltagare).

Signaleringsarkitekturen omfattar tre komponenter: Signaling Server, Signal Channel (transportprotokoll mellan klient och server) och klient-API (vanligtvis inbäddat i webbläsarens WebRTC-stack). WebRTC-specifikationen (W3C, 2024) standardiserar avsiktligt inte signaleringsprotokollet — utvecklare kan välja vilken transport som helst som passar deras applikation. Denna flexibla lösning gör det möjligt att använda WebSocket för webbapplikationer, XMPP för chatt-system eller SIP för integration med telekommunikationsinfrastruktur.

Signaleringsprocess: hög nivå

Innan WebRTC-anslutningen upprättas måste peers utbyta tre typer av meddelanden: session description (offer och answer), ICE candidates och information om avslutning/ändring av sessionen. Signaling Server dirigerar dessa meddelanden mellan peers med hjälp av rums- eller användaridentifikatorer för adressering. Standardmönstret — att skapa ett “rum” som två deltagare ansluter till, och servern vidarebefordrar meddelanden från varje deltagare endast till dess samtalspartner.

Hur signalering fungerar i WebRTC

Signaling Server implementerar följande typiska protokoll för att upprätta en WebRTC-anslutning. Peers ansluter till servern via WebSocket (eller annan transport) och registrerar sig i ett rum. Peer A (initiativtagaren) skapar ett offer (SDP-beskrivning av den utgående mediaströmmen) via RTCPeerConnection.createOffer(), anger det som local description och skickar det till Signaling Server. Servern vidarebefordrar offert till peer B. Peer B tar emot offert, anger det som remote description, skapar ett answer via createAnswer(), anger det som local description och skickar tillbaka det via servern. Denna process kallas SDP Offer/Answer.

Parallellt med SDP-utbytet samlar varje peer in ICE candidates (host, srflx, relay) och skickar dem via Signaling Server till den andra peern. Den fjärranslutna peern lägger till de mottagna kandidaterna via RTCPeerConnection.addIceCandidate(). ICE-processen kontrollerar alla kombinationer av kandidater för att hitta en fungerande väg. När en fungerande väg har hittats (vanligtvis inom 1–5 sekunder) börjar mediatrafik överföras direkt mellan peers, och Signaling Server deltar inte längre i dataöverföringen — dess roll är avslutad fram till nästa tjänstehändelse (avsluta samtal, ändra strömkvalitet).

Rumsmekanism och registrering

För adressering av meddelanden använder Signaling Server en mekanism med rum (rooms) eller kanaler. Varje ny WebRTC-session skapar ett unikt rum med en identifierare (vanligtvis UUID). Initiativtagaren skapar rummet och väntar på att den andra peern ska ansluta. Den andra peern ansluter till rummet via ett ID som erhållits via en extern kanal (till exempel en inbjudningslänk). Servern upprätthåller en karta över rum där varje ID motsvarar en lista över anslutna klienter. När antalet deltagare når två börjar servern att vidarebefordra signaleringsmeddelanden mellan dem.

WebRTC-signaleringsprotokoll

Signaling Server kan använda olika transportprotokoll, var och en med sina egna fördelar och nackdelar. Valet av protokoll beror på applikationstyp, infrastrukturbegränsningar och kompatibilitetskrav. Nedan visas de vanligaste protokollen och deras egenskaper.

WebSocket är det mest populära protokollet för Signaling Server i webbapplikationer. Det ger full duplex-kommunikation, vilket är viktigt för asynkront utbyte av SDP- och ICE-kandidater, och stöds inbyggt av alla moderna webbläsare via WebSocket API. Serverimplementeringen av WebSocket finns på alla populära plattformar (Node.js, Python, Java, Go). För applikationer med miljontals användare används skalbara WebSocket-lösningar baserade på Redis Pub/Sub eller Kafka för synkronisering mellan Signaling Server-instanser.

Exempel på Signaling Server-implementering

Låt oss titta på en enkel implementering av Signaling Server i Node.js med hjälp av ws-biblioteket (WebSocket) och den inbyggda HTTP-servern. Servern stöder användarregistrering, skapande av rum och vidarebefordran av meddelanden mellan deltagare.

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

Denna Signaling Server implementerar grundläggande funktionalitet: anslutning till rum, vidarebefordran av WebRTC-meddelanden (offer, answer, ice-candidate) mellan två peers och hantering av frånkopplingar. Servern använder Map för att lagra rum med anslutna WebSocket-klienter. Funktionen relayToPeer skickar meddelandet till alla deltagare i rummet utom avsändaren. För produktion krävs tillägg av bekräftelse av meddelandetyper, hantering av JSON-parsningsfel och en heartbeat-mekanism för att upptäcka brutna anslutningar.

Klientintegration med Signaling Server

På klientsidan integreras Signaling Server via webbläsarens WebSocket API. Klienten upprättar en anslutning till servern, skickar en begäran om att ansluta till ett rum och bearbetar sedan inkommande WebRTC-meddelanden genom att vidarebefordra dem till RTCPeerConnection via setRemoteDescription() och addIceCandidate(). Klientkoden skickar också sina egna SDP- och ICE-kandidater till servern, erhållna från RTCPeerConnection via händelser onicecandidate och efter att offer/answer har skapats.

Roll av SDP och ICE i signalering

Signaling Server överför två viktiga typer av metadata: SDP (Session Description Protocol) och ICE candidates. SDP beskriver parametrarna för mediaströmmen — codecs, samplingsfrekvens, antal kanaler, överföringsriktning (sendrecv, sendonly, recvonly, inactive). ICE candidates innehåller nätverksadresser (lokala, erhållna från STUN, relay från TURN) där en peer kan nås för anslutning.

SDP presenteras i textformat som innehåller sessioner och mediasektioner. Sessionsdelen beskriver allmänna parametrar (session-ID, version, namn), mediasektionerna — varje mediaström (ljud, video, DataChannel) med dess codec, port och protokoll. ICE-kandidater innehåller foundation (identifierare för gruppering), priority, IP-adress, port, typ (host, srflx, relay) och protokoll (UDP, TCP). Varje kandidat innehåller också attributet ufrag (username fragment) som kopplar det till en specifik ICE-process.

• SDP Offer — initiativtagaren skapar en beskrivning av sina mediaförmågor och skickar den till den fjärranslutna peern via Signaling Server.
• SDP Answer — den fjärranslutna peern svarar med sin egen beskrivning, vilket bekräftar eller korrigerar mediaformat och codecs.
• ICE Candidate — varje peer skickar sina nätverkskandidater till signaleringsservern när de upptäcks av ICE-ramverket.
• Trickle ICE — en modern optimering där kandidater skickas en i taget när de upptäcks, inte alla på en gång efter insamlingen är klar.
• Re-negotiation — när mediaparametrar ändras (sätta på/stänga av video, lägga till deltagare) initierar peers ett upprepat SDP-utbyte via Signaling Server.

Trickle ICE påskyndar avsevärt upprättandet av WebRTC-anslutningen. Istället för att vänta på fullständig insamling av alla ICE-kandidater (vilket kan ta 2–10 sekunder i komplexa nätverk) skickas varje kandidat till Signaling Server omedelbart efter upptäckt. Den fjärranslutna peern tar emot kandidaten och börjar omedelbart testa anslutningen via ICE-ramverket. Detta minskar anslutningstiden till 500–1500 ms i de flesta fall.