الخلاصة

  • أتاح RFC 3327 للوكلاء إضافة Path مرتب أثناء مرور REGISTER؛ وبعد نجاح التسجيل، ربط خادم التسجيل هذا المتجه بربط AOR وContact وأعاده في الاستجابة.
  • كان بوسع الوكيل المنزلي إدراج المتجه المحفوظ لاحقًا في ترويسة Route للطلبات المتجهة إلى ذلك Contact. لكنه لم يكن دليلًا على العقد التي اجتازتها حزمة REGISTER بالفعل.

حوار ينتهي وربط يواصل العمل

يستطيع خادم تسجيل SIP حفظ العنوان الذي يمكن الوصول عنده إلى وكيل المستخدم (UA). يجيب هذا الربط عن سؤال محدود: أي Contact ينبغي أن يتلقى طلبًا موجّهًا إلى عنوان السجل (AOR)؟ لكنه لا يجيب بالضرورة عن سؤال آخر: ما الوكلاء الوسيطون الذين يجب أن يعبرهم الطلب كي يبلغ ذلك Contact؟

تظهر الفجوة عندما يمر REGISTER عبر وكلاء طرفيين لا يستطيع الوكيل المنزلي إعادة استنتاجهم من DNS أو من جداول توجيهه. فقد يسجل UA من شبكة زائرة، بينما يوجد خادم التسجيل في مكان آخر، ويحتاج طلب وارد لاحق إلى المرور عبر عقد لا يكشفها URI الخاص بـ Contact. أتاح RFC 3327، المنشور في ديسمبر 2002، لهذه العقد أن تترك متجه توجيه ضمن تبادل التسجيل.

قد توحي كلمة Path بأنه قياس لمسار الشبكة، لكن ذلك لم يكن دورها. كان بإمكان وكيل يعبره REGISTER إضافة قيمة Path. ويحفظ خادم التسجيل القيم المرتبة مع ربط Contact وAOR، ثم يعكسها في استجابة REGISTER ناجحة. وعندما يسترجع الوكيل المنزلي ذلك الربط لاحقًا، يمكنه وضع المتجه المحفوظ في ترويسة Route مُحمّلة مسبقًا وإرسال الطلب الجديد عبر تلك الوكلاء. ما حُفظ هو مرجع توجيه يحتاجه الربط، لا التقاط لحزم معاملة REGISTER.

مسار يتجاوز عمر المعاملة

يشبه Path ترويسة Record-Route، لكن لكل منهما أفق زمني مختلف. تحدد Record-Route التوجيه للطلبات داخل الحوار الذي أنشأها. أما Path فتنتقل عبر REGISTER واستجابته الناجحة كي تُستخدم سلسلة الوكلاء في حوارات لاحقة. تتولى آليات التوجيه القائمة في RFC 3261 تنفيذ Route؛ ويعبر RFC 3327 بهذه السلسلة حدود التسجيل.

كان النطاق محددًا: تنطبق الآلية على الطلبات العابرة لنطاق المستخدم المنزلي أو الصادرة منه. وتتبع القيم صياغة عنصر Route وتستخدم معامل التوجيه المرن ;lr. يستطيع UA إعلان الدعم عبر Supported: path؛ وعادة ينبغي للوكلاء ألا يضيفوا Path ما لم يعلن UA هذا الدعم. وإذا تلقى خادم التسجيل Path من دون ذلك الإعلان، أوصى RFC بالرفض مع ترك مجال للسياسة المحلية.

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

المتجه ليس شاهدًا

سمح RFC 3327 صراحةً لوكيل واعٍ بالطوبولوجيا بإضافة قيمة Path تشير إلى عقدة أخرى، حتى إذا لم تطابق المسار الذي سلكه REGISTER بالفعل. وهذا يحسم طريقة فهم Path: إنها وصفة توجيه مرتبة تُركّب وفق سياسات الوكلاء وخادم التسجيل، وليست دليلًا جنائيًا على عبور الحزم. ولا تستطيع وحدها إثبات أن وكيلًا مرر رسالة سابقة، أو أن المسار المقترح ما زال قابلًا للوصول، أو أن اتصالًا مستقبليًا سيصل.

أنشأ هذا الخيار أيضًا حدًا أمنيًا. فالوكيل الذي يُدرج في المتجه المحفوظ قد يظهر في الطلبات المستقبلية وربما يعترض المكالمات. لذلك ناقش RFC 3327 سلامة النقل والمصادقة المتبادلة، مثل TLS أو IPsec، ووصف نسخًا محمية عبر S/MIME تتيح لـ UA اكتشاف التغييرات في Path المعادة. صحة URI نحويًا لا تعني أن الوكيل الوسيط مخوّل.

أعادت أعمال لاحقة استخدام الآلية لغرض أضيق. يضع RFC 5626 رمز تدفق فريدًا في Path كي يربط وكيل طرفي طلبًا مستقبليًا باتصال بدأه العميل بعينه. هذه المعالجة الخاصة بكل تدفق تنتمي إلى التوسعة اللاحقة، ولا ينبغي إسقاطها على كل متجه في RFC 3327. أما Service-Route في RFC 3608 فيعمل بالاتجاه المعاكس: يمنح UA مسارًا لطلباته الصادرة، لا للطلبات الواردة إليه.

المصادر