الخلاصة

  • لا يمدد RFC 4028 أجل الجلسة إلا عندما يتلقى re-INVITE أو UPDATE داخل الحوار استجابة 2xx؛ أما إرسال الطلب أو رؤية الحركة أو تلقي 422 فلا يكفي.
  • توزع حقول Session-Expires وMin-SE وrefresher واجبات التوقيت والتجديد والتنظيف بين الطرفين والوسطاء، ولا تمنح دليلاً على RTP أو حضور إنسان أو جودة الخدمة أو صحة الفاتورة.
  • يحتفظ النظام القابل للمراجعة بأدلة المعاملة والحوار والوسائط والتطبيق والحالة التجارية منفصلة، ثم يفسر مواضع اتفاقها واختلافها.

حين يتوقف وسيط وتستمر المكالمة

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

وفي حادثة أخرى يحدث العكس. يرسل الطرف UPDATE بلا SDP، ويتلقى 200 OK، فتتجدد حالة SIP. لكن عطلاً مستقلاً أوقف الصوت في اتجاه واحد، واختفت تقارير RTCP، وظلت البرمجية ترسل التجديد آلياً. إذا ساوت منصة الفوترة بين 200 وبين «الخدمة مستمرة»، تحولت حقيقة ضيقة إلى حكم تجاري واسع.

صُمم RFC 4028 لمعالجة بقاء الحالة عندما لا يُرسل BYE أو يضيع. يمنح التجديد الدوري الأطراف والوسطاء call-stateful حداً يقررون بعده أن حالة SIP صارت قديمة. وهو يميز صراحة بين هذا الغرض وبين إشارات الحياة الخاصة بالجلسة مثل RTCP.

إذن، المؤقت ليس نبضاً شاملاً. هو صلاحية زمنية لحالة الإشارة.

ثلاثة أزمنة داخل واجهة واحدة

فاصل الجلسة هو أكبر مدة مسموحة بين تجديدين ناجحين. تؤخذ قيمته العملية من Session-Expires في أحدث استجابة 2xx ذات صلة.

الحد الأدنى للمؤقت هو أقصر فاصل يقبله العنصر. تستهلك الطلبات داخل الحوار قدرة معالجة، ولذلك يمنع Min-SE طرفاً من فرض معدل تجديد مرهق.

أما انتهاء الجلسة فهو موعد يحسبه كل عنصر محلياً. يبدأ UAS من لحظة إرسال 2xx، ويبدأ UAC من لحظة استقباله، ويحسب الوكيل من الاستجابة التي مررها. تأخير الشبكة والمعالجة يعني أن المواعيد متقاربة لا متطابقة. لا يوجد ختم زمني عالمي شهد عليه الجميع.

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

التفاوض ملك للمسار أيضاً

يمكن لـ UAC أن يعلن دعم timer ويقترح Session-Expires. وللوكلاء الذين يحتفظون بالحالة مصلحة مشروعة: يمكنهم طلب المؤقت، أو خفض الفاصل، أو رفع Min-SE، لكنهم لا يستطيعون كسر أكبر حد أدنى متراكم.

يحدد UAS القيمة النهائية في 2xx ويضيف refresher=uac أو refresher=uas. ترى الوكلاء الاستجابة في طريق العودة، ولا تعيد كتابة القيمة النهائية.

إذا كان الفاصل المقترح أصغر مما يسمح به عنصر، يرد 422 Session Interval Too Small مع Min-SE. يستطيع UAC إعادة الطلب في معاملة جديدة ذات CSeq أعلى وقيمة مناسبة.

هذه مساومة على القيود، لا تجديد ناجح. لا يحرك الموعد إلا 2xx. لذلك يشكل 422 القريب من الانتهاء سباقاً حقيقياً: تعلم الطرف قيمة المستقبل، لكنه لا يزال مطالباً بإتمام الطلب الجديد قبل نهاية الحاضر. لوحة تعرض 200 الأخير فقط تحذف نافذة الخطر.

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

uac وuas ليستا هويتين دائمتين

تحدد قيمة refresher الطرف الذي يصدر التجديد التالي، لا المتصل الدائم أو صاحب الحساب أو الشخص الذي يدفع.

UAC وUAS دوران في المعاملة. قد يصبح متلقي INVITE الأول UAC عندما يرسل UPDATE لاحقاً. ولهذا يضع RFC قواعد تبقي مسؤول التجديد مفهوماً عند انقلاب الدورين.

سجل يكتب refresher=uac وحدها ناقص. يجب أن يربط الدور بنقطة النهاية في تلك المعاملة، وأن يحفظ Call-ID والوسمين والطريقة وCSeq والاتجاه.

ويزيد التفرع الحد وضوحاً. قد ينشئ INVITE واحد حوارات عدة، لكل منها فاصل ومسؤول وموعد مستقل أو بلا مؤقت. تجديد فرع لا يحيي فرعاً آخر. كما يمكن أن يختفي المؤقت أثناء الحوار إذا خلا أحدث 2xx من Session-Expires؛ وجوده سابقاً ليس دليلاً على وجوده الآن.

الحدث الوحيد الذي يمدد المهلة

القاعدة صريحة: استجابة 2xx لطلب تجديد هي وحدها التي تمدد الانتهاء.

إرسال UPDATE لا يكفي، ولا الرد المؤقت، ولا 401 أو 407، ولا 422، ولا نجاح الكتابة إلى النقل، ولا رؤية الوكيل للطلب. قد تنجح محاولة مصدقة لاحقاً، لكنها لا تمنح المحاولة الأولى نجاحاً بأثر رجعي.

إذا انتهت معاملة التجديد أو أعادت 408 أو 481، يرسل UA المكلف BYE وفق قواعد SIP. قد تسمح أخطاء أخرى بمحاولة محدودة، لا بتكرار لا نهائي يخفي العطل.

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

سلطة الوكيل أضيق: عندما تنتهي ساعته يحذف حالته ويحرر موارده، لكنه لا ينشئ BYE. له أن ينظف دفتره، وليس له أن ينتحل الطرف النهائي ويعلن انتهاء الحوار.

لهذا يمكن أن يتعايش صوت جارٍ مع وكيل نسي الجلسة، أو BYE ضائع مع حالة ما زالت ظاهرة، أو مواعيد محلية مختلفة. اختزالها إلى «وقت إنهاء» وحيد يصنع دقة وهمية.

التجديد ليس بالضرورة رسالة بلا آثار

يظل re-INVITE أو UPDATE طلباً SIP عادياً. يعرّف RFC 3311 UPDATE كطلب يستطيع تغيير معلومات الجلسة ويحدث الهدف البعيد. ويربط RFC 3261 re-INVITE بالحوار وعملية offer/answer وتحديث Contact.

يوصي RFC 4028 باستخدام UPDATE بلا offer للتجديد الخالص إذا كان الطرف الآخر يدعمه. أما re-INVITE فعادة يحمل offer حتى إن لم تتغير الجلسة. وقد يؤدي طلب أُرسل من أجل hold أو الاستعادة أو نقل الوسائط وظيفة التجديد أيضاً.

لذلك قد يجتمع مع 2xx واحد تمديد المؤقت وتغيير Contact أو SDP أو اتجاه stream أو codec أو عنوان أو حل تنازع. يعالج RFC 6141 491 وتداخل re-INVITE واستعادة offer/answer لأن الرسالة ليست ping بسيطاً.

يجب أن يذكر الأثر إن كان الطلب timer-only، وهل حمل SDP، وهل تغير إصدار الأصل أو الاتجاهات أو المنافذ، وهل تغير Contact، وأي استجابة حسمت المعاملة.

حياة الإشارة ليست حياة الوسائط

يعرف RFC 3264 أوضاع sendrecv وsendonly وrecvonly وinactive ورفض stream. إنها أوصاف تفاوضية، لا إيصالات تسليم.

كما يقرر RFC 3550 أن RTP لا يضمن التسليم أو الجودة. تقدم RTCP تقارير استقبال وتوقيت وهوية مشاركين، فتفيد في قياس التدفق، لكنها لا تثبت أن إنساناً سمع أو فهم أو وافق أو حصل على قيمة.

ينبغي فصل خمس طبقات على الأقل: معاملة SIP؛ الحوار والمؤقت؛ RTP/RTCP؛ التطبيق والفعل البشري؛ الاستحقاق والفوترة والامتثال. يكون 2xx قوياً في الأوليين وضعيف الكلام في الثلاث الأخرى.

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

حماية كل قفزة لا تعني شهادة شاملة

يغير الوكلاء حقول المؤقت بشكل مشروع، ولذلك لا يصلح S/MIME من طرف إلى طرف لحماية حقول يحتاج الوسطاء إلى تعديلها. يوصي RFC 4028 بسلامة hop-by-hop عبر TLS واستخدام SIPS.

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

يحتوي سجل تصحيحات RFC 4028 على تصحيحات موثقة لصياغة UAC/UAS. وهناك بلاغ في مايو 2026 يناقش سلوك الوكيل مع طلب صريح refresher=uas، وما زال Reported. يصلح للاختبار، لا لتقديمه كقانون معدل.

دليل يصمد عند النزاع

يربط السجل القابل للدفاع هوية الحوار بكل معاملة وأدوار طرفيها الحقيقيين. يحفظ الطريقة وCSeq وbranch وroute وحقول المؤقت قبل الوسطاء وبعدهم، وأوقات الطلب والرد، والحدود المحسوبة، و2xx الذي حركها فعلاً.

ويحفظ الآثار الجانبية: وجود SDP وبصمته، إصدار offer/answer، اتجاهات streams، Contact، تحديات التوثيق والمحاولات. يحتاج BYE إلى مصدر وسبب: فعل مستخدم، فشل المجدد، انتهاء انتظار الطرف أو سياسة تطبيق.

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

ينبغي اختبار 422 قرب الموعد، و401 ثم نجاح، و408 و481، وغياب التجديد عند الطرف الآخر، وتنظيف الوكيل بلا BYE، وموت الوسائط مع نجاح التجديد، واستمرار الوسائط بعد فقد الإشارة، وفروع مختلفة، وإلغاء timer، وUPDATE بلا offer، وre-INVITE يغير SDP، وتحديث الهدف، وفقد الحالة بعد failover، وقفزة بلا حماية.

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

المصادر