الخلاصة

  • يلزم RFC 5263 وكيل الحضور بانتظار الاستجابة النهائية أو انتهاء مهلة NOTIFY الجزئي السابق قبل إرسال آخر إلى Request-URI نفسه؛ وهذا يسلسل المعاملات ولا يقدم إيصالا بحالة دائمة لدى المراقب.
  • يربط السجل القابل للدفاع الاشتراك والإصدار وجسم NOTIFY باستجابة SIP ونتيجة التحليل والرقعة وبصمتي ما قبل التطبيق وما بعده وإقرار التخزين والعرض للنظام اللاحق.

فشل المعالج فاختار المراقب العودة إلى الحالة الكاملة

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

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

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

الاستجابة النهائية تفتح نافذة الإرسال التالية

لا يجوز لوكيل الحضور إرسال NOTIFY جزئي جديد إلى Request-URI نفسه قبل تلقي استجابة نهائية للسابق أو انتهاء مهلته. تمنع القاعدة تراكم فروق يعتمد كل منها على حالة سابقة من دون حد ترتيب واضح.

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

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

الإصدار منسوب إلى الاشتراك

يسمح المراقب بالإشعارات الجزئية حين يعلن application/pidf-diff+xml مع application/pidf+xml. يمكنه تحديد الأفضلية، لكن سياسة وكيل الحضور المحلية تشارك في اختيار الصيغة.

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

لذلك لا تكفي عبارة «عاد 200 للإصدار 12». يجب ربطها بـ Request-URI والحوار وCall-ID والوسوم وCSeq وبصمة الجسم. الرقم المعزول ليس إحداثية عالمية، والاستجابة المعزولة لا تحدد أي انتقال كان مطلوبا محليا.

النجاح في الإرسال وصف من جهة المرسل

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

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

قد تتتابع المراحل بسرعة في الأحوال السليمة. قربها الزمني لا يمنح واحدة منها سلطة إثبات الأخرى عند النزاع أو العطل.

المقارنة المحلية تحدد ما حدث فعلا

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

الإهمال والتطبيق والاسترداد ثلاث نتائج مختلفة. لا تصفها الاستجابة النهائية عند حافة SIP بدقة كافية.

يجب أن يسجل الإيصال الإصدار المتوقع والمستلم والفرع المختار ونتيجة الرقعة وبصمة الحالة الناتجة، لا أن يستنتجها من رؤية المرسل.

انتهاء المعاملة لا يلغي خطأ المعالجة

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

بهذا يمكن أن تكون كل استجابات النقل مكتملة بينما لا تتكون السلسلة المحلية المقصودة. عبارة «لم نستلم خطأ» لا تساوي «طبق المستقبل التغيير».

الحد المؤسسي الصحيح يضيف إقرارا مستقلا بعد التحليل والتطبيق والتخزين، بدلا من توسيع معنى 200.

عند تغيير الصيغة يبقى العداد ويختفي المحتوى

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

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

الحالة الكاملة عند التجديد تقدم مرساة جديدة للحاضر، لكنها لا تثبت بأثر رجعي ما حدث للفروق السابقة.

أصالة الرسالة لا تعني ثبات التطبيق

يرث RFC 5263 اعتبارات السرية والسلامة والأصالة ومنع إعادة الإرسال ورفض الخدمة في نظام حضور SIP. ويوصي في سياقه الأصلي بـ TLS بين العناصر ويسمح بـ S/MIME؛ ثم حدث RFC 8996 اعتماد TLS بإخراج TLS 1.0 و1.1 من الاستخدام.

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

دليل المصدر المشفر وإغلاق معاملة SIP طبقتان مهمتان، ولا تحل أي منهما محل إيصال الحالة المحلية.

إيصال حالة المراقب

للاستخدام ذي العواقب، احتفظ بما يلي:

  • صاحب الحضور والمراقب وRequest-URI والاشتراك والحوار وحزمة الحدث؛
  • أنواع المحتوى المقبولة والأفضليات واختيار الوكيل المحلي؛
  • Call-ID والوسوم وCSeq والنوع والبايتات والبصمة ووقت NOTIFY؛
  • إصدار الاشتراك والإصدار السابق المتوقع؛
  • رمز استجابة SIP ووقتها وانتهاء المهلة أو إعادة المحاولة؛
  • نتيجة التحليل وخطأ المعالجة المحدد؛
  • بصمة الوثيقة الكاملة قبل التطبيق ونتيجة الرقعة؛
  • البصمة المعاد بناؤها والعداد المحلي وإقرار التخزين؛
  • التجديد والتراجع وتغيير الصيغة والحالة الكاملة البديلة؛
  • هوية العرض اللاحق وبصمته ووقت ملاحظته؛ و
  • العرض ومحاولة الاتصال والتسليم والنتيجة البشرية أو الخدمية.

لا ينتقص هذا الإيصال من قيمة 200. إنه يمنع دليلا على التدفق من ادعاء أنه دليل على الحالة.

Sources