WebRTC को डीबग कैसे करें

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

WebRTC का स्याह पक्ष

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

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

asynchrony

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

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

नैट बाईपास माइनफील्ड

वेब एप्लिकेशन बनाना सर्वर पर चलने वाली कुछ चीज़ों को विकसित करने के लिए नीचे आता है और अनुरोधों का जवाब देता है। सबसे खराब चीज जो पोर्ट हो सकती है वह IPTables में खुली नहीं है। इसका उपचार 2 मिनट में किया जाता है। आप WebRTC के बारे में नहीं कह सकते।

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

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

डिबगिंग कहाँ से शुरू करें

इस लेख में मैं सबसे लोकप्रिय समस्याओं को हल करने के लिए बुनियादी उपकरणों के बारे में बात करता हूं। लेकिन इससे पहले, आइए देखें कि वेबआरटीसी आमतौर पर एक कनेक्शन कैसे स्थापित करता है।

WebRTC एक कनेक्शन कैसे स्थापित करता है

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

WebRTC IP पते, कैप्चर करने की क्षमता और आवाज और वीडियो, नेटवर्क टोपोलॉजी और संचारित डेटा के बारे में जानकारी प्रसारित करने के लिए सिग्नलिंग प्रोटोकॉल का उपयोग करेगा।

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

प्रस्ताव और उत्तर दें

WebRTC कनेक्शन "ऑफ़र" और "उत्तर" का उपयोग करते हैं:

1. कनेक्शन के सर्जक दूसरी ओर "प्रस्ताव" बनाता है और पास करता है।
2. दूसरी पार्टी एक "प्रस्ताव" प्राप्त करती है, एक "प्रतिक्रिया" बनाती है और इसे वापस पारित करती है।
3. कनेक्शन के आरंभकर्ता को एक "उत्तर" प्राप्त होता है।

यह सिद्धांत में है। व्यवहार में, शिष्टाचार का आदान-प्रदान इतना सरल नहीं लगता है।

1. "ऑफ़र" प्रसारित करने से पहले, कनेक्शन सर्जक RTCPeerConnection का एक उदाहरण बनाता है और इससे प्राप्त होता है टेक्स्ट पैकेट "SDP" (सत्र विवरण प्रोटोकॉल) rtcPeerConnection.createOffer () का उपयोग करके; यह पैकेज ब्राउज़र के लिए आवाज और वीडियो प्राप्त / प्रसारित करने की क्षमता का वर्णन करता है।
2. SDP पैकेज की सामग्री rtcPeerConnection.setLocalDescription () का उपयोग करके "कनेक्शन के स्थानीय पक्ष का वर्णन" के रूप में सेट की जाती है।
3. पैकेट को दूसरी तरफ भेजा जाता है, जहां इसकी सामग्री को rtcPeerConnection.setRemoteDescription () का उपयोग करके "कनेक्शन के दूसरे पक्ष का वर्णन" के रूप में सेट किया जाता है।
4. कनेक्शन के दूसरी तरफ, अपने स्वयं के एसडीपी पैकेज को rtcPeerConnection.createAnswer () का उपयोग करके बनाया गया है, इसकी सामग्री को "कनेक्शन के स्थानीय पक्ष का विवरण" के रूप में सेट किया गया है।
5. पैकेट कनेक्शन सर्जक को दिया जाता है, जो अपनी सामग्री को "कनेक्शन के दूसरे पक्ष का विवरण" के रूप में सेट करता है।

और सभी कार्यों के बाद, दोनों कनेक्टिंग पार्टियां एक दूसरे की क्षमताओं को आवाज / वीडियो प्राप्त करने और भेजने के लिए जानती हैं।

आईसीई उम्मीदवारों

लेकिन मीडिया के साथ काम करने की क्षमता पर्याप्त नहीं है। आखिरकार, अनुबंध दलों ने अभी तक नेटवर्क की स्थिति के बारे में कुछ भी नहीं कहा है।

आप यह पता लगा सकते हैं कि ब्राउज़र किस वीडियो कोडेक्स का समर्थन करता है और क्या लैपटॉप पर कैमरा लगभग तुरंत है। आपके बाहरी आईपी पते और NAT ऑपरेशन के तर्क का पता लगाने में समय लगता है, और नेटवर्क स्थिति के बारे में जानकारी का आदान-प्रदान होता है क्योंकि यह जानकारी प्राप्त होती है।

ट्रिक ICE तकनीक के लिए धन्यवाद (सभी ब्राउज़रों द्वारा समर्थित नहीं - अनुवादक का नोट), दो WebRTC उपकरणों के बीच संबंध किसी भी समय स्थापित किया जा सकता है - जैसे ही एक उपयुक्त "उम्मीदवार" मिल जाता है।

डेवलपर को onicecandidate इवेंट (सभी लोअरकेस!) को सब्सक्राइब करना होगा और प्राप्त एसडीपी पैकेट को दूसरी तरफ पास करना होगा, जहाँ उन्हें AddIceCandidate मेथड (और यहाँ, सरप्राइज़, कैपिटल लेटर) का उपयोग करके WebRTC द्वारा प्रसारित करना होगा। यह दोनों तरह से काम करता है।

संबंध

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

STUN सर्वर

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

TURN सर्वर

TURN सर्वर STUN प्रोटोकॉल एक्सटेंशन का उपयोग करता है। एक ही पैकेज, हेडर, एक नई चीज़: कमांड । सर्वर एक प्रॉक्सी है: दोनों क्लाइंट यूडीपी आवंटन पोर्ट के माध्यम से इसे कनेक्ट करते हैं और सर्वर के माध्यम से अपने डेटा को प्रसारित करते हैं।

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

डिबगिंग

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

यह कई अलग-अलग तरीकों से टूट जाएगा। पहले एक कनेक्टिविटी की कमी है। आपने दोनों WebRTCs के लिए STUN और TURN सर्वर सेटिंग्स को पारित किया, उन्हें एक्सचेंज ऑफर, उत्तर और ICE उम्मीदवारों की मदद की, लेकिन कोई वीडियो या आवाज नहीं है। कहाँ से शुरू करें? स्थानीय प्लेबैक समस्याओं के साथ।

WebRTC स्थानीय डिबगिंग

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

जांच करने के लिए पहली चीज आपकी सिग्नलिंग है। यह आपका कोड है जो वीडियो (प्रस्ताव, उत्तर) और ब्राउज़रों के बीच नेटवर्क सेटिंग्स (बर्फ के उम्मीदवारों) के बारे में जानकारी के साथ ऑडियो के कॉन्फ़िगरेशन को प्रसारित करता है। आपको यह जाँचने की आवश्यकता है कि कौन से पैकेट भेजे गए, जो WebRTC को प्राप्त हुए और प्रेषित किए गए:

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

यदि पैकेट का आदान-प्रदान संदिग्ध नहीं है, तो आप सत्र की हिम्मत में देरी कर सकते हैं।

सत्र विवरण प्रोटोकॉल

एसडीआर पाठ प्रारूप में WebRTC द्वारा ऑफ़र, उत्तर और ICE उम्मीदवार पैकेज बनाए जाते हैं। पहली नज़र में, पैकेज की सामग्री डरावनी दिखती है, लेकिन थोड़ी तैयारी के साथ आपको डीबगिंग के दौरान उनसे बहुत लाभ मिल सकता है। विकिपीडिया एसडीपी को बहुत अच्छी तरह से वर्णन करता है, लेकिन मुझे आपके लिए बेहतर विवरण मिला।

उम्मीदवार आईसीई एसडीपी पैकेट में सबसे महत्वपूर्ण क्षेत्र टाइप है । WebRTC के लिए, एक फ़ील्ड में तीन मान हो सकते हैं:

• टाइप होस्ट;
• टाइप srflx;
• टाइप रिले।

प्रकार होस्ट

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

टाइप srflx

पत्र "srflx" का संयोजन "सर्वर रिफ्लेक्टिव" के लिए खड़ा है और बाहरी आईपी पते का उपयोग करके कनेक्शन उम्मीदवारों को चिह्नित करता है, जहां कनेक्शन के लिए एक STUN सर्वर पर्याप्त है (NAT पैठ तकनीक का उपयोग करना, जो लगभग 80% मामलों में सफल है, अनुवादक ध्यान दें)।

टाइप रिले

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

डिवाइस कनेक्टिविटी का परीक्षण

Google आपके डिवाइस पर WebRTC कनेक्शन के परीक्षण के लिए एक समर्पित वेब एप्लिकेशन प्रदान करता है। पृष्ठ खोलें, "प्रारंभ" बटन पर क्लिक करें और जावास्क्रिप्ट कोड सिग्नलिंग, Google के STUN और TURN सर्वर का उपयोग करके Google सर्वर से कनेक्शन स्थापित करने का प्रयास करेगा।

WebRTC आंतरिक

आपने सभी पैकेजों की जांच की, कोड की जांच की, सब कुछ सही लग रहा है, लेकिन यह काम नहीं करता है? ऐसे मामलों के लिए, Google ने एक विशेष अनुभाग के साथ अपना क्रोम ब्राउज़र प्रदान किया है जो कनेक्शन सेटअप के दौरान WebRTC के आंतरिक और सफल कनेक्शन के मामले में कुछ सुंदर रेखांकन दिखाता है। उपयोग करने के लिए, ब्राउज़र में एक विशेष तकनीकी लिंक खोलें:

chrome://webrtc-internals

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

ICE सेटअप

पृष्ठ के शीर्ष पर ICE स्ट्रिंग है जिसका उपयोग कनेक्शन को आरंभ करने के लिए किया गया था। यदि इसके गठन के दौरान कोई त्रुटि हुई थी, तो यह तुरंत दिखाई देगा ("ICE लाइन" द्वारा लेखक STCP और TURN सर्वर की सूची के साथ RTCPeerConnection ऑब्जेक्ट के कॉन्फ़िगरेशन को संदर्भित करता है ('आइसवर्कर्स' ऑब्जेक्ट) - अनुवादक द्वारा नोट)। शायद सर्वर की कोई सूची नहीं है? CreateOffer या createAnswer को पहला कॉल करने से पहले आपको RTCPeerConnection ऑब्जेक्ट को कॉन्फ़िगर करना होगा।

RTCPeerConnection इवेंट

अगला इंटर्नल सेक्शन RTCPeerConnection के तरीकों और कालानुक्रमिक क्रम में ऑब्जेक्ट से प्राप्त घटनाओं को दिखाता है । त्रुटियों को ध्यान से लाल रंग में हाइलाइट किया गया है। कृपया ध्यान दें कि लाल addIceCandidateFailed अक्सर एक त्रुटि का संकेत नहीं है और कनेक्शन सामान्य रूप से स्थापित हो सकता है। यदि कनेक्शन सफल होता है, तो सूची में अंतिम घटना पूर्ण के मान के साथ एक iceconnectionstatechange घटना होगी।

अनुभाग 'आँकड़े'

कनेक्शन सफलतापूर्वक स्थापित होने पर अगला अनुभाग प्रासंगिक है। इसमें संचरित डेटा और नेटवर्क देरी के आंकड़े शामिल हैं। दो सबसे दिलचस्प विकल्प हैं: ssrc और bweforvideo ।

• ssrc , "Stream Source", आपके प्रत्येक ऑडियो और वीडियो ट्रैक को चिह्नित करता है। राउंड ट्रिप के समय के रूप में प्रेषित डेटा और मापदंडों के आंकड़े प्रदर्शित करता है ;
• bweforvideo , BandWidth Estimate, उपयोग किए गए नेटवर्क चैनल की चौड़ाई प्रदर्शित करता है।

गेटस्टैट्स फ़ंक्शन

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

 rtcPeerConnection.getStats(function(stats) { document.getElementById("lostpackets").innerText = stats.packetsLost; }); 

एक अन्य उपयोगी उपकरण एक RTCPeerConnection ऑब्जेक्ट का oniceconnectionstatechange घटना है। ईवेंट हैंडलर कनेक्शन कनेक्शन की जानकारी प्राप्त करेगा। संभावित विकल्प:

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

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

वीडियो के बजाय ब्लैक आयत

अक्सर एक ऐसी स्थिति होती है जब कनेक्शन स्थापित होता है, ध्वनि संचारित होती है, लेकिन वीडियो के बजाय, एक या दोनों प्रतिभागियों में एक काले रंग की आयत होती है। अधिकांश बार ऐसा होता है यदि आप प्राप्त किए गए वीडियो ऑब्जेक्ट को पूर्ण स्थिति में कनेक्शन संक्रमण से पहले एक HTML तत्व को असाइन करते हैं।

कैसे बाहर एक छड़ी प्रहार करने के लिए

RTCPeerConnection ऑब्जेक्ट के अलावा और ब्राउज़र द्वारा प्रदर्शित किए गए इंटर्नल के अलावा, आप नेटवर्क पैकेट विश्लेषण उपकरण जैसे Wireshark का उपयोग कर सकते हैं। ये उपकरण उपयोग किए गए WebRTC प्रोटोकॉल के पैकेट प्रदर्शित कर सकते हैं। उदाहरण के लिए, Wireshark आपको मुख्य विंडो में STUN पैकेट की सामग्री दिखाएगी, और आप फ़िल्टर फ़ील्ड में कीवर्ड "stun" लिखकर उन्हें फ़िल्टर कर सकते हैं:


सर्वर प्रतिक्रियाओं में क्या देखना है? यदि आप केवल बाइंडिंग प्रकार के साथ उत्तर देखते हैं, तो इसका मतलब है कि केवल STUN (बाहरी IP टॉक) समर्थित है, और WebRTC केवल srflx उम्मीदवारों की पेशकश कर सकता है। यदि उत्तरों में TURN- विशिष्ट पैकेज आवंटन और CreatePermission शामिल हैं , तो WebRTC के पास प्रॉक्सी सर्वर के माध्यम से कनेक्ट करने का प्रयास करने का अवसर होगा। पैकेट विश्लेषक सफल और असफल आवंटन को चिह्नित करता है। यदि कोई सफल नहीं है, तो सबसे अधिक संभावना है कि TURN सर्वर तक गलत पहुंच पैरामीटर (जो लगभग हमेशा एक उपयोगकर्ता नाम और पासवर्ड के साथ रक्षा करते हैं - अनुवादक का नोट) पारित हो जाते हैं।

यदि लॉग में CreatePermission Success Response पैकेज है, तो हम मान सकते हैं कि STUN और TURN कॉन्फ़िगरेशन के साथ सब कुछ ठीक है। और अगर कोई ChannelBind पैकेज है, तो उच्च गति पर TURN सर्वर से कनेक्शन स्थापित करना संभव था।

सेलुलर मुद्दों

मेरे व्यवहार में, WiFi कनेक्शन स्थापित करने वाले कई WebRTC समाधान 3G / 4G के माध्यम से कनेक्ट नहीं हो सकते हैं। मोबाइल डिवाइस पर लॉन्च किया गया एक एप्लिकेशन डीबग करना कठिन है: हमारे पास ऐसा कोई साधारण पैकेट एनालाइजर नहीं है, जैसे कि वियरशर्क, और सफारी वेबआरटीसी इंटर्नल्स को नहीं दिखा सकते। लॉजिक बताता है कि यदि एप्लिकेशन वाईफाई के माध्यम से ठीक काम करता है, तो समस्या एप्लिकेशन में ही नहीं है, बल्कि सेलुलर संचार में है। डिबग कैसे करें? एक लैपटॉप लें और उसमें 3 जी डोंगल कनेक्ट करें। तो आपके पास एक पैकेट विश्लेषक और सुविधाजनक लॉग हैं जिसके साथ आप उचित समय में सभी परेशानियों की जड़ का पता लगा सकते हैं।

निष्कर्ष

WebRTC को डीबग करना आसान नहीं है, लेकिन यदि आप इंटरनेट पर अच्छी तरह से खोज करते हैं, तो आप कई लेख और उदाहरण पा सकते हैं। यदि आप रीयलटाइम संचार के क्षेत्र में काम करते हैं, तो मेरा सुझाव है कि आप STUN , TURN प्रोटोकॉल और WebRTC प्रौद्योगिकी के लिए RFC विनिर्देशों को पढ़ें। दस्तावेज़ बड़े हैं, लेकिन उनमें निहित जानकारी विश्वसनीय निर्णय लेने और "क्यों नहीं बजती है" इस सवाल का जवाब देने में मदद करती है।