स्काइप से वेबआरटीसी तक: हमने वेब के माध्यम से वीडियो संचार कैसे व्यवस्थित किया

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

मैंने नई दिशा के प्रमुख किरिल रोगोवॉय से स्काईेंग में वीडियो संचार के विकास, खोजी गई समस्याओं, समाधानों और बैसाखियों के बारे में बात करने के लिए कहा, जिनका हमने अंततः उपयोग किया। हमें उम्मीद है कि यह लेख उन कंपनियों के लिए उपयोगी होगा जो वेब एप्लिकेशन के माध्यम से स्वयं वीडियो भी बनाती हैं।

एक छोटा सा इतिहास

2017 की गर्मियों में, स्काईेंग विकास के प्रमुख, सर्गेई सफोनोव ने बैकएंड कॉन्फ में एक कहानी के साथ बात की थी कि कैसे हमने "स्काइप को छोड़ दिया और वेबआरटीसी को लागू किया।" रुचि रखने वाले लोग भाषण की रिकॉर्डिंग यहां देख सकते हैं लिंक (~45 मिनट), और यहां मैं संक्षेप में इसके सार को रेखांकित करूंगा।

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

दरअसल, वीडियो संचार के लिए हमारी आवश्यकताएँ लगभग निम्नलिखित थीं:
-स्थिरता;
- प्रति पाठ कम कीमत;
— रिकॉर्डिंग पाठ;
— ट्रैकिंग कौन कितना बोलता है (यह हमारे लिए महत्वपूर्ण है कि छात्र पाठ के दौरान शिक्षक से अधिक बोलते हैं);
- रैखिक स्केलिंग;
- यूडीपी और टीसीपी दोनों का उपयोग करने की क्षमता।

सबसे पहले 2013 में टोकबॉक्स को लागू करने का प्रयास किया गया था। सब कुछ अच्छा था, लेकिन यह बहुत महंगा निकला - प्रति पाठ 113 रूबल - और लाभ खा गया।

फिर 2015 में वोक्सिमप्लांट को एकीकृत किया गया। यहां वह फ़ंक्शन था जिसकी हमें यह निगरानी करने के लिए आवश्यकता थी कि कौन कितना बोला, और साथ ही समाधान बहुत सस्ता था: यदि केवल ऑडियो रिकॉर्ड किया गया था, तो इसकी लागत प्रति पाठ 20 रूबल थी। हालाँकि, यह केवल यूडीपी के माध्यम से काम करता था और टीसीपी पर स्विच नहीं कर सका। हालाँकि, लगभग 40% छात्रों ने इसका उपयोग करना समाप्त कर दिया।

एक साल बाद, हमारे पास अपनी विशिष्ट आवश्यकताओं वाले कॉर्पोरेट ग्राहक आने लगे। उदाहरण के लिए, सब कुछ एक ब्राउज़र के माध्यम से काम करना चाहिए; कंपनी केवल http और https खोलती है; यानी कोई स्काइप या यूडीपी नहीं। कॉर्पोरेट ग्राहक = पैसा, इसलिए वे टोकबॉक्स में लौट आए, लेकिन कीमत की समस्या दूर नहीं हुई।

समाधान - वेबआरटीसी और जानूस

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

एक नियमित पी2पी कनेक्शन हमारे लिए पर्याप्त नहीं है, क्योंकि हम शिकायतों के मामले में आगे के विश्लेषण के लिए पाठ रिकॉर्ड करना चाहते हैं। इसलिए हम एक रिले के माध्यम से WebRTC स्ट्रीम भेजते हैं मीटेको द्वारा जानूस गेटवे. परिणामस्वरूप, ग्राहक एक-दूसरे के पते नहीं जानते, केवल जानूस सर्वर पता देखते हैं; यह सिग्नल सर्वर के कार्य भी करता है। जानूस में कई विशेषताएं हैं जिनकी हमें आवश्यकता है: यदि क्लाइंट ने यूडीपी अवरुद्ध कर दिया है तो स्वचालित रूप से टीसीपी पर स्विच हो जाता है; यूडीपी और टीसीपी दोनों स्ट्रीम रिकॉर्ड कर सकते हैं; मापनीय; इको परीक्षणों के लिए एक अंतर्निहित प्लगइन भी है। यदि आवश्यक हो, तो ट्विलियो से STUN और TURN सर्वर स्वचालित रूप से कनेक्ट हो जाते हैं।

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

वीडियो संचार के विषय पर वापस लौटना

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

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

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

एक नई दिशा चल रही है

आदेश कुछ इस तरह दिखता है:

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

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

दूसरे चरण में, एक परिकल्पना उभरी: WebRTC एक पीयर-टू-पीयर समाधान है, और हम बीच में एक सर्वर का उपयोग करते हैं। शायद समस्या यहीं है? हमने खुदाई शुरू की और अब तक का सबसे महत्वपूर्ण सुधार पाया।

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

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

हमने हाल ही में एक और गैर-स्पष्ट, लेकिन स्पष्ट रूप से महत्वपूर्ण चीज़ की खोज की है: एक मोटे चैनल पर एक शक्तिशाली जानूस सर्वर के बजाय, पतले बैंडविड्थ के साथ दो सरल सर्वर रखना बेहतर है। यह तब स्पष्ट हो गया जब हमने एक ही समय में अधिक से अधिक कमरे (संचार सत्र) भरने की आशा में शक्तिशाली मशीनें खरीदीं। सर्वर में एक बैंडविड्थ सीमा होती है, जिसे हम कमरों की संख्या में सटीक रूप से अनुवादित कर सकते हैं - हम जानते हैं कि कितने खोले जा सकते हैं, उदाहरण के लिए, 300 Mbit/s पर। जैसे ही सर्वर पर बहुत सारे कमरे खुले होते हैं, हम लोड कम होने तक इसे नई गतिविधियों के लिए चुनना बंद कर देते हैं। विचार यह था कि, एक शक्तिशाली मशीन खरीदकर, हम उसमें चैनल को अधिकतम तक लोड करेंगे, ताकि अंत में यह प्रोसेसर और मेमोरी द्वारा सीमित हो, न कि बैंडविड्थ द्वारा। लेकिन यह पता चला कि एक निश्चित संख्या में खुले कमरों (420) के बाद, इस तथ्य के बावजूद कि प्रोसेसर, मेमोरी और डिस्क पर लोड अभी भी सीमा से बहुत दूर है, तकनीकी सहायता पर नकारात्मकता आने लगती है। जाहिर तौर पर जानूस के अंदर कुछ खराब हो रहा है, शायद वहां भी कुछ पाबंदियां हैं. हमने प्रयोग करना शुरू किया, बैंडविड्थ सीमा को 300 से घटाकर 200 Mbit/s कर दिया और समस्याएं दूर हो गईं। अब हमने कम सीमा और विशेषताओं के साथ एक साथ तीन नए सर्वर खरीदे हैं, हमें लगता है कि इससे संचार की गुणवत्ता में लगातार सुधार होगा। बेशक, हमने यह पता लगाने की कोशिश नहीं की कि वहां क्या हो रहा था; हमारी बैसाखियाँ ही सब कुछ हैं। अपने बचाव में, आइए हम कहें कि उस समय इस गंभीर समस्या को जितनी जल्दी हो सके हल करना आवश्यक था, न कि इसे खूबसूरती से करना; इसके अलावा, जानूस हमारे लिए सी में लिखा एक ब्लैक बॉक्स है, इसके साथ छेड़छाड़ करना बहुत महंगा है।

खैर, इस प्रक्रिया में हम:

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

प्रयोगों और उसके बाद के परिवर्तनों ने शिक्षकों के बीच संचार के प्रति असंतोष को जनवरी 7,1 में 2018% से घटाकर जनवरी 2,5 में 2019% करना संभव बना दिया।

आगे क्या है

हमारे विमबॉक्स प्लेटफॉर्म को स्थिर करना 2019 के लिए कंपनी की मुख्य परियोजनाओं में से एक है। हमें बहुत उम्मीदें हैं कि हम गति बनाए रखने में सक्षम होंगे और अब शीर्ष शिकायतों में वीडियो संचार नहीं देखेंगे। हम समझते हैं कि इन शिकायतों का एक महत्वपूर्ण हिस्सा उपयोगकर्ताओं के कंप्यूटर और इंटरनेट में अंतराल से संबंधित है, लेकिन हमें इस हिस्से को निर्धारित करना होगा और बाकी को हल करना होगा। बाकी सब कुछ एक तकनीकी समस्या है, ऐसा लगता है कि हमें इससे निपटने में सक्षम होना चाहिए।

मुख्य कठिनाई यह है कि हम नहीं जानते कि गुणवत्ता में सुधार वास्तव में किस स्तर तक संभव है। इस छत का पता लगाना मुख्य कार्य है। इसलिए, दो प्रयोगों की योजना बनाई गई:

1. युद्ध की स्थिति में जानूस के माध्यम से वीडियो की तुलना नियमित पी2पी से करें। यह प्रयोग पहले ही किया जा चुका है, हमारे समाधान और पी2पी के बीच कोई सांख्यिकीय महत्वपूर्ण अंतर नहीं पाया गया;
2. आइए उन कंपनियों से (महंगी) सेवाएं प्रदान करें जो विशेष रूप से वीडियो संचार समाधानों पर पैसा कमाती हैं, और उनसे मिलने वाली नकारात्मकता की मात्रा की तुलना मौजूदा से करें।

ये दो प्रयोग हमें एक प्राप्य लक्ष्य की पहचान करने और उस पर ध्यान केंद्रित करने की अनुमति देंगे।

इसके अलावा, ऐसे कई कार्य हैं जिन्हें नियमित रूप से हल किया जा सकता है:

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

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

और, निःसंदेह, हम वीडियो संचार के साथ काम करने वाले लोगों और कंपनियों के साथ सक्रिय रूप से संवाद करना जारी रखते हैं। यदि आप हमारे साथ अनुभव का आदान-प्रदान करना चाहते हैं, तो हमें खुशी होगी! टिप्पणी करें, संपर्क करें - हम सभी को उत्तर देंगे।

स्रोत: www.habr.com