الخلاصة

  • أتاحت RFC 3326 لطلب SIP حمل سبب إرساله، سواء أكان رمز حالة SIP أم سبباً من Q.850 عند الربط مع شبكة الهاتف.
  • لا يغيّر الحقل معالجة SIP: تظل CANCEL مسؤولة عن الإلغاء، بينما يمكن لـ Reason الإشارة إلى أن فرعاً آخر أكمل المكالمة.

أجاب فرع واحد، لكن كان لا بد من إيقاف البقية

يرسل وكيل INVITE عبر عدة فروع. يجيب أحد الوجهات بـ 200 OK، لكن الهواتف الأخرى قد تظل ترن. لذلك يرسل الوكيل CANCEL إلى تلك الفروع. الذي يوقف التنبيه هو أسلوب SIP المسمى CANCEL، لا حقل يروي ما حدث.

قدمت RFC 3326، المنشورة في ديسمبر 2002، وسيلة لإرفاق ذلك التفسير: Reason: SIP;cause=200;text="Call completed elsewhere". يستطيع النظام المستقبِل التمييز بين مكالمة أجاب عنها فرع آخر ومكالمة تُركت قبل الرد. قد يؤثر ذلك في سجل المكالمات الفائتة أو واجهة المستخدم، مع أن الإجراء البروتوكولي الفوري واحد.

هذا الفصل هو قرار التصميم المحوري. كان لدى SIP رموز حالة للردود، لكن الطلب نفسه قد يُرسل لأسباب مختلفة، ولا يحمل عادةً الرد الذي دفع إلى إرساله. يربط Reason السبب بالطلب الذي تصرّف بناءً عليه. إنه بيانات تفسيرية، لا قناة أوامر ثانية.

لكل سبب مساحة بروتوكولية

تحدد RFC 3326 معنى القيمة باسم البروتوكول. تشير SIP إلى أن المعامل cause يحمل رمز حالة SIP؛ أما Q.850 فيشير إلى قيمة عشرية من نظام الإشارات الهاتفية لدى ITU-T. وهكذا يمكن للبوابة نقل سبب إنهاء من شبكة الهاتف داخل رسالة SIP. فالرقم وحده لا يكفي؛ اسم البروتوكول يحدد نظام الترقيم الذي أتى منه.

يساعد المعامل text القارئ، لكنه لا يملك سلطة معالجة البروتوكول. ينتمي السبب إلى مفردات البروتوكول المذكور، بينما تحدد الرسالة نفسها الأسلوب والحالة وسياق المعاملة. اعتبار cause=200 ردّاً بحد ذاته، أو قراءة قيمة Q.850 كأنها حالة SIP، يخلط بين سطحي تحكم منفصلين.

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

ردّ قد يخفيه تشعّب الفروع

ربطت المواصفة أيضاً Reason بمشكلة ردود الخطأ المختلفة في الطلبات المتشعبة. فقد يتلقى INVITE إخفاقات نهائية مختلفة في كل فرع. ولأن الوكيل ينتظر عادةً نتائج الفروع قبل تقرير ما يرسله إلى الجهة السابقة، قد يظل خطأ مهم غير ظاهر بينما ينتظر فرع آخر. وذكرت RFC 3326 أن تضمين حالة نهائية داخل رد مؤقت قد يكون استخداماً مناسباً لـ Reason.

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

أبقت التوسعات اللاحقة الحدّ واضحاً

أضافت RFC 8606 لاحقاً معامل موقع ISUP إلى أسباب Q.850، كي تحفظ الإشارات موضع بدء الإنهاء عند توافر تلك المعلومة. ثم خففت RFC 9366 قاعدة القيمة الواحدة لكل بروتوكول، لكن فقط عندما يعرّف البروتوكول المسجل معنى تعدد القيم. في الحالتين، زادت البنية دقة المصدر ولم تحوّل Reason إلى العملية نفسها.

يساعد ذلك أيضاً في قراءة تاريخ البروتوكولات. تناولت RFC 3087 استخدام Request-URI كسياق محلي لاختيار خدمة، بينما ألحقت RFC 3326 سبباً بإجراء SIP تم اختياره بالفعل. الأولى تختار وجهة الطلب، والثانية تشرح لماذا أُرسل. ولا تثبت أي منهما المصادقة أو التفويض أو السجل الكامل للمكالمة أو نتيجة لاحقة.

المصادر

  1. https://www.rfc-editor.org/rfc/rfc3326.html
  2. https://www.rfc-editor.org/info/rfc3326/
  3. https://www.rfc-editor.org/rfc/rfc3261.html
  4. https://www.rfc-editor.org/rfc/rfc9366.html
  5. https://www.rfc-editor.org/rfc/rfc8606.html
  6. https://www.rfc-editor.org/rfc/rfc5411.html
  7. https://www.rfc-editor.org/rfc/rfc4411.html