Signaling Server: ce este, cum funcționează și unde se utilizează

Ce este Signaling Server

Signaling Server — este un serviciu de rețea responsabil pentru coordonarea procesului de stabilire a conexiunii WebRTC între doi sau mai mulți peeri. Acesta nu transmite date media (audio, video, datele canalului DataChannel), ci doar informații de serviciu necesare pentru descoperirea peerilor și negocierea parametrilor conexiunii. După stabilirea cu succes a canalului P2P, Signaling Server poate să nu mai fie necesar, dar în unele arhitecturi rămâne pentru schimbul ulterior de semnale (de exemplu, terminarea apelului, adăugarea participanților).

Arhitectura semnalizării include trei componente: Signaling Server, Signal Channel (protocolul de transport între client și server) și API client (de obicei încorporat în stiva WebRTC a browserului). Specificația WebRTC (W3C, 2024) nu standardizează intenționat protocolul de semnalizare — dezvoltatorii pot alege orice transport potrivit pentru aplicația lor. Această soluție flexibilă permite utilizarea WebSocket pentru aplicații web, XMPP pentru sisteme de chat sau SIP pentru integrarea cu infrastructura de telecomunicații.

Procesul de semnalizare: nivel înalt

Înainte de stabilirea conexiunii WebRTC, peerii trebuie să facă schimb de trei tipuri de mesaje: session description (offer și answer), ICE candidates și informații despre terminarea/modificarea sesiunii. Signaling Server rută aceste mesaje între peeri, folosind identificatori de camere sau utilizatori pentru adresare. Modelul standard — crearea unei „camere” la care se conectează doi participanți, iar serverul retransmite mesajele de la fiecare participant doar interlocutorului său.

Cum funcționează semnalizarea în WebRTC

Signaling Server implementează următorul protocol tipic de stabilire a conexiunii WebRTC. Peerii se conectează la server prin WebSocket (sau alt transport) și se înregistrează într-o cameră. Peerul A (inițiatorul) creează un offer (descrierea SDP a fluxului media de ieșire) prin RTCPeerConnection.createOffer(), îl setează ca local description și îl trimite la Signaling Server. Serverul retransmite offer-ul peerului B. Peerul B primește offer-ul, îl setează ca remote description, creează un answer prin createAnswer(), îl setează ca local description și îl trimite înapoi prin server. Acest proces se numește SDP Offer/Answer.

Paralel cu schimbul de SDP, fiecare peer colectează ICE candidates (host, srflx, relay) și le trimite prin Signaling Server celuilalt peer. Peerul la distanță adaugă candidații primiți prin RTCPeerConnection.addIceCandidate(). Procesul ICE verifică toate combinațiile de candidați pentru a găsi o cale funcțională. După găsirea unei căi funcționale (de obicei în 1–5 secunde), traficul media începe să fie transmis direct între peeri, iar Signaling Server nu mai participă la transmiterea datelor — rolul său se încheie până la următorul eveniment de serviciu (terminarea apelului, modificarea calității fluxului).

Mecanismul camerelor și înregistrarea

Pentru adresarea mesajelor, Signaling Server folosește mecanismul camerelor (rooms) sau canalelor. Fiecare sesiune WebRTC nouă creează o cameră unică cu un identificator (de obicei UUID). Inițiatorul creează camera și așteaptă conectarea celui de-al doilea peer. Al doilea peer se conectează la cameră prin ID-ul primit printr-un canal extern (de exemplu, un link de invitație). Serverul menține o hartă a camerelor, unde fiecărui ID îi corespunde o listă de clienți conectați. Când numărul participanților ajunge la doi, serverul începe să retransmită mesajele de semnalizare între ei.

Protocoalele de semnalizare WebRTC

Signaling Server poate utiliza diferite protocoale de transport, fiecare având avantajele și dezavantajele sale. Alegerea protocolului depinde de tipul aplicației, constrângerile de infrastructură și cerințele de compatibilitate. Mai jos sunt prezentate cele mai comune protocoale și caracteristicile lor.

WebSocket este cel mai popular protocol pentru Signaling Server în aplicațiile web. Acesta asigură comunicare full-duplex, importantă pentru schimbul asincron de SDP și ICE candidați, și este suportat nativ de toate browserele moderne prin WebSocket API. Implementarea server WebSocket este disponibilă pe toate platformele populare (Node.js, Python, Java, Go). Pentru aplicațiile cu milioane de utilizatori, se utilizează soluții WebSocket scalabile bazate pe Redis Pub/Sub sau Kafka pentru sincronizarea între instanțele Signaling Server.

Exemplu de implementare Signaling Server

Să examinăm o implementare simplă a Signaling Server în Node.js folosind biblioteca ws (WebSocket) și serverul HTTP încorporat. Serverul suportă înregistrarea utilizatorilor, crearea camerelor și retransmiterea mesajelor între participanți.

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

Acest Signaling Server implementează funcționalitatea de bază: conectarea la cameră, retransmiterea mesajelor WebRTC (offer, answer, ice-candidate) între doi peeri și gestionarea deconectărilor. Serverul folosește Map pentru stocarea camerelor cu clienți WebSocket conectați. Funcția relayToPeer trimite mesajul tuturor participanților din cameră, cu excepția expeditorului. Pentru producție, este necesară adăugarea confirmării tipurilor de mesaje, gestionarea erorilor de parsare JSON și un mecanism heartbeat pentru detectarea conexiunilor întrerupte.

Integrarea client cu Signaling Server

Pe partea client, Signaling Server se integrează prin WebSocket API al browserului. Clientul stabilește conexiunea cu serverul, trimite o cerere de alăturare la cameră, apoi procesează mesajele WebRTC primite, transmițându-le către RTCPeerConnection prin setRemoteDescription() și addIceCandidate(). Codul client trimite, de asemenea, propriile SDP și ICE candidați către server, primite de la RTCPeerConnection prin evenimentele onicecandidate și după crearea offer/answer.

Rolul SDP și ICE în semnalizare

Signaling Server transmite două tipuri cheie de metadate: SDP (Session Description Protocol) și ICE candidates. SDP descrie parametrii fluxului media — codecuri, frecvența de eșantionare, numărul de canale, direcția de transmisie (sendrecv, sendonly, recvonly, inactive). ICE candidates conțin adrese de rețea (locale, obținute de la STUN, releu de la TURN) la care peerul poate fi accesibil pentru conexiune.

SDP este prezentat în format text care conține sesiuni și secțiuni media. Partea de sesiune descrie parametrii generali (identificatorul sesiunii, versiunea, numele), secțiunile media — fiecare flux media (audio, video, DataChannel) cu codecul, portul și protocolul său. Candidații ICE conțin foundation (identificator pentru grupare), priority, adresa IP, portul, tipul (host, srflx, relay) și protocolul (UDP, TCP). Fiecare candidate include, de asemenea, atributul ufrag (username fragment), care îl leagă de un proces ICE specific.

• SDP Offer — inițiatorul creează o descriere a capacităților sale media și o trimite peerului la distanță prin Signaling Server.
• SDP Answer — peerul la distanță răspunde cu propria descriere, confirmând sau corectând formatele media și codecurile.
• ICE Candidate — fiecare peer trimite serverului de semnalizare propriii candidați de rețea pe măsură ce sunt descoperiți de framework-ul ICE.
• Trickle ICE — o optimizare modernă în care candidații sunt trimiși unul câte unul pe măsură ce sunt descoperiți, nu toți odată după finalizarea colectării.
• Re-negotiation — la modificarea parametrilor media (activarea/dezactivarea video, adăugarea unui participant), peerii inițiază un schimb repetat de SDP prin Signaling Server.

Trickle ICE accelerează semnificativ stabilirea conexiunii WebRTC. În loc să aștepte colectarea completă a tuturor candidaților ICE (ceea ce poate dura 2–10 secunde în rețele complexe), fiecare candidat este trimis la Signaling Server imediat după descoperire. Peerul la distanță primește candidatul și începe imediat verificarea conexiunii prin framework-ul ICE. Aceasta reduce timpul de stabilire a conexiunii la 500–1500 ms în majoritatea cazurilor.