कैस्केडिंग SFUs: WebRTC अनुप्रयोगों में मीडिया की मापनीयता और गुणवत्ता में सुधार

WebRTC के लिए मीडिया सर्वर को तैनात करने में दो कठिनाइयाँ हैं: स्केलिंग, अर्थात्। एक सर्वर का उपयोग करने से परे जा रहा है और सभी सम्मेलन उपयोगकर्ताओं के लिए देरी का अनुकूलन कर रहा है। जबकि "वाई को एक्स कॉन्फ्रेंस के सभी उपयोगकर्ताओं को सर्वर वाई" की भावना में सरल पैनापन क्षैतिज रूप से आसानी से तराजू, यह देरी के मामले में इष्टतम से दूर है। उन सर्वरों के बीच सम्मेलन का वितरण करना जो न केवल उपयोगकर्ताओं के करीब हैं, बल्कि परस्पर जुड़े हुए हैं - दोनों समस्याओं के समाधान की तरह लगते हैं। आज हमने Jitsi से बोरिस ग्रोज़व से विस्तृत सामग्री का अनुवाद तैयार किया है: दृष्टिकोण और कुछ कठिनाइयों के विवरण के साथ-साथ कार्यान्वयन विवरण के साथ, SFUs की कैस्केडिंग की समस्याएं। यह कहने योग्य है कि Voximplant सम्मेलनों में भी SFU का उपयोग किया जाता है ; हम वर्तमान में SFU के कैस्केडिंग पर काम कर रहे हैं, जो अगले साल हमारे प्लेटफॉर्म पर प्रदर्शित होने के कारण है।


माउस न्यूरॉन्स। NIHD इमेज ( CC-BY-2.0 )

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

इसलिए, सम्मेलन के लिए अंत उपकरणों / उपयोगकर्ताओं के बीच इष्टतम मार्ग चुनना बहुत महत्वपूर्ण है। जब केवल दो उपयोगकर्ता होते हैं, तो यह आसान है - वेबआरटीसी प्रतिभागियों के बीच संबंध स्थापित करने के लिए आईसीई प्रोटोकॉल का उपयोग करता है । यदि संभव हो तो, प्रतिभागी सीधे कनेक्ट होते हैं, अन्यथा TURN सर्वर का उपयोग किया जाता है। WebRTC एक TURN सर्वर का पता प्राप्त करने के लिए एक डोमेन नाम को हल कर सकता है, इसलिए आप आसानी से DNS पर आधारित एक स्थानीय TURN का चयन कर सकते हैं, उदाहरण के लिए, AWS Route53 गुणों का उपयोग करके।

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

एक स्टार के साथ समस्या

स्टार टोपोलॉजी में, सभी प्रतिभागी एकल सर्वर से जुड़ते हैं, जिसके माध्यम से वे मीडिया स्ट्रीम का आदान-प्रदान करते हैं। जाहिर है, सर्वर स्थान का चुनाव बहुत महत्व रखता है: यदि सभी प्रतिभागी यूएसए में स्थित हैं, तो सिडनी में सर्वर का उपयोग करना अच्छा विचार नहीं है।


कई सेवाएं एक सरल दृष्टिकोण का उपयोग करती हैं जो ज्यादातर मामलों में अच्छी तरह से काम करती हैं: वे सम्मेलन में पहले प्रतिभागी के करीब एक सर्वर चुनते हैं। हालांकि, ऐसे समय होते हैं जब यह समाधान इष्टतम नहीं होता है। कल्पना कीजिए कि ऊपर की तस्वीर से हमारे तीन प्रतिभागी हैं। यदि एक ऑस्ट्रेलियाई (कॉलर सी) सम्मेलन में शामिल होने वाला पहला है, तो एल्गोरिथ्म ऑस्ट्रेलिया में एक सर्वर का चयन करेगा, हालांकि संयुक्त राज्य अमेरिका में सर्वर 1 सबसे अच्छा विकल्प होगा, क्योंकि वह ज्यादातर प्रतिभागियों के करीब है।

वर्णित परिदृश्य बहुत अक्सर नहीं है, लेकिन ऐसा होता है। यदि हम मानते हैं कि उपयोगकर्ता यादृच्छिक क्रम में जुड़ा हुआ है, तो वर्णित स्थिति 3 प्रतिभागियों के साथ सभी सम्मेलनों के साथ होती है, जिनमें से एक को बहुत हटा दिया जाता है।

एक और अधिक लगातार परिदृश्य: हमारे पास विभिन्न स्थानों में प्रतिभागियों के दो समूह हैं। इस मामले में, कनेक्शन का आदेश महत्वहीन है, हमारे पास हमेशा निकट स्थित प्रतिभागियों का एक समूह होगा जो दूरस्थ सर्वर के साथ मीडिया का आदान-प्रदान करने के लिए मजबूर हैं। उदाहरण के लिए, ऑस्ट्रेलिया से 2 प्रतिभागी (C & D) और 2 USA (A & B) से।


सर्वर 1 पर स्विच करना C & D सदस्यों के लिए इष्टतम नहीं होगा। सर्वर 2 A & B के लिए इष्टतम नहीं है। यही है, कोई फर्क नहीं पड़ता कि क्या सर्वर का उपयोग किया जाता है, हमेशा रिमोट (= गैर-इष्टतम) सर्वर से जुड़े प्रतिभागी होंगे।

लेकिन अगर हमारे पास एक भी सर्वर सीमा नहीं है? हम प्रत्येक भागीदार को निकटतम सर्वर से जोड़ सकते हैं, यह केवल इन सर्वरों को जोड़ने के लिए रहेगा।

समाधान: कैस्केडिंग

हम सर्वर को कनेक्ट करने के तरीके के सवाल को स्थगित करते हैं; आइए पहले देखें कि क्या प्रभाव होगा।


सी और डी के बीच एसएफयू कनेक्शन नहीं बदला है - सर्वर 2 अभी भी उपयोग किया जाता है। सर्वर 1 का उपयोग प्रतिभागियों ए और बी के लिए किया जाता है, और यह स्पष्ट रूप से बेहतर है। सबसे दिलचस्प बात यह है कि उदाहरण के लिए, ए और सी: के बजाय ए <=> सर्वर 2 <=> सी, मार्ग ए <=> सर्वर 1 <=> सर्वर 2 <=> सी के बीच संबंध है।

विनिमय दर पर प्रभाव

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

यह कैसे काम करता है? मीडिया को प्रसारित करने के लिए WebRTC RTP (आमतौर पर UDP पर) का उपयोग करता है। इसका मतलब है कि परिवहन अविश्वसनीय है। जब एक यूडीपी पैकेट खो जाता है, तो आप नुकसान को अनदेखा कर सकते हैं या RTCP NACK पैकेट का उपयोग करके पुनः भेजने (पुन: भेजने) का अनुरोध कर सकते हैं - विकल्प पहले से ही आवेदन के विवेक पर है। उदाहरण के लिए, एक एप्लिकेशन ऑडियो पैकेटों के नुकसान को अनदेखा कर सकता है और कुछ (लेकिन सभी नहीं) वीडियो पैकेटों के पुन: प्रसारण का अनुरोध करता है, इस पर निर्भर करता है कि उन्हें बाद के फ़्रेमों को डिकोड करने की आवश्यकता है या नहीं।


आरटीपी पैकेट रिट्रांसमिशन, सिंगल सर्वर

जब कैस्केडिंग होता है, तो रिट्रांसमिशन स्थानीय सर्वर तक सीमित हो सकता है, अर्थात, प्रत्येक व्यक्तिगत साइट पर किया जाता है। उदाहरण के लिए, ए-एस 1-एस 2-सी मार्ग में, यदि ए और एस 1 के बीच एक पैकेट खो जाता है, तो एस 1 इस पर ध्यान देगा और पुन: प्रवेश का अनुरोध करेगा; S2 और C. के बीच के नुकसान के समान और यदि पैकेट सर्वरों के बीच खो जाता है, तो भी प्राप्त करने वाला पक्ष पुनः प्राप्ति का अनुरोध कर सकता है।


आरटीपी पैकेट रिट्रांसमिशन, दो सर्वर। ध्यान दें कि सर्वर 2 पैकेट 2 का अनुरोध नहीं करता है, क्योंकि पैकेट भेजने के तुरंत बाद NACK आ गया है।

ग्राहक वीडियो प्लेबैक में देरी करने और विलंबित / पुनर्प्राप्त पैकेट प्राप्त करने का प्रबंधन करने के लिए एक घबराना बफर का उपयोग करता है। पार्टियों के बीच विनिमय समय के आधार पर बफर आकार गतिशील रूप से बदलता है। जब हॉप-बाय-हॉप रिट्रन्समिशन होते हैं, तो देरी कम हो जाती है, और परिणामस्वरूप, बफर छोटा हो सकता है - परिणामस्वरूप, समग्र देरी भी कम हो जाती है।

संक्षेप में: भले ही प्रतिभागियों के बीच विनिमय का समय अधिक हो, इससे प्रतिभागियों के बीच मीडिया को स्थानांतरित करने में देरी में कमी आ सकती है। हमें इस प्रभाव का अध्ययन अभी तक करना है।

पेश है कैस्केडिंग एसएफयू: जित्सी मीट केस

अलार्म बनाम। मीडिया

आइए अलार्म को देखें। शुरुआत से ही, Jitsi Meet ने एक सिग्नलिंग सर्वर ( Jicofo ) और एक मीडिया सर्वर / SFU की अवधारणा को साझा किया। यह कैस्केडिंग समर्थन की शुरूआत अपेक्षाकृत सरल है। सबसे पहले, हम एक ही स्थान पर सभी सिग्नलिंग तर्क को संभाल सकते हैं; दूसरे, हमारे पास पहले से ही Jicofo और मीडिया सर्वर के बीच एक सिग्नलिंग प्रोटोकॉल था। हमें केवल कार्यक्षमता को थोड़ा विस्तारित करने की आवश्यकता थी: हमने पहले से ही एक सिग्नलिंग सर्वर से जुड़े कई एसएफयू का समर्थन किया था, हमें कई सिग्नलिंग सर्वर से कनेक्ट करने के लिए एक एसएफयू की क्षमता को जोड़ना था।

नतीजतन, दो स्वतंत्र सर्वर पूल दिखाई दिए: एक जिकोफो इंस्टेंस के लिए, दूसरा मीडिया सर्वर इंस्टेंस के लिए, आरेख देखें:


विभिन्न डेटा केंद्रों के बीच एक झरना की संभावना के साथ AWS पर सर्वर के आयोजन का एक उदाहरण।

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

ऑक्टो प्रोटोकॉल

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

स्पष्टीकरण: इसे ओक्टो हेडर में लपेटने के बजाय, आप आरटीपी हेडर एक्सटेंशन का उपयोग कर सकते हैं, जो शुद्ध (एस) आरटीपी पर पुलों के बीच प्रवाह बना देगा। ऑक्टो के भविष्य के संस्करण इस दृष्टिकोण का उपयोग कर सकते हैं।

दूसरी व्याख्या: ऑक्टो का कोई मतलब नहीं है। सबसे पहले, हम एक केंद्रीय सर्वर का उपयोग करना चाहते थे, और इसने हमें एक ऑक्टोपस की याद दिला दी। इसलिए परियोजना का नाम दिखाई दिया।

ऑक्टो हैडर प्रारूप

जित्ती शब्दावली में, जब एक पुल कई पुलों के साथ एक सम्मेलन का हिस्सा होता है, तो इसमें एक अतिरिक्त ऑक्टो चैनल होता है (वास्तव में, ऑडियो के लिए एक चैनल और वीडियो के लिए एक)। यह चैनल अन्य पुलों से / को मीडिया भेजने / प्राप्त करने के लिए जिम्मेदार है। प्रत्येक पुल को ऑक्टो (डिफ़ॉल्ट रूप से 4096) के लिए एक मुफ्त पोर्ट सौंपा गया है, इसलिए हमें कई सम्मेलनों को संभालने के लिए कॉन्फ्रेंस आईडी फ़ील्ड की आवश्यकता है।

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

साइमलकास्ट

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

सक्रिय सदस्य चयन

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

पुल का चयन

वर्तमान कार्यान्वयन में, यह एल्गोरिथ्म सरल है। जब एक नया प्रतिभागी सम्मेलन में शामिल होता है, तो Jicofo को यह निर्धारित करना होगा कि उसे किस ब्रिज को असाइन करना है। यह प्रतिभागी के क्षेत्र और पुलों की भीड़ के आधार पर किया जाता है। यदि उसी क्षेत्र में एक मुफ्त पुल है, तो इसे नियुक्त किया जाता है। अन्यथा, किसी अन्य पुल का उपयोग किया जाता है।

ऑक्टो के बारे में अधिक जानकारी के लिए, दस्तावेज देखें।

कैस्केडिंग SFU का विस्तार करें

तैनाती के लिए, हमने Amazon AWS में मशीनों का उपयोग किया। हमारे पास 6 क्षेत्रों में सर्वर (अलार्म और मीडिया) थे:

• us-east-1 (उत्तरी वर्जीनिया);
• us-west-2 (ओरेगन);
• यूरोप-पश्चिम -1 (आयरलैंड);
• यूरोप-केंद्रीय -1 (फ्रैंकफर्ट);
• एपी-से -1 (सिंगापुर);
• एपी-सी -2 (सिडनी)।

हमने सदस्य क्षेत्र को निर्धारित करने के लिए भू-संदर्भित HAProxy उदाहरणों का उपयोग किया। Meet.jit.si डोमेन को रूट 53 द्वारा प्रबंधित किया जाता है और HAProxy उदाहरण के लिए हल होता है, जो इस क्षेत्र को भेजे गए अनुरोध के HTTP हेडर में जोड़ता है। शीर्षलेख का उपयोग बाद में config.deploymentInfo.userRegion वैरिएबल के मान के रूप में किया जाता है, जो क्लाइंट /config.js फ़ाइल के लिए धन्यवाद पर उपलब्ध है।

जित्ती इंटरफ़ेस दिखाता है कि कितने पुलों का उपयोग किया जाता है और किन विशिष्ट उपयोगकर्ताओं को संलग्न किया जाता है - नैदानिक ​​और प्रदर्शन उद्देश्यों के लिए। स्थानीय वीडियो के ऊपरी बाएँ कोने पर होवर करने से सर्वर की कुल संख्या और आपके द्वारा कनेक्ट किए गए सर्वर को दिखाया जाएगा। इसी तरह, आप दूसरे प्रतिभागी के मापदंडों को देख सकते हैं। आप अपने ब्राउज़र और इंटरलाक्यूटर के ब्राउज़र (पैरामीटर E2E RTT) के बीच विनिमय समय भी देखेंगे।


यह देखने से कि कौन किस सर्वर से जुड़ा है, आप देख सकते हैं कि कैस्केडिंग का उपयोग किया जाता है या नहीं।

निष्कर्ष

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