MailRu Agent और ICQ में WebRTC - पेशेवरों, विपक्ष और संभावनाओं

हेलो, हेब्र!

हाल ही में हमने विंडोज प्लेटफॉर्म के लिए Mail.Ru Agent 5.10 का एक नया संस्करण जारी किया , और इस संस्करण की नई "सुविधाओं" की सूची में एक असंगत रेखा दिखाई दी: "आवाज और वीडियो कॉल की गुणवत्ता में सुधार हुआ है"।

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

कहानी

इसलिए, हाल ही में (जो कि संस्करण 5.9 तक है), हमने अपने डेस्कटॉप क्लाइंट में "इंजन" का उपयोग किया, जिसे कई साल पहले ग्लोबल आईपी सॉल्यूशंस (जीआईपीएस) द्वारा लाइसेंस दिया गया था। उस समय किसी और के उत्पाद को लाइसेंस देने का विचार काफी सफल रहा: हमें बाजार के नेताओं में से एक से एक तैयार समाधान प्राप्त हुआ, और इसके साथ कुछ ही समय में Mail.Ru Agent में कॉल कार्यक्षमता जोड़ने का अवसर मिला, जिसकी आवश्यकता स्पष्ट हो गई।

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

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

इसके अलावा, लगभग उसी समय, हमने खुद एओएल से आईसीक्यू का अधिग्रहण किया, और एकल मीडिया प्लेटफॉर्म का सवाल बहुत तेजी से उठा।

हमने कई विकल्पों पर विचार किया, अपने स्वयं के विकास से "इंजन" को दूसरे विक्रेता से लाइसेंस देने के लिए, लेकिन Google ने फिर से समायोजन शुरू किया, जिसने अप्रत्याशित रूप से अपने नए WebRTC प्रोजेक्ट के हिस्से के रूप में GIPS स्रोत कोड का हिस्सा खोला।

WebRTC

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

खैर, विचार अच्छा है - हालांकि, इसकी स्थिति अभी भी अस्पष्ट है। एकमात्र ब्राउज़र जो वर्तमान में WebRTC का समर्थन करता है, क्रोम का विकास संस्करण है (तथाकथित "नाइटली बिल्ड"), अब तक यह इस तकनीक के W3C मानक स्थिति से बहुत दूर है, और Microsoft सो नहीं रहा है, सक्रिय रूप से अपने Silverlight को बढ़ावा दे रहा है।

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

WebRTC रिपोजिटरी पर पहला शोध उत्साहजनक परिणाम मिला:

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

हालांकि, वेबआरटीसी के साथ एक अधिक विस्तृत परिचित पहली अप्रिय खोजों का कारण बना:

• परियोजना कीड़ों से भरी थी, लगभग कुछ भी काम नहीं किया;
• वीडियो की गुणवत्ता कम होने के बजाय (विशेष रूप से चैनल के नुकसान के अनुकूलन के मामले में);
• केवल विंडोज प्लेटफॉर्म का समर्थन किया गया था (एंड्रॉइड के लिए अल्पविकसित कोड रिपॉजिटरी में मौजूद था, लेकिन इसके अध्ययन के समय यह भी नहीं चल रहा था);
• सबसे महत्वपूर्ण ध्वनिक घटकों में से एक का कार्यान्वयन, वेबआरटीसी में इको कैन्सेलर (एईसी - ध्वनिक इको कैंसेलर), जीआईपीएस से भी बदतर निकला;
• VP8 कोडेक , WebRTC में शामिल है, कुछ स्थितियों में मालिकाना GIPS LSVX कोडेक की तुलना में खराब हो गया है जो पहले इस्तेमाल किया गया था;
• बड़ी मात्रा में "कचरा" - अप्रयुक्त कोड।

अध्ययन के अंत में हमने जो मुख्य निष्कर्ष निकाला है वह यह है कि वेबआरटीसी लाइब्रेरी में वीडियो के लिए जिम्मेदार हिस्सा "टूटा हुआ" है और त्रुटियों को ठीक करने के लिए सावधानीपूर्वक काम करने की आवश्यकता है।

फिर भी, कई कमियों की खोज के बावजूद, हमने तय किया कि वेबआरटीसी हमारे अपने "इंजन" के लिए एक अच्छा आधार है, और इसे अपने दम पर विकसित करना शुरू कर दिया। हमने माना कि लंबे समय में एक तृतीय-पक्ष विक्रेता से कोड और स्वतंत्रता पर पूर्ण नियंत्रण हमारे लिए एक नए प्रदाता से लाइसेंस प्राप्त "इंजन" के साथ Mail.Ru Agent और ICQ के त्वरित लॉन्च की तुलना में अधिक महत्वपूर्ण है।

तो, हमारी रणनीति निम्नानुसार थी - पहले WebRTC कोड को उत्पादन की गुणवत्ता में लाएं, और फिर अधिक जटिल समस्याओं को हल करें: विशेष रूप से समस्याग्रस्त मॉड्यूल की एक संख्या को फिर से लिखें, h.264 वीडियो कोडेक के लिए समर्थन जोड़ें (केवल VP8 बॉक्स से बाहर है), कोड को मोबाइल प्लेटफार्मों पर पोर्ट करें आदि

वास्तव में, हमने सफलतापूर्वक कार्य के पहले भाग को हल कर दिया, और Mail.Ru Agent 5.10 अवधारणा का एक प्रकार का प्रमाण है - पहला वास्तविक उत्पाद जिस पर WebRTC लाइब्रेरी को हमारे सुधारों के साथ "परीक्षण" किया गया था।

एजेंट 5.10 में कॉल में नया क्या है?

यदि हम नए संस्करण की तुलना पिछले वाले (कॉल के मामले में) से करते हैं, तो पहली नज़र में, कुछ बदलाव हैं। हालांकि, ग्राहकों के बीच एक सत्र की स्थापना की तेजी से बढ़ी हुई गति तुरंत ध्यान आकर्षित करती है। यह libjingle के उपयोग के माध्यम से हासिल किया गया था - WebRTC के घटकों में से एक।

Libjingle पी 2 पी सत्रों के आयोजन के लिए एक बल्कि परिष्कृत रूपरेखा है, जिसे मूल रूप से Google टॉक मैसेंजर में कॉल करने के लिए डिज़ाइन किया गया है। चूंकि Google टॉक XMPP प्रोटोकॉल का उपयोग करता है, लिबजिंगल कोड की एक उचित मात्रा इस IM प्रोटोकॉल के शीर्ष पर सिग्नलिंग (सत्र मापदंडों के बारे में डेटा का आदान-प्रदान) की समस्या को हल करती है।

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

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

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

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

आप आधिकारिक वेबसाइट से नवीनतम क्लाइंट संस्करण (5.10) डाउनलोड करके नए "इंजन" का परीक्षण कर सकते हैं। बेशक, आपके वार्ताकार को भी इस संस्करण को स्थापित करना चाहिए।

योजनाओं

फिलहाल, हमारी 3 मुख्य प्राथमिकताएँ हैं:

• वीडियो की गुणवत्ता में सुधार (चैनल बैंडविड्थ और पैकेट हानि के लिए बेहतर अनुकूलन सहित);
• संभावित वीडियो रिज़ॉल्यूशन की सीमा का विस्तार करना (अब, पिछले संस्करण में, केवल सीआईएफ समर्थित है, अर्थात 352x288 - हम कम से कम वीजीए और 720p जोड़ने की योजना बनाते हैं);
• "इंजन" को मोबाइल प्लेटफ़ॉर्म एंड्रॉइड और आईओएस पर पोर्ट करना।

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

व्यक्तिपरक गुणवत्ता में लगातार सुधार करने के लिए, हम "इंजन" के प्रमुख घटकों को बदलते हैं: घबराना बफर, एआरएस (स्वचालित दर चयन), एफईसी (फॉरवर्ड एरर करेक्शन), एईसी (ध्वनिक इको कैंसेलर), आदि। हमने h.264 बनाम VP8 की एक शोध तुलना भी शुरू की - यह बहुत संभावना है कि विभिन्न कॉल मापदंडों (चैनल बैंडविड्थ, क्लाइंट डिवाइस के प्रकार और प्रदर्शन) के साथ भविष्य के संस्करणों में हम विभिन्न वीडियो कोडेक्स का उपयोग करेंगे।

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

उदाहरण के लिए, ARM आर्किटेक्चर के लिए अधिकांश आधुनिक SoC- सॉल्यूशंस (सिस्टम-ऑन-ए-चिप) में h.264 मानक में एन्कोडिंग और डिकोडिंग वीडियो के लिए एक हार्डवेयर त्वरक होता है (यही कारण है कि हमने अपने इंजन में h.264 कोडेक सहित काम शुरू किया है)। कठिनाई इस तथ्य में निहित है कि विभिन्न निर्माताओं के त्वरक के नियंत्रण इंटरफेस में एक-दूसरे के साथ कुछ भी नहीं है। यह फोन या टैबलेट के "देशी" सॉफ़्टवेयर के लिए कोई समस्या पेश नहीं करता है: यह ऐसे सॉफ़्टवेयर के लिए पर्याप्त है जो केवल एक त्वरक के साथ काम करने में सक्षम हो। हालांकि, एक तृतीय-पक्ष एप्लिकेशन को उन सभी चिपसेटों का समर्थन करने की आवश्यकता है जो वर्तमान में व्यापक हैं - और यह इतना सरल नहीं है, यह देखते हुए कि खुले दस्तावेज अक्सर गायब होते हैं।

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

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

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

इन सभी कठिनाइयों के बावजूद, पोर्टिंग चल रही है और निकट भविष्य में हम कॉल सपोर्ट के साथ एंड्रॉइड के लिए एक क्लाइंट पेश करेंगे।

देखते रहो!

इल्या नौमोव,
प्रोजेक्ट मैनेजर Mail.Ru Agent