Signaling Server: ano ito, paano ito gumagana at saan ginagamit

Ano ang Signaling Server

Signaling Server — ay isang network service na responsable para sa pag-coordinate ng proseso ng pag-set up ng WebRTC connection sa pagitan ng dalawa o higit pang peer. Hindi ito nagpapadala ng media data (audio, video, DataChannel data), kundi impormasyon lamang na kinakailangan para sa pagtuklas ng mga peer at pagsang-ayon sa mga parameter ng koneksyon. Pagkatapos ng matagumpay na pag-set up ng P2P channel, maaaring hindi na kailangan ang Signaling Server, ngunit sa ilang arkitektura nananatili ito para sa susunod na pagpapalitan ng signal (halimbawa, pagtatapos ng tawag, pagdagdag ng mga kalahok).

Ang arkitektura ng signaling ay may tatlong bahagi: Signaling Server, Signal Channel (transport protocol sa pagitan ng client at server) at client API (karaniwang naka-embed sa WebRTC stack ng browser). Ang WebRTC specification (W3C, 2024) ay sadyang hindi nag-standardize ng signaling protocol — ang mga developer ay maaaring pumili ng anumang transport na angkop para sa kanilang application. Ang nababaluktot na solusyong ito ay nagpapahintulot sa paggamit ng WebSocket para sa web applications, XMPP para sa chat systems o SIP para sa integration sa telecommunication infrastructure.

Proseso ng signaling: mataas na antas

Bago mag-set up ng WebRTC connection, ang mga peer ay dapat magpalitan ng tatlong uri ng mensahe: session description (offer at answer), ICE candidates at impormasyon tungkol sa pagtatapos/pagbabago ng session. Ang Signaling Server ay nagruruta ng mga mensaheng ito sa pagitan ng mga peer, gamit ang mga room o user identifier para sa pag-address. Ang karaniwang pattern — paggawa ng “room” kung saan kumokonekta ang dalawang kalahok, at ang server ay nagrerelay ng mga mensahe mula sa bawat kalahok sa kanyang kausap lamang.

Paano gumagana ang signaling sa WebRTC

Signaling Server ay nag-iimplementa ng sumusunod na tipikal na protocol ng pag-set up ng WebRTC connection. Ang mga peer ay kumokonekta sa server sa pamamagitan ng WebSocket (o ibang transport) at nagrerehistro sa isang room. Peer A (ang initiator) ay gumagawa ng offer (SDP description ng papalabas na media stream) sa pamamagitan ng RTCPeerConnection.createOffer(), itinatakda ito bilang local description at ipinapadala sa Signaling Server. Ang server ay nagre-relay ng offer sa peer B. Peer B ay tumatanggap ng offer, itinatakda ito bilang remote description, gumagawa ng answer sa pamamagitan ng createAnswer(), itinatakda ito bilang local description at ipinapadala pabalik sa pamamagitan ng server. Ang prosesong ito ay tinatawag na SDP Offer/Answer.

Kaakibat ng pagpapalitan ng SDP, ang bawat peer ay nangongolekta ng ICE candidates (host, srflx, relay) at ipinapadala ang mga ito sa pamamagitan ng Signaling Server sa kabilang peer. Ang remote peer ay nagdaragdag ng mga natanggap na kandidato sa pamamagitan ng RTCPeerConnection.addIceCandidate(). Ang ICE process ay sumusuri sa lahat ng kumbinasyon ng mga kandidato upang makahanap ng gumaganang daanan. Pagkatapos mahanap ang gumaganang daanan (karaniwan sa loob ng 1–5 segundo), ang media traffic ay nagsisimulang maipadala nang direkta sa pagitan ng mga peer, at ang Signaling Server ay hindi na nakikilahok sa pagpapadala ng data — ang papel nito ay tapos na hanggang sa susunod na service event (pagtatapos ng tawag, pagbabago ng kalidad ng stream).

Mekanismo ng room at pagrerehistro

Para sa pag-address ng mga mensahe, ang Signaling Server ay gumagamit ng mekanismo ng mga room o channel. Ang bawat bagong WebRTC session ay gumagawa ng natatanging room na may identifier (karaniwang UUID). Ang initiator ay gumagawa ng room at naghihintay ng koneksyon ng ikalawang peer. Ang ikalawang peer ay kumokonekta sa room sa pamamagitan ng ID na nakuha sa pamamagitan ng external channel (halimbawa, isang invitation link). Ang server ay nagpapanatili ng mapa ng mga room, kung saan ang bawat ID ay tumutugma sa isang listahan ng mga konektadong client. Kapag ang bilang ng mga kalahok ay umabot sa dalawa, ang server ay nagsisimulang mag-relay ng mga signaling message sa pagitan nila.

Mga protocol ng signaling WebRTC

Signaling Server ay maaaring gumamit ng iba't ibang transport protocols, bawat isa ay may kanya-kanyang mga pakinabang at disadvantages. Ang pagpili ng protocol ay depende sa uri ng application, mga limitasyon sa infrastructure at mga kinakailangan sa compatibility. Sa ibaba ay ang mga pinakakaraniwang protocol at ang kanilang mga katangian.

WebSocket ay ang pinakasikat na protocol para sa Signaling Server sa web applications. Ito ay nagbibigay ng full-duplex na komunikasyon, na mahalaga para sa asynchronous na pagpapalitan ng SDP at ICE candidates, at native na sinusuportahan ng lahat ng modernong browser sa pamamagitan ng WebSocket API. Ang server implementation ng WebSocket ay available sa lahat ng sikat na platform (Node.js, Python, Java, Go). Para sa mga application na may milyun-milyong user, ginagamit ang scalable WebSocket solutions batay sa Redis Pub/Sub o Kafka para sa synchronization sa pagitan ng Signaling Server instances.

Halimbawa ng implementasyon ng Signaling Server

Tingnan natin ang simpleng implementasyon ng Signaling Server sa Node.js gamit ang ws library (WebSocket) at built-in na HTTP server. Ang server ay sumusuporta sa pagrerehistro ng user, paggawa ng mga room at pag-relay ng mga mensahe sa pagitan ng mga kalahok.

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

Ang Signaling Server na ito ay nag-iimplementa ng pangunahing functionality: pagkonekta sa room, pag-relay ng WebRTC messages (offer, answer, ice-candidate) sa pagitan ng dalawang peer at pamamahala ng mga pagdiskonekta. Ang server ay gumagamit ng Map para sa pag-imbak ng mga room na may konektadong WebSocket clients. Ang function na relayToPeer ay nagpapadala ng mensahe sa lahat ng kalahok sa room maliban sa nagpadala. Para sa produksyon, kailangan magdagdag ng kumpirmasyon ng mga uri ng mensahe, paghawak ng JSON parsing errors at heartbeat mechanism para sa pagtuklas ng mga putol na koneksyon.

Integration ng client sa Signaling Server

Sa panig ng client, ang Signaling Server ay nai-integrate sa pamamagitan ng WebSocket API ng browser. Ang client ay nagtatag ng koneksyon sa server, nagpapadala ng kahilingan na sumali sa room, at pagkatapos ay nagproseso ng mga papasok na WebRTC message, na ipinapasa ang mga ito sa RTCPeerConnection sa pamamagitan ng setRemoteDescription() at addIceCandidate(). Ang client code ay nagpapadala rin ng sarili nitong SDP at ICE candidates sa server, na nakuha mula sa RTCPeerConnection sa pamamagitan ng mga event na onicecandidate at pagkatapos gumawa ng offer/answer.

Papel ng SDP at ICE sa signaling

Signaling Server ay nagpapadala ng dalawang pangunahing uri ng metadata: SDP (Session Description Protocol) at ICE candidates. Ang SDP ay naglalarawan ng mga parameter ng media stream — mga codec, sampling frequency, bilang ng channel, direksyon ng transmission (sendrecv, sendonly, recvonly, inactive). Ang ICE candidates ay naglalaman ng mga network address (lokal, nakuha mula sa STUN, relay mula sa TURN) kung saan ang isang peer ay maaaring maabot para sa koneksyon.

Ang SDP ay ipinapakita sa text format na naglalaman ng mga session at media sections. Ang session part ay naglalarawan ng mga pangkalahatang parameter (session identifier, version, pangalan), ang media sections — bawat media stream (audio, video, DataChannel) kasama ang codec, port at protocol nito. ICE candidates ay naglalaman ng foundation (identifier para sa pag-grupo), priority, IP address, port, type (host, srflx, relay) at protocol (UDP, TCP). Ang bawat candidate ay naglalaman din ng attribute na ufrag (username fragment) na nag-uugnay nito sa isang tiyak na ICE process.

• SDP Offer — ang initiator ay gumagawa ng paglalarawan ng kanyang media capabilities at ipinapadala ito sa remote peer sa pamamagitan ng Signaling Server.
• SDP Answer — ang remote peer ay tumutugon gamit ang sarili nitong paglalarawan, kinukumpirma o itinatama ang mga media format at codec.
• ICE Candidate — bawat peer ay nagpapadala ng sarili nitong network candidates sa signaling server habang natutuklasan ng ICE framework.
• Trickle ICE — isang modernong optimization kung saan ang mga kandidato ay ipinapadala nang paisa-isa habang natutuklasan, hindi lahat nang sabay-sabay pagkatapos ng koleksyon.
• Re-negotiation — kapag nagbago ang mga media parameter (pag-on/off ng video, pagdagdag ng kalahok), ang mga peer ay nag-uumpisa ng paulit-ulit na SDP exchange sa pamamagitan ng Signaling Server.

Trickle ICE ay makabuluhang nagpapabilis ng pag-set up ng WebRTC connection. Sa halip na maghintay para sa buong koleksyon ng lahat ng ICE candidates (na maaaring tumagal ng 2–10 segundo sa komplikadong network), ang bawat kandidato ay ipinapadala sa Signaling Server kaagad pagkatapos matuklasan. Ang remote peer ay tumatanggap ng kandidato at agad na nagsisimulang suriin ang koneksyon sa pamamagitan ng ICE framework. Ito ay nagbabawas ng oras ng pag-set up ng koneksyon sa 500–1500 ms sa karamihan ng mga kaso.