الخلاصة

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

يمكن أن يظهر audio/L16 في وصف لمحتوى، ثم يظهر L16 في جلسة RTP. سهولة القراءة قد توحي بأن الاسم وحده يكفي لنقل العقد كله. لكن RFC 3555 أخذ العبارة audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15 وفككها قبل إدخالها إلى SDP.

ذهب audio إلى سطر الوسائط m=. وذهب L16 مع ساعة 48000 وقناتين إلى a=rtpmap:97 L16/48000/2. وانتقلت emphasis=50-15 إلى a=fmtp:97. أما ptime=5 فصار سمة مستقلة. لم يكن الرقم 97 جزءاً من هوية عالمية؛ كان تعييناً ديناميكياً داخل تلك الجلسة.

تشابه الاسم لا يكفي لتشابه الإطار

سمح نص 2003 بإضافة نقل RTP إلى نوع وسائط مستخدم في بروتوكول آخر، أو توسيع نوع RTP ليستعمل خارج RTP، بشرط بيان المعلمات الخاصة بكل نمط. لكن الصياغة اللاحقة في RFC 4855 وضعت اختباراً أدق.

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

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

معلمات fmtp ليست سلطة مفتوحة

ينقل fmtp معلمات خاصة بالصيغة إلى أداة الوسائط من دون أن يفهم SDP تفاصيلها. لكن RFC 3555 منع سجل النوع الفرعي من توسيع مجموعة المعلمات وحده. الصيغة التي تعرّف حمولة RTP هي صاحبة المعنى، وأي إضافة تحتاج إلى مراجعة مقابلة لتلك المواصفة.

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

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

سجل مستمر لا يعني تنفيذًا مستمراً

جعل RFC 4855 وRFC 4856 الوثيقة القديمة متقادمة في 2007. احتفظ الأول بالإجراء وخريطة SDP وأضاف قيود مشاركة الاسم. ونقل الثاني التسجيلات الفعلية لملف الصوت والفيديو، مؤكداً أن النقل لم يغيرها تقنياً.

في لقطة IANA المؤرخة في 6 أكتوبر 2026، كان سجل الصوت يحتوي 165 إدخالاً وسجل الفيديو 97 إدخالاً، ويشير عشرون إدخالاً مباشرة إلى RFC 4856. من بينها audio/L16 وaudio/PCMA وaudio/PCMU. هذه حقيقة عن دفتر الأسماء في ذلك اليوم، وليست إحصاءً للهواتف أو البوابات أو المتصفحات التي تدعمها.

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

تعلمنا قصة RFC 3555 أن قابلية النقل لا تأتي من فرض اسم واحد على اختلافات غير مرئية. تأتي من خريطة تكشف الاختلاف، ومن سلطة محدودة ترفض أن تجعل دفتر الأسماء بديلاً عن الشيفرة التي تنفذ العقد.

المصادر