الخلاصة

  • كان نجاح SETUP ينشئ سياق تحكم في الخادم ويعيد معرّف Session؛ أما وصف SDP أو بقاء اتصال TCP مفتوحاً فلم يكن أي منهما ينشئ تلك الحالة.
  • أمكن للسياق أن يبقى عند استبدال اتصال التحكم، لكن المعرّف لم يغنِ عن URI الصحيح أو حالة الطريقة أو المصادقة أو قابلية الوصول إلى مسار الوسائط.
  • استمرت ذاكرة الخادم ما دام يحتفظ بالسياق ويتلقى دليلاً مقبولاً على الحيوية. وبعد TEARDOWN أو انتهاء المهلة أو إجراء نهائي آخر، كان الأمر التالي قد يتلقى 454 Session Not Found.

لم يكن السلك هو جهاز التحكم

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

عالج RFC 2326 هذا التفاوت سنة 1998 بعبارة واضحة: لا وجود لمفهوم «اتصال RTSP». كانت الجلسة التي يحفظها الخادم موسومة بمعرّف ومستقلة عن اتصال نقل مثل TCP. لذلك استطاع العميل أن يفتح اتصالات موثوقة عدة ويغلقها، مع بقاء سياق تحكم واحد.

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

الوصف لا يساوي الحجز

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

تظهر كلمة «جلسة» في القاموسين، ولذلك يسهل الخلط. قد يسرد ملف SDP الصوت والصورة ويعرض مراجع التحكم، لكنه لا يثبت أن الخادم حجز منافذ أو قبل وسيلة نقل أو خصص مخازن لعميل بعينه. الوصف يبين ما يمكن أن يوجد؛ ولا يثبت ما قبله الخادم فعلاً.

كان SETUP هو نقطة العبور. يسمي العميل مورداً إعلامياً ويعرض بدائل Transport التي يستطيع استقبالها. فإذا وافق الخادم، اختار البديل المناسب وحفظ معالمه وأعادها. يصف RFC 7826، الذي حل محل RTSP 1.0 في 2016، النتيجة صراحة بأنها إنشاء سياق جلسة RTSP. ومع الرد يصل معرّف أنشأه الخادم في ترويسة Session.

العنوان الثاني كان يشير إلى ذاكرة الخادم

يشير URI الخاص بالوسائط إلى الشيء الذي يمكن التحكم فيه. أما Session فيميز سياق تسليم مقبولاً عن سياق آخر، حتى إذا استخدما المورد نفسه. طلب RTSP 1.0 سلسلة عشوائية مبهمة لا تقل عن ثمانية ثمانيات. وحدد RTSP 2.0 طولاً بين 8 و128 محرفاً، مع توليد عشوائي تشفيرياً، وتوصية بنحو 128 بتاً من الإنتروبيا.

عالج المرجع إلى RFC 4086 خطر التخمين. فالمولد الضعيف يجعل العثور على قيمة تخص طرفاً آخر أسهل. غير أن صعوبة التنبؤ لا تمنح حقاً في المشاهدة. حذر RFC 7826 من أن المعرّف لا يحمي من اختطاف الجلسة ما لم يحافظ العميل والخادم والوكلاء الموثوقون على سريته.

للمصادقة آلية منفصلة. يستخدم Digest في RFC 7616 تحدياً وبيانات اعتماد وnonce وضوابط لإعادة الإرسال. تجيب Session عن سؤال «أي سياق محفوظ؟»، وتجيب المصادقة عن سؤال «أي طالب يقبل ضمن نطاق الحماية؟». وجودهما في الطلب نفسه دليل على اختلاف المعنى، لا على التكرار.

معرفة المعرّف لا تلغي URI

بعد أن يتلقى العميل القيمة، يرسلها مع PLAY وPAUSE وTEARDOWN وغيرها من الأوامر المتعلقة بالسياق. وهكذا يصل الأمر عبر اتصال TCP لاحق إلى الذاكرة الصحيحة. لكن ترويسة Session لا تمحو URI الخاص بالطلب.

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

قد تكفي Session للعثور على سجل داخلي، لكنها لا تجيز كل طريقة على كل مورد في ذلك السجل. لذلك ميّز RTSP بين جلسة مفقودة، وطريقة غير صالحة في الحالة الراهنة، وعملية مجمعة في النطاق الخطأ. لم يسمح لمفتاح بحث مريح بأن يختصر هوية المورد وآلة الحالات وصلاحية الأمر في حقل واحد.

وإذا حاول SETUP إضافة مورد إلى سياق قائم ثم فشل، اشترط RTSP 2.0 أن تبقى الجلسة القديمة وحالة Transport كما لو أن المحاولة لم تقع. فالطلب الجزئي الفاشل لا يعيد كتابة سطح التحكم المقبول خفية.

جلسات كثيرة في اتصال، واتصالات متعاقبة للجلسة

ألزم RTSP 2.0 الخوادم بدعم اتصالات TCP المستمرة والعابرة. يستطيع العميل إرسال SETUP وPLAY، ثم إغلاق الاتصال وفتح آخر حين يريد PAUSE. وهكذا يمكنه النجاة من ضياع TCP بسبب انتهاء حالة NAT مثلاً، من دون إعادة إنشاء العرض من الصفر.

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

ظل مسار الوسائط طبقة أخرى. قد يمر RTP في منافذ UDP تفاوض عليها SETUP، أو يتداخل في قناة التحكم. ومع ذلك لا يثبت السياق الصحيح أن المرشحين يعبرون NAT أو جدار الحماية. لهذا طبق RFC 7825 ICE على وسائط الداتاغرام التي يتحكم فيها RTSP. كانت Session تحدد الحالة المراد تغييرها، بينما تختبر ICE إمكانية وصول الحزم.

لبقاء الذاكرة ثمن من إشارات الحيوية

لا يستطيع الخادم الاحتفاظ بالسياقات المهجورة إلى الأبد. كان رد Session يستطيع إعلان المدة التي ينتظرها بين الطلبات أو الإشارات المقبولة؛ والقيمة الافتراضية، عند عدم إعلان غيرها، 60 ثانية. في RTSP 2.0 كان timeout خاصاً بالرد، ولا يجوز تغيير طوله أثناء الجلسة القائمة.

يمكن لأي طلب RTSP يشير إلى السياق أن يجدد الحيوية. ولإشارة keep-alive خالصة، فضلت المواصفة SET_PARAMETER فارغة. وفي عمليات RTP، استطاع RTCP تقديم دليل إضافي. عرّف RFC 3550 تقارير المرسل والمستقبل عن المصدر والاستقبال؛ وأجاز RFC 7826 اعتبار التقرير المرتبط بالمصدر وتركيبة الشبكة الملائمين إشارة إلى أن جهة العميل لا تزال حاضرة.

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

قد تبقى القيمة بعد زوال ما كانت تشير إليه

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

بعد ذلك لا يعيد تكرار المعرّف القديم أي شيء. يغطي الرد 454 Session Not Found حالة غياب Session أو بطلانها أو انتهاء مهلتها. قد يحتفظ العميل بالمحارف نفسها بدقة، مع عدم وجود سجل حي يطابقها في الخادم.

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