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

في سيناريو قيادة وت dispatch نموذجي، قد تكون هناك حاجة في الوقت نفسه إلى المعاينة الحية، والمحادثة منخفضة التأخير، وتسجيل الفيديو، وتسلسل المنصات، والمشاهدة عبر الهاتف المحمول، والربط في حالات الطوارئ، والمشاركة عن بعد. ولهذا تظهر بروتوكولات مثل RTSP وRTP/RTCP وONVIF وRTMP وHLS وWebRTC وSRT وGB28181 غالبًا معًا في مشروع واحد. كل بروتوكول يحل مشكلة مختلفة، والحل النهائي يعتمد على التأخير، والتوافق، وعرض النطاق، وظروف الشبكة، وطريقة الوصول إلى الأجهزة، واحتياجات تشغيل مركز القيادة.

لماذا لا تكفي طريقة فيديو واحدة

تتكون مشاريع اتصالات الفيديو عادة من عدة طبقات. قد تشمل طبقة الواجهة الأمامية كاميرات IP، وكاميرات الجسم، والطائرات بدون طيار، والهواتف المحمولة، وأنظمة الاتصال الداخلي المرئي، وأجهزة NVR وDVR، وأجهزة الحافة الذكية. وقد تشمل طبقة المنصة نظام إدارة فيديو، ومنصة ت dispatch تعتمد على SIP، ونظام قيادة طوارئ، وخادم تسجيل، وبوابة وسائط، أو خدمة سحابية. أما طبقة المستخدم فقد تشمل شاشات غرفة التحكم، وعملاء المتصفح، وتطبيقات الهاتف المحمول، ووحدات الت dispatch، ومنصات قيادة تابعة لأطراف ثالثة.

هذه الطبقات لا تتحدث دائمًا بالبروتوكول نفسه. فقد توفر الكاميرا بث RTSP، بينما قد تتطلب منصة الأمن وصول GB28181. وقد يفضل المتصفح WebRTC للتفاعل منخفض التأخير أو HLS للتشغيل المستقر. وقد يحتاج مشروع نقل كبير عبر شبكة عامة إلى SRT لتحسين الموثوقية عند فقدان الحزم. وقد تستخدم الطائرة بدون طيار أو الجهاز المحمول طريقة نقل خاصة، ثم يخرج RTMP أو بيانات HTTP API أو تدفقات فيديو قائمة على SDK.

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

RTSP للوصول إلى تدفقات الكاميرات وأجهزة NVR

RTSP، أو Real Time Streaming Protocol، هو من أكثر الطرق شيوعًا للوصول إلى تدفقات الفيديو من كاميرات IP وأجهزة NVR وDVR والعديد من أجهزة الفيديو. ويستخدم غالبًا للمعاينة الحية، وسحب تدفقات الأجهزة، ووصول المنصات، وتوجيه الفيديو داخليًا.

في كثير من المشاريع، يكون RTSP مسؤولًا عن التحكم في جلسة الفيديو، بينما يتم نقل بيانات الوسائط الفعلية عادة عبر RTP. ووفقًا للجهاز وبيئة الشبكة، قد يستخدم التدفق TCP أو UDP. يمكن أن يقلل UDP من التأخير، بينما قد يحسن TCP استقرار التدفق في ظروف شبكة معينة.

يناسب RTSP الوصول الاحترافي إلى الفيديو داخل شبكة LAN، أو شبكة خاصة، أو نظام أمني، أو مركز تحكم صناعي، أو منصة ت dispatch. لكنه ليس دائمًا الخيار الأفضل للتشغيل المباشر في المتصفح أو التوزيع واسع النطاق عبر الإنترنت العام. في هذه الحالات، قد يحتاج النظام إلى تحويل RTSP إلى WebRTC أو HLS أو RTMP أو تنسيق تسليم آخر.

RTP وRTCP كطبقة نقل للوسائط

RTP، أو Real-time Transport Protocol، هو طريقة أساسية لنقل الوسائط تستخدمها RTSP ومكالمات الفيديو عبر SIP وWebRTC وأنظمة الاتصالات الأخرى في الزمن الحقيقي. فهو يحمل حزم الصوت والفيديو عبر الشبكة، عادة فوق UDP، لدعم نقل الوسائط في الزمن الحقيقي.

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

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

ONVIF لاكتشاف الأجهزة والتحكم بها

يستخدم ONVIF على نطاق واسع في مشاريع المراقبة المرئية لأنه يساعد المنصات على اكتشاف كاميرات IP من شركات مختلفة والوصول إليها والتحكم بها. وهو مفيد بشكل خاص عندما يحتاج مدمج الأنظمة إلى ربط كاميرات دون الاعتماد على منظومة علامة تجارية واحدة.

يستخدم ONVIF غالبًا لاكتشاف الأجهزة، والحصول على ملفات تعريف التدفق، والمصادقة، والتحكم في PTZ، وإدارة قدرات الكاميرا. في كثير من عمليات النشر، يوفر ONVIF إدارة الجهاز والتحكم، بينما لا يزال تدفق الفيديو الفعلي يُسحب عبر RTSP.

بالنسبة إلى نظام اتصالات مرئية متقارب، يحسن ONVIF كفاءة الوصول والتوافق. ومع ذلك، لا يزال على المهندسين التحقق من دعم كل كاميرا لملف ONVIF المطلوب، ومن عمل أوامر PTZ بشكل صحيح، ومن إمكانية الحصول على تنسيق التدفق المتوقع بصورة موثوقة.

RTMP لدفع البث وتوزيع المنصة

RTMP، أو Real-Time Messaging Protocol، ارتبط في الأصل بـ Adobe Flash، لكنه لا يزال يستخدم على نطاق واسع لدفع التدفقات، والتوزيع المباشر، وإدخال منصات الفيديو، وبعض خدمات الوسائط السحابية. ويستخدم غالبًا عندما يحتاج جهاز أو منصة إلى دفع الفيديو إلى خادم وسائط.

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

في الأنظمة الحديثة، يتم غالبًا تحويل RTMP إلى HLS أو FLV أو WebRTC أو تنسيقات أخرى للتشغيل النهائي. وهو بروتوكول جسري عملي، خصوصًا عندما تدعم أجهزة الواجهة الأمامية أو المرمزات المحمولة إخراج RTMP بالفعل.

HLS للتشغيل عبر الويب والمشاهدة واسعة النطاق

HLS، أو HTTP Live Streaming، يستخدم على نطاق واسع للتشغيل عبر المتصفح، والمشاهدة المحمولة، وبوابات الويب، وتوزيع الفيديو واسع النطاق. وبما أنه يعتمد على HTTP، يمكنه العمل عبر منافذ ويب شائعة مثل 80 و443، وهو مناسب للتوزيع عبر CDN، وعبور الجدران النارية، ووصول جمهور كبير.

المقابل هو التأخير. عادة يكون لدى HLS تأخير أعلى من RTMP أو WebRTC. في كثير من المشاريع قد يكون التأخير النموذجي نحو 5 إلى 8 ثوانٍ، رغم أن الإعدادات المحسنة يمكن أن تقلله في بعض السيناريوهات. لذلك يناسب HLS المشاهدة المستقرة، والعرض العام، وتشغيل التسجيلات، وصفحات المراقبة عبر الويب، والمعاينة الحية غير التفاعلية.

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

WebRTC للتفاعل منخفض التأخير

صُمم WebRTC للتفاعل الصوتي والمرئي في الزمن الحقيقي داخل المتصفحات وتطبيقات الهاتف المحمول. ويستخدم عادة لمكالمات الفيديو، والت dispatch عبر المتصفح، والمعاينة المرئية منخفضة التأخير، واتصالات القيادة عن بعد، والاتصال الداخلي المرئي، وسير عمل الاستجابة الطارئة التفاعلي.

من أهم مزايا WebRTC التأخير المنخفض. في بيئات الشبكة المناسبة، يمكن لـ WebRTC غالبًا تحقيق تأخير في حدود 200 إلى 500 مللي ثانية. وهذا يجعله ذا قيمة لمراكز القيادة، والدعم عن بعد، والاتصال الداخلي المرئي، والمراقبة المدعومة بالذكاء الاصطناعي، والمواقف التي يجب فيها على المشغلين الرؤية والاستجابة بسرعة.

يجلب WebRTC أيضًا تحديات هندسية. يجب مراعاة عبور NAT، وسياسات الجدار الناري، وخوادم الإشارة، وخدمات TURN/STUN، وتوافق المتصفحات، والتفاوض على الترميزات، وتزامن الخادم. في المشاريع الاحترافية، ينبغي التخطيط لـ WebRTC كجزء من بنية النظام بالكامل، وليس كتنسيق مشغل بسيط.

SRT للنقل الموثوق عبر الشبكات غير المستقرة

SRT، أو Secure Reliable Transport، يستخدم عندما يجب نقل الفيديو عبر شبكات غير مستقرة أو بعيدة المسافة. وهو مفيد للنقل عبر الإنترنت العام، والمواقع البعيدة، والمركبات المتنقلة، ومراكز القيادة المؤقتة، وإرجاع الفيديو بين المناطق، وسيناريوهات الاتصالات الميدانية حيث قد يحدث فقدان حزم وتذبذب.

يحسن SRT الموثوقية عبر آليات مثل ARQ وFEC. تساعد هذه التقنيات على استعادة الحزم المفقودة والحفاظ على جودة التدفق أثناء تقلبات الشبكة. وبالنسبة إلى قيادة الطوارئ، والنقل، والفحص الصناعي، والمراقبة عن بعد، قد يكون أكثر موثوقية من البث البسيط عبر UDP.

لا يستخدم SRT دائمًا للتشغيل النهائي. ففي كثير من الحلول يستخدم كبروتوكول مساهمة أو backhaul قوي، ثم يتم تحويله في منصة الوسائط إلى WebRTC أو HLS أو RTMP أو GB28181 أو غيرها من التنسيقات التي يحتاجها المستخدمون والمنصات.

GB28181 لربط منصات الأمن

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

تقنيًا، يعتمد GB28181 على SIP وSDP وRTP. يتولى SIP التسجيل، والإشارات، ووصول الأجهزة، والتحكم في الجلسة. ويصف SDP جلسة الوسائط، بينما يحمل RTP تدفق الوسائط. ولذلك يناسب GB28181 تسلسل المنصات، وتسجيل الأجهزة، والعرض الحي، والتشغيل، والتحكم، ومشاركة موارد الفيديو متعددة المستويات.

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

طرق وصول فيديو الطائرات بدون طيار والفيديو الخاص

تستخدم بعض الأنظمة الميدانية طائرات بدون طيار، وكاميرات جسم، وأجهزة محمولة، وأجهزة فيديو تعمل بالذكاء الاصطناعي، أو وحدات نقل خاصة بالمورد. قد تستخدم هذه الأجهزة بروتوكولات خاصة مثل OcuSync وLightBridge، أو نقلًا قائمًا على SDK، أو وسائط UDP مملوكة، أو خرج HTTP API، أو دفع RTMP، أو طرق ترحيل سحابية.

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

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

كيف يمكن أن تناسب Becke Telcom الحل

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

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

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

اختيار البروتوكول المناسب حسب السيناريو

للوصول إلى الكاميرات

يستخدم RTSP وONVIF عادة لربط كاميرات IP وأجهزة NVR. يساعد ONVIF في الاكتشاف والتحكم، بينما يوفر RTSP عادة تدفق الفيديو الحي.

للمشاهدة عبر المتصفح والهاتف المحمول

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

لدفع المنصة واستقبال التدفقات

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

لإرجاع الفيديو الميداني لمسافات طويلة

يناسب SRT الشبكات غير الموثوقة، والمواقع البعيدة، ومركبات القيادة المؤقتة، وإرجاع الفيديو الميداني عندما قد تؤثر خسارة الحزم والتذبذب في الجودة.

لتسلسل أنظمة الأمن

يناسب GB28181 ربط الكاميرات ومنصات الفيديو بأنظمة الأمن العام أو الأنظمة الحكومية أو أنظمة المراقبة متعددة المستويات.

فحوصات هندسية قبل النشر

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

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

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

الخلاصة

يعتمد نظام الاتصالات المرئية المتقارب على مجموعة من البروتوكولات وليس على تقنية فيديو واحدة. يعد RTSP وONVIF مفيدين للوصول إلى الكاميرات، ويدعم RTP/RTCP نقل الوسائط في الزمن الحقيقي، ويساعد RTMP في دفع التدفقات، ويدعم HLS المشاهدة المستقرة عبر الويب، ويمكّن WebRTC التفاعل منخفض التأخير، ويحسن SRT موثوقية النقل عبر الشبكات غير المستقرة، ويدعم GB28181 شبكات الفيديو على مستوى المنصة.

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

FAQ

أي بروتوكول فيديو هو الأفضل لاتصالات القيادة منخفضة التأخير؟

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

هل يكفي RTSP لنظام اتصالات مرئية متقارب كامل؟

لا. RTSP مفيد لسحب تدفقات الكاميرات، لكن النظام الكامل قد يحتاج أيضًا إلى ONVIF للتحكم في الأجهزة، وHLS للتشغيل عبر الويب، وWebRTC للتأخير المنخفض، وSRT للإرجاع الموثوق لمسافات طويلة، وGB28181 لربط المنصات.

لماذا يعد GB28181 مهمًا في مشاريع تكامل الفيديو؟

يكون GB28181 مهمًا عندما تحتاج موارد الفيديو إلى الاتصال بمنصات الأمن أو الأنظمة الحكومية أو منصات المراقبة متعددة المستويات. فهو يستخدم SIP وSDP وRTP للتسجيل والإشارات ونقل الوسائط.

متى يجب استخدام SRT؟

يناسب SRT النقل لمسافات طويلة أو عبر الشبكات غير المستقرة، مثل المواقع البعيدة، ومركبات القيادة المؤقتة، والعمليات الميدانية، وإرجاع الفيديو بين المناطق حيث قد تحدث خسارة حزم وتذبذب.

ما الذي يجب اختباره قبل القبول النهائي؟

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