Real-time Transport Protocol بروتوكول البث الحي والمباشر

عند مشاهدة مقاطع الفيديو الموجودة على الانترنت أو سماع المقاطع الصوتية مثل الراديو وغيـرها وكذلك  المشاركة في الألعاب الـ online، نحتاج إلى بروتوكول يتحكم بالإرسال والاستقبال ونقل البيانات بشكل فوري أو بمعنى آخر تدفق البيانات بصورة مباشرة، لذلك في عام 1996 قامت منظمة IETF بتطوير بروتوكول أطلق عليه Real-time Transport Protocol أو اختصارا RTP.

في هذا المقال سأقدم مقدمة بسيطة عن هذا البروتوكول، فهو احد بروتوكولات الطبقة السابعة Application Layer ومهمته الرئيسية هو نقل بيانات الفيديو والصوت عبر الشبكة مثل المكالمات الصوتية VOIP والمؤتمرات الفيديوية video conference وبث القنوات التلفزيونية عبر الانترنت وكذلك في الألعاب التي تحتاج إلى نقل البيانات في الزمن الحقيقي بغض النظر عن دقة البيانات المستلمة كون إن فقدان بعض المعلومات والتي لا يمكن تمييزها خصوصا عند استعمال خوارزميات معينة تكون أفضل من تأخر وصولها كليا.

فعليا بروتوكول الـ RTP يتكون من جزئين احدهما هو البروتوكول نفسه والجزء الآخر هو بروتوكول RTCP حيث يعمل جنبا إلى جنب معه. فبينما يعمل بروتوكول RTP على نقل البيانات وترتيبها عند وصولها بتسلسل خاطئ مثلا، يقوم RTCP بتنظيم هذه العملية عن طريق نقل المعلومات الخاصة بالتحكم مثل المزامنة synchronization بين قنوات النقل المتعددة ومراقبة عملية QoS المستخدمة لذلك فكمية المعلومات أو الـ Bandwidth الذي يشغله تساوي 5% مقارنة مع الذي يشغله بروتوكول الـ RTP. ويستعمل بالتوازي مع بروتوكول الـ RTCP بروتوكولات اخرى للتحكم وتنظيم عملية النقل مثل RTSP و  H.225و H.245 و SIP.

يتم إرسال البيانات واستقبالها في RTP عبر المنافذ  portsالزوجية بينما في الـ RTCP يتم ذلك عبر المنافذ الفردية التي تليها ومن خلال بروتوكول UDP في الطبقة الرابعة Transport Layer، وممكن أن يكون الإرسال unicast أو Multicast.

من الأشياء الأساسية التي تم أخذها بنظر الاعتبار عند تصميم هذا البروتوكول هو دعمه للعديد من الصيغ من ضمنها (H.264, MPEG-4, MJPEG, MPEG) وكذلك يسمح بإضافة صيغ جديدة ومن دون التعديل على البروتوكول، هذا التصميم تم عمله وفقا للمعمارية التي تسمى (ALF) Application Level Framing.

 

RTP  packet  header

يتكون RTP header من 12 بايت على اقل تقدير ويمكن إضافة عدة bytes إضافية ملحقة بالهيدر، وبعد الهيدر يأتي الـ Payload والذي يمثل البيانات. وبعد أن تعرفنا على حجم الهيدر نأتي الآن لتفصيل أجزاءه

Version : ويتكون من 2 bits والذي يحدد نسخة البروتوكول. النسخة الحالية المستخدمة هي الإصدار 2.

P : مختصر Padding يتكون من 1 بت ويستخدم لمعرفة إذا كان هناك bytes إضافية في نهاية الباكيت المرسلة. هذه الـ bytes تضاف عندما يكون هناك حجم معين من الباكيت يتطلب وجوده كقالب عند استعمالها في خوارزميات التشفير مثلا.

X : مختصر Extension يتكون من 1 بت ويستخدم لمعرفة إذا كان هناك bytes إضافية ملحقة بالهيدر أم لا كما ذكرت سابقا.

CC : مختصر CSRC Count يتكون من bits 4 وسيتم ذكر فائدته لاحقا في CSRC.

M : مختصر Marker يتكون من 1 بت ويستخدم لتفعيل خاصية تضمين المعلومات الخاصة بحدود الفريم من ضمن الباكيت المرسلة.

PT : مختصر Payload Type يتكون من bits 7 ويستخدم لمعرفة صيغة الـPayload  وكيفية ترجمة أجزاءه من قبل الApplication Layer .

Sequence Number : يأخذ رقم عشوائي يتكون من bits 16 ومن ثم يزداد بمقدار واحد عند كل إرسال ، وعلى الرغم من استخدامه في معرفة إذا كان هناك فقد للبيانات أو وصولها بترتيب خاطئ عند المستقبل إلا انه عديم الفائدة في هذا البروتوكول حيث يترك الأمر للتطبيق المستخدم لتحديد القرار الذي يتطلب اتخاذه. فمثلا بعض التطبيقات تقوم بعرض آخر فريم تم استلامه بدلا من الفريم المفقود، لهذا فهو يستعمل فقط لمعرفة إذا ما تم فقد بيانات من عدمها كونه يعتمد على بروتوكول UDP في عمله.

: Timestamp يتكون من 32 bits ويستعمل لتفعيل إمكانية عرض الملف بـ Sampling rate معين.

 SSRC : يتكون من 32 bits ويحمل رقم عشوائي يمثل المصدر المستخدم في المزامنة بين streams.

CSRC : يتكون من 32 bits ويحدد مصادر البيانات الموجودة في حقل الـ Payload عندما يتم نقل البيانات من أكثر من مصدر. أما عدد هذه المصادر والذي يكون 15 كحد أقصى فيتم تحميله في حقل CC.

إلى هنا نأتي إلى نهاية هذه المقدمة السريعة عن هذا البروتوكول ولنا لقاء آخر في مقال آخر إن شاء الله.