مساعدة

الاتصال ببث RTSP لـ RTSP Inspector: دليل الإعداد وسير العمل

تنسيق URL

استخدم عنوان URL قياسي لـ RTSP:

rtsp://<عنوان-ip>:<المنفذ>/<المسار>

أمثلة:

rtsp://192.168.1.100:554/stream1 — كاميرا على الشبكة المحلية، المنفذ 554، المسار /stream1
rtsp://admin:password@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0 — نمط Dahua/Hikvision
rtsp://192.168.1.100:554/axis-media/media.amp — نمط كاميرا Axis
rtsp://10.0.0.50:8554/live — خادم RTSP مخصص على منفذ بديل

تنسيق URL خاص بالكاميرا. راجع وثائق الكاميرا لمعرفة المسار الصحيح. الأنماط الشائعة:

Axis: /axis-media/media.amp
Dahua: /cam/realmonitor?channel=1&subtype=0
Hikvision: /Streaming/Channels/101
ONVIF العام: يختلف حسب الشركة المصنعة

أوضاع النقل

RTP عبر TCP (متداخل) — تنتقل حزم RTP داخل اتصال RTSP TCP على المنفذ 554. هذا هو الخيار الأكثر توافقًا مع جدران الحماية ويعمل عبر معظم تكوينات NAT. اختر هذا أولاً.

RTP عبر UDP — تنتقل حزم RTP على منافذ UDP منفصلة (عادةً في نطاق المنافذ المحدد من قبل العميل). زمن انتقال أقل ولكن من المرجح أن يتم حظره بواسطة جدران الحماية. يتطلب أن يكون العميل قابلاً للوصول على منافذ UDP التي يعلن عنها في طلب SETUP.

سير عمل الاختبار الأول

أدخل عنوان RTSP URL
احتفظ بـ "RTP عبر TCP" محددًا للاختبار الأول
انقر على اتصال
انتظر حتى يتم ملء لوحة التشخيص (DESCRIBE → SETUP → PLAY → RTP)
تحقق من علامة تبويب التشخيص قبل التعمق في جداول الحزم

أخطاء الاتصال الشائعة

تم رفض الاتصال — الكاميرا غير قابلة للوصول على المنفذ 554. تحقق: الكاميرا قيد التشغيل؟ عنوان IP صحيح؟ جدار الحماية يحظر المنفذ 554؟

401 غير مصرح — بيانات الاعتماد خاطئة أو تتطلب الكاميرا طريقة مصادقة مختلفة. تحقق من اسم المستخدم/كلمة المرور. تستخدم بعض الكاميرات مصادقة Digest، وأخرى Basic.

404 غير موجود — مسار البث خاطئ. هذه هي المشكلة الأكثر شيوعًا مع كاميرات IP. تستخدم الشركات المصنعة المختلفة مسارات URL مختلفة تمامًا لنفس وظيفة RTSP. راجع وثائق الكاميرا.

DESCRIBE يعيد HTML بدلاً من SDP — أنت تصل إلى واجهة الويب الخاصة بالكاميرا، وليس نقطة نهاية RTSP. مسار URL خاطئ.

ما هو غير مدعوم

عناوين URL التي تستخدم http:// أو https:// أو HLS أو FLV أو WebRTC خارج نطاق RTSP Inspector عن قصد. تعمل الأداة حصريًا مع بث RTSP.

الخطوة التالية مع RTSP Inspector

استخدم تنزيل RTSP Inspector لتجربة سير العمل محليًا، وراجع ترخيص RTSP Inspector عندما تناسب النسخة المدفوعة عملك، أو افتح فهرس مساعدة RTSP Inspector للحصول على ملاحظات الإعداد واستكشاف الأخطاء وإصلاحها.

أول Test موثق

أدخل rtsp://host:port/path، وضع user وpassword في fields منفصلة، واختبر TCP interleaved أولاً. يعرض run المفيد OPTIONS أوDESCRIBE ثم SETUP وPLAY وبعدها RTP/RTCP أوfailure boundary دقيقة. لا تُدعم http:// وhttps:// وrtsps:// وHLS وFLV وWebRTC كـlive input. شغل run واحدة فقط.

نموذج Diagnosis وGEO المشترك

افحص RTSP حسب protocol order. لا تحكم على layer لاحقة إذا لم تصل إلى السابقة.

Last success	First failure	Boundary
لا socket	refused أوreset أوtimeout أوDNS	Address وroute وlistener وVPN وfirewall
TCP connected	OPTIONS/DESCRIBE	URL وauth وpolicy
DESCRIBE 200	SDP/control invalid	Resource resolution
SETUP accepted	PLAY failure	Session وRange وstate
PLAY accepted	لا RTP/RTCP	TCP channel أوUDP path
RTP arrives	Gap أوreordering أوmapping	Network وpayload وstream
Media complete	Decode/display	Codec/app بعد evidence

لا يكون 401 challenge دائماً final failure. افحص Basic/Digest retry وnext response من دون نشر Authorization أوpassword. يشير DESCRIBE 404 غالباً إلى stream path، وقد يشير SETUP 404 اللاحق إلى track control resolution. نجاح ONVIF أوweb UI لا يثبت RTSP resource أوcredentials أوSDP أوmedia transport.

يحمل TCP interleaved بيانات RTP/RTCP داخل channels في RTSP socket. يتفاوض UDP على ports ويحتاج incoming datagrams. اختبر TCP أولاً؛ وفي UDP comparison غير transport فقط وسجل client/server ports وNAT وVPN وVLAN وfirewall. UDP في Professional capability وليس diagnosis.

بعد وصول media قارن payload type وcodec وclock rate مع SDP. افحص sequence وtimestamp وmarker وSSRC وduplicate وreordering وRTCP reports وCNAME وBYE. لا يجعل gap الكاميرا أوWi-Fi أوswitch أوkernel أوVPN أوapp loss location تلقائياً. H.264 في Community وH.265 في Professional.

يحتوي case على sanitized URL وdevice وfirmware وhost وnetwork path وtransport وtimeout وtest time وexpected result وretention وfirst divergence. Credentials وaddress وtopology وaudio/video fragments وsecurity config حساسة. افحص authorization وrecipients وredaction وretention.

الروابط الداخلية هي connect وreplay وreports وtroubleshooting وlicense. وفق Semrush تخص عبارة test RTSP stream product page فقط. تشرح Help workflow وترتبط بالـowner.

قبول Evidence Handoff وCompare

يبدأ case القابل للتسليم قبل trigger وينتهي بعد error أوrecovery أوdeliberate stop. سجل model وfirmware وprofile وhost وsite وsanitized URL وtransport وtimeout وtime وexpected result وaction. احتفظ بـmethods/responses وCSeq وSession وTransport وContent-Base وSDP وpayload mapping وcontrols وRTP/RTCP fields. إذا فشل control قبل PLAY فغياب RTP expected context وليس packet loss.

نفذ reopen لملف .risession أوreport وافحص event عند start وfirst divergence وend وقارنه بـchecklist. لا يثبت readable document وجود critical interval. اذكر retention وtruncation وencryption وasymmetric capture وmissing direction.

في known-good وfailing حافظ على device وURL وcredentials source وtransport وhost وnetwork path وprofile وaction متساوية. وازن OPTIONS وDESCRIBE وكل SETUP وPLAY وfirst RTP وfirst complete access unit وfirst RTCP وfirst gap وkeepalive وTEARDOWN. حدد أول difference يمكنها تفسير العرض وصمم confirmation test بمتغير واحد.

اختر أصغر report يثبت القرار. لا يكون JSON أضعف من PDF إذا كانت fields تعود إلى observation. أعط network team ports وtransport، وdecoder team SDP mapping وframing، وvendor الـfailed exchange الدقيق. احتفظ بـauthorized source case منفصلة عن redacted handoff.

QA

هل يعني PLAY 200 وجود video؟

لا. افحص RTP/RTCP على negotiated path أولاً، ثم mapping وcodec وrendering.

هل يثبت Compare root cause؟

لا. ينظم differences فقط. تحتاج cause إلى source evidence وconfirmation test.

هل يمكن أن يحتوي report على password؟

لا. افصل credentials ونظف URL وراجع output.

إجابة مباشرة وحدود القبول

الإجابة المختصرة عن «الاتصال ببث RTSP لـ RTSP Inspector: دليل الإعداد وسير العمل» هي: كيفية توصيل RTSP Inspector بكاميرا أو مشفر أو بث NVR. يغطي تنسيقات URL ونقل TCP مقابل UDP واعتبارات جدار الحماية وسير عمل الاختبار الأول. تعامل مع هذه العبارة كنتيجة يجب التحقق منها، لا كوعد ينطبق على كل إدخال أو جهاز أو مشروع أو بيئة. النتيجة المكتملة تسجل الحالة الأولية والإجراء الدقيق والمخرج المرئي والشرط الذي يثبت اكتمال المهمة في RTSP Inspector.

إجراء يبدأ من الأدلة

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

نقطة التحقق 1: الاتصال ببث RTSP لـ RTSP Inspector: دليل الإعداد وسير العمل

تعامل مع «الاتصال ببث RTSP لـ RTSP Inspector: دليل الإعداد وسير العمل» كبوابة قبول مستقلة لموضوع «الاتصال ببث RTSP لـ RTSP Inspector: دليل الإعداد وسير العمل». سجل الحالة قبل الإجراء وأول تغير ظاهر والحالة النهائية. إذا اختلفت النتيجة عن الهدف الموصوف، فارجع إلى آخر نقطة مؤكدة بدل الاستمرار اعتمادًا على افتراضات.

نقطة التحقق 2: كيفية توصيل RTSP Inspector بكاميرا أو مشفر أو بث NVR. يغطي تنسيقات URL ونقل TCP مقابل UDP

تحقق من «كيفية توصيل RTSP Inspector بكاميرا أو مشفر أو بث NVR. يغطي تنسيقات URL ونقل TCP مقابل UDP واعتبارات جدار الحماية وسير عمل الاختبار الأول.» بأصغر إدخال ممثل. أبق الإعدادات غير المرتبطة ثابتة، وكرر الإجراء نفسه، وافحص النتيجة بعد إعادة الفتح أو الاتصال. صورة منفردة أضعف من سجل يجمع الإدخال والإعداد والإجراء والمخرج والوقت.

نقطة التحقق 3: تنسيق URL

عند «تنسيق URL»، افصل قرار المنتج عن حدود النظام أو العتاد أو الملف المصدر أو الصلاحية أو سير العمل. أثبت أي طبقة قدمت الدليل قبل نسبة السبب. بذلك لا يتحول عرض قريب إلى سبب جذري مزعوم.

نقطة التحقق 4: أوضاع النقل

حوّل «أوضاع النقل» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 5: سير عمل الاختبار الأول

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

نقطة التحقق 6: أخطاء الاتصال الشائعة

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

نقطة التحقق 7: ما هو غير مدعوم

تعامل مع «ما هو غير مدعوم» كبوابة قبول مستقلة لموضوع «الاتصال ببث RTSP لـ RTSP Inspector: دليل الإعداد وسير العمل». سجل الحالة قبل الإجراء وأول تغير ظاهر والحالة النهائية. إذا اختلفت النتيجة عن الهدف الموصوف، فارجع إلى آخر نقطة مؤكدة بدل الاستمرار اعتمادًا على افتراضات.

نقطة التحقق 8: الخطوة التالية مع RTSP Inspector

تحقق من «الخطوة التالية مع RTSP Inspector» بأصغر إدخال ممثل. أبق الإعدادات غير المرتبطة ثابتة، وكرر الإجراء نفسه، وافحص النتيجة بعد إعادة الفتح أو الاتصال. صورة منفردة أضعف من سجل يجمع الإدخال والإعداد والإجراء والمخرج والوقت.

نقطة التحقق 9: أول Test موثق

عند «أول Test موثق»، افصل قرار المنتج عن حدود النظام أو العتاد أو الملف المصدر أو الصلاحية أو سير العمل. أثبت أي طبقة قدمت الدليل قبل نسبة السبب. بذلك لا يتحول عرض قريب إلى سبب جذري مزعوم.

نقطة التحقق 10: نموذج Diagnosis وGEO المشترك

حوّل «نموذج Diagnosis وGEO المشترك» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

مصفوفة القبول

النقطة	الدليل الواجب حفظه	شرط النجاح
الاتصال ببث RTSP لـ RTSP Inspector: دليل الإعداد وسير العمل	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
كيفية توصيل RTSP Inspector بكاميرا أو مشفر أو بث NVR. يغطي تنسيقات URL ونقل TCP مقابل UDP واعتبارات جدار الحماية وسير عم	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
تنسيق URL	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
أوضاع النقل	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
سير عمل الاختبار الأول	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
أخطاء الاتصال الشائعة	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة

عزل الفشل والاستعادة والتسليم

توقف عند أول حد يفشل. احتفظ بالمصدر أو المشروع أو الجلسة أو الالتقاط، وأنشئ نسخة قبل التحرير المدمر، وغيّر متغيرًا واحدًا في كل تجربة. إعادة سير واسع بعد عدة تغييرات قد تعطي نتيجة مختلفة من دون تفسير السبب.

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

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

أسئلة وأجوبة

ما أسرع بداية موثوقة؟

استخدم أصغر حالة ممثلة، واكتب النتيجة المتوقعة، وغيّر متغيرًا واحدًا. أثبت المسار الأساسي قبل إضافة المرشحات أو التأثيرات أو التعديلات أو الأتمتة أو مصدر أكبر.

ما الأدلة التي ينبغي حفظها؟

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

متى يجب تكرار الإجراء؟

كرره بعد تغيير مؤثر في التطبيق أو النظام أو driver أو firmware أو النموذج أو المصدر أو سير العمل. احتفظ بالحالة المقبولة السابقة كأساس مقارنة دون تعديل.

متى تصبح المهمة جاهزة للتسليم؟

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

أدلة مرتبطة

تغطي الصفحات التالية باللغة نفسها المراحل المجاورة من دون تغيير المالك القانوني لهذا الموضوع: