بروتوكول التحكم في RTP

بروتوكول التحكم في بروتوكول النقل في الوقت الحقيقي ( RTCP ) هو بروتوكول إشارة ثنائي التشفير خارج النطاق ، يعمل بالتوازي مع بروتوكول النقل في الوقت الحقيقي (RTP). يوفر RTCP إحصائيات ومعلومات تحكم لجلسة RTP. ويتعاون مع RTP في توصيل وتغليف بيانات الوسائط المتعددة، ولكنه لا ينقل أي بيانات وسائط بنفسه.

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

وظائف البروتوكول

عادةً، يتم إرسال بروتوكول RTP عبر منفذ UDP ذي رقم زوجي ، بينما يتم إرسال رسائل RTCP عبر المنفذ ذي الرقم الفردي الأعلى التالي. ^{[ 1 ]}

لا يوفر بروتوكول RTCP نفسه أي طرق لتشفير التدفق أو المصادقة. يمكن تطبيق هذه الآليات، على سبيل المثال، باستخدام بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) ^{[ 2 ].}

يوفر بروتوكول RTCP وظائف أساسية من المتوقع تنفيذها في جميع جلسات RTP:

تتمثل الوظيفة الأساسية لبروتوكول RTCP في جمع إحصائيات حول جوانب جودة توزيع الوسائط أثناء الجلسة، وإرسال هذه البيانات إلى مصدر الوسائط الخاص بالجلسة وإلى المشاركين الآخرين فيها. ويمكن للمصدر استخدام هذه المعلومات لترميز الوسائط التكيفي ( برنامج الترميز ) والكشف عن أعطال الإرسال. وفي حال نقل الجلسة عبر شبكة بث متعدد، فإن ذلك يتيح مراقبة جودة الجلسة دون تدخل.
يُوفّر بروتوكول RTCP مُعرّفات نقاط النهاية الأساسية (CNAME) لجميع المشاركين في الجلسة. على الرغم من أنه من المتوقع أن يكون مُعرّف المصدر (SSRC) لتدفق RTP فريدًا، إلا أن الربط الفوري لمُعرّفات المصدر بنقاط النهاية قد يتغير أثناء الجلسة. يُؤمّن CNAME تعريفًا فريدًا لنقاط النهاية عبر مثيل التطبيق (استخدام أدوات الوسائط المتعددة) ولأغراض المراقبة من قِبل جهات خارجية.
توفير وظائف التحكم في الجلسة. يُعدّ بروتوكول RTCP وسيلةً ملائمةً للوصول إلى جميع المشاركين في الجلسة، بينما لا يُعدّ بروتوكول RTP كذلك. إذ يُنقل بروتوكول RTP فقط عبر مصدر وسائط.

من المتوقع أن يرسل جميع المشاركين تقارير RTCP، حتى في جلسات البث المتعدد التي قد تضم آلاف المستلمين. سيزداد حجم هذه البيانات بشكل متناسب مع عدد المشاركين. لذا، لتجنب ازدحام الشبكة، يجب أن يتضمن البروتوكول إدارة عرض النطاق الترددي للجلسة. ويتحقق ذلك من خلال التحكم الديناميكي في وتيرة إرسال التقارير. يجب ألا يتجاوز استخدام عرض النطاق الترددي لبروتوكول RTCP عمومًا 5% من إجمالي عرض النطاق الترددي للجلسة. علاوة على ذلك، يجب تخصيص 25% من عرض النطاق الترددي لبروتوكول RTCP لمصادر الوسائط في جميع الأوقات، حتى يتمكن المشاركون الجدد في المؤتمرات الكبيرة من تلقي مُعرّفات CNAME الخاصة بالمرسلين دون تأخير مفرط.

يتم تحديد فاصل إرسال تقارير بروتوكول التحكم في الوقت الحقيقي (RTCP) عشوائيًا لمنع التزامن غير المقصود للإبلاغ. الحد الأدنى الموصى به لفاصل إرسال تقارير RTCP لكل محطة هو 5 ثوانٍ. يجب ألا ترسل المحطات تقارير RTCP أكثر من مرة كل 5 ثوانٍ.

رأس الحزمة

رأس حزمة RTCP ^{[ 3 ]}
إزاحة	ثمانية	0								1								2								3
ثمانية	قليل	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	إصدار		P	RC					العلاج الطبيعي								طول
4	32	معرّف SSRC

الإصدار : 2 بت: يُحدد هذا الإصدار من بروتوكول النقل في الوقت الحقيقي (RTP)، وهو نفسه في حزم بروتوكول التحكم في الوقت الحقيقي (RTCP) كما هو الحال في حزم بيانات بروتوكول النقل في الوقت الحقيقي (RTP). الإصدار المحدد في هذه المواصفة هو الإصدار الثاني (2).
الحشو (P) : 1 بت: يشير هذا إلى وجود بايتات حشو إضافية في نهاية حزمة بروتوكول النقل في الوقت الحقيقي (RTP). يُستخدم الحشو لملء كتلة بحجم معين، كما هو مطلوب في خوارزمية التشفير. يحتوي البايت الأخير من الحشو على عدد بايتات الحشو المضافة (بما في ذلك البايت نفسه).
عدد تقارير الاستقبال (RC) : 5 بتات: عدد كتل تقارير الاستقبال الموجودة في هذه الحزمة. القيمة صفر صالحة.
نوع الحزمة (PT) : 8 بتات: يحتوي على ثابت لتحديد نوع حزمة RTCP.
الطول : 16 بت: يشير إلى طول حزمة RTCP هذه (بما في ذلك الرأس نفسه) بوحدات 32 بت ناقص واحد.
معرّف SSRC : 32 بت: يُعرّف مُعرّف مصدر التزامن مصدر البث بشكل فريد.

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

أنواع الرسائل

يميز بروتوكول RTCP عدة أنواع من الحزم: تقرير المرسل ، وتقرير المُستقبِل ، ووصف المصدر ، ورسالة الوداع . إضافةً إلى ذلك، يتميز البروتوكول بقابليته للتوسيع، مما يسمح باستخدام حزم RTCP خاصة بالتطبيقات. ومن بين الامتدادات القياسية لبروتوكول RTCP نوع حزمة التقرير الموسّع . ^{[ 4 ]}

تقرير المرسل (SR): يُرسل تقرير المُرسِل دوريًا من قِبل المُرسِلين النشطين في المؤتمر، وذلك للإبلاغ عن إحصائيات الإرسال والاستقبال لجميع حزم بروتوكول النقل في الوقت الحقيقي (RTP) المُرسلة خلال الفترة الزمنية المحددة. يتضمن تقرير المُرسِل طابعين زمنيين مُختلفين: طابع زمني مُطلق، مُُمثَّل باستخدام تنسيق الطابع الزمني لبروتوكول وقت الشبكة (NTP) (وهو بالثواني نسبةً إلى منتصف ليل التوقيت العالمي المنسق في 1 يناير 1900)، وطابع زمني لبروتوكول النقل في الوقت الحقيقي (RTP) يُطابق وقت طابع NTP الزمني، ولكن بنفس الوحدات وبنفس الإزاحة العشوائية لطوابع RTP الزمنية في حزم البيانات الموصوفة في تقرير المُرسِل هذا. ^{[ 3 ]}^{: 12، 37.} يُتيح الطابع الزمني المُطلق للمُستقبِل مُزامنة رسائل RTP. وهو ذو أهمية خاصة عند إرسال كلٍّ من الصوت والفيديو في وقت واحد، لأن تدفقات الصوت والفيديو تستخدم طوابع زمنية نسبية مُستقلة.
تقرير المُستقبِل (RR): يُعدّ تقرير المُستقبِل خاصًا بالمشاركين السلبيين، أي أولئك الذين لا يرسلون حزم بيانات بروتوكول النقل في الوقت الحقيقي (RTP). ويُعلم هذا التقرير المُرسِل والمُستقبِلين الآخرين بجودة الخدمة.
وصف المصدر (SDES): تُستخدم رسالة وصف المصدر لإرسال عنصر CNAME إلى المشاركين في الجلسة. ويمكن استخدامها أيضًا لتوفير معلومات إضافية مثل اسم مالك المصدر أو المتحكم به، وعنوان بريده الإلكتروني، ورقم هاتفه، وعنوانه.
وداعاً (BYE): يرسل المصدر رسالة "وداعًا" لإيقاف البث. تسمح هذه الرسالة للطرفية بالإعلان عن مغادرتها للمؤتمر. ورغم أن المصادر الأخرى قد تكتشف غياب المصدر، إلا أن هذه الرسالة تُعدّ إعلانًا مباشرًا. كما أنها مفيدة لمُوزّع الوسائط.
رسالة خاصة بالتطبيق (APP): توفر الرسالة الخاصة بالتطبيق آلية لتصميم ملحقات خاصة بالتطبيق لبروتوكول RTCP.

قابلية التوسع في عمليات النشر الكبيرة

في التطبيقات واسعة النطاق، مثل تلفزيون بروتوكول الإنترنت (IPTV)، قد تحدث تأخيرات طويلة جدًا (من دقائق إلى ساعات) بين تقارير بروتوكول التحكم في الوقت الحقيقي (RTCP)، وذلك بسبب آلية التحكم في عرض النطاق الترددي لبروتوكول RTCP اللازمة للتحكم في الازدحام (انظر § وظائف البروتوكول ). عادةً ما تكون الترددات المقبولة أقل من مرة واحدة في الدقيقة. وهذا يُتيح إمكانية الإبلاغ غير الدقيق عن الإحصائيات ذات الصلة من قِبل المُستقبِل، أو يُؤدي إلى تقييم غير دقيق من قِبل مُرسِل الوسائط بالنسبة للحالة الراهنة للجلسة. وقد طُرحت طرق للتخفيف من هذه المشاكل: ^{[ 5 ]} تصفية RTCP، وتحيز RTCP، والتجميع الهرمي . ^{[ 6 ]}

التجميع الهرمي

التجميع الهرمي (أو ما يُعرف أيضًا بتسلسل التغذية الراجعة لبروتوكول RTCP) هو تحسين لنموذج التغذية الراجعة لبروتوكول RTCP، ويهدف إلى زيادة الحد الأقصى لعدد المستخدمين مع قياس جودة الخدمة (QoS). ^{[ 7 ]}^{[ 8 ]} يُعد عرض نطاق RTCP ثابتًا ، ويشغل 5% فقط من عرض نطاق الجلسة. لذلك، تعتمد فترة الإبلاغ عن جودة الخدمة، من بين أمور أخرى، على عدد أعضاء الجلسة، وقد تصبح طويلة جدًا (دقائق أو حتى ساعات) في الجلسات الكبيرة جدًا. ^[³^] مع ذلك، فإن الفترة المقبولة للإبلاغ هي حوالي 10 ثوانٍ. القيم الأكبر من ذلك ستؤدي إلى تأخير زمني وعدم دقة في الإبلاغ عن حالة الجلسة الحالية، وقد يكون لأي تحسين يُجريه المُرسِل تأثير سلبي على الشبكة أو جودة الخدمة.

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

اعتبارًا من يونيو 2007، فقط أنظمة IPTV الأكثر حداثة تستخدم التجميع الهرمي.

هدف التغذية الراجعة

يُعدّ "هدف التغذية الراجعة" نوعًا جديدًا من الأعضاء، وقد طُرح لأول مرة في مسودة الإنترنت draft-ietf-avt-rtcpssm-13. ^{[ 9 ]} وقد وسّعت طريقة التجميع الهرمي وظائفه. تتمثل وظيفة هذا العضو في استقبال تقارير المُستقبِل (RR) (انظر RTCP ) وإعادة إرسال حزم RR المُجمّعة، والتي تُسمى معلومات ملخص المُستقبِل (RSI) ^{[ 9 ]} إلى المُرسِل (في حالة التسلسل الهرمي أحادي المستوى).

وثائق المعايير

RFC 3550 – " RTP: بروتوكول نقل للتطبيقات في الوقت الحقيقي، " معيار الإنترنت 64.

انظر أيضاً

مراجع

↑ سي. هويتيما (أكتوبر 2003). سمة بروتوكول التحكم في الوقت الحقيقي (RTCP) في بروتوكول وصف الجلسة (SDP) . مجموعة عمل الشبكة. doi : 10.17487/RFC3605 . RFC 3605 .المعيار المقترح.
↑ م. باوغر؛ د. مكغرو؛ م. ناسلوند؛ إ. كارارا؛ ك. نورمان (مارس 2004). بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) . مجموعة عمل الشبكة. doi : 10.17487/RFC3711 . RFC 3711 .معلوماتية. تم التحديث بواسطة RFC 9335 و 5506 و 6904 .
1 2 3 هـ. شولزراين؛ س. كاسنر؛ ر. فريدريك؛ ف. جاكوبسون (يوليو 2003). بروتوكول النقل في الوقت الحقيقي: بروتوكول نقل للتطبيقات في الوقت الحقيقي . مجموعة عمل الشبكة. doi : 10.17487/RFC3550 . STD 64. RFC 3550 .معيار الإنترنت 64. تم تحديثه بواسطة RFC 8860 و 7160 و 5761 و 5506 و 6051 و 6222 و 7022 و 7164 و 8083 . يلغي RFC 1889 .
↑ ت. فريدمان؛ ر. كاسيريس؛ أ. كلارك، محرران (نوفمبر 2003). تقارير موسعة لبروتوكول التحكم في الوقت الحقيقي (RTCP XR) . مجموعة عمل الشبكة. doi : 10.17487/RFC3611 . RFC 3611 .المعيار المقترح.
↑ فيت نوفوتني، دان كوموسني، تحسين ردود الفعل على RTCP على نطاق واسع ، مجلة الشبكات، المجلد 3 (3)، مارس 2008
↑ بروتوكول التحكم في الوقت الحقيقي وتحسيناته لتلفزيون بروتوكول الإنترنت
↑ كوموسني د.، نوفوتني ف. بنية شجرية للبث المتعدد ذي المصدر المحدد مع تجميع التغذية الراجعة، في المؤتمر الدولي السادس للشبكات ICN07. مارتينيك، 2007 ISBN 0-7695-2805-8
↑ نوفوتني، ف.، كوموسني، د. تحسين الإبلاغ عن التغذية الراجعة لبروتوكول التحكم في الوقت الحقيقي (RTCP) على نطاق واسع في المؤتمر الدولي للاتصالات اللاسلكية والمتنقلة (ICWMC 2007). المؤتمر الدولي الثالث للاتصالات اللاسلكية والمتنقلة (ICWMC 2007). غوادلوب، 2007. رقم ISBN 0-7695-2796-5
1 2 ج. أوت؛ ج. تشيسترفيلد؛ إ. سكولر (فبراير 2010). امتدادات بروتوكول التحكم في الوقت الحقيقي لجلسات البث المتعدد أحادية المصدر مع التغذية الراجعة أحادية البث . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5760 . RFC 5760 .المعيار المقترح. تم تحديثه بواسطة RFC 6128 .

للمزيد من القراءة

بيركنز، كولين (2003). RTP . أديسون-ويسلي. ص 414. ISBN 978-0-672-32249-5.
بيترسون، لاري ل.؛ بروس س. ديفي (2007). شبكات الحاسوب ( الطبعة الرابعة). مورغان كوفمان. ص 806. ISBN 978-0-12-374013-7.
"RTCP" . دليل بروتوكولات الشبكة . شركة جافين تكنولوجيز. 2005. ISBN 978-0-9740945-2-6.

[rfc3605-1] سي. هويتيما (أكتوبر 2003). سمة بروتوكول التحكم في الوقت الحقيقي (RTCP) في بروتوكول وصف الجلسة (SDP) . مجموعة عمل الشبكة. doi : 10.17487/RFC3605 . RFC 3605 .المعيار المقترح.

[rfc3711-2] م. باوغر؛ د. مكغرو؛ م. ناسلوند؛ إ. كارارا؛ ك. نورمان (مارس 2004). بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) . مجموعة عمل الشبكة. doi : 10.17487/RFC3711 . RFC 3711 .معلوماتية. تم التحديث بواسطة RFC 9335 و 5506 و 6904 .

[rfc3550-3] 1 2 3 هـ. شولزراين؛ س. كاسنر؛ ر. فريدريك؛ ف. جاكوبسون (يوليو 2003). بروتوكول النقل في الوقت الحقيقي: بروتوكول نقل للتطبيقات في الوقت الحقيقي . مجموعة عمل الشبكة. doi : 10.17487/RFC3550 . STD 64. RFC 3550 .معيار الإنترنت 64. تم تحديثه بواسطة RFC 8860 و 7160 و 5761 و 5506 و 6051 و 6222 و 7022 و 7164 و 8083 . يلغي RFC 1889 .

[rfc3611-4] ت. فريدمان؛ ر. كاسيريس؛ أ. كلارك، محرران (نوفمبر 2003). تقارير موسعة لبروتوكول التحكم في الوقت الحقيقي (RTCP XR) . مجموعة عمل الشبكة. doi : 10.17487/RFC3611 . RFC 3611 .المعيار المقترح.

[5] فيت نوفوتني، دان كوموسني، تحسين ردود الفعل على RTCP على نطاق واسع ، مجلة الشبكات، المجلد 3 (3)، مارس 2008

[6] بروتوكول التحكم في الوقت الحقيقي وتحسيناته لتلفزيون بروتوكول الإنترنت

[HA1-7] كوموسني د.، نوفوتني ف. بنية شجرية للبث المتعدد ذي المصدر المحدد مع تجميع التغذية الراجعة، في المؤتمر الدولي السادس للشبكات ICN07. مارتينيك، 2007 ISBN 0-7695-2805-8

[HA2-8] نوفوتني، ف.، كوموسني، د. تحسين الإبلاغ عن التغذية الراجعة لبروتوكول التحكم في الوقت الحقيقي (RTCP) على نطاق واسع في المؤتمر الدولي للاتصالات اللاسلكية والمتنقلة (ICWMC 2007). المؤتمر الدولي الثالث للاتصالات اللاسلكية والمتنقلة (ICWMC 2007). غوادلوب، 2007. رقم ISBN 0-7695-2796-5

[rfc5760-9] 1 2 ج. أوت؛ ج. تشيسترفيلد؛ إ. سكولر (فبراير 2010). امتدادات بروتوكول التحكم في الوقت الحقيقي لجلسات البث المتعدد أحادية المصدر مع التغذية الراجعة أحادية البث . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5760 . RFC 5760 .المعيار المقترح. تم تحديثه بواسطة RFC 6128 .

[ 1 ]

[ 2 ].

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]