WebRTC. مؤتمرات الفيديو في المتصفح. دردشة متعددة المستخدمين باستخدام WebRTC Webrtc الدردشة الصوتية

الديباجة. تشغيل دردشة الفيديو P2P قاعدة ويب آر تي سيهو بديل لبرنامج Skype ووسائل الاتصال الأخرى. العناصر الرئيسية للدردشة المرئية p2p المستندة إلى WebRTC هي المتصفح وخادم الاتصال. محادثات الفيديو P2P هي محادثات فيديو نظير إلى نظير حيث لا يشارك الخادم في نقل تدفقات المعلومات. يتم نقل المعلومات مباشرة بين متصفحات المستخدمين (الأقران) دون أي برامج إضافية. بالإضافة إلى المتصفحات، تستخدم محادثات الفيديو P2P خوادم الاتصال، والتي تم تصميمها لتسجيل المستخدمين وتخزين البيانات المتعلقة بهم وضمان التبديل بين المستخدمين. توفر المتصفحات التي تدعم أحدث تقنيات WebRTC وHTML5 رسائل نصية فورية ونقل الملفات، بالإضافة إلى اتصالات الصوت والفيديو عبر شبكات IP.

لذلك، فإن الدردشات ومحادثات الويب والمحادثات الصوتية والمرئية في واجهة الويب وIMS وVoIP هي خدمات توفر اتصالات عبر الإنترنت من خلال شبكات تبديل الحزم المركبة. كقاعدة عامة، تتطلب خدمات الاتصالات إما تثبيت تطبيقات العميل على أجهزة المستخدم (أجهزة الكمبيوتر والهواتف الذكية وما إلى ذلك) أو تثبيت المكونات الإضافية والإضافات في المتصفحات. تتمتع الخدمات بشبكات اتصالات خاصة بها، ومعظمها مبني على بنية خادم العميل.

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

مشكلة تكامل خدمات الاتصال في الوقت الحقيقي (الدردشة، الهاتف، مؤتمرات الفيديو)، أي. يمكن حل تكامل قنوات الصوت والفيديو والبيانات والوصول إليها باستخدام تطبيق واحد (متصفح) في محادثات فيديو نظير إلى نظير أو p2p (نظير إلى نظير ومن نقطة إلى نقطة) استنادًا إلى بروتوكول WebRTC. بشكل أساسي، يصبح المتصفح الذي يدعم WebRTC واجهة واحدة لجميع أجهزة المستخدم (أجهزة الكمبيوتر والهواتف الذكية وأجهزة iPad وهواتف IP، الهواتف المحمولةالخ) التي تعمل مع خدمات الاتصالات.

إن WebRTC هو الذي يضمن تنفيذ جميع التقنيات في المتصفح التي توفر اتصالات في الوقت الفعلي. جوهر محادثات الفيديو P2P هو أن الوسائط المتعددة والبيانات النصية يتم نقلها مباشرة بين متصفحات المستخدمين (التناظر عن بعد) دون مشاركة خادم أو برامج إضافية. وبالتالي، فإن المتصفحات لا توفر الوصول إلى الجميع تقريبًا فحسب مصادر المعلوماتالإنترنت، التي يتم تخزينها على الخوادم، ولكنها تصبح أيضًا وسيلة للوصول إلى جميع خدمات الاتصال في الوقت الفعلي وخدمات البريد (البريد الصوتي، بريد إلكتروني، الرسائل القصيرة، الخ.)

الخوادم (خوادم جهات الاتصال) لمحادثات الفيديو p2p مخصصة فقط لتسجيل المستخدمين وتخزين البيانات حول المستخدمين وإنشاء اتصال (تبديل) بين متصفحات المستخدمين. تم تنفيذ أول محادثات فيديو P2P باستخدام تقنيات الفلاش. تُستخدم محادثات الفيديو Flash p2p، على سبيل المثال، في في الشبكات الاجتماعية. لا يتم توفير محادثات فيديو فلاش p2p جودة عاليةنقل بيانات الوسائط المتعددة. بالإضافة إلى ذلك، لإخراج دفق الصوت والفيديو من الميكروفون وكاميرا الفيديو في محادثات فيديو فلاش p2p، تحتاج إلى تثبيت البرنامج المساعد فلاشفي متصفح الويب.

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

لذلك، فإن التكنولوجيا الجديدة لاتصالات الويب (محادثات P2P، ومحادثات الفيديو) هي بروتوكول WebRTC. يتيح لك WebRTC مع HTML5 وCSS3 وJavaScript إنشاء تطبيقات ويب متنوعة. تم تصميم WebRT لتنظيم اتصالات الويب (شبكات نظير إلى نظير) في الوقت الفعلي باستخدام بنية نظير إلى نظير. توفر محادثات P2P المستندة إلى WebRTC نقل الملفات، بالإضافة إلى التواصل النصي والصوت والفيديو بين المستخدمين عبر الإنترنت باستخدام متصفحات الويب فقط دون استخدام الوظائف الإضافية والمكونات الإضافية الخارجية في المتصفح.

في محادثات P2P، يتم استخدام الخادم فقط لتأسيس اتصال P2P بين متصفحين. لإنشاء جزء العميل من دردشة p2p استنادًا إلى بروتوكول WebRTC، يتم استخدام HTML5 وCSS3 وJavaScript. يتفاعل تطبيق العميل مع المتصفحات عبر WebRTC API.

يتم تنفيذ WebRTC من خلال ثلاث واجهات برمجة تطبيقات JavaScript:

• RTCPeerConnection;
• MediaStream(getUserMedia);
• RTCDataChannel.

تنقل المتصفحات بيانات الوسائط باستخدام بروتوكول SRTP، الذي يعمل أعلى UDP. نظرًا لأن NAT تخلق مشكلات للمتصفحات (العملاء) خلف أجهزة توجيه NAT التي تستخدم اتصالات p2p عبر الإنترنت، يتم استخدام STUN لتجاوز مترجمي NAT. STUN هو بروتوكول خادم عميل يعمل فوق بروتوكول النقل UDP. في محادثات P2P، كقاعدة عامة، يتم استخدام خادم STUN عام، ويتم استخدام المعلومات الواردة منه لاتصال UDP بين متصفحين إذا كانا خلف NAT.

أمثلة على تنفيذ تطبيقات WebRTC (محادثات p2p، ومحادثات الويب الصوتية والمرئية):
1. يمكن فتح دردشة فيديو P2P Bistri (دردشة فيديو بنقرة واحدة، دردشة p2p)، استنادًا إلى WebRTC، على Bistri. يعمل Bistri في المتصفح دون تثبيت برامج ومكونات إضافية. جوهر العمل هو كما يلي: افتح دردشة فيديو P2P باستخدام الرابط المحدد، بعد التسجيل في الواجهة التي تفتح، قم بدعوة الشركاء، ثم من قائمة العملاء الأقران حدد الشريك المتصل وانقر على "مكالمة الفيديو" " زر.

ونتيجة لذلك، سيقوم MediaStream (getUserMedia) بالتقاط الميكروفون + كاميرا الويب، وسيقوم الخادم بتبادل رسائل الإشارة مع الشريك المحدد. بعد تبادل رسائل الإشارة، تقوم واجهة PeerConnection API بإنشاء قنوات لنقل تدفقات الصوت والفيديو. بالإضافة إلى ذلك، يقوم Bistri بنقل الرسائل النصية والملفات الفورية. في التين. يعرض الشكل 1 لقطة شاشة لواجهة دردشة الفيديو Bistri p2p.

أرز. 1. دردشة فيديو P2P Bistri

2. Twelephone (دردشة فيديو p2p، دردشة p2p، SIP Twelephone) - تم إنشاء تطبيق العميل هذا على أساس HTML5 وWebRTC، والذي يسمح لك بإجراء مكالمات صوتية ومرئية، بالإضافة إلى إرسال رسائل نصية فورية، أي. يتضمن Twelephone اختبار دردشة p2p ودردشة الفيديو وSIP Twelephone. تجدر الإشارة إلى أن Twelephone يدعم بروتوكول SIP ويمكنك الآن إجراء واستقبال مكالمات الصوت والفيديو من هواتف SIP باستخدام حساب Twitter الخاص بك كرقم هاتف. بجانب، رسائل نصيةيمكنك الدخول عن طريق الصوت من خلال الميكروفون، ويقوم برنامج التعرف على الصوت بإدخال النص الموجود في سطر "إرسال رسالة".

Twelephone هي خدمة هاتفية عبر الويب تعتمد على المتصفح جوجل كرومابتداءً من الإصدار 25 بدون إضافة برمجة. تم تطوير Twelephone بواسطة كريس ماتيو. تم بناء الواجهة الخلفية لـ Twelephone على Node.js. يتم استخدام الخادم (خادم جهة الاتصال) فقط لتأسيس اتصال p2p بين متصفحين أو عملاء WebRTC. لا يحتوي تطبيق Twelephone على أدوات ترخيص خاصة به، ولكنه يركز على الاتصال بالحساب ( حساب) على تويتر.

في التين. 2 يعرض لقطة شاشة لواجهة دردشة الفيديو Twelephone p2p.

أرز. 2. هاتف P2P

3. دردشة الفيديو الجماعية p2p Conversat.io مبنية على أحدث تقنيات WebRTC وHTML5. تم تطوير دردشة الفيديو Conversat استنادًا إلى مكتبة SimpleWebRTC وهي مخصصة للتواصل بين ما يصل إلى 6 عملاء أقران في غرفة واحدة (للاتصال، حدد اسم الغرفة المشتركة للعملاء الأقران في سطر "تسمية المحادثة"). توفر محادثة الفيديو P2P Conversat خدمات الاتصال للمستخدمين دون التسجيل على خادم الاتصال. في التين. يوضح الشكل 3 لقطة شاشة لواجهة الدردشة المرئية Conversat p2p.

أرز. 3. دردشة فيديو جماعية P2P Conversat.io

للمشاركة في محادثات فيديو P2P استنادًا إلى WebRTC، يجب أن يكون لدى المستخدمين متصفح مثبت يدعم بروتوكول WebRTC ومواصفات HTML5. حاليًا، متصفحات Google Chrome، بدءًا من الإصدار 25، و موزيلا فايرفوكسيدعم Nightly بروتوكول WebRTC ومواصفات HTML5. تتفوق تطبيقات WebRTC على تطبيقات Flash من حيث جودة نقل الصورة والصوت.

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

مقدمة ويب آر تي سي

WebRTC هي تقنية موجهة نحو المتصفح تتيح لك توصيل عميلين لنقل بيانات الفيديو. الميزات الرئيسية هي الدعم الداخلي للمتصفحات (ليست هناك حاجة لتقنيات تنفذها جهات خارجية مثل Adobe Flash) والقدرة على توصيل العملاء دون استخدام خوادم إضافية - اتصال نظير إلى نظير (المشار إليه فيما بعد بـ p2p).

يعد إنشاء اتصال P2P مهمة صعبة إلى حد ما، حيث لا تحتوي أجهزة الكمبيوتر دائمًا على عناوين IP عامة، أي عناوين على الإنترنت. نظرًا للعدد الصغير من عناوين IPv4 (ولأغراض أمنية)، تم تطوير آلية NAT، والتي تتيح لك إنشاء شبكات خاصة، على سبيل المثال، للاستخدام المنزلي. تدعم العديد من أجهزة التوجيه المنزلية الآن NAT، وبفضل هذا، تتمتع جميع الأجهزة المنزلية بإمكانية الوصول إلى الإنترنت، على الرغم من أن موفري الإنترنت يقدمون عادةً عنوان IP واحدًا. تعتبر عناوين IP العامة فريدة من نوعها على الإنترنت، ولكن العناوين الخاصة ليست كذلك. ولذلك، ربط p2p أمر صعب.

لفهم ذلك بشكل أفضل، فكر في ثلاث حالات: كلتا العقدتين على نفس الشبكة (الشكل 1)، وكلتا العقدتين على شبكتين مختلفتين (واحدة خاصة والأخرى عامة) (الشكل 2) وكلا العقدتين في شبكات خاصة مختلفة مع نفس عناوين IP (الشكل 3).

الشكل 1: كلا العقدتين على نفس الشبكة

الشكل 2: العقد في شبكات مختلفة (واحدة خاصة وواحدة عامة)

الشكل 3: العقد في شبكات خاصة مختلفة، ولكن بعناوين متساوية عدديًا

في الأشكال أعلاه، يشير الحرف الأول في التدوين المكون من حرفين إلى نوع العقدة (p = النظير، r = جهاز التوجيه). في الصورة الأولى، الوضع مناسب: يتم تحديد العقد الموجودة في شبكتها بالكامل من خلال عناوين IP الخاصة بالشبكة، وبالتالي يمكنها الاتصال ببعضها البعض مباشرة. في الشكل الثاني لدينا شبكتان مختلفتان لهما أرقام عقد متشابهة. هذا هو المكان الذي تظهر فيه أجهزة التوجيه (أجهزة التوجيه)، والتي تحتوي على اثنين واجهة الشبكة- داخل شبكتك وخارج شبكتك. لهذا السبب لديهم عنوانين IP. تحتوي العقد العادية على واجهة واحدة فقط يمكنها التواصل من خلالها فقط داخل شبكتها. إذا قاموا بنقل البيانات إلى شخص ما خارج شبكتهم، فسيتم استخدام NAT فقط داخل جهاز التوجيه (جهاز التوجيه) وبالتالي يكون مرئيًا للآخرين تحت عنوان IP الخاص بجهاز التوجيه - فهو ملكهم خارجيعنوان IP. لذا فإن العقدة p1 موجودة الداخليةالملكية الفكرية = 192.168.0.200 و خارجيالملكية الفكرية = 10.50.200.5 وسيكون العنوان الأخير أيضًا خارجيًا لجميع العقد الأخرى في شبكته. الوضع مشابه للعقدة p2. ولذلك، فإن اتصالاتهم مستحيلة إذا تم استخدام عناوين IP الداخلية (الخاصة) الخاصة بهم فقط. يمكنك استخدام عناوين خارجية، أي عناوين جهاز التوجيه، ولكن نظرًا لأن جميع العقد الموجودة في نفس الشبكة الخاصة لها نفس العنوان الخارجي، فهذا أمر صعب للغاية. يمكن حل هذه المشكلة باستخدام آلية NAT

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

يتعامل WebRTC مع مثل هذه المشكلات بنجاح باستخدام بروتوكول ICE، والذي يتطلب، مع ذلك، استخدام خوادم إضافية (STUN، TURN). المزيد عن كل هذا أدناه.

مرحلتان من WebRTC

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

يستحق القول على الفور أنه على الرغم من أن تقنية WebRTC تستخدم الكثير بطرق متعددةالاتصالات (TCP وUDP) وتتمتع هذه التقنية بمرونة التبديل بينهما ليس لديه بروتوكول لنقل بيانات الاتصال. ليس من المستغرب، لأن ربط عقدتين P2P ليس بهذه السهولة. ولذلك فمن الضروري أن يكون بعض إضافيطريقة لنقل البيانات لا علاقة لها بأي شكل من الأشكال بـ WebRTC. يمكن أن يكون نقل مأخذ توصيل، أو بروتوكول HTTP، أو حتى بروتوكول SMTPأو البريد الروسي. آلية النقل هذه أولييتم استدعاء البيانات الإشارة. لا يلزم نقل الكثير من المعلومات. يتم إرسال جميع البيانات في شكل نص وتنقسم إلى نوعين - SDP و Ice Candidate. يُستخدم النوع الأول لإنشاء اتصال منطقي، والثاني للاتصال المادي. المزيد عن كل هذا لاحقًا، ولكن في الوقت الحالي من المهم فقط أن تتذكر أن WebRTC سيزودنا ببعض المعلومات التي يجب نقلها إلى عقدة أخرى. بمجرد أن نرسل جميع المعلومات الضرورية، ستكون العقد قادرة على الاتصال ولن تكون هناك حاجة لمساعدتنا بعد الآن. لذا فإن آلية الإشارة التي نحتاج إلى تنفيذها هي بشكل منفصل، سوف يستخدم فقط عند الاتصال، ولكن لن يتم استخدامها عند نقل بيانات الفيديو.

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

• البادئ (المتصل):
• عرض لبدء نقل بيانات الفيديو (createOffer)
• الحصول على SDP SDP الخاص بك)
• استقبال مرشح الجليد الخاص بك مرشح الجليد)
• انتظار المكالمات (المتصل):
• تلقي دفق الوسائط المحلي (الخاص بك) وإعداده للإرسال (getUserMediaStream)
• تلقي عرض لبدء نقل بيانات الفيديو وإنشاء إجابة (createAnswer)
• استلام كائن SDP الخاص به وتمريره عبر آلية الإشارة (SDP)
• استلام الأجسام المرشحة للجليد وتمريرها عبر آلية الإشارة (المرشح الجليدي)
• استقبال دفق وسائط عن بعد (أجنبي) وعرضه على الشاشة (onAddStream)

والفرق الوحيد هو في النقطة الثانية.

على الرغم من التعقيد الواضح للخطوات، إلا أن هناك في الواقع ثلاث خطوات: إرسال دفق الوسائط الخاص بك (البند 1)، وتعيين معلمات الاتصال (البنود 2-4)، واستقبال دفق الوسائط الخاص بشخص آخر (البند 5). وأصعب خطوة هي الخطوة الثانية، لأنها تتكون من جزأين: التأسيس بدنيو منطقيروابط. الأول يشير طريق، والتي يجب أن تنتقل عبرها الحزم للانتقال من عقدة شبكة إلى أخرى. ويشير الثاني معلمات الفيديو/الصوت- ما هي الجودة التي يجب استخدامها، وما هي برامج الترميز التي يجب استخدامها.

عقليًا، يجب أن تكون مرحلة createOffer أو createAnswer مرتبطة بمراحل تمرير كائنات SDP وIce المرشحة.

الكيانات الأساسية تدفقات الوسائط (MediaStream)

الكيان الرئيسي هو دفق الوسائط، أي دفق بيانات الفيديو والصوت والصورة والصوت. هناك نوعان من تدفقات الوسائط - المحلية والبعيدة. يستقبل الجهاز المحلي البيانات من أجهزة الإدخال (الكاميرا والميكروفون) والجهاز البعيد عبر الشبكة. وبالتالي، تحتوي كل عقدة على خيط محلي وخيط بعيد. في WebRTC، توجد واجهة MediaStream للتدفقات وهناك أيضًا واجهة فرعية LocalMediaStream مخصصة للبث المحلي. في JavaScript، يمكنك مواجهة الأول فقط، ولكن إذا كنت تستخدم libjingle، فيمكنك أيضًا مواجهة الثاني.

يحتوي WebRTC على تسلسل هرمي مربك إلى حد ما داخل سلسلة الرسائل. يمكن أن يتكون كل دفق من عدة مسارات وسائط (MediaTrack)، والتي بدورها يمكن أن تتكون من عدة قنوات وسائط (MediaChannel). وقد يكون هناك أيضًا العديد من تدفقات الوسائط نفسها.

دعونا ننظر إلى كل شيء بالترتيب. للقيام بذلك، دعونا نضع بعض الأمثلة في الاعتبار. لنفترض أننا نريد أن ننقل ليس فقط مقطع فيديو لأنفسنا، ولكن أيضًا مقطع فيديو لطاولتنا، حيث توجد قطعة من الورق سنكتب عليها شيئًا ما. سنحتاج إلى مقطعي فيديو (نحن + جدول) وصوت واحد (نحن). من الواضح أنه يجب تقسيمنا نحن والجدول إلى سلاسل مختلفة، لأن هذه البيانات ربما تعتمد بشكل ضعيف على بعضها البعض. لذلك، سيكون لدينا MediaStreams - واحد لنا والآخر للطاولة. سيحتوي الأول على بيانات الفيديو والصوت، وسيحتوي الثاني على فيديو فقط (الشكل 4).

الشكل 4: تياران مختلفان للوسائط. واحدة لنا، وواحدة لطاولتنا

من الواضح على الفور أن تدفق الوسائط يجب أن يتضمن على الأقل القدرة على احتواء البيانات أنواع مختلفة- الفيديو والصوت. يتم أخذ ذلك بعين الاعتبار في التكنولوجيا وبالتالي يتم تنفيذ كل نوع من البيانات من خلال مسار الوسائط MediaTrack. يحتوي مسار الوسائط على نوع خاصية خاص يحدد ما إذا كان فيديو أم صوتًا (الشكل 5)

الشكل 5: تتكون تدفقات الوسائط من مسارات الوسائط

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

ولكن كيف نميز تدفقات الوسائط على الطرف الآخر من الاتصال؟ للقيام بذلك، يحتوي كل دفق وسائط على خاصية تسمية - تسمية الدفق واسمه (الشكل 6). مسارات الوسائط لها نفس الخاصية. على الرغم من أنه يبدو للوهلة الأولى أنه يمكن تمييز الفيديو عن الصوت بطرق أخرى.

الشكل 6: يتم تحديد تدفقات الوسائط ومساراتها بواسطة التسميات

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

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

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

أخيرًا، يجدر التفكير في صوت الاستريو. كما تعلم، صوت الاستريو عبارة عن صوتين مختلفين. ويجب أيضًا نقلهم بشكل منفصل. يتم استخدام القنوات الإعلامية لهذا الغرض. يمكن أن يحتوي المسار الصوتي للوسائط على العديد من القنوات (على سبيل المثال، 6 إذا كنت بحاجة إلى صوت 5+1). هناك أيضًا قنوات داخل المسارات الإعلامية بالطبع. متزامن. بالنسبة للفيديو، عادةً ما يتم استخدام قناة واحدة فقط، ولكن يمكن استخدام عدة قنوات، على سبيل المثال، لتراكب الإعلانات.

كي تختصر:نستخدم دفق الوسائط لنقل بيانات الفيديو والصوت. تتم مزامنة البيانات داخل كل دفق وسائط. يمكننا استخدام تدفقات وسائط متعددة إذا لم نكن بحاجة إلى المزامنة. يوجد داخل كل دفق وسائط نوعان من مسارات الوسائط - للفيديو وللصوت. لا يوجد عادةً أكثر من مسارين، ولكن قد يكون هناك المزيد إذا كنت بحاجة إلى إرسال عدة مقاطع فيديو مختلفة (للمحاور وطاولته). يمكن أن يتكون كل مسار من عدة قنوات، والتي تُستخدم عادة لصوت الاستريو فقط.

في أبسط حالات الدردشة المرئية، سيكون لدينا تدفق وسائط محلي واحد، والذي سيتكون من مسارين - مسار فيديو ومسار صوتي، كل منهما سيتكون من قناة رئيسية واحدة. مسار الفيديو مسؤول عن الكاميرا، ومسار الصوت عن الميكروفون، وتدفق الوسائط هو الحاوية لكليهما.

واصف الجلسة (SDP)

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

يتم استخدام أي آلية إشارة لهذا الغرض. يمكن إرسال SDP إما عبر المقابس أو عن طريق شخص (إخباره بعقدة أخرى عبر الهاتف) أو عن طريق البريد الروسي. كل شيء بسيط للغاية - سيتم إعطاؤك بطاقة SDP جاهزة وسيتعين عليك إرسالها. وعند استلامها على الجانب الآخر قم بنقلها إلى قسم WebRTC. يتم تخزين واصف الجلسة كنص ويمكن تغييره في تطبيقاتك، لكن هذا ليس ضروريًا بشكل عام. على سبيل المثال، عند توصيل هاتف سطح المكتب ↔، تحتاج أحيانًا إلى فرض تحديد برنامج ترميز الصوت المطلوب.

عادةً، عند إنشاء اتصال، يجب عليك تحديد نوع ما من العناوين، مثل عنوان URL. هذا ليس ضروريًا هنا، لأنه من خلال آلية الإشارة ستقوم أنت بنفسك بإرسال البيانات إلى وجهتها. للإشارة إلى WebRTC بأننا نريد إنشاء اتصال p2p، نحتاج إلى استدعاء وظيفة createOffer. بعد استدعاء هذه الوظيفة وتحديد رد اتصال خاص، سيتم إنشاء كائن SDP وتمريره إلى نفس رد الاتصال. كل ما هو مطلوب منك هو نقل هذا الكائن عبر الشبكة إلى عقدة أخرى (محاور). بعد ذلك، ستصل البيانات إلى الطرف الآخر من خلال آلية الإشارة، أي كائن SDP هذا. واصف الجلسة هذا غريب على هذه العقدة وبالتالي يحمل معلومات مفيدة. يعد استلام هذا الكائن بمثابة إشارة لبدء الاتصال. لذلك، يجب عليك الموافقة على ذلك واستدعاء وظيفة createAnswer. إنه نظير كامل لـ createOffer. مرة أخرى، سيتم تمرير واصف الجلسة المحلية إلى رد الاتصال الخاص بك وسيلزم تمريره مرة أخرى من خلال آلية الإشارة.

تجدر الإشارة إلى أنه لا يمكنك استدعاء وظيفة createAnswer إلا بعد استلام كائن SDP الخاص بشخص آخر. لماذا؟ لأن كائن SDP المحلي الذي سيتم إنشاؤه عند استدعاء createAnswer يجب أن يعتمد على كائن SDP البعيد. في هذه الحالة فقط يمكن تنسيق إعدادات الفيديو الخاصة بك مع إعدادات محاورك. أيضًا، لا يجب عليك الاتصال بـ createAnswer وcreateOffer قبل تلقي دفق الوسائط المحلية - فلن يكون لديهم ما يكتبونه في كائن SDP.

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

بعد هذا المصافحاتتعرف العقد عن رغبات بعضها البعض. على سبيل المثال، إذا كانت العقدة 1 تدعم برنامجي الترميز A وB، وكانت العقدة 2 تدعم برنامجي الترميز B وC، فبما أن كل عقدة تعرف أوصافها الخاصة وواصفات العقدة الأخرى، فستختار كلا العقدتين برنامج الترميز B (الشكل 7). تم الآن إنشاء منطق الاتصال ويمكن إرسال تدفقات الوسائط، ولكن هناك مشكلة أخرى - لا تزال العقد متصلة فقط من خلال آلية الإشارة.

الشكل 7: تفاوض برنامج الترميز

مرشح الجليد

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

لذلك، تم إنشاء الاتصال بالفعل (الاتصال المنطقي)، ولكن لا يوجد حتى الآن مسار يمكن لعقد الشبكة من خلاله نقل البيانات. الأمر ليس بهذه البساطة، ولكن دعونا نبدأ ببساطة. دع العقد تكون على نفس الشبكة الخاصة. وكما نعلم بالفعل، يمكنهم الاتصال ببعضهم البعض بسهولة باستخدام عناوين IP الداخلية الخاصة بهم (أو ربما عناوين أخرى، إذا لم يتم استخدام TCP/IP).

من خلال بعض عمليات رد الاتصال، يخبرنا WebRTC بالكائنات المرشحة لـ Ice. كما أنها تأتي أيضًا في شكل نص، ومثل واصفات الجلسة، فهي تحتاج ببساطة إلى إرسالها من خلال آلية الإشارة. إذا كان واصف الجلسة يحتوي على معلومات حول إعداداتنا على مستوى الكاميرا والميكروفون، فإن المرشحين سيحتويون على معلومات حول موقعنا على الشبكة. قم بتمريرها إلى عقدة أخرى، وستكون قادرة على الاتصال بنا فعليًا، وبما أنها تحتوي بالفعل على واصف جلسة، فإنها ستكون قادرة منطقيًا على الاتصال وسوف "تتدفق" البيانات. إذا تذكر أن يرسل لنا كائنه المرشح، أي معلومات حول مكان وجوده على الشبكة، فسنكون قادرين على التواصل معه. دعونا نلاحظ هنا اختلافًا آخر عن التفاعل الكلاسيكي بين العميل والخادم. يتم الاتصال بخادم HTTP وفقًا لنظام الاستجابة للطلب، حيث يرسل العميل البيانات إلى الخادم الذي يقوم بمعالجتها وإرسالها عبر العنوان المحدد في حزمة الطلب. في WebRTC عليك أن تعرف عنوانينوربطها على كلا الجانبين.

يتمثل الاختلاف عن واصفات الجلسة في أنه يلزم تثبيت المرشحين البعيدين فقط. التحرير هنا محظور ولا يمكن أن يحقق أي فائدة. في بعض تطبيقات WebRTC، يلزم تثبيت المرشحين فقط بعد تعيين واصفات الجلسة.

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

لذلك، هناك عقدتان على نفس الشبكة (الشكل 8). كيفية التعرف عليهم؟ باستخدام عناوين IP. لا توجد طريقة أخرى. صحيح أنه لا يزال بإمكانك استخدام وسائل نقل مختلفة (TCP وUDP) ومنافذ مختلفة. هذه هي المعلومات الموجودة في الكائن المرشح - IP، PORT، TRANSPORT وبعض الأشياء الأخرى. لنفترض، على سبيل المثال، استخدام نقل UDP والمنفذ 531.

الشكل 8: عقدتان على نفس الشبكة

بعد ذلك، إذا كنا في العقدة p1، فسوف يمنحنا WebRTC مثل هذا الكائن المرشح - . هذا ليس تنسيقًا دقيقًا، بل مجرد رسم تخطيطي. إذا كنا في العقدة p2، فإن المرشح هو . من خلال آلية الإشارة، سيستقبل p1 مرشح p2 (أي موقع العقدة p2، أي IP و PORT). ثم يمكن لـ p1 الاتصال بـ p2 مباشرة. وبشكل أكثر دقة، سيرسل p1 البيانات إلى 10.50.150.3:531 على أمل أن تصل إلى p2. لا يهم ما إذا كان هذا العنوان ينتمي إلى العقدة p2 أو إلى وسيط ما. الشيء الوحيد المهم هو أنه سيتم إرسال البيانات من خلال هذا العنوان ويمكن أن تصل إلى p2.

طالما أن العقد موجودة على نفس الشبكة، فكل شيء يكون بسيطًا وسهلاً - كل عقدة لديها كائن مرشح واحد فقط (يعني دائمًا موقعها الخاص، أي موقعها في الشبكة). ولكن سيكون هناك العديد من المرشحين عندما تكون العقد موجودة مختلفالشبكات.

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

الشكل 9: إحدى العقدتين خلف NAT، والأخرى ليست كذلك

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

لنفترض أن خادم الويب متصل بالإنترنت مباشرة، أي أنه يحتوي على عنوان IP * عام. دع هذه تكون العقدة p2. ترسل العقدة p1 (عميل الويب) طلبًا إلى العنوان 10.50.200.10. أولا، تذهب البيانات إلى جهاز التوجيه r1، أو بالأحرى إلى جهاز التوجيه الخاص به الداخليةالواجهة 192.168.0.1. بعد ذلك، يتذكر جهاز التوجيه عنوان المصدر (العنوان p1) ويدخله في جدول NAT خاص، ثم يغير عنوان المصدر إلى عنوانه الخاص (p1 → r1). علاوة على ذلك، بطريقتي الخاصة خارجيالواجهة، يرسل جهاز التوجيه البيانات مباشرة إلى خادم الويب P2. يقوم خادم الويب بمعالجة البيانات وإنشاء استجابة وإرسالها مرة أخرى. يرسل r1 إلى جهاز التوجيه، لأنه موجود في عنوان المرسل (قام جهاز التوجيه باستبدال العنوان بعنوان خاص به). يتلقى جهاز التوجيه البيانات وينظر إلى جدول NAT ويعيد توجيه البيانات إلى العقدة p1. يعمل جهاز التوجيه كوسيط هنا.

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

دعنا نعود إلى تقنية WebRTC، أو بشكل أكثر دقة، إلى الجزء الذي يستخدم بروتوكول ICE (وبالتالي مرشحي Ice). العقدة p2 لديها مرشح واحد (موقعها في الشبكة هو 10.50.200.10)، والعقدة p1، التي تقع خلف جهاز التوجيه مع NAT، سيكون لها مرشحان - محلي (192.168.0.200) ومرشح جهاز التوجيه (10.50.200.5). الأول ليس مفيدًا، ولكن يتم إنشاؤه على الرغم من ذلك، نظرًا لأن WebRTC لا يعرف حتى الآن أي شيء عن العقدة البعيدة - فقد تكون أو لا تكون على نفس الشبكة. سيكون المرشح الثاني مفيدًا، وكما نعلم بالفعل، سيلعب المنفذ (المرور عبر NAT) دورًا مهمًا.

يتم إنشاء الإدخال في جدول NAT فقط عندما تغادر البيانات الشبكة الداخلية. لذلك، يجب أن تقوم العقدة p1 بنقل البيانات أولاً وبعد ذلك فقط يمكن أن تصل البيانات من العقدة p2 إلى العقدة p1.

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

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

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

خوادم STUN و TURN

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

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

دعونا نلقي نظرة على هذه العملية مع مثال.

مثال (تشغيل خادم STUN)

سيتم الإشارة إلى خادم STUN بالرمز s1. جهاز التوجيه، كما كان من قبل، من خلال r1، والعقدة من خلال p1. ستحتاج أيضًا إلى مراقبة جدول NAT - وسنشير إليه بالرمز r1_nat. علاوة على ذلك، يحتوي هذا الجدول عادةً على العديد من السجلات من العقد المختلفة للشبكة الفرعية - ولن يتم تقديمها.

لذلك، في البداية لدينا جدول فارغ r1_nat.

الجدول 2: رأس الحزمة

ترسل العقدة p1 هذه الحزمة إلى جهاز التوجيه r1 (بغض النظر عن كيفية استخدام الشبكات الفرعية المختلفة تقنيات مختلفة). يحتاج جهاز التوجيه إلى استبدال عنوان المصدر Src IP، حيث من الواضح أن العنوان المحدد في الحزمة غير مناسب لشبكة فرعية خارجية، علاوة على ذلك، يتم حجز العناوين من هذا النطاق، ولا يوجد عنوان واحد على الإنترنت به مثل هذا العنوان. يقوم جهاز التوجيه بإجراء استبدال في الحزمة وإنشاء دخول جديدفي الجدول الخاص بك r1_nat. للقيام بذلك، يحتاج إلى التوصل إلى رقم المنفذ. تذكر أنه بما أن العديد من المضيفين داخل شبكة فرعية يمكنهم الوصول إلى شبكة خارجية، فيجب تخزين جدول NAT معلومات إضافية، حتى يتمكن جهاز التوجيه من تحديد أي من هذه العقد المتعددة مخصصة لحزمة الإرجاع من الخادم. دع جهاز التوجيه يأتي بالمنفذ 888.

تم تغيير رأس الحزمة:

الجدول 4: تم تحديث جدول NAT بإدخال جديد

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

المنفذ الحقيقي الذي تقبل عليه العقدة p1 الاتصال هو بالطبع 35777، لكن الخادم يرسل البيانات إليه خياليالمنفذ 888، والذي سيتم تغييره بواسطة جهاز التوجيه إلى 35777 الحقيقي.

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

Src IP Src PORT Dest IP Dest PORT

10.50.200.5	888	12.62.100.200	6000

الجدول 5: تلقى خادم STUN الحزمة

في المجمل، يعرف خادم STUN أنه تلقى حزمة من العنوان 10.50.200.5:888. الآن يرسل الخادم هذا العنوان مرة أخرى. يجدر بنا التوقف هنا وإلقاء نظرة أخرى على ما نظرنا إليه للتو. الجداول أعلاه هي مقتطف من headerالحزمة، وليس على الإطلاق منه محتوى. لم نتحدث عن المحتوى، لأنه ليس مهمًا جدًا - فهو موصوف بطريقة ما في بروتوكول STUN. الآن سننظر، بالإضافة إلى العنوان، في المحتوى. سيكون بسيطًا ويحتوي على عنوان جهاز التوجيه - 10.50.200.5:888، على الرغم من أننا أخذناه من headerطَرد. لا يتم القيام بذلك في كثير من الأحيان؛ عادةً لا تهتم البروتوكولات بالمعلومات المتعلقة بعناوين العقد؛ من المهم فقط أن يتم تسليم الحزم إلى وجهتها المقصودة. نحن هنا ننظر إلى بروتوكول ينشئ مسارًا بين عقدتين.

والآن لدينا حزمة ثانية تسير في الاتجاه المعاكس:

الجدول 7: يرسل خادم STUN حزمة تحتوي على هذا المحتوى

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

منفذ IP داخلي منفذ IP خارجي منفذ IP خارجي

192.168.0.200	35777	10.50.200.5	888

الجدول 8: جدول NAT

نحن محظوظون، مثل هذا الخط موجود. إذا كنا غير محظوظين، فسيتم التخلص من الحزمة ببساطة. أنت الآن بحاجة إلى فهم العقدة الموجودة على الشبكة الفرعية التي يجب أن ترسل هذه الحزمة. لا داعي للاندفاع، فلنتذكر مرة أخرى أهمية المنافذ في هذه الآلية. وفي الوقت نفسه، يمكن لعقدتين على الشبكة الفرعية إرسال طلبات إلى الشبكة الخارجية. بعد ذلك، إذا جاء جهاز التوجيه بمنفذ 888 للعقدة الأولى، فسيأتي بالمنفذ 889 للعقدة الثانية. لنفترض أن هذا قد حدث، أي أن الجدول r1_nat يبدو كالتالي:

الجدول 10: يستبدل جهاز التوجيه عنوان جهاز الاستقبال

Src IP Src PORT Dest IP Dest PORT

12.62.100.200	6000	192.168.0.200	35777

الجدول 11: قام جهاز التوجيه بتغيير عنوان جهاز الاستقبال

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

ماذا بعد؟ ما فائدة كل هذا؟ الفائدة هي إدخال في الجدول r1_nat. إذا أرسل أي شخص الآن حزمة بمنفذ 888 إلى جهاز التوجيه r1، فسيقوم جهاز التوجيه بإعادة توجيه هذه الحزمة إلى العقدة p1. أدى هذا إلى إنشاء ممر ضيق صغير إلى العقدة المخفية p1.

من المثال أعلاه، يمكنك الحصول على فكرة عن كيفية عمل NAT وجوهر خادم STUN. بشكل عام، تهدف آلية ICE وخوادم STUN/TURN على وجه التحديد إلى التغلب على قيود NAT.

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

خادم TURN هو خادم STUN محسن. من هنا يجب عليك أن تستبعد على الفور أن أي خادم TURN يمكن أن يعمل أيضًا كخادم STUN. ومع ذلك، هناك أيضا مزايا. إذا كان اتصال P2P مستحيلا (كما هو الحال، على سبيل المثال، في شبكات 3G)، فإن الخادم يتحول إلى وضع الترحيل، أي أنه يعمل كوسيط. بالطبع، نحن لا نتحدث عن أي p2p إذن، ولكن خارج آلية ICE، تعتقد العقد أنها تتواصل بشكل مباشر.

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

وبالتالي، هناك حاجة إلى خادم TURN في حالة تخلف كلا المحاورين متماثل NAT (كل واحد لنفسه).

ملخص موجز

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

• تيار وسائل الإعلام
  • يتم تجميع بيانات الفيديو والصوت في تدفقات الوسائط
  • تقوم تدفقات الوسائط بمزامنة مسارات الوسائط التي تتكون منها
  • لا تتم مزامنة تدفقات الوسائط المختلفة مع بعضها البعض
  • يمكن أن تكون تدفقات الوسائط محلية وبعيدة، وعادةً ما يكون التدفق المحلي متصلاً بكاميرا وميكروفون، وتتلقى التدفقات البعيدة البيانات من الشبكة في شكل مشفر
  • هناك نوعان من مسارات الوسائط - للفيديو وللصوت.
  • تتمتع مسارات الوسائط بالقدرة على التشغيل/الإيقاف
  • تتكون المسارات الإعلامية من قنوات إعلامية
  • تعمل مسارات الوسائط على مزامنة قنوات الوسائط التي تتكون منها
  • تحتوي تدفقات الوسائط ومسارات الوسائط على تسميات يمكن تمييزها من خلالها
• مقبض الجلسة
  • يتم استخدام واصف الجلسة لتوصيل عقدتين بالشبكة بشكل منطقي
  • يقوم واصف الجلسة بتخزين معلومات حول الطرق المتاحةترميز بيانات الفيديو والصوت
  • يستخدم WebRTC آلية إشارات خارجية - تقع مهمة إعادة توجيه واصفات الجلسة (sdp) على عاتق التطبيق
  • تتكون آلية الاتصال المنطقي من مرحلتين - العرض (العرض) والاستجابة (الإجابة)
  • من المستحيل إنشاء واصف الجلسة دون استخدام دفق الوسائط المحلية في حالة العرض، وهو مستحيل دون استخدام واصف الجلسة البعيدة في حالة الإجابة.
  • يجب إعطاء الواصف الناتج لتطبيق WebRTC، ولا يهم ما إذا كان هذا الواصف قد تم استلامه عن بعد أو محليًا من نفس تطبيق WebRTC
  • من الممكن تعديل واصف الجلسة قليلاً
• مرشحين
  • مرشح الجليد هو عنوان العقدة في الشبكة
  • يمكن أن يكون عنوان العقدة خاصًا بك، أو يمكن أن يكون عنوان جهاز توجيه أو خادم TURN
  • هناك دائما العديد من المرشحين
  • يتكون المرشح من عنوان IP والمنفذ ونوع النقل (TCP أو UDP)
  • يتم استخدام المرشحين لإنشاء اتصال فعلي بين عقدتين في الشبكة
  • يجب أيضًا إرسال المرشحين من خلال آلية الإشارات
  • يحتاج المرشحون أيضًا إلى المرور إلى تطبيقات WebRTC، ولكن فقط عن بعد
  • في بعض تطبيقات WebRTC، لا يمكن إرسال المرشحين إلا بعد تعيين واصف الجلسة
• صاعقة/دوران/جليد/NAT
  • NAT هي آلية لتوفير الوصول إلى شبكة خارجية
  • تدعم أجهزة التوجيه المنزلية جدول NAT خاصًا
  • يستبدل جهاز التوجيه العناوين الموجودة في الحزم - عنوان المصدر بعنوانه الخاص، إذا كانت الحزمة تنتقل إلى شبكة خارجية، وعنوان جهاز الاستقبال بعنوان المضيف على الشبكة الداخلية، إذا كانت الحزمة واردة من شبكة خارجية
  • لتوفير وصول متعدد القنوات إلى شبكة خارجية، يستخدم NAT المنافذ
  • ICE - محرك اجتياز NAT
  • خوادم STUN وTURN – خوادم مساعدة لاجتياز NAT
  • يتيح لك خادم STUN إنشاء الإدخالات الضرورية في جدول NAT، كما يُرجع أيضًا العنوان الخارجي للمضيف
  • يقوم خادم TURN بتعميم آلية STUN ويجعلها تعمل دائمًا
  • في أسوأ الحالات، يتم استخدام خادم TURN كوسيط (ترحيل)، أي أن P2P يتحول إلى اتصال عميل خادم عميل.

تعد WebRTC اليوم التقنية "الساخنة" لبث الصوت والفيديو في المتصفحات. تعد التقنيات المحافظة، مثل HTTP Streaming وFlash، أكثر ملاءمة لتوزيع المحتوى المسجل (الفيديو حسب الطلب) وهي أدنى بكثير من WebRTC من حيث البث في الوقت الفعلي والبث عبر الإنترنت، أي. حيث يلزم الحد الأدنى من زمن استجابة الفيديو للسماح للمشاهدين برؤية ما يحدث "مباشرًا".

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

يعد زمن الوصول للاتصالات مهمًا في أنظمة البث عبر الإنترنت والندوات عبر الإنترنت والتطبيقات الأخرى التي تتطلب اتصالاً تفاعليًا مع مصدر الفيديو والمستخدمين النهائيين وتتطلب حلاً.

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

من أجل اختبار تقنية WebRTC أثناء العمل وتشغيل عملية بسيطة البث عبر الإنترنت، استخدمنا برنامج خادم Flashphoner WebRTC Media & Broadcasting Server. تنص الميزات على القدرة على بث تدفقات WebRTC في وضع واحد إلى متعدد، بالإضافة إلى دعم كاميرات IP وأنظمة المراقبة بالفيديو عبر بروتوكول RTSP؛ سنركز في هذه المراجعة على عمليات البث عبر الويب وميزاتها.

تثبيت خادم البث والوسائط WebRTC

لأن ل أنظمة ويندوزلم يكن هناك إصدار خادم، ولم أرغب في تثبيت جهاز افتراضي مثل VMWare+Linux، حتى أتمكن من اختبار عمليات البث عبر الإنترنت في المنزل كمبيوتر ويندوزلم ينجح في مبتغاه. لتوفير الوقت، قررنا أن نأخذ مثالاً على الاستضافة السحابية مثل هذا:

كان الإصدار 6.5 من Centos x86_64 بدون أي برامج مثبتة مسبقًا في مركز بيانات أمستردام. وبالتالي، كل ما لدينا تحت تصرفنا هو الوصول إلى الخادم وSSH. بالنسبة لأولئك الذين هم على دراية أوامر وحدة التحكم Linux، يعد تثبيت خادم WebRTC بأن يكون بسيطًا وغير مؤلم. فماذا فعلنا:

1. تنزيل الأرشيف:

$wget https://site/download-wcs5-server.tar.gz

2. تفريغ:

$tar -xzf download-wcs5-server.tar.gz

3. التثبيت:

$cd FlashphonerWebCallServer

أثناء التثبيت، أدخل عنوان IP الخاص بالخادم: XXX.XXX.XXX.XXX

4. تفعيل الترخيص:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. بدء تشغيل خادم WCS:

بدء خدمة $service webcallserver

6. تحقق من السجل:

$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. تأكد من وجود العمليتين:

$ps aux | grep Flashphoner

اكتملت عملية التثبيت.

اختبار البث عبر الإنترنت عبر WebRTC

تبين أن اختبار عمليات البث أمر بسيط. بالإضافة إلى الخادم، يوجد عميل ويب يتكون من عشرات ملفات Javascript وHTML وCSS وتم نشرها بواسطتنا في المجلد /var/www/html أثناء مرحلة التثبيت. الشيء الوحيد الذي كان يجب القيام به هو إدخال عنوان IP الخاص بالخادم في تكوين flashphoner.xml حتى يتمكن عميل الويب من إنشاء اتصال بالخادم عبر HTML5 Websockets. دعونا نصف عملية الاختبار.

1. افتح صفحة عميل اختبار Index.html في متصفح Chrome:

2. من أجل بدء البث، تحتاج إلى النقر فوق الزر "ابدأ" في منتصف الشاشة.
قبل القيام بذلك، عليك التأكد من أن كاميرا الويب متصلة وجاهزة للاستخدام. لا توجد متطلبات خاصة لكاميرا الويب، على سبيل المثال، استخدمنا كاميرا قياسية مدمجة في جهاز كمبيوتر محمول بدقة 1280 × 800.

سيطلب متصفح Chrome بالتأكيد الوصول إلى الكاميرا والميكروفون حتى يفهم المستخدم أنه سيتم إرسال الفيديو الخاص به إلى خادم الإنترنت ويسمح بذلك.

3. تمثل الواجهة بثًا ناجحًا لدفق الفيديو من الكاميرا إلى خادم WebRTC. في الزاوية اليمنى العليا، يوجد مؤشر يشير إلى أن البث ينتقل إلى الخادم، وفي الزاوية السفلية يوجد زر "إيقاف" لإيقاف إرسال الفيديو.

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

في التطبيقات الحقيقية مثل الندوات عبر الإنترنت أو المحاضرات أو عمليات بث الفيديو عبر الإنترنت أو التلفزيون التفاعلي، سيتعين على المطورين تنفيذ توزيع هذا المعرف على مجموعات معينة من المشاهدين حتى يتمكنوا من الاتصال بالتدفقات المطلوبة، ولكن هذا هو بالفعل منطق التطبيق . لا يؤثر WebRTC Media & Broadcasting Server عليه، ولكنه يوزع الفيديو فقط.

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

نتائج اختبار خادم البث عبر الإنترنت WebRTC

أثناء الاختبارات، بدا الكمون مثاليًا. كان اختبار الاتصال بمركز البيانات حوالي 100 مللي ثانية وكان التأخير غير مرئي للعين. من هنا، يمكننا أن نفترض أن التأخير الحقيقي هو نفسه 100 زائد أو ناقص بضع عشرات من المللي ثانية لوقت التخزين المؤقت. مقارنة بفيديو Flash: في مثل هذه الاختبارات، لا يعمل Flash مثل WebRTC. لذلك، إذا قمت بتحريك يدك على شبكة مماثلة، فلا يمكن رؤية الحركة على الشاشة إلا بعد ثانية أو ثانيتين.

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

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

تبين أن جودة البث مقبولة تمامًا للندوات عبر الإنترنت وعمليات البث عبر الإنترنت. الشيء الوحيد الذي أثار بعض الأسئلة هو دقة الفيديو. تدعم الكاميرا 1280x800، لكن الدقة في صورة الاختبار مشابهة جدًا لـ 640x480. يبدو أن هذه المشكلة تحتاج إلى توضيح مع المطورين.

فيديو عن الاختبار يتم بثه من كاميرا الويب
عبر خادم WebRTC

تقنيات إجراء المكالمات من المتصفح موجودة منذ سنوات عديدة: Java، وActiveX، برنامج أدوب فلاش...في السنوات القليلة الماضية أصبح من الواضح أن الإضافات واليسار الأجهزة الظاهريةإنها لا تتألق بالراحة (لماذا يجب أن أقوم بتثبيت أي شيء على الإطلاق؟) والأهم من ذلك أنها لا تتمتع بالراحة. ما يجب القيام به؟ هناك مخرج!

حتى وقت قريب، كانت شبكات IP تستخدم عدة بروتوكولات للاتصال الهاتفي أو الفيديو عبر بروتوكول الإنترنت: SIP، وهو البروتوكول الأكثر شيوعًا، وH.323 وMGCP، وJabber/Jingle (المستخدم في Gtalk)، وAdobe RTMP* شبه المفتوح، وبالطبع ، مغلق سكايب. يحاول مشروع WebRTC، الذي بدأته شركة Google، تغيير الوضع في عالم IP والاتصال الهاتفي عبر الويب، مما يجعل كل شيء الهواتف الذكيةبما في ذلك سكايب. لا يقوم WebRTC فقط بتنفيذ جميع إمكانيات الاتصال مباشرة داخل المتصفح، والذي تم تثبيته الآن على كل جهاز تقريبًا، ولكنه يحاول أيضًا حل مشكلة عامة تتعلق بالاتصال بين مستخدمي المتصفح في نفس الوقت (تبادل البيانات المختلفة، وبث الشاشة، والتعاون مع المستندات، و أكثر بكثير).

WebRTC من وجهة نظر مطور الويب

من وجهة نظر مطور الويب، يتكون WebRTC من جزأين رئيسيين:

• التحكم في تدفقات الوسائط من الموارد المحلية (الكاميرا أو الميكروفون أو الشاشة الكمبيوتر المحلي) يتم تنفيذه بواسطة الأسلوب navigator.getUserMedia، الذي يُرجع كائن MediaStream؛
• اتصال نظير إلى نظير بين الأجهزة التي تولد تدفقات الوسائط، بما في ذلك تحديد طرق الاتصال ونقلها مباشرة - كائنات RTCPeerConnection (لإرسال واستقبال تدفقات الصوت والفيديو) وRTCDataChannel (لإرسال واستقبال البيانات من المتصفح).

ماذا نفعل؟

سنتعرف على كيفية تنظيم محادثة فيديو بسيطة متعددة المستخدمين بين المتصفحات استنادًا إلى WebRTC باستخدام مقابس الويب. سنبدأ بتجربة Chrome/Chromium، باعتبارهما المتصفحات الأكثر تقدمًا من حيث WebRTC، على الرغم من أن Firefox 22، الذي تم إصداره في 24 يونيو، قد لحق بهم تقريبًا. يجب أن يقال أنه لم يتم اعتماد المعيار بعد، وقد تتغير واجهة برمجة التطبيقات (API) من إصدار إلى آخر. تم اختبار جميع الأمثلة في Chromium 28. ومن أجل البساطة، لن نراقب نظافة التعليمات البرمجية والتوافق عبر المتصفحات.

ميدياستريم

أول وأبسط مكون WebRTC هو MediaStream. فهو يمنح المتصفح إمكانية الوصول إلى تدفقات الوسائط من كاميرا الكمبيوتر المحلي والميكروفون. في Chrome، تحتاج إلى استدعاء الوظيفة navigator.webkitGetUserMedia() (نظرًا لأن المعيار لم يتم الانتهاء منه بعد، تأتي جميع الوظائف ببادئة، وفي Firefox تسمى الوظيفة نفسها navigator.mozGetUserMedia()). عند الاتصال به، سيُطلب من المستخدم السماح بالوصول إلى الكاميرا والميكروفون. لن يكون من الممكن مواصلة المكالمة إلا بعد موافقة المستخدم. يتم تمرير معلمات تدفق الوسائط المطلوبة ووظيفتي رد الاتصال كمعلمات لهذه الوظيفة: سيتم استدعاء الأولى إذا تم الوصول إلى الكاميرا/الميكروفون بنجاح، والثانية - في حالة حدوث خطأ. أولاً، لنقم بإنشاء ملف HTML rtctest1.html باستخدام زر وعنصر:

WebRTC - فيديو المقدمة الأول ( الارتفاع: 240 بكسل; العرض: 320 بكسل; الحدود: 1 بكسل رمادي خالص;) getUserMedia

مايكروسوفت CU-RTC-ويب

لن تكون Microsoft هي Microsoft إذا لم تستجب على الفور لمبادرة Google من خلال إطلاق خيارها غير القياسي غير المتوافق المسمى CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. هتم). على الرغم من أن حصة IE، الصغيرة بالفعل، مستمرة في الانخفاض، إلا أن عدد مستخدمي Skype يمنح Microsoft الأمل في إزاحة Google، ويمكن الافتراض أنه سيتم استخدام هذا المعيار بالذات في المتصفح إصدارات سكايب. يركز معيار Google بشكل أساسي على التواصل بين المتصفحات؛ وفي الوقت نفسه، لا يزال الجزء الأكبر من حركة الصوت على شبكة الهاتف العادية، وهناك حاجة إلى بوابات بينها وبين شبكات IP ليس فقط لسهولة الاستخدام أو التوزيع الأسرع، ولكن أيضًا كوسيلة لتحقيق الدخل مما يسمح لمزيد من اللاعبين تطويرهم. قد لا يؤدي ظهور معيار آخر إلى الحاجة غير السارة للمطورين لدعم تقنيتين غير متوافقتين في وقت واحد فحسب، بل قد يمنح المستخدم أيضًا في المستقبل خيارًا أوسع للوظائف الممكنة والحلول التقنية المتاحة. انتظر و شاهد.

تمكين الدفق المحلي

داخل علامات ملف HTML الخاص بنا، دعنا نعلن عن متغير عام لتدفق الوسائط:

var localStream = null;

يجب أن تحدد المعلمة الأولى للطريقة getUserMedia معلمات دفق الوسائط المطلوب - على سبيل المثال، قم ببساطة بتمكين الصوت أو الفيديو:

varstreamConstraints = ("audio": true, "video": true); // طلب الوصول إلى كل من الصوت والفيديو

أو حدد معلمات إضافية:

varstreamConstraints = ( "audio": true، "video": ( "mandatory": ( "maxWidth": "320"، "maxHeight": "240"، "maxFrameRate": "5")، "اختياري": ) );

يجب تمرير المعلمة الثانية لطريقة getUserMedia إلى وظيفة رد الاتصال، والتي سيتم استدعاؤها إذا نجحت:

الوظيفة getUserMedia_success(stream) (console.log("getUserMedia_success():, تيار); localVideo1.src = URL.createObjectURL(stream); // قم بتوصيل دفق الوسائط بعنصر HTML localStream = تيار; // واحفظه في متغير عالمي لمزيد من الاستخدام)

المعلمة الثالثة هي وظيفة رد الاتصال، وهي معالج الأخطاء الذي سيتم استدعاؤه في حالة حدوث خطأ

الدالة getUserMedia_error(error) ( console.log("getUserMedia_error():", error); )

الاستدعاء الفعلي لطريقة getUserMedia هو طلب للوصول إلى الميكروفون والكاميرا عند الضغط على الزر الأول

الدالة getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

ليس من الممكن الوصول إلى دفق الوسائط من ملف مفتوح محليًا. إذا حاولنا القيام بذلك، فسوف نحصل على الخطأ:

NavigatorUserMediaError (الرمز: 1، الإذن_رفض: 1)"

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

يمكنك تحديد الأجهزة التي سيتمكن Chrome من الوصول إليها في الإعدادات، وإظهار رابط الإعدادات المتقدمة، وقسم الخصوصية، وزر المحتوى. في متصفحات Firefox وOpera، يتم تحديد الأجهزة من القائمة المنسدلة مباشرة عندما يكون الوصول مسموحًا به.

عند استخدام بروتوكول HTTP، سيتم طلب الإذن في كل مرة يتم فيها الوصول إلى دفق الوسائط بعد تحميل الصفحة. سيسمح لك التبديل إلى HTTPS بعرض الطلب مرة واحدة، فقط في المرة الأولى التي تدخل فيها إلى دفق الوسائط.

لاحظ الدائرة النابضة في أيقونة الإشارة المرجعية وأيقونة الكاميرا على الجانب الأيمن من شريط العناوين:

RTCMediaConnection

RTCMediaConnection هو كائن مصمم لإنشاء ونقل تدفقات الوسائط عبر الشبكة بين المشاركين. بالإضافة إلى ذلك، هذا الكائن مسؤول عن إنشاء وصف جلسة الوسائط (SDP)، والحصول على معلومات حول المرشحين ICE لاجتياز NAT أو جدران الحماية(محلي وباستخدام STUN) والتفاعل مع خادم TURN. يجب أن يكون لدى كل مشارك RTCMediaConnection واحد لكل اتصال. يتم إرسال تدفقات الوسائط باستخدام بروتوكول SRTP المشفر.

خوادم بدوره

هناك ثلاثة أنواع من المرشحين ICE: المضيف، srflx والتتابع. يحتوي المضيف على المعلومات التي يتم تلقيها محليًا، وsrflx - الشكل الذي تبدو عليه العقدة بالنسبة لخادم خارجي (STUN)، والترحيل - معلومات لتوكيل حركة المرور من خلال خادم TURN. إذا كانت عقدتنا خلف NAT، فسوف تحتوي على المرشحين المضيفين العناوين المحليةوسيكون عديم الفائدة، وسيساعد مرشحو srflx فقط في أنواع معينة من NAT وسيكون الترحيل هو الأمل الأخير لتمرير حركة المرور عبر خادم وسيط.

مثال لمرشح ICE من النوع المضيف، بالعنوان 192.168.1.37 والمنفذ udp/34022:

أ= المرشح:337499441 2 UDP 2113937151 192.168.1.37 34022 نوع الجيل المضيف 0

التنسيق العام لتحديد خوادم STUN/TURN:

خوادم var = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" )، ( "url": "turn:user@host:port"، "بيانات الاعتماد": "كلمة المرور" ) ]);

هناك العديد من خوادم STUN العامة على الإنترنت. هناك قائمة كبيرة، على سبيل المثال. ولسوء الحظ، فإنها تحل مشاكل قليلة جدا. لا توجد خوادم TURN عامة عمليًا، على عكس STUN. ويرجع ذلك إلى حقيقة أن خادم TURN يمر عبر تدفقات الوسائط، والتي يمكنها تحميل كل من قناة الشبكة والخادم نفسه بشكل كبير. ولذلك، فإن أسهل طريقة للاتصال بخوادم TURN هي تثبيته بنفسك (من الواضح أنك ستحتاج إلى عنوان IP عام). من بين جميع الخوادم، في رأيي، الأفضل هو rfc5766-turn-server. حتى أن هناك صورة جاهزة لـ Amazon EC2.

مع TURN، ليس كل شيء جيدًا كما نرغب، ولكن التطوير النشط جارٍ، وأود أن آمل أنه بعد مرور بعض الوقت، WebRTC، إن لم يكن مساويًا لـ Skype من حيث جودة المرور عبر ترجمة العناوين (NAT) وجدران الحماية ، هو على الأقل ملحوظ سوف يقترب.

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

يقع اختيار طريقة النقل على عاتق المطور - على الأقل يدويًا. بمجرد أن يتم تبادل البيانات الضرورية، سيقوم RTCMediaConnection بتثبيت تدفقات الوسائط تلقائيًا (إن أمكن بالطبع).

نموذج العرض والإجابة

لإنشاء تدفقات الوسائط وتغييرها، يتم استخدام نموذج العرض/الإجابة (الموصوف في RFC3264) وSDP (بروتوكول وصف الجلسة). يتم استخدامها أيضًا بواسطة بروتوكول SIP. في هذا النموذج، يوجد وكيلان: مقدم العرض - الشخص الذي يقوم بإنشاء وصف SDP للجلسة لإنشاء وصف جديد أو تعديل موجود (عرض SDP)، والمجيب - الشخص الذي يتلقى وصف SDP للجلسة من وكيل آخر ويستجيب بوصف الجلسة الخاصة به (الإجابة على SDP). في الوقت نفسه، تتطلب المواصفات بروتوكولًا عالي المستوى (على سبيل المثال، SIP أو بروتوكول خاص به عبر مآخذ الويب، كما في حالتنا)، وهو المسؤول عن نقل SDP بين الوكلاء.

ما هي البيانات التي يجب تمريرها بين اثنين من RTCMediaConnections حتى يتمكنوا من إنشاء تدفقات الوسائط بنجاح:

• يقوم المشارك الأول الذي يبدأ الاتصال بتشكيل عرض ينقل فيه بنية بيانات SDP (يُستخدم نفس البروتوكول لنفس الغرض في SIP) ويصف الخصائص المحتملة لتدفق الوسائط الذي هو على وشك البدء في إرساله. يجب نقل كتلة البيانات هذه إلى المشارك الثاني. يقوم المشارك الثاني بتكوين إجابة مع بطاقة SDP الخاصة به، ويرسلها إلى الأول.
• يقوم كل من المشاركين الأول والثاني بإجراء تحديد المرشحين المحتملين لـ ICE والتي يمكن للمشارك الثاني من خلالها إرسال دفق الوسائط إليهم. عند تحديد المرشحين، ينبغي نقل المعلومات المتعلقة بهم إلى مشارك آخر.

عرض التكوين

لإنشاء عرض، نحتاج إلى وظيفتين. سيتم استدعاء الأول إذا تم تشكيله بنجاح. المعلمة الثانية لأسلوب createOffer() هي وظيفة رد اتصال يتم استدعاؤها في حالة حدوث خطأ أثناء تنفيذها (شريطة أن يكون الخيط المحلي متاحًا بالفعل).

بالإضافة إلى ذلك، هناك حاجة إلى معالجي الأحداث: onicecandidate عند تحديد مرشح ICE جديد وonadstream عند توصيل دفق الوسائط من الجانب البعيد. لنعد إلى ملفنا. دعونا نضيف واحدًا آخر إلى HTML بعد الأسطر التي تحتوي على العناصر:

createOffer

وبعد السطر مع العنصر (للمستقبل):

أيضًا في بداية كود JavaScript سنعلن عن متغير عام لـ RTCPeerConnection:

فار pc1؛

عند استدعاء مُنشئ RTCPeerConnection، يجب عليك تحديد خوادم STUN/TURN. لمزيد من المعلومات حولهم، راجع الشريط الجانبي؛ طالما أن جميع المشاركين موجودون على نفس الشبكة، فلا داعي لذلك.

خوادم فار = فارغة؛

معلمات إعداد عرض SDP

فار OfferConstraints = ();

المعلمة الأولى لأسلوب createOffer() هي وظيفة رد اتصال يتم استدعاؤها عند التكوين الناجح للعرض

الوظيفة pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:"، desc); pc1.setLocalDescription(desc); // تعيين RTCPeerConnection الذي تم إنشاؤه بواسطة عرض SDP باستخدام طريقة setLocalDescription. // عندما يرسل الجانب البعيد إجابته SDP، سيحتاج إلى تعيينه باستخدام طريقة setRemoteDescription // حتى يتم تنفيذ الجانب الثاني، لا نفعل شيئًا // pc2_receivedOffer(desc); )

المعلمة الثانية هي وظيفة رد الاتصال التي سيتم استدعاؤها في حالة حدوث خطأ

الدالة pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:"، error);)

ودعنا نعلن عن وظيفة رد الاتصال التي سيتم تمرير مرشحي ICE إليها عند تحديدهم:

الدالة pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ events.candidate.candidate.replace("\r\n", ""), events.candidate); // حتى يتم تنفيذ الجانب الثاني، لا نفعل شيئًا // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

وأيضًا وظيفة رد اتصال لإضافة دفق وسائط من الجانب البعيد (للمستقبل، نظرًا لأنه لدينا الآن RTCPeerConnection واحد فقط):

الدالة pc1_onaddstream(event) ( console.log("pc_onaddstream()"); RemoteVideo1.src = URL.createObjectURL(event.stream); )

عند النقر فوق الزر "createOffer"، سنقوم بإنشاء RTCPeerConnection، وتعيين أساليب onicecandidate وonaddstream ونطلب تكوين عرض SDP عن طريق استدعاء الأسلوب createOffer():

الوظيفة createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // إنشاء RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // وظيفة رد الاتصال لمعالجة مرشحي ICE pc1.onaddstream = pc1_onaddstream; // يتم استدعاء وظيفة رد الاتصال عندما يظهر دفق الوسائط من الجانب البعيد. لا يوجد أي شيء حتى الآن pc1.addStream(localStream); // دعنا ننقل دفق الوسائط المحلية (بافتراض أنه تم استلامه بالفعل) pc1.createOffer(// والطلب فعليًا تشكيل العرض pc1_createOffer_success , pc1_createOffer_error, OfferConstraints); )

دعونا نحفظ الملف كـ rtctest2.html ونرفعه إلى الخادم ونفتحه في المتصفح ونرى في وحدة التحكم البيانات التي يتم إنشاؤها أثناء تشغيله. أما الفيديو الثاني فلن يظهر بعد، حيث أن هناك مشارك واحد فقط. دعونا نتذكر أن SDP هو وصف لمعلمات جلسة الوسائط، وبرامج الترميز المتاحة، وتدفقات الوسائط، ومرشحي ICE هي خيارات ممكنة للاتصال بمشارك معين.

تشكيل الإجابة SDP وتبادل المرشحين ICE

يجب نقل كل من عرض SDP وكل من مرشحي ICE إلى الجانب الآخر وهناك، بعد استلامهم، يستدعي RTCPeerConnection أساليب setRemoteDescription لعرض SDP وaddIceCandidate لكل مرشح ICE يتم استلامه من الجانب البعيد؛ بالمثل في الجانب المعاكسللإجابة على مرشحي SDP وICE عن بعد. يتم تشكيل الإجابة SDP نفسها بشكل مشابه للعرض؛ الفرق هو أنه لا يتم استدعاء طريقة createOffer، ولكن طريقة createAnswer، وقبل ذلك يتم تمرير طريقة RTCPeerConnection setRemoteDescription إلى العرض SDP المستلم من المتصل.

دعونا نضيف عنصر فيديو آخر إلى HTML:

ومتغير عام لـ RTCPeerConnection الثاني ضمن إعلان الأول:

فار pc2؛

معالجة العرض والإجابة على SDP

تشكيل الإجابة SDP مشابه جدًا للعرض. في وظيفة رد الاتصال التي يتم استدعاؤها عند التكوين الناجح للإجابة، على غرار العرض، سنقدم وصفًا محليًا ونمرر SDP للإجابة المستلمة إلى المشارك الأول:

الدالة pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

وظيفة رد الاتصال، التي يتم استدعاؤها في حالة حدوث خطأ عند إنشاء الإجابة، تشبه تمامًا العرض:

الدالة pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", error); )

معلمات تشكيل الإجابة SDP:

var AnswerConstraints = ( "mandatory": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

عندما يتلقى المشارك الثاني العرض، سنقوم بإنشاء RTCPeerConnection وتشكيل إجابة بنفس طريقة العرض:

الوظيفة pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()"، desc)؛ // إنشاء كائن RTCPeerConnection للمشارك الثاني بنفس طريقة المشارك الأول pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate ; // قم بتعيين معالج الحدث عندما يظهر مرشح ICE pc2.onaddstream = pc_onaddstream; // عندما يظهر الدفق، قم بتوصيله بـ HTML pc2.addStream(localStream); // نقل دفق الوسائط المحلية (في مثالنا، الثاني المشارك لديه نفس الأول) // الآن، عندما يكون RTCPeerConnection الثاني جاهزًا، سنمرر له العرض المستلم SDP (لقد مررنا الدفق المحلي إلى الأول) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // اطلب الاتصال الثاني لإنشاء بيانات لرسالة الإجابة pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error,answerConstraints); )

من أجل نقل العرض SDP من المشارك الأول إلى الثاني في مثالنا، دعنا نزيل التعليق عنه في الدالة pc1 createOfferخط اتصال النجاح ():

Pc2_receivedOffer(desc);

لتنفيذ معالجة مرشحي ICE، دعنا نزيل التعليق في معالج حدث استعداد مرشح ICE للمشارك الأول pc1_onicecandidate() نقله إلى الثاني:

Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));

معالج حدث جاهزية مرشح ICE للمشارك الثاني يشبه المرآة للأول:

الدالة pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", events.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

وظيفة رد الاتصال لإضافة دفق الوسائط من المشارك الأول:

الدالة pc2_onaddstream(event) ( console.log("pc_onaddstream()"); RemoteVideo2.src = URL.createObjectURL(event.stream); )

إنهاء الاتصال

دعونا نضيف زر آخر إلى HTML

يشنق

ووظيفة إنهاء الاتصال

الوظيفة btnHangupClick() ( // افصل الفيديو المحلي عن عناصر HTML، وأوقف دفق الوسائط المحلية، set = null localVideo1.src = ""; localStream.stop(); localStream = null; // لكل مشارك، قم بتعطيل الفيديو من HTML العناصر، أغلق الاتصال، اضبط المؤشر = خالٍ RemoteVideo1.src = ""؛ pc1.Close(); pc1 = null; RemoteVideo2.src = ""; pc2.Close(); pc2 = null; )

فلنحفظه كـ rtctest3.html ونرفعه إلى الخادم ونفتحه في المتصفح. يطبق هذا المثال النقل ثنائي الاتجاه لتدفقات الوسائط بين اثنين من اتصالات RTCPeerConnections داخل علامة تبويب المتصفح نفسها. لتنظيم تبادل العرض والإجابة لمرشحي SDP وICE بين المشاركين والمعلومات الأخرى عبر الشبكة، بدلاً من إجراءات الاتصال المباشرة، سيكون من الضروري تنفيذ التبادل بين المشاركين باستخدام نوع ما من وسائل النقل، في حالتنا - مآخذ الويب.

بث الشاشة

يمكن لوظيفة getUserMedia أيضًا التقاط الشاشة والبث كـ MediaStream عن طريق تحديد المعلمات التالية:

var mediaStreamConstraints = ( audio: false, video: ( إلزامي: ( chromeMediaSource: "screen"), اختياري: ) );

للوصول إلى الشاشة بنجاح، يجب استيفاء عدة شروط:

• تمكين علامة لقطة الشاشة في getUserMedia() في chrome://flags/,chrome://flags/;
• يجب تنزيل الملف المصدر عبر HTTPS (أصل SSL)؛
• لا ينبغي طلب الدفق الصوتي؛
• لا ينبغي تنفيذ طلبات متعددة في علامة تبويب متصفح واحدة.

مكتبات WebRTC

على الرغم من أن WebRTC لم ينته بعد، فقد ظهرت بالفعل العديد من المكتبات المبنية عليه. تم تصميم JsSIP لإنشاء هواتف إلكترونية قائمة على المستعرض تعمل مع محولات SIP مثل Asterisk وCamalio. ستعمل PeerJS على تسهيل إنشاء شبكات P2P لتبادل البيانات، وستعمل Holla على تقليل مقدار التطوير المطلوب لاتصالات P2P من المتصفحات.

Node.js وsocket.io

من أجل تنظيم تبادل مرشحي SDP و ICE بين اثنين من اتصالات RTCPeerConnections عبر الشبكة، نستخدم Node.js مع وحدة المقبس.io.

تم شرح تثبيت أحدث إصدار ثابت من Node.js (لـ Debian/Ubuntu).

$ sudo apt-get install python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get installNodejs

التثبيت للآخرين نظام التشغيلالموصوفة

دعونا تحقق:

$ echo "sys=require("util"); sys.puts("رسالة اختبارية");" > Nodetest1.js $ Nodejs Nodetest1.js

باستخدام npm (Node Package Manager)، سنقوم بتثبيت المقبس.io والوحدة السريعة الإضافية:

$ npm تثبيت المقبس.io اكسبرس

لنختبر ذلك عن طريق إنشاء ملف Nodetest2.js من جانب الخادم:

$ nanoodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // إذا كان المنفذ 80 مجانيًا app.get("/"، الوظيفة (req, res) ( // عند الوصول إلى الصفحة الجذرية res.sendfile(__dirname + "/nodetest2.html"); // أرسل ملف HTML ) ) ; io.sockets.on("connection"، الوظيفة (socket) ( // عند الاتصال بمأخذ التوصيل.emit("حدث الخادم"، (مرحبًا: "world" )); // إرسال رسالة المقبس.on("حدث العميل" ، الوظيفة (البيانات) ( // والإعلان عن معالج الحدث عند وصول رسالة من وحدة تحكم العميل.log(data; )); ));

وnodetest2.html لجانب العميل:

$ nanoNodetest2.html varocket = io.connect("/"); // عنوان URL لخادم Websocket (الصفحة الجذرية للخادم الذي تم تحميل الصفحة منه) المقبس.on("حدث الخادم"، الوظيفة (البيانات) (console.log(data); "الاسم": "القيمة" )); );

لنبدأ الخادم:

$ سودو Nodejs Nodetest2.js

وافتح الصفحة http://localhost:80 (إذا كانت تعمل محليًا على المنفذ 80) في المتصفح. إذا نجح كل شيء، فسنرى في وحدة تحكم JavaScript بالمتصفح تبادل الأحداث بين المتصفح والخادم عند الاتصال.

تبادل المعلومات بين RTCPeerConnection عبر جزء عميل مقابس الويب

لنحفظ مثالنا الرئيسي (rtcdemo3.html) تحت الاسم الجديد rtcdemo4.html. لنقم بتضمين مكتبة المقبس.io في العنصر:

وفي بداية البرنامج النصي JavaScript - الاتصال بمآخذ الويب:

var المقبس = io.connect("http://localhost");

لنستبدل الاتصال المباشر بوظائف مشارك آخر بإرسال رسالة إليه عبر مقابس الويب:

الوظيفة createOffer_success(desc) ( ... // pc2_receivedOffer(desc); مقبس.emit("offer", desc); ... ) وظيفة pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); المقبس .emit("answer", desc); ) الدالة pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); المقبس.emit("ice1", events.candidate); .. . ) وظيفة pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); المقبس.emit("ice2", events.candidate); ... )

في الدالة Hangup()، بدلًا من استدعاء وظائف المشارك الثاني مباشرةً، سنرسل رسالة عبر مقابس الويب:

الدالة btnHangupClick() ( ... // RemoteVideo2.src = ""; pc2.إغلاق(); pc2 = null; المقبس.emit("hangup", ()); )

وأضف معالجات استلام الرسائل:

المقبس.on("offer", الوظيفة (البيانات) ( console.log("socket.on("offer"):", data); pc2_receivedOffer(data); )); المقبس.on ("إجابة"، الوظيفة (البيانات) (هي console.log ("socket.on ("الإجابة"):"، البيانات)؛ pc1.setRemoteDescription(new RTCSessionDescription(data)); )); المقبس.on ("ice1"، الوظيفة (البيانات) ( console.log ("socket.on ("ice1"):"، data)؛ pc2.addIceCandidate(new RTCIceCandidate(data)); )); المقبس.on ("ice2"، الوظيفة (البيانات) ( console.log ("socket.on ("ice2"):"، data)؛ pc1.addIceCandidate(new RTCIceCandidate(data)); )); المقبس.on("hangup"، الوظيفة (البيانات) ( console.log("socket.on("hangup"):"، data); RemoteVideo2.src = ""; pc2.إغلاق(); pc2 = null; ) );

جزء الخادم

من جانب الخادم، احفظ ملف Nodetest2 تحت الاسم الجديد rtctest4.js وداخل وظيفة io.sockets.on("connection", function (socket) ( ... ) سنضيف استقبال وإرسال رسائل العميل:

المقبس.on("offer", function (data) ( // عندما نتلقى رسالة "العرض"، // نظرًا لوجود اتصال عميل واحد فقط في هذا المثال، // سنرسل الرسالة مرة أخرى من خلال نفس مقبس المقبس .emit("offer" , data); // إذا كان من الضروري إعادة توجيه الرسالة عبر كافة الاتصالات، // باستثناء المرسل: // soket.broadcast.emit("offer"، data); )); المقبس.on ("الإجابة"، الوظيفة (البيانات) ( المقبس.emit ("الإجابة"، البيانات)؛ ))؛ المقبس.on("ice1"، الوظيفة (البيانات) (socket.emit("ice1"، data); )); المقبس.on("ice2"، الوظيفة (البيانات) (socket.emit("ice2"، data); )); المقبس.on("hangup"، الوظيفة (البيانات) (socket.emit("hangup"، data); ));

بالإضافة إلى ذلك، دعونا نغير اسم ملف HTML:

// res.sendfile(__dirname + "/nodetest2.html"); // أرسل ملف HTML res.sendfile(__dirname + "/rtctest4.html");

بدء الخادم:

$ سودو Nodejs Nodetest2.js

على الرغم من أن الكود الخاص بكلا العميلين يتم تنفيذه ضمن نفس علامة تبويب المتصفح، إلا أن كل التفاعل بين المشاركين في مثالنا يتم بالكامل عبر الشبكة ولا يتطلب "فصل" المشاركين أي صعوبات خاصة. ومع ذلك، ما فعلناه كان بسيطًا جدًا أيضًا - فهذه التقنيات جيدة لأنها سهلة الاستخدام. حتى لو كانت خادعة في بعض الأحيان. على وجه الخصوص، دعونا لا ننسى أنه بدون خوادم STUN/TURN، لن يتمكن مثالنا من العمل في ظل وجود ترجمة العناوين وجدران الحماية.

خاتمة

المثال الناتج تقليدي للغاية، ولكن إذا قمنا بتعميم معالجات الأحداث قليلاً بحيث لا تختلف بين المتصل والطرف المتصل، فبدلاً من كائنين pc1 وpc2، قم بإنشاء مصفوفة RTCPeerConnection وتنفيذها الخلق الديناميكيوإزالة العناصر، سوف تحصل على دردشة فيديو قابلة للاستخدام بالكامل. لا توجد تفاصيل خاصة مرتبطة بـ WebRTC، ويوجد مثال على محادثة فيديو بسيطة لعدة مشاركين (بالإضافة إلى نصوص جميع الأمثلة في المقالة) على القرص الذي يأتي مع المجلة. ومع ذلك، يمكنك بالفعل العثور على الكثير على الإنترنت. أمثلة جيدة. على وجه الخصوص، تم استخدام ما يلي في إعداد المقالة: simpl.info getUserMedia، simpl.info RTCPeerConnection، WebRTC Reference App.

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