الخلاصة

  • يجيز RFC 9970 حقل Identity في ردود SIP المؤقتة والنهائية، فيعالج سؤالاً لا تجيب عنه هوية STIR الخاصة بالمنشئ: من الذي أجاب عن المكالمة؟
  • يحمل rsp ادعاء هوية من الطرف الذي اتصلت به المكالمة، ويحمل div سجلاً لتحويل الهدف. لا يحكم أي منهما بأن الهدف الجديد مقبول في كل سياق.
  • يجب فصل الوجهة المطلوبة، ودليل الرد، وسلسلة التحويل، والتوقعات، وحرجية العملية، والنتيجة، ومسؤول الاستثناء. قابلية تبادل الدليل ليست سلطة تلقائية على القرار.

المكالمة التي وصلت ليست بالضرورة المكالمة التي قصدتها

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

RFC 9970 هو Proposed Standard من IETF نُشر في يونيو 2026 ويحدّث connected identity في STIR. في الاتصال البسيط، يطابق address of record الذي تم الوصول إليه قيمة dest في PASSporT الذي بدأ INVITE. وتسمح الوثيقة بردود مؤقتة أو نهائية موقعة؛ ويستخدم PASSporT الخاص بالرد عادة النوع rsp. هكذا يحصل المتصل على ادعاء قابل للتحقق عن الطرف الذي رد في هذا الحوار.

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

صحة التوقيع لا تختار مستوى المخاطرة

التحقق من rsp يثبت حقائق تشفيرية وحقائق خاصة بالملف التشغيلي، لكنه لا يعرف سبب الاتصال. قد يكون الرد من مفوض غير متوقع مقبولاً في استعلام عام، وغير مقبول في اتصال لتأكيد دفعة. يمكن أن تكون الإشارة صحيحة في الحالتين ويكون قرار الإتمام مختلفاً.

يتصور RFC 9970 أن يضع المتصل أو نظامه وضع حرجية للمكالمة أو الوجهة. وعند غياب الهوية المتصلة أو اختلافها عن المتوقع، يمكن للجهاز ألا يتم المكالمة. لا تفرض RFC عتبة ولا واجهة ولا قناة بديلة ولا صاحب استثناء. وهذا التقيد مقصود: الطرف الذي يعرف الغرض ويتحمل الخسارة هو من يحدد كفاية الدليل.

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

التحويل يحتاج إلى سلسلة مرئية، لا إلى رواية لاحقة

يعرّف RFC 8946 امتداد div في PASSporT عندما تكتسب المكالمة هدفاً جديداً. يمكن لخدمة التحقق في النهاية أن تفهم منه سبب وصول المكالمة إلى مقصدها الأخير. لكن ما يراه الطرف المنهي ليس بالضرورة ما يراه المتصل. يوضح RFC 9970 أن retargeting المعتاد لا يعيد بالضرورة أدلة التحويل إلى المتصل؛ أما SIP 3XX فهو الطريق المعرّف حالياً لإظهار معلومات التحويل بصورة آمنة في الاتجاه العكسي.

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

سلامة الحوار ليست ثقة في الإنسان أو في الوسائط

بعد إنشاء connected identity، يوصي RFC 9970 بوضع PASSporT صالح في re-INVITE وBYE. هذا يجعل تزوير تعديل الحوار أو إنهائه أصعب على طرف ثالث، وهو مكسب محدد لإشارات SIP. لكنه لا يثبت من يتكلم، ولا أن الوسائط لم تستبدل، ولا أن مضمون المحادثة مخول للعمل التجاري.

ينبغي أن تبقى المسؤوليات منفصلة: فريق الصوت يتحقق من البروتوكول؛ مالك العملية يحدد الدليل الكافي للإفصاح أو التنفيذ؛ وفريق الأمن يحتفظ بالرؤوس ونسخة السياسة والنتيجة. تسمية واحدة مثل «مكالمة موثقة» تخفي قرارات ثلاثة أطراف.

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

Sources