الخلاصة

  • يجيز RFC 9878 ترويستي P-Access-Network-Info وP-Charging-Vector في ACK الذي تطلقه استجابة 2xx، ويحظرهما في ACK المرتبط باستجابة غير 2xx.
  • يثبت ذلك جواز حمل الحقل في سياق محدد، ولا يثبت هوية من أضافه أو حداثته أو اكتمال تغيير مسار الحمل أو صحة السعر.
  • يحتاج الإثبات القابل للمراجعة إلى سياق SIP، وسلسلة حماية بين القفزات، وNPLI، ومسار اتجاهي، وحدث bearer، وCDR، وقاعدة تسعير ومسار اعتراض.

قد يرى محرك التحاسب كلمة ACK وترويسة للشحن فيحوّل السجل فوراً إلى «مكتمل». إلا أن ACK لا يحمل معنى واحداً في كل الحالات. فالرسالة التي تتبع نجاح INVITE ليست كالرسالة المرتبطة برد نهائي فاشل، حتى لو اشتركتا في اسم الطريقة.

صدر RFC 9878 في نوفمبر 2025 لتصحيح هذا النوع من الالتباس. فهو يحدث RFC 7315، ويلغي RFC 7976، ويوحد جدول مواضع الترويسات الخاصة بعدما تعارض مع تعريفاتها. الإصلاح مهم للتشغيل البيني، لكنه لا يرفع البيانات المحمولة إلى مرتبة الحكم النهائي.

ACK الذي سبقته استجابة ناجحة

يمكن أن تحمل P-Access-Network-Info معلومات الموقع المقدمة من الشبكة، NPLI. ويمكن أن تحمل P-Charging-Vector هوية التحاسب في IMS ومعرفات المشغلين. يسمح النص الجديد بهما في ACK الناشئ عن 2xx فقط؛ أما ACK الناشئ عن استجابة غير 2xx فلا يجوز أن يتضمنهما.

لذلك لا يكفي تخزين method=ACK. يميز RFC 3261 معالجة ACK النجاح عن ACK الفشل على مستوى المعاملة. يجب حفظ فئة الرد النهائي وCall-ID والوسوم وCSeq والاتجاه والوكيل الذي عالج الانتقال. من دون هذه القرائن لا يمكن إثبات أن الترويسة كانت في الفرع المسموح.

توضح حالة NPLI الحاجة العملية. قد تحمل استجابة 2xx لـINVITE جواب SDP يجعل الوكيل يبدأ تعديل bearer. تحتاج سجلات CDR في IMS إلى معلومات الموقع في لحظة كهذه كي تدعم التحاسب الصحيح، فيحصل الوكيل على NPLI ويضعها في ACK التالي.

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

مصفوفة ضيقة لست ترويسات

تعكس بقية التصحيحات الدقة نفسها. تظهر P-Associated-URI في ردود REGISTER من فئة 2xx لا في طلب REGISTER على إطلاقه. وتقتصر P-Called-Party-ID على قائمة طلبات أضيف إليها REFER، ولا يسمح بها في كل الردود. وقد تظهر P-Visited-Network-ID في الردود غير 100 مع استثناء طرق مسماة. وتظل P-Charging-Function-Addresses ممنوعة في ACK وCANCEL.

تجيب المصفوفة عن سؤال «هل يجوز أن يوجد الحقل هنا؟». ولا تجيب عن «من كتبه وبأي سلطة؟». يوفر سجل IANA لمعاملات SIP أسماء ومراجع موحدة، لكنه لا يوثق كل نسخة تمر في الشبكة.

وينبه RFC 9878 إلى أن بعض التطبيقات المنشورة قد لا تكون حدثت. قد يعني الغياب نسخة قديمة أو سياسة محلية أو حالة غير منطبقة أو فشلاً فنياً. وقد يعني الظهور غير المتوقع تفسيراً سابقاً أو خللاً أو إدخالاً غير موثوق. لا تحسم المشاهدة السبب من دون نسخة البرنامج ومسار الرسالة.

التغيير المشروع يحتاج إلى سجل حيازة

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

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

ولا تمثل قيم transit-ioi خريطة كاملة للمكالمة. قد ترشحها شبكة أو تحذفها أو تستبدلها بقيمة فارغة. ويبين RFC 9878 أن اختيار مشغل العبور يمكن أن يتغير لكل طريقة SIP ولكل اتجاه، وفق الحمل أو التكلفة أو النسبة أو الوقت. مسار INVITE ليس برهاناً على مسار ACK أو الاتجاه المعاكس أو الجلسة كلها.

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

من الرسالة إلى بند الفاتورة

يبدأ السجل المفيد بالرسالة الخام وتوقيتها وفئة الرد وإحداثيات الحوار والمعاملة والاتجاه ونسخة كل وكيل والسياسة السارية. ولكل P-Header يحفظ مدخل الثقة والجهة التي أضافته أو عدلته ونتيجة حماية القفزة والبصمة قبل التعديل وبعده. وتضاف إلى NPLI جهة المصدر والوقت والدقة والغرض المسموح.

بعد ذلك تربط الإشارة بصورة مستقلة مع جواب SDP وحدث إنشاء bearer أو تعديله أو إنهائه، ثم مع CDR وقاعدة rating وحساب بند الفاتورة. ICID أداة ربط وليس تفويضاً بالتحصيل. إذا فشل الربط فالحالة الصحيحة هي «بانتظار المطابقة»، لا ملء الفراغ بمجرد وجود الترويسة.