الخلاصة

  • يربط Ident في RFC 5215 بيانات Vorbis بإعداد Configuration محدد. رؤية المعرّف في الحزمة تثبت اختيار المرسل، لا استلام المستقبل لرؤوس Identification وSetup ولا تثبيتها لديه.
  • عندما تتغير قيمة Ident ولا يملك العميل الإعداد الصحيح، يجب ألّا يفك البيانات الخام المرتبطة بها. لذلك يمكن أن يكون تسلسل RTP سليماً تماماً بينما يكون الصمت هو السلوك الصحيح.

حادثة لم تُسقط فيها الشبكة حزمة صوت واحدة

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

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

لا تسمح RFC 5215 بالتخمين. إذا اكتشف العميل تغير Ident ولم تكن لديه Configuration المناسبة، فعليه ألّا يفك بيانات Vorbis الخام حتى يجلبها. الصمت هنا ليس دليلاً على غياب الحركة في الشبكة؛ إنه تطبيق سليم لحدّ يمنع تفسير بيانات بلا أساس.

المعرّف يشير ولا يحمل ما يشير إليه

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

لهذا لا بد من رؤوس Identification وSetup قبل تفسير إطارات الصوت. أما رأس Comment فيحمل بيانات وصفية ولا يلزم لفك تسلسل الإطارات، ويمكن استبداله برأس شكلي داخل الحزمة المجمّعة. ليست كل المعلومات المتاحة متساوية في سلطتها التشغيلية.

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

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

تلميحات SDP ليست حالة المفكك

يمكن لـ SDP أن يعلن vorbis ومعدل الساعة وعدد القنوات في rtpmap. وتقول RFC 5215 إن هذه المعلومات تلميحات، لأن Configuration هي التي تعطي التفاصيل الدقيقة. ويجب أن يظهر معامل configuration في fmtp، كما يُنصح بوضع الإعداد المجمّع في SDP الأولي للتدفق غير المتسلسل.

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

هذه علامة بداية، وليست إيصال استلام. يستطيع المرسل إثبات أنه أعلن الانتقال، لكنه لا يستطيع استنتاج أن كل مستقبل ثبّت الحالة الجديدة قبل وصول أول بيانات تعتمد عليها.

جسم نادر يتحكم في قيمة سيل كامل

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

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

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

إيصال لسلطة فك الترميز

ينبغي أن يبدأ السجل التشغيلي من جيل العرض/القبول ونوع الحمولة وSSRC وبصمة Configuration. ثم يربط Ident ببصمتي Identification وSetup وبأول طابع وقت ينطبق عليه الإعداد.

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

هذا «إيصال سلطة فك الترميز» تحليل تحريري من BTW وليس شرطاً جديداً في RFC 5215. غايته منع كل دليل من تجاوز نطاقه: RTP يشهد للنقل، وSDP للتفاوض، وIdent للاختيار، وحالة المستقبل للقدرة، وأحداث المفكك والمخرج للتنفيذ.

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

ومن ثم فالسؤال القيادي الصحيح ليس: هل وصلت الحزم؟ بل: ما الدليل على أن هذا المستقبل امتلك في الوقت المناسب الحالة التي تسمح له بتحويلها إلى صوت؟

المصادر

  1. RFC 5215
  2. IETF Datatracker — RFC 5215
  3. معلومات RFC 5215
  4. تاريخ الوثيقة
  5. RFC 3550 — RTP
  6. RFC 4566 — SDP
  7. RFC 3264 — العرض والقبول
  8. RFC 4588 — إعادة إرسال RTP
  9. RFC 3611 — RTCP XR
  10. RFC 3533 — تغليف Ogg
  11. RFC 4648 — ترميزات Base
  12. RFC 3986 — URI
  13. RFC 3551 — ملف RTP
  14. RFC 1191 — اكتشاف Path MTU
  15. RFC 1981 — Path MTU في IPv6
  16. مواصفة Vorbis I
  17. RFC 8088 — قواطع RTP
  18. RFC 8866 — SDP
  19. Heng Lu — أولوية الشفرة العاملة