WebRTC में STUN/TURN/TURNS/SFU का विस्तृत विवरण और व्यावहारिक अनुप्रयोग।

12 अप्रैल, 2025

विषयसूची

WebRTC क्या है?

वेबआरटीसी (वेब रियल-टाइम कम्युनिकेशन) एक ओपन टेक्नोलॉजी है जो ब्राउज़रों के बीच ऑडियो, वीडियो और डेटा के रियल-टाइम संचार को सक्षम बनाती है। गूगल जैसी कंपनियां इसे मानकीकृत कर रही हैं, क्योंकि यह अतिरिक्त प्लगइन या सॉफ़्टवेयर की आवश्यकता के बिना, केवल जावास्क्रिप्ट एपीआई का उपयोग करके पी2पी संचार की अनुमति देता है।

WebRTC में निम्नलिखित तीन मुख्य घटक शामिल हैं:

उपयोगकर्ता मीडिया प्राप्त करेंएक एपीआई जो कैमरा और माइक्रोफोन जैसे उपकरणों से ऑडियो और वीडियो प्राप्त करता है।
आरटीसीपीईरकनेक्शन: एक कोर एपीआई जो साथियों के बीच संचार स्थापित करता है और मीडिया और डेटा का आदान-प्रदान करता है।
आरटीसीडेटाचैनलएक डेटा चैनल जिसका उपयोग फाइल ट्रांसफर, चैट और अन्य कार्यों के लिए किया जा सकता है।

ये API वीडियो कॉल, ऑडियो कॉन्फ्रेंसिंग और फ़ाइल शेयरिंग जैसे कई रीयल-टाइम एप्लिकेशन विकसित करने में सक्षम बनाते हैं। हालांकि, वास्तविक संचार में NAT ट्रैवर्सल और फ़ायरवॉल संबंधी समस्याएं शामिल होती हैं, इसलिए STUN/TURN/TURNS जैसी NAT ट्रैवर्सल तकनीकों को समझना और लागू करना आवश्यक है।

STUN, TURN और TURNS के बीच अंतर और भूमिकाएँ

WebRTC के साथ स्थिर पीयर-टू-पीयर कनेक्टिविटी प्राप्त करने के लिए, NAT ट्रैवर्सल तंत्र आवश्यक है। यहाँ, हम प्रतिनिधि तकनीकों STUN, TURN और TURNS के तकनीकी अंतर, उपयोग परिदृश्य, लाभ और हानियों की विस्तार से व्याख्या करेंगे।

STUN मुख्य रूप से NAT वातावरण में किसी व्यक्ति का बाहरी पता निर्धारित करने के लिए उपयोग किया जाने वाला प्रोटोकॉल है, जबकि TURN एक रिले सर्वर के रूप में कार्य करता है जब सीधा कनेक्शन संभव नहीं होता है। दूसरी ओर, TURNS, TLS का उपयोग करके TURN संचार को एन्क्रिप्ट करता है और HTTPS के समान पोर्ट 443 का उपयोग करता है, जिससे कॉर्पोरेट नेटवर्क जैसे सख्त फ़ायरवॉल के तहत संचार संभव हो पाता है।

प्रत्येक विधि की विशेषताओं को समझकर और उनका उचित उपयोग करके, आप वेबआरटीसी संचार की सफलता दर और गुणवत्ता में सुधार कर सकते हैं।

STUN (UDP) की भूमिका और विशेषताएं

STUN (Session Traversal Utilities for NAT) एक क्लाइंट है।बाह्य आईपी पता और पोर्टयह आपके आईपी पते का पता लगाने का एक सरल प्रोटोकॉल है। उदाहरण के लिए, यदि आपका पीसी NAT के पीछे है, तो उसे अपना वैश्विक आईपी पता नहीं पता होता है, लेकिन वह STUN सर्वर से क्वेरी करके "बाहर से दिखाई देने वाला आईपी पता और पोर्ट" प्राप्त कर सकता है।

STUN सर्वर एक दर्पण की तरह काम करता है, जो प्राप्त अनुरोध की मूल जानकारी को हूबहू लौटा देता है। इसके परिणामस्वरूप, क्लाइंट अपना वैश्विक IP पता और NAT द्वारा निर्धारित पोर्ट नंबर जान सकता है (सर्वर रिफ्लेक्सिव का एक संभावित उदाहरण)।

STUN संचार आमतौर पर UDP का उपयोग करता है, जिसका डिफ़ॉल्ट पोर्ट 3478 (UDP/3478) होता है। चूंकि इसमें केवल हल्का और एक बार का UDP संचार आवश्यक होता है, इसलिए इसमें ओवरहेड और लेटेंसी कम होती है और सर्वर पर लगभग कोई भार नहीं पड़ता। अतः, जिन वातावरणों में UDP संचार की अनुमति है, वहां NAT को पार करने के लिए STUN को ही सबसे पहले आजमाया जाता है।

STUN उपयोग के दृश्य

STUN उन वातावरणों में प्रभावी है जहाँ NAT ट्रैवर्सल आवश्यक है लेकिन UDP संचार स्वयं अवरुद्ध नहीं होता है, जैसे कि होम नेटवर्क और मोबाइल कनेक्शन। यदि क्लाइंट STUN का उपयोग करके एक-दूसरे के बाहरी IP पते और पोर्ट प्राप्त कर सकते हैं, तो वे सीधा (पीयर-टू-पीयर) संचार स्थापित कर सकते हैं। संचार पथ सीधा होने के कारण, विलंबता कम होती है और गुणवत्ता उच्च स्तर पर बनी रहती है। साथ ही, सर्वर केवल IP जानकारी के आदान-प्रदान में सहायता करता है, इसलिए लागत बहुत कम रखी जा सकती है। उदाहरण के लिए, ऑनलाइन गेम या वीडियो कॉल में, यदि दोनों डिवाइस अपेक्षाकृत खुले NAT पर हैं, तो पीयर-टू-पीयर कनेक्शन के लिए STUN पर्याप्त है।

STUN की सीमाएँ और कमियाँ

STUN केवल "अपना बाहरी पता खोजने" का एक साधन है, और NAT प्रकार और फ़ायरवॉल की सीमाओं के आधार पर, केवल STUN का उपयोग करके कनेक्शन स्थापित करना संभव नहीं हो सकता है। विशेष रूप से, सममित NAT या सख्त फ़ायरवॉल वाले वातावरण में, दूसरे पक्ष से आने वाले पैकेट STUN के माध्यम से प्राप्त पते तक नहीं पहुँच सकते हैं, जिससे संचार असंभव हो जाता है।

इसके अलावा, कुछ कॉर्पोरेट नेटवर्कों में, UDP संचार स्वयं अवरुद्ध हो सकता है, ऐसी स्थिति में STUN अनुरोध डिलीवर नहीं होगा। संक्षेप में, STUN एक ऐसा तंत्र है जो "यह निर्धारित करता है कि प्रत्यक्ष संचार संभव है या नहीं," और यह उन वातावरणों में काम नहीं करता जहाँ प्रत्यक्ष संचार भौतिक रूप से असंभव है। इसलिए, STUN का उपयोग ICE (जिसका वर्णन आगे किया जाएगा) में उम्मीदवार अधिग्रहण के पहले चरण में किया जाता है, और यदि STUN अपर्याप्त है, तो यह TURN पर वापस जाने के लिए डिज़ाइन किया गया है, जिसका वर्णन आगे किया जाएगा।

TURN (UDP) की भूमिका और विशेषताएं

TURN (Traversal Using Relays around NAT) एक प्रोटोकॉल है जो STUN के माध्यम से सीधा संचार संभव न होने पर रिले के रूप में कार्य करता है। TURN सर्वर एक वैश्विक स्तर पर सुलभ रिले बिंदु के रूप में कार्य करता है, जो पैकेट अग्रेषित करने के लिए क्लाइंट और संचार भागीदार के बीच मध्यस्थ के रूप में कार्य करता है। क्लाइंट TURN सर्वर से जुड़ता है और एक रिले आईपी पता और पोर्ट प्राप्त करता है जिसे रिले कैंडिडेट कहा जाता है। इसके बाद, मीडिया और डेटा का आदान-प्रदान दूसरे पक्ष के साथ उस TURN सर्वर के माध्यम से होता है।

TURN आमतौर पर UDP का उपयोग करके संचार करता है, इसलिए जब तक UDP उपलब्ध है, यह मीडिया पैकेट को लगभग सीधे संचार के समान तरीके से रिले कर सकता है। डिफ़ॉल्ट रूप से, यह STUN की तरह ही पोर्ट 3478 (UDP) पर TURN प्रोटोकॉल को स्वीकार करता है। भले ही फ़ायरवॉल नीति द्वारा UDP पोर्ट नंबर प्रतिबंधित हो, TURN फिर भी UDP/443 जैसे अनुमत पोर्ट पर चल सकता है। जब तक UDP उपलब्ध है, यह TCP की तुलना में अधिक रीयल-टाइम रिले प्रदान कर सकता है।

TURN उपयोग परिदृश्य

जब दूसरे पक्ष से सीधा संपर्क स्थापित नहीं किया जा सकता है, तब TURN आवश्यक है। उदाहरण के लिए,ऐसा तब हो सकता है जब एक या दोनों पक्ष किसी कंपनी के सख्त फ़ायरवॉल के पीछे हों, या जब सममित NAT के बीच UDP होल पंचिंग विफल हो जाए।ऐसे वातावरण में, TURN सर्वर के माध्यम से रिले किए बिना संचार असंभव है, इसलिए TURN अंतिम सुरक्षा पंक्ति के रूप में कार्य करता है।

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

टर्न के लाभ

सबसे बड़ा फायदा विश्वसनीयता है। किसी भी NAT या फ़ायरवॉल वातावरण में, जब तक क्लाइंट से TURN सर्वर तक संचार स्थापित हो जाता है, पीयर-टू-पीयर संचार संभव हो जाता है। साथ ही, चूंकि TURN, STUN प्रोटोकॉल का ही एक विस्तार है, इसलिए एक ही सर्वर (जैसे coturn, जिसकी चर्चा आगे की जाएगी) STUN और TURN दोनों अनुरोधों को संभाल सकता है। एक बार कनेक्शन स्थापित हो जाने पर, आगे का मीडिया एक स्ट्रीम के रूप में भेजा जाता है, इसलिए उपयोगकर्ता के दृष्टिकोण से, संचार निर्बाध होता है और इसमें केवल थोड़ी सी देरी होती है।

टर्न के नुकसान

सबसे बड़ी कमियां संसाधन खपत और विलंबता हैं। TURN में, सभी ऑडियो और वीडियो डेटा सर्वर से होकर गुजरता है, जिसके लिए सर्वर पक्ष पर काफी बैंडविड्थ और प्रोसेसिंग क्षमता की आवश्यकता होती है। उदाहरण के लिए, मान लीजिए कि एक वीडियो कॉल एक दिशा में 1 Mbps बैंडविड्थ की खपत करता है, तो एक साधारण गणना से पता चलता है कि 1000 एक साथ उपयोग करने वाले उपयोगकर्ताओं के लिए 1 Gbps की रिले बैंडविड्थ की आवश्यकता होगी। इसलिए, TURN सर्वरों की परिचालन लागत अधिक होती है, और बड़े पैमाने की सेवाओं के लिए कई TURN रिले सर्वरों की आवश्यकता होती है।

इसके अलावा, संचार का लंबा मार्ग लेटेंसी को बढ़ाता है, जिससे वीडियो और ऑडियो में समय की देरी और गुणवत्ता में कमी आती है। साथ ही, STUN की तुलना में TURN पूरी तरह से पीयर-टू-पीयर नहीं है, जिससे यह थोड़ा कम सुरक्षित है (हालांकि TURN सर्वर आमतौर पर केवल अनएन्क्रिप्टेड RTP/डेटाग्राम को रिले करते हैं और उनकी सामग्री की व्याख्या नहीं करते हैं)।

सामान्य तौर पर, TURN का उपयोग केवल आवश्यकता पड़ने पर ही किया जाना चाहिए। वास्तव में, कई WebRTC संचार STUN का उपयोग करके सीधे कनेक्ट किए जा सकते हैं, और Google के आंकड़ों के अनुसार लगभग 861 TP3T कॉल बिना रिलेइंग (पीयर-टू-पीयर) के पूरी हो जाती हैं। केवल शेष लगभग 141 TP3T मामलों में ही TURN की आवश्यकता होती है, और इन 141 TP3T मामलों के लिए TURN इन्फ्रास्ट्रक्चर तैयार रखना महत्वपूर्ण है।

TURNS (TLS ओवर TCP/443) की भूमिका और विशेषताएं

TURNS "TURN over TLS" का संक्षिप्त रूप है, जो TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) के साथ TURN प्रोटोकॉल का उपयोग करके रिले संचार को एन्क्रिप्ट करने की एक विधि है।TURN संचार TLS (HTTPS) द्वारा सुरक्षित है।इसे अक्सर टीसीपी पोर्ट 443 पर सेवा प्रदान की जाती है।चूंकि पोर्ट 443 HTTPS के समान पोर्ट नंबर है, इसलिए कॉर्पोरेट फ़ायरवॉल से गुजरना आसान होता है, जो एक फायदा है क्योंकि इससे प्रॉक्सी और सेंसरशिप को बायपास करना आसान हो जाता है।。

उदाहरण के लिए, किसी कंपनी नेटवर्क में, बाहरी संचार के लिए केवल पोर्ट 80 और 443 ही अनुमत हो सकते हैं। ऐसे मामलों में भी, पोर्ट 443 पर TLS संचार का उपयोग करने वाला TURN सर्वर आसानी से संचार कर सकता है। इसके अलावा, TLS का उपयोग करके एन्क्रिप्ट किए जाने के कारण, संचार की सामग्री को तीसरे पक्ष द्वारा इंटरसेप्ट किए जाने की संभावना कम होती है और यह सुरक्षित रहता है।

WebRTC में, सेटिंग्स""यूआरएल": "टर्न:टर्नसर्वर:443""जैसे कि यूआरआई योजना मेंबारी:इस विकल्प को निर्दिष्ट करके, आप इस TLS-एन्क्रिप्टेड TURN सर्वर का उपयोग कर सकते हैं।

TURNS उपयोग परिदृश्य

कॉर्पोरेट नेटवर्क जैसे सख्त प्रतिबंधों के तहत WebRTC संचार में, TURNS तब उपयोगी होता है जब अन्य सभी तरीके अवरुद्ध हों। यहां तक कि उन वातावरणों में भी जहां सभी UDP और सामान्य TCP पोर्ट अवरुद्ध हैं, कई नीतियां संचार की अनुमति देती हैं यदि इसे HTTPS संचार के समान माना जाता है, जिससे TLS पोर्ट 443 पर TURN एक व्यावहारिक अंतिम उपाय बन जाता है।

इसका उपयोग उन स्थितियों में भी किया जाता है जहां सार्वजनिक वाई-फाई नेटवर्क पर कुछ पोर्ट बंद होते हैं, या जब क्लाइंट पक्ष केवल टीएलएस संचार कर सकता है। संक्षेप में,पहले यूडीपी का प्रयास करें, यदि वह काम नहीं करता है तो टीसीपी का प्रयास करें, और यदि वह भी विफल रहता है, तो पोर्ट 443 पर टीएलएस का प्रयास करें।इसे क्रमिक वापसी प्रक्रिया के अंतिम चरण के रूप में प्रस्तुत किया गया है।

टर्न्स के लाभ

इसका सबसे बड़ा फायदा इसकी उच्च फ़ायरवॉल प्रतिरोधक क्षमता है। TLS एन्क्रिप्टेड संचार को सामान्य HTTPS से अलग करना मुश्किल है, जिससे सख्त फ़िल्टरों से भी इसके गुजरने की संभावना बढ़ जाती है। विशेष रूप से किसी कंपनी में वेब कॉन्फ्रेंसिंग सिस्टम लागू करते समय, आंतरिक नेटवर्क से बाहरी नेटवर्क तक कनेक्शन की अनुमति देना आवश्यक होता है, और सुरक्षा नीति के दृष्टिकोण से TCP/443 TLS संचार को आसानी से स्वीकार किया जाता है। इसके अलावा, एन्क्रिप्टेड होने के कारण, रिले सर्वर तक संचार की गोपनीयता सुनिश्चित होती है (हालांकि, वीडियो जैसी सामग्री अक्सर WebRTC लेयर पर पहले से ही एन्क्रिप्टेड होती है)।

बारी के नुकसान

सबसे बड़ी कमी प्रदर्शन में गिरावट है। TURN के विलंब और भार के अलावा, TLS और TCP का अतिरिक्त भार भी जुड़ जाता है। TCP में पैकेट खो जाने पर विश्वसनीय परिवहन के लिए पुनः प्रसारण तंत्र होता है, लेकिन यह रीयल-टाइम मीडिया के लिए उपयुक्त नहीं है, और पैकेट खो जाने पर वीडियो और ऑडियो सुचारू रूप से नहीं चल सकते हैं।

इसके अलावा, पैकेट ऑर्डरिंग कंट्रोल के कारण टीसीपी में हेड-ऑफ-लाइन ब्लॉकिंग की समस्या होने की संभावना रहती है।यूडीपी की तुलना में, जिटर (उतार-चढ़ाव) भी बढ़ जाता है।इसके अलावा, TLS एन्क्रिप्शन और डिक्रिप्शन प्रोसेसिंग से CPU पर पड़ने वाला भार भी इसमें जुड़ जाता है। परिणामस्वरूप, वास्तविक मापों में 50 मिलीसेकंड या उससे अधिक की अतिरिक्त देरी देखी गई है, जिससे उपयोगकर्ताओं को स्पष्ट रूप से विलंब का सामना करना पड़ता है। विशेष रूप से, वीडियो कॉन्फ्रेंसिंग में, यह बढ़ी हुई देरी बातचीत की गति को बाधित कर सकती है और समय संबंधी विसंगतियों को और अधिक स्पष्ट कर सकती है।

इस प्रकार, गुणवत्ता के मामले में टर्न्स को "अंतिम उपाय" माना जा सकता है, लेकिन यह उन स्थितियों में एक विश्वसनीय जीवन रेखा भी है जहां संचार स्थापित करना सुनिश्चित करने के अलावा कोई अन्य विकल्प नहीं है।

हाल के वर्षों में, एक नए दृष्टिकोण (TURN ओवर QUIC) पर विचार किया गया है जो UDP पोर्ट 443 पर संचालित होता है और TLS के बजाय DTLS/QUIC का उपयोग करता है, लेकिन यह अभी भी मानकीकरण के चरण में है और अभी तक आम नहीं है।

UDP STUN अनुपलब्ध होने पर संचार प्रवाह

यह लेख चरण-दर-चरण बताता है कि जब UDP के माध्यम से STUN उपलब्ध नहीं होता है, तो WebRTC ICE प्रोसेसिंग कैसे आगे बढ़ती है। हम यह भी देखेंगे कि जब UDP पूरी तरह से अवरुद्ध हो जाता है, जैसे कि किसी कॉर्पोरेट नेटवर्क पर, तो ICE नेगोशिएशन कैसे काम करता है।

क्लाइंट STUN सर्वर को एक बाहरी IP क्वेरी (UDP/3478) भेजता है:
वेबआरटीसी क्लाइंट (ब्राउज़र)आइस सर्वरएक बाइंडिंग अनुरोध (बाह्य पते को सत्यापित करने का अनुरोध) निर्दिष्ट STUN सर्वर को UDP पोर्ट 3478 के माध्यम से भेजा जाता है। यह ICE कैंडिडेट संग्रह का पहला चरण है, और सफल होने पर, सर्वर अपना वैश्विक IP पता और पोर्ट नंबर लौटाता है, और इसे सर्वर रिफ्लेक्सिव कैंडिडेट (srflx कैंडिडेट) के रूप में कैंडिडेट सूची में जोड़ दिया जाता है।
फ़ायरवॉल द्वारा UDP पैकेट अवरुद्ध कर दिए जाते हैं और कोई प्रतिक्रिया प्राप्त नहीं होती है।
इस स्थिति में, नेटवर्क फ़ायरवॉल सेटिंग्स के कारण UDP संचार बाहरी नेटवर्क तक नहीं पहुँच पाता है। इसलिए, STUN सर्वर को भेजे गए अनुरोध या तो सर्वर तक नहीं पहुँच पाते हैं, या क्लाइंट को कोई प्रतिक्रिया नहीं मिलती है। परिणामस्वरूप, क्लाइंट को समस्या होती है।STUN प्रतिक्रिया प्राप्त करने में असमर्थइसलिए, बाहरी आईपी पता निर्धारित नहीं किया जा सकता है। ICE एजेंट कुछ समय तक प्रतिक्रिया की प्रतीक्षा करता है, लेकिन फिर समय समाप्त हो जाता है। उपयोगकर्ता के दृष्टिकोण से, इस समय कनेक्शन प्रक्रिया जारी रहती है और कोई त्रुटि संदेश प्रदर्शित नहीं होता है, लेकिन वास्तविकता में...उम्मीदवारों का चयन विफल रहायह कार्य प्रगति पर है।
ICE डायरेक्ट कनेक्शन चेक विफल रहा क्योंकि कोई सर्वर रिफ्लेक्सिव उम्मीदवार नहीं मिले:
सामान्यतः, यदि STUN सफल होता है, तो क्लाइंट के पास एक होस्ट कैंडिडेट (उसका स्थानीय IP पता) और साथ ही एक सर्वर रिफ्लेक्सिव कैंडिडेट (उसका वैश्विक IP पता) होगा, और वह दूर स्थित पीयर पर समान कैंडिडेट के साथ संयोजन करके कनेक्शन की जाँच करेगा। हालाँकि, यदि STUN विफल हो जाता है और कोई वैश्विक IP कैंडिडेट नहीं है,प्रत्यक्ष पीयर-टू-पीयर कनेक्शन के लिए उम्मीदवारों की संख्या अत्यंत सीमित है।ऐसा हो सकता है। उदाहरण के लिए, यदि दोनों पक्षों के पास केवल निजी आईपी पते हैं, तो वे एक दूसरे से कनेक्ट नहीं हो पाएंगे। परिणामस्वरूप, ICE यह निर्धारित करेगा कि "प्रत्यक्ष कनेक्शन संभव नहीं है।" यदि ICE सर्वर (TURN) कॉन्फ़िगर नहीं किया गया है, तो इस चरण में संपूर्ण ICE को विफल माना जाएगा, और WebRTC कनेक्शन स्थापित नहीं होगा (डेवलपर कंसोल में यह दिखाई देगा...)।आईईसी विफल रहाやICE कनेक्शन स्थिति: विफलनिम्न प्रकार की त्रुटियाँ प्रदर्शित होंगी।
TURN रिले उम्मीदवार प्राप्त करने का प्रयास किया जा रहा है (TCP/TLS/443 के माध्यम से):
यदि STUN सीधे तौर पर उम्मीदवारों को प्राप्त करने में विफल भी रहता है,आइस सर्वरयदि कोई TURN सर्वर निर्दिष्ट किया गया है, तो ICE एजेंटअगला मतलबचलिए आगे बढ़ते हैं। इस स्थिति में, UDP काम नहीं कर रहा है, इसलिए क्लाइंट TCP या TLS (उदाहरण के लिए) का उपयोग करके TURN सर्वर से कनेक्ट करने का प्रयास करेगा।turns:turn.example.com:443यदि कॉन्फ़िगर किया गया है, तो TLS हैंडशेक शुरू हो जाएगा। सौभाग्य से, फ़ायरवॉल ने TCP 443 पर HTTPS संचार की अनुमति दी, इसलिए TLS TURN कनेक्शन सफल रहा। क्लाइंट फ़ॉरवर्डिंग के लिए TURN सर्वर पर एक रिले पता सुरक्षित करता है।रिले उम्मीदवाररिले कैंडिडेट प्राप्त हो जाता है। यह "टर्न सर्वर के माध्यम से संचार के लिए एक आभासी कैंडिडेट गंतव्य" होता है। दूसरी ओर, संचार भागीदार (रिमोट साइड) को भी एक रिले कैंडिडेट प्राप्त होगा, या यदि नेटवर्क ठीक है, तो उसके पास पहले से ही एक डायरेक्ट कैंडिडेट या एसटीयूएन कैंडिडेट होगा। किसी भी स्थिति में, यदि कम से कम एक पक्ष के पास रिले कैंडिडेट है, तो दूसरा पक्ष उस टर्न सर्वर से कनेक्ट करने का प्रयास कर सकता है।
रिले के माध्यम से ICE कनेक्शन की स्थापना (या अंतिम विफलता):
एक बार जब दोनों पीयर्स को उपलब्ध रिले कैंडिडेट मिल जाते हैं (इस उदाहरण में, एक या दोनों के लिए रिले कैंडिडेट), तो ICE इनका उपयोग कनेक्शन की जाँच करने के लिए करता है। चूंकि TURN सर्वर के साथ समझौता स्थापित होने के बाद उसके माध्यम से संचार रिले किया जा सकता है, इसलिए मीडिया चैनल तब भी खुल जाता है जब पीयर्स के बीच सीधा UDP ट्रैफ़िक पास नहीं हो पाता। इससे उपयोगकर्ता वीडियो और ऑडियो संचार शुरू कर सकते हैं। कनेक्शन स्थापित होने के बाद, TCP ओवर TLS के कारण कुछ ओवरहेड होने के बावजूद, बातचीत संभव हो जाती है। इसके विपरीत, यदि यह भी विफल हो जाता है (उदाहरण के लिए, यदि कॉर्पोरेट प्रॉक्सी गैर-HTTP TLS संचार का पता लगाकर उसे ब्लॉक कर देता है, या यदि TURN सर्वर के साथ प्रमाणीकरण विफल हो जाता है), तो दुर्भाग्यवश, ICE पूरी तरह से विफल हो जाता है और कनेक्शन समाप्त हो जाता है। एप्लिकेशन को इस स्थिति का पता लगाना चाहिए और उपयोगकर्ता को "कनेक्शन स्थापित नहीं हो सका" जैसे संदेश के साथ सूचित करना चाहिए।

ऊपर दिए गए विवरण में एक चुनौतीपूर्ण वातावरण में ICE वार्ता प्रक्रिया का वर्णन किया गया है जहाँ UDP उपलब्ध नहीं है। संक्षेप में, सिस्टम "होस्ट → STUN → TURN" क्रम में संभावित सर्वरों को आज़माता है, और यदि इनमें से कोई भी काम नहीं करता है, तो कनेक्शन विफल हो जाता है। डेवलपर्स के लिए इस व्यवहार को समझना महत्वपूर्ण है और कम से कम, ICE सर्वर सूची में TURN/TURNS सर्वर को शामिल करना चाहिए ताकि सबसे खराब स्थिति में भी संचार स्थापित हो सके। इसके अलावा, उपयोगकर्ताओं से पूछताछ प्राप्त होने पर, समस्या निवारण आवश्यक है, जैसे कि "ICE विफल" जैसी जानकारी से नेटवर्क वातावरण की समस्याओं (उदाहरण के लिए, UDP अवरोधन) का अनुमान लगाना और किसी भी गुम TURN सर्वर सेटिंग की जाँच करना।

coturn का उपयोग करके STUN/TURN/TURNS सर्वर का निर्माण और कॉन्फ़िगरेशन करना।

यदि आप अपना खुद का STUN/TURN सर्वर स्थापित कर रहे हैं, तो ओपन-सोर्स कार्यान्वयन का उपयोग करें। कोटर्नकोटर्न (Coturn) का उपयोग करना आम बात है। कोटर्न एक सर्वर कार्यान्वयन है जो STUN और TURN दोनों का समर्थन करता है, और कॉन्फ़िगरेशन के आधार पर TURNS (TLS) का भी समर्थन कर सकता है। यहां, हम लिनक्स सर्वर पर कोटर्न स्थापित करने और STUN/TURN/TURNS प्रदान करने वाले सर्वर का निर्माण करने की प्रक्रिया और कॉन्फ़िगरेशन बिंदुओं की व्याख्या करेंगे। साथ ही, विशिष्ट कॉन्फ़िगरेशन फ़ाइलें भी बताई जाएंगी।turnserver.confमैं इसका एक उदाहरण भी दिखाऊंगा।

स्थापना और बुनियादी सेटिंग्स

स्थापित करना

उबंटू या डेबियन के मामले में,अपार्टआप coturn पैकेज को यहाँ से इंस्टॉल कर सकते हैं। उदाहरण के लिए, आप इसे इंस्टॉल कर सकते हैं और निम्नलिखित कमांड का उपयोग करके इसे स्वचालित रूप से शुरू होने के लिए कॉन्फ़िगर कर सकते हैं।

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

उपरोक्त कमांड coturn सर्वर को डेमॉन के रूप में शुरू करेगा। डिफ़ॉल्ट रूप से, कॉन्फ़िगरेशन फ़ाइल /etc/turnserver.conf अब हम फाइल को लोड करेंगे और फिर उसे संपादित करना शुरू करेंगे (संपादित करने से पहले बैकअप जरूर बना लें)।

बुनियादी सेटिंग्स

turnserver.confअब, आइए निम्नलिखित आइटम सेट करें।

क्षेत्र और सर्वर-नाम: यह TURN सर्वर का डोमेन नाम या पहचानकर्ता है। इसका उपयोग WebRTC क्लाइंट प्रमाणीकरण के दौरान किया जा सकता है, लेकिन सामान्यतः कोई भी स्ट्रिंग स्वीकार्य है। उदाहरण: क्षेत्र=उदाहरण.कॉम，सर्वर-नाम=example.com。
लिसनिंग-पोर्ट: यह वह यूडीपी पोर्ट नंबर है जिस पर TURN और STUN सेवाएं उपलब्ध हैं। डिफ़ॉल्ट पोर्ट नंबर 3478 है।लिसनिंग-आईपीआप किसी विशिष्ट NIC से भी जुड़ सकते हैं, लेकिन आमतौर पर0.0.0.0हम सभी प्रकार की पूछताछ स्वीकार करते हैं।
टीएलएस-लिसनिंग-पोर्ट: यह TLS (TURNS) के लिए सुनने हेतु TCP पोर्ट संख्या है। सामान्यतः, पोर्ट 443 या 5349 निर्दिष्ट किए जाते हैं। उदाहरण: tls-listening-port=443。
ऑटो-आईपी: यदि सर्वर स्वयं NAT के पीछे है, तो उसका अपना वैश्विक IP पता निर्दिष्ट करें (इससे सर्वर आंतरिक और बाहरी IP पतों के बीच मैपिंग को पहचान सकेगा)। जिन सर्वरों के पास सीधा वैश्विक IP पता होता है, उनके लिए यह आवश्यक नहीं है।
प्रमाणीकरण विधि: WebRTC का TURN प्रोटोकॉल दीर्घकालिक प्रमाणीकरण (लॉन्ग-टर्म क्रेडेंशियल्स) का उपयोग करता है।lt-cred-mechदीर्घकालिक क्रेडेंशियल तंत्र को सक्षम करें।उपयोगकर्ता = उपयोगकर्ता नाम:पासवर्डअपना यूजरनेम और पासवर्ड निम्नलिखित फॉर्मेट में सेट करें:उपयोग-प्राधिकरण-गुप्तडायनामिक प्रमाणीकरण का प्रदर्शन (बाद वाला टोकन-आधारित प्रमाणीकरण है, जो सुरक्षा में सुधार के लिए प्रभावी है, लेकिन यहां हम एक उदाहरण के रूप में सरल स्थिर उपयोगकर्ता प्रमाणीकरण का उपयोग करेंगे) का उपयोग करके किया जाता है।
लॉग सेटिंग्स: समस्या निवारण के लिएबोटा दस्तावेजफिर, लॉग फ़ाइल का पथ निर्दिष्ट किया गया।जॉर्जआपको विस्तृत लॉगिंग को सक्षम करना चाहिए।

फ़ायरवॉल सेटिंग्स

सर्वर साइड पर, STUN/TURN के लिएयूडीपी पोर्ट 3478और TURN/TLS के लिएटीसीपी पोर्ट 443आपको पोर्ट 5349 खोलना होगा। इसके अतिरिक्त, चूंकि TURN रिले डिफ़ॉल्ट रूप से UDP पोर्ट 10000-20000 का उपयोग करता है, इसलिए आपको सर्वर पर भी इस पोर्ट रेंज को खोलना होगा (यदि आवश्यक हो)।न्यूनतम-पोर्टとअधिकतम-पोर्ट(सीमा को बदला जा सकता है।)

निम्नलिखित में ऊपर उल्लिखित बुनियादी सेटिंग्स दर्शाई गई हैं।/etc/turnserver.confयहां एक उदाहरण दिया गया है।

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

उपरोक्त में, डोमेनexample.comमैंने लेट्स एनक्रिप्ट का सर्टिफिकेट प्राप्त कर लिया है और मैं इसका उपयोग टीएलएस कॉन्फ़िगरेशन के लिए कर रहा हूं।lt-cred-mechदीर्घकालिक प्रमाणीकरण सक्षम करें,उपयोगकर्तायह सरल उपयोगकर्ता नाम और पासवर्ड प्रमाणीकरण स्थापित करता है। वास्तविक संचालन में...उपयोग-प्राधिकरण-गुप्तとस्थैतिक-प्रमाणीकरण-गुप्तहालांकि अस्थायी क्रेडेंशियल जारी करने के लिए टोकन-आधारित विधि का उपयोग करने की अनुशंसा की जाती है, हम यहां उस स्पष्टीकरण को छोड़ देंगे।

टीएलएस का उपयोग करते समय बरती जाने वाली सावधानियां

Linux वातावरण में पोर्ट 443 पर Coturn चलाते समय, पोर्ट अनुमतियों के बारे में सावधान रहना आवश्यक है। 1024 से नीचे के पोर्ट विशेषाधिकार प्राप्त पोर्ट कहलाते हैं और आमतौर पर रूट विशेषाधिकारों के बिना नहीं खोले जा सकते। Ubuntu coturn पैकेज डिफ़ॉल्ट रूप से 1024 पोर्ट का उपयोग करता है।टर्नसर्वरक्योंकि इसे उपयोगकर्ता द्वारा निष्पादित किया जाता है, इसलिए पोर्ट 443 को सीधे तौर पर बाइंड नहीं किया जा सकता है। एक वैकल्पिक समाधान के रूप में,/etc/default/coturnनिष्पादन उपयोगकर्ता को रूट में बदलें।सेटकैपआज्ञाटर्नसर्वरनिष्पादन योग्य फ़ाइलकैप_नेट_बाइंड_सर्विसअनुमति देने के कई तरीके हैं। उदाहरण के लिए, बाद वाले मामले में,sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverइसे निष्पादित करने से गैर-रूट उपयोगकर्ता कम संख्या वाले पोर्ट से जुड़ सकेंगे। साथ ही, प्रमाणपत्र फ़ाइल (cert/pkey) के लिए सही पथ निर्दिष्ट करें और फ़ाइल अनुमतियाँ इस प्रकार सेट करें कि coturn उपयोगकर्ता इसे पढ़ सके। सेटिंग्स बदलने के बाद...sudo systemctl restart coturnसेवा को पुनः आरंभ करें और किसी भी त्रुटि के लिए लॉग की जांच करें।

ऑपरेशन चेक

एक बार कोटर्न सर्वर शुरू हो जाने के बाद, हम इसके संचालन को सत्यापित करने के लिए एक एसटीयूएन क्लाइंट का उपयोग करके एक परीक्षण करेंगे, और फिर एक ब्राउज़र में वेबआरटीसी एप्लिकेशन से एक आईईसी कनेक्शन स्थापित करने का प्रयास करेंगे।स्टनक्लाइंटआज्ञा(apt-get install stun-client(इसके साथ लागू किया जा सकता है)stunclient <server IP> 3478इसे इस तरह से निष्पादित करने से आप यह जांच कर सकेंगे कि क्या आप अपना बाहरी आईपी पता प्राप्त कर सकते हैं। साथ ही, ब्राउज़र में, डेवलपर टूल्स लॉग में ICE उम्मीदवारों की सूची दिखाई देगी।एसआरएफएलएक्स(सर्वर रिफ्लेक्सिव) उम्मीदवार औररिलेकृपया जांच लें कि आपको उम्मीदवार मिल गया है या नहीं। यदि यह काम नहीं करता है, तो निम्नलिखित बिंदुओं पर समस्या का निवारण करें।

जांचें कि सर्वर की फ़ायरवॉल सेटिंग्स (iptables या क्लाउड सुरक्षा समूह) में आवश्यक पोर्ट खुले हैं या नहीं।
जांचें कि क्लाइंट-साइड ICE सर्वर सेटिंग्स (जिसका वर्णन बाद में किया गया है) में सही URI, पोर्ट और प्रमाणीकरण जानकारी कॉन्फ़िगर की गई है या नहीं।
turnserver.confのक्षेत्रसुनिश्चित करें कि सेटिंग्स क्लाइंट के प्रमाणीकरण से मेल खाती हैं (ब्राउज़र-आधारित वेबआरटीसी में यह आमतौर पर कोई समस्या नहीं होती है क्योंकि यह स्वचालित रूप से दायरे निर्दिष्ट करता है, लेकिन कस्टम कार्यान्वयन के साथ सावधान रहें)।
कोटर्न लॉग (/var/log/turnserver.log) प्रमाणीकरण संबंधी त्रुटियों की जाँच करें (गलत उपयोगकर्ताऊपर बताई गई जैसी त्रुटियां उपयोगकर्ता नाम और पासवर्ड के बीच बेमेल होने का संकेत देती हैं।

यदि उपरोक्त सेटिंग्स सही हैं, तो आपका अपना STUN/TURN/TURNS सर्वर चल रहा होगा, जिससे विभिन्न नेटवर्क वातावरणों में WebRTC कनेक्शन के लिए समर्थन सक्षम हो जाएगा।

वेबआरटीसी क्लाइंट में आईईसी सर्वर कॉन्फ़िगरेशन का उदाहरण (जावास्क्रिप्ट)

वेबआरटीसी एप्लिकेशन (ब्राउज़र) साइड पर हमने जो एसटीयूएन/टीयूआरएन सर्वर बनाया है, उसका वास्तव में उपयोग करने के लिए,ICE सर्वर कॉन्फ़िगरेशनयह हो गया। जावास्क्रिप्ट वेबआरटीसी एपीआई में,आरटीसीपीईरकनेक्शनकॉन्फ़िगरेशन बनाते समय, आप STUN/TURN सर्वरों की सूची निर्दिष्ट कर सकते हैं। आगे, हम एक ठोस कोड उदाहरण दिखाएंगे जो सभी STUN/TURN/TURNS सर्वरों को निर्दिष्ट करता है और इसका अर्थ समझाएंगे।

सबसे पहले, ICE सर्वर के लिए एक कॉन्फ़िगरेशन ऑब्जेक्ट बनाएं। अपने सर्वर के डोमेन नाम का उपयोग करें।turn.example.com(आवश्यकतानुसार बदलें) STUN को प्रमाणीकरण की आवश्यकता नहीं होती है, इसलिए केवल URI निर्दिष्ट किया जाता है, जबकि TURN/TURNS को प्रमाणीकरण की आवश्यकता होती है, इसलिए उपयोगकर्ता नाम और पासवर्ड भी निर्दिष्ट किए जाते हैं।

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

उपरोक्तआइस सर्वरइस ऐरे में तीन प्रविष्टियाँ निर्दिष्ट हैं।

स्तब्ध: स्टन:टर्न.उदाहरण.कॉम:3478
यह आपके अपने STUN सर्वर का पता निर्दिष्ट करता है (यदि पोर्ट नहीं दिया गया है, तो 3478 का उपयोग किया जाता है)। STUN का उपयोग NAT ट्रैवर्सल डिटेक्शन और कैंडिडेट रिट्रीवल के लिए किया जाता है, और ब्राउज़र सबसे पहले UDP के माध्यम से इस सर्वर से क्वेरी करके सर्वर रिफ्लेक्सिव कैंडिडेट प्राप्त करने का प्रयास करता है।
टर्न (यूडीपी): turn:turn.example.com:443?transport=udp
मेरा अपना टर्न सर्वरयूडीपी पोर्ट 443यही सेटिंग इस्तेमाल की जानी है। प्रमाणीकरण जानकारी वही उपयोगकर्ता नाम है जिसे आपने पहले coturn में सेट किया था।वेबआरटीक्यूज़रऔर पासवर्डसीक्रेटपास123यह क्वेरी पैरामीटर को निर्दिष्ट करता है।?transport=udpइस विकल्प को जोड़ने से सिस्टम UDP का उपयोग करके TURN कनेक्शन स्थापित करने का प्रयास करेगा (यदि निर्दिष्ट नहीं किया गया है, तो ब्राउज़र पहले UDP का प्रयास करेगा, और यदि वह विफल रहता है, तो वह TCP का भी प्रयास करेगा)। यह सेटिंग सुनिश्चित करती है कि यदि STUN के माध्यम से सीधा कनेक्शन विफल भी हो जाता है, तो UDP पोर्ट 443 (रिले कैंडिडेट) पर TURN रिले के लिए एक उपयुक्त विकल्प मिल जाए।
टर्न (टीएलएस/टीसीपी): turns:turn.example.com:443
TLS का उपयोग करके TURN करेंयह टर्न्स सर्वर कॉन्फ़िगरेशन है। यहाँ भी, उपयोगकर्ता नाम और पासवर्ड निर्दिष्ट किए गए हैं। ब्राउज़र टीसीपी पोर्ट 443 पर इस प्रविष्टि से टीएलएस कनेक्शन स्थापित करता है और एक टर्न्स रिले कैंडिडेट प्राप्त करता है। यह एक अंतिम उपाय रिले कैंडिडेट है; भले ही यूडीपी संचार पूरी तरह से असंभव हो, इस कैंडिडेट की उपस्थिति संचार स्थापित करने की उम्मीद जगाती है।

आरटीसीपीईरकनेक्शनजब ये जनरेट हो जाते हैं, तो सिस्टम क्रमानुसार निर्दिष्ट ICE सर्वरों से कनेक्ट करने का प्रयास करता है और संभावित पथों को एकत्रित करता है। ICE एजेंट पहले STUN संभावित पथों (srflx) को प्राप्त करता है, और फिर साथ ही TURN संभावित पथों (relay) को प्राप्त करता है। इसके बाद ICE एल्गोरिदम इन संभावित पथों को संयोजित करता है, कनेक्शन की जाँच करता है और सबसे उपयुक्त पथ का चयन करता है। डेवलपर्स को किसी अन्य प्रक्रिया की जानकारी होने की आवश्यकता नहीं है।

बिंदु: जैसा ऊपर वर्णित हैकई विकल्प तैयार करें।यह महत्वपूर्ण है। उदाहरण के लिएस्तब्ध करना:यदि आप केवल TURN निर्दिष्ट करते हैं, तो ऐसे वातावरण में जहां UDP अवरुद्ध है, कोई भी विकल्प नहीं मिलेगा और कनेक्शन विफल हो जाएगा। इसी प्रकार, केवल TURN (UDP) निर्दिष्ट करने से भी ऐसे वातावरण में विफलता होगी जहां केवल TCP की अनुमति है। इसलिए, यदि संभव हो,मोड़:とबारी:ICE सर्वर पर दोनों को शामिल करने से अतिरेक मिलता है, जिससे यह सुनिश्चित होता है कि किसी भी वातावरण में कम से कम एक वैध विकल्प मिल जाए (बेशक, TURN सर्वर को UDP और TCP/TLS दोनों का समर्थन करना चाहिए)। क्लाइंट (ब्राउज़र) स्वचालित रूप से एक उपलब्ध पथ का चयन करेगा, इसलिए सूची का क्रम कोई बड़ी समस्या नहीं है। बल्कि,बर्फ परिवहन नीतिをरिलेजब तक अन्यथा निर्दिष्ट न हो, ब्राउज़र सीधे कनेक्शन को प्राथमिकता देते हैं, इसलिए STUN प्रविष्टि शामिल करने से TURN सर्वरों का अनावश्यक उपयोग रोका जा सकेगा। साथ ही, ICE सर्वर सूची में अप्रासंगिक सर्वरों (जैसे कि अस्तित्वहीन पते) को शामिल करने से टाइमआउट के कारण विलंब हो सकता है, इसलिए केवल उन्हीं सर्वरों को शामिल करना सर्वोत्तम है जो निश्चित रूप से उपलब्ध हों।

अंत में, आइए इन सेटिंग्स को लागू करके WebRTC एप्लिकेशन को चलाएं और कनेक्शन की स्थिति सत्यापित करें। अपने ब्राउज़र के डेवलपर टूल्स का उपयोग करके...पीयरकनेक्शन.गेटस्टेट्स()उपयोग करें, याchrome://webrtc-internals(क्रोम में) आप ICE कैंडिडेट और कनेक्शन की स्थिति देख सकते हैं। यदि यह अपेक्षा के अनुरूप काम कर रहा है, तो UDP उपलब्ध होने पर यह स्वचालित रूप से सीधे (P2P) कनेक्शन पर और UDP उपलब्ध न होने पर TURN/TLS कनेक्शन पर स्विच हो जाएगा।

SFU और TURN के बीच अंतर

WebRTC रिलेइंग को मोटे तौर पर "TURN" और "SFU" में विभाजित किया गया है, लेकिन उनकी भूमिकाएँ, कॉन्फ़िगरेशन और उपयोग काफी भिन्न हैं। यह अनुभाग उनके तकनीकी अंतरों का सारांश प्रस्तुत करता है।

टर्न: पीयर-टू-पीयर के विकल्प के रूप में एक रिले

TURN (Traversal Using Relays around NAT) एक सहायक रिले सर्वर है जिसका उपयोग उन वातावरणों में किया जाता है जहाँ WebRTC P2P संचार संभव नहीं होता है। मुख्य रूप से, जब NAT या फ़ायरवॉल के कारण STUN काम नहीं करता है, तो TURN सर्वर पीयर्स के बीच पैकेटों को इंटरसेप्ट करता है और उन्हें रिले करता है। चूंकि प्रत्येक पीयर अपने संबंधित संचार पार्टनर को अपना स्ट्रीम व्यक्तिगत रूप से भेजता है, इसलिए कॉन्फ़िगरेशन अभी भी मेश प्रकार का है, और TURN एक "विकल्प" के रूप में कार्य करता है।

संघटनप्रत्येक उपयोगकर्ता एक रिले के माध्यम से एक दूसरे को डेटा संचारित करता है (प्रभावी रूप से एक मेश नेटवर्क)।
अनुमापकताकम (लोगों की संख्या बढ़ने पर भार भी बढ़ता है)
प्रसारण की सामग्रीकेवल साधारण पैकेट फॉरवर्डिंग की जाती है; कोई मीडिया विश्लेषण या अनुकूलन नहीं किया जाता है।

SFU: कई व्यक्तियों द्वारा की जाने वाली कॉलों के लिए कुशल रिले

सेलेक्टिव फॉरवर्डिंग यूनिट (एसएफयू) एक इंटेलिजेंट रिले सर्वर है जिसका उपयोग कई व्यक्तियों के वेब कॉन्फ्रेंस में किया जाता है।प्रत्येक क्लाइंट एसएफयू को एक स्ट्रीम भेजता है, जो फिर उसे चुनिंदा रूप से अन्य प्रतिभागियों को अग्रेषित करता है।यह स्पीकर डिटेक्शन, इमेज क्वालिटी एडजस्टमेंट और लेटेंसी ऑप्टिमाइजेशन जैसी प्रक्रियाओं को भी अंजाम दे सकता है, जिससे स्केलेबल और उच्च-प्रदर्शन प्रसारण संभव हो पाता है।

संघटन: एक स्टार कॉन्फ़िगरेशन जहां प्रत्येक क्लाइंट एक ही कनेक्शन के साथ एसएफयू से जुड़ता है।
अनुमापकताउच्च (लोगों की संख्या बढ़ने पर भी केवल एक ही संदेश भेजा जाता है)
प्रसारण की सामग्रीइससे स्थानांतरण गंतव्य पर नियंत्रण और मीडिया का अनुकूलन संभव हो पाता है।

TURN और SFU की तुलना तालिका

विशेषताएँ	मोड़	एसएफयू
उद्देश्य	NAT ट्रैवर्सल संभव न होने पर वैकल्पिक विधियाँ	कई लोगों के साथ वास्तविक समय में संचार
संचार विन्यास	मेश (प्रत्येक प्राप्तकर्ता को अलग-अलग भेजें)	तारा विन्यास (एकल संचरण)
रिले फ़ंक्शन	एक साधारण रिले (पारदर्शी)	चयनात्मक स्थानांतरण और अनुकूलन उपलब्ध है।
अनुमापकता	कम	महँगा
मीडिया नियंत्रण	कोई नहीं	हां (उदाहरण के लिए, स्पीकर का पता लगाना, रिज़ॉल्यूशन समायोजन)

TURN केवल "P2P संचार असंभव होने पर उपयोग किया जाने वाला अंतिम उपाय" है, और इसके विन्यास के संदर्भ में, यह एक रिले है जो P2P मेश का पूरक है। दूसरी ओर,एसएफयू एक रिले आर्किटेक्चर है जिसे शुरू से ही कई व्यक्तियों के बीच होने वाली कॉलों के लिए कुशल बनाने के लिए डिज़ाइन किया गया है।चूंकि उनकी भूमिकाएं मौलिक रूप से भिन्न हैं, इसलिए उन्हें इस तरह से डिजाइन करना महत्वपूर्ण है जिससे उनमें भ्रम न हो।

सारांश

यह लेख वेबआरटीसी के मध्यवर्ती से उन्नत स्तर के उपयोगकर्ताओं के लिए STUN, TURN और TURNS के तकनीकी अंतरों और उपयोगों की विस्तृत व्याख्या प्रदान करता है, साथ ही coturn का उपयोग करके सर्वर बनाने का तरीका, कोड उदाहरण और चुनौतीपूर्ण नेटवर्क वातावरण में ICE के व्यवहार की जानकारी भी देता है।

अचेतयह हल्का है फिर भी NAT वातावरण में सीधे संचार को सक्षम बनाता है।मोड़यह कठिन परिस्थितियों में भी संचार स्थापित करने के लिए एक जीवन रेखा बन जाता है।मोड़ोंइन तत्वों को मिलाकर, कंपनी जैसे विशेष वातावरण में भी वेबआरटीसी का उपयोग करना संभव हो जाता है।

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

WebRTC एक जटिल क्षेत्र है जो ब्राउज़र API और नेटवर्क तकनीकों को जोड़ता है, लेकिन विश्वसनीय एप्लिकेशन बनाने के लिए STUN/TURN और ICE की कार्यप्रणाली को समझना आवश्यक है।

मैं आपको इस लेख में दी गई जानकारी का उपयोग करके अपने उत्पाद में NAT ट्रैवर्सल की समस्या से निपटने के लिए प्रोत्साहित करता हूँ। ऐसा करने से उपयोगकर्ता बिना किसी रुकावट के सहज संचार का आनंद ले सकेंगे, क्योंकि पर्दे के पीछे कनेक्शन प्रोसेसिंग को कुशलतापूर्वक डिज़ाइन किया गया है।

URLをコピーしました！