كيفية تصحيح WebRTC

في Voximplant ، نستخدم WebRTC منذ إنشائه: أولاً كبديل لـ Flash لمكالمات الصوت والفيديو ، ثم كبديل كامل. لقد وصلت التكنولوجيا إلى مسار طويل ومؤلم للتطوير ، ومؤخراً فقط بدأت جميع المتصفحات الرئيسية في دعمها ، وهناك صعوبات في نقل الشاشة ، والعديد من تدفقات الفيديو ، وأحيانًا يتعطل المتصفح ببساطة إذا قمت بإيقاف تشغيل الفيديو وتشغيله. تتيح لنا التجربة المتراكمة ترجمة مقالات مثيرة للاهتمام لـ Habr ، واليوم ننقل الكلمة إلى Lee Sylvester من Xirsys ، الذي سيتحدث عن تصحيح أخطاء مكالمات (الفيديو) في Chrome و Firefox و Safari و Edge. تصحيح WebRTC ليس سهلاً ، بل لدينا تعليمات خاصة لإزالة السجلات في المتصفحات الشائعة. وما لدى لي - ستكتشف تحت القطع (المفسد: الكثير من كل شيء ، بما في ذلك WireShark).

الجانب المظلم من WebRTC

أثناء العمل في Xirsys ، رأيت بعض التطبيقات الرائعة التي تستخدم WebRTC. ولكن بينما تقوم مجموعة صغيرة من المطورين بإنشاء أشياء عالية التقنية ، فإن معظم المبرمجين لا يمكنهم حتى البدء في استخدام WebRTC. لماذا؟ وكل شيء بسيط. إنه معقد.

الكثير منا على دراية بتطبيق ويب نموذجي. مثل هذا التطبيق لديه عميل يرسل الطلبات وخادم يستجيب لهذه الطلبات. عملية بسيطة وخطية ويمكن التنبؤ بها بسهولة. إذا حدث خطأ ما ، فإننا عادة ما نعرف أين ننظر إلى السجلات وما يمكن أن يحدث. ولكن مع WebRTC ، كل شيء ليس بهذه البساطة.

عدم التزامن

إذا كنت قد كتبت تطبيقًا متعدد الخيوط ، فمن المحتمل أنك تعرف عن الصداع الذي يحدثه هذا التطوير. الرحلات الجوية والذاكرة السيئة - ولكن غالبًا ما تكون مجرد أخطاء يصعب العثور عليها.

WebRTC غير متزامن في الطبيعة. وهذا ليس تزامن AJAX البسيط على الإطلاق. لرسم التناظر ، هناك العديد من طلبات AJAX التي تم إطلاقها في وقت واحد والتي تحاول التوفيق بين البيانات على جهازي كمبيوتر. هذا لا يزال الترفيه.

NAT تجاوز حقل الألغام

يأتي إنشاء تطبيقات الويب لتطوير شيء يعمل على الخادم ويستجيب للطلبات. أسوأ شيء يمكن أن يحدث هو المنفذ غير المفتوح في IPTables. يتم علاجها في دقيقتين. لا يمكنك القول عن WebRTC.

خوادم الويب ، ولا حتى برامجها ، ولكن الأجهزة ، هي أجهزة ذات عناوين IP عامة. إنها مصنوعة لتكون متاحة من أي مكان. ويتم WebRTC لإرسال واستقبال البيانات من أجهزة كمبيوتر المستخدمين. والتي عادة ما يكون لها عنوان IP 192.168. شيء ولا يحترق برغبة في الاستجابة لطلبات الشبكة.

يعرف مؤلفو WebRTC عن هذا الأمر ، لذلك سيقوم المحرك بالفرز عبر طرق اتصال مختلفة ، في محاولة لإنشاء اتصال بين جهازي كمبيوتر لم يتم تصميمهما بشكل كبير لهذا الغرض.

من أين تبدأ التصحيح

في هذه المقالة أتحدث عن الأدوات الأساسية لحل المشاكل الأكثر شعبية. ولكن قبل ذلك ، دعنا نرى كيف يقوم WebRTC عادةً بإنشاء اتصال.

كيف ينشئ WebRTC الاتصال

تتطلب جميع اتصالات WebRTC القليل من المساعدة من بروتوكول التشوير. "القليل من المساعدة" هو خادمك والبروتوكول الخاص بك اللذين سيتمكن المتصل من خلالهما من الاتصال بالشخص الذي يتصل به قبل إنشاء اتصال نظير إلى نظير.

سيستخدم WebRTC بروتوكول التشوير لنقل المعلومات حول عناوين IP ، والقدرة على التقاط وتشغيل الصوت والفيديو ، وطبولوجيا الشبكة ، والبيانات المنقولة.

البروتوكول الشائع الاستخدام هو COMET (أو SIP - ملاحظة المترجم) ومآخذ الويب. لا يقتصر WebRTC على المطورين لأي شيء ، لذلك يمكنك استخدام ما تريد ، على الأقل نقل البيانات من خلال المفكرة ولصق النسخ (يتم ذلك في إحدى ورش العمل ، يعمل - مرة أخرى مترجم). يسمح لك التشوير المتصل بجهازي الكمبيوتر ببدء اتصال بالفعل عبر WebRTC.

العرض والإجابة

تستخدم اتصالات WebRTC "عرض" و "إجابة":

1. بادئ الاتصال يخلق ويمر إلى "عرض" الجانب الآخر.
2. يتلقى الطرف الآخر "عرضًا" ، ويخلق "استجابة" ويمررها مرة أخرى.
3. يتلقى البادئ الاتصال "إجابة".

هذا من الناحية النظرية. من الناحية العملية ، لا يبدو تبادل المجاملات بهذه البساطة.

1. قبل إرسال "العرض" ، يقوم بادئ الاتصال بإنشاء مثيل من RTCPeerConnection ويتلقى منه حزمة النص "SDP" (بروتوكول وصف الجلسة) باستخدام rtcPeerConnection.createOffer () ؛ تصف هذه الحزمة القدرة على استقبال / نقل الصوت والفيديو للمتصفح.
2. يتم تعيين محتويات حزمة SDP على أنها "وصف للجانب المحلي من الاتصال" باستخدام rtcPeerConnection.setLocalDescription () .
3. يتم إرسال الحزمة إلى الجانب الآخر ، حيث يتم تعيين محتوياتها على أنها "وصف الجانب الآخر من الاتصال" باستخدام rtcPeerConnection.setRemoteDescription () .
4. على الجانب الآخر من الاتصال ، يتم إنشاء حزمة SDP الخاصة به باستخدام rtcPeerConnection.createAnswer () ، ويتم تعيين محتوياتها على أنها "وصف للجانب المحلي من الاتصال".
5. يتم تمرير الحزمة إلى بادئ الاتصال ، الذي يقوم بتعيين محتوياتها على أنها "وصف للجانب الآخر من الاتصال".

وفقط بعد كل الإجراءات ، يعرف الطرفان المتصلان قدرات بعضهما البعض لاستقبال وإرسال الصوت / الفيديو.

المرشحين ICE

لكن القدرة على العمل مع وسائل الإعلام ليست كافية. بعد كل شيء ، لم تقل الأطراف المتعاقدة بعد أي شيء عن حالة الشبكة.

يمكنك معرفة برامج ترميز الفيديو التي يدعمها المتصفح وما إذا كانت هناك كاميرا على الكمبيوتر المحمول على الفور تقريبًا. يستغرق الأمر وقتًا لمعرفة عنوان IP الخارجي ومنطق عملية NAT ، ويتم تبادل المعلومات حول حالة الشبكة عند تلقي هذه المعلومات.

بفضل تقنية Trickle ICE (غير مدعومة من جميع المتصفحات - ملاحظة المترجم) ، يمكن تأسيس الاتصال بين جهازي WebRTC في أي وقت - بمجرد العثور على "مرشح" مناسب.

يجب على المطور الاشتراك في حدث onicecandidate (جميع الأحرف الصغيرة!) وتمرير حزم SDP المستلمة إلى الجانب الآخر ، حيث يلزم إرسالها بواسطة WebRTC باستخدام طريقة addIceCandidate (وهنا ، المفاجأة ، الحرف الكبير). يعمل في كلا الاتجاهين.

اتصال

يستخدم WebRTC أشياء مثل STUN (جلسة عمل الأدوات المساعدة لـ NAT) و TURN (الاجتياز باستخدام الترحيل حول NAT) لإنشاء اتصال. يبدو الأمر مخيفًا ، ولكن في الواقع لا يوجد سوى بروتوكولين للشبكة.

خادم STUN

يعد أول بروتوكولين أكثر تعقيدًا من خادم الصدى. عند توصيل المشاركين يريدون وصف كيفية الاتصال بهم ، فإنهم بحاجة إلى عنوان IP العام الخاص بهم. وعلى الأرجح لن يكون عنوان IP الخاص بالكمبيوتر ، نادرًا ما يتم تخصيص الأجهزة العامة لأجهزة المستخدم. تم اختراع تقنية NAT بالكامل حتى لا يتم عزلها. للاستمرار في معرفة عنوانك العام ، يقوم المتصفح بتقديم طلب إلى خادم STUN. عند المرور عبر NAT ، تقوم حزمة الشبكة بتغيير عنوان الإرجاع الخاص بها إلى الجمهور. بعد استلام الحزمة مع الطلب ، يقوم خادم STUN بنسخ عنوان الإرجاع الخاص بالحزمة إلى حمولتها وإرسالها مرة أخرى. بالمرور عبر NAT في الاتجاه المعاكس ، تفقد الحزمة عنوان IP العام الخاص بها ، ولكن تظل نسخة من هذا العنوان في الحمولة ، حيث يمكن لـ WebRTC قراءتها.

قم بتشغيل الخادم

يستخدم خادم TURN ملحق بروتوكول STUN. نفس الحزم ، الرؤوس ، بالإضافة إلى شيء جديد: الأمر . الخادم وكيل: يتصل كلا العملاء به من خلال منفذ تخصيص UDP وينقلون بياناتهم عبر الخادم.

تم تصميم خوادم TURN بحيث يكون لبادئ الاتصال ميزات أكثر من الجانب الآخر. يؤدي هذا إلى تأثير مثير للاهتمام عندما تكون المكالمة من خلال خادم TURN ناجحة أو غير ناجحة ، اعتمادًا على من يتصل بمن (يتذكر كل مترجم Skype - note).

تصحيح الأخطاء

لذا ، قرأت حتى هذه الفقرة. نحن سعداء بالمترجم ونتذكر أن المقالة تدور حول تصحيح أخطاء WebRTC. لكن كل ما سبق هو الحد الأدنى الضروري ، والذي بدونه لا يمكنك حتى البدء. ولكن إذا بدأت ، ولم يكن لديك حظ غير إنساني ، فسوف ينكسر.

سوف ينكسر بعدة طرق مختلفة. الأول هو نقص الاتصال. لقد مررت كلاً من إعدادات خادم STUN و TURN إلى كل من WebRTCs ، وساعدتهم على تبادل العروض والإجابات ومرشحي ICE ، ولكن لا يوجد فيديو أو صوت. من أين تبدأ؟ مع مشاكل التشغيل المحلية.

تصحيح أخطاء WebRTC المحلي

كما كتبت أعلاه ، فإن العمل الرئيسي لـ WebRTC يحدث على جانب المتصفح. خوادم STUN و TURN بسيطة للغاية ، لذلك تحدث معظم المشاكل في شفرة JavaScript الخاصة بك ، والتي تعمل في مستعرضين. حزين ولكنه حقيقي. من ناحية أخرى ، إذا حدث الشيء الأكثر إثارة للاهتمام محليًا في المتصفحات ، فستكون لديك فرصة كبيرة لتصحيح الأخطاء!

أول شيء يجب التحقق منه هو إشاراتك. هو رمزك الذي ينقل تكوين الصوت مع الفيديو (عرض ، إجابة) ومعلومات حول إعدادات الشبكة (مرشحات الجليد) بين المتصفحات. تحتاج إلى التحقق من الحزم التي تم إرسالها واستلامها وإرسالها WebRTC:

• تلقى الجانب الآخر من الاتصال عرضا؟ هل تلقى بادئ الاتصال ردًا؟ لن يتم إنشاء اتصال دون هذا الحد الأدنى من تبادل المرافق ؛
• هل مرر WebRTC عند طرفي الاتصال الحزم مع مرشحي ICE؟ هل استبدلت هذه الحزم ومررتها إلى الجانب الآخر باستخدام addIceCandidate ؟
• إذا كان كل شيء يسير على ما يرام مع تبادل الحزم ، فهل تم استدعاء معالج حدث onaddstream وهل قمت بتثبيت الكائن الناتج في عنصر HTML لتشغيل الفيديو (أو الصوت)؟

إذا لم يكن تبادل الحزم مريبًا ، فيمكنك الخوض في شجاعة الجلسة.

بروتوكول وصف الجلسة

يتم إنشاء حزم العروض والردود والمرشح ICE بواسطة WebRTC بتنسيق نص SDP. للوهلة الأولى ، تبدو محتويات الحزم مخيفة ، ولكن مع القليل من التحضير ، يمكنك الحصول على الكثير من الاستفادة منها أثناء تصحيح الأخطاء. تصف ويكيبيديا SDP جيدًا ، لكني وجدت وصفًا أفضل لك.

يعد الحقل أهم حقل في حزم ICE SDP المرشحة. بالنسبة إلى WebRTC ، يمكن أن يحتوي الحقل على إحدى القيم الثلاث:

• مضيف الطباع
• اكتب srflx ؛
• تتابع الكتابة.

اكتب مضيف

يحدد نوع المضيف مرشح ICE لاتصال محلي (يعدد WebRTC العديد من المرشحين على أمل إنشاء اتصال ، ولا يُعرف مقدمًا أيهما سيظهر - ملاحظة من المترجم). لا يتطلب مثل هذا الاتصال إما STUN أو خادم TURN ، حيث يمكن للأجهزة في الشبكة المحلية إنشاء اتصالات الشبكة مباشرة. عند تصحيح الأخطاء من الشبكة المحلية ، ما عليك سوى التحقق من إرسال حزم المضيف وتصحيحها والتأكد من أن الأجهزة يمكنها إرسال حزم UDP إلى بعضها البعض. على الرغم من وجود استثناءات ، فقد رأيت عمليًا تكوينات الشبكة التي يحتاج فيها المتصفح إلى خادم TURN للاتصال ... بنفسه.

اكتب srflx

مزيج الأحرف "srflx" يرمز إلى "خادم انعكاسي" ويمثل مرشحي الاتصال باستخدام عنوان IP خارجي ، حيث يكون خادم STUN كافياً للاتصال (باستخدام تقنية اختراق NAT ، والتي تنجح في حوالي 80٪ من الحالات ، لاحظ المترجم).

تتابع الكتابة

يشير "Relay" إلى الاتصال من خلال خادم TURN ، والذي يكون دائمًا ناجحًا تقريبًا. من المهم أن تتذكر أن WebRTC غير مطلوب لإنشاء ثلاث حزم مختلفة تمامًا مع حقل "النوع" ؛ تعتمد كيفية اختيار المرشحين على تطبيق WebRTC في إصدار متصفح معين.

اختبار اتصال الجهاز

تقدم Google تطبيق ويب مخصصًا لاختبار اتصالات WebRTC على جهازك. افتح الصفحة وانقر على زر "ابدأ" وسيحاول رمز جافا سكريبت إنشاء اتصال بخادم Google باستخدام الإشارات وخوادم STUN و TURN من Google.

WebRTC الداخلية

لقد قمت بفحص جميع الحزم ، والتحقق من الرمز ، كل شيء يبدو على ما يرام ، لكنه لا يعمل؟ لمثل هذه الحالات ، زودت Google متصفح Chrome بقسم خاص يعرض الأجزاء الداخلية لـ WebRTC أثناء إعداد الاتصال وبعض الرسوم البيانية الجميلة في حالة نجاح الاتصال. للاستخدام ، افتح رابطًا فنيًا خاصًا في المتصفح:

chrome://webrtc-internals

إذا كان لديك بالفعل تطبيق يستخدم WebRTC مفتوحًا ، فسترى على الفور مجموعة من البيانات الفنية. خلاف ذلك ، ما عليك سوى فتح علامة تبويب أخرى وهناك شيء يستخدم WebRTC. تعرض علامة التبويب جميع المكالمات إلى كائن RTCPeerConnection وتسمح لك برؤية كيفية إنشاء الاتصال في الوقت الفعلي.

إعداد ICE

في الجزء العلوي من الصفحة توجد سلسلة ICE التي تم استخدامها لتهيئة الاتصال. إذا حدث خطأ أثناء تكوينه ، فسيكون هذا مرئيًا على الفور (بواسطة "سطر ICE" يشير المؤلف إلى تكوين كائن RTCPeerConnection بقائمة من خوادم STUN و TURN (كائن 'iceServers') - ملاحظة من المترجم). ربما لا توجد قائمة بالخوادم؟ يجب عليك تكوين كائن RTCPeerConnection قبل إجراء المكالمة الأولى لإنشاء createOffer أو createAnswer .

أحداث RTCPeerConnection

يعرض القسم الداخلي التالي المكالمات إلى طرق RTCPeerConnection والأحداث المستلمة من الكائن بترتيب زمني. يتم تمييز الأخطاء بعناية باللون الأحمر. يرجى ملاحظة أن addIceCandidateFailed الأحمر ليس في الغالب علامة على وجود خطأ وقد يتم إنشاء الاتصال بشكل طبيعي. إذا كان الاتصال ناجحًا ، فسيكون الحدث الأخير في القائمة عبارة عن حدث iceconnectionstatechange بقيمة كاملة .

القسم "إحصائيات"

القسم التالي ذو صلة عندما يتم تأسيس الاتصال بنجاح. أنه يحتوي على إحصاءات البيانات المرسلة وتأخير الشبكة. الخياران الأكثر إثارة للاهتمام هما: ssrc و bweforvideo .

• ssrc ، "مصدر البث" ، يميز كل من مساراتك الصوتية والمرئية. يعرض إحصائيات البيانات والمعلمات المرسلة مثل وقت الذهاب والإياب ؛
• يعرض bweforvideo ، BandWidth Estimate عرض قناة الشبكة المستخدمة.

دالة GetStats

في كثير من الأحيان لن تتمكن من الوصول إلى الصفحة الداخلية. على سبيل المثال ، عندما تحدث مشكلة مع المستخدم الخاص بك. في هذه الحالة ، يمكنك الحصول على نفس البيانات التي تظهرها الصفحة الداخلية عن طريق استدعاء طريقة getStats على كائن RTCPeerConnection . تعمل هذه الطريقة على إعداد وظيفة رد الاتصال التي سيتصل بها WebRTC في كل مرة يحدث فيها شيء مثير للاهتمام. تحصل الوظيفة المطلوبة على كائن يحتوي على الحقول التي تعرضها الصفحة الداخلية:

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

أداة أخرى مفيدة هي حدث oniceconnectionstatechange لكائن RTCPeerConnection . سيتلقى معالج الأحداث معلومات تقدم الاتصال. الخيارات الممكنة:

• جديد : يتوقع WebRTC مرشحين من الجانب الثاني من الاتصال ، ويجب إضافتهم باستخدام طريقة addIceCandidate ؛
• التحقق : تلقى WebRTC مرشحين من الجانب الثاني من الاتصال ، ويقارنهم بالمرشحين المحليين ويكرروا الخيارات ؛
• متصل : يتم اختيار زوج مناسب من المرشحين ويتم تأسيس الاتصال. يشار إلى أنه بعد ذلك ، يمكن للمرشحين الاستمرار في القدوم ، وفقًا لبروتوكول Trickle ICE ؛
• اكتمل : تم استلام جميع المرشحين وإقامة الاتصال.
• غير متصل : تم قطع الاتصال . على القنوات غير المستقرة WebRTC قادر على إعادة توصيل نفسه ، نراقب العلم المتصل ؛
• مغلق : تم قطع الاتصال ولم يعد WebRTC يعمل معه.

إذا انتهى الاتصال في الحالة الفاشلة ، فيمكننا فحص المرشحين المستقبلين من كلا الجانبين وفهم سبب فشل الاتصال. على سبيل المثال ، إذا قدم أحد الجانبين مرشحين للمضيف و srflx ، فإن المضيف الآخر والمرحل ، ولكن الأجهزة كانت على شبكات مختلفة.

مستطيل أسود بدلاً من الفيديو

غالبًا ما يكون هناك موقف عند إنشاء الاتصال ، يتم إرسال الصوت ، ولكن بدلاً من الفيديو ، يكون لدى أحد المشاركين أو كليهما مستطيل أسود. يحدث هذا غالبًا إذا قمت بتعيين كائن الفيديو المستلم إلى عنصر HTML قبل أن ينتقل الاتصال إلى الحالة المكتملة .

كيفية كزة عصا في الخارج

بالإضافة إلى كائن RTCPeerConnection نفسه والأجزاء الداخلية التي يعرضها المستعرض ، يمكنك استخدام أدوات تحليل حزم الشبكة مثل Wireshark. يمكن لهذه الأدوات عرض حزم بروتوكولات WebRTC المستخدمة. على سبيل المثال ، سيعرض لك Wireshark محتويات حزم STUN في النافذة الرئيسية ، ويمكنك تصفيتها عن طريق كتابة الكلمة الأساسية "stun" في حقل الفلتر:


ما الذي يجب النظر إليه في استجابات الخادم؟ إذا رأيت إجابات من نوع Binding فقط ، فهذا يعني أنه يتم دعم STUN (نقاش IP الخارجي) فقط ، ويمكن لـ WebRTC تقديم مرشحي srflx فقط. إذا كانت الإجابات تحتوي على حزم مخصصة لـ TURN تخصيص و CreatePermission ، فستتاح الفرصة لـ WebRTC لمحاولة الاتصال عبر خادم وكيل. يشير محلل الحزمة إلى تخصيص ناجح وغير ناجح. إذا لم يكن هناك واحد ناجح ، فمن المرجح أن يتم تمرير معلمات الوصول الخاطئة إلى خوادم TURN (التي تحمي دائمًا باسم المستخدم وكلمة المرور - ملاحظة المترجم).

إذا كان هناك حزمة استجابة نجاح CreatePermission في السجل ، يمكننا أن نفترض أن كل شيء على ما يرام مع تكوينات STUN و TURN. وإذا كان هناك أيضًا حزمة ChannelBind ، فقد كان من الممكن إنشاء اتصال بخادم TURN بسرعة عالية.

القضايا الخلوية

في ممارستي ، لا يمكن للعديد من حلول WebRTC التي تنشئ اتصال WiFi الاتصال عبر 3G / 4G. من الصعب تصحيح التطبيق الذي يتم تشغيله على جهاز محمول: ليس لدينا محلل حزم بسيط مثل Wireshark ، ولا يمكن لـ Safari إظهار WebRTC الداخلية. يقترح المنطق أنه إذا كان التطبيق يعمل بشكل جيد عبر WiFi ، فإن المشكلة ليست في التطبيق نفسه ، ولكن في الاتصال الخلوي. كيفية التصحيح؟ اصطحب جهاز كمبيوتر محمول وقم بتوصيل جهاز 3G به. لذلك لديك محلل حزم وسجلات ملائمة يمكنك من خلالها العثور على جذر جميع المشاكل في وقت معقول.

الاستنتاجات

تصحيح WebRTC ليس سهلاً ، ولكن إذا كنت تبحث جيدًا على الإنترنت ، فيمكنك العثور على العديد من المقالات والأمثلة. إذا كنت تعمل في مجال الاتصالات في الوقت الفعلي ، فأوصيك بقراءة مواصفات RFC لبروتوكولات STUN و TURN وتقنية WebRTC . المستندات كبيرة ، ولكن المعلومات الواردة فيها تساعد على اتخاذ قرارات موثوقة والإجابة على السؤال "لماذا لا يرن".