الخلاصة

  • تجمع سطر o= في SDP بين tuple ثابت لهوية الجلسة وsess-version مستقل؛ يمكن أن يتغير الوصف وتبقى الجلسة نفسها.
  • يطلب SDP العام زيادة الإصدار عند تعديل الوصف. أما Offer/Answer فيُلزم العرض المعدّل بالحفاظ على بقية origin وزيادة الإصدار واحداً، وبإعادة SDP مطابقاً إذا تكرر الإصدار.
  • يساعد الرقم الأكبر على رفض وصف متأخر، لكنه لا يصادق المرسل ولا يقبل العرض ولا يثبت الإذن أو وصول الوسائط أو موافقة الإنسان.

كان للاستمرارية سؤالان

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

وضع SDP الجوابين في سطر الأصل:

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

يتكوّن lineage الجلسة من اسم المستخدم ومعرّف الجلسة ونوعي الشبكة والعنوان وعنوان origin. أما sess-version فيرتب الأوصاف داخل ذلك lineage. لذلك يجب التحقق من tuple كاملاً قبل مقارنة رقمين؛ تشابه sess-id وحده لا يدمج أصلين مختلفين.

لم يكن origin بطاقة هوية

قد يكون username اسم دخول، وقد يكون مجرد . وتسمح المواصفة الحديثة، حمايةً للخصوصية، باسم اعتباطي وعنوان origin خاص ما دامت فرادة tuple الكاملة محفوظة.

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

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

حكم كل مستقبِل على المراجعة محلياً

عند تعديل الوصف، تزيد أداة الإنشاء sess-version. يستطيع المستقبِل حفظ الأصل والإصدار وبصمة النص الذي قبله، ثم يمنع نسخة أقدم من إزاحة نسخة أحدث.

لا توجد خدمة عالمية تمنح كل مراجعة رقماً. الدليل محلي ونسبي. يطلب SDP العام الزيادة، لا الزيادة واحداً في كل تطبيق؛ والتوصية باستعمال timestamp لا تجعله وقتاً مدنياً؛ ولا معنى لترتيب إصدارين تحت tuple مختلفين.

السجل القابل للتدقيق ليس «رأيت 42»، بل «رأيت هذه البايتات بوصفها الإصدار 42 لهذا origin ضمن هذا السياق، واتخذت هذه السياسة القرار الآتي».

شدّد Offer/Answer عقد المراجعة

بدأ SDP صيغةً للوصف. أضاف Offer/Answer طريقة وصول agentين إلى رؤية مشتركة، واعتمد على بروتوكول أعلى مثل SIP لحمل الرسائل وصيانة السياق وترتيبها ورفضها وحل العرضين المتزامنين.

إذا عدّل agent عرضه السابق، يبقى سطر o= الجديد مطابقاً للسابق إلا أن الإصدار يزيد واحداً بالضبط. تثبت الإحداثيات الثابتة استمرار lineage، وتعلن الخطوة الواحدة المراجعة التالية لذلك agent.

ويعمل القيد في الاتجاه الآخر أيضاً. إذا لم يتغير الإصدار وجب أن يكون SDP مطابقاً للنص المرتبط به. يمكن إعادة عرض مطابق باعتباره no-op، وعلى المستقبِل إعطاء answer صحيح، لكن لا يجوز وضع بايتات جديدة تحت رقم قديم.

ينشأ بذلك invariant واضح للتدقيق: نصان مختلفان تحت (origin, version) واحد دليلان متعارضان، لا بديلان متساويان. أسبقية الوصول لا تحل التعارض.

ويقيّد Offer/Answer معرّف الجلسة والإصدار بتمثيل 64-bit signed، ويجعل الإصدار الأول دون 2^62 - 1 لتجنب rollover. هذه حدود لهذا الاستخدام وليست حساباً دائرياً لكل SDP.

بقي الإصدار الجديد اقتراحاً

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

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

حتى answer الصحيح يثبت اتفاقاً وصفياً فحسب. لا يثبت أن الحزم وصلت، أو أن codec عمل، أو أن firewall فتح المسار، أو أن مستخدماً وافق، أو أن التسجيل مشروع، أو أن الخدمة اكتملت.

لم تصنع الحداثةُ الثقة

يستطيع المهاجم كتابة عدد ضخم أيضاً. لذلك يعتمد Offer/Answer على بروتوكول الإشارة لتقديم مصادقة طرفية وحماية سلامة للعروض والأجوبة، بينما يحتفظ المستقبِل بقرار admission والموافقة محلياً.

تسمّي المصادقة المصدر المعترف به؛ وتحمي السلامة الرسالة أثناء النقل؛ ويعلن origin lineage؛ ويعلن version المراجعة؛ وتسجل حالة Offer/Answer الاقتراح والقبول أو الرفض؛ وتقيس مراقبة الوسائط الأثر الفعلي. لا يحل واحد منها محل الآخر.

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

المصادر وحدود الدليل

تقوم السلسلة المعيارية على RFC 2327 وRFC 4566 وRFC 8866 وRFC 3264. تثبت هذه النصوص القواعد وOffer/Answer، ولا تقيس توافق المنتجات الحالية أو تثبت هوية مرسل حي أو نجاح تسليم الوسائط.