الخلاصة

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

الخصوصية لا تعني افتراض أن الحوار انتهى

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

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

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

نشر RFC8599 في مايو2019، ويضع في الفقرة6.2.1 واجبين متزامنين. يجب توليد Proxy Unique Registration Reference، واختصارها PURR، بقيمة جديدة دوريا حتى عندما تبقى معلمات الدفع كما هي. ويجب الاحتفاظ بالقيم القديمة ما دامت الحوارات المرتبطة بها جارية. لا يقدم النص التجديد بوصفه إذنا بمحو كل ما سبقه.

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

لماذا يحتاج التطبيق إلى إشعار أصلا؟

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

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

يحصل وكيل المستخدم من Push Notification Service، أي PNS، على Push Resource ID، أي PRID. صيغة هذا المورد خاصة بالخدمة. ينقل التسجيل إلى الوكيل الوسيط بيانات المزود وPRID، ومعلمة إضافية إذا تطلبها المزود. اكتشاف الخدمة والتسجيل لديها والمحافظة على العلاقة معها ليست إجراءات يوحدها RFC8599.

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

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

إحالة محدودة بدلا من نشر إحداثيات الخدمة

لا يحتاج الطرف الآخر في الحوار إلى امتلاك جميع البيانات التي يستخدمها الوكيل الوسيط لطلب الدفع. يمنع RFC8599 وكيل المستخدم من إدراج معلمات الدفع المعنية في الطلبات غير REGISTER، باستثناء pn-purr. تظل pn-provider وpn-prid وpn-param بعيدة عن الطرف المقابل في إشارات الحوار العادية.

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

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

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

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

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

المشاركة قرار لكل حوار

لا يضع دعم الوكيل الوسيط كل محادثة تحت آلية الدفع تلقائيا. يترك RFC8599 لوكيل المستخدم الاختيار وفقا لسياسة محلية: هل يستخدم هذا الحوار الدفع لاستقبال طلبات تصل في أثنائه؟ قد تتعلق الإجابة بخصائص الحوار أو وسائطه. اختيار حوار واحد ليس تصريحا دائما لكل ما يفعله التطبيق لاحقا.

عندما يختار المشاركة، يضع وكيل المستخدم pn-purr في Contact الأولي المعني، مستخدما أحدث قيمة تلقاها عبر sip.pnspurr. إذا لم يتلق مؤشر القدرة، فلا يجوز له اختراع المعلمة. ينبغي أن يحصل المقابل على إحالة تستند إلى قدرة معلنة بالفعل، لا إلى وعد من طرف واحد عن وسيط غير معلوم.

يوفر RFC6809 إطار Feature-Caps لإعلان قدرات الكيانات التي لا تمثلها URI الخاصة بـContact. يصف سجل IANA مؤشر sip.pnspurr باعتباره قدرة على ربط طلبات داخل الحوار بمعلومات التسجيل. لا تتحول هذه القدرة إلى صلاحية عامة لدى مزود الدفع أو إلى سلطة على وسائط التطبيق.

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

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

التحديث ليس شهادة بإغلاق الاعتماد السابق

قد يقدم رد التسجيل اللاحق قيمة جديدة دون أن يثبت استبدال كل الحوارات القائمة لمعلومات الاتصال التي تعلمتها في البداية. إذا ظل حوار يعتمد على P1، تبقى علاقة P1 ذات وظيفة. إصدار P2 يخبرنا بما حدث مؤخرا، لا بكل ما انتهى سابقا.

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

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

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

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

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

المسار جزء من المسؤولية

العلاقة الصحيحة لا تنفع إذا لم يصل الطلب إلى الوكيل الذي يستطيع حلها. ضمن إجراءات إنشاء الحوار المعنية، يدرج الوكيل نفسه في Record-Route ليبقى على مسار الطلبات اللاحقة. يوضح RFC3261 مجموعة مسارات الحوار والهدف البعيد الذي تستخدمه الإشارة.

ويجب التمييز بين ذلك وبين Path. يصف RFC3327 الوسطاء اللازمين للوصول إلى وكيل مستخدم مسجل. أما Record-Route فيتعلق بمسار حوار قائم. صحة بيانات التسجيل لا تثبت تلقائيا أن طلبا في الحوار سيمر على حامل PURR.

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

في معالجة الطلب داخل الحوار، قد تظهر pn-purr في Request-URI أو في URI بحقل Route بحسب بناء المسار. إذا استرجع الوكيل المعلومات اللازمة، يضع طلب SIP في انتظار المعالجة ويطلب إشعارا. وعند وصول رد2xx لمعاملة REGISTER المرتبطة، يخرج الطلب الموافق ويوجهه إلى وكيل المستخدم.

لا يستخدم هذا الإجراء مقارنة URI في الفقرة5.3، لأن الطلب داخل الحوار لا يحمل pn-prid وpn-provider وpn-param. تعتمد العلاقة هنا على PURR المرتبطة برد التسجيل. الإحالة غير المباشرة تغير طريقة المطابقة فعليا، ولا تكتفي بإخفاء أسماء الحقول عن الأنظار.

وهذا الوصف خاص بالفقرة6.2.3. للطلبات الأولية شروط وتسلسل قد يختلفان باختلاف النقل. لا يصح القول إن كل طلب SIP في كل ظرف ينتظر دائما رد REGISTER2xx قبل أن يتمكن من الوصول.

الاحتفاظ لا يمدد سلطة انتهت

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

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

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

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

يصف RFC8030 أمن HTTP Web Push، لكنه لا يقرر سياسة التطبيق لكل حوار SIP. قبول المزود وحل الإحالة والمشاركة في الحوار حقائق مختلفة. دمجها في «حق إيقاظ» شامل يخفي المسؤول عن استيقاظ غير لازم واستهلاك البطارية وإشارات إضافية.

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

ماذا تثبت وثائق التنفيذ؟

تصف وثائق registrar للإصدار المحدد OpenSIPS3.6 عناصر pn_enable_purr وpn_process_purr ومهلة pn_refresh_timeout القابلة للضبط. فائدتها أنها تجعل إعلان القدرة والعثور على الإحالة وانتظار إعادة التسجيل عمليات ملموسة في تنفيذ موثق.

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

حالة التصويبات مهمة كذلك. التصويب8136 تحريري موثق بالتحقق، ويصحح sip.pnsreq إلى sip.pnsreg في الفقرة4.1.4. التصويب7136 تقني مبلّغ عنه بخصوص أمثلة Request-URI في REGISTER؛ لا يعد تغييرا معياريا مقبولا. لا حاجة إلى اختراع مثال تنفيذي لإيضاح الفكرة.

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

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

المصادر