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

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

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

थोड़ा सा इतिहास

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

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

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

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

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

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

समाधान - WebRTC और जानूस

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

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

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

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

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

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

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

काम के लिए एक नई दिशा ली गई है

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

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

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

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

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

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

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

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

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

जनवरी 2018 में शिक्षकों के बीच असंतोष को कम करने के लिए प्रयोगों और बाद के परिवर्तनों को जनवरी 2018 में 7.1% से 2.5% तक सीमित किया गया।

आगे क्या है

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

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

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

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

इसके अलावा, कार्य क्रम में कई कार्य हल किए गए हैं:

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

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

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