مهلة RTSP: متى يجب تجربة TCP Interleaved أو UDP Unicast أو إصلاح مسار الشبكة

تعد "مهلة RTSP" واحدة من أوسع عبارات استكشاف أخطاء الكاميرا وإصلاحها. يمكن أن يعني ذلك انتهاء مهلة اتصال TCP بخادم RTSP. يمكن أن يعني ذلك إرجاع DESCRIBE ببطء. يمكن أن يعني ذلك نجاح "PLAY" ولكن حزم RTP لم تصل أبدًا. يمكن أن يعني ذلك أن منافذ UDP قد تم حظرها، أو أن NAT أعادت كتابة شيء ما بشكل غير صحيح، أو أن جدار الحماية يسمح بالتحكم في حركة المرور ولكن ليس حركة مرور الوسائط.

العبارة غامضة. الأدلة لا يجب أن تكون.

مهلة التحكم منفصلة عن مهلة الوسائط

عادةً ما يتم التحكم في RTSP عبر TCP. قد تتدفق وسائط RTP عبر UDP أو قد تكون مشذرة عبر اتصال RTSP TCP. القسم التشخيصي الأول هو:

• هل تم فتح اتصال RTSP TCP؟
• هل أجاب الخادم على OPTIONS؟
• هل قام DESCRIBE بإرجاع SDP؟
• هل نجح SETUP؟
• هل نجح "PLAY"؟
• هل وصل RTP بعد "PLAY"؟

إذا فشل اتصال TCP نفسه، فافحص المضيف والمنفذ والتوجيه وجدار الحماية وVPN وما إذا كانت خدمة RTSP ممكّنة أم لا. إذا نجح التحكم في RTSP ولكن لم يصل RTP، فافحص مفاوضات النقل ومسار الوسائط.

لماذا يفشل UDP غالبًا أثناء عمل TCP

يمكن أن يفشل UDP RTP حتى عندما يعمل التحكم في RTSP. يتفاوض العميل والكاميرا على المنافذ أثناء "الإعداد". يمكن لجدران الحماية وأجهزة NAT وسياسة VLAN والتوجيه السحابي أن تمنع مسار الوسائط. قد ترسل الكاميرا RTP إلى منفذ لا يمكن للعميل استقباله. قد تسمح بوابة الأمان بـ TCP 554 ولكنها تسقط UDP.

أعراض:

• نجح DESCRIBE
• نجح SETUP
• نجح "اللعب".
• عدم وصول أي حزم RTP
• يقوم اللاعب في النهاية بالإبلاغ عن انتهاء المهلة أو ظهور شاشة سوداء

وفي هذه الحالة، يعد التبديل إلى TCP المشذّر اختبارًا مفيدًا. يرسل RTP داخل اتصال RTSP TCP. إذا كان TCP interleashed يعمل ولم يعمل UDP، فمن المحتمل ألا يكون برنامج الترميز هو المشتبه به الأول. مسار وسائط الشبكة هو.

يعد TCP Interleaved بمثابة اختبار، وليس دائمًا الإجابة النهائية

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

يقارن:

• UDP أحادي البث RTP: هل تصل الوسائط؟
• TCP مشذّر RTP: هل تصل الوسائط؟
• RTCP: هل تقارير المرسل مرئية؟
• فقدان الحزمة: هل يُظهر UDP فجوات التسلسل؟
• الكمون: هل يقوم TCP بإنشاء أكشاك تحت ضغط النطاق الترددي؟

إذا كان النشر يتوقع UDP، فإن نجاح TCP لا يتحقق من صحة الموقع بشكل كامل. فهو يحدد حدود الشبكة التي تحتاج إلى العمل.

رفض الاتصال يختلف عن المهلة

"تم رفض الاتصال" يعني عادةً أن المضيف رفض اتصال TCP بشكل نشط. الأسباب الشائعة:

• تم تعطيل خدمة RTSP
• منفذ خاطئ
• البرامج الثابتة للكاميرا لا تعرض RTSP
• يختلف منفذ NVR عن منفذ الكاميرا
• يرفض جدار الحماية بدلا من قطرات

المهلة تعني عدم وصول أي إجابة قبل أن يستسلم العميل. الأسباب الشائعة:

• قضية التوجيه
• إسقاط جدار الحماية
• شبكة لا يمكن الوصول إليها
• تعيين خاطئ للمنافذ العامة
• الكاميرا حاليا
• مشكلة مسار VPN

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

ما يجب التقاطه في تقرير المهلة

يجب أن يتضمن تقرير مهلة RTSP المفيد ما يلي:

• المضيف والمنفذ المستهدف
• ما إذا كان اتصال TCP
• تم إرسال آخر طريقة RTSP
• حالة الاستجابة إن وجدت
• عاد SDP أم لا
• رأس النقل المحدد
• منافذ العميل/الخادم التي تم التفاوض عليها
• سواء وصل RTP
• سواء وصل RTCP
• مقارنة TCP المشذرة
• مقارنة UDP

وهذا هو الدليل الذي يحتاجه مهندس الشبكات. "انتهت المهلة" ليست كافية.

حيث يناسب مفتش RTSP

يساعد RTSP Inspector من خلال الحفاظ على التحكم في RTSP، وتفاوض النقل، وتسليم RTP، وأدلة RTCP، وجاهزية برنامج الترميز في تدفق تشخيصي واحد. إنها لا تحاول أن تكون اللاعب الذي يخفي التميز.

بالنسبة لعمليات بحث مهلة RTSP، فإن النتيجة الأقوى هي الحكم القصير:

• مهلة التحكم قبل SDP
• انتهت مهلة الوسائط بعد "التشغيل" الناجح
• تم حظر UDP ولكن يعمل TCP المشذّب
• تم رفض TCP على منفذ RTSP
• تم تسليم RTP ولكن برنامج الترميز غير جاهز لفك التشفير

كل حكم له إصلاح مختلف. قد تكون الكلمة الأساسية للبحث هي "مهلة RTSP"، ولكن الإجابة الحقيقية تكمن في الحدود بين التحكم والوسائط.