حُمِيت إشارة المنفذ من التعديل، لكن الطريق ظل غير مُثبت

الخلاصة

• عرّف RFC 3605 سمة a=rtcp على مستوى الوسيط كي يُذكر منفذ RTCP وعنوانه الاختياري صراحة عندما يبدد NAT علاقة التجاور القديمة بين RTP وRTCP.
• الإعلان الموثوق ليس دليلاً على التشغيل. يجب فصل نتيجة التحليل والتفاوض وربط المقبس وملاحظة الترجمة والإرسال والوصول والتحقق من RTCP والتقرير وقرار الجودة.

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

نُشر RFC 3605 في أكتوبر 2003 ضمن Standards Track لمعالجة عيب محدد في الوصف. اعتادت تطبيقات RTP استخدام منفذ للوسائط ومنفذ تالٍ فردي لـ RTCP. كان SDP يذكر منفذ الوسيط، ويستنتج التطبيق منفذ التحكم حسابياً.

تستطيع ترجمة المنافذ في NAT محو الترتيب والتكافؤ. المنفذان المتجاوران داخلياً قد يظهران خارجياً برقمين غير متجاورين. وإذا كان المترجم يدير مجموعة عناوين، فقد يظهر RTP على عنوان وRTCP على عنوان آخر. عندئذ تصبح إضافة واحد إلى منفذ الوسائط افتراضاً بلا دليل.

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

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

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

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

قدّم RFC مثالاً لاكتشاف العناوين بواسطة STUN. يخصص المضيف منفذين UDP، ويرسل من كل واحد إلى خادم، ويقرأ الخادم عنوان المصدر ومنفذه، ثم يعيدهما. بذلك يعرف المضيف الإحداثيات الخارجية التي رآها ذلك الخادم.

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

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

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

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

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

تضيف المواصفات اللاحقة خيارات لا تلغي الحدود. يسمح RFC 5761 بدمج RTP وRTCP على منفذ واحد بعد التفاوض. يصنف RFC 8859 السمة rtcp ضمن TRANSPORT عند تحليل الدمج. وما زال سجل IANA يسردها كسمة وسائط. المطلوب هو حفظ النمط الذي اختير فعلاً، لا افتراضه لاحقاً من إعداد افتراضي.

كما أعاد RFC 5389 وضع STUN في حجمه: أداة، لا حلاً كاملاً لعبور NAT. هذه قاعدة مؤسسية أيضاً. الآلية الصغيرة تقدم دليلاً صغيراً صالحاً. الاكتشاف لا يحجز. الوصف لا يوصل. الوصول لا يعني الإدخال إلى التحليلات. والتحليل لا يثبت النتيجة البشرية.

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

ينبغي أن تسجل سلسلة الأدلة نص SDP الأصلي وبصمته، ونتيجة المحلل، ونتيجة العرض والجواب، ونمط المنافذ، وربط المقبس، وملاحظة NAT، والوجهة المعلنة، وفحص السلامة. وبعدها تُسجل أول حزمة صادرة، وأول وصول بعيد، وأول RTCP صالح، وأول تقرير، والفترة التي يغطيها، وإدخاله إلى التحليل، والقرار الناتج.

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

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