أظهر سجل المؤتمر أن عضواً غادر، لكنه لم يثبت أي طلب هو الذي أخرجه

الخلاصة

• تتيح RFC 5368 لعنوان Refer-To أن يشير عبر cid: إلى قائمة أهداف، ثم ينشئ متلقي REFER طلب SIP مستقلاً لكل هدف فعلي. نجاح المعاملة الأصلية لا يساوي نجاح الطلبات الناتجة.
• توصي الوثيقة بـ norefersub وRefer-Sub: false، فتوقف الاشتراك الضمني الذي يحمل عادة حالات message/sipfrag، لأن هذه القناة لم تُعرّف لتمثيل معاملات متعددة.
• يجب حفظ أساس عدم التفرع، وقيمة Refer-Sub العائدة، وحدود كائن Content-ID، والقائمة بعد التطبيع، وكل طلب فرعي، ومشاهدة الخدمة بإصدارها وزمنها. وقد أوضحت RFC 8262 لاحقاً إمكان الإشارة إلى جزء MIME أو إلى متن الرسالة كاملاً.

لقطة العضوية جاءت من سلطة مختلفة

تقترح RFC 5368 في سياق المؤتمرات أن يتابع المشرف حزمة أحداث حالة المؤتمر. يمكن لهذه القناة أن تبيّن من يدرجه الـ focus ضمن المشاركين بعد عملية دعوة أو إنهاء متعددة.

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

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

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

الرد الأصلي سبق العمل المطلوب

في مخطط RFC يرسل المشرف REFER إلى خادم مؤتمر ويستقبل 202 Accepted. بعد ذلك فقط يرسل الخادم طلبات BYE إلى الأهداف. لا يستطيع حدث سابق أن يثبت النتائج النهائية لأحداث لم تبدأ بعد.

يثبت 202 أن مستقبل REFER قبل مسؤولية محاولة العملية وفق سياسته. لا يثبت وجود كل حوار، ولا إرسال كل BYE، ولا قبول الطرف البعيد، ولا تغير العضوية.

ويؤدي المستقبل دورين مختلفين. هو UAS أمام مُصدر REFER، ثم يصبح UAC أمام كل هدف. الانتقال بين الدورين ينشئ معاملات جديدة وهوية تشغيلية وقرارات صلاحية منفصلة.

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

القناة المعتادة للنتائج أُغلقت عمداً

ينشئ REFER أحادي الهدف عادة اشتراكاً ضمنياً في حدث refer. ترسل طلبات NOTIFY أجسام message/sipfrag لتصف تقدم المعاملة التي بدأها المستقبل.

عند تعدد الأهداف لا توجد معاملة واحدة تمثل الجميع. قد يرفض هدف، ويعيد آخر التوجيه، وينتهي ثالث، بينما لا يزال رابع ينتظر. لم تعرف RFC 5368 صيغة تجمع هذه الحالات مع الحفاظ على هوية كل هدف.

بدلاً من اختراع حالة جامعة، توصي بـ norefersub وبقيمة Refer-Sub: false. وعلى المستقبل أن يعيد false في 200 وألا ينشئ الاشتراك الضمني.

غياب NOTIFY بعد ذلك سلوك متفق عليه. لا يعني «لم يحدث خطأ»، ولا «نجحت كل الأهداف». إذا حوّل نظام المراقبة الصمت إلى نجاح، فهو يستخرج دليلاً إيجابياً من قناة حُذفت قصداً.

الطلب اقترح الإخماد والرد منحه أو رفضه

القيمة false في الطلب ليست النتيجة النهائية للتفاوض. false في رد 2xx هي التي تؤكد موافقة المستقبل. إذا غاب الحقل أو عاد true، ينشأ الاشتراك الضمني المعتاد.

حفظ الطلب وحده يسجل رغبة العميل لا العقد الفعلي. وحفظ الرد وحده يفقد الوسوم المطلوبة وRefer-To والقائمة والطريقة المقصودة. يجب ربط الرسالتين.

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

الصمت احتاج دليلاً على عدم التفرع

للاشتراك الضمني وظيفة أخرى: إظهار الحوارات المتعددة إذا تفرع REFER. ولهذا لا تسمح RFC 4488 بطلب false إلا عندما يكون المُصدر متيقناً أن الطلب لن يتفرع.

يستخدم مثال RFC 5368 عنوان GRUU لتحقيق هذا الشرط. العنوان جزء من الدليل الذي يربط قرار الاشتراك بمستقبل واحد. اسم خدمة عام خلف موزع حمل لا يكفي تلقائياً؛ يجب معرفة إن كان مستوى SIP يستطيع التسليم إلى وكلاء مستقلين متعددين.

يسجل الدفتر Request-URI ومسار التوجيه وأساس عدم التفرع وفرع الرد وهوية المستقبل. وسم norefersub بلا هذا السياق يحفظ النتيجة وينسى شرط صلاحيتها.

مرجع cid ربط السلطة ببايتات محددة

لا يحمل Refer-To الأهداف مباشرة، بل يحمل URL من نوع Content-ID، فيما توجد القائمة في المتن. يجب أن يبقى المعرّف ونوع المحتوى وContent-Disposition وحدود MIME والبايتات والهاش معاً.

كشفت RFC 8262 غموضاً سابقاً. أظهرت أمثلة في RFC 5368 الإشارة إلى متن رسالة كامل، بينما كانت القواعد المتاحة تعرف الإشارة إلى جزء من المتن. فسّر منفذون كثيرون المثال كأنه سماح. وقد أجاز التحديث لاحقاً الإشارة صراحة إلى جزء أو إلى المتن كاملاً، باستعمال Content-ID على مستوى MIME أو SIP.

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

القائمة لم تمنح كل طريقة المعنى نفسه

تسمح صيغة القائمة بسمات copyControl وإخفاء الهوية. قد يكون لهذه السمات أثر مفهوم مع INVITE، لكنها لا تمنح BYE داخل حوار معنى نسخ إلى أو نسخة كربونية.

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

تسجيل multiple-refer وnorefersub لدى IANA يثبت مفردات مشتركة فقط. لا يثبت تفعيلها في نظام، ولا صلاحية مستخدم، ولا إصدار طلب، ولا نتيجة هدف.

كذلك قد تُدمج URI متكررة وفق قواعد المقارنة. يجب حفظ القائمة المستلمة والمجموعة الفعلية والطلبات الصادرة، حتى لا يُفسر الدمج كفقد أو يُخفى الفقد باسم التطبيع.

حد الإثبات

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

السلسلة الدنيا تشمل هوية المُصدر وتفويضه، وسياق التطبيق، ودليل عدم التفرع، والطلب والرد، وقيمة Refer-Sub العائدة، وكائن Content-ID، والقائمة الأصلية والمطبعة، وكل طلب فرعي، ونتيجته، وحالة الخدمة بإصدار وزمن، ثم النتيجة الإنسانية أو التجارية مستقلة.

يجمع البروتوكول الأمر ولا يجمع الحقائق التي تنتج عنه. المحافظة على هذا الفرق هي ما يجعل الكفاءة قابلة للمراجعة.