ظهر المشارك في حالة المؤتمر، لكن ذلك كان رصداً بإصدار وزمن لا إثبات حضور دائم

الخلاصة

• يثبت الرد 200 على INVITE الأول أن المؤتمر أُنشئ، وأن العميل المنشئ دخل إليه، وأن الخادم فهم القائمة. لا يخبر بشيء عن إدخال بقية الأسماء.
• تأتي حالة المشاركين من آلية لاحقة مثل حزمة أحداث المؤتمر. إشعاراتها ذات إصدارات وقد تكون كاملة أو جزئية؛ لذلك لا يجوز استعمال القائمة الأولى لتعويض فجوة في الحالة.
• تختص قائمة الإنشاء بعنوان مصنع المؤتمر. عنوان المؤتمر المعاد في Contact مورد مختلف، ولا معنى معرفاً للقائمة في re-INVITE؛ وعند اشتراط الامتداد يرد المورد 420.

الرد الأول لم يكن ينتظر بقية البشر

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

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

تحدد الوثيقة معنى 200 بثلاث نقاط: إنشاء المؤتمر، وجود الـUAC الذي أرسل الطلب في المؤتمر، وفهم الخادم لقائمة URI. لا تضيف نجاحاً ضمنياً إلى صفوف المدعوين.

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

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

إشعار الحالة جاء من سلطة أخرى

حين يريد المنشئ معرفة وضع المستخدمين الآخرين، تشير RFC 5366 إلى آليات عامة مثل حزمة أحداث المؤتمر في RFC 4575. يصف الـfocus بواسطتها الحالة التي يمثلها بعد الدعوات والقرارات.

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

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

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

حتى الظهور الصحيح في الحالة لا يثبت الانتباه البشري. إنه قول الـfocus عن علاقة منطقية. لا يثبت وصول الصوت، ولا تشغيله، ولا فهمه، ولا مساهمة الشخص في القرار.

ثلاث مجموعات لا مجموعة واحدة

المقارنة المفيدة تفصل بين مجموعة مطلوبة، ومجموعة عالجها الـfocus، ومجموعة شوهدت في حالة المؤتمر.

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

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

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

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

الـfocus يقرر بعد أن يقرأ المصنع الاسم

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

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

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

تضيف RFC 5363 قواعد توثيق وترخيص مستدعي خدمة القوائم ومبدأ opt-in. وهي تحد من قدرة طلب صغير على توليد عدد كبير من العمليات. لكنها لا تلغي قرار القبول الخاص بالمؤتمر.

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

جسمان في رسالة واحدة لا يصنعان نتيجة واحدة

قد يحتوي INVITE الأول على multipart يضم SDP وقائمة URI. يستخدم SDP في offer/answer بين المنشئ وخادم المؤتمر. تستخدم القائمة لبدء عمليات نحو أطراف أخرى.

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

لذلك تحفظ بصمة SDP ونتيجة offer/answer لكل حوار. تميز المراقبة بين قيام الإشارة، واختيار المعلمات، ومرور الحزم، وقدرة العميل على العرض. لا تستخدم كلمة «سمع» إذا كان الدليل لا يتجاوز التفاوض.

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

المصنع والغرفة موردان مختلفان

يذهب INVITE الأول إلى URI مصنع المؤتمر. يعيد الخادم في Contact عنوان المؤتمر الفعلي ويشير إلى أنه focus. بعد قيام الحوار، تذهب re-INVITE إلى المورد الجديد.

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

لا تعطي RFC 5366 معنى لقائمة في re-INVITE. لا ينبغي للعميل إرسالها. وإذا أرسلها واشترط الامتداد، يرد مورد المؤتمر 420 Bad Extension ويذكر الوسم في Unsupported.

هذا 420 لا يعني زوال المؤتمر ولا فشل الوسائط القائمة ولا غياب دعم المصنع. إنه دليل محدود على أن المورد والمرحلة لا يقبلان العملية.

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

القائمة المفهومة قد تكون قد فقدت بنية زائدة

يوفر RFC 4826 قوائم هرمية ومراجع نسبية إلى XCAP. تحتاج خدمة RFC 5366 إلى قائمة مسطحة فقط. ينبغي للعميل تجنب الخصائص الزائدة، ويجوز للمصنع التخلص مما لا يحتاجه.

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

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

حد الدليل

تثبت المصادر المجمدة نصوص المعايير والأدوار والمفردات المسجلة. لا تثبت سلوك منتج حالي أو مؤتمر حقيقي أو حادثة أو معدل انتشار. الرسائل في RFC أمثلة وليست التقاطاً لحركة فعلية.

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