الخلاصة

  • يمكن لوكيل يخدم المستخدم إدراج Answer-Mode أو حذفه أو تغييره بموجب اتفاق خارجي صريح فقط؛ لذا يجب حفظ التحويل ومصدر سلطته.
  • Priv-Answer-Mode يطلب تطبيق سياسة امتياز أشد ولا يثبت الامتياز. أما require فيحدد الرفض أو فهم الامتداد ولا يجبر الجهاز على الفعل.
  • قبول جلسة واردة آلياً لا يسمح بفتح وسائط صادرة لاحقاً. يحتاج تغيير الاتجاه عبر re-INVITE أو UPDATE إلى قبول صريح جديد من المستخدم.

الوكيل لم يكن ناقلاً محايداً دائماً

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

هذا الاستثناء مفيد، لكنه يغيّر نسب القرار. القيمة التي يراها UAS قد تعبّر عن المتصل، أو عن سياسة فوّضها المستخدم للوكيل، أو عن تغيير غير مشروع. لا يمكن للحقل وحده أن يفرّق بينها.

ينبغي أن يضم السجل الرسالة الأصلية، وهوية الوكيل، ونص التحويل، ورقم الاتفاق أو نسخته، والرسالة النهائية التي قيّمها UAS. حماية وصلة واحدة لا تثبت أن المعنى بقي ثابتاً عبر جميع الوكلاء، خصوصاً مع اعتماد SIP المعتاد على ثقة انتقالية.

Auto ظل طلباً خاضعاً للقرار المحلي

يطلب Answer-Mode: Auto قبول INVITE من دون انتظار تفاعل المستخدم. يستطيع UAS، بحسب الهوية والسياسة والمخاطر، أن يجيب يدوياً أو يرفض. المصادقة تحدد من طلب؛ والتفويض يقرر ما إذا كان هذا الشخص يستطيع تشغيل هذا السلوك لهذه الوسائط.

إذا ورد Auto;require واختارت السياسة وضعاً مختلفاً، يجب الرفض بدلاً من التحويل إلى يدوي. لا تُقيَّم require قبل السياسة ولا تمنح المتصل سيطرة على الجهاز.

أما Require: answermode فيطلب فهم الامتداد أو الرفض. لا توجد، كما توضح RFC، آلية تفاوض SIP تجبر السلوك بعينه. إعلان answermode في التسجيل واختيار contact متوافق دليل قدرة، لا إيصال تنفيذ.

Priv طلب فحصاً أشد

تشبه RFC الحقل Priv-Answer-Mode بطلب sudo. كتابة الاسم لا تمنح الامتياز؛ بل تستدعي قائمة سياسة مختلفة. ينبغي أن تكون السياسة أشد، وأن ترفض افتراضياً ما لم تكن الهوية موثقة ومصرحاً لها تحديداً.

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

كانت RFC 5373 تستشهد بآلية الهوية RFC 4474، التي حلت محلها RFC 8224 لاحقاً. تبقى الحاجة إلى هوية مناسبة وقرار تفويض منفصل؛ ولا يبقى افتراض أن آلية تاريخية مستخدمة في كل شبكة اليوم.

اتجاه الوسائط رسم حد الخصوصية

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

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

قد تبدأ الجلسة واردة فقط ثم يطلب re-INVITE أو UPDATE اتجاه sendrecv. حقول Answer-Mode ليست معرفة في منتصف الحوار، لكن الحارس الأمني يجب أن يتابع الحالة ويطلب قبولاً جديداً قبل خروج أي وسائط محلية.

التفرع جعل جهازاً خاسراً يتصرف

يمكن أن يصل INVITE إلى عدة contacts بالتوازي. قد ترسل أجهزة متعددة 200 تلقائياً، ثم يحتفظ SIP بالأول وينهي البقية عبر BYE. الجهاز الذي خسر قد يكون شغّل مكبره بالفعل.

لهذا لا توصي RFC بالإجابة الآلية مع التفرع المتوازي. يجب تسجيل كل فرع ووقت 200 وبدء الوسائط وBYE، لا الحوار الفائز فقط. القدرة المسجلة لا تثبت أن عنواناً واحداً يمثل جهازاً واحداً.

الصمت في الاستجابة حمى معلومة الحضور

يمكن للـ200 أن يذكر Manual أو Auto. لكن الإعلان أن الإجابة كانت يدوية قد يكشف وجود شخص، لذلك يوصى بالحذف افتراضياً.

غياب الحقل يعني «لم يُفصح»، ولا يعني تلقائياً أو يدوياً. ووجوده يصف تفاعل واجهة محدداً، لا هوية الإنسان أو انتباهه أو فهمه. الاستجابة بروتوكولية وليست شهادة حضور.

حد الإثبات

يجمع الملف INVITE الأصلي، والهوية، ونوع الطلب العادي أو المميز، وشكلي require، واختيار contact، وكل الفروع، وتحويلات الوكيل وسندها، ونسخة سياسة UAS، والاستجابة، واتجاه SDP لكل حالة، وقبول المستخدم، والحزم الصادرة فعلياً. السماع والفهم والنتيجة تبقى ادعاءات مستقلة.

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