RFC 5219: تصحيح اسم SDP

الخلاصة

طلب RFC 3119 استخدام mp3 اسماً للترميز في SDP، مع أن النوع الفرعي المسجّل ومثال rtpmap المجاور استخدما mpa-robust؛ ووحّد RFC 5219 اسم الترميز.
أبقى الإصدار اللاحق تصميم RTP القائم على وحدات ADU، ووصف تعديلات الشيفرة الكاذبة بأنها توضيحات طفيفة وغير معيارية. ولا يثبت سجل المعايير أن برنامجاً منشوراً استخدم الاسم المتناقض أو أن جلسة أخفقت بسببه.

اسمان في المقطع نفسه

من السهل تجاوز هذا التناقض. فقد سجّل RFC 3119، المنشور عام 2001، النوع الفرعي mpa-robust لصيغة MP3 عبر RTP. لكنه قال في قسم استخدام SDP إن اسم الترميز يجب أن يكون mp3. وبعد ذلك مباشرة، يعيّن المثال نوع الحمولة الديناميكي 121 ويكتب a=rtpmap:121 mpa-robust/90000.

يصف السطران الصيغة نفسها عند نقطتين مختلفتين. يحمل RTP أرقام أنواع الحمولة؛ وبالنسبة إلى الرقم الديناميكي، تخبر خاصية SDP المسماة rtpmap الطرف الآخر بالترميز ومعدل الساعة المرتبطين به. يحدد RFC 4566 هذه المطابقة. وبذلك أعطى RFC 3119 اسمين غير متوافقين لوصف الجلسة، رغم توافق النوع الفرعي ومثال المطابقة.

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

لماذا ظهرت صيغة RTP أخرى؟

عالج التصميم الأصلي خاصية محددة في MP3 Layer III. فقد يشير الإطار إلى بيانات مشفّرة في إطارات سابقة، لذلك لا يكون دائماً وحدة مستقلة لفك الترميز. وشرح RFC 3119 أن تقسيم حزم RTP عند حدود الإطارات قد يجعل بيانات في إطارات وصلت سليمة عديمة الفائدة عند فقدان حزمة.

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

حافظ RFC 5219، المنشور في فبراير 2008، على هذا النهج الأساسي. وأعادت مقدمته شرح المؤشر الخلفي ووحدات ADU والواصفات والتشابك الاختياري. يقول الملخص إنه يحل محل RFC 3119 لتصحيح أخطاء مطبعية في قسم SDP وملحقات الشيفرة الكاذبة. ويحدد الملحق C التغيير الأساسي بوضوح: تصحيح اسم الترميز في SDP؛ أما الملحقان A وB فتلقيا إصلاحات وتوضيحات طفيفة لشيفرة كاذبة غير معيارية.

التصحيح صريح: يطلب RFC 5219 الاسم mpa-robust المطابق للنوع الفرعي المسجّل، ويبقي المثال النوع الديناميكي 121 مرتبطاً بـmpa-robust/90000. كما يسجّل خطأ RFC 3119 تقرير أخطاء تحقّق منه محرر RFCs، إضافة إلى إصلاحات في الأمثلة: المؤشر الخلفي قيمة لا حجم؛ واسم متغير واحد يصبح prevADU بدلاً من curADU؛ وحدّا مصفوفتين في B.2 يصبحان 256 بدلاً من 32. هذه تحسينات للتعليمات المكتوبة، وليست دليلاً على تغير حمولات الشبكات في 2008.

رقم RFC ليس تقرير حادثة

يوضح RFC 5219 كيف يمكن تصحيح المعايير على أكثر من مستوى. فاسم SDP جزء من إرشادات وصف الجلسة المعيارية: يصحح الاسم الذي ينبغي للمشاركين استخدامه للترميز. أما تعديلات الملحقين فتتعلق بشيفرة كاذبة وصفها RFC 5219 نفسه بأنها غير معيارية. ولا يحدد أي من الأمرين وحده حجم مشكلة تشغيلية.

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

هذا هو الحد التاريخي الواجب الحفاظ عليه. استبدل RFC 5219 سلفه لأن تعليمات وصف الجلسة احتاجت إلى تصحيح، ولأن بعض إرشادات التنفيذ احتاجت إلى إيضاح. لكنه أبقى نموذج الحمولة القائمة على ADU. يبيّن سجل المعايير ما صححه المؤلفون؛ أما أثره في الأنظمة الحقيقية فيتطلب أدلة مستقلة من التطبيقات والجلسات.

صحّح RFC الجديد اسم الجلسة لا تصميم الحمولة: RFC 5219

لماذا هذا مهم

الخلاصة

اسمان في المقطع نفسه

لماذا ظهرت صيغة RTP أخرى؟

رقم RFC ليس تقرير حادثة

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات