आईसीई उमीदवार: यह क्या है, उमीदवारों के प्रकार और कैसे काम करता है

ICE Candidate क्या है?

ICE Candidate (Interactive Connectivity Establishment Candidate) WebRTC प्रोटोकॉल के माध्यम से P2P कनेक्शन स्थापित करने की प्रक्रिया में एक मौलिक इकाई है। यह एक IP पता + पोर्ट जोड़ी दर्शाता है जिसका उपयोग दो पीयर्स के बीच डेटा ट्रांसमिशन के लिए किया जा सकता है। प्रत्येक उम्मीदवार में परिवहन प्रोटोकॉल (UDP, TCP), कनेक्शन प्रकार और प्राथमिकता के बारे में जानकारी होती है।

ICE Candidate प्रत्येक उपकरण पर अलग-अलग बनता है। उपकरण सभी उपलब्ध नेटवर्क इंटरफ़ेस एकत्र करता है, STUN सर्वर के माध्यम से बाहरी पते का अनुरोध करता है और TURN सर्वर से रिले पता जोड़ता है। उम्मीदवारों की परिणामी सूची SDP (Session Description Protocol) प्रारूप में सिग्नलिंग चैनल के माध्यम से दूरस्थ पीयर को भेजी जाती है।

RFC 8445 (IETF, 2018) विनिर्देश के अनुसार, ICE नॉमिनेटेड पेयर्स तंत्र का उपयोग करता है: सभी उम्मीदवारों के संग्रह के बाद, STUN अनुरोधों के माध्यम से उनका जोड़ीवार परीक्षण किया जाता है। जो जोड़ी पहले परीक्षण पास करती है उसे नॉमिनेटेड घोषित किया जाता है और मल्टीमीडिया ट्रांसमिशन के लिए उपयोग किया जाता है। शेष जोड़ियाँ कनेक्शन टूटने की स्थिति में रिज़र्व में रहती हैं।

WebRTC स्टैक में ICE की भूमिका

WebRTC P2P संचार के लिए एक खुला मानक है, लेकिन NAT (Network Address Translation) और फ़ायरवॉल के कारण उपकरणों के बीच सीधा कनेक्शन अक्सर संभव नहीं होता है। ICE Candidate कई वैकल्पिक कनेक्शन पथ प्रदान करके इस समस्या का समाधान करता है। ICE (Interactive Connectivity Establishment) प्रोटोकॉल WebRTC का एक अनिवार्य घटक है और W3C WebRTC विनिर्देश (2025) में वर्णित है।

कई मोबाइल एप्लिकेशन डेवलपर WebRTC लाइब्रेरीज़ जैसे Google WebRTC (Android के लिए) और iOS के लिए नेटिव रैपर का उपयोग करते हैं। इनमें से प्रत्येक में, ICE प्रक्रिया स्वचालित रूप से प्रबंधित होती है, लेकिन उम्मीदवार प्रकारों को समझने से डेवलपर सर्वर बुनियादी ढाँचे को कॉन्फ़िगर कर सकता है और कनेक्शन गुणवत्ता को अनुकूलित कर सकता है।

ICE उम्मीदवारों के साथ SDP प्रारूप

ICE Candidate SDP संदेश के भीतर a=candidate विशेषताओं के रूप में प्रेषित होता है। प्रत्येक पंक्ति में foundation, component ID, परिवहन प्रोटोकॉल, प्राथमिकता, IP पता, पोर्ट और उम्मीदवार प्रकार होता है। नीचे विभिन्न प्रकारों के तीन उम्मीदवारों के साथ SDP खंड का एक उदाहरण दिया गया है:

// Sample SDP with ICE candidates
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

priority फ़ील्ड उम्मीदवारों के परीक्षण का क्रम निर्धारित करता है। जितनी अधिक प्राथमिकता, उतनी जल्दी उम्मीदवार की जाँच की जाएगी। Host उम्मीदवारों की हमेशा सबसे अधिक प्राथमिकता होती है, relay उम्मीदवारों की सबसे कम।

ICE उम्मीदवारों के प्रकार

RFC 8445 विनिर्देश ICE उम्मीदवारों के चार प्रकार परिभाषित करता है, प्रत्येक एक दूरस्थ पीयर तक पहुँचने के एक विशिष्ट तरीके से मेल खाता है। उम्मीदवार प्रकार उसकी प्राथमिकता, कनेक्शन सेटअप समय और सर्वर बुनियादी ढाँचे की आवश्यकताओं को प्रभावित करता है।

Host उम्मीदवार

Host उम्मीदवार उपकरण के स्थानीय नेटवर्क इंटरफ़ेस के IP पते से बनता है। यदि उपकरण किसी पीयर के साथ एक ही स्थानीय नेटवर्क पर है, तो host उम्मीदवार न्यूनतम विलंब के साथ सीधा कनेक्शन प्रदान करता है। मोबाइल उपकरणों के लिए, host उम्मीदवार WiFi इंटरफ़ेस, सेल्युलर LTE/5G कनेक्शन और आवश्यकता पड़ने पर VPN टनल के लिए उत्पन्न होते हैं।

Host उम्मीदवारों की सर्वोच्च प्राथमिकता (UDP के लिए 2130706431) होती है और उनका पहले परीक्षण किया जाता है। यदि दोनों पीयर NAT के पीछे हैं, तो उनके host उम्मीदवार निजी पते (192.168.x.x, 10.x.x.x) होंगे और उनके माध्यम से सीधा कनेक्शन संभव नहीं होगा। ICE तब srflx और relay उम्मीदवारों के परीक्षण पर आगे बढ़ता है।

SRFLX और PRFLX उम्मीदवार

SRFLX (Server Reflexive) उम्मीदवार STUN सर्वर से प्राप्त एक बाहरी IP पता और पोर्ट है। जब उपकरण STUN अनुरोध भेजता है, सर्वर NAT के बाद उसका सार्वजनिक पता देखता है और उसे वापस भेजता है। यह उम्मीदवार विभिन्न NAT के पीछे पीयर्स के बीच सीधा कनेक्शन स्थापित करने की अनुमति देता है, यदि उनके NAT उपकरण Hairpinning का समर्थन करते हैं।

PRFLX (Peer Reflexive) उम्मीदवार गतिशील रूप से खोजा जाता है जब एक पीयर से STUN अनुरोध किसी अप्रत्याशित पते पर आता है। यह प्रकार तब होता है जब दोनों पीयर एक साथ अनुरोध भेजते हैं और NAT एक अस्थायी बंधन बनाता है। PRFLX उम्मीदवार की srflx से अधिक प्राथमिकता होती है लेकिन host से कम।

मोबाइल एप्लिकेशन में, WiFi और सेल्युलर नेटवर्क के बीच स्विच करते समय srflx उम्मीदवार विशेष रूप से महत्वपूर्ण होते हैं। जब उपकरण नेटवर्क बदलता है, IP पता बदल जाता है और ICE को उम्मीदवारों को फिर से एकत्र करना होता है। इस प्रक्रिया को ICE रीस्टार्ट कहा जाता है और इसके लिए नया SDP भेजने की आवश्यकता होती है।

TURN के माध्यम से Relay उम्मीदवार

Relay उम्मीदवार TURN सर्वर पर एक पता है जिसके माध्यम से ट्रैफ़िक एक पीयर से दूसरे तक रिले किया जाता है। इस प्रकार का उपयोग बैकअप विकल्प के रूप में किया जाता है जब सीधा P2P कनेक्शन संभव न हो (सममित NAT, कॉर्पोरेट फ़ायरवॉल)। रिले चैनल विलंब बढ़ाता है और सर्वर लोड बढ़ाता है, इसलिए इष्टतम कॉन्फ़िगरेशन में, TURN सर्वर का उपयोग केवल 10–15% सत्रों के लिए किया जाता है।

लोकप्रिय TURN सर्वर कार्यान्वयन: coturn (खुला स्रोत), Twilio Network Traversal, Metered TURN। TURN प्रदाता का चयन मोबाइल एप्लिकेशन में मीडिया कनेक्शन गुणवत्ता को प्रभावित करता है — सर्वर अतिरिक्त विलंब को कम करने के लिए भौगोलिक रूप से उपयोगकर्ताओं के करीब होना चाहिए।

ICE प्रक्रिया कैसे काम करती है

ICE प्रक्रिया एक बहु-चरणीय प्रोटोकॉल है जो नेटवर्क टोपोलॉजी अनिश्चितता की स्थितियों में एक विश्वसनीय P2P कनेक्शन स्थापित करने की गारंटी देता है। एल्गोरिदम RFC 8445 में वर्णित है और इसमें चार अनिवार्य चरण शामिल हैं: उम्मीदवार संग्रह, छँटाई, परीक्षण और नॉमिनेशन।

चरण 1: उम्मीदवारों का संग्रह

प्रत्येक उपकरण सभी उपलब्ध नेटवर्क पते एकत्र करता है। ऐसा करने के लिए, WebRTC इंजन स्थानीय इंटरफ़ेस (host) की गणना करता है, STUN सर्वर (srflx) को अनुरोध भेजता है और TURN सर्वर से रिले पते का अनुरोध करता है। साथ ही, यदि उपकरण को किसी पीयर से आने वाला STUN अनुरोध प्राप्त होता है तो वह prflx उम्मीदवार की खोज कर सकता है।

मोबाइल डेवलपमेंट में, यह चरण कनेक्शन सेटअप समय के लिए महत्वपूर्ण है। iOS और Android पर, नेटवर्क गति, STUN/TURN सर्वरों की उपलब्धता और सक्रिय नेटवर्क इंटरफ़ेस की संख्या के आधार पर उम्मीदवार संग्रह 200 मिलीसेकंड से 2 सेकंड तक ले सकता है।

चरण 2: जोड़ी निर्माण और छँटाई

सिग्नलिंग चैनल के माध्यम से दूरस्थ पीयर से उम्मीदवारों की सूची प्राप्त करने के बाद, स्थानीय ICE इंजन सभी संभावित उम्मीदवार जोड़ियाँ (स्थानीय + दूरस्थ) बनाता है। प्रत्येक जोड़ी RFC 8445 के सूत्र के अनुसार प्राथमिकता प्राप्त करती है, जो दोनों उम्मीदवारों की प्राथमिकताओं और दिशा (इनकमिंग/आउटगोइंग) को ध्यान में रखता है।

जोड़ियाँ प्राथमिकता के अवरोही क्रम में छाँटी जाती हैं। सर्वश्रेष्ठ जोड़ियाँ पहले परीक्षित की जाती हैं। एल्गोरिदम गारंटी देता है कि host-host जोड़ी की जाँच host-srflx, host-relay या relay-relay से पहले की जाएगी, सरल नेटवर्क कॉन्फ़िगरेशन में कनेक्शन विलंब को कम करता है।

चरण 3: परीक्षण और नॉमिनेशन

ICE प्रत्येक उम्मीदवार जोड़ी के लिए STUN बाइंडिंग अनुरोध भेजता है। यदि STUN प्रतिक्रिया प्राप्त होती है — जोड़ी वैध है। पहली वैध जोड़ी को प्राथमिक के रूप में नॉमिनेट किया जाता है। WebRTC इंजन इस जोड़ी पर मीडिया संचारित करना शुरू करता है, जबकि शेष जोड़ियाँ प्राथमिक के विफल होने की स्थिति में जाँचती रहती हैं।

बड़ी संख्या में उम्मीदवारों के साथ परीक्षण प्रक्रिया कई सेकंड तक ले सकती है। WebRTC टाइमर का उपयोग करता है: host जोड़ियों के लिए टाइमर आक्रामक (20 मिमी) है, relay जोड़ियों के लिए — अधिक रूढ़िवादी (200 मिमी)। मोबाइल एप्लिकेशन डेवलपर ICE सर्वरों की संख्या सीमित करके या iceTransportPolicy कॉन्फ़िगर करके कनेक्शन को गति दे सकते हैं।

ICE रीस्टार्ट

ICE रीस्टार्ट संपूर्ण RTCPeerConnection को फिर से बनाए बिना ICE प्रक्रिया का पुनरारंभ है। यह नेटवर्क बदलने, कनेक्शन खोने या WiFi और मोबाइल नेटवर्क के बीच स्विच करने पर आवश्यक है। रीस्टार्ट के दौरान, सभी वर्तमान उम्मीदवारों को खारिज कर दिया जाता है और प्रक्रिया नए ufrag और pwd जनरेट करके फिर से शुरू होती है।

iOS डेवलपमेंट में, ICE रीस्टार्ट RTCPeerConnection पर restartIce() विधि के माध्यम से बुलाया जाता है। Android पर, Google WebRTC से PeerConnection वर्ग में एक समान विधि का उपयोग किया जाता है। उचित ICE रीस्टार्ट हैंडलिंग अस्थिर नेटवर्क कनेक्शन वाले मोबाइल उपकरणों पर चलने वाले एप्लिकेशन के लिए एक महत्वपूर्ण आवश्यकता है।

ICE में STUN और TURN सर्वर

STUN (Session Traversal Utilities for NAT) और TURN (Traversal Using Relays around NAT) महत्वपूर्ण सर्वर घटक हैं जिनके बिना ICE Candidate वास्तविक इंटरनेट स्थितियों में सफल कनेक्टिविटी की गारंटी नहीं दे सकता। उनका उचित कॉन्फ़िगरेशन सीधे मोबाइल एप्लिकेशन में कॉल गुणवत्ता को प्रभावित करता है।

STUN: बाहरी पते की खोज

STUN सर्वर एक उपकरण को अपना सार्वजनिक IP पता और पोर्ट खोजने की अनुमति देता है जो NAT ने आउटगोइंग कनेक्शन के लिए आवंटित किया है। STUN प्रोटोकॉल RFC 8489 में परिभाषित है और पोर्ट 3478 पर UDP पर काम करता है, साथ ही TCP का भी समर्थन करता है। Google सार्वजनिक STUN सर्वर (stun.l.google.com:19302) प्रदान करता है जिनका उपयोग मुफ्त में किया जा सकता है।

मोबाइल डेवलपमेंट में, STUN अनुरोध एक हल्का ऑपरेशन है जो 50–200 मिमी लेता है। हालाँकि, कुछ कॉर्पोरेट और मोबाइल नेटवर्क UDP ट्रैफ़िक को ब्लॉक करते हैं, जिससे ICE को STUN संचार के लिए TCP का उपयोग करने या सीधे TURN पर वापस जाने के लिए मजबूर होना पड़ता है।

TURN: ट्रैफ़िक रिले

TURN सर्वर एक मीडिया ट्रैफ़िक रिले है। जब सीधा P2P कनेक्शन संभव न हो (सममित NAT, फ़ायरवॉल), उपकरण TURN को डेटा भेजता है, जो इसे दूसरे पीयर को अग्रेषित करता है। TURN एक विश्वसनीय लेकिन महँगा तंत्र है: यह विलंब (30–100 मिमी) जोड़ता है और इसके लिए सभी मीडिया सत्रों के योग के बराबर सर्वर बैंडविड्थ की आवश्यकता होती है।

WebRTC Stats Report (2025) के अनुसार, मोबाइल नेटवर्क पर लगभग 8–15% WebRTC सत्रों को TURN की आवश्यकता होती है। TURN ट्रैफ़िक लागत को अनुकूलित करने के लिए, डेवलपर प्रारंभिक कनेक्शन परीक्षण का उपयोग करते हैं और P2P विफल होने पर ही TURN चैनल सक्रिय करते हैं।

मोबाइल एप्लिकेशन के लिए STUN/TURN चुनना

मोबाइल प्रोजेक्ट में ICE के लिए बुनियादी ढाँचा चुनते समय, निम्नलिखित कारक माने जाते हैं: विलंब कम करने के लिए सर्वरों का भौगोलिक स्थान, UDP और TCP समर्थन, TURN ट्रैफ़िक लागत और SLA। लोकप्रिय समाधानों में शामिल हैं: स्वयं-होस्टिंग के लिए coturn, क्लाउड-आधारित उपयोग के लिए Twilio, Agora और LiveKit।

मोबाइल डेवलपमेंट में ICE Candidate

मोबाइल डेवलपर्स के लिए, ICE Candidate को समझना सिद्धांत से परे है — वॉइस और वीडियो कॉल वाले एप्लिकेशन बनाते समय यह एक व्यावहारिक आवश्यकता है। iOS और Android प्लेटफ़ॉर्म नेटिव WebRTC API प्रदान करते हैं जो ICE हैंडलिंग को स्वचालित करते हैं, लेकिन डेवलपर ICE सर्वर कॉन्फ़िगर करने और नेटवर्क परिवर्तन ईवेंट को संभालने के लिए जिम्मेदार है।

iOS पर ICE कॉन्फ़िगरेशन

iOS पर, WebRTC WebRTC.framework या CocoaPods के माध्यम से GoogleWebRTC लाइब्रेरी के माध्यम से उपलब्ध है। ICE सर्वर RTCConfiguration में RTCIceServer की सरणी के माध्यम से कॉन्फ़िगर किए जाते हैं:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

RTCPeerConnection बनाने और offer() या answer() कॉल करने के बाद, इंजन स्वचालित रूप से ICE उम्मीदवारों को एकत्र करता है। iceGatheringStateChange ईवेंट संग्रह स्थिति में परिवर्तन के बारे में सूचित करता है, जबकि iceConnectionState कनेक्शन स्थिति की रिपोर्ट करता है।

Android पर ICE कॉन्फ़िगरेशन

Android उसी Google WebRTC लाइब्रेरी का उपयोग करता है। ICE सर्वर PeerConnection.RTCConfiguration के माध्यम से सेट किए जाते हैं। डेवलपर iceTransportsType के माध्यम से ICE नीति का प्रबंधन कर सकता है — रिले मोड जबरन केवल TURN का उपयोग करता है, जो विश्वसनीयता बढ़ाता है लेकिन विलंब जोड़ता है:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

bundlePolicy पैरामीटर ICE उम्मीदवारों की संख्या को प्रभावित करता है — MAXBUNDLE मोड सभी मीडिया स्ट्रीम को एक परिवहन में संयोजित करता है, उम्मीदवारों की कुल संख्या कम करता है और कनेक्शन को गति देता है।

मोबाइल एप्लिकेशन में ICE ईवेंट की हैंडलिंग

मुख्य ICE ईवेंट जिन्हें डेवलपर को संभालना चाहिए उनमें शामिल हैं: ICE कनेक्शन स्थिति, ICE संग्रह स्थिति और नए उम्मीदवार की खोज। ICE द्वारा संग्रह और परीक्षण पूरा करने के बाद, इसकी स्थिति connected या completed में बदल जाती है।

मोबाइल नेटवर्क में, WiFi और सेल्युलर कनेक्टिविटी के बीच स्विच बार-बार होते हैं। जब नेटवर्क बदलता है, ICE को रीस्टार्ट करना होता है, अन्यथा मीडिया स्ट्रीम बाधित हो जाती है। डेवलपर स्वचालित रूप से restartIce() कॉल करने के लिए NetworkManager (iOS) या ConnectivityManager (Android) की निगरानी लागू करते हैं।

मोबाइल एप्लिकेशन में एक सफल ICE कार्यान्वयन में शामिल है: विश्वसनीय STUN/TURN सर्वर चुनना, नेटवर्क बदलने पर उचित ICE रीस्टार्ट हैंडलिंग, UI स्थिति प्रदर्शन के लिए iceConnectionState कॉन्फ़िगरेशन और RTCStatsReport के माध्यम से आँकड़ों की निगरानी।