الخلاصة

  • يضع العميل rport بلا قيمة كي يطلب إرسال الاستجابة إلى عنوان IP ومنفذ UDP اللذين وصل منهما الطلب فعلياً. وصول الاستجابة يثبت مسار هذه المعاملة خلال ربط NAT القائم آنذاك، ولا يثبت مساراً مستقبلياً.
  • للهوية والتسجيل والتدفق وربط NAT والمعاملة والحوار والنتيجة مدد وسلطات مختلفة. اختزالها في حالة واحدة اسمها «متاح» يمحو الدليل اللازم لتفسير الفشل اللاحق.

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

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

صدرت RFC 3581 في أغسطس 2003 ضمن Standards Track. أهم ما فيها أنها لا تخفي حدود الحل. تصلح وجهة الاستجابة لمعاملة واحدة، ثم تناقش صراحة هشاشة استخدام المعلومة نفسها لتثبيت عنوان تسجيل أو Record-Route.

كانت وجهة الاستجابة مركبة من مصدرين

في SIP فوق UDP، أخذت القاعدة الأصلية عنوان IP من مصدر الحزمة، لكنها أخذت المنفذ من sent-by في أعلى Via. ساعد ذلك الخادم على الاستماع في نقطة معلنة واحدة. غير أن NAT قد يغيّر العنوان والمنفذ معاً، فيصبح نصف الوجهة من الواقع الخارجي ونصفها من إعلان داخلي لم يعد قابلاً للوصول.

يضيف العميل rport فارغاً. الفراغ مقصود: العميل لا يدّعي معرفة المنفذ العام، بل يطلب من المستقبل أن يكتب ما شاهده. يملأ الخادم rport بالمنفذ المرصود وreceived بالعنوان المرصود، حتى عندما يساوي العنوان قيمة sent-by.

عند استخدام نقل unicast غير موثوق وغياب maddr، تُرسل الاستجابة إلى received:rport. ويجب أن تخرج من عنوان الخادم ومنفذه اللذين استقبلا الطلب. ففي NAT المتماثل قد يكون الطرف البعيد جزءاً من مفتاح الربط.

إذن لا تقول الآلية «ثق بالرأس». تقول: اربط استجابة هذه المعاملة بملاحظة حديثة على السلك.

الملاحظة الصحيحة لا تكتسب سلطة الهوية

قد يعلن Via العنوان 10.1.1.1:4540 بينما يرى الوكيل 192.0.2.1:9988. الزوج الثاني وجهة صحيحة للاستجابة الآن، لكنه ليس اسم الشخص أو Address-of-Record أو معرّف الجهاز أو حجزاً دائماً للمنفذ العام.

وللدليل درجات. rport الفارغ يثبت طلب السلوك. الرقم في الاستجابة يثبت ما كتبه الخادم. وحده استلام العميل يثبت أن الاستجابة أكملت الطريق. حتى هذا الاستلام لا يحدد عمر الربط ولا يثبت أن خادماً آخر يستطيع استخدامه.

لذلك يجمع السجل branch وCall-ID وCSeq وVia قبل التعديل وبعده وزوج المصدر على الشبكة ونسخة الوكيل وواجهة الدخول ومقبس الخروج وحالة الاستجابة وإثبات الاستلام. أما reachable=true بلا زمن ولا مراقب ولا معاملة فليس حجة قابلة للمراجعة.

انعدام الحالة لا يعني انعدام المصدر

الخادم الذي يستمع على منافذ وواجهات متعددة يحتاج إلى معرفة موضع استقبال الطلب. يستطيع الوكيل stateful حفظه طوال المعاملة. أما الوكيل stateless فيستطيع ترميز عنوان الوجهة ومنفذها في Via الذي يضيفه، ثم استعادته عندما تعود الاستجابة.

الحالة لم تختف، بل انتقلت من الذاكرة إلى الرسالة. وإذا احتفظت المراقبة باسم الخدمة المنطقي فقط، فلن تستطيع إثبات المقبس الذي قبله NAT. قد يرى موازن الحمل عقدتين متكافئتين، بينما يميّز المترجم بينهما.

صحة المجموعة وصحة النسخة وصحة المسار المتماثل ثلاث نتائج مستقلة. لا تعني خضرة الأولى نجاح الثالثة.

قد ينتهي ربط NAT قبل انتهاء INVITE

تشترط RFC 3581 بقاء الربط طوال المعاملة. اعتُبرت معاملات non-INVITE أقصر من مهلات UDP الشائعة وقتها. أما INVITE فيمكن أن ينتظر الاستجابة النهائية زمناً غير محدود عملياً؛ لذلك أوصت الوثيقة بإعادة إرساله دورياً حتى بعد استجابة مؤقتة لتجديد الربط.

هذه الحاجة دليل على أن الزوج المرصود لا يحمل تاريخ انتهاء. الاستجابة المؤقتة ليست عقد إيجار. الصمت أو إعادة تشغيل NAT أو تغيير السياسة أو انتقال الوكيل قد يغلق الطريق مع بقاء هوية SIP والتسجيل كما هما.

أشارت الوثيقة إلى اكتشاف عمر الربط في RFC 3489 مع تحذير من عدم موثوقيته. حلّت RFC 5389 محل RFC 3489، ثم حلّت RFC 8489 محل RFC 5389. لا يجوز تحويل افتراض تاريخي إلى قياس حاضر. المطلوب هو حفظ آخر حركة ناجحة، وتواتر التجديد، والميزانية وعدم اليقين.

معرفة العنوان لا تنشئ طريقاً إليه

يكشف received+rport للعميل الزوج العام كما رآه الخادم. يمكن أن يغري ذلك بوضعه في Contact أو Record-Route لاستقبال طلبات مستقبلية. تصنف RFC 3581 هذا الاستخدام ضمن UNSAF وتشرح لماذا هو هش.

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

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

حددت RFC 3581 مخرجاً تقنياً: ينبغي أن يطلب العميل استقبال الطلبات على الاتصال أو التدفق الذي بدأه، وأن يُعالج تعدد الخوادم، وألا تفرض الآلية حملاً مفرطاً. جاءت RFC 5626 بـ SIP Outbound لربط التسجيل بتدفقات ينشئها العميل، ودعم عدة تدفقات، والإبقاء عليها واكتشاف فشلها. وتوصي RFC 6314 بهذا النهج في ممارسة عبور NAT.

لكن الأدوات اللاحقة لا تذوب في ادعاء واحد. توضح RFC 6223 أن keepalive لا يعرّف connection reuse. تعالج RFC 5923 الطلب العكسي على النقل القائم على اتصال. توفر RFC 5627 عنوان GRUU ثابتاً لنسخة UA. نجاح pong ليس اختيار تسجيل، وflow token ليس تفويضاً، والعنوان الثابت لا يثبت الرنين أو الإعلام أو النتيجة.

حماية الإشارة لا توسع معنى الملاحظة

قد يكون عنوان المصدر ومنفذه معلومات حساسة، لذلك تشير RFC 3581 إلى SIP فوق TLS. تحمي TLS الرسالة من التعديل. وعلى TCP/TLS يصبح rport في الأساس معلومة عن المنفذ المرصود، لا سبباً لعبور استجابة UDP.

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

تحتاج السلسلة إلى سلطات منفصلة: مصادقة للهوية، وملاحظة سلكية لزوج المعاملة، ومصدر مقبس لمسار الاستجابة، وPath أو flow للمستقبل، وحالة registrar للاختيار، وRoute set للحوار، وإثباتات مستقلة للرنين والإجابة والإعلام ونتيجة التطبيق.

حدود الدليل

لا يحدد هذا المقال مشغلاً أو PBX أو مزود SIP أو UA أو proxy أو registrar أو منتج NAT أو مجموعة أو مستخدماً أو مكالمة أو حادثاً أو نتيجة إعلام. Standards Track لا يثبت الانتشار.

توفر RFC 3261 أساس Via والمعاملة، وRFC 3327 آلية Path، وRFC 3424 إطار UNSAF. تبقى RFC 3489 سياقاً تاريخياً، وتبيّن RFC 5389 وRFC 8489 تطور STUN. تفصل RFC 5626 وRFC 6314 وRFC 5923 وRFC 6223 وRFC 5627 بين Outbound والممارسة وإعادة الاستخدام والإبقاء والهوية القابلة للتوجيه. سجل IANA ليس running code.

مقالا Heng Lu عن Running-Code Primacy وMinimum Initial Specification عدستان تحريريتان معلنتان. يدعوان إلى فحص الطريق الذي عمل فعلاً وحصر القاعدة المشتركة في الحد اللازم. ولا يثبتان نية مؤلفي RFC أو واقع نشر.

الخلاصة محدودة وقوية: رأى الخادم منفذ عودة ونجحت استجابة في لحظة. لا يحق لهذا الدليل أن يعلن قابلية الاتصال غداً.

المصادر