الخلاصة
- يمكن لـSFU أو SFM إعادة كتابة Frame ID كي تبقى السلسلة متصلة لكل مستقبل، ويقول المشروع إنه ينبغي عادة ألّا يقرّ صعوداً قبل إقرار جميع المستقبلين النشطين.
- كلمة «جميع» تحتاج مقاماً مؤرخاً: من كان نشطاً، وما ترجمة المعرّفات، وما الحالة الفردية. الإقرار المجمع لا يثبت فك الترميز أو العرض لدى مستقبل لم يُحفظ في ذلك المقام.
كان في المؤتمر 48 مستقبلاً بحسب لوحة الحضور، وأرسل الـSFU إقراراً صاعداً لإطار واحد. فقرأ نظام الجودة الإشارة على أنها «وصل وفُك ترميزه لدى 48 من 48». لكن مجموعة المستقبلين النشطين في منطق الوسيط كانت 43 فقط: ثلاثة كانوا في طور الانضمام، واثنان استُبعدا مؤقتاً بسبب تبديل طبقة. لم يكذب الـSFU؛ بل ضاعت هوية المقام بين طبقتين من النظام.
يناقش مشروع RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement هذا الحد مباشرة. في طوبولوجيا نقطة إلى نقاط متعددة، قد يحتاج SFU أو SFM إلى إعادة كتابة Frame ID حتى تبقى كل سلسلة خارجة متصلة. ويشير المشروع إلى أن الوسيط، في العادة، لا ينبغي أن يقرّ الإطار في اتجاه المنبع حتى يقرّه جميع المستقبلين النشطين.
هذه ليست قاعدة حسابية مكتفية بذاتها. لا معنى لعبارة «الجميع» من دون تعريف «نشط»، وزمن العضوية، وحالة كل مستقبل، وعلاقة المعرّف الداخل بالمعرّفات الخارجة. قد يتغير المقام بين وصول الإطار وصعود الإقرار. وقد لا تُرسل الطبقة نفسها إلى كل مستقبل. لذلك فإن البت الصاعد يثبت، في أفضل الأحوال، أن الوسيط طبّق قاعدة تجميع معلومة على مجموعة محفوظة.
الوثيقة المجمدة هنا هي المراجعة 01، مؤرخة في 6 يوليو 2026 وتنتهي في 7 يناير 2027. إنها Internet-Draft نشطة في مجموعة AVTCORE، وحالتها المقصودة Informational. يسجل Datatracker الحالة I-D Exists من دون shepherd أو Area Director مسؤول أو تقييم IESG أو رقم RFC أو تخصيص IANA مكتمل. تستخدم رسالة RTCP النوع 205، أما FMT فما زال TBD مع اقتراح القيمة 12. لا توفر هذه الحالة دليلاً على تنفيذ أو تشغيل أو قابلية بينية.
المعرّف يتغير عند عبور الوسيط
Frame ID في المشروع عدد من 16 بتاً يزيد واحداً لكل وحدة معرفة وفق ترتيب الإرسال، ثم يلتف إلى الصفر. يجب أن يقبل المستقبل نقطة بداية اعتباطية. ينبغي أن يظهر امتداد RTP على آخر حزمة من الوحدة، ولا يجوز أن يظهر أكثر من مرة على الإطار نفسه.
غير أن الإطار هنا ليس بالضرورة صورة مرئية. إنه وحدة bitstream قابلة لفك الترميز تحدّث حالة يستطيع ما بعدها الرجوع إليها. قد يكون إطاراً كاملاً، أو إطاراً غير معروض، أو tile أو slice مستقلاً. لذلك لا يثبت المعرّف، حتى قبل وجود SFU، أن المشاهد رأى صورة.
عندما يعيد الوسيط كتابة المعرّفات، يصبح لدينا نسب بين ثلاثة مجالات على الأقل: تسلسل المنبع، وتسلسل كل ساق منحدرة، وزمن العضوية في المجموعة النشطة. إذا حُفظ الإقرار المجمع ولم تُحفظ هذه السلسلة، يتعذر ربطه لاحقاً بحالة مستقبل بعينه.
قيم FFR تفصل التعريف عن الطلب. 00 يحمل المعرّف فقط، و01 يطلب ضمنياً حالة إطار واحد، و10 يحمل بداية وطولاً مستقلين، أما 11 فمحجوز. تستجيب رسالة RTCP بعلم إعادة المزامنة R وبداية وطول ثمانية بتات ومتجه حالة من بت لكل إطار.
حتى البت الفردي أضيق من عبارة «تم»
القيمة واحد تعني أن الوحدة استُقبلت وفُك ترميزها أو أنها ستُفك. يسمح المشروع بإرسالها قبل اكتمال فك الترميز لتقليل التأخير، بشرط ضمان محاولة الفك. وإذا فشلت المحاولة بعد الإقرار، يجب طلب keyframe حتى لو كانت الوحدة في طبقة قابلة للإسقاط. أما الصفر فيجمع: لم تُستقبل، لم تُفك، أو لا يُتوقع فكها.
إذا جمع الـSFU هذه القيم، فإنه يجمع وعوداً وحالات إنجاز معاً ما لم يحتفظ بالتمييز اللاحق. والإقرار الصاعد لا يثبت أن كل مستقبل أكمل فك الترميز؛ قد يكون بعضهم قد أقرّ وعداً بالمحاولة. ولا يثبت العرض، إذ ربما كانت الوحدة غير مرئية أصلاً.
ينبغي أن يحتفظ سجل التجميع لكل ساق بزوج SSRC، وحقبة Frame ID، والبت كما أُرسل، وهل اكتمل الفك لاحقاً، ووقت الانضمام إلى المقام أو الخروج منه. ثم يسجل قاعدة الـSFU والنسخة التي طبّقها ووقت إنتاج الإقرار الصاعد.
عبارة all_active=true من دون قائمة أو تجزئة مقام ليست إيصالاً. إنها نتيجة لا يمكن إعادة حسابها.
النافذة المحدودة تجعل المقام والزمن متلازمين
يحفظ المستقبل نافذة متصلة من الحالات، حجمها الافتراضي 255 مع إمكانية تفاوض من 1 إلى 32767. لأن حقل Length ثمانية بتات، تتطلب النافذة الأكبر من 255 رسائل متعددة. ومع تقدم السلسلة تُطرح أقدم الحالات بطريقة FIFO.
إذا تقاطع الطلب جزئياً مع النافذة، تحرك الاستجابة نقطة البداية إلى أقدم حالة باقية. وإذا لم يبقَ أي تقاطع، أعادت طولاً صفراً. يعني ذلك أن الحالة لم تعد محفوظة؛ لا يعني ضياع الإطار أو نجاحه. وعلى المرسل ألّا يستخدم تلك الإطارات القديمة كمراجع.
قد تؤجل قواعد RTCP الإرسال بينما تستمر النافذة في الحركة. تُبنى الاستجابة من الحالة عند وقت الإرسال، لا من لقطة وقت وصول الطلب. وقد يسقط المستقبل طلباً قديماً معلقاً إذا جاء طلب أحدث. في SFU، يحدث هذا بشكل مستقل على سيقان كثيرة، بينما تتغير مجموعة المستقبلين أيضاً.
لذلك لا يكفي حفظ مقام واحد للمؤتمر. نحتاج مقاماً عند كل قرار تجميع، وحدود النافذة في كل ساق، ووقت الحالة التي دخلت القرار. قد يكون المستقبل عضواً نشطاً عند وصول الإطار لكنه خرج قبل إرسال الإقرار، أو العكس. كلا الحالتين مشروع، لكنهما لا تحملان المعنى نفسه.
حقبة SSRC تمنع استعارة حالة من اتصال آخر
حالة Frame ID فريدة لكل زوج من SSRC المرسل والمستقبل. إذا تغير أي منهما، تبدأ السلسلة من جديد وتُهمل كل الحالة القديمة. ما عدا ذلك، لا يسمح المشروع بفجوات أو إعادة ضبط اعتباطية.
يستطيع SFU أن ينشئ أزواج SSRC مختلفة لكل ساق. دمج قيم رقمية متساوية عبر هذه الأزواج يجعل مستقبلاً جديداً يرث وعد مستقبل غادر. الالتفاف الطبيعي لعدد 16 بت يحتاج أيضاً إلى حساب تسلسلي ضمن الحقبة نفسها، لا إلى مفتاح رقمي مجرد.
وقد تتشابك سلاسل اعتماد مستقلة داخل SSRC واحد. إقرار Frame ID متأخر في سلسلة لا يثبت حالة رقم أقدم في سلسلة أخرى. إذا كان كل مستقبل يتلقى تمثيلاً مختلفاً، فعلى التجميع أن يحفظ السلسلة أو الطبقة لا مجرد أكبر رقم.
إعلان SDP عن امتداد الرأس وrtcp-fb يثبت القدرة المتفاوض عليها فقط. لا يثبت طلباً أو حالة محفوظة أو فك ترميز أو نتيجة عرض، ولا يحدد مقام الـSFU.
إعادة المزامنة لا تختصر التنفيذ
بعلم R يستطيع المستقبل تحديد آخر مرجع فُك بنجاح، وتقديم حالات حتى أحدث وحدة مستلمة إذا سمح الطول. هذه معرفة على جانب المستقبل. يجب على المرسل أن يتحقق أيضاً من بقاء المرجع في مخزن ترميز المرسل.
إن بقي، ينبغي أن يبني الوحدة التالية منه أو من مرجع آخر معروف عند المستقبل. وإن لم يبقَ، ينبغي أن يرسل keyframe. في توزيع متعدد، قد يختلف آخر مرجع صالح بين المستقبلين، فلا يوجد دائماً اختيار مرجعي واحد يرضي الجميع. التجميع يجب أن يكشف هذا التعارض بدلاً من إخفائه في بت واحد.
resync-timeout بين 1 و65535 مللي ثانية هو سياسة تحفيز عند جوع فك الترميز، وليس ضماناً لزمن الاستعادة. وstatus-window-size حد لذاكرة المستقبل، لا ضمان لسعة مراجع المرسل. بعد القرار تبقى عملية إنشاء الإطار، وإرساله، وتسليمه، وفكه، وعرضه.
مقام قابل لإعادة الحساب
وفق فصل طبقات الواقع عند Heng Lu، فإن Frame ID والمتجه وإقرار SFU رموز تنسيق؛ والنافذة ومخازن المراجع وحالة العضوية حالات تنفيذية؛ أما التسليم وفك الترميز والعرض وتجربة المشاهد فملاحظات لاحقة. يفشل الحكم عندما يمنح الرمز سلطة الملاحظة.
الحد الأدنى للمواصفة التشغيلية يجب أن يسجل لكل تجميع: SSRC وحقبته لكل ساق، معرف المنبع والخريطة إلى كل مخرج، مجموعة المستقبلين النشطين بإصدار وزمن، التمثيل أو سلسلة الاعتماد، الطلب والاستجابة، نافذة الحالة، معنى البت، وحالة المرجع في الطرفين. يجب أن تكون نتيجة التجميع قابلة لإعادة الحساب من هذه المدخلات.
اختبارات الكود الحي ينبغي أن تضيف مستقبلاً وتحذفه أثناء تأجيل RTCP، وتغير تمثيله، وتلف 16 بتاً، وتفشل فكاً بعد إقرار إيجابي، وتدفع الحالة خارج النافذة، وتغير SSRC، وتطرد المرجع من المرسل. النجاح ليس بقاء لوحة واحدة خضراء؛ النجاح هو أن يتغير المقام بوضوح ولا يتكلم إقرار عن مشاهد لم يحسبهم.
في الحادث الافتتاحي، كان إقرار الـSFU مفيداً. أخبر المنبع بشيء عن 43 ساقاً وفق قاعدة داخل الوسيط. الخطأ هو أن طبقة أخرى وسعته إلى 48 مشاهداً وإلى عرض ناجح. الإقرار بلا مقام قد يكون صحيحاً في مصدره وخطيراً في السلطة التي تمنحها له المؤسسة.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-avtcore-frame-acknowledgement/
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/references/
- https://datatracker.ietf.org/doc/draft-ietf-avtcore-frame-acknowledgement/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-avtcore-frame-acknowledgement-01.txt
- https://www.ietf.org/archive/id/draft-ietf-avtcore-frame-acknowledgement-01.html
- https://www.ietf.org/archive/id/draft-ietf-avtcore-frame-acknowledgement-01.xml
- https://www.ietf.org/archive/id/draft-sprang-avtcore-frame-acknowledgement-02.txt
- https://datatracker.ietf.org/wg/avtcore/about/
- https://www.rfc-editor.org/rfc/rfc3550.html
- https://www.rfc-editor.org/rfc/rfc4585.html
- https://www.rfc-editor.org/rfc/rfc8285.html
- https://www.rfc-editor.org/rfc/rfc8866.html
- https://www.rfc-editor.org/rfc/rfc7656.html
- https://www.rfc-editor.org/rfc/rfc5104.html
- https://www.rfc-editor.org/rfc/rfc9627.html
- https://www.rfc-editor.org/rfc/rfc8083.html
- https://www.rfc-editor.org/rfc/rfc7201.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
