پروتکل RTP RTP و RTCP: پروتکل هایی برای تلفن IP

2. مفاهیم اساسی

3. پروتکل انتقال داده RTP

اصول ساخت پروتکل RTP

روش های کنترل کار

فرمت هدر پروتکل RTP

پروتکل رزرو منابع - RSVP

ادبیات

2.1. کنفرانس صوتی گروهی

2.2. کنفرانس ویدیویی

2.3. مفهوم میکسر و مترجم

2.4. ترتیب بایت، تراز، و قالب مهر زمان

3.1. فیلدهای هدر RTP ثابت شد

3.2. جلسات RTP

3.3. تغییرات هدر RTP تعریف شده از نمایه

3.4. پسوند هدر RTP

پروتکل RTP

و چه چیزی اینقدر سخت است؟

به دنبال راه حل مناسب ...

چه چیزی را می توان با فیلدهای یک بسته RTP اندازه گیری کرد؟

چگونه جریان های RTP را شناسایی کنیم؟

چگونه بسته های RTP را از سایر ترافیک ها جدا کنیم؟

در حال حرکت…

نتیجه نهایی سرور چیست؟

مزایا و معایب

خلاصه

رشد سریع اینترنت تقاضاهای جدیدی را در مورد سرعت و حجم انتقال داده ایجاد می کند. و برای برآورده ساختن همه این خواسته ها تنها افزایش ظرفیت شبکه کافی نیست، بلکه به روش های معقول و موثر مدیریت ترافیک و ازدحام خطوط انتقال نیاز است.

در برنامه های بلادرنگ، فرستنده جریانی از داده ها را با نرخ ثابت تولید می کند و گیرنده (یا گیرندگان) باید این داده ها را با همان سرعت در اختیار برنامه قرار دهند. از جمله برنامه های کاربردی می توان به کنفرانس صوتی و تصویری، ویدئوی زنده، تشخیص از راه دور پزشکی، تلفن کامپیوتری، شبیه سازی تعاملی توزیع شده، بازی ها، نظارت بر زمان واقعی و موارد دیگر اشاره کرد.

پرکاربردترین پروتکل لایه انتقال TCP است. اگرچه TCP می تواند طیف گسترده ای از برنامه های کاربردی توزیع شده را پشتیبانی کند، اما برای برنامه های بلادرنگ مناسب نیست.

این کار قرار است با پروتکل جدید حمل و نقل بلادرنگ حل شود - RTP(پروتکل حمل و نقل بلادرنگ)، که تحویل داده ها به یک یا چند مقصد را با تاخیر در محدوده های مشخص تضمین می کند، یعنی داده ها را می توان در زمان واقعی پخش کرد.

RTP از هیچ مکانیزمی برای تحویل بسته، اعتبار انتقال یا قابلیت اطمینان اتصال پشتیبانی نمی کند. همه این توابع به پروتکل حمل و نقل اختصاص داده شده است. RTP در بالای UDP اجرا می شود و می تواند از انتقال بیدرنگ داده بین چندین شرکت کننده در یک جلسه RTP پشتیبانی کند.

توجه داشته باشید

برای هر شرکت کننده RTP، یک جلسه توسط یک جفت آدرس انتقال مقصد بسته تعریف می شود (یک آدرس شبکه- IP و چند پورت: RTP و RTCP).

بسته‌های RTP حاوی فیلدهای زیر هستند: شناسه فرستنده که نشان می‌دهد کدام طرف داده‌ها را تولید می‌کند، مهرهای زمانی زمان تولید بسته به طوری که داده‌ها در فواصل زمانی صحیح توسط طرف گیرنده پخش شوند، اطلاعات مربوط به ترتیب ارسال، و اطلاعات مربوط به ماهیت محتوای بسته، مانند نوع رمزگذاری ویدئو (MPEG، Indeo، و غیره). در دسترس بودن چنین اطلاعاتی تخمین مقدار تاخیر اولیه و اندازه بافر انتقال را ممکن می سازد.

توجه داشته باشید

در یک محیط بلادرنگ معمولی، فرستنده بسته ها را با نرخ ثابت تولید می کند. آنها در فواصل زمانی منظم ارسال می شوند، شبکه را طی می کنند و توسط گیرنده ای دریافت می شوند که داده ها را در زمان دریافت آن ها به صورت بلادرنگ پخش می کند. با این حال، به دلیل تغییر در تاخیر زمانی که بسته ها از طریق شبکه منتقل می شوند، ممکن است در فواصل نامنظم برسند. برای جبران این اثر، بسته های ورودی بافر می شوند، برای مدتی نگه داشته می شوند و سپس با نرخ ثابتی در اختیار نرم افزار تولید کننده خروجی قرار می گیرند. بنابراین، برای عملکرد پروتکل بلادرنگ، لازم است که هر بسته حاوی یک مهر زمانی باشد - بنابراین گیرنده می تواند داده های دریافتی را با همان سرعت فرستنده بازتولید کند.

از آنجایی که RTP قالب محموله داده های ارسالی را تعریف می کند (و تنظیم می کند)، مفهوم همگام سازی مستقیماً با این ارتباط دارد که تا حدی مسئولیت مکانیسم ترجمه RTP - میکسر است. پس از دریافت جریان بسته های RTP از یک یا چند منبع، میکسر آنها را ترکیب کرده و جریان جدیدی از بسته های RTP را برای یک یا چند گیرنده ارسال می کند. میکسر به سادگی می تواند داده ها را ترکیب کند، و همچنین فرمت آن را تغییر دهد، به عنوان مثال، هنگام ترکیب چندین منبع صدا. بیایید وانمود کنیم که سیستم جدیدمی‌خواهد در جلسه شرکت کند، اما پیوند آن به شبکه ظرفیت کافی برای پشتیبانی از تمام جریان‌های RTP را ندارد، سپس میکسر تمام این جریان‌ها را دریافت می‌کند، آنها را در یکی ادغام می‌کند و آخرین مورد را به عضو جلسه جدید ارسال می‌کند. هنگام دریافت چندین جریان، میکسر به سادگی مقادیر PCM را اضافه می کند. هدر RTP تولید شده توسط میکسر شامل هویت فرستنده ای است که داده هایش در بسته موجود است.

یک دستگاه رله ساده تر یک بسته RTP خروجی برای هر بسته RTP ورودی ایجاد می کند. این مکانیسم ممکن است فرمت داده ها را در بسته تغییر دهد یا از مجموعه متفاوتی از پروتکل های سطح پایین برای انتقال داده ها از یک دامنه به دامنه دیگر استفاده کند. به عنوان مثال، یک گیرنده بالقوه ممکن است نتواند سیگنال ویدیویی پرسرعت مورد استفاده سایر شرکت کنندگان در جلسه را پردازش کند. مترجم ویدیو را بیشتر به فرمت تبدیل می کند کیفیت پایین، به سرعت داده نه چندان بالایی نیاز دارد.

پروتکل RTP فقط برای انتقال داده های کاربر - معمولا چندپخشی - به همه شرکت کنندگان در جلسه استفاده می شود. همراه با RTP، پروتکل RTCP (پروتکل کنترل حمل و نقل در زمان واقعی) کار می کند که وظیفه اصلی آن ارائه کنترل بر انتقال RTP است. RTCP از همان پروتکل انتقال اولیه مانند RTP (معمولا UDP) استفاده می کند، اما از شماره پورت متفاوتی استفاده می کند.

RTCP چندین عملکرد را انجام می دهد:

اطمینان و نظارت بر کیفیت خدمات و بازخورد در صورت ازدحام. از آنجایی که بسته‌های RTCP چندپخشی هستند، همه شرکت‌کنندگان در جلسه می‌توانند میزان عملکرد و دریافت سایر شرکت‌کنندگان را ارزیابی کنند. پیام های فرستنده به گیرندگان اجازه می دهد تا نرخ داده و کیفیت انتقال را ارزیابی کنند. پیام های گیرندگان حاوی اطلاعاتی در مورد مشکلاتی است که آنها با آن مواجه می شوند، از جمله از دست دادن بسته و ریپل بیش از حد. بازخورد گیرنده نیز برای تشخیص خطاهای انتشار مهم است. با تجزیه و تحلیل پیام های همه شرکت کنندگان در جلسه، مدیر شبکه می تواند تعیین کند که آیا مشکل مربوط به یک شرکت کننده است یا ماهیت کلی دارد. اگر برنامه ارسال به این نتیجه برسد که مشکل برای کل سیستم معمول است، به عنوان مثال، به دلیل خرابی یکی از کانال های ارتباطی، می تواند درجه فشرده سازی داده ها را به دلیل کاهش کیفیت یا افزایش دهد. به طور کلی از انتقال ویدیو خودداری کنید - این به شما امکان می دهد داده ها را با ظرفیت کم اتصال منتقل کنید.
شناسایی فرستنده بسته های RTCP حاوی یک توصیف متنی استاندارد از فرستنده هستند. آنها اطلاعات بیشتری در مورد فرستنده بسته های داده نسبت به شناسه منبع همگام سازی تصادفی انتخاب شده ارائه می دهند. علاوه بر این، آنها به کاربر کمک می کنند تا موضوعات مربوط به جلسات مختلف را شناسایی کند.
اندازه و مقیاس بندی جلسه. برای اطمینان از کیفیت خدمات و بازخورد برای کنترل ازدحام، و همچنین شناسایی فرستنده، همه شرکت کنندگان به طور دوره ای بسته های RTCP را ارسال می کنند. فرکانس ارسال این بسته ها با افزایش تعداد شرکت کنندگان کاهش می یابد. با تعداد کمی از شرکت کنندگان، حداکثر هر 5 ثانیه یک بسته RTCP ارسال می شود. RFC-1889 الگوریتمی را توصیف می کند که براساس آن شرکت کنندگان نرخ بسته های RTCP را بسته به تعداد کلشركت كنندگان. هدف این است که ترافیک RTCP کمتر از 5٪ از کل ترافیک جلسه باشد.

RTP یک پروتکل جریان گرا است. سربرگ بسته RTP با در نظر گرفتن نیازهای انتقال بلادرنگ طراحی شده است. این شامل اطلاعاتی در مورد ترتیب بسته ها به طوری که جریان داده به درستی در انتهای گیرنده مونتاژ شود، و یک مهر زمانی برای درهم آمیختگی صحیح فریم در حین پخش و برای همگام سازی جریان های داده های متعدد، مانند ویدئو و صدا.

هر بسته RTP دارای یک هدر اصلی و احتمالاً فیلدهای اضافی ویژه برنامه است.

استفاده از TCP به عنوان پروتکل حمل و نقل برای این برنامه ها به چند دلیل امکان پذیر نیست:

این پروتکل فقط امکان برقراری ارتباط بین دو نقطه پایانی را فراهم می کند و بنابراین برای چند کستینگ مناسب نیست.
TCP امکان ارسال مجدد بخش‌های از دست رفته را فراهم می‌کند که زمانی می‌رسند که برنامه بلادرنگ دیگر منتظر آنها نیست.
TCP مکانیسم مناسبی برای مرتبط کردن اطلاعات زمان بندی با بخش ها ندارد که یک نیاز اضافی برای برنامه های بلادرنگ است.

یکی دیگر از پروتکل های لایه انتقال که به طور گسترده مورد استفاده قرار می گیرد، LJDP برخی از محدودیت های TCP را ندارد، اما اطلاعات زمان بندی حیاتی را نیز ارائه نمی دهد.

در حالی که هر برنامه بلادرنگ ممکن است مکانیسم های خاص خود را برای پشتیبانی از انتقال بلادرنگ داشته باشد، اما آنها ویژگی های مشترک بسیاری دارند که تعریف یک پروتکل واحد را بسیار مطلوب می کند.

این کار قرار است با یک پروتکل جدید حمل و نقل بلادرنگ حل شود - RTP (پروتکل حمل و نقل بلادرنگ)، که تحویل داده ها به یک یا چند گیرنده را با تاخیر در محدوده های مشخص تضمین می کند، یعنی داده ها را می توان در بازتولید کرد. به موقع.

روی انجیر 1 یک هدر RTP ثابت را نشان می دهد که حاوی تعدادی فیلد است که عناصری مانند قالب بسته، شماره ترتیب، منابع، مرزها و نوع بار را شناسایی می کند. هدر ثابت ممکن است با فیلدهای دیگری حاوی اطلاعات اضافی در مورد داده ها دنبال شود.

برنج. 1. هدر RTP ثابت.

V(2 بیت). فیلد نسخه نسخه فعلی نسخه دوم است.
آر(1 بیت). فیلد را پر کنید این فیلد وجود اکتت های بالشتکی را در انتهای محموله سیگنال می دهد. Padding زمانی اعمال می شود که یک برنامه نیاز دارد که اندازه بار بار مضرب مثلاً 32 بیت باشد. در این حالت آخرین اکتت تعداد اکتت های padding را نشان می دهد.
ایکس(1 بیت). فیلد پسوند هدر. هنگامی که این فیلد تنظیم می شود، سرصفحه اصلی توسط یک هدر اضافی که در پسوندهای RTP آزمایشی استفاده می شود، دنبال می شود.
اس اس(4 بیت). فیلد تعداد فرستنده. این فیلد شامل تعداد شناسه فرستنده هایی است که داده های آنها در بسته وجود دارد و خود شناسه ها از هدر اصلی پیروی می کنند.
م(1 بیت). فیلد نشانگر. معنای بیت نشانگر به نوع بار بستگی دارد. بیت نشانگر معمولاً برای نشان دادن مرزهای جریان داده استفاده می شود. در مورد ویدیو، انتهای فریم را تنظیم می کند. در مورد صدا، شروع گفتار را پس از مدتی سکوت مشخص می کند.
RT(7 بیت). فیلد نوع بار. این فیلد نوع محموله و فرمت داده، از جمله فشرده سازی و رمزگذاری را مشخص می کند. در حالت ساکن، فرستنده تنها از یک نوع بار در هر جلسه استفاده می کند، اما در صورت سیگنال دهی توسط پروتکل کنترل حمل و نقل بلادرنگ، می تواند آن را در پاسخ به شرایط تغییر تغییر دهد.
شماره ترتیب(16 بیت). فیلد شماره دنباله. هر منبع شروع به شماره گذاری بسته ها از یک عدد دلخواه می کند، سپس با ارسال هر بسته داده RTP یک عدد افزایش می یابد. این به شما امکان می دهد تا از دست رفتن بسته ها را شناسایی کنید و ترتیب بسته ها را با همان زمان مشخص کنید. اگر به طور منطقی در یک لحظه تولید شوند، ممکن است چندین بسته متوالی دارای مهر زمانی یکسانی باشند، مانند بسته‌هایی که متعلق به یک فریم ویدیویی هستند.
مهر زمان(32 بیت). فیلد مهر زمان. این فیلد حاوی نقطه زمانی است که در آن اولین اکتت داده محموله ایجاد شده است. واحدهایی که در آن زمان در این قسمت مشخص شده است به نوع محموله بستگی دارد. مقدار توسط ساعت محلی فرستنده تعیین می شود.
منبع همگام سازی شناسه (SSRC).(32 بیت). فیلد شناسه منبع همگام سازی: شماره ای که به طور تصادفی تولید می شود که به طور منحصر به فرد منبع را در یک جلسه شناسایی می کند و مستقل از آدرس شبکه است. این عدد نقش مهمی در پردازش بخش ورودی داده از یک منبع دارد.
شناسه منبع کمک کننده (CSRC).(32 بیت). فهرستی از فیلدهای شناسه منبع "مخلوط" در جریان اصلی، به عنوان مثال، با استفاده از میکسر. مخلوط‌کننده فهرست کاملی از شناسه‌های SSRC منابعی را که در ساخت این بسته RTP شرکت کرده‌اند درج می‌کند. این لیست CSRC نام دارد. تعداد عناصر موجود در لیست: از 0 تا 15. اگر تعداد شرکت کنندگان بیش از 15 نفر باشد، 15 نفر اول انتخاب می شوند. به عنوان مثال یک کنفرانس صوتی، در بسته های RTP که سخنرانی های همه شرکت کنندگان جمع آوری شده است، هر کدام با SSRC خود را - آنها لیست CSRC را تشکیل می دهند. در این مورد، کل کنفرانس دارای یک SSRC مشترک است.

پروتکل RTCP، مانند هر پروتکل کنترلی، هم از نظر ساختار و هم از نظر عملکردهایی که انجام می دهد بسیار پیچیده تر است (مثلاً پروتکل های IP و TCP را مقایسه کنید). اگرچه هسته پروتکل RTCP RTP است، اما حاوی بسیاری از فیلدهای اضافی است که با آنها توابع خود را پیاده سازی می کند.

برای حل مشکل اولویت داده‌های حساس به تاخیر، برخلاف داده‌های سنتی که تاخیر برای آن‌ها چندان حیاتی نیست، از پروتکل رزرو منابع - RSVP که در حال حاضر توسط گروه ویژه مهندسی اینترنت (IETF) در دست بررسی است، استفاده می‌شود. . RSVP به سیستم‌های نهایی اجازه می‌دهد تا منابع شبکه را برای به دست آوردن کیفیت خدمات مورد نیاز، به ویژه منابع برای ترافیک بلادرنگ روی پروتکل RTP، رزرو کنند. RSVP در درجه اول به روترها مربوط می شود، اگرچه برنامه های کاربردی گره انتهایی نیز باید بدانند که چگونه از RSVP استفاده کنند تا پهنای باند مورد نیاز را برای یک کلاس سرویس یا سطح اولویت خاص رزرو کنند.

RTP، همراه با استانداردهای دیگر توضیح داده شده، امکان انتقال موفقیت آمیز تصویر و صدا را از طریق شبکه های IP معمولی فراهم می کند. RTP/RTCP/RSVP یک راه حل استاندارد شده برای شبکه های داده بلادرنگ است. تنها عیب آن این است که فقط برای شبکه های IP است. با این حال، این محدودیت موقتی است: شبکه ها در این جهت یا به طریق دیگری توسعه خواهند یافت. این راه حل نوید حل مشکل انتقال داده های حساس به تاخیر از طریق اینترنت را می دهد.

شرح پروتکل RTPرا می توان در RFC-1889 یافت.

عصر بخیر!

به طور خلاصه: سیستم مانیتورینگ مجموعه ای است که در حالت غیر نفوذی به شماره n ام لینک های اترنت 10 گیگابیتی متصل می شود که به طور مداوم انتقال تمام جریان های ویدئویی RTP موجود در ترافیک را "نظارت" می کند و اندازه گیری می کند. در یک بازه زمانی معین به منظور ذخیره آنها بعدا در پایگاه. با توجه به داده های پایگاه داده، گزارش ها به طور منظم برای همه دوربین ها ساخته می شوند.

در روند یافتن راه حل، چندین مشکل بلافاصله برطرف شد:

اتصال غیر نفوذی سیستم مانیتورینگ به کانال‌هایی که از قبل کار می‌کنند متصل می‌شود، که در آن بیشتر اتصالات (از طریق RTSP) قبلاً برقرار شده‌اند، سرور و مشتری از قبل می‌دانند که تبادل در کدام پورت انجام می‌شود، اما ما از قبل این را نمی‌دانیم. یک پورت شناخته شده فقط برای پروتکل RTSP وجود دارد، اما جریان های UDP می توانند از طریق پورت های دلخواه عبور کنند (علاوه بر این، مشخص شد که آنها اغلب الزامات پورت SHOULD/فرد را نقض می کنند، به rfc3550 مراجعه کنید). چگونه تشخیص دهیم که این یا آن بسته از برخی از آدرس های IP متعلق به یک جریان ویدیویی است؟ به عنوان مثال، پروتکل BitTorrent به طور مشابه رفتار می کند - در مرحله برقراری یک اتصال، مشتری و سرور در مورد پورت ها توافق می کنند، و سپس تمام ترافیک UDP به نظر می رسد "فقط یک جریان کمی".
پیوندهای متصل می توانند بیشتر از جریان های ویدئویی باشند. می‌توان HTTP، BitTorrent، و SSH و هر پروتکل دیگری که امروزه استفاده می‌کنیم وجود داشته باشد. بنابراین، سیستم باید جریان های ویدئویی را به درستی شناسایی کند تا آنها را از بقیه ترافیک جدا کند. چگونه با 8 لینک ده گیگابیتی این کار را در زمان واقعی انجام دهیم؟ البته معمولاً 100٪ پر نمی شوند ، بنابراین کل ترافیک 80 گیگابیت در ثانیه نیست ، بلکه حدود 50-60 خواهد بود ، اما این خیلی کم نیست.
مقیاس پذیری. در جاهایی که در حال حاضر جریان های ویدیویی زیادی وجود دارد، ممکن است تعداد بیشتری از آنها وجود داشته باشد، زیرا نظارت تصویری مدت هاست که خود را به عنوان یک ابزار مؤثر ثابت کرده است. این نشان می دهد که باید حاشیه ای برای عملکرد و ذخیره ای برای پیوندها وجود داشته باشد.

طبیعتا سعی کردیم از آن نهایت استفاده را ببریم تجربه خود. زمانی که تصمیم گرفته شد، ما قبلاً پردازش بسته های اترنت را در دستگاه مبتنی بر FPGA Bercut-MX (به طور ساده تر - MX) داشتیم. با کمک Bercut-MX توانستیم فیلدهای لازم برای تحلیل را از سربرگ بسته های اترنت بدست آوریم. ما هیچ تجربه ای در پردازش چنین حجمی از ترافیک با استفاده از سرورهای "معمولی" نداشتیم، بنابراین، متأسفانه راه حل مشابهبا کمی دلهره نگاه کرد...

به نظر می رسد که تنها اعمال روش بر روی بسته های RTP باقی مانده است و کلید طلایی را در جیب خود خواهیم داشت، اما MX فقط می تواند ترافیک را پردازش کند، توانایی ثبت و ذخیره آمار را شامل نمی شود. حافظه کافی در FPGA برای ذخیره اتصالات یافت شده (ترکیبات IP-IP-port-port) وجود ندارد، زیرا در یک لینک 2x10 گیگابیتی که وارد ورودی می شود، می تواند حدود 15 هزار جریان ویدیویی وجود داشته باشد و برای هر یک باید " به خاطر داشته باشید” تعداد بسته های دریافتی، تعداد بسته های گم شده و غیره... علاوه بر این، جستجو با چنین سرعتی و برای چنین حجمی از داده ها، مشروط به پردازش بدون تلفات، به یک کار غیر ضروری تبدیل می شود.

برای یافتن راه‌حل، مجبور شدیم «عمیق‌تر» کنیم و بفهمیم که از چه الگوریتم‌هایی برای اندازه‌گیری کیفیت و شناسایی جریان‌های ویدیویی استفاده خواهیم کرد.

از توضیحات می توان دریافت که از نقطه نظر اندازه گیری کیفیت در بسته RTP، ما به زمینه های زیر علاقه مند هستیم:

شماره دنباله - شمارنده 16 بیتی که با ارسال هر بسته افزایش می یابد.
برچسب زمانی - مهر زمانی، برای h.264 اندازه نمونه 1/90000 ثانیه است (یعنی مربوط به فرکانس 90 کیلوهرتز است).
بیت نشانگر در rfc3550، به طور کلی توضیح داده شده است که این بیت برای تعیین رویدادهای "مهم" در نظر گرفته شده است، و در واقع دوربین ها اغلب شروع یک فریم ویدئو و بسته های تخصصی با اطلاعات SPS / PPS را با این بیت نشان می دهند.

کاملاً واضح است که شماره دنباله به شما امکان می دهد پارامترهای جریان زیر را تعریف کنید:

از دست دادن بسته (از دست دادن فریم)؛
ارسال مجدد بسته (کپی)؛
تغییر ترتیب ورود (سفارش مجدد)؛
بارگذاری مجدد دوربین، با یک "شکاف" بزرگ در دنباله.

مهر زمان به شما امکان می دهد اندازه گیری کنید:

تغییرات تاخیری (همچنین جیتر نامیده می شود). در این مورد، یک شمارنده 90 کیلوهرتز باید در سمت گیرنده کار کند.
در اصل، تاخیر در عبور بسته. اما برای این کار باید زمان دوربین را با مهر زمان همگام کنید و این در صورتی امکان پذیر است که دوربین گزارش های فرستنده (RTCP SR) را ارسال کند که معمولاً درست نیست، زیرا در زندگی واقعی، بسیاری از دوربین‌ها پیام RTCP SR را نادیده می‌گیرند (حدود نیمی از دوربین‌هایی که ما فرصت کار با آنها را داشتیم).

خوب، M-bit به شما امکان می دهد نرخ فریم را اندازه گیری کنید. درست است، فریم های SPS/PPS پروتکل h.264 یک خطا ایجاد می کند، زیرا فریم های ویدئویی نیستند اما می توان آن را با استفاده از اطلاعات هدر NAL-unit که همیشه از هدر RTP پیروی می کند، تراز کرد.

الگوریتم های دقیق برای اندازه گیری پارامترها خارج از محدوده مقاله است، من به آن نمی پردازم. در صورت علاقه، rfc3550 یک نمونه کد محاسبه ضرر و فرمولی برای محاسبه جیتر دارد. نتیجه گیری اصلی این است که تنها چند فیلد از بسته های RTP و واحدهای NAL برای اندازه گیری ویژگی های اساسی یک جریان انتقال کافی است. و بقیه اطلاعات در اندازه گیری ها دخالتی ندارد و می توان و باید دور انداخت!

برای حفظ آمار، اطلاعات به‌دست‌آمده از هدر RTP باید به یک شناسه دوربین خاص (جریان ویدیویی) "ضمیمه" شود. دوربین را می توان به طور منحصر به فرد با پارامترهای زیر شناسایی کرد:

آدرس IP منبع و مقصد
پورت های منبع و مقصد
SSRC هنگامی که چندین جریان از یک IP پخش می شود، از اهمیت ویژه ای برخوردار است. در مورد رمزگذار چند پورت.

جالب اینجاست که در ابتدا شناسایی دوربین را فقط با IP منبع و SSRC انجام می‌دادیم، با تکیه بر این واقعیت که SSRC باید تصادفی باشد، اما در عمل مشخص شد که بسیاری از دوربین‌ها SSRC را روی یک مقدار ثابت تنظیم می‌کنند (مثلاً 256). ظاهراً این به دلیل صرفه جویی در منابع است. در نتیجه مجبور شدیم پورت هایی را به شناسه دوربین اضافه کنیم. این مشکل منحصر به فرد بودن را به طور کامل حل کرد.

سوال باقی می ماند: چگونه Berkut-MX با پذیرش بسته، متوجه می شود که RTP است؟ هدر RTP دارای شناسایی صریح مانند IP نیست، دارای چک جمع نیست، می توان آن را از طریق UDP با شماره پورت هایی که هنگام برقراری اتصال به صورت پویا انتخاب می شوند، منتقل کرد. و در مورد ما، بیشتر اتصالات مدتهاست برقرار شده اند و می توانید مدت زیادی برای نصب مجدد صبر کنید.

برای حل این مشکل، در rfc3550 (پیوست A.1) توصیه می شود بیت های نسخه RTP را بررسی کنید - این دو بیت است و فیلد Payload Type (PT) - هفت بیت، که در مورد نوع پویا یک مقدار طول می کشد. محدوده کوچک ما در عمل متوجه شده ایم که برای مجموعه دوربین هایی که با آنها کار می کنیم، PT در محدوده 96 تا 100 قرار می گیرد.

یک عامل دیگر وجود دارد - برابری بندر، اما همانطور که تمرین نشان داده است، همیشه رعایت نمی شود، بنابراین باید رها می شد.

بنابراین، رفتار Berkut-MX به شرح زیر است:

ما یک بسته دریافت می کنیم، آن را در فیلدها جدا می کنیم.
اگر نسخه 2 باشد و نوع payload در محدوده داده شده باشد، هدرها را به سرور ارسال می کنیم.

بدیهی است که با این رویکرد، نکات مثبت کاذب وجود دارد، زیرا. نه تنها بسته های RTP می توانند تحت چنین معیارهای ساده ای قرار گیرند. اما برای ما مهم است که بسته RTP را از دست ندهیم و سرور بسته های "اشتباه" را فیلتر می کند.

برای فیلتر موارد نادرست، سرور از مکانیزمی استفاده می کند که منبع ترافیک ویدیو را برای چندین بسته دریافتی متوالی ثبت می کند (یک شماره دنباله در بسته وجود دارد!). اگر چندین بسته با اعداد متوالی آمدند، پس این تصادفی نیست و ما شروع به کار با این جریان می کنیم. ثابت شد که این الگوریتم بسیار قابل اعتماد است.

با درک اینکه تمام اطلاعاتی که در بسته‌ها برای اندازه‌گیری کیفیت و شناسایی جریان‌ها نیازی نیست، تصمیم گرفتیم تمام کارهای پربار و حساس در زمان دریافت و جداسازی فیلدهای بسته‌های RTP را به Berkut-MX منتقل کنیم. FPGA. جریان ویدئو را "پیدا می کند"، بسته را تجزیه می کند، فقط فیلدهای مورد نیاز را باقی می گذارد و آن را به یک سرور معمولی در تونل UDP ارسال می کند. سرور برای هر دوربین اندازه گیری می کند و نتایج را در پایگاه داده ذخیره می کند.

در نتیجه، سرور با 50-60 گیگابیت بر ثانیه کار نمی کند، بلکه با حداکثر 5٪ کار می کند (این دقیقاً نسبت داده های ارسال شده به اندازه متوسط بسته است). یعنی در ورودی کل سیستم 55 گیگابیت بر ثانیه و فقط بیش از 3 گیگابیت بر ثانیه به سرور نمی رسد!

در نتیجه، معماری زیر را دریافت کردیم:

و ما اولین نتیجه را در این پیکربندی دو هفته پس از تنظیم TOR اولیه دریافت کردیم!

بنابراین سرور در معماری ما چه می کند؟ وظایف او:

به یک سوکت UDP گوش دهید و فیلدهایی را با هدرهای بسته بندی شده از آن بخوانید.
بسته های دریافتی را تجزیه کنید و فیلدهای هدر RTP را به همراه شناسه های دوربین از آنجا استخراج کنید.
فیلدهای دریافتی را با فیلدهایی که قبلاً دریافت شده اند مرتبط کنید و بفهمید که آیا بسته ها گم شده اند یا خیر، آیا بسته ها به طور مکرر ارسال شده اند یا خیر، آیا ترتیب رسیدن تغییر کرده است، تفاوت در تأخیر حمل و نقل بسته (جیتر) چقدر بوده است، و غیره.
ثبت داده های اندازه گیری شده در پایگاه داده با توجه به زمان؛
تجزیه و تحلیل پایگاه و تولید گزارش، ارسال تله در مورد رویدادهای مهم (از دست دادن بسته های زیاد، از دست دادن بسته ها از برخی دوربین ها و غیره).

علیرغم این واقعیت که کل ترافیک ورودی سرور حدود 3 گیگابیت بر ثانیه است، سرور حتی اگر از هیچ DPDK استفاده نکنیم کار می کند، اما به سادگی از طریق یک سوکت لینوکس کار می کند (البته پس از افزایش اندازه بافر برای سوکت) . علاوه بر این، امکان اتصال پیوندهای جدید و MX "ها وجود خواهد داشت، زیرا حاشیه عملکرد باقی می ماند.

این همان چیزی است که بالای سرور به نظر می رسد (این بالای یک ظرف lxc است، گزارش ها در دیگری تولید می شوند):

از آن می توان دریافت که کل بار برای محاسبه پارامترهای کیفیت و حسابداری آمار به طور مساوی در چهار فرآیند توزیع شده است. ما با استفاده از هش در FPGA موفق به دستیابی به چنین توزیعی شدیم: تابع هش توسط IP محاسبه می شود و بیت های کم هش دریافتی تعداد پورت UDP را تعیین می کند که آمار به آن می رود. بر این اساس، هر فرآیندی که در پورت خود گوش می دهد تقریباً همان میزان ترافیک را دریافت می کند.

وقت آن است که لاف بزنیم و کاستی های راه حل را بپذیریم.

من با جوانب مثبت شروع می کنم:

بدون ضرر در محل اتصال با لینک های 10G. از آنجایی که FPGA تمام "ضربه" را می گیرد، می توانیم مطمئن باشیم که هر بسته تجزیه و تحلیل خواهد شد.
برای نظارت بر 55000 دوربین (یا بیشتر)، تنها یک سرور با یک کارت 10G مورد نیاز است. ما در حال حاضر از سرورهای مبتنی بر 2x Xeon با 4 هسته 2400 مگاهرتز استفاده می کنیم. به اندازه کافی با حاشیه: به موازات جمع آوری اطلاعات، گزارش ها تولید می شود.
نظارت بر 8 "دوجین" (پیوندهای 10G) فقط در 2-3 واحد قرار می گیرد: همیشه فضای و قدرت زیادی در قفسه برای سیستم نظارت وجود ندارد.
هنگام اتصال پیوندها از MX ها از طریق سوئیچ، می توانید پیوندهای جدید را بدون توقف نظارت اضافه کنید، زیرا شما نیازی به قرار دادن هیچ تابلویی در سرور ندارید و برای این کار نیازی به خاموش کردن آن ندارید.
سرور با داده ها بارگیری نمی شود، فقط آنچه را که لازم است دریافت می کند.
هدرهای MX در یک بسته اترنت جامبو می آیند، به این معنی که پردازنده با وقفه خفه نمی شود (علاوه بر این، ما ادغام وقفه را فراموش نمی کنیم).

انصافاً من معایب را در نظر خواهم گرفت:

به دلیل بهینه سازی سنگین وظیفه خاصافزودن پشتیبانی برای فیلدها یا پروتکل های جدید نیاز به تغییر در کد FPGA دارد. این منجر به زمان بیشتری نسبت به زمانی می شود که ما همین کار را روی پردازنده انجام دهیم. هم در توسعه و آزمایش و هم در حین استقرار.
اطلاعات ویدئویی اصلا تحلیل نمی شود. دوربین می تواند از یک یخ که در جلوی آن آویزان است عکس بگیرد یا به سمت اشتباه چرخانده شود. این واقعیت مورد توجه قرار نخواهد گرفت. البته ما قابلیت فیلم برداری از دوربین انتخابی را فراهم کرده ایم اما اپراتور نمی تواند از تمام 55000 دوربین عبور کند!
یک سرور و دستگاه های مجهز به FPGA گران تر از یک یا دو سرور هستند؛)

در پایان، ما یک مجموعه نرم‌افزاری و سخت‌افزاری به دست آوردیم که در آن می‌توانیم هم قسمتی را که بسته‌ها را روی رابط‌ها تجزیه می‌کند و هم بخشی را که آمار را نگه می‌دارد، کنترل کنیم. کنترل کامل بر روی تمام گره‌های سیستم به معنای واقعی کلمه ما را نجات داد زمانی که دوربین‌ها شروع به تغییر حالت RTSP/TCP کردند. زیرا در این مورد، هدر RTP دیگر در بسته با یک افست ثابت قرار ندارد: می تواند در هر جایی باشد، حتی در مرز دو بسته (نیمه اول در یکی، دومی در دیگری). بر این اساس الگوریتم به دست آوردن هدر RTP و فیلدهای آن دستخوش تغییرات اساسی شده است. ما مجبور شدیم برای تمام 50000 اتصال، دوباره TCP را روی سرور انجام دهیم - از این رو بار نسبتاً بالایی در بالا وجود دارد.

ما قبلاً هرگز در زمینه برنامه های کاربردی پر بار کار نکرده ایم، اما به دلیل مهارت های خود در FPGA موفق به حل این مشکل شدیم و بسیار خوب بود. حتی یک حاشیه وجود داشت - به عنوان مثال، 20-30 هزار جریان دیگر را می توان به سیستمی با 55000 دوربین متصل کرد.

تنظیم زیرسیستم های لینوکس (توزیع صف ها توسط وقفه ها، افزایش بافرهای دریافت، تخصیص مستقیم هسته ها به فرآیندهای خاص و غیره) من را خارج از محدوده مقاله رها کردم، زیرا. این موضوع در حال حاضر به خوبی پوشش داده شده است.

من به دور از همه چیز توضیح داده ام ، تعداد زیادی چنگک جمع آوری شده است ، بنابراین در صورت تمایل سؤال بپرسید :)

با تشکر فراوان از همه کسانی که تا آخر خواندند!

RTSP(پروتکل Real Time Streaming Protocol یا به زبان روسی پروتکل جریان بیدرنگ) یک پروتکل کاربردی است که دستوراتی را برای کنترل یک جریان ویدیویی توصیف می کند. با این دستورات، می‌توانیم به دوربین یا سرور، مثلاً شروع به پخش یک جریان ویدیویی، «سفارش» کنیم. نمونه ای از درخواست برای شروع پخش به این صورت است: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

یعنی RTSP فقط مجموعه ای از دستورات برای کنترل جریان ویدئو است. بیایید یک آزمایش انجام دهیم. برای این کار به یک دوربین IP نیاز داریم که از پروتکل RTSP و آدرس RTSP آن پشتیبانی کند. این آدرس چیزی شبیه به این rtsp:///mpeg است. می توان آن را در دفترچه راهنمای دوربین یا در توضیحات API یافت. برای راحتی، ما آدرس های RTSP را برای تعدادی از دوربین های محبوب در جدول لیست می کنیم. پس از دانستن آدرس RTSP دوربین، پخش کننده استانداردی را باز می کنیم که از RTSP پشتیبانی می کند. میتونه یکی از برنامه های زیر: Windows Media Player، QuickTime، Media Player Classic، رسانه VLCپخش کننده، RealPlayer، MPlayer. ما QuickTime را انتخاب کردیم. منوی "File > Open URL" را باز کنید و آدرس RTSP ما را وارد کنید. پس از آن، QuickTime به دوربین متصل می شود و "ویدیو زنده" را پخش می کند. دستگاه‌های ضبطی که در سیستم‌های نظارت تصویری IP کار می‌کنند ویدیو را از دوربین‌ها یا با استفاده از پروتکل HTTP دریافت می‌کنند - یعنی به همان روشی که تصاویر JPEG را از وب‌سایت‌ها دانلود می‌کنیم یا به صورت جریانی از طریق RTSP - یعنی همان روشی که ما آن را با استفاده از استاندارد دریافت کردیم. بازیکن در آخرین مثال. در تنظیمات دوربین های IP، گزینه انتقال داده های جریانی را می توان به عنوان RTSP over، RTSP over یا به سادگی نام برد. بنابراین، RTSP مجموعه ای از دستورات برای کنترل جریان است. اما سایر اختصارات به چه معناست: TCP، RTP؟ TCP و RTP مکانیسم های انتقال (پروتکل) هستند که در واقع ویدئو را انتقال می دهند.

پروتکل TCP

فرض کنید روش RSTP را نسبت به TCP انتخاب کرده‌ایم و می‌خواهیم شروع به انتقال یک جریان ویدیویی کنیم. در سطح مکانیسم های حمل و نقل چه اتفاقی خواهد افتاد؟ قبل از آن با کمک چند دستور ارتباطی بین فرستنده و گیرنده برقرار می شود. پس از آن، انتقال داده های ویدئویی شروع می شود. در همان زمان، مکانیسم های TCP
اطمینان حاصل می کند که تمام داده ها بدون تغییر و به ترتیب صحیح به مخاطب می رسد. TCP همچنین نرخ انتقال را تنظیم می کند تا فرستنده داده ها را با شدت بیشتری نسبت به گیرنده ارسال نکند.

UDP جایگزینی برای پروتکل انتقال TCP است. برخلاف TCP، UDP یک پیش اتصال برقرار نمی کند، بلکه به سادگی شروع به انتقال داده می کند. UDP مطمئن نمی شود که داده ها دریافت شده است و در صورت گم شدن قطعات یا دریافت با خطا، آن ها را کپی نمی کند. UDP کمتر از TCP قابل اعتماد است. اما از سوی دیگر، به دلیل عدم وجود مکانیزمی برای ارسال مجدد بسته های گم شده، جریان سریع تری را فراهم می کند.

با انجام آزمایش زیر می توانید تفاوت پروتکل ها را ببینید: سعی کنید دوربین را روی حالت RTSP روی حالت TCP قرار دهید و دست خود را جلوی لنز تکان دهید - یک تاخیر در صفحه نمایشگر مشاهده خواهید کرد. اکنون همان تست را در RTSP روی حالت UDP اجرا کنید. تاخیر کمتر خواهد بود. چندین عامل بر زمان تأخیر تأثیر می‌گذارند: فرمت فشرده‌سازی، قدرت رایانه، پروتکل انتقال و ویژگی‌ها نرم افزاردرگیر در رمزگشایی ویدیو

RTP (پروتکل حمل و نقل بلادرنگ)، یا پروتکل حمل و نقل بلادرنگ به زبان روسی. این پروتکل به طور خاص برای انتقال ترافیک بلادرنگ طراحی شده است. این به شما امکان می دهد تا همگام سازی داده های ارسال شده را نظارت کنید، ترتیب تحویل بسته را تنظیم کنید و بنابراین برای انتقال داده های تصویری و صوتی مناسب تر است. به طور کلی، استفاده از RTP یا UDP برای انتقال یک جریان ویدیویی ترجیح داده می شود. کار از طریق TCP تنها در صورتی توجیه می شود که مجبور باشیم با شبکه های مشکل دار کار کنیم، زیرا پروتکل TCP می تواند خطاها و خرابی هایی را که در حین انتقال داده رخ می دهد اصلاح کند.

یکی از مهمترین روند تکامل ارتباطات از راه دور مدرن، توسعه IP-telephony است - مجموعه ای از فن آوری های جدید که انتقال پیام های چندرسانه ای (صدا، داده، ویدئو) را از طریق اطلاعات و شبکه های کامپیوتری (ICNs) ساخته شده بر روی بر اساس پروتکل IP (پروتکل اینترنت) از جمله محلی، شرکتی، جهانی شبکه های کامپیوترو اینترنت مفهوم تلفن IP شامل تلفن اینترنتی است که امکان سازماندهی ارتباط تلفنی بین مشترکین اینترنت، بین مشترکین شبکه های تلفن سوئیچ شده عمومی (PSTN) از طریق اینترنت و همچنین ارتباط تلفنی بین مشترکین PSTN و اینترنت با یکدیگر را فراهم می کند.

IP-telephony دارای تعدادی مزیت غیرقابل انکار است که توسعه سریع و گسترش بازار تلفن کامپیوتری را تضمین می کند. برای کاربران نهایی که ارتباطات تلفنی با پرداخت نسبتاً کم در دقیقه ارائه می‌شوند، سودمند است. برای شرکت هایی که شعبه های راه دور دارند، فناوری IP به شما امکان می دهد ارتباطات صوتی را با استفاده از شبکه های IP موجود سازماندهی کنید. به جای چندین شبکه ارتباطی، از یکی استفاده می شود. مزیت بدون شک IP-telephony نسبت به یک تلفن معمولی نیز توانایی ارائه آن است خدمات اضافیاز طریق استفاده از رایانه چند رسانه ای و برنامه های مختلف اینترنتی. بنابراین، با تلفن IP، مشاغل و افراد می‌توانند قابلیت‌های ارتباطی خود را با ترکیب ویدئو کنفرانس پیشرفته، اشتراک‌گذاری برنامه‌ها، ابزارهای تخته سفید و موارد دیگر گسترش دهند.

چه استانداردها و پروتکل های بین المللی پارامترها و الگوریتم های اصلی را برای عملکرد سخت افزار و ابزارهای نرم افزاریاتصالات مورد استفاده در تلفن IP؟ بدیهی است، همانطور که از نام آن پیداست، این فناوری مبتنی بر پروتکل IP است، که با این حال، نه تنها برای تلفن استفاده می شود: این فناوری در ابتدا برای انتقال داده های دیجیتال به IVS سوئیچ بسته توسعه داده شد.

در شبکه‌هایی که کیفیت خدمات تضمینی ارائه نمی‌دهند (اینها شامل شبکه‌هایی است که بر اساس پروتکل IP ساخته شده‌اند)، بسته‌ها ممکن است از بین بروند، ترتیب ورود آنها ممکن است تغییر کند، داده‌های ارسال شده در بسته‌ها ممکن است مخدوش شوند. روش های لایه انتقال مختلف برای اطمینان از تحویل قابل اعتماد اطلاعات ارسال شده تحت این شرایط استفاده می شود. هنگام انتقال داده های دیجیتال، از پروتکل TCP (پروتکل کنترل انتقال) برای این منظور استفاده می شود. این پروتکل تحویل داده قابل اعتماد را فراهم می کند و سفارش بسته اصلی را بازیابی می کند. اگر خطایی در یک بسته شناسایی شود یا بسته گم شود، رویه‌های TCP یک درخواست ارسال مجدد ارسال می‌کنند.

برای برنامه‌های کنفرانس صوتی و تصویری، تأخیر بسته‌ها تأثیر بسیار بیشتری بر کیفیت سیگنال نسبت به اعوجاج داده‌ها دارد. تفاوت در تاخیر می تواند منجر به شکاف شود. برای چنین کاربردهایی، پروتکل لایه انتقال دیگری مورد نیاز است که بازیابی توالی اصلی بسته‌ها، تحویل آنها با کمترین تأخیر، پخش بلادرنگ در لحظات دقیقاً مشخص، تشخیص نوع ترافیک، چندپخشی یا ارتباط دو طرفه. چنین پروتکلی پروتکل حمل و نقل بلادرنگ RTP (پروتکل حمل و نقل در زمان واقعی) است. این پروتکل انتقال داده های چندرسانه ای را در بسته ها از طریق IVS در سطح حمل و نقل تنظیم می کند و با پروتکل کنترل انتقال داده در زمان واقعی RTCP (پروتکل کنترل زمان واقعی) تکمیل می شود. پروتکل RTCP به نوبه خود کنترل بر تحویل داده های چند رسانه ای، کنترل کیفیت خدمات، انتقال اطلاعات در مورد شرکت کنندگان در جلسه ارتباطی جاری، کنترل و شناسایی را فراهم می کند و گاهی اوقات بخشی از پروتکل RTP در نظر گرفته می شود.

در بسیاری از نشریات در مورد تلفن IP، اشاره شده است که بسیاری از تجهیزات شبکهو نرم افزار ویژه این فناوری بر اساس توصیه بخش استانداردسازی مخابرات اتحادیه بین المللی مخابرات (ITU-T) H.323 (شامل TAPI 3.0، NetMeeting 2.0 و غیره) توسعه یافته است. H.323 چگونه با RTP و RTCP ارتباط دارد؟ H.323 یک چارچوب مفهومی گسترده است که شامل بسیاری از استانداردهای دیگر است که هر کدام با جنبه های مختلف انتقال اطلاعات سروکار دارند. بیشتر این استانداردها، مانند استانداردهای کدک صوتی و تصویری، نه تنها در تلفن IP به طور گسترده مورد استفاده قرار می گیرند. در مورد پروتکل‌های RTP/RTCP، آنها اساس استاندارد H.323 را تشکیل می‌دهند، دقیقاً بر روی ارائه فناوری IP متمرکز هستند و زیربنای سازماندهی تلفن IP هستند. این مقاله به بررسی این پروتکل ها اختصاص دارد.

پروتکل حمل و نقل بلادرنگ RTP انتقال بلادرنگ سرتاسر داده های چندرسانه ای مانند صدا و تصویر تعاملی را فراهم می کند. این پروتکل تشخیص نوع ترافیک، شماره‌گذاری توالی بسته‌ها، کار با آن را پیاده‌سازی می‌کند مهر زمانیو کنترل انتقال

عمل پروتکل RTP به تخصیص هر بسته خروجی یک برچسب زمانی کاهش می یابد. در سمت دریافت، مهرهای زمانی بسته نشان می‌دهد که با چه ترتیبی و با چه تاخیرهایی باید پخش شوند. پشتیبانی از RTP و RTCP به میزبان گیرنده این امکان را می دهد که بسته های دریافتی را به ترتیب مناسب مرتب کند، تأثیر لرزش تأخیر بسته در شبکه را بر کیفیت سیگنال کاهش دهد و همگام سازی بین صدا و تصویر را بازیابی کند تا اطلاعات دریافتی به درستی شنیده و مشاهده شود. توسط کاربران

توجه داشته باشید که RTP خود مکانیزمی برای تضمین انتقال به موقع داده ها و کیفیت خدمات ندارد، اما برای اطمینان از این امر از خدمات اساسی استفاده می کند. از ارسال بسته‌های خارج از نظم جلوگیری نمی‌کند، اما فرض نمی‌کند که شبکه اصلی کاملاً قابل اعتماد است و بسته‌ها را به ترتیب صحیح ارسال می‌کند. اعداد دنباله موجود در RTP به گیرنده اجازه می دهد تا بسته های فرستنده را مجدداً ترتیب دهد.

پروتکل RTP از ارتباط دو طرفه و انتقال داده به گروهی از مقصدها پشتیبانی می کند، اگر چندپخشی توسط شبکه زیربنایی پشتیبانی شود. RTP برای ارائه اطلاعات مورد نیاز برنامه های کاربردی در نظر گرفته شده است و در بیشتر موارد در عملکرد برنامه یکپارچه می شود.

اگرچه RTP به عنوان یک پروتکل لایه انتقال در نظر گرفته می شود، اما معمولاً در بالای پروتکل لایه انتقال دیگری، UDP (پروتکل Datagram کاربر) عمل می کند. هر دو پروتکل به عملکرد لایه انتقال کمک می کنند. لازم به ذکر است که RTP و RTCP مستقل از لایه های انتقال و شبکه زیرین هستند، بنابراین پروتکل های RTP/RTCP را می توان با سایر پروتکل های انتقال مناسب استفاده کرد.

واحدهای داده پروتکل RTP/RTCP بسته نامیده می شوند. بسته هایی که مطابق با پروتکل RTP تولید می شوند و برای انتقال داده های چند رسانه ای استفاده می شوند، بسته های اطلاعاتی یا بسته های داده (بسته های داده) و بسته هایی که مطابق با پروتکل RTCP تولید می شوند و برای انتقال اطلاعات سرویس مورد نیاز برای کنفرانس های راه دور قابل اعتماد استفاده می شوند، بسته ها نامیده می شوند. یا بسته های سرویس (بسته های کنترلی). یک بسته RTP شامل یک هدر ثابت، یک پسوند هدر با طول متغیر اختیاری و یک فیلد داده است. یک بسته RTCP با یک بخش ثابت (شبیه به قسمت ثابت بسته های اطلاعاتی RTP) شروع می شود و سپس بلوک های ساختمانی با طول متغیر قرار می گیرند.

برای اینکه پروتکل RTP منعطف تر باشد و برای برنامه های مختلف قابل استفاده باشد، برخی از پارامترهای آن عمداً تعریف نشده اند، اما مفهوم پروفایل را ارائه می دهد. نمایه (پروفایل) مجموعه ای از پارامترها برای پروتکل های RTP و RTCP برای یک کلاس خاص از برنامه ها است که ویژگی های عملکرد آنها را تعیین می کند. نمایه استفاده از فیلدهای هدر بسته، انواع ترافیک، افزودن سرصفحه و الحاقات سرصفحه، انواع بسته ها، سرویس ها و الگوریتم های امنیت ارتباطی، ویژگی های استفاده از پروتکل زیربنایی، و غیره را تعریف می کند. نمایه RTP برای کنفرانس های صوتی و تصویری با حداقل کنترل ). هر اپلیکیشن معمولا تنها با یک پروفایل کار می کند و تنظیم نوع پروفایل با انتخاب اپلیکیشن مناسب انجام می شود. عدم اشاره صریح نوع نمایه بر اساس شماره پورت، شناسه پروتکل و غیره. ارائه نشده است.

بنابراین، یک مشخصات کامل RTP برای یک برنامه خاص باید شامل اسناد اضافی باشد که شامل توضیحات نمایه و همچنین یک توضیح فرمت ترافیک است که نحوه پردازش نوع خاصی از ترافیک، مانند صدا یا تصویر، در RTP را مشخص می کند.

ویژگی‌های انتقال داده‌های چندرسانه‌ای در طول کنفرانس‌های صوتی و تصویری در بخش‌های زیر مورد بحث قرار می‌گیرد.

کنفرانس صوتی گروهی به یک آدرس گروه چند کاربره و دو پورت نیاز دارد. در این حالت یک پورت برای تبادل داده های صوتی مورد نیاز است و دیگری برای کنترل بسته های پروتکل RTCP استفاده می شود. آدرس گروه و اطلاعات پورت برای شرکت کنندگان در کنفرانس راه دور ارسال می شود. در صورت نیاز به حفظ حریم خصوصی، بسته های اطلاعات و کنترل ممکن است همانطور که در بخش 7.1 تعریف شده است رمزگذاری شوند، در این صورت کلید رمزگذاری نیز باید تولید و توزیع شود.

برنامه کنفرانس صوتی که توسط هر شرکت کننده در کنفرانس استفاده می شود، داده های صوتی را به صورت پشت سر هم، مانند 20 میلی ثانیه ارسال می کند. قبل از هر قطعه از داده های صوتی یک عنوان RTP وجود دارد. هدر RTP و داده ها به نوبه خود در یک بسته UDP تشکیل می شوند (کپسوله می شوند). هدر RTP نشان می دهد که کدام نوع کدگذاری صوتی (مثلا PCM، ADPCM یا LPC) برای تشکیل داده ها در بسته استفاده شده است. این امکان تغییر نوع کدگذاری را در طول کنفرانس فراهم می‌کند، به عنوان مثال، زمانی که یک شرکت‌کننده جدید وارد می‌شود که از اتصال پهنای باند کم استفاده می‌کند، یا در هنگام ازدحام شبکه.

در اینترنت، مانند دیگر شبکه‌های داده سوئیچ بسته، بسته‌ها گاهی گم می‌شوند و مرتب می‌شوند و همچنین برای زمان‌های مختلف به تأخیر می‌افتند. برای مقابله با این رویدادها، هدر RTP حاوی یک مهر زمانی و شماره ترتیبی است که به گیرنده‌ها اجازه می‌دهد زمان‌بندی مجدد کنند، به‌طور مثال، بخش‌هایی از سیگنال صوتی به‌طور پیوسته در هر 20 میلی‌ثانیه توسط بلندگو پخش می‌شود. این بازسازی زمان بندی به طور جداگانه و مستقل برای هر منبع بسته های RTP در کنفرانس تلفنی انجام می شود. شماره دنباله همچنین می تواند توسط گیرنده برای تخمین تعداد بسته های گم شده استفاده شود.

از آنجایی که شرکت کنندگان در یک کنفرانس تلفنی می توانند در حالی که کنفرانس تلفنی در حال انجام است به آن بپیوندند و آن را ترک کنند، دانستن اینکه چه کسی در کنفرانس تلفنی شرکت می کند مفید است. این لحظهو شرکت کنندگان در کنفرانس چقدر داده های صوتی را دریافت می کنند. برای این منظور، هر نمونه از برنامه صوتی در طول کنفرانس به طور دوره ای در پورت کنترل (پورت RTCP) برای برنامه های سایر شرکت کنندگان، پیام های دریافت بسته ای را که نام کاربری آنها را نشان می دهد، صادر می کند. پیام دریافت نشان می دهد که بلندگوی فعلی چقدر خوب شنیده می شود و می توان از آن برای کنترل رمزگذارهای تطبیقی استفاده کرد. علاوه بر نام کاربری، سایر اطلاعات شناسایی برای کنترل پهنای باند نیز ممکن است گنجانده شود. هنگام خروج از کنفرانس، سایت یک بسته RTCP BYE ارسال می کند.

اگر در یک کنفرانس تلفنی از سیگنال های صوتی و تصویری استفاده شود، آنها به طور جداگانه منتقل می شوند. برای انتقال هر نوع ترافیک، بدون توجه به نوع دیگر، مشخصات پروتکل مفهوم جلسه RTP را معرفی می کند (لیست اختصارات و اصطلاحات استفاده شده را ببینید). یک جلسه توسط یک جفت آدرس انتقال مقصد مشخص (یک آدرس شبکه به اضافه یک جفت پورت برای RTP و RTCP) تعریف می شود. بسته ها برای هر نوع ترافیک با استفاده از دو جفت مختلف پورت UDP و/یا آدرس های چندپخشی منتقل می شوند. هیچ ارتباط مستقیم لایه RTP بین جلسات صوتی و تصویری وجود ندارد، به جز اینکه کاربری که در هر دو جلسه شرکت می کند باید از یک نام متعارف در بسته های RTCP برای هر دو جلسه استفاده کند تا بتوان جلسات را پیوند داد.

یکی از دلایل این جدایی این است که برخی از شرکت کنندگان در کنفرانس باید در صورت تمایل فقط یک نوع ترافیک را دریافت کنند. علی رغم جداسازی، پخش همزمان داده های رسانه منبع (صوتی و تصویری) را می توان با استفاده از اطلاعات زمان بندی که در بسته های RTCP برای هر دو جلسه حمل می شود، به دست آورد.

همیشه همه سایت‌ها توانایی دریافت داده‌های چندرسانه‌ای در قالب یکسان را ندارند. موردی را در نظر بگیرید که شرکت کنندگان از همان محل از طریق یک پیوند با سرعت کم به اکثر شرکت کنندگان دیگر کنفرانس که به شبکه پهنای باند دسترسی دارند متصل می شوند. به جای اینکه همه را مجبور به استفاده از پهنای باند باریکتر و کدگذاری صوتی با کیفیت پایین تر کنیم، یک تسهیلات ارتباطی لایه RTP به نام میکسر را می توان در یک منطقه با پهنای باند کم قرار داد. این میکسر بسته‌های صوتی ورودی را مجدداً همگام می‌کند تا فواصل 20 میلی‌ثانیه اصلی را بازیابی کند، این جریان‌های صوتی بازیابی شده را در یک جریان واحد ترکیب می‌کند، کدگذاری می‌کند. سیگنال صوتیبرای پهنای باند باریک و جریانی از بسته ها را از طریق یک لینک با سرعت کم ارسال می کند. در این حالت، بسته ها می توانند به یک گیرنده یا گروهی از گیرندگان با آدرس های مختلف خطاب شوند. به منظور دریافت نقاط پایانی برای ارائه یک نشانه صحیح از منبع پیام ها، هدر RTP شامل ابزارهایی برای میکسرها می شود تا منابع دخیل در تشکیل بسته مخلوط را شناسایی کنند.

برخی از شرکت کنندگان در کنفرانس صوتی ممکن است با خطوط ارتباطی باند پهن متصل شوند، اما ممکن است از طریق یک کنفرانس گروه چندپخشی IP (IPM) قابل دسترسی نباشند. به عنوان مثال، آنها ممکن است پشت فایروال لایه برنامه باشند که اجازه انتقال بسته های IP را نمی دهد. برای چنین مواردی، به میکسرها نیاز نیست، بلکه به نوع دیگری از ارتباط لایه RTP، به نام مترجم، نیاز است. از دو مترجم، یکی خارج از فایروال نصب شده است و تمام بسته های چندپخشی دریافتی را از طریق یک اتصال امن به مترجم دیگری که پشت دیوار آتش نصب شده است، به صورت خارجی ارسال می کند. مترجم پشت فایروال آنها را دوباره به عنوان بسته های چندپخشی برای یک گروه چند کاربره محدود به شبکه داخلی سایت پخش می کند.

میکسرها و مترجم ها را می توان برای اهداف مختلفی طراحی کرد. مثال: یک میکسر ویدیویی که تصاویر ویدیویی افراد را در جریان‌های ویدیویی مستقل مقیاس‌بندی می‌کند و آنها را در یک جریان ویدیویی واحد ترکیب می‌کند و یک صحنه گروهی را شبیه‌سازی می‌کند. نمونه‌های پخش: اتصال گروهی از میزبان‌های فقط IP/UDP به گروهی از میزبان‌های فقط ST-II، یا رمزگذاری بسته‌های ویدئویی توسط بسته از منابع مجزا بدون زمان‌بندی مجدد یا اختلاط. جزئیات نحوه کار میکسرها و مترجم ها در بخش 5 مورد بحث قرار گرفته است.

تمام فیلدهای بسته های RTP/RTCP از طریق شبکه به صورت بایت (هشتت) منتقل می شوند. مهم ترین بایت ابتدا منتقل می شود. تمام داده های فیلد سرصفحه با توجه به طول آن تراز می شوند . اکتت هایی که به عنوان اختیاری تعیین می شوند مقدار صفر دارند.

زمان مطلق (زمان ساعت دیواری) در RTP با استفاده از قالب مهر زمان نشان داده می شود پروتکل شبکهزمان NTP (پروتکل زمان شبکه)، که شمارش معکوس بر حسب ثانیه نسبت به ساعت صفر در 1 ژانویه 1900 است. قالب کامل مهر زمانی NTP یک عدد نقطه ثابت بدون علامت 64 بیتی با یک قسمت صحیح در 32 بیت اول و یک قسمت کسری در 32 بیت آخر است. در برخی از زمینه ها با نمایش فشرده تر، فقط از 32 بیت میانی استفاده می شود - 16 بیت پایین قسمت عدد صحیح و 16 بیت بالا از قسمت کسری.

دو بخش بعدی این مقاله (3 و 4) به ترتیب در مورد قالب‌های بسته و ویژگی‌های عملکرد پروتکل‌های RTP و RTCP بحث می‌کنند.

همانطور که در بالا ذکر شد، یک بسته RTP شامل یک هدر ثابت، یک پسوند هدر با طول متغیر اختیاری و یک فیلد داده است. هدر ثابت بسته های پروتکل RTP دارای فرمت زیر است: .

دوازده اکتت اول در هر بسته RTP وجود دارد، در حالی که فیلد شناسه منبع کمک کننده CSRC (منبع کمک کننده) تنها زمانی وجود دارد که توسط میکسر درج شود. فیلدها اهداف زیر را دارند.

نسخه (V): 2 بیت. این قسمت نسخه RTP را مشخص می کند. این مقاله بر روی نسخه 2 پروتکل RTP تمرکز دارد (مقدار 1 در اولین نسخه پیش نویس RTP استفاده شده است).

مکمل (P): 1 بیت. اگر بیت padding روی یک تنظیم شده باشد، بسته در انتها شامل یک یا چند هشت بالشتک است که بخشی از ترافیک نیستند. آخرین octet padding نشانی از تعداد چنین octet هایی دارد که بعداً نادیده گرفته می شوند. ممکن است برای برخی از الگوریتم‌های رمزی با اندازه بلوک ثابت یا برای حمل بسته‌های RTP متعدد در یک بار پروتکل زیربنایی، نیاز به padding باشد.

پسوند (X): 1 بیت. اگر بیت پسوند تنظیم شده باشد، پس از هدر ثابت یک پسوند هدر با فرمت تعریف شده در .

شمارنده CSRC (CC): 4 بیت. شمارنده CSRC حاوی تعداد شناسه های منبع CSRC برای گنجاندن است (لیست اختصارات و اصطلاحات استفاده شده را ببینید) که از هدر ثابت پیروی می کنند.

نشانگر (M): 1 بیت. تفسیر نشانگر با نمایه تعیین می شود. در نظر گرفته شده است که اجازه دهد رویدادهای مهم (مثلاً مرزهای فریم ویدیو) در جریان بسته علامت گذاری شوند. نمایه ممکن است بیت های نشانگر دیگری را معرفی کند یا با تغییر تعداد بیت ها در فیلد نوع ترافیک مشخص کند که هیچ بیت نشانگری وجود ندارد (نگاه کنید به ).

نوع ترافیک (PT): 7 بیت. این فیلد فرمت ترافیک RTP را مشخص می کند و نحوه تفسیر برنامه را تعیین می کند. یک نمایه یک نگاشت استاتیک پیش فرض از مقادیر PT و فرمت های ترافیک را تعریف می کند. کدهای نوع ترافیک اضافی را می توان به صورت پویا از طریق امکانات غیر RTP تعریف کرد. فرستنده یک بسته RTP در هر زمان معین یک مقدار ترافیک RTP را منتشر می کند. این فیلد برای مالتی پلکس کردن جریان های رسانه ای منفرد در نظر گرفته نشده است (نگاه کنید به ).

شماره دنباله: 16 بیت. مقدار شماره دنباله با ارسال هر بسته اطلاعاتی RTP یک عدد افزایش می یابد و می تواند توسط گیرنده برای شناسایی بسته های گم شده و بازیابی توالی اصلی آنها استفاده شود. مقدار اولیه شماره دنباله به‌طور تصادفی انتخاب می‌شود تا شکستن کلید بر اساس مقادیر شناخته شده این فیلد دشوار شود (حتی اگر منبع از رمزگذاری استفاده نکند، زیرا بسته‌ها ممکن است از رله‌ای عبور کنند که از رمزگذاری استفاده می‌کند). مهر زمانی: 32 بیت. مهر زمان زمان نمونه برداری برای اولین اکتت در بسته اطلاعاتی RTP را منعکس می کند. زمان نمونه باید از یک تایمر بدست آید که به صورت یکنواخت و خطی با زمان افزایش می یابد تا همگام سازی و تشخیص لرزش را فراهم کند (به بخش 4.3.1 مراجعه کنید). وضوح تایمر باید برای دقت زمان‌بندی مورد نظر و اندازه‌گیری جیتر رسیدن بسته کافی باشد (یک گزارش تایمر در هر فریم ویدئو معمولاً کافی نیست). فرکانس زمان بندی به فرمت ترافیک ارسالی بستگی دارد و به صورت ایستا در نمایه فرمت ترافیک یا مشخصات تنظیم می شود، یا می تواند به صورت پویا برای قالب های ترافیکی که از طریق "امکانات غیر RTP" تعریف شده اند، تنظیم شود. اگر بسته‌های RTP به صورت دوره‌ای تولید می‌شوند، باید از زمان‌های نمونه‌برداری اسمی تعیین‌شده توسط تایمر نمونه‌برداری استفاده شود، نه مقادیر تایمر سیستم. به عنوان مثال، برای یک سیگنال صوتی با نرخ ثابت، مطلوب است که رمزگذار مهر زمانی برای هر دوره نمونه یک عدد افزایش یابد. اگر یک برنامه صوتی از یک دستگاه ورودی بلوک‌های حاوی 160 نمونه را بخواند، بدون در نظر گرفتن اینکه آیا بلوک در یک بسته ارسال شده یا به صورت مکث حذف شده است، مهر زمانی باید برای هر بلوک 160 افزایش یابد. مقدار اولیهبرچسب زمان، و همچنین مقدار اولیه شماره دنباله، یک متغیر تصادفی است. چندین بسته RTP متوالی ممکن است دارای مهر زمانی برابر باشند اگر به طور منطقی در یک زمان تولید شوند، به عنوان مثال متعلق به یک فریم ویدیویی باشند. بسته‌های RTP متوالی ممکن است حاوی مهرهای زمانی غیر یکنواخت باشند، اگر داده‌ها به ترتیب نمونه ارسال نشوند، همانطور که در مورد فریم‌های ویدئویی MPEG درون‌یابی شده وجود دارد (اما، اعداد دنباله بسته‌ها هنگام ارسال همچنان یکنواخت خواهند بود).

SSRC: 32 بیت. فیلد SSRC (منبع همگام سازی) منبع همگام سازی را مشخص می کند (لیست اختصارات و اصطلاحات استفاده شده را ببینید). این شناسه به‌طور تصادفی انتخاب می‌شود تا هیچ دو منبع ساعتی در یک جلسه RTP یک شناسه SSRC نداشته باشند. در حالی که احتمال انتخاب یک شناسه از چندین منبع کم است، همه پیاده سازی های RTP باید برای شناسایی و حل چنین برخوردهایی آماده باشند. بخش 6 احتمال برخوردها را به همراه مکانیزمی برای حل آنها و شناسایی حلقه های لایه RTP بر اساس منحصر به فرد بودن شناسه SSRC مورد بحث قرار می دهد. اگر منبعی آدرس انتقال اصلی خود را تغییر دهد، باید یک شناسه SSRC جدید نیز انتخاب کند تا به عنوان منبع حلقه ای تفسیر نشود.

لیست CSRC: 0 تا 15 مورد، هر کدام 32 بیت. فهرست منبع کمک کننده (CSRC) منابع ترافیک موجود در بسته را شناسایی می کند. تعداد شناسه ها توسط فیلد CC داده می شود. اگر بیش از پانزده منبع گنجانده شده باشد، تنها 15 مورد از آنها قابل شناسایی است. شناسه‌های CSRC هنگام استفاده از شناسه‌های SSRC برای منابع سوئیچ شده توسط میکسرها درج می‌شوند. به عنوان مثال، برای بسته‌های صوتی، شناسه‌های SSRC همه منابعی که هنگام ایجاد بسته با هم ترکیب شده‌اند، در فهرست CSRC فهرست شده‌اند که نشان‌دهنده درستی از منابع پیام برای گیرنده است.

همانطور که در بالا ذکر شد، مطابق با پروتکل RTP، انواع مختلف ترافیک باید به طور جداگانه و در جلسات RTP مختلف منتقل شوند. یک جلسه توسط یک جفت آدرس انتقال مقصد مشخص (یک آدرس شبکه به اضافه یک جفت پورت برای RTP و RTCP) تعریف می شود. به عنوان مثال، در یک کنفرانس تلفنی که از صدا و تصویر رمزگذاری شده جداگانه تشکیل شده است، هر نوع ترافیک باید در یک جلسه RTP جداگانه با آدرس حمل و نقل مقصد خاص خود ارسال شود. انتظار نمی رود صدا و تصویر در یک جلسه RTP حمل شوند و بر اساس نوع ترافیک یا فیلدهای SSRC از هم جدا شوند. درهم آمیختن بسته هایی که دارند انواع متفاوتترافیک اما استفاده از همان SSRC باعث ایجاد برخی مشکلات می شود:

اگر یکی از انواع ترافیک در طول یک جلسه تغییر کند، هیچ ابزار کلی برای تعیین اینکه کدام یک از مقادیر قدیمی با مقادیر جدید جایگزین شده است وجود نخواهد داشت.
SSRC یک مقدار بازه زمانی واحد و فضای شماره دنباله را شناسایی می کند. اگر نرخ ساعت جریان‌های مختلف متفاوت باشد، برای نشان دادن نوع ترافیکی که از دست دادن بسته‌ها به آن مربوط می‌شود، به‌هم‌پیچیدن چندین نوع ترافیک نیاز به فواصل همگام‌سازی متفاوتی دارد.
پیام‌های فرستنده و گیرنده RTCP (به بخش 4.3 مراجعه کنید) فقط یک مقدار فاصله زمانی و فضای شماره ترتیبی را برای SSRC توصیف می‌کنند و دارای فیلد نوع ترافیک نیستند.
میکسر RTP قادر به ترکیب جریان های در هم تنیده از انواع مختلف ترافیک در یک جریان واحد نیست.
عوامل زیر مانع از انتقال چندین نوع ترافیک در یک جلسه RTP می شود: استفاده از انواع مختلف مسیرهای شبکهیا تخصیص منابع شبکه دریافت زیرمجموعه ای از داده های چندرسانه ای در صورت لزوم، مانند صدا فقط در صورتی که سیگنال ویدئویی از پهنای باند موجود فراتر رفته باشد. پیاده‌سازی‌های سینک که از فرآیندهای جداگانه برای انواع مختلف ترافیک استفاده می‌کنند، در حالی که استفاده از جلسات RTP جداگانه امکان پیاده‌سازی تک‌فرایند و چندگانه را فراهم می‌کند.

با استفاده از SSRC های مختلف برای هر نوع ترافیک، اما ارسال آنها در همان جلسه RTP، می توان از سه مشکل اول جلوگیری کرد، اما دو مشکل آخر را نمی توان اجتناب کرد. بنابراین، مشخصات پروتکل RTP مستلزم آن است که هر نوع ترافیک از جلسه RTP خود استفاده کند.

سرصفحه بسته اطلاعات RTP موجود برای مجموعه ای از ویژگی های مورد نیاز به طور کلی برای همه کلاس های برنامه هایی که ممکن است RTP را پشتیبانی کنند کامل است. با این حال، برای انطباق بهتر با وظایف خاص، هدر را می توان از طریق تغییرات یا اضافات تعریف شده در مشخصات مشخصات تغییر داد.

بیت نشانگر و فیلد نوع ترافیک حاوی اطلاعات خاصی از نمایه هستند، اما در یک هدر ثابت قرار دارند زیرا انتظار می رود بسیاری از برنامه ها به آنها نیاز داشته باشند. اکتت حاوی این فیلدها ممکن است توسط نمایه بازتعریف شود تا نیازهای مختلف را برآورده کند، به عنوان مثال با بیت های نشانگر بیشتر یا کمتر. اگر هر بیت نشانگر وجود داشته باشد، آنها باید در بیت های مرتبه بالای اکتت قرار گیرند، زیرا مانیتورهای مستقل از نمایه ممکن است بتوانند ارتباط بین الگوی از دست دادن بسته و بیت نشانگر را مشاهده کنند.

اطلاعات اضافی که برای یک فرمت ترافیک خاص مورد نیاز است (به عنوان مثال نوع کدگذاری ویدیو) باید در قسمت داده بسته حمل شود. می توان آن را در یک مکان مشخص در ابتدا یا داخل آرایه داده قرار داد.

اگر یک کلاس خاص از برنامه ها به عملکرد اضافی مستقل از قالب ترافیک نیاز داشته باشد، آنگاه نمایه ای که آن برنامه ها با آن کار می کنند باید فیلدهای ثابت اضافی را تعریف کند تا بلافاصله بعد از فیلد SSRC سربرگ ثابت موجود قرار گیرد. این برنامه‌ها می‌توانند مستقیماً به فیلدهای اضافی دسترسی پیدا کنند، در حالی که مانیتورها یا ضبط‌کننده‌های مستقل از نمایه همچنان می‌توانند بسته‌های RTP را تنها با تفسیر دوازده اکتت اول پردازش کنند.

در صورتی که اضافه در نظر گرفته شود عملکردبه طور کلی برای تمام پروفایل ها مورد نیاز است، سپس یک نسخه جدید RTP برای ایجاد تغییر دائمی عنوان ثابت.

برای اینکه پیاده‌سازی‌های منفرد بتوانند ویژگی‌های جدید مستقل از فرمت ترافیک را که نیاز به اطلاعات اضافی در سربرگ بسته اطلاعاتی دارند، آزمایش کنند، RTP مکانیزم گسترش سرصفحه بسته را فراهم می‌کند. این مکانیزم به گونه ای طراحی شده است که پسوند هدر توسط سایر برنامه های کاربردی که به آن نیاز ندارند نادیده گرفته شود.

اگر بیت X در هدر RTP روی یک تنظیم شود، پسوند هدر با طول متغیر به هدر RTP ثابت اضافه می شود (در صورت وجود، به دنبال لیست CSRC). توجه داشته باشید که این پسوند هدر فقط برای استفاده محدود است. پسوند هدر بسته RTP دارای فرمت زیر است:

برنامه افزودنی شامل یک فیلد طول 16 بیتی است که تعداد کلمات 32 بیتی را در آن نشان می دهد، به استثنای سرصفحه پسوند چهار هشتگانه (از این رو طول می تواند صفر باشد). فقط یک پسوند را می توان به سربرگ بسته اطلاعاتی RTP ثابت اضافه کرد. برای اجازه دادن به هر یک از چندین پیاده‌سازی همکار برای آزمایش مستقل با پسوندهای سرصفحه مختلف، یا اجازه دادن به یک پیاده‌سازی خاص برای آزمایش با بیش از یک نوع پسوند هدر، استفاده از 16 بیت اول پسوند تعریف نشده است و به تمایز واگذار می‌شود. شناسه ها یا پارامترها فرمت این 16 بیت باید با مشخصات پروفایلی که برنامه ها با آن کار می کنند تعیین شود.

1999
2000

شناسه منبع همگام سازی (SSRC).

شناسه های منبع کمک کننده (CSRC).

پروتکل اصلی حمل و نقل برای برنامه های چند رسانه ای تبدیل به پروتکل بلادرنگ RTP (پروتکل زمان واقعی) شده است که برای سازماندهی انتقال بسته ها با سیگنال های گفتاری رمزگذاری شده از طریق یک شبکه IP طراحی شده است. انتقال بسته های RTP از طریق پروتکل UDP انجام می شود که به نوبه خود از طریق IP کار می کند (شکل 1.5).

برنج. 1.5.

در واقع، سطحی که RTP به آن تعلق دارد، همانطور که در شکل نشان داده شده است به طور واضح تعریف نشده است. 1.5 و همانطور که معمولا در ادبیات توضیح داده شده است. از یک طرف، پروتکل واقعاً در بالای UDP کار می کند، پیاده سازی می شود برنامه های کاربردیو طبق همه نشانه ها، یک پروتکل کاربردی است. اما در عین حال، همانطور که در ابتدای این پاراگراف بیان شد، RTP خدمات حمل و نقل را مستقل از برنامه های چند رسانه ای ارائه می دهد و از این منظر فقط یک پروتکل حمل و نقل است. بهترین تعریف: RTP یک پروتکل انتقال است که در لایه برنامه پیاده سازی شده است.

برای انتقال ترافیک صوتی (چند رسانه ای)، RTP از بسته هایی استفاده می کند که ساختار آنها در شکل نشان داده شده است. 1.6.

یک بسته RTP حداقل از 12 بایت تشکیل شده است. دو بیت اول هدر RTP (فیلد بیت نسخه، V) نشان دهنده نسخه پروتکل RTP (نسخه فعلی 2) است.

واضح است که با این ساختار هدر، حداکثر یک نسخه RTP دیگر امکان پذیر است. فیلد پس از آنها شامل دو بیت است: بیت P، که نشان می دهد آیا کاراکترهای padding به انتهای فیلد محموله اضافه شده اند یا نه (اگر پروتکل انتقال یا الگوریتم رمزگذاری نیاز به استفاده از بلوک های با اندازه ثابت داشته باشد، معمولاً اضافه می شوند). بیت X، که نشان می دهد که آیا از یک هدر توسعه یافته استفاده می شود یا خیر.

برنج. 1.6.

در صورت استفاده، اولین کلمه هدر توسعه یافته شامل طول کل پسوند است. علاوه بر این، چهار بیت CC تعداد فیلدهای CSRC را در انتهای هدر RTP تعیین می کنند، یعنی. تعداد منابع تشکیل دهنده جریان بیت نشانگر M به شما امکان می دهد آنچه را که استاندارد به عنوان رویدادهای مهم تعریف می کند، علامت گذاری کنید، به عنوان مثال، شروع یک فریم ویدیو، شروع یک کلمه در یک کانال صوتی و غیره. به دنبال آن یک فیلد نوع داده PT (7 بیت) وجود دارد که نشان دهنده کد نوع بار است که محتویات فیلد بار را تعیین می کند - داده های برنامه (داده های برنامه)، به عنوان مثال، صدای MP3 8 بیتی فشرده نشده و غیره. از این کد، برنامه می تواند یاد بگیرد که برای رمزگشایی داده ها چه کاری انجام دهد. بقیه هدر با طول ثابت شامل یک فیلد Sequence Number، یک قسمت Time Stamp برای ضبط اولین کلمه بسته است و یک فیلد منبع زمان‌بندی SSRC که این منبع را مشخص می‌کند. آخرین فیلد می‌تواند یک دستگاه تنها با یک آدرس شبکه، چندین منبع باشد که می‌تواند رسانه‌های مختلف (صوتی، ویدیویی و غیره) یا جریان‌های مختلف یک رسانه را نشان دهد. از آنجایی که منابع ممکن است دستگاه های مختلف، شناسه SSRC به طور تصادفی انتخاب می شود تا شانس دریافت داده ها از دو منبع به طور همزمان در طول یک جلسه RTP حداقل باشد. با این حال، مکانیسمی برای حل تعارض در صورت بروز آنها نیز تعریف شده است. بخش ثابت هدر RTP را می توان با حداکثر 15 فیلد CSRC 32 بیتی جداگانه دنبال کرد که منابع داده را شناسایی می کند.

RTP توسط پروتکل کنترل حمل و نقل در زمان واقعی (RTCP) پشتیبانی می شود، که گزارش های اضافی حاوی اطلاعات مربوط به جلسات RTP را تولید می کند. به یاد داشته باشید که نه UDP و نه RTP در ارائه QoS (کیفیت خدمات) مشغول نیستند. پروتکل RTCP فراهم می کند بازخوردبا فرستنده ها، و برای گیرندگان جریان، برخی از پیشرفت های QoS، اطلاعات بسته (از دست دادن، تاخیر، لرزش) و کاربر (برنامه، جریان) را فراهم می کند. برای کنترل جریان، دو نوع گزارش وجود دارد - تولید شده توسط فرستنده و تولید شده توسط گیرنده. به عنوان مثال، اطلاعات مربوط به درصد بسته‌های از دست رفته و تعداد مطلق تلفات به فرستنده اجازه می‌دهد، هنگام دریافت گزارش، تشخیص دهد که ازدحام کانال ممکن است باعث شود گیرندگان جریان‌های بسته‌ای را که انتظار داشتند دریافت نکنند. در این حالت، فرستنده این گزینه را دارد که نرخ کدگذاری را برای کاهش تراکم و بهبود دریافت کاهش دهد. گزارش فرستنده حاوی اطلاعات مربوط به زمان تولید آخرین بسته RTP است (هم شامل یک برچسب داخلی و هم می شود به موقع). این اطلاعات به گیرنده اجازه می دهد تا جریان های متعددی مانند ویدئو و صدا را هماهنگ و همگام کند. اگر جریان به چندین گیرنده هدایت شود، جریان های بسته های RTCP از هر یک از آنها سازماندهی می شوند. این اقداماتی را برای محدود کردن پهنای باند انجام می دهد - به طور معکوس با نرخ تولید گزارش های RTCP و تعداد گیرندگان متناسب است.

لازم به ذکر است که اگرچه RTCP جدا از RTP کار می کند، زنجیره RTP/UDP/IP خود منجر به هزینه های سربار قابل توجهی (در قالب هدر آنها) می شود. کدک G.729 بسته های 10 بایتی (80 بیت در هر 10 میلی ثانیه) تولید می کند. یک هدر RTP با اندازه 12 بایت بزرگتر از کل این بسته است. علاوه بر این، یک هدر UDP 8 بایتی و یک هدر IP 20 بایتی (در IPv4) باید به آن اضافه شود که یک هدر چهار برابر داده های ارسالی ایجاد می کند.