Signaling Server: यह क्या है, कैसे काम करता है और कहां उपयोग होता है

Signaling Server क्या है

Signaling Server — एक नेटवर्क सेवा है जो दो या अधिक पीयर्स के बीच WebRTC कनेक्शन स्थापित करने की प्रक्रिया के समन्वय के लिए जिम्मेदार है। यह मीडिया डेटा (ऑडियो, वीडियो, DataChannel डेटा) प्रेषित नहीं करता, बल्कि केवल पीयर डिस्कवरी और कनेक्शन पैरामीटर वार्ता के लिए आवश्यक नियंत्रण जानकारी प्रेषित करता है। सफल P2P चैनल स्थापित होने के बाद, Signaling Server की अब आवश्यकता नहीं रह सकती, लेकिन कुछ आर्किटेक्चर में यह बाद के सिग्नल आदान-प्रदान (जैसे कॉल समाप्ति, प्रतिभागियों को जोड़ना) के लिए बना रहता है।

सिग्नलिंग आर्किटेक्चर में तीन घटक शामिल हैं: Signaling Server, Signal Channel (क्लाइंट और सर्वर के बीच ट्रांसपोर्ट प्रोटोकॉल) और क्लाइंट API (आमतौर पर ब्राउज़र के WebRTC स्टैक में निर्मित)। WebRTC विनिर्देश (W3C, 2024) जानबूझकर सिग्नलिंग प्रोटोकॉल को मानकीकृत नहीं करता — डेवलपर्स अपने एप्लिकेशन के लिए उपयुक्त कोई भी ट्रांसपोर्ट चुन सकते हैं। यह लचीला दृष्टिकोण वेब एप्लिकेशन के लिए WebSocket, चैट सिस्टम के लिए XMPP या दूरसंचार बुनियादी ढांचे के साथ एकीकरण के लिए SIP का उपयोग करने की अनुमति देता है।

सिग्नलिंग प्रक्रिया: उच्च-स्तरीय अवलोकन

WebRTC कनेक्शन स्थापित करने से पहले, पीयर्स को तीन प्रकार के संदेशों का आदान-प्रदान करना होता है: सत्र विवरण (offer और answer), ICE उम्मीदवार और सत्र समाप्ति/संशोधन जानकारी। Signaling Server इन संदेशों को पीयर्स के बीच पते के लिए कक्ष या उपयोगकर्ता पहचानकर्ताओं का उपयोग करके रूट करता है। मानक पैटर्न एक “कक्ष” बनाना है जहां दो प्रतिभागी जुड़ते हैं, और सर्वर प्रत्येक प्रतिभागी से केवल उसके वार्ताकार को संदेश रीले करता है।

WebRTC में सिग्नलिंग कैसे काम करती है

Signaling Server निम्नलिखित विशिष्ट WebRTC कनेक्शन स्थापना प्रोटोकॉल को कार्यान्वित करता है। पीयर WebSocket (या अन्य ट्रांसपोर्ट) के माध्यम से सर्वर से जुड़ते हैं और एक कक्ष में पंजीकृत होते हैं। पीयर A (आरंभकर्ता) RTCPeerConnection.createOffer() के माध्यम से एक offer (आउटगोइंग मीडिया स्ट्रीम का SDP विवरण) बनाता है, इसे स्थानीय विवरण के रूप में सेट करता है और Signaling Server को भेजता है। सर्वर offer को पीयर B को रीले करता है। पीयर B offer प्राप्त करता है, इसे रिमोट विवरण के रूप में सेट करता है, createAnswer() के माध्यम से answer बनाता है, इसे स्थानीय विवरण के रूप में सेट करता है और सर्वर के माध्यम से वापस भेजता है। इस प्रक्रिया को SDP Offer/Answer कहा जाता है।

SDP आदान-प्रदान के समानांतर, प्रत्येक पीयर ICE उम्मीदवारों (host, srflx, relay) को एकत्र करता है और उन्हें Signaling Server के माध्यम से दूसरे पीयर को भेजता है। रिमोट पीयर प्राप्त उम्मीदवारों को RTCPeerConnection.addIceCandidate() के माध्यम से जोड़ता है। ICE प्रक्रिया कार्यशील पथ खोजने के लिए उम्मीदवारों के सभी संयोजनों का परीक्षण करती है। एक बार कार्यशील पथ मिल जाने पर (आमतौर पर 1–5 सेकंड के भीतर), मीडिया ट्रैफ़िक सीधे पीयर्स के बीच प्रवाहित होने लगता है, और Signaling Server अब डेटा प्रेषण में भाग नहीं लेता — अगली नियंत्रण घटना (कॉल समाप्ति, स्ट्रीम गुणवत्ता परिवर्तन) तक इसकी भूमिका समाप्त हो जाती है।

कक्ष तंत्र और पंजीकरण

संदेश पते के लिए, Signaling Server कक्ष (room) या चैनल तंत्र का उपयोग करता है। प्रत्येक नया WebRTC सत्र एक अद्वितीय पहचानकर्ता (आमतौर पर UUID) के साथ एक कक्ष बनाता है। आरंभकर्ता कक्ष बनाता है और दूसरे पीयर के जुड़ने की प्रतीक्षा करता है। दूसरा पीयर बाहरी चैनल (जैसे आमंत्रण लिंक) के माध्यम से प्राप्त ID का उपयोग करके कक्ष में शामिल होता है। सर्वर कक्षों का एक मानचित्र बनाए रखता है, जहां प्रत्येक ID जुड़े क्लाइंट की सूची से मेल खाती है। जब प्रतिभागियों की संख्या दो तक पहुंच जाती है, तो सर्वर उनके बीच सिग्नलिंग संदेशों को रीले करना शुरू कर देता है।

WebRTC सिग्नलिंग प्रोटोकॉल

Signaling Server विभिन्न ट्रांसपोर्ट प्रोटोकॉल का उपयोग कर सकता है, जिनमें से प्रत्येक के अपने लाभ और हानियाँ हैं। प्रोटोकॉल का चुनाव एप्लिकेशन के प्रकार, बुनियादी ढांचे की बाधाओं और संगतता आवश्यकताओं पर निर्भर करता है। नीचे सबसे सामान्य प्रोटोकॉल और उनकी विशेषताएँ दी गई हैं।

WebSocket वेब एप्लिकेशन में Signaling Server के लिए सबसे लोकप्रिय प्रोटोकॉल है। यह पूर्ण-द्वैध संचार प्रदान करता है, जो SDP और ICE उम्मीदवारों के अतुल्यकालिक आदान-प्रदान के लिए महत्वपूर्ण है, और WebSocket API के माध्यम से सभी आधुनिक ब्राउज़रों द्वारा मूल रूप से समर्थित है। सर्वर-साइड WebSocket कार्यान्वयन सभी लोकप्रिय प्लेटफार्मों (Node.js, Python, Java, Go) पर उपलब्ध हैं। लाखों उपयोगकर्ताओं वाले एप्लिकेशन के लिए, Signaling Server इंस्टेंस के बीच सिंक्रनाइज़ेशन के लिए Redis Pub/Sub या Kafka पर आधारित स्केलेबल WebSocket समाधानों का उपयोग किया जाता है।

Signaling Server कार्यान्वयन उदाहरण

आइए ws लाइब्रेरी (WebSocket) और अंतर्निर्मित HTTP सर्वर का उपयोग करके Node.js में एक सरल Signaling Server कार्यान्वयन देखें। सर्वर उपयोगकर्ता पंजीकरण, कक्ष निर्माण और प्रतिभागियों के बीच संदेश रीले का समर्थन करता है।

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

यह Signaling Server मूल कार्यक्षमता को कार्यान्वित करता है: कक्ष से कनेक्शन, दो पीयर्स के बीच WebRTC संदेशों (offer, answer, ice-candidate) का रीले और डिस्कनेक्शन प्रबंधन। सर्वर जुड़े WebSocket क्लाइंट वाले कक्षों को संग्रहीत करने के लिए Map का उपयोग करता है। relayToPeer फ़ंक्शन प्रेषक को छोड़कर कक्ष के सभी प्रतिभागियों को संदेश भेजता है। उत्पादन के लिए, आपको संदेश प्रकार सत्यापन, JSON पार्सिंग त्रुटि प्रबंधन और टूटे कनेक्शन का पता लगाने के लिए heartbeat तंत्र जोड़ने की आवश्यकता होगी।

Signaling Server के साथ क्लाइंट एकीकरण

क्लाइंट पक्ष पर, Signaling Server ब्राउज़र के WebSocket API के माध्यम से एकीकृत होता है। क्लाइंट सर्वर से कनेक्शन स्थापित करता है, कक्ष में शामिल होने का अनुरोध भेजता है, और फिर setRemoteDescription() और addIceCandidate() के माध्यम से उन्हें RTCPeerConnection में पास करते हुए आने वाले WebRTC संदेशों को संसाधित करता है। क्लाइंट कोड onicecandidate इवेंट के माध्यम से और offer/answer बनाने के बाद RTCPeerConnection से प्राप्त अपने स्वयं के SDP और ICE उम्मीदवारों को भी सर्वर को भेजता है।

सिग्नलिंग में SDP और ICE की भूमिका

Signaling Server दो प्रमुख प्रकार के मेटाडेटा प्रेषित करता है: SDP (Session Description Protocol) और ICE उम्मीदवार। SDP मीडिया स्ट्रीम मापदंडों का वर्णन करता है — कोडेक, नमूनाकरण दर, चैनलों की संख्या, प्रेषण दिशा (sendrecv, sendonly, recvonly, inactive)। ICE उम्मीदवारों में नेटवर्क पते (स्थानीय, STUN से प्राप्त, TURN से रिले) होते हैं जिनके माध्यम से पीयर कनेक्शन के लिए पहुंच योग्य हो सकता है।

SDP एक टेक्स्ट प्रारूप में प्रस्तुत किया जाता है जिसमें सत्र और मीडिया अनुभाग होते हैं। सत्र भाग सामान्य मापदंडों (सत्र ID, संस्करण, नाम) का वर्णन करता है, जबकि मीडिया अनुभाग अपने कोडेक, पोर्ट और प्रोटोकॉल के साथ प्रत्येक मीडिया स्ट्रीम (ऑडियो, वीडियो, DataChannel) का वर्णन करते हैं। ICE उम्मीदवारों में foundation (समूहीकरण पहचानकर्ता), प्राथमिकता, IP पता, पोर्ट, प्रकार (host, srflx, relay) और प्रोटोकॉल (UDP, TCP) शामिल हैं। प्रत्येक उम्मीदवार में एक ufrag (उपयोगकर्ता नाम खंड) विशेषता भी शामिल होती है जो इसे एक विशिष्ट ICE प्रक्रिया से जोड़ती है।

• SDP Offer — आरंभकर्ता अपनी मीडिया क्षमताओं का विवरण बनाता है और इसे Signaling Server के माध्यम से रिमोट पीयर को भेजता है।
• SDP Answer — रिमोट पीयर अपने स्वयं के विवरण के साथ उत्तर देता है, मीडिया प्रारूपों और कोडेक की पुष्टि या समायोजन करता है।
• ICE Candidate — प्रत्येक पीयर अपने नेटवर्क उम्मीदवारों को ICE फ्रेमवर्क द्वारा खोजे जाने पर सिग्नलिंग सर्वर को भेजता है।
• Trickle ICE — एक आधुनिक अनुकूलन जहां उम्मीदवारों को संग्रह पूरा होने के बाद एक साथ भेजने के बजाय खोजे जाने पर एक-एक करके भेजा जाता है।
• पुनर्वार्ता — जब मीडिया पैरामीटर बदलते हैं (वीडियो सक्षम/अक्षम करना, प्रतिभागी जोड़ना), पीयर Signaling Server के माध्यम से नया SDP आदान-प्रदान शुरू करते हैं।

Trickle ICE WebRTC कनेक्शन स्थापना को काफी तेज करता है। सभी ICE उम्मीदवारों के पूर्ण संग्रह की प्रतीक्षा करने के बजाय (जो जटिल नेटवर्क में 2–10 सेकंड ले सकता है), प्रत्येक उम्मीदवार को खोज के तुरंत बाद Signaling Server को भेजा जाता है। रिमोट पीयर उम्मीदवार प्राप्त करता है और ICE फ्रेमवर्क के माध्यम से तुरंत कनेक्शन परीक्षण शुरू करता है। यह अधिकांश मामलों में कनेक्शन स्थापना समय को 500–1500 ms तक कम कर देता है।