الخلاصة

  • أتاح RFC 3326 لطلب SIP أن يحمل السبب البروتوكولي الذي أدى إلى صدوره، فبقيت علة CANCEL أو BYE منفصلة عن الفعل نفسه.
  • كان Reason اختياريا ويمكن تجاهله ولا يغير معالجة SIP؛ لذلك لا تثبت قيمته وحدها الحدث أو المراقب الأصلي أو صحة الترجمة أو استخدام المستقبل لها.

النسخة الأخيرة لم تكن الشاهد الأول

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

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

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

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

لم يحصر RFC 3326 الحقل في CANCEL. يمكن أن يظهر في أي طلب داخل حوار، وفي أي CANCEL، وفي استجابة يسمح رمزها بذلك صراحة. قد ينهي عميل جلسة بعد أن يتلقى عرضا غير مقبول داخل استجابة ناجحة، فيرسل BYE بسبب SIP 488. وقد يرى متحكم طرف ثالث أن B مشغول في حوار، ثم ينهي حواره مع A مستخدما السبب 486.

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

التفسير لم يكن أمرا ثانيا

سمح النص للعملاء والخوادم بتجاهل Reason، وصرح بأن الحقل لا يؤثر في معالجة البروتوكول. تنجح CANCEL في الإلغاء حتى إذا غاب السبب أو لم يفهمه المستقبل. وينهي BYE الحوار وفق قواعد SIP، لا وفق العبارة المقروءة في الحقل.

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

تبدأ كل قيمة باسم protocol، ثم يمكن أن تحمل cause رقميا وtext بين علامتي اقتباس وامتدادات. كانت SIP وQ.850 أول مساحتين معرفتين. لا يحمل الرقم معنى مستقلا عن مساحته. حذف اسم البروتوكول من قاعدة البيانات يخلط رمز حالة SIP بسبب إطلاق هاتفي.

أما النص فمساعدة بشرية، لا المصدر القانوني للمعنى الآلي. يمكن أن يترجم أو يختصر أو يكتب بصورة خاطئة. يجب حفظ البروتوكول والسبب والنص والامتدادات كحقول منفصلة، مع الإبقاء على الرسالة الأصلية.

سمحت القاعدة الأولى بقيم متعددة فقط عندما يختلف البروتوكول في كل قيمة. عدّل RFC 9366 ذلك: يمكن تكرار بروتوكول مسجل إذا كان تعريفه يحدد معنى وجود عدة قيم. وإذا لم يحدد، يبقى حد قيمة واحدة لكل بروتوكول. لا يجوز للمحلل أن يخترع سياسة جمع أو أولوية من شكل القائمة وحده.

يوفر سجل معلمات SIP لدى IANA المرجع لأسماء البروتوكولات والمعلمات. وهو جزء من سياق التفسير، لا مجرد قائمة إدارية. يجب أن يعرف نظام الأرشفة أي قواعد تسجيل استخدمها حين فسر القيمة.

البوابة حفظت السبب وغيرت لغته

وصف RFC 3398 خرائط ISUP إلى SIP. عندما تصل رسالة تحرير من الشبكة الهاتفية، يمكن للبوابة أن تنشئ CANCEL في SIP وأن تضع سبب Q.850 الوارد في Reason. بدلا من رؤية الإلغاء المجرد، يرى طرف SIP تفسيرا آتيا من الشبكة الأخرى.

سمح RFC 6432 بوضع سبب Q.850 في استجابات SIP ما عدا 100 Trying. ثم أضاف RFC 8606 المعلمة location عندما يكون موضع التحرير في ISUP متاحا. الموضع يحدد قسما عاما من الشبكة، مثل الشبكة المحلية أو العابرة أو البعيدة، ولا يحدد المكان الفعلي أو هوية المتصل أو المتلقي.

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

يتناول History-Info في RFC 7044 وآلية Diversion التاريخية في RFC 5806 تاريخ إعادة الاستهداف والتحويل. لا يجيبان عن السؤال نفسه. المسار لا يثبت سبب التحرير، والسبب لا يعيد بناء كل وجهات المسار. جمع الطبقتين ممكن، ودمجهما في حقيقة واحدة خطأ.

سلامة البايتات لا تثبت سلامة التاريخ

في مشكلة HERFP قد يبقى الخطأ النهائي لفرع مخفيا عن العميل ما دامت فروع أخرى نشطة. تصور RFC 3326 استخدام Reason لحمل النتيجة النهائية داخل استجابة مؤقتة. تزوير الحقل أو حذفه قد يمنع العميل من تحديث طلبه السابق ويجعل إنشاء الجلسة مستحيلا. لذلك أوصى بحماية مناسبة للسلامة.

إذا نجحت الحماية، فهي تثبت أن البايتات المحمية لم تتغير بين نقطتين معلومتين. لا تثبت أن الحدث الخارجي وقع، ولا أن المرسل الأول كان صادقا، ولا أن خريطة Q.850 إلى SIP كانت صحيحة. وإذا غابت الحماية لا تصبح القيمة عديمة الفائدة، لكن الثقة تنخفض ويجب طلب أدلة مساندة قبل الأتمتة.

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

المصادر