ब्राउज़र से एसआईपी में वीडियो कॉल

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

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

प्रौद्योगिकी के

मैं पिछले लेख से सभी गणनाओं को पूरी तरह से नहीं दोहराऊंगा, लेकिन सीधे निष्कर्ष पर पहुंचूंगा। अगर हम चाहते हैं:

• सभी डेस्कटॉप ब्राउज़रों ने समर्थन किया
• अतिरिक्त सॉफ़्टवेयर स्थापित करने की आवश्यकता नहीं है
• सिस्टम नेटवर्क के हस्तक्षेप के लिए प्रतिरोधी था
• देरी न्यूनतम थी

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

एडोब फ्लैश प्लेयर में वीडियो का समर्थन

वर्तमान में फ़्लैश कई कोडेक्स द्वारा संपीड़ित स्ट्रीम चलाने में सक्षम है:

• H264
• सोरेनसन स्पार्क H263
• ऑन 2 वीपी 6
• फ्लैश स्क्रीन वीडियो

इस सभी "धन" में से, हम केवल H264 में रुचि रखते हैं, क्योंकि सॉफ्टफ़ोन और एसआईपी उपकरणों में अन्य विकल्पों के लिए समर्थन प्राप्त करना लगभग असंभव है।

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



हमें यह भी नहीं भूलना चाहिए कि हम किसके साथ व्यवहार कर रहे हैं। एडोब फ़्लैश प्लेयर संस्करणों 11.0 - 11.2 में H264 धाराओं के कुछ प्रकारों के प्लेबैक को "तोड़ने" में कामयाब रहा। समस्या पैकेट-मोड में पैक की गई स्ट्रीम खेल रही है: 0, अर्थात् इस मोड का उपयोग अधिकांश सॉफ्टफ़ोन द्वारा किया जाता है। बग के बारे में विवरण कंपनी के बगट्रैकर में पाया जा सकता है।

परिणाम निम्न चित्र है। H264 के माध्यम से SIP क्लाइंट को सफलतापूर्वक कनेक्ट करने के लिए, हमें चाहिए:

• ट्रांसकोड सोरेनसन -> H264 एक दिशा में अगर उपयोगकर्ता का एफपी संस्करण 11 से कम है
• ट्रांसकोड H264 -> H264 (पैकेट बदलने के लिए) एक दिशा में यदि उपयोक्ता बग के साथ FP 11 है
• अन्य सभी मामलों में यातायात को अनुमति दें।

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

वीडियो कोई आवाज नहीं है

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

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

एक और बात महत्वपूर्ण है। यदि हमने ऑडियो स्ट्रीम का एक फ्रेम खो दिया है, तो हम बस इसे भटका सकते हैं , उदाहरण के लिए, पिछले फ्रेम को फिर से खोना, और कुछ इसे नोटिस करेंगे। लेकिन इस तरह के एक ट्रिक वीडियो में काम नहीं करेगा, क्योंकि बाद के फ्रेम को खोए हुए पर सुपरइम्पोज किया जाना चाहिए। यहां से कलाकृतियां दिखाई देती हैं, जब तक कि आप स्वतंत्र रूप से संपीड़ित कुंजी फ़्रेम भेजने के लिए रिमोट साइड नहीं पूछते, तब तक खुद गायब नहीं होंगे। SIP में, यह दो तरह से किया जा सकता है: SIP INFO के माध्यम से सिग्नलिंग स्तर पर और RTCP के माध्यम से मीडिया स्तर पर।

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

परिणाम

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



आप हमारे परीक्षण पृष्ठ पर पंजीकरण किए बिना यह सब परीक्षण कर सकते हैं। वीडियो के लिए रिज़ॉल्यूशन 352x288 तक सीमित है। हमने Jitsi और LinPhone सॉफ्टफ़ोन का परीक्षण किया, यह H264 का समर्थन करने वाले अन्य ग्राहकों के बारे में समीक्षा सुनना दिलचस्प होगा। हम भार प्रभाव से भार का सामना करने की कोशिश करेंगे! महत्वपूर्ण नोट: यदि आप ब्राउज़र से ब्राउज़र में RTCKit के माध्यम से कॉल करते हैं, और उसी समय आपके पास NAT काफी अनुकूल है, तो वर्णित सब कुछ के बजाय, RTMFP पीयर-2-पीयर तकनीक का उपयोग किया जाता है।

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