بروتوكول البث المباشر في الوقت الحقيقي

الموسوعة الحرة

بروتوكول البث في الوقت الحقيقي ( RTSP ) هو بروتوكول شبكة على مستوى التطبيق مصمم لتعدد الإرسال وتقسيم حزم تدفقات نقل الوسائط المتعددة (مثل الوسائط التفاعلية والفيديو والصوت ) عبر بروتوكول نقل مناسب .

يُستخدم بروتوكول RTSP في أنظمة الترفيه والاتصالات للتحكم في خوادم بث الوسائط .

يُستخدم البروتوكول لإنشاء جلسات الوسائط والتحكم بها بين نقاط النهاية.

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

تاريخ

طُوِّر بروتوكول RTSP بواسطة RealNetworks و Netscape وجامعة كولومبيا . [ 1 ] [ 2 ] قُدِّمَت المسودة الأولى للبروتوكول إلى فريق عمل هندسة الإنترنت (IETF) في أكتوبر 1996 من قِبَل Netscape و Progressive Networks ، وبعد ذلك قدّم هينينغ شولزراين من جامعة كولومبيا مسودة "RTSP՚" ("RTSP prime") في ديسمبر 1996. [ 3 ] [ 4 ] دُمِجَت المسودتان لتوحيدهما من قِبَل فريق عمل التحكم في جلسات الوسائط المتعددة متعددة الأطراف (MMUSIC WG) التابع لفريق عمل هندسة الإنترنت (IETF)، ونُشِرَت مسودات أخرى من قِبَل الفريق. [ 5 ] [ 6 ] نُشر بروتوكول RTSP كـ RFC 2326 في عام 1998. [ 7 ]

تم نشر بروتوكول RTSP 2.0 كـ RFC 7826 في عام 2016 كبديل لبروتوكول RTSP 1.0. يعتمد الإصدار 2.0 على الإصدار 1.0 ولكنه غير متوافق مع الإصدارات السابقة (باستثناء آلية التفاوض الأساسية على الإصدار). [ 8 ]

RTP

لا يُعدّ نقل البيانات المتدفقة بحد ذاته مهمةً لبروتوكول RTSP. تستخدم معظم خوادم RTSP بروتوكول النقل في الوقت الحقيقي (RTP) بالتزامن مع بروتوكول التحكم في الوقت الحقيقي (RTCP) لتوصيل تدفق الوسائط. مع ذلك، يستخدم بعض الموردين بروتوكولات نقل خاصة بهم. على سبيل المثال، يستخدم برنامج خادم RTSP من RealNetworks بروتوكول نقل البيانات الحقيقي (RDT) الخاص بشركة RealNetworks.

توجيهات البروتوكول

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

فيما يلي طلبات RTSP الأساسية. تتوفر أيضًا بعض طلبات HTTP الشائعة، مثل طلب OPTIONS. رقم منفذ طبقة النقل الافتراضي هو 554 [ 7 ] لكل من TCP و UDP ، ولكن نادرًا ما يُستخدم الأخير لطلبات التحكم.

خيارات

يُعيد طلب OPTIONS أنواع الطلبات التي سيقبلها الخادم.
C->S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 1 المتطلبات: التشغيل الضمني Proxy-Require: gzipped-messages S->C: RTSP/1.0 200 OK CSeq: 1 عام: وصف، إعداد، تفكيك، تشغيل، إيقاف مؤقت

يصف

يتضمن طلب DESCRIBE rtsp://عنوان URL لبروتوكول RTSP ، ونوع بيانات الرد التي يمكن معالجتها. يتضمن هذا الرد وصف العرض التقديمي، عادةً بتنسيق بروتوكول وصف الجلسة (SDP). من بين أمور أخرى، يسرد وصف العرض التقديمي تدفقات الوسائط التي يتم التحكم بها باستخدام عنوان URL المجمع. في الحالة النموذجية، يوجد تدفق وسائط واحد لكل من الصوت والفيديو. يتم الحصول على عناوين URL لتدفقات الوسائط إما مباشرةً من حقول التحكم في SDP أو عن طريق إلحاق حقل التحكم في SDP بعنوان URL المجمع.
C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 2 S->C: RTSP/1.0 200 OK CSeq: 2 Content-Base: rtsp://example.com/media.mp4 نوع المحتوى: تطبيق/sdp طول المحتوى: 460 m=video 0 RTP/AVP 96 a=control:streamid=0 a=range:npt=0-7.741000 a=length:npt=7.741000 a=rtpmap:96 MP4V-ES/5544 a=mimetype:string;"video/MP4V-ES" a=AvgBitRate:integer;304018 a=StreamName:string;"مسار فيديو مُلمّح إليه" m=audio 0 RTP/AVP 97 a=control:streamid=1 a=range:npt=0-7.712000 a=length:npt=7.712000 a=rtpmap:97 mpeg4-generic/32000/2 a=mimetype:string;"audio/mpeg4-generic" a=AvgBitRate:integer;65790 a=StreamName:string;"مسار صوتي مُلمّح إليه"

يثبت

يُحدد طلب الإعداد (SETUP) كيفية نقل دفق وسائط واحد. يجب إتمام هذه العملية قبل إرسال طلب التشغيل (PLAY). يحتوي الطلب على عنوان URL لدفتر الوسائط ومُحدد النقل. يتضمن هذا المُحدد عادةً منفذًا محليًا لاستقبال بيانات RTP (صوت أو فيديو)، ومنفذًا آخر لبيانات RTCP (البيانات الوصفية). عادةً ما يُؤكد رد الخادم المعلمات المُختارة ويُكمل الأجزاء الناقصة، مثل منافذ الخادم المُختارة. يجب تهيئة كل دفق وسائط باستخدام طلب الإعداد (SETUP) قبل إرسال طلب تشغيل مُجمّع.
C->S: إعداد rtsp://example.com/media.mp4/streamid=0 RTSP/1.0 CSeq: 3 النقل: RTP/AVP؛ أحادي البث؛ منفذ العميل = 8000-8001 S->C: RTSP/1.0 200 OK CSeq: 3 النقل: RTP/AVP؛ أحادي البث؛ منفذ العميل = 8000-8001؛ منفذ الخادم = 9000-9001؛ المصدر = 1234ABCD رقم الجلسة: 12345678 C->S: إعداد rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSeq: 3 النقل: RTP/AVP؛ أحادي البث؛ منفذ العميل = 8002-8003 رقم الجلسة: 12345678 S->C: RTSP/1.0 200 OK CSeq: 3 النقل: RTP/AVP؛ أحادي البث؛ منفذ العميل = 8002-8003؛ منفذ الخادم = 9002-9003؛ المصدر = 1234ABCD رقم الجلسة: 12345678

يلعب

يؤدي طلب التشغيل إلى تشغيل واحد أو جميع تدفقات الوسائط. ويمكن تجميع طلبات التشغيل بإرسال عدة طلبات تشغيل. قد يكون عنوان URL هو عنوان URL الإجمالي (لتشغيل جميع تدفقات الوسائط)، أو عنوان URL لتدفق وسائط واحد (لتشغيل هذا التدفق فقط). ويمكن تحديد نطاق زمني. إذا لم يتم تحديد نطاق زمني، فسيتم تشغيل التدفق من البداية إلى النهاية، أو إذا كان التدفق متوقفًا مؤقتًا، فسيتم استئنافه من النقطة التي توقف عندها.
C->S: تشغيل rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 النطاق: npt=5-20 رقم الجلسة: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 رقم الجلسة: 12345678 معلومات RTP: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

يوقف

يُوقف طلب الإيقاف المؤقت (PAUSE) مؤقتًا واحدًا أو جميع تدفقات الوسائط، ليتم استئنافها لاحقًا عبر طلب التشغيل (PLAY). يحتوي الطلب على عنوان URL لتدفق الوسائط أو مجموعة منها. يُحدد مُعامل النطاق في طلب الإيقاف المؤقت وقت الإيقاف. عند حذف مُعامل النطاق، يحدث الإيقاف فورًا وإلى أجل غير مسمى.
C->S: إيقاف مؤقت rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 5 رقم الجلسة: 12345678 S->C: RTSP/1.0 200 OK CSeq: 5 رقم الجلسة: 12345678

سِجِلّ

تبدأ هذه الطريقة بتسجيل مجموعة من بيانات الوسائط وفقًا لوصف العرض التقديمي. يعكس الطابع الزمني وقت البدء والانتهاء (بتوقيت UTC). في حال عدم تحديد نطاق زمني، يُستخدم وقت البدء أو الانتهاء المذكور في وصف العرض التقديمي. إذا كانت الجلسة قد بدأت بالفعل، يبدأ التسجيل فورًا. يقرر الخادم ما إذا كان سيخزن البيانات المسجلة تحت عنوان URI الخاص بالطلب أو عنوان URI آخر. إذا لم يستخدم الخادم عنوان URI الخاص بالطلب، فيجب أن تكون الاستجابة 201 وأن ​​تحتوي على كيان يصف حالات الطلب ويشير إلى المورد الجديد، بالإضافة إلى احتوائها على ترويسة الموقع.
C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 6 رقم الجلسة: 12345678 S->C: RTSP/1.0 200 OK CSeq: 6 رقم الجلسة: 12345678

أعلن

تخدم طريقة الإعلان غرضين:

عند إرسال أمر ANNOUNCE من العميل إلى الخادم، فإنه يُرسل وصفًا لعرض تقديمي أو عنصر وسائط مُحدد بواسطة عنوان URL للطلب إلى الخادم. وعند إرساله من الخادم إلى العميل، يُحدّث أمر ANNOUNCE وصف الجلسة في الوقت الفعلي. إذا تمت إضافة دفق وسائط جديد إلى عرض تقديمي (مثلاً، أثناء عرض تقديمي مباشر)، فيجب إعادة إرسال وصف العرض التقديمي بالكامل، وليس فقط المكونات الإضافية، حتى يُمكن حذف المكونات.
 C->S: إعلان rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 7 التاريخ: 23 يناير 1997 الساعة 15:35:06 بتوقيت جرينتش رقم الجلسة: 12345678 نوع المحتوى: تطبيق/sdp طول المحتوى: 332 v=0 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 s=ندوة برنامج التنمية الاجتماعية i= ندوة حول بروتوكول وصف الجلسة ش= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (مارك هاندلي) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 أ = استقبال فقط m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 S->C: RTSP/1.0 200 OK CSeq: 7

هدم

يُستخدم طلب TEARDOWN لإنهاء الجلسة. فهو يوقف جميع تدفقات الوسائط ويحرر جميع البيانات المتعلقة بالجلسة على الخادم.
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 8 رقم الجلسة: 12345678 S->C: RTSP/1.0 200 OK CSeq: 8

الحصول على المعامل

يسترجع طلب GET_PARAMETER قيمة مُعاملٍ لعرضٍ أو بثٍّ مُحددٍ في مُعرّف الموارد الموحد (URI). ويُترك محتوى الرد والاستجابة للتنفيذ. يُمكن استخدام GET_PARAMETER بدون نصٍّ لاختبار جاهزية العميل أو الخادم ("ping").
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 9 نوع المحتوى: نص/معلمات رقم الجلسة: 12345678 طول المحتوى: 15 الحزم المستلمة غضب C->S: RTSP/1.0 200 OK CSeq: 9 طول المحتوى: 46 نوع المحتوى: نص/معلمات عدد الحزم المستلمة: 10 التذبذب: 0.3838

SET_PARAMETER

تطلب هذه الطريقة تعيين قيمة معلمة لعرض تقديمي أو بث محدد بواسطة URI.
C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 10 طول المحتوى: 20 نوع المحتوى: نص/معلمات باربارام: بارستاف S->C: RTSP/1.0 451 مُعامل غير صالح CSeq: 10 طول المحتوى: 10 نوع المحتوى: نص/معلمات باربارام

إعادة توجيه

يُعلم طلب إعادة التوجيه العميل بضرورة الاتصال بموقع خادم آخر. يحتوي هذا الطلب على ترويسة إلزامية تُسمى Location، تُشير إلى وجوب إرسال العميل طلبات لهذا العنوان URL. قد يحتوي أيضًا على مُعامل Range، الذي يُحدد وقت سريان إعادة التوجيه. إذا رغب العميل في الاستمرار بإرسال أو استقبال الوسائط لهذا العنوان URI، فعليه إرسال طلب TEARDOWN للجلسة الحالية وطلب SETUP للجلسة الجديدة على المضيف المُحدد.
S->C: إعادة توجيه rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 11 الموقع: rtsp://bigserver.com:8001 النطاق: الساعة = 19960213T143205Z-

البيانات الثنائية المضمنة (المتداخلة)

قد تُجبر بعض تصميمات جدران الحماية أو ظروف أخرى الخادم على دمج أساليب RTSP وتدفق البيانات. يُنصح عمومًا بتجنب هذا الدمج إلا عند الضرورة، لأنه يُعقّد عمل كلٍ من العميل والخادم ويُضيف عبئًا إضافيًا. لا يُنصح باستخدام البيانات الثنائية المتداخلة إلا إذا تم نقل RTSP عبر TCP.

تُغلّف بيانات البث، مثل حزم بروتوكول النقل في الوقت الحقيقي (RTP)، برمز الدولار ASCII (24 سداسيًا عشريًا)، متبوعًا بمعرّف قناة من بايت واحد، ثم طول البيانات الثنائية المُغلّفة كعدد صحيح ثنائي من بايتين بترتيب بايتات الشبكة. تلي ذلك مباشرةً بيانات البث، بدون سطر جديد (CRLF)، ولكن بما في ذلك رؤوس بروتوكول الطبقة العليا. تحتوي كل كتلة $ على وحدة بيانات واحدة فقط من بروتوكول الطبقة العليا، مثل حزمة RTP واحدة.

C->S: إعداد rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 3 النقل: RTP/AVP/TCP؛ متداخل = 0-1 S->C: RTSP/1.0 200 OK CSeq: 3 التاريخ: 5 يونيو 1997، الساعة 18:57:18 بتوقيت غرينتش النقل: RTP/AVP/TCP؛ متداخل = 0-1 رقم الجلسة: 12345678 C->S: تشغيل rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 رقم الجلسة: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 رقم الجلسة: 12345678 التاريخ: 5 يونيو 1997، الساعة 18:59:15 بتوقيت غرينتش معلومات RTP: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234 S->C: $\000{طول بايتين}{"طول" بايت من البيانات، مع رأس RTP} S->C: $\000{طول بايتين}{"طول" بايت من البيانات، مع رأس RTP} S->C: $\001{طول 2 بايت}{"طول" بايت حزمة RTCP}

بروتوكول RTSP عبر HTTP

تم تعريف بروتوكول RTSP عبر HTTP من قِبل شركة Apple في عام 1999. [ 9 ] يقوم هذا البروتوكول بدمج بيانات الفيديو والصوت الخاصة ببروتوكول RTP في اتصال أوامر RTSP (كما هو مُعرّف في RFC2326)، ثم يرسل اتصال أوامر RTSP عبر اتصالين من نوع HTTP. أحدهما اتصال GET طويل الأمد، والآخر اتصال POST طويل الأمد.

تُستخدم هذه الطريقة أيضًا في معيار كاميرا IP ONVIF ، ويمكن دمجها مع HTTPS للحصول على فيديو وصوت آمنين ومشفرين.

تشفير RTSP وRTSPS

توجد عدة طرق مختلفة لتشفير رسائل أوامر RTSP وبيانات الفيديو والصوت RTP.

يُعرّف بروتوكول RTSP 2.0 (RFC7826) عدة طرق للتشفير ويُقدّم rtsps://عنوان URL جديدًا. وقد تم دمج العديد من هذه الطرق في عملاء وخوادم بروتوكول RTSP 1.0 (RFC2326).

  • عنوان URL لبروتوكول RTSP (باستخدام rtsps://عنوان URL) - تستخدم هذه الطريقة مقبس TLS (المنفذ الافتراضي 322) لإنشاء اتصال مشفر بين عميل RTSP وخادم RTSP. ويمكن بعد ذلك إرسال الفيديو والصوت بإحدى الطريقتين التاليتين:
    • فيديو/صوت TCP - يتم إرسال فيديو وصوت RTP متداخلين مع أوامر RTSP عبر اتصال TLS المشفر بالفعل .
    • UDP و Multicast-UDP Video/Audio - يتم تشفير فيديو RTP والصوت باستخدام بروتوكول Secure RTP (SRTP) وإرساله بالتوازي مع اتصال RTSPS TLS .
  • بروتوكول RTSP عبر HTTPS - تقوم هذه الطريقة بدمج بيانات الفيديو والصوت من بروتوكول RTP في اتصال أوامر RTSP (كما هو محدد في RFC2326)، ثم ترسل اتصال أوامر RTSP عبر زوج من اتصالات HTTPS المشفرة. وتستخدم المنفذ 443 افتراضيًا.

خصصت هيئة IANA بادئة rtsps://عنوان URL والمنفذ 322 لبروتوكول RTSP. [ 10 ] اعتبارًا من سبتمبر 2024، تم تطبيق بروتوكول RTSP عبر HTTPS في العديد من كاميرات IP المتوافقة مع معيار ONVIF، كما rtsps://تم تطبيق بروتوكول RTSP (باستخدام عنوان URL) بواسطة كاميرات المراقبة Axis وBosch، [ 11 ] وبرامج FFmpeg و GStreamer وMediaMTX، [ 12 ] وخادم Ant Media Server ، [ 13 ] وبرنامج SharpRTSP. [ 14 ]

معدل التكيف

يسمح بروتوكول RTSP باستخدام بروتوكولي RTP وRTCP بتنفيذ تعديل معدل البيانات. [ 15 ]

التطبيقات

الخادم

تدعم العديد من كاميرات المراقبة الأمنية، والتي تسمى غالبًا كاميرات IP ، بث RTSP أيضًا، وخاصة تلك التي تحتوي على ملفات تعريف ONVIF G و S و T.

عميل

مراجع

  1. ↑ مجموعة إنفوورلد الإعلامية (2 مارس 1998). إنفوورلد . مجموعة إنفوورلد الإعلامية، ص 18. الرقم الدولي الموحد للدوريات 0199-6649 .  
  2. ↑ رافائيل أوسو (1999). دليل تقنيات الاتصالات الناشئة: العقد القادم . مطبعة سي آر سي. ص 42. ISBN  978-1-4200-4962-6.
  3. ↑ راو، أنوب؛ لانفير، روب. "بروتوكول البث المباشر في الوقت الحقيقي (RTSP)" . متتبع بيانات IETF . تم الاسترجاع في 23 فبراير 2021 .
  4. ↑ هينينغ شولزراين (ديسمبر 1996). "RTSP prime" . جامعة كولومبيا .
  5. ↑ شولزراين، هينينغ ؛ راو، أنوب؛ لانفير، روب (24 فبراير 1997). "بروتوكول البث المباشر في الوقت الحقيقي (RTSP) (draft-ietf-mmusic-rtsp-01.txt)" . متتبع بيانات IETF . تم الاسترجاع في 23 فبراير 2021 .
  6. ↑ شولزراين، هينينغ ؛ راو، أنوب؛ لانفير، روب (15 يناير 1998). "بروتوكول البث المباشر في الوقت الحقيقي (RTSP) (draft-ietf-mmusic-rtsp-08.txt)" . متتبع بيانات IETF . تم الاسترجاع في 23 فبراير 2021 .
  7. 1 2 هـ. شولزراين ؛ أ. راو؛ ر. لانفير (أبريل 1998). بروتوكول البث المباشر في الوقت الحقيقي (RTSP) . مجموعة عمل الشبكة. doi : 10.17487/RFC2326 . RFC 2326 .قديم. تم إلغاؤه بموجب RFC 7826 . 
  8. ↑ هـ. شولزراين ؛ أ. راو؛ ر. لانفير؛ م. ويسترلوند (ديسمبر 2016). م. ستيمرلينغ (محرر). بروتوكول البث المباشر في الوقت الحقيقي، الإصدار 2.0 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7826 . ISSN 2070-1721 . RFC 7826 . المعيار المقترح. يلغي RFC 2326 . 
  9. ↑ "المطور - كويك تايم - رسائل من الجليد الطافي" . 1 مايو 2013. مؤرشف من الأصل في 1 مايو 2013. تم الاطلاع عليه في 22 سبتمبر 2024 .نقل بروتوكولات QuickTime RTSP وRTP عبر HTTP في Wayback Machine (تمت أرشفته في 2024-02-15)
  10. ↑ "سجل اسم الخدمة ورقم منفذ بروتوكول النقل" .
  11. ↑ "بث RTSP الآمن - SRTP/RTSPS" .
  12. ↑ MediaMTX
  13. ↑ مجتمع خادم وسائط Ant
  14. ↑ "Ngraziano/SharpRTSP" . GitHub .
  15. ^ سانتوس، هوغو. كروز، روي سانتوس؛ Nunes، Mário Serafim (2010)، “Rate Adaptation Techniques for WebTV”، وسائط تتمحور حول المستخدم ، ملاحظات محاضرة لمعهد علوم الكمبيوتر والمعلوماتية الاجتماعية وهندسة الاتصالات، المجلد. 40، الصفحات من 161 إلى 168، دوى : 10.1007/978-3-642-12630-7_19 ، ISBN   978-3-642-12629-1
  16. ↑ ant-media/Ant-Media-Server ، Ant Media، 12-12-2024 ، تم الاطلاع عليه بتاريخ 13-12-2024
  17. ↑ "يوتيوب موبايل فاشل! (تشغيل 3GP/RTSP على نظام ويندوز فون 5)" . كريس ديوك . 23 يونيو 2007. تاريخ الاطلاع: 29 مايو 2021 .
  18. ↑ cURL — التغييرات
  19. ↑ "وثائق FFmpeg" . مشروع FFmpeg. 11 سبتمبر 2012. القسم 20.19 . تم الاطلاع عليه بتاريخ 11-09-2012 .
  • "معلومات وتحديثات بروتوكول البث المباشر" . مؤرشف من الأصل بتاريخ 2007-03-06.، وهو مستودع معلومات مركزي حول بروتوكول RTSP.
  • "تمرير بروتوكولات RTSP وRTP عبر HTTP" . مؤرشف من الأصل بتاريخ 2013-05-01.حل قياسي لمساعدة بروتوكول RTSP على العمل عبر جدران الحماية وخوادم البروكسي للويب
  • " تجميع الوسائط المُدارة باستخدام Rtsp و Rtp "، يرشد المطور خلال تنفيذ RtspClient و RtspServer المتوافقين مع المعايير.