الخلاصة

  • سمّى RFC 7865 وثيقة XML الخاصة ببيانات تسجيل SIPREC الوصفية application/rs-metadata+xml، بينما استخدم RFC 7866 الاسم application/rs-metadata في الإجراءات والأمثلة.
  • سُجل Erratum 7987 في يونيو 2024، وما زالت صفحته تعرض Held for Document Update. نشر RFC 9806 على مسار المعايير في يونيو 2025، فحدّث RFC 7866 واستبدل كل ظهور للاسم القديم.
  • أضاف RFC 9806 أيضاً تسجيل IANA الذي أغفلته وثيقتا 2016. يعرض السجل الحالي application/rs-metadata+xml ويحيل إلى RFC 7865 وRFC 9806.
  • تثبت هذه السلسلة الاسم الصحيح في المواصفات، ولا تثبت ما أرسله SRC عامل، أو ما قبله SRS، أو كيف فُكك جسم multipart، أو أي تسمية احتفظ بها الأرشيف.

اتفقت الوثائق، لكن الآلات قد تظل مختلفة

يعرّف RFC 7865 معلومات المشاركين وغيرها من بيانات جلسة التسجيل ضمن وثيقة XML مخصصة لـSIPREC، ويسمي نوعها application/rs-metadata+xml. أما RFC 7866، المنشور في الشهر نفسه من عام 2016، فيعرّف بروتوكول جلسة التسجيل لكنه يستخدم application/rs-metadata في القسم 9 وفي عدة أمثلة.

لا يعني ذلك وجود تنسيقين مختلفين لـXML؛ فـRFC 7866 يرجع إلى RFC 7865 لتعريف المحتوى. يقع التناقض في معرّف MIME الذي يختار مسار المعالجة. قد يفهم المستقبل وحدات XML نفسها ثم يرفض الجسم لأن Content-Type لا يطابق جدول التوجيه. وقد ينشئ المرسل رسائل SIP وXML صحيحة لكنه يعلن اسماً غير صحيح.

وثّق Erratum 7987 هذا التعارض في 12 يونيو 2024. تعرض الصفحة القيمة القديمة والقيمة المصححة، وتلاحظ أن الوثيقتين الأصليتين لم تسجلا النوع. حالتها الحالية هي Held for Document Update وليست Verified. يجب حفظ هذا الفرق، لأن تغيير وصف الحالة يغيّر الدليل نفسه.

جاء RFC 9806 بالقرار اللاحق. نُشر في يونيو 2025 كوثيقة IETF على مسار المعايير، ويحمل العلاقة Updates: 7866، ويقول إنه يحل Erratum 7987، ويستبدل كل application/rs-metadata في RFC 7866 بـapplication/rs-metadata+xml. حُسمت القراءة الحالية للمواصفة؛ أما حالة البرمجيات المنشورة فتحتاج إلى قياس مستقل.

التحديث لا يمحو الصفحة التي قرأها مطور سابق

لا يزال نص RFC 7866 الأصلي يعرض الاسم المختصر. لم يعدّل RFC 9806 الملف التاريخي بصمت، بل أضاف تحديثاً صريحاً يمكن تتبعه. يتيح ذلك للمدقق رؤية الادعاء الأول، وبلاغ الخطأ، والحل اللاحق.

لكن الأدلة تصبح موزعة. قد ينسخ مطور يقرأ RFC 7866 وحده الاسم القديم. ولا يكشف سجل أصول يكتب «يدعم RFC 7866» أي تفسير طُبق. وقد يحتفظ جامع للتصويبات بحالة Held من دون ربطها بالوثيقة اللاحقة. كما أن العثور على قيد IANA الصحيح لا يثبت أن إصداراً برمجياً استهلكه.

تجيب كل وثيقة عن سؤال مختلف: يوضح RFC 7865 الاسم المقصود، ويكشف RFC 7866 موضع دخول التناقض إلى الإجراء، ويحفظ Erratum 7987 البلاغ وحالته التحريرية، ويقدم RFC 9806 التحديث الرسمي. ولا تمثل أي منها جرداً للعمليات والتكوينات العاملة.

أغلق سجل IANA فجوة الاسم فقط

يقر RFC 9806 بأن التسجيل كان مفقوداً ويقدم القالب. النوع application، والنوع الفرعي rs-metadata+xml، ولا توجد معاملات مطلوبة أو اختيارية، وتتبع اعتبارات الترميز application/xml وفق RFC 7303. التطبيقات هي Session Recording Client وSession Recording Server، والاستخدام المقصود COMMON، والتحكم في التغيير لدى IETF.

تحتوي لقطة سجل IANA في 20 سبتمبر 2026 على application/rs-metadata+xml مع إحالتين إلى RFC 7865 وRFC 9806. يثبت ذلك تنسيق فضاء الأسماء، لكنه لا يبين ما إذا كان إصدار معين يحتوي الرمز، أو إن كان التكوين فعّله، أو إن أعاد وسيط كتابة الرأس، أو إن احتفظ الأرشيف بالقيمة الواردة.

وللاحقة +xml معنى محدود أيضاً. تسمح للبرمجيات العامة بالتعرف إلى عائلة XML، لكنها لا تثبت مطابقة مخطط SIPREC، أو ارتباط الوثيقة بـRecording Session الصحيحة، أو اتساق اللقطات الكاملة والتحديثات الجزئية.

تظهر حقيقة التصحيح داخل غلاف MIME

يسمح RFC 7866 لـSRC بإرسال لقطة كاملة أو تحديث جزئي ضمن INVITE أو UPDATE. عندما تحمل رسالة SIP نفسها عرض SDP والبيانات الوصفية، يكون الجسم الخارجي multipart/mixed: جزء لـSDP وآخر للبيانات الوصفية. ويستخدم الجزء الثاني Content-Disposition: recording-session.

لذلك يحتاج إثبات التشغيل البيني إلى أكثر من خانة «يدعم RFC 9806». يجب أن يربط طريقة SIP ومعرّفات محدودة، وContent-Type الخارجي وboundary، وContent-Type وContent-Disposition للجزء، وبصمة جسم XML وnamespace، وحالة اللقطة، ونتيجة الطرف المقابل.

يحافظ SRS على حالة متسلسلة. يتابع التحديثات الجزئية، ويمكنه بعد فقدان الحالة الداخلية طلب لقطة كاملة جديدة. وإذا وجد خطأ نحوياً أو دلالياً في البيانات الوصفية فيمكنه إنهاء Recording Session. لا تصلح استجابة 2xx في طبقة أخرى دليلاً على قبول هذه السلسلة.

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

قد تخفي التوافقية آخر عقدة قديمة

يمكن أن يكون قبول application/rs-metadata وapplication/rs-metadata+xml معاً سياسة انتقال معقولة. فهو يبقي الطرف القديم عاملاً بينما تنتقل المولدات الجديدة. لكنه ليس مطلباً من RFC 9806، ويجعل نجاح الاتصال أقل قدرة على الإثبات.

إذا قبل كل SRS الاسمين إلى أجل غير محدد، يختفي SRC المتأخر داخل معدل النجاح. وإذا حوّلت بوابة الاسم القديم إلى الجديد، تبدو البيانات اللاحقة كأن المصدر مصحح. وإذا طبّع السجل القيمتين قبل الكتابة، تضيع إشارة الحركة القديمة المتبقية.

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

إيصال حيازة التصحيح

الإيصال المقترح هنا ضبط تحريري من Daniel Kade، وليس حقلاً في RFC 9806 ولا مطلباً من IETF أو RFC Editor أو IANA.

يبدأ بسلسلة الوثائق: مواضع محددة في الوثيقتين الأصليتين؛ ومعرّف Erratum 7987 وتاريخه وحالته واستبداله؛ وتصنيف RFC 9806 وعلاقة التحديث وقاعدة الاستبدال؛ ولقطة مؤرخة وبصمة لقيد IANA وقالب التسجيل.

ثم يربط التنفيذ: منتج SRC وSRS وإصداره وbuild، ووحدات التحليل والتوليد، وجيل التكوين، والتسميات المقبولة والمرسلة في كل اتجاه. ويسجل للبديل القديم إن كان يُرفض أو يُقبل أو يُطبّع أو يُعاد كتابته، والقاعدة التي تجعل ذلك مرئياً.

وعلى مستوى المعاملة يحتفظ بالطريقة، والمعرّفات المحدودة، وAccept وContent-Type، وboundary، وContent-Disposition، وبصمة الوثيقة وnamespace، وحالة اللقطة، وربط SDP، وحكم الطرف المقابل. ولا يدمج الرفض أو طلب اللقطة أو إنهاء الجلسة في عبارة «نجح التسجيل».

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

يثبت نشر المعيار وجود القاعدة. ويثبت الإيصال أين عملت القاعدة.

حدود الأدلة

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

مسارات الخطر الواردة سيناريوهات قابلة للاختبار وليست أعطالاً مرصودة. تستند إلى أسطح واضحة في البروتوكول: الرمز الدقيق، وبنية multipart، وتحليل XML، وتسلسل التحديثات، ومعالجة الأرشيف. يجب اختبارها في كل بيئة، لا استخدام وجود RFC 9806 بديلاً عن دليل التشغيل.

المصادر