الخلاصة
- يميز SDP بين
v=0الذي يعرّف نسخة صيغة البروتوكول وsess-versionداخلo=الذي يزداد عند تعديل وصف جلسة محددة الهوية. - لا يعمل رقم المراجعة إلا داخل صف أصل كامل. ومقارنته عبر أصلين، أو اعتبار شكله الزمني ساعة موثقة، يبدد دليل النسب الذي تحتاجه الاستمرارية.
لم يكن 402 أحدث من 391 بالضرورة
عند انتقال الخدمة إلى متحكم احتياطي قد يبدأ مولد الإصدارات لديه من قيمة أعلى أو أدنى من المتحكم السابق. لكل أداة تاريخها وطريقة تخصيصها. لا تنشئ RFC عداداً عالمياً يتقاسمه كل من يكتب SDP، كما أن تغير عنوان المنشئ يغيّر جزءاً من الهوية قبل النظر إلى الرقم.
يسهل تخزين session_id مع max(version)، لكنه يخلط ثلاثة أحداث: ترتيب أعلنه المنشئ، ووقت وصول سجله المستقبل، وقرار يجيز لأصل جديد أن يخلف قديماً. الوصول لاحقاً لا يثبت مراجعة أحدث. والمراجعة الأعلى لا تمنح سلطة. والسلطة لا تثبت أن الطرف الآخر قبل التغيير.
الصفر في v=0 ليس أول مراجعة للمكالمة
تبدأ RFC 8866 وصف SDP بالسطر v=0. هذا الحقل يحدد إصدار Session Description Protocol نفسه، وتقول الوثيقة إنه لا توجد نسخة فرعية. لذلك لا يصبح v=1 عند إضافة فيديو أو تغيير codec أو نقل عنوان الوسائط.
أما o= فيضم ست قيم: اسم المستخدم، ومعرف الجلسة، وإصدار الجلسة، ونوع الشبكة، ونوع العنوان، وعنوان unicast. هنا يصف sess-version مراجعة بيانات الجلسة. يجب على أداة الإنشاء رفعه عند تعديل الوصف، وتوصي الوثيقة باستخدام طابع زمني لتخصيصه.
ينتج عن الخلط خطآن متعاكسان. رفع v= يعلن صيغة بروتوكول غير موجودة. وتغيير المحتوى مع تثبيت sess-version يجعل نصين مختلفين يبدوان مراجعة واحدة. يحتاج السجل إلى الحقلين، لكن لكل منهما نطاق مختلف.
خمس قيم تسمي السجل والسادسة ترتبه
تعرف RFC الحالية هوية الجلسة العالمية بأنها صف اسم المستخدم ومعرف الجلسة ونوع الشبكة ونوع العنوان وعنوان unicast. لا تكفي قيمة واحدة. تكرار معرف رقمي على جهاز آخر لا ينقل التاريخ إليه، واسم المستخدم ليس مصادقة، وتغير العنوان ليس خلافة تلقائية.
كانت RFC 2327 أوضح في شرح الغرض الأول. كتب Handley وVan Jacobson أن الإصدار يساعد إعلانات الوكيل على تمييز الأحدث بين عدة إعلانات للجلسة نفسها. عبارة «الجلسة نفسها» هي شرط المقارنة. وقد احتفظت RFC 8866 بالهوية المركبة وبزيادة الإصدار عند تعديل الوصف.
إذا غيّر failover المخطط صف الأصل، فيلزم سجل ترحيل مستقل: الأصل القديم والجديد، والجهة التي وافقت، ووقت النفاذ، والحالة المنقولة، وطريق الرجوع. لا يستطيع العدد الأكبر توقيع هذه العلاقة.
في offer/answer يعني الإصدار نفسه المحتوى نفسه
تضع RFC 3264 قاعدة أدق عند تعديل جلسة قائمة. يجب أن يبقى سطر o= في العرض الجديد مطابقاً للسابق، باستثناء زيادة الإصدار واحداً. وإذا لم يزد الإصدار، وجب أن يكون SDP مطابقاً للنص الذي حمل ذلك الرقم. إعادة العرض نفسه عملية بلا تغيير فعلي، مع بقاء واجب إصدار answer صحيح.
توفر القاعدة اختباراً قابلاً للتكرار. الأصل نفسه مع الإصدار نفسه ومحتوى مختلف ليس retransmission عادياً. ينبغي حفظ النصين وhash كل منهما، وتعليم السلسلة كمتعارضة، ثم تطبيق سياسة الخطأ المحلية. اختيار آخر وصول يمحو المخالفة.
ولا يعني ارتفاع الإصدار نجاح الجلسة. إنه يثبت أن المنشئ أعلن تعديلاً. قبول answer ووصول RTP وتجربة المستخدم نتائج منفصلة.
هيئة الطابع الزمني لا توثق الوقت
توصي RFC 8866 باستخدام عدد الثواني منذ 1 يناير 1900 UTC لمعرف الجلسة، كما توصي بطابع زمني للإصدار. هذه وسيلة عملية لينتج المنشئ أعداداً مميزة ومتزايدة، وليست جهة تصديق للساعة. لا يثبت الحقل التزامن أو وقت الاستلام أو الصلاحية المؤسسية.
وتضع فقرة الأمن شرط الثقة في موضع آخر: لا يوثق وصف الجلسة ما لم يصل من مصدر معروف وموثوق عبر نقل مصادق عليه ومحمي السلامة. لذا يجمع الإيصال بين صف الأصل المعلن والهوية المصادق عليها ونتيجة حماية القناة. لا يصادق السطر على نفسه.
لدى SAP إشارة تغيير مستقلة
تمنح RFC 2974 بروتوكول Session Announcement Protocol حقلي originating source وmessage identifier hash الخاصين به. تغيير hash يجعل المستقبل يعيد تحليل الإعلان. ويظل SDP داخله محتفظاً بأصله وإصداره. إشارة التوزيع ليست نسب الوثيقة.
هذا الفصل مقصود. SDP صيغة وصف لا بروتوكول نقل، ولا يتولى وحده التفاوض على المحتوى أو الترميزات. يستعمله SIP offer/answer في إطار تفاوض محدود، ويمكن أن يحمله SAP أو HTTP أو البريد. وصول الوثيقة وهويتها وقرار التفاوض ونتيجة الوسائط سجلات مترابطة لا سجلاً واحداً.
موقع Mark Handley داخل عمل جماعي
تحمل RFC 2327 اسمي Mark Handley وVan Jacobson. وتجمع RFC 4566 بين Handley وJacobson وColin Perkins. أما RFC 8866 الحالية فتحمل أسماء Ali Begen وPaul Kyzivat وPerkins وHandley. إنه معيار جماعي متراكم، وليس اختراع شخص منفرد.
تصف Royal Society Handley بأنه Professor of Networked Systems في UCL، ومؤلف لعدد كبير من معايير الإنترنت، وعضو سابق في Internet Architecture Board. ومنحته ACM SIGCOMM جائزة 2019 عن إسهاماته في multimedia وmulticast والتحكم في الازدحام وشبكات multipath وتوحيد البروتوكولات.
ما يثبته العداد فعلاً
مع صف الأصل الكامل، وبايتات SDP الدقيقة، وسجل اقتناء موثوق، يدعم sess-version ادعاء محدوداً: أعلن هذا المنشئ أن الوصف مراجعة لاحقة للجلسة نفسها. وفي سياق RFC 3264 يكشف أيضاً اختلاف المحتوى تحت إصدار ثابت أو تعديلاً لم يرفع الإصدار.
لكنه لا يثبت خلافة أصل آخر، ولا صحة الساعة، ولا سلطة المرسل، ولا قبول العرض، ولا وصول الحزم، ولا نجاح الخدمة. لكل منها إثبات مستقل.
المصادر
- https://www.rfc-editor.org/rfc/rfc2327.txt
- https://www.rfc-editor.org/rfc/rfc2974.txt
- https://www.rfc-editor.org/rfc/rfc3264.txt
- https://www.rfc-editor.org/rfc/rfc4566.txt
- https://www.rfc-editor.org/rfc/rfc8866.txt
- https://royalsociety.org/people/mark-handley-14096/
- https://imagecdn.royalsociety.org/people/P25318.jpg
- https://sigcomm.hosting2.acm.org/awards/sigcomm-awards
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
