تسجيلان لا يعنيان هاتفين

الخلاصة

• أتاح SIP Outbound وصول طلبات جديدة إلى جهاز عبر تدفقات أنشأها الجهاز نفسه، في بيئات يستطيع فيها الاتصال بالخادم ولا يستطيع الخادم بدء اتصال جديد إليه.
• عنوان الحساب وهوية نسخة وكيل المستخدم ومعرّف تسجيل كل تدفق ليست شيئًا واحدًا. تعدد الطرق إلى الجهاز نفسه لا يحوّلها إلى عدة مستقبِلين مستقلين.
• يشير الرد 430 إلى تعطل تدفق معين. أما وصول رد نهائي من النسخة المقصودة، باستثناء حالتي 408 و430، فيمنع إرسال الطلب نفسه إليها مجددًا عبر تسجيل آخر.

قد يعثر التحويل على الشخص، لكنه يخطئ الهاتف

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

عرض RFC 5627، المنشور في أكتوبر 2009، هذا الفرق لتفسير الحاجة إلى GRUU: معرّف URI يمكن استخدامه من خارج الشبكة لتوجيه الطلب إلى نسخة معينة من وكيل المستخدم. يعود الطلب عبر نطاقها إلى التسجيلات المرتبطة بها. الاسم هنا يحدد المستقبِل، لكنه ليس اتصالًا قائمًا ولا ضمانًا دائمًا لإمكان الوصول.

وفي الشهر نفسه، تناول RFC 5626 سؤالًا مجاورًا: إذا كان هذا الجهاز لا يقبل اتصالًا جديدًا يأتيه من الخارج، فكيف يصل إليه الطلب؟ وإذا أنشأ أكثر من طريق احتياطي، كيف يعرف الخادم أن الطرق كلها تعود إلى جهاز واحد؟

هنا يبدأ تاريخ SIP Outbound. ليس الهدف جمع أكبر عدد من العناوين، بل إبقاء معنى كل عنوان وتسجيل وطريق واضحًا بما يكفي لاتخاذ القرار التالي.

نجاح التسجيل لم يفتح بابًا جديدًا

كانت وظيفة التسجيل موجودة في RFC 3261 الصادر في يونيو 2002. يربط التسجيل عنوانًا مرجعيًا للمستخدم، أو AOR، بعنوان Contact واحد أو أكثر. يستعين الوكيل بخدمة تحديد الموقع ليعرف أين يرسل الطلب، ويُدير خادم التسجيل هذه الروابط. ويمكن للجهاز نفسه أن يؤدي الوظيفتين.

لكن وضع Contact في سجل لا يغيّر سياسة جدار الحماية. قد يستطيع الهاتف إنشاء اتصال إلى الخارج، ثم يعجز الخادم عن إنشاء اتصال جديد في الاتجاه المعاكس. وقد يعمل الحاسوب كعميل TLS من دون اسم نطاق ثابت وشهادة تمكّن الآخرين من معاملته كخادم.

يجب التمييز هنا بين الاستجابة والطلب الجديد. كان SIP يرسل الاستجابة، عند استخدام نقل موثوق وبقاء الاتصال مفتوحًا، على الاتصال الذي حمل الطلب الأصلي. أما طلب INVITE الذي يصل لاحقًا فليس استجابة لعملية REGISTER السابقة. وصول رسالة تؤكد التسجيل لا يثبت وحده وجود طريق صالح للنداء التالي.

استفاد Outbound من التدفق الذي بدأه الجهاز. في TCP يقابل التدفق اتصالًا؛ وفي UDP هو ارتباط ثنائي الاتجاه تحدده عناوين الطرفين ومنافذهما وبروتوكول النقل. لذلك لا تعني كلمة تدفق دائمًا جلسة TCP. المقصود أن يستخدم الخادم الارتباط المعروف بالجهاز، بدل افتراض قدرته على بدء اتصال جديد إلى العنوان المكتوب.

كيف يتذكر الخادم الطريق عبر الحافة؟

قد يمر REGISTER بوكيل على الحافة قبل أن يصل إلى خادم التسجيل. حفظ عنوان الجهاز وحده لا يخبر الخادم بأن الطلب اللاحق يحتاج المرور بذلك الوكيل أيضًا.

عرّف RFC 3327، في ديسمبر 2002، حقل Path لجمع معلومات الوسطاء أثناء التسجيل وحفظها مع الرابط. يستخدم وكيل النطاق تلك المعلومات لاحقًا في Route للوصول إلى الجهاز. يظل ذلك مرتبطًا بالطلبات التي تنشأ في النطاق المسؤول أو تمر به، وليس طريقًا عالميًا يفرض على كل مرسل.

ولا ينشئ REGISTER حوارًا بالمعنى البروتوكولي. حقل Record-Route لا يؤدي فيه وظيفة إنشاء مسار لحوار جديد. Path يساعد على إيصال طلبات مستقبلية إلى طرف مسجل، أما الطلبات داخل الحوار الذي ينشأ لاحقًا فتحتاج ترتيب المسار المناسب لذلك الحوار.

أضاف Outbound دقة أخرى عند أول وكيل بعد العميل. عليه تضمين رمز يحدد التدفق، مع إشارة ob المناسبة في Path. عند عودة الطلب يستطيع الوكيل معرفة الارتباط الذي ينبغي استخدامه، لا مجرد معرفة أن عليه المشاركة في الطريق.

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

لماذا كان تكرار المعرّف مقصودًا؟

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

يستخدم Outbound معرّف instance-id ثابتًا لنسخة وكيل المستخدم. لا يتغير لمجرد إعادة تشغيل الجهاز أو انتقاله إلى شبكة أخرى. ويستخدم reg-id لتمييز التدفقات المسجلة بالتزامن. بعد إعادة التشغيل، يعيد الجهاز استخدام تسلسل reg-id نفسه، كي تحل المعلومات الجديدة محل التسجيلات القديمة.

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

تصبح هوية الرابط مكونة من AOR وinstance-id وreg-id. يظل Contact محفوظًا لأن الوكيل يحتاجه لبناء مجموعة الوجهات، لكنه لا يبقى وحده أساس الحكم على هوية الرابط.

ومن هنا يأتي المنع المحدد في RFC 5626: لا يجوز أن تحتوي مجموعة الوجهات في الوقت نفسه على أكثر من Contact يحمل AOR وinstance-id نفسيهما. لا يمنع ذلك مستخدمًا من امتلاك أجهزة مختلفة؛ إنه يمنع عدّ مسارين إلى النسخة نفسها مستقبِلين مستقلين.

عطل يعرفه الوكيل قبل الهاتف

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

يعيد الوكيل الأول الرد 430 Flow Failed. يستطيع الوكيل المسؤول عن عنوان المستخدم تجربة رابط آخر له AOR وinstance-id نفسيهما وreg-id مختلف. وفي المثال تصل الدعوة عبر الحافة الثانية، ويُرتّب مسار الطلبات اللاحقة للحوار الجديد. بعد ذلك يكتشف الهاتف الخلل ويعيد التسجيل عبر الطريق الذي فقده.

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

نطاق 430 ضيق عمدًا: التدفق المعين تعطل، وقد تبقى تدفقات أخرى إلى النسخة نفسها صالحة. لا يقول إن المستخدم رفض، أو إن حسابه اختفى، أو إن الصوت نفسه انقطع. وهو رد بين الوسطاء؛ لا يُفترض أن يتلقاه الطرف النهائي، وإذا تلقاه يعامله كـ400. أما الرمز المعدل فيستدعي معالجة مختلفة، مع توصية باستخدام 403.

الطريق البديل لا يلغي جوابًا وصل

بعد رد نهائي من فرع الطلب، لا يجيز RFC 5626 إرسال الطلب نفسه إلى هدف آخر يمثل AOR وinstance-id نفسيهما، إلا في حالتي 408 و430. السبب أن النسخة المستهدفة قدمت جوابها بالفعل.

عندما لم يُسلّم الطريق الطلب، يمكن لطريق آخر أن يساعد. لكن حين أجاب الجهاز، لا يحوّل تغيير الطريق الجواب إلى غياب للجواب. وإلا صارت آلية تحسين الاعتمادية وسيلة لإعادة سؤال المستقبِل مرات متتالية.

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

البقاء على الخط ليس حالة واحدة

مدة صلاحية التسجيل تختلف عن مدة بقاء ارتباط NAT أو اتصال النقل. وقد يفشل تجديد التسجيل مؤقتًا بينما يستمر الاتصال في الإجابة عن رسائل التحقق. تسمح الوثيقة بإبقاء الاتصال في حالات الخطأ القابل للتعافي بدل إغلاقه وفتحه بلا ضرورة.

وفي UDP، قد تصل استجابة STUN لكن يتغير عنوان المرسل الخارجي الوارد فيها. يجب اعتبار تغير XOR-MAPPED-ADDRESS فشلًا للتدفق. ما زالت هناك جهة تجيب، لكن الارتباط الذي اعتمد عليه السجل تبدل.

تجري هذه الاختبارات مع القفزة التالية في SIP، لا من طرف إلى طرف. ولا تثبت وصول المكالمة إلى الشخص أو سلامة مسار الوسائط الصوتية. كذلك يحتاج إرسال STUN إلى إشارة صريحة بأن الجار يدعمه؛ خيار مبهم يقول «العمل خلف NAT» لا يكفي.

في أبريل 2011، عرّف RFC 6223 معلمة Via المسماة keep للتفاوض على رسائل المحافظة على النشاط بين الجيران. أوضح أن هذا التفاوض، الذي يراعي اتجاه الإرسال، لا يحدد آلية إعادة استخدام الاتصال. الحفاظ على فتحة في الطريق لا يمنح وحده حق إرسال أي طلب عكسي عبرها.

أما RFC 5923، الصادر في يونيو 2010، فيناقش أسماء بديلة لاتصالات TLS بين طرفين مجاورين يستطيع أي منهما بدء الاتصال. تختلف هذه الفرضية عن بيئة لا يستطيع فيها إلا العميل فتح الطريق. تبقى المصادقة وسياسة القبول ضرورية؛ الاتصال المستمر لا يعني تلقائيًا السماح بإعادة استخدامه في الاتجاه المعاكس.

المتصفح جعل الفرق مرئيًا

يقدم RFC 7118، المنشور في يناير 2014، سيناريو SIP داخل المتصفح. في إرشادات التنفيذ، يمكن للعميل الذي طلب دعم Outbound وحصل عليه أن يستخدم اسمًا عشوائيًا تحت .invalid في Contact. لا يعرف برنامج المتصفح بالضرورة عنوان النقل المحلي، لكن الطلبات تعود عبر وكيل WebSocket والتدفق القائم.

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

يؤكد سجل معلمات SIP لدى IANA أسماء الرموز والمعلمات ومراجعها. لا يثبت عدد الأجهزة التي نفذتها أو جودة التنفيذ في شبكة معينة. ما يمكن استخلاصه من التاريخ أضيق وأهم: زيادة طرق العودة لم تكن تستلزم زيادة عدد المستقبِلين، شرط أن يعرف النظام ما الذي تعدّه كل خانة في سجله.