اقرأ في هذا المقال
في الأيام الأولى من تبديل الحزم، كانت معظم التطبيقات معنية بنقل الملفات على الرغم من أنّه في وقت مبكر من عام 1981م، وكانت التجارب مستمرة لنقل حركة المرور في الوقت الفعلي مثل عينات الصوت الرقمية، كما تم الاطلاق عليه “الوقت الفعلي” عندما يتم تطبيقه ويكون لديه متطلبات قوية لتسليم المعلومات في الوقت المناسب.
ما هو بروتوكول النقل في الوقت الفعلي RTP
بروتوكول النقل في الوقت الفعلي “RTP”: هو بروتوكول “IP” يدعم نقل الصوت والفيديو في الوقت الفعلي، كما يستخدم على نطاق واسع في الاتصالات الهاتفية عبر بروتوكول الإنترنت وتدفق الصوت والفيديو.
يتم تشغيل حزمة “RTP” أعلى “UDP” وهو نظير “TCP” غير موثوق به ويتضمن معلومات الطوابع الزمنية والمزامنة في رأسه لإعادة التجميع المناسبة عند الطرف المستلم، و”SRTP” هو إصدار من “RTP” يوفر السرية ومصادقة الرسائل، كما يُعد “VoIP” مثالاً معروفاً لتطبيق الوقت الفعلي لأنّه لا يمكنك إجراء محادثة بسهولة مع شخص ما إذا احتاج الأمر أكثر من جزء من الثانية للحصول على رد.
- “SRTP” هي اختصار لـ “Secure RTP”.
- “VoIP” هي اختصار لـ “Voice over IP”.
- “UDP” هي اختصار لـ “User datagram protocol”.
- “TCP” هي اختصار لـ “Transmission Control Protocol”.
- “RTP” هي اختصار لـ “Real-time Transport Protocol”.
- “IP” هي اختصار لـ “Internet Protocol”.
مزايا واستخدامات RTP
إنّ هدف تصميم “RTP” هو التدفق الشامل في الوقت الفعلي للبيانات المتعلقة بالوسائط، كما تتضمن “RTP” آليات لتعويض الارتعاش، واكتشاف فقدان الحزم بالإضافة إلى تسليم حزم البيانات خارج الترتيب وهي مشكلات شائعة بشكل خاص في عمليات إرسال بروتوكول مخطط بيانات المستخدم “UDP” عبر “IP”.
ونظراً لأنّ “RTP” تتيح نقل البيانات إلى نقاط نهائية متعددة على التوازي عبر البث المتعدد “IP”، فهي المعيار الأساسي الذي يتم نشره لعمليات نقل شبكة “IP” للصوت والفيديو، كما يتم تنفيذ آليات ملف التعريف المرتبط وتنسيق الحمولة والمشار إليها في تصميم بنية “RTP” على مستوى طبقة التطبيق بدلاً من طبقة نظام التشغيل.
تتطلب تطبيقات مثل “VoIP” التي تحتاج إلى استخدام تدفق بيانات الوسائط المتعددة في الوقت الفعلي وعادةً تسليم البيانات في الوقت المناسب ومع تفاوت متفاوت في فقدان الحزمة، وعلى سبيل المثال يمكن أن يتسبب فقدان حزمة الصوت في تطبيق “VoIP” في فقدان بعض أجزاء من بيانات الصوت، كما يمكن معالجة هذه الخسارة بشكل مناسب عن طريق خوارزميات تعويض الخطأ لجعلها غير مهمة وغير محسوسة للمتصل.
يتم أيضاً توحيد بروتوكول التحكم في الإرسال “TCP” لاستخدام “RTP”، على الرغم من أنّه لا يتم استخدامه عادةً في التطبيقات نظراً لآليات التحكم في الأخطاء، والتي يمكن أن تسبب تأخيرات وتؤثر على تسليم الحزم في الوقت المناسب، ولهذا السبب تعتمد معظم تطبيقات “RTP” بشكل شائع على تطبيقاتها على “UDP”.
متطلبات ووظائف بروتوكول RTP
أكثر المتطلبات الرئيسية لبروتوكول الوسائط المتعددة للأمور العامة هو أنّه يتيح للتطبيقات المماثلة بالتفاعل مع بعضها البعض، فعلى سبيل المثال ينبغي أن يكون من الممكن لتطبيقين لعقد المؤتمرات الصوتية منفذين بشكل مستقل التحدث مع بعضهما البعض، كما يُشير هذا على الفور إلى أنّ التطبيقات كان من الأفضل لها استخدام نفس طريقة تشفير وضغط الصوت.
وخلاف ذلك فإنّ البيانات المرسلة من قبل طرف واحد ستكون غير مفهومة للطرف المتلقي، ونظراً لوجود عدد غير قليل من أنظمة التشفير المختلفة للصوت، ولكل منها مقايضات خاصة بها بين الجودة ومتطلبات النطاق الترددي والتكلفة الحسابية، فقد يكون من السيئ أن يتم تقرير أنّه يمكن استخدام مخطط واحد فقط.
وبدلاً من ذلك يجب أن يوفر بروتوكولنا طريقة يمكن للمرسل من خلالها إخبار جهاز الاستقبال بنظام التشفير الذي يريد استخدامه، وربما التفاوض حتى يتم تحديد مخطط متاح لكلا الطرفين، وكما هو الحال مع الصوت هناك العديد من أنظمة ترميز الفيديو المختلفة، وبالتالي تظهر الوظيفة العامة الأولى التي يمكن أن تتيحها “RTP” هي إمكانية توصيل تحديد مخطط التشفير هذا.
كما أنّ هذا يعمل أيضاً على تحديد نوع التطبيق فعلى سبيل المثال الصوت أو الفيديو، وبمجرد أن يتم معرفة ما هي خوارزمية الترميز المستخدمة، فإنّه يتم معرفة نوع البيانات التي يتم تشفيرها أيضاً، وهناك مطلب مهم آخر هو تمكين متلقي تدفق البيانات من تحديد علاقة التوقيت بين البيانات المستلمة.
كما تحتاج تطبيقات الوقت الفعلي إلى وضع البيانات المستلمة في مخزن مؤقت للتشغيل لتخفيف الارتعاش الذي قد يكون قد تم إدخاله في دفق البيانات أثناء النقل عبر الشبكة، وبالتالي سيكون من الضروري وجود نوع من الطوابع الزمنية للبيانات لتمكين المتلقي من إعادة تشغيلها في الوقت المناسب.
ترتبط مشكلة توقيت تدفق وسائط واحد بربط الوسائط المتعددة في المؤتمر بالنسبة للوقت، مثل ربط دفق الصوت والفيديو الذي يتكون من نفس المرسل، كما أنّ هذه مشكلة أكثر تعقيداً قليلاً من تحديد وقت التشغيل لدفق واحد
وظيفة أخرى مهمة يجب توفيرها هي الإشارة إلى فقدان الحزمة، حيث أنّ التطبيق ذي حدود الكمون الضيقة لا يمكنه عموماً استخدام وسيلة نقل موثوقة مثل “TCP”، لأنّ إعادة إرسال البيانات لتصحيح الخسارة قد يتسبب في وصول الحزمة بعد فوات الوقت لتكون مفيدة، وبالتالي يجب أن يكون التطبيق قادراً على التعامل مع الحزم المفقودة.
بدءاً في التعامل معها هي معرفة أنّها مفقودة بالفعل، فعلى سبيل المثال قد يأخذ تطبيق الفيديو الذي يستعمله تشفير “MPEG” إجراءات متنوعة عند فقدان حزمة، واعتماداً على ما إذا كانت الحزمة قادمة من إطار “I” أو إطار “B” أو إطار “P”.
يُعد ضياع الحزم أيضاً مؤشراً مناسباً للازدحام، ونظراً لأنّ تطبيقات الوسائط المتنوعة لا تتفعل بشكل عام عبر “TCP” فإنّها تترك أيضاً سمات الابتعاد عن الازدحام في “TCP”، ومع ذلك فإنّ العديد من تطبيقات الوسائط المتعددة تمتلك القدرة على تلقي للازدحام، فعلى سبيل المثال عن طريق تغيير معلمات خوارزمية التشفير لتقليل عرض النطاق الترددي المستهلك.
ولإنجاز هذا العمل يحتاج المستلم إلى إخطار المرسل بحدوث خسائر حتى يتمكن المرسل من ضبط معلمات التشفير الخاصة به، ووظيفة أخرى شائعة عبر تطبيقات الوسائط المتعددة هي مفهوم بيان حدود الإطار، والإطار في هذا السياق خاص بالتطبيق فعلى سبيل المثال قد يكون من المفيد إخطار تطبيق فيديو أن مجموعة معينة من الحزم تتوافق مع إطار واحد، ومن المفيد في تطبيق صوتي تعيين بداية “talk purt” وهي عبارة عن مجموعة من الأصوات أو الكلمات متبوعة بالصمت.
يمكن للمتلقي بعد ذلك تحديد فترات الصمت بين محاور المحادثات واستخدامها كفرص لتحريك نقطة التشغيل، ويتبع ذلك ملاحظة أنّ الاختصار الطفيف أو إطالة المسافات بين الكلمات غير محسوس للمستخدمين، في حين أن تقصير أو إطالة الكلمات نفسها أمر محسوس ومزعج.
الوظيفة النهائية التي قد يجب وضعها في البروتوكول هي طريقة ما لتعيين المرسلين الأكثر سهولة في الاستخدام من عنوان “IP”، كما يمكن أن تعرض تطبيقات المؤتمرات الصوتية والمرئية سلاسل مثل تلك الموجودة على لوحات التحكم الخاصة بها، وبالتالي يجب أن يدعم بروتوكول التطبيق ارتباط هذه السلسلة بتدفق البيانات.
- “MPEG” هي اختصار لـ “Moving Picture Experts Group”.
