Summary

  • رقم تسلسل FIR ذو الثماني بتات يميّز الطلب الجديد من تكراره داخل زوج محدد من SSRC؛ وهو لا يصف حالة وحدة فك الترميز ولا زمن ظهور الصورة.
  • عند وجود MCU، تكون رحلة الطلب من المستقبِل إلى MCU ورحلته من MCU إلى المصدر نطاقين مستقلين للموثوقية، ولكل منهما ساعته وسياقه الأمني ودليل الوسائط الخاص به.

تسجل ساعة خدمة المؤتمرات وصول FIR إلى MCU عند لحظة معينة، ثم تسجل ساعة المصدر إنشاء إطار تحديث بعد ذلك بقليل. في الوقت نفسه تقول ساعة جهاز المستقبِل إن الصورة بقيت مجمدة. إذا اختُزلت السجلات الثلاثة في خانة «اكتمل التحديث»، يختفي السؤال الحاسم: أي مصدر وأي مسار وأي حقبة اختيار تخص تلك الحزمة؟

تعرّف RFC 5104 مجموعة رسائل تحكم بالترميز ضمن AVPF. يطلب Full Intra Request، أو FIR، نقطة تحديث لوحدة فك الترميز. أما TSTR وTSTN فيتعاملان مع المفاضلة الزمنية والمكانية، ويحمل VBCM ملاحظات H.271، ويعبر TMMBR وTMMBN عن حد مؤقت لمعدل الوسائط ومجموعة القيود التي ترسم حدوده. تشابه الغلاف لا يعني تشابه معنى النجاح.

يتضمن FIR معرّف SSRC لمرسِل الوسائط المستهدف ورقم تسلسل من ثماني بتات. فضاء الرقم خاص بالزوج المكوّن من SSRC الذي يرسل الملاحظات وSSRC الهدف. يزيد الطلب الجديد الرقم واحداً مع الالتفاف بعد 255، بينما يحتفظ تكرار الطلب نفسه بالقيمة ذاتها.

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

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

لذلك لا يكفي أن يرى المراقب زيادة كبيرة في الحجم أو وحدة NAL بعينها. توضح RFC 6184 كيف توزع حمولة H.264 على RTP، بما في ذلك التجزئة والسياق. قد يبدأ المصدر IDR صحيحاً وتضيع قطعة منه، أو تصل الصورة من دون المعلمات المطلوبة، أو تنتمي إلى مصدر لم يعد MCU يختاره للمستقبِل الأصلي.

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

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

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

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

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

في MCU تبدو الحيازة أكثر تعقيداً. تصف RFC 5117 طوبولوجيات RTP متعددة. قد يستقبل MCU طلب FIR من المشاهد ثم يولد FIR آخر نحو المصدر المختار. وتعامل RFC 5104 موثوقية المسار من المشاهد إلى MCU والمسار من MCU إلى المصدر بصورة مستقلة.

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

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

ليس FIR استجابة عامة لفقد الصورة. توصي المواصفة باستخدام Picture Loss Indication من RFC 4585 للفقد العادي. يُستخدم FIR عندما يجعل غياب التحديث الفيديو غير صالح، مثل انضمام مشارك جديد من دون تحديث دوري أو تبديل MCU إلى مصدر مشفر مختلف.

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

توضح TSTR وTSTN أن «الرد» ليس بالضرورة قبولاً مطابقاً. يطلب TSTR تغيير المفاضلة بين الدقة الزمنية والمكانية، ويعلن TSTN ما اختاره المرسِل فعلاً. قد تختلف القيمة لأن المشفّر يوازن بين عدة مستقبلين وموارده وسياساته. الإشعار دليل قرار، لا نسخة موقعة من الرغبة الأصلية.

لـTMMBR وTMMBN عقد آخر. يرسل المستقبِل حد المعدل الكلي المؤقت مع كلفة كل حزمة. يحسب المرسِل منطقة ممكنة ومجموعة الأزواج التي ترسم حدودها، ثم يعلن المجموعة ومالكيها. يجب إرسال TMMBN حتى عندما لا يدخل الزوج الجديد ضمن المجموعة. إذن وجود الرد لا يثبت اعتماد القيد ولا تحسن الفيديو.

حتى المعدل الكلي يعتمد على موضع الرصد. قد يعد المرسِل والمستقبِل عند طبقات بروتوكول مختلفة وبكلفة إضافية مختلفة. يعبر TMMBR عن قيود معروفة، غالباً محلية، لا عن ضمان للمسار كاملاً. وتربط RFC 8083 ملاحظات RTCP بضرورة احترام التحكم بالازدحام.

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

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

ما زالت RFC 5104 في حالة Proposed Standard، وقد حدّثتها RFC 7728 في شأن إيقاف تدفق RTP واستئنافه، وRFC 8082 في شأن الترميز متعدد الطبقات. جامع القياسات الذي يعرف القالب الأصلي فقط قد يفهم الحقول ويخطئ في تفسير طبقة متفاوض عليها أو تدفق متوقف.

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

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

Sources