الخلاصة

  • يناقش RFC 5371 السرية والسلامة وتوثيق المصدر كخصائص منفصلة. إثبات أن رزمة جاءت من عضو في جلسة RTP لا يثبت أن ذلك العضو أنشأ codestream صحيحاً أو كاملاً أو قابلاً للعرض.
  • يحدد fragment offset موضع كل payload من بداية صورة JPEG 2000، بينما يصف MHF مادة الترويسة ويحدد T صلاحية رقم tile. هذه الحقول تجعل النقص قابلاً للرؤية لكنها لا تستعيد الرزم المفقودة.
  • تتطلب النتيجة سلسلة إيصالات مستقلة: تفاوض SDP، هوية الرزمة المحمية، تغطية البايتات، اكتمال الترويسة، عقد RFC 5372 إن استُخدم، قرار الموارد، فك الترميز والعرض.

التوقيع يحفظ الادعاء ولا يصححه

يمكن لآلية حماية مناسبة أن تثبت أن رزمة RTP صدرت عن عضو في الجلسة وأن محتواها لم يتغير ضمن سياق الحماية. هذه نتيجة مهمة؛ فهي تمنع مهاجماً خارج السياق من تعديل offset أو payload من دون كشف.

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

لهذا لا يجوز أن يتحول وصف “authenticated media” إلى “valid picture”. الأول عن الهوية والسلامة. الثاني يحتاج قواعد JPEG 2000 وموارد receiver ونتيجة decoder.

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

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

السرية والسلامة وهوية المصدر ثلاث مسائل

يذكر RFC 5371 أن السرية تتحقق بتشفير payload، وأن السلامة تحتاج حماية تشفيرية مناسبة، وأن النظام قد يوفر توثيق المصدر. لا يجمعها في خاصية واحدة.

قد تكون الرزم مشفرة من دون إثبات كاف لهوية المصدر. وقد تكون موثَّقة وسليمة لكن مرئية لأطراف غير مقصودة إذا أخفقت السرية. وقد تتحقق الخصائص الثلاث ويبقى codestream ناقصاً.

تتغير الآلية المناسبة بحسب التطبيق والنقل وبروتوكول الإشارة. تشير الوثيقة، في سياق 2008، إلى SRTP وIPsec وTLS عند RTP فوق TCP. لا تثبت هذه الإشارات ما يستخدمه نشر حالي، ولا ينبغي تحويلها إلى وصفة إعداد معاصرة.

سجل التدقيق يجب أن يسمّي الآلية والنطاق والمفاتيح أو الهوية المنطقية ونقطة انتهاء الحماية. بعدها يسجل codec validation منفصلاً.

جمع كل ذلك في خانة “secure=true” يفقد القدرة على تفسير حادث: هل انكشفت الصورة، أم عُدلت، أم أرسلها عضو خاطئ، أم كانت غير قابلة للفك منذ المصدر؟

الإزاحة الدقيقة لم تكن دليلاً على الاستمرارية

يحمل كل payload إزاحة على 24 بت من أول بايت في codestream الخاص بالصورة. يستطيع المستقبل وضع الجزء في موقعه الصحيح حتى إن وصل خارج ترتيب النقل.

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

تعطي الإزاحة موقعاً، لا تغطية. إذا وصلت الفترة 0–209 ثم 1610–3009، يبقى ما بينهما فجوة مهما كان الجزء الأخير موثَّقاً.

السجل الصحيح هو خريطة intervals تربط frame والجلسة والطبقة وsequence والإزاحة والطول وhash البايتات. تكشف الفجوات والتداخل والبيانات المتعارضة.

لا يكفي أعلى offset. الوصول إلى موضع بعيد لا يثبت مرور كل المواضع السابقة. ولا يكفي مجموع البايتات؛ يمكن أن تتداخل intervals فيبدو المجموع كاملاً بينما توجد فجوة.

الترويسة الرئيسية تملك سلطة التفسير

ينص RFC 5371 على أن فقدان main header يمنع فك الصورة. يمكن لبيانات tiles أن تصل كاملة وبهوية موثقة، لكنها تفتقد المعلمات المشتركة التي تفسرها.

يحدد MHF أربع حالات: لا ترويسة؛ جزء غير أخير من ترويسة مجزأة؛ الجزء الأخير؛ أو ترويسة كاملة في payload واحد.

القيمة تصف payload الحالي. لا تشهد بوصول الأجزاء السابقة. MHF=2 صحيح لا يعني أن سلسلة الترويسة كاملة. وMHF=3 يغلق سؤال الترويسة في ذلك payload، لا سؤال بقية الصورة.

توصي الممارسات الإرشادية بفصل الترويسات لتسهيل recovery. ينبغي إثبات أن sender اتبع التوصية وأن المستقبل احتفظ بالحالة المناسبة. التوصية ليست نتيجة تشغيلية.

لذلك يلزم receipt خاص بالترويسة: byte coverage، parse result، parameter hash، generation وقرار decoder.

اسم mh_id لم يمنحه سلطة في العقد الأساسي

تتضمن الترويسة ثلاثة بتات تسمى mh_id. إلا أن RFC 5371 يطلب من التطبيقات التي تتبع هذا العقد وحده أن ترسل صفراً وأن يتجاهل المستقبل الحقل.

يقدم RFC 5372 عقداً إضافياً لتعويض الترويسة. يحدد ثبات ID حين لا تتغير معلمات encoder، وزيادته عند التغيير، والتعامل مع rollover، وإمكان احتفاظ المستقبل بترويسة سابقة.

وجود البتات لا يعني أن extension مفعّل. parser قد يعرض القيمة، لكن لا يجوز اعتبارها cache generation من دون تفاوض وتنفيذ مؤكدين.

وهنا يتكرر حد التوثيق: توقيع mh_id=0 يثبت أن المرسل أرسل صفراً. لا يثبت أن تعويضاً حدث أو أن receiver استخدم الترويسة الصحيحة.

ينبغي ربط القيمة بمعلمة SDP، وهوية الترويسة المخزنة وقرار الاستبدال والنتيجة.

T يقرر إن كان رقم tile قابلاً للقراءة

رقم tile على 16 بت يخضع لبت T. عندما يكون T=0 يكون الرقم صالحاً؛ وعندما يكون واحداً يجب تجاهله.

يجب على sender إبطاله حين يحتوي payload على main header فقط، إذ لا توجد tile-part، وحين يجمع عدة tile-parts، إذ لا يستطيع رقم واحد تمثيلها.

قد تبقى بتات تبدو كرقم معقول. لكنها لا تملك سلطة الإسناد. حفظ الرقم من دون T يصنع واقعة مكانية زائفة.

إذا أظهر تقرير أن “tile 0” تسبب في الفشل بينما T=1، فهو لا يقرأ packet؛ بل يقرأ مخطط قاعدة بيانات أسقط شرط الصلاحية.

يجب أن يمثل النظام القيمة المشروطة كنوع واحد: valid مع رقم، أو invalid مع سبب. null وحده قد يخلط بين غير مطبق وغير ملاحظ.

الأولوية لم تكن تفويضاً للشبكة

يضم RFC 5371 حقل priority على ثمانية بتات، لكنه يطلب في العقد الأساسي إرسال 255 وتجاهل القيمة. يعرّف RFC 5372 أنماط priority للتدرج والطبقات والدقة والمكونات.

حتى عند تفعيل extension، تعبر القيمة عن أهمية ضمن عقد payload. لا تثبت أن network queue قرأتها أو طبقت معاملة أفضل.

يلزم لإثبات الخدمة: تفاوض extension، mode، القيمة، mapping إلى scheduler، فعل scheduler، ونتيجة delivery. عرض البايت ليس إثبات QoS.

يمكن لخدمة أن توقع payload ذي priority مرتفعة وتفقده الشبكة. التوقيع يثبت intent المعلن، لا outcome.

الخلط بينهما يخلق حافزاً لتجميل الحقول بدلاً من تحسين التوصيل.

Marker ينهي مساهمة جلسة واحدة

يُضبط RTP Marker إلى واحد في آخر packet من frame. وعند استخدام عدة جلسات، تضع كل جلسة Marker في آخر packet خاص بها لتلك frame.

يمكن أن يصل Marker للطبقة الأساسية وتبقى enhancement layer في الطريق. ويمكن أن تصل جميع Markers مع فجوة داخلية. وقد تغيب جلسة كاملة إذا لم يحتفظ النظام بقائمة الطبقات المتوقعة.

لذلك لا يمثل Marker إيصالاً للصورة الكاملة. يلزم manifest للجلسات، Marker لكل واحدة، byte coverage وسياسة جودة تحدد إن كانت base layer كافية.

إيقاف timer عند أول Marker يقيس نهاية جلسة، لا display latency. إيقافه عند آخر Marker معروف لا يثبت decode.

على كل metric أن يسمّي الحدث الذي يقيسه بدلاً من استعمال كلمة “complete” بلا فاعل.

ترتيب الوحدات لا يمنع الفقد

يعرف RFC 5371 packetization unit كترويسة رئيسية أو ترويسة tile-part أو JPEG 2000 packet. يمكن جمع عدة وحدات مع الحفاظ على ترتيب codestream.

إذا تجاوزت وحدة MTU يمكن تجزئتها، ولا يجوز أن يشارك fragment منها payload مع الوحدة التالية. يحمي ذلك حدود parsing.

هذه قاعدة بناء لدى sender. يمكن للشبكة أن تفقد packet أو تعيد ترتيبه. RTP sequence يصف النقل، offset يصف codestream، وحدود الوحدة تصف parser.

قد يصل كل ما رُصد بالترتيب الصحيح مع غياب وحدة كاملة. وقد يكون codestream متصلاً لكن يرفضه decoder بسبب الموارد.

سلامة packet لا تغير ذلك. receipt التشفيري، transport receipt وcodec receipt يجب أن تبقى منفصلة.

interlace يجعل الحقل نصف الصورة

يميز tp progressive عن odd وeven fields. في interlace يكون ارتفاع main header نصف ارتفاع الصورة المعروضة، ويحتاج receiver إلى مزج الحقل الفردي مع الزوجي التالي.

وصول odd field سليماً وموثقاً لا يثبت وصول even أو نجاح deinterlace. Marker للحقل لا يساوي displayed frame.

إذا غابت معلمة interlace عن SDP يجب أن يكون stream progressive وtp=0. وجودها لا يعفي من التحقق من packet-level agreement.

ينبغي حفظ field identity، timestamp، pairing، errors وoutput. عدّ كل نهاية كframe يضاعف الحقيقة.

التوثيق يثبت مصدر كل field، لكنه لا يثبت أن الزوجين ينتميان إلى نتيجة صحيحة.

SDP يحدد envelope لا نتيجة

يتطلب video/jpeg2000 clock rate وsampling. يجب دعم 90 kHz ويمكن دعم معدلات أخرى. عند تفضيل rate مختلف يُستحسن عرض بديل 90 kHz تحت payload type آخر.

width وheight حدان أقصى اختياريان ويظهران معاً. المجال حتى 2^32−1 لا يعني أن receiver خصص ذاكرة لذلك.

offer/answer يختار grammar. يجب بعده التحقق من timestamps والparameters والموارد والparse والoutput.

عضو موثَّق قد يرسل frame داخل envelope لكنه يتجاوز الحالة الحالية للموارد، أو خارج envelope رغم نجاح التفاوض.

التحكم والواقع التشغيلي مرحلتان. تقرير “SDP accepted” لا يحق له أن يقول “decoder succeeded”.

QoS المعلن يحتاج قياس الخسارة

حتى مع خدمة QoS محسنة، يطلب RFC 5371 من receiver مراقبة packet loss للتأكد من أن الخدمة المطلوبة تُقدَّم فعلاً. وإلا يتصرف كـ best effort.

في best effort يجب تكييف rate أو عدد layers أو مغادرة session عندما يصبح loss غير مقبول، مع مراعاة عدالة TCP.

قد تكون طبقة غائبة قرار adaptation، أو خسارة، أو نقصاً في نقطة capture. interval map يظهر الغياب؛ control log يفسر السبب.

لا priority ولا authentication يثبت delivery. الخدمة تحتاج request، observed loss، action وresult.

من دون ذلك يُتهم decoder بمواد لم تصله، أو تُعرض خسارة الشبكة كخفض جودة مقصود.

RFC 9828 يجيب عن سؤال زمني مختلف

يعرّف RFC 9828 payload لاحقاً لـ sub-codestream latency، مع Main/Body Packets وإشارات resync وsequence وtime وquality وresolution.

المقال المنشور سابقاً في BTW يسأل لماذا لا يثبت خروج أول packet مبكراً زمن العرض أو recovery أو الجودة الكاملة. لا يكرر هذا المقال تلك الأطروحة.

السؤال هنا هو: ماذا يثبت source authentication عندما تكون بنية RFC 5371 ناقصة؟ الجواب أنه يثبت الأصل ضمن session، لا اكتمال الصورة.

RFC 5372 أيضاً extension مستقل يفعّل معاني إضافية. لا ينبغي تجميع أفضل features من ثلاث وثائق ونسبها إلى deployment مجهول.

الهوية الوثائقية لا تثبت adoption أو vendor behavior أو incident frequency.

الحد الأدنى يفصل سلطات الإثبات

تُستخدم Minimum Initial Specification للـ Lu Heng كعدسة تحرير معلنة. لا يحتاج العقد المشترك إلى فرض decoder واحد، لكنه يجب أن يحفظ ما لا تستطيع القرارات المحلية إعادة بنائه لاحقاً.

الحد الأدنى يشمل SDP، frame/session/layer، sequence، timestamp، Marker، flags، offset، intervals، extension، header state، security context، resource verdict، decode وdisplay.

الروابط ضرورية: tile يعتمد على T، priority وmh_id على extension، Marker على session manifest، offset على frame origin، والنتيجة على كامل input.

تحدد Reality Layers نقطة التوقف. هوية المرسل طبقة؛ byte integrity طبقة؛ codestream طبقة؛ decoder output طبقة؛ تجربة المستخدم طبقة.

المرسل الموثَّق يستحق أن يُنسب إليه ما أرسل. ولا يستحق أن تُنسب إليه بايتات لم تصل أو صورة لم تُعرض.