الاتصال في الزمن الحقيقي في الويب (Web Real-Time Communication) او اختصارها WebRTC، هي مشروع مجاني مفتوح المصدر مقدم من Google يسمح لمتصفحات الويب والتطبيقات بتبادل البيانات في الوقت الحقيقي باستخدام أكواد برمجية بسيطة   -واجهات برمجية للتطبيقات- (APIs).

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

webrtc-points-projects

المكونات الرئيسية:

  • MediaStream: يسمح هذا الAPI بالوصول إلى الكاميرا والمايك والشاشة، ويتحكم في المجرى  (Stream) وعرضه على الصفحة و إيقافه أو تشغيله.
  • RTCPeerConnection: هذا المكون هو جوهر الWebRTC ويسمح للمشتركين (Peers)  بالاتصال مباشرة، دون وسطاء.
    يقوم كل مشترك بنقل مجرى البث الذي حصل عليه من (MediaStream API) مما يؤدي إلى إنشاء مقاطع (صوت- فيديو) يمكن للمشتركين الآخرين الوصول لها ، يتحكم هذا المكون ب ترميز الفيديو والصوت، عرض الحزمة ، تبادل البيانات والعناوين ضمن الشبكة (Network Address Translation) و غيرها الكثير.
  • RTCDataChannel: يؤمن هذا المكون نقل البيانات ثنائي الاتجاه، وهو مستوحى من WebSocket ولكنه يستخدم UDP بدلاً من TCP من أجل تقليل الازدحام والتكاليف العادية لاتصالات TCP.

يعد إرسال واستقبال حزم الصوت والصورة في مخدمات الويب مثل Youtube أمراً سهلاً، يرسل حاسوب A من المتصفح طلباً إلى DNS server  ليحصل على عنوان الدومين youtube.com ، ثم يقدم المتصفح طلباُ إلى العنوان الذي تلقاه وبعد ذلك، يعرف Youtube كيف يرسل الفيديو إلى الحاسوب A.

ماذا لو أراد حاسوب A أن يتصل بحاسوب آخر B، سوف يرسل طلب ل DNS server لكن من دون نتيجة، إذاً كيف يتم إجراء مكالمة WebRTC؟ لنكتشف ذلك.

  1. Session Description Protocol اختصاراً SDP:

أولاً يجب على A إنشاء عرض SDP (بروتوكول وصف الجلسة). يحتوي هذا العرض على معلومات حول الجلسة التي يريد أن يبدأها: ما هي برامج الترميز التي يستطيع فهمها، ونوع الوسائط التي يريد نقلها (الصوت / الفيديو / البيانات العامة) والمزيد. والأهم من ذلك، يجب أن يحتوي عرض SDP أيضًا على قائمة بعناوين IP والمنافذ التي يكون A مستعدًا لتلقي مجريات الوسائط الواردة، والتي سيستخدمها B للتواصل معه. كيف يولد A هذه القائمة؟  لنتعرف على ICE.

  1. InteractiveConnectivity Establishment اختصاراً ICE:

هذه الخطوة التي تقوم بتأمين لوازم الاتصال سواء كانت الشبكة محلية (LAN) او عالمية (WAN) تسمى هذه اللوازم بـ ICE candidates وهي عبارة عن (Local IP – addresses Reflexive addresses – STUN ones and relayed addresses – TURN ones)، يستخدم للحصول على السابق المخدمات التالية:

  1. Session Traversal Utilities for NAT (STUN): مهمته الحصول على العنوان العام (Public IP) والمنفذ (Port)للحاسوب Aداخل الشبكة(NAT) ، لا يعمل على (Symmetric NAT).
  2. Traversal Using Relay around NAT (TURN): إذا لم يتمكن مخدم STUN لسبب ما من إنشاء اتصال مع المشترك B، يتم تقديم طلب إلى مخدم TURN والذي سيعمل كمرحل وسائط. سيوفر مخدم TURN عنوان IP العام والمنفذ الذي سيعيد توجيه الحزم المستلمة من وإلى كلا المشتركين.
  1. Signaling server:
    الآن بعد أن قام كل مشترك (Peer) بجمع بعض الوسائط لإرسالها وإنشاء SDP، كيف يصل إلى المشترك الآخر؟ هذا هو المكان الذي تحدث فيه الإشارة: عملية الاكتشاف والتفاوض لإنشاء اتصال جلسة الشبكة مع حاسوب B، أو بشكل عام، المشترك الآخر. لا يفرض WebRTC بروتوكول إشارات معين، لذا يمكنك استخدام أي شيء تريده تقريبًا: (Session Initiation Protocol)SIP أو Web Sockets أو (Extensible Messaging Presence Protocol)XMPP أو الحمام الزاجل أو حتى إشارات الدخان إذا كان هذا هو ما تريده (ولا يمثل وقت الاستجابة مشكلة). بغض النظر عما ينتهي بك الأمر باختياره، فإن الفكرة الرئيسية هي أن كل مشترك يتصل بمخدم إشارات (Signaling server) يعمل كوسيط لتبادل المعلومات الضرورية:

    1. بيانات الشبكة (Network data): عناوين أجهزة المشركين على الانترنت ليمكنهم التواصل مع بعضهم البعض.
    2. معلومات التحكم بالجلسة (Session control information data): كيف ومتى تبدأ أو تنتهي الجلسة.
    3. بيانات الوسائط (Media data): ما هو ترميز الصوت والصورة الذي يفهمه المشتركين.

JavaScript API

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

  1. يطلب متصفح A الإذن للوصول إلى الكاميرا والمايك باستخدام mediaDevices.getUserMedia
  2. ينشئ غرضا جديداً من الصف RTCPeerConnection، ويقوم بإضافة البيانات المأخوذة في الخطوة السابقة إلى مجموعة المسارات التي سوف يتم نقلها بين المشتركين، يتم ذلك باستدعاء addTrack
  3. باستدعاء createOffer يتم إنشاء SDP خاص بالمشتركA.
  4. setLocalDescription لوضع الوصف المحلي وإرساله بعد ذلك للمشترك B، من خلال قناة الإشارة (Signaling channel).
  5. ينتظر المشترك B لوصول ال SDP وعند تلقيها ينشئ غرضاً له من الصف RTCPeerConnection وعلى الفور يقوم بوضع الوصف البعيد setRemoteDescription
  6. يعيد المشترك B الخطوات 1 و2 ليلتقط الصوت والصورة ويضمنها مع الاتصال.
  7. يجيب المشترك B بإرساله ال SDP الخاصة به createOffer
  8. يعيد B الخطوة 4 ويضع الإجابة وصف محلي ويرسلها للمشترك A من خلال قناة الإشارة.
  9. أخيراً يستقبل A إجابة B ويضعها وصف بعيد.

يتمكن الآن المشتركين من تبادل البيانات والوسائط.

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

 

Introduction | WebRTC for the Curious

WebRTC API – Web APIs | MDN (mozilla.org)

A simple RTCDataChannel sample – Web APIs | MDN (mozilla.org)

Peer-to-peer communications with WebRTC – Developer guides | MDN (mozilla.org)

draft-ietf-ice-trickle-04 – Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol

SIP & WebRTC: Is There a Difference? | GetVoIP