الخلاصة

  • عرّف RFC 3524 دلالة SRF كي تطلب أسطر وسائط محددة بواسطة mid الاشتراك في تدفق واحد لحجز الموارد.
  • عبّر التجميع عن الخطة، بينما بقي القبول والإذن وحالة المصنف والمجدول والتحديث ووصول الوسائط أدلة مستقلة.

كان السطر a=group:SRF 1 2 صغيراً وواضحاً. يشير الرقمان إلى وصفي الصوت والفيديو، وتعلن دلالة Single Reservation Flow أن الطرف البعيد ينبغي أن يضعهما في محاولة حجز واحدة. لم يعد على المتلقي أن يخمن التقسيم المطلوب.

لكن RFC 3524 فصل منذ البداية بين تدفق الوسائط وتدفق حجز الموارد. يمكن لجلسة متعددة الوسائط أن تجمع كل التدفقات، أو تجعل لكل واحد حجزاً مستقلاً، أو تمزج النموذجين. اختار SRF علاقة بين الأشياء، ولم يمنح عرض نطاق أو مساراً أو دوراً في المجدول.

حافظت الكلمات المعيارية على الحد. أسطر المجموعة SHOULD أن تُربط بالتدفق نفسه، والأسطر خارجها SHOULD NOT أن تدخل فيه. وقد تتكون المجموعة من سطر واحد. كانت هذه قاعدة لبناء الطلب التالي، لا تقريراً بأن الشبكة نفذته.

وفر إطار التجميع مراجع قابلة للتحقق. يجب أن يكون كل mid فريداً داخل جلسة SDP، ويسرد group تلك المعرفات تحت دلالة محددة. إذا لم يجد المعرف سطر وسائط مطابقاً، فلا تصنعه الكتابة في القائمة. أبقى RFC 5888 هذه البنية لاحقاً. كما أن SDP يسمح للمتلقي بتجاهل السمة التي لا يفهمها؛ صحة النص لا تثبت دعم الوظيفة.

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

استخدم المثال SIP لنقل SDP وRSVP لإنشاء الحجز، لكنه سمح ببروتوكولات أخرى. لذلك بقي SRF في طبقة الوصف، لا التنفيذ.

في RSVP لا يزال على المستقبل إرسال Resv يحمل flowspec للجودة المطلوبة وfilter spec لاختيار الحزم. عند كل عقدة يفحص admission control كفاية الموارد، ويفحص policy control الإذن. فشل أي منهما يمنع تثبيت الحالة. بعد النجاح فقط يمكن إعداد المصنف والمجدول.

والحالة المثبتة ليست دائمة. تحافظ رسائل Path وResv الدورية على soft state. عند تغير المسار تنشأ حالة جديدة وتزول القديمة بعد انتهاء المهلة. يمكن أن يبقى SDP صحيحاً بينما تختفي الموارد التي كان يقصدها.

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

فصل RFC 3312 بين الحالة الحالية والحالة المرغوبة لـQoS. هذا الفصل موجود لأن وصف الهدف لا يجعله واقعاً. أجاب SRF عن سؤال: أي وسائط تشترك في المحاولة؟ ولم يجب: هل تحققت الموارد في الاتجاهين؟

أظهر قسم الأمن سلطة السطر وحدودها. يستطيع مهاجم يضيف أسطر SRF أن يجبر الطرف على إنشاء عدد أكبر أو أصغر من تدفقات الحجز. العدد الأكبر يستهلك موارده، والأصغر يضعف الجودة. لذلك أوصى RFC بقوة بحماية تكامل SDP، وذكر S/MIME عند حمله في SIP.

يثبت التكامل هوية التعليمات وعدم تعديلها. لا يخلق السعة، ولا يتجاوز السياسة، ولا يجعل الطرف غير الداعم يفهم SRF، ولا يجدد الحالة، ولا يثبت أن المستخدم سمع أو شاهد شيئاً. كذلك يسجل IANA رمزاً مشتركاً ولا يراقب جلسة حية.

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

المصادر