الخلاصة

  • كان الرد الناجح على REFER في RFC 3515 يعني أن المتلقي قبل مسؤولية معالجة التعليمات والإبلاغ عن حالتها؛ ولم يكن يعني أن الطلب المحال انتهى بنجاح.
  • كان لكل من اشتراك refer الضمني، وإشعارات NOTIFY ذات محتوى message/sipfrag، والإجراء المحال دورة حياة مستقلة. إيقاف المراقبة لا يلغي التنفيذ، ولا يجوز دمج حالات الاشتراكات المتفرعة.

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

عرّف RFC 3515، بصفته وثيقة على مسار المعايير آنذاك، طريقة REFER وحقل الترويسة Refer-To وحزمة الحدث refer. يحدد Request-URI الجهة التي تتلقى التعليمات، بينما تحدد قيمة واحدة فقط في Refer-To المورد الذي ينبغي الاتصال به. بعد ذلك يستخدم المتلقي الآلية المعتادة لنوع URI: قد ينشئ طلب INVITE جديداً لعنوان SIP، أو يشغّل إجراءً تابعاً لبروتوكول آخر.

لذلك لم يكن REFER مواصفة خاصة بتحويل المكالمات فقط. سمح RFC بوجود جسم للرسالة من دون أن يمنحه معنى عاماً. يستطيع المتلقي تفسير ذلك الجسم وفق Content-Type، لكن هذا التفسير المحلي لا يحوّل أي حمولة مرفقة إلى تعليمات معيارية.

كان على المتلقي أولاً أن يقرر هل يقبل الطلب. قد تؤدي صياغة غير سليمة أو مخطط URI غير مدعوم أو فشل المصادقة أو السياسة المحلية إلى الرفض. أما الطلب السليم فكان ينبغي أن يحصل على موافقة المستخدم أو على سماح مقرر سلفاً في السياسة. وإذا لم ينطبق رد نهائي آخر، طلبت المواصفة الأصلية إرسال 202 Accepted قبل انتهاء معاملة REFER.

كلمة «Accepted» هي موضع الالتباس. فهي تغلق سؤالاً محدوداً: هل قَبِل الوكيل مسؤولية معالجة REFER؟ لا تقول إن INVITE اللاحق تلقى 200 نهائياً، ولا إن مورداً خارج SIP استجاب، ولا إن الوسائط تدفقت، ولا إن شخصاً شارك، ولا إن الغرض التشغيلي تحقق. بل ربما لم يكن الطلب المحال قد أُرسل بعد عند صدور 202.

في العقد الأصلي لـ RFC 3515، كان الرد من فئة 2xx ينشئ أيضاً اشتراكاً ضمنياً في حدث refer. ثم يرسل الوكيل الذي قبل الطلب إشعارات NOTIFY. لم تكن تلك القناة زينة تشغيلية؛ بل كانت تحمل أدلة التقدم التي لا يستطيع رد REFER أن يقدمها بصدق.

كان من الممكن أن يصل أول NOTIFY قبل اكتمال معاملة REFER نفسها. وهكذا كان على المرسل أن يتحمل انقلاباً ظاهرياً في ترتيب الزمن: يبدأ مسار المراقبة فيما لا يزال تبادل القبول يُغلق. وقد لا يحتوي إشعار الحالة المعلقة إلا على SIP/2.0 100 Trying. هذا وصف لحالة جارية، وليس دليلاً على الوصول إلى الهدف.

حمل كل NOTIFY القيمة Event: refer وجسماً من نوع message/sipfrag يبدأ بسطر حالة SIP. وكانت فئة الرد تصف وضع الإجراء المحال عند نقطة الإبلاغ تلك. اعتبر RFC كل جسم تصريحاً كاملاً بالحالة في لحظته، لا فرقاً جزئياً لا يُفهم إلا بإعادة بناء جميع الرسائل السابقة.

يمكن للتنفيذ الأدنى أن يستخدم 100 للحالة المعلقة، و200 للنجاح، و503 للفشل، و603 عندما تُرفض الموافقة بعد أن كان REFER قد قُبل. تكشف هذه السلسلة لماذا كان 202 الأول أضعف عمداً من إثبات النجاح: قد يُقبل التفويض، ثم تُرفض الموافقة، أو يفشل التنفيذ اللاحق، أو تناقض النتيجة النهائية التفاؤل الذي ولّده الإيصال الأول.

وكان هناك رقمان مختلفان من فئة 200 ينبغي عدم الخلط بينهما. يرد وكيل المستخدم على معاملة NOTIFY نفسها بـ 200 OK ليثبت وصول التقرير. أما سطر الحالة داخل message/sipfrag فيصف معاملة الإجراء المحال. إن اختزال السطرين إلى كلمة «200» في سجل أو لوحة مراقبة يمحو حدوداً مهمة بين الدليلين.

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

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

كان للاشتراك عمر خاص. لم يحمل REFER مدة لذلك الاشتراك في الطلب أو الرد. يختار الوكيل القابل المدة ويعلنها في أول NOTIFY، وغالباً يجعلها طويلة بما يكفي لإنهاء الطلب المحال. ويمكن للمُحيل تجديد الاشتراك أو إنهاؤه مبكراً.

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

هذه ليست غرابة تاريخية في SIP. تخطئ أنظمة كثيرة عندما تفسر «لا ترسل إلي مزيداً من التحديثات» بمعنى «أوقف العمل»، أو عندما تعتبر اختفاء صف من لوحة التحكم دليلاً على انتهاء المهمة. اختار RFC 3515 العكس: الاشتراك يتحكم في الرؤية؛ أما الطلب المحال فيحتفظ بقواعد معاملته وإلغائه.

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

ربطت معرّفات الحوار كل NOTIFY بالاشتراك الصحيح، لكن الارتباط لا يغني عن التخويل. كان على المتلقي أن يقرر من يحق له أن يجبره على الاتصال بأي مورد. وقد تحوّل سياسة متساهلة REFER إلى طريق غير مباشر نحو موارد SIP أو HTTP أو غيرها من الأهداف المحمية. لذلك كان بناء Refer-To والقرار المحلي جزءاً من الحد الأمني.

عدلت RFCs لاحقة شكل قناة المراقبة. سمح RFC 4488 بطلب إلغاء الاشتراك الضمني، وعرّف RFC 7614 الاشتراك الصريح، ووضح RFC 7647 سلوك REFER ضمن إطار الأحداث الذي حدثه RFC 6665، بينما حسّن RFC 8217 قواعد تركيب ذات صلة. لم تجعل أي من هذه التحديثات القبول والنتيجة شيئاً واحداً. بل تجعل تسجيل العقد الذي حكم الأثر أكثر أهمية.

يفيد هنا تمييز Heng Lu بين الواقع الرمزي والواقع التشغيلي. إن 202 إيصال رمزي لمسؤولية محدودة. وNOTIFY تقرير صادر عن مُخطر معلوم داخل اشتراك محدد. ويجري الطلب المحال وفق بروتوكوله الخاص. ثم تأتي الوسائط والكلام والموافقة البشرية والنتيجة التجارية في طبقات أبعد. صحة رسالة في طبقة لا تنشئ إيصالات الطبقة التالية.

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

لا تقول لنا قصة RFC 3515 إن التفويض غير موثوق. بل تقول إن التفويض يحتاج سجلات منفصلة للتعليمات والمراقبة والتنفيذ. لقد قُبل REFER، وهذا حقيقي ومفيد. لكن الإجراء ما زال يتعين أن يحدث في مكان آخر، وكان نجاحه يحتاج دليلاً خاصاً به.

المصادر