پروتکل های RTP و RTCP در VoIP. پروتکل های RTSP، RTP، UDP و TCP در سیستم های نظارت تصویری

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

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

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

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

9. فهرست ثابت های پروتکل

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

ثابت های نوع ترافیک RTP (PT - نوع بار محموله) در پروفایل ها تعریف می شوند. با این حال، هشت هدر RTP که حاوی بیت(های) نشانگر و فیلد نوع ترافیک است، نباید حاوی مقادیر رزرو شده 200 و 201 (اعشاری) باشد تا بسته های RTP را از بسته های RTCP SR و RR متمایز کند. برای قالب استاندارد با یک بیت نشانگر و یک فیلد نوع ترافیک هفت بیتی، این محدودیت به این معنی است که انواع ترافیک 72 و 73 نباید استفاده شود.

مقادیر انواع بسته های RTCP (به جدول 1 مراجعه کنید) در محدوده 200 تا 204 انتخاب می شوند تا صحت هدر بسته RTCP را در مقایسه با بسته های RTP بهتر کنترل کنند. هنگامی که فیلد نوع بسته RTCP با اکتت متناظر سرآیند RTP مقایسه می شود، این محدوده با یک بیت نشانگر یک (که معمولاً در بسته های اطلاعاتی اینطور نیست) و مهم ترین بیت از فیلد نوع ترافیک استاندارد یک مطابقت دارد. (در حالی که انواع ترافیک تعریف شده استاتیک معمولاً دارای مقادیر PT با صفر در مهمترین رقم هستند). این محدوده همچنین از مقادیر 0 و 255 دورتر انتخاب شده است، زیرا فیلدهایی که کاملاً از صفر یا یک تشکیل شده اند عمدتاً مشخصه داده ها هستند.

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

انواع معتبر اقلام در بسته SDES در جدول ارائه شده است. 2. سایر انواع اقلام SDES توسط انجمن IANA اختصاص داده شده است. توسعه دهندگان این توانایی را دارند که مقادیر مورد نیاز خود را هنگام انجام مطالعات تجربی ثبت کنند و سپس زمانی که دیگر به آن مقادیر نیاز نیست، از ثبت نام خارج کنند.

10. شرح مشخصات و قالب ترافیک

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

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

یک سند اختیاری از نوع دوم، مشخصات قالب ترافیک، نحوه انتقال نوع خاصی از ترافیک (مثلاً ویدیوی رمزگذاری شده H.261) را بر اساس RTP تعریف می کند. یک قالب ترافیک ممکن است برای چندین نمایه استفاده شود و بنابراین ممکن است مستقل از نمایه تعریف شود. اسناد نمایه فقط مسئول تطبیق این قالب با مقدار PT هستند .

شرح نمایه ممکن است موارد زیر را تعریف کند، اما این فهرست جامع نیست.

سربرگ بسته داده RTP. اکتت در هدر بسته داده RTP، که حاوی بیت رمز و فیلد نوع ترافیک است، می تواند با توجه به مشخصات برای برآورده کردن نیازهای مختلف، به عنوان مثال برای ارائه بیت های بیشتر یا کمتر رمز، مجدداً تعریف شود (بخش 3.3).

انواع ترافیک یک نمایه معمولاً مجموعه‌ای از فرمت‌های ترافیک (به عنوان مثال، الگوریتم‌های رمزگذاری رسانه) و یک نگاشت استاتیک پیش‌فرض از این قالب‌ها و مقادیر PT را تعریف می‌کند. برخی از قالب‌های ترافیک ممکن است با ارجاع به توضیحات فرمت ترافیک فردی تعریف شوند. برای هر نوع ترافیک تعریف شده، نمایه باید نرخ ساعت مُهر زمانی RTP مورد نیاز برای استفاده را مشخص کند (بخش 3.1).

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

پسوندهای هدر بسته داده RTP. محتویات 16 بیت اول ساختار RTP Data Packet Header Extension باید مشخص شود اگر استفاده از این مکانیسم توسط نمایه مجاز باشد. .

انواع بسته های RTCP ممکن است انواع جدیدی از بسته های RTCP در کلاس برنامه تعریف شوند (و با IANA ثبت شوند).

فاصله گزارش RTCP نمایه باید مقادیر مورد استفاده در محاسبه فاصله گزارش RTCP را مشخص کند: کسر پهنای باند جلسه RTCP، حداقل فاصله گزارش دهی، و پهنای باند تقسیم بین فرستنده و گیرنده.

پسوند بسته SR/RR. اگر اطلاعات اضافی در مورد فرستنده یا گیرنده وجود داشته باشد که باید به طور مرتب ارسال شود، می توان یک بخش افزونه برای بسته های SR و RR پروتکل RTCP تعریف کرد.

با استفاده از SDES نمایه ممکن است اولویت های نسبی را برای موارد RTCP SDES برای انتقال یا حذف تعریف کند (به بخش 4.2.2 مراجعه کنید). نحو یا معنای جایگزین برای یک عبارت CNAME (بخش 4.4.1). قالب مورد LOC (بخش 4.4.5)؛ معناشناسی و استفاده از بند NOTE (بخش 4.4.7) و بندهای جدید SDES که باید در IANA ثبت شوند.

ایمنی. یک نمایه ممکن است تعریف کند که برنامه‌ها از کدام سرویس‌ها و الگوریتم‌های امنیتی باید استفاده کنند و ممکن است کنترل استفاده از آنها را فراهم کند (بند 7).

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

پروتکل زیربنایی انتقال بسته های RTP ممکن است نیاز به استفاده از یک شبکه زیربنایی خاص یا پروتکل لایه انتقال داشته باشد.

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

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

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

11. پروفایل RTP برای کنفرانس صوتی و تصویری با حداقل کنترل

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

11.1. فرمت های بسته RTP و RTCP و پارامترهای پروتکل

این بخش شامل توضیحات تعدادی از مواردی است که می توان آنها را در یک پروفایل تعریف یا تغییر داد.

سرتیتر بسته اطلاعاتی RTP. استفاده شده فرمت استانداردهدر ثابت بسته های اطلاعاتی RTP (یک بیت توکن).

انواع ترافیک مقادیر استاتیک برای انواع ترافیک در بخش های 11.3 و 11.4 تعریف شده است.

پسوندهای هدر بسته اطلاعاتی RTP. هیچ فیلد ثابت اضافی به سربرگ های بسته اطلاعاتی RTP پیوست نشده است.

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

انواع بسته های RTCP هیچ نوع بسته RTCP اضافی در این مشخصات پروفایل تعریف نشده است.

فاصله گزارش RTCP هنگام محاسبه بازه گزارش RTCP، باید از ثابت های پیشنهادی در RFC 1889 استفاده شود.

پسوندهای بسته SR/RR. برنامه های افزودنی برای بسته های RTCP SR و RR تعریف نشده اند.

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

ایمنی. سرویس های امنیتی پیش فرض RTP نیز به صورت پیش فرض با این نمایه تعریف می شوند.

تطبیق رمز و کلید. رمز عبور وارد شده توسط کاربر با استفاده از الگوریتم MD5 به یک خلاصه 16 octet تبدیل می شود. یک کلید N-bit از خلاصه با استفاده از N بیت اول آن به دست می آید. در نظر گرفته شده است که رمز عبور فقط شامل حروف ASCII، اعداد، خط تیره و فاصله باشد تا احتمال خرابی هنگام انتقال رمزهای عبور از طریق تلفن، فکس، تلکس یا ایمیل کاهش یابد. ممکن است قبل از رمز عبور، مشخصات الگوریتم رمزگذاری وجود داشته باشد. هر کاراکتری تا اولین اسلش رو به جلو (کد ASCII 0x2f) به عنوان نام الگوریتم رمزگذاری گرفته می شود. اگر اسلش رو به جلو وجود نداشته باشد، الگوریتم رمزگذاری پیش فرض DES-CBC است.

رمز عبور وارد شده توسط کاربر قبل از اعمال الگوریتم بسته شدن به شکل متعارف خود تبدیل می شود. برای انجام این کار، رمز عبور با استفاده از رمزگذاری UTF-8 همانطور که در ضمیمه P ISO/IEC 10646-1:1993 تعریف شده است، به مجموعه کاراکتر ISO 10646 تبدیل می‌شود (کاراکترهای ASCII نیازی به تبدیل ندارند). فاصله ها در ابتدا و انتهای رمز عبور حذف می شوند. دو یا چند فضا با یک فاصله (ASCII یا UTF-8 0x20) جایگزین می شوند. همه حروف به حروف کوچک تبدیل می شوند

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

انطباق حمل و نقل نگاشت استاندارد RTP و RTCP برای انتقال آدرس های لایه استفاده می شود.

کپسوله سازی. کپسوله سازی بسته های RTP تعریف نشده است.

11.2. ثبت انواع ترافیک

این پروفایل تعریف می کند انواع استانداردکدهای مورد استفاده با RTP سایر انواع رمزگذاری باید قبل از استفاده در IANA ثبت شوند. هنگام ثبت یک نوع کدگذاری جدید، اطلاعات زیر باید ارائه شود:

نام کنوانسیون نوع کدگذاری و فرکانس ساعت مُهر زمان RTP (اسامی کنوانسیون باید سه یا چهار کاراکتر باشد تا در صورت لزوم یک نمایش فشرده ارائه شود).
نشانی از اینکه چه کسی حق تغییر نوع رمزگذاری را دارد (به عنوان مثال، ISO، CCITT/ITU، سایر سازمان های استاندارد بین المللی، یک کنسرسیوم، یک شرکت خاص یا گروهی از شرکت ها).
هر پارامتر عملیاتی؛
پیوندهایی به توضیحات موجود از الگوریتم رمزگذاری، مانند (به ترتیب اولویت) RFC، مقاله منتشر شده، ثبت اختراع، گزارش فنی، کد منبع کدک، یا کتاب مرجع؛
برای انواع رمزگذاری خصوصی، اطلاعات تماس ( آدرس پستیو آدرس ایمیل)
مقدار برای نشان دادن نوع ترافیک این نمایه، در صورت لزوم (به زیر مراجعه کنید).
توجه داشته باشید که همه انواع رمزگذاری برای استفاده با RTP نیازی به تخصیص استاتیک ندارند. برای ایجاد یک نگاشت پویا بین مقدار نوع ترافیک (PT) در محدوده 96 تا 127 و نوع رمزگذاری، می توان از "موازی غیر RTP" که در این مقاله پوشش داده نشده است استفاده کرد.
فضای موجود مقادیر برای انواع ترافیک بسیار کوچک است. انواع ترافیک جدید فقط در صورتی به صورت ایستا (دائمی) اختصاص داده می شود که شرایط زیر رعایت شود:
کدگذاری در تا اندازه زیادیعلاقه مند به جامعه اینترنتی؛
مزایای قابل مقایسه با رمزگذاری‌های موجود را ارائه می‌دهد و/یا برای قابلیت همکاری با سیستم‌های کنفرانس یا چندرسانه‌ای موجود و پرکاربرد مورد نیاز است.
توضیحات برای ایجاد رمزگشا کافی است.

11.3. کدگذاری صوتی

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

ساعت RTP مورد استفاده در هنگام تولید مهر زمانی RTP مستقل از تعداد کانال ها و نوع کدگذاری است. برابر است با تعداد دوره های نمونه برداری در ثانیه. برای کدگذاری کانال N (استریو، چهارگانه و غیره)، هر دوره نمونه برداری (مثلاً 1/8000 ثانیه) N نمونه تولید می کند. تعداد کلنمونه های تولید شده در ثانیه برابر است با حاصل ضرب نرخ نمونه و تعداد کانال ها.

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

ل - چپ؛
r - راست؛
ج - مرکزی؛
S - محیطی؛
F - جلویی؛
R - عقب.

تعداد کانال ها	نام سیستم	شماره کانال
تعداد کانال ها	نام سیستم	1	2	3	4	5	6
2	استریو	ل	r
3		ل	r	ج
4	چهار	fl	Fr	Rl	Rr
4		ل	ج	r	اس
5		fl	Fr	Fc	Sl	پدر
6		ل	ال سی	ج	r	rc	اس

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

نرخ نمونه باید از انواع مختلف انتخاب شود: 8000، 11025، 16000، 22050، 24000، 32000، 44100 و 48000 هرتز (کامپیوترهای مکینتاش دارای نرخ نمونه بومی 22254.54، 2000، 170، 2000 و 22254.54 و 112 می باشند که می توان آنها را تبدیل کرد. کیفیت با پرش چهار یا دو نمونه در یک قاب 20 میلی‌ثانیه). با این حال، اکثر الگوریتم های کدگذاری صوتی برای مجموعه محدودتری از نرخ نمونه تعریف شده اند. گیرنده ها باید برای دریافت صدای چند کاناله آماده باشند، اما می توانند مونو را نیز انتخاب کنند.

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

در کدگذاری های مبتنی بر نمونه، هر نمونه سیگنال با تعداد ثابتی از بیت ها نشان داده می شود. در داده های صوتی فشرده، کدهای نمونه فردی ممکن است از مرزهای هشتگانه عبور کنند. مدت زمان سیگنال ارسال شده در بسته صوتی با تعداد نمونه های موجود در بسته تعیین می شود.

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

الگوریتم کدگذاری مبتنی بر فریم، یک بلوک صوتی با طول ثابت را به بلوک داده فشرده دیگری تبدیل می‌کند، که معمولاً دارای طول ثابت است. برای رمزگذاری های مبتنی بر فریم، فرستنده ممکن است چندین فریم را در یک پیام واحد ترکیب کند.

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

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

روی میز. 3 مقادیر انواع ترافیک (PT) تعریف شده توسط این پروفایل برای سیگنال های صوتی، نمادهای آنها و ویژگی های فنی اصلی الگوریتم های کدگذاری را نشان می دهد.

11.4. رمزگذاری ویدیو

روی میز. 4 مقادیر انواع کدگذاری (PT)، نمادهای الگوریتم های کدگذاری و ویژگی های فنی الگوریتم های کدگذاری ویدیویی تعریف شده توسط این نمایه و همچنین مقادیر PT اختصاص نیافته، رزرو شده و به صورت پویا را نشان می دهد.

مقادیر نوع ترافیک در محدوده 96 تا 127 را می توان به صورت پویا از طریق پروتکل کنترل کنفرانس تعیین کرد که در این مقاله به آن پرداخته نشده است. به عنوان مثال، دایرکتوری نشست ممکن است مشخص کند که برای یک جلسه معین، نوع ترافیک 96 نشان دهنده کدگذاری PCMU، کانال دوگانه در 8000 هرتز است. محدوده نوع ترافیک با علامت "رزرو شده" استفاده نمی شود تا بسته های پروتکل RTCP و RTP به طور قابل اعتمادی قابل تشخیص باشند. .

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

برنامه های صوتی که از این نمایه استفاده می کنند، حداقل باید بتوانند انواع ترافیک 0 (PCMU) و 5 (DVI4) را ارسال و دریافت کنند. این امکان قابلیت همکاری بدون مذاکره فرمت را فراهم می کند.

11.5. واگذاری بندر

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

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

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

12. فهرست اصطلاحات و اختصارات استفاده شده

ASCII (کد استاندارد آمریکایی برای تبادل اطلاعات) - آمریکایی کد استانداردبرای تبادل اطلاعات کد هفت رقمی برای نمایندگی اطلاعات متنیبا تغییرات فردی در اکثر موارد استفاده می شود سیستم های محاسباتی
CBC (زنجیره سازی بلوک رمز) - زنجیره ای از بلوک های رمزگذاری شده، حالت استاندارد رمزگذاری داده DES
CELP (پیش‌بینی خطی تحریک‌شده با کد) - نوعی کدگذاری صوتی با استفاده از پیش‌بینی خطی تحریک‌شده با کد
CNAME (نام متعارف) - نام متعارف
CSRC (منبع کمک کننده) - منبع گنجانده شده است. منبع جریان بسته RTP که به جریان ترکیبی تولید شده توسط میکسر RTP کمک می کند. میکسر فهرستی از شناسه‌های SSRC از منابعی را که در شکل‌گیری این بسته مشارکت داشته‌اند، در سربرگ بسته RTP وارد می‌کند. این لیست لیست CSRC نامیده می شود. مثال: میکسر شناسه‌های شرکت‌کنندگان در کنفرانس تلفنی را که در حال حاضر صحبت می‌کنند، که صداهای صوتی آنها ترکیب شده و در ایجاد بسته خروجی استفاده شده است، ارسال می‌کند و گیرنده را به منبع فعلی پیام‌ها نشان می‌دهد، حتی اگر همه بسته‌های صدا حاوی شناسه SSRC یکسان باشند (مانند به عنوان میکسر)
DES (استاندارد رمزگذاری داده ها) - استاندارد رمزگذاری داده ها
IANA (Internet Assigned Numbers Authority) - Internet Assigned Numbers Authority
IMA (انجمن چند رسانه ای تعاملی) - انجمن چند رسانه ای تعاملی
IP (پروتکل اینترنت) - پروتکل اینترنت، پروتکل لایه شبکه، پروتکل دیتاگرام. به بسته ها اجازه می دهد در مسیر رسیدن به مقصد از چندین شبکه عبور کنند
IPM (IP Multicast) - چندپخشی با استفاده از پروتکل IP
LD-CELP (پیش‌بینی خطی برانگیخته با تاخیر کم) - یک الگوریتم کدگذاری گفتار با استفاده از پیش‌بینی خطی تحریک‌شده با کد با تاخیر کم
LPC (کدگذاری پیش بینی خطی) - کدگذاری پیش بینی خطی
NTP (پروتکل زمان شبکه) - یک پروتکل زمان شبکه، شمارش معکوس در ثانیه نسبت به ساعت صفر در 1 ژانویه 1900 است. قالب کامل مهر زمانی NTP یک عدد نقطه ثابت بدون علامت 64 بیتی با یک قسمت صحیح در 32 بیت اول و یک قسمت کسری در 32 بیت آخر است. در برخی موارد، نمایش فشرده تری استفاده می شود که در آن فقط 32 بیت میانی از قالب کامل گرفته شده است: 16 بیت پایین قسمت عدد صحیح و 16 بیت بالا از قسمت کسری.
RPE/LTP (تحریک پالس باقیمانده / پیش بینی طولانی مدت) - الگوریتم کدگذاری سیگنال گفتار با تحریک پالس تفاضلی و پیش بینی طولانی مدت
RTCP (پروتکل کنترل در زمان واقعی) - پروتکل کنترل ارتباط در زمان واقعی
RTP (پروتکل حمل و نقل در زمان واقعی) - پروتکل حمل و نقل در زمان واقعی
SSRC (منبع همگام سازی) - منبع همگام سازی. منبع جریان بسته RTP، شناسایی شده توسط شناسه عددی SSRC 32 بیتی که در هدر RTP، بدون توجه به آدرس شبکه، حمل می شود. همه بسته‌هایی که منبع زمان‌بندی یکسانی دارند، از فاصله زمانی یکسان و فضای شماره توالی یکسانی استفاده می‌کنند، به طوری که گیرنده بسته‌ها را برای پخش با استفاده از منبع زمان‌بندی گروه‌بندی می‌کند. مثال منبع همگام سازی: فرستنده جریانی از بسته ها که از منبع سیگنالی مانند میکروفون، دوربین فیلمبرداری یا میکسر RTP دریافت می شود. منبع ساعت ممکن است در طول زمان قالب داده ها را تغییر دهد، مانند کدگذاری صدا. شناسه SSRC یک مقدار انتخابی تصادفی است که در یک جلسه RTP خاص در سطح جهانی منحصر به فرد در نظر گرفته می شود. یک شرکت کننده در کنفرانس راه دور نیازی به استفاده از شناسه SSRC یکسان برای تمام جلسات RTP در یک جلسه چند رسانه ای ندارد. تجمیع شناسه SSRC از طریق پروتکل RTCP ارائه می شود. اگر یک شرکت‌کننده در یک جلسه RTP، به عنوان مثال از چندین دوربین، چندین جریان تولید کند، هر جریان باید توسط یک SSRC جداگانه شناسایی شود.
TCP (پروتکل کنترل انتقال) یک پروتکل لایه انتقال است که در ارتباط با پروتکل IP استفاده می شود.
UDP (User Datagram Protocol) یک پروتکل لایه انتقال بدون ایجاد ارتباط منطقی است. UDP فقط ارسال یک بسته را به یک یا چند ایستگاه در شبکه فراهم می کند. بررسی صحت و اطمینان از یکپارچگی (تحویل مطمئن) انتقال داده ها در سطح بالاتری انجام می شود.
ADPCM - مدولاسیون کد پالس دیفرانسیل تطبیقی
جیتر (جتر) - لرزش، انحراف فاز یا فرکانس سیگنال. در رابطه با تلفن IP - بی نظمی تاخیر دیتاگرام در شبکه
ZPD - پیوند انتقال داده (سطح دوم مدل مرجع تعامل سیستم های باز)
IVS - اطلاعاتی شبکه های کامپیوتر
میکسر (میکسر) - یک سیستم میانی که بسته های RTP را از یک یا چند منبع دریافت می کند، احتمالاً قالب داده را تغییر می دهد، بسته ها را در یک بسته RTP جدید ترکیب می کند و سپس آن را ارسال می کند. از آنجایی که چندین منبع سیگنال عموماً هماهنگ نیستند، میکسر زمان بندی جریان های مؤلفه را تصحیح می کند و زمان بندی خود را برای جریان ترکیبی ایجاد می کند. بنابراین، تمام بسته‌های داده‌ای که توسط میکسر تولید می‌شوند، به‌عنوان منبع ساعت خود میکسر شناسایی می‌شوند.
مانیتور (مانیتور) - برنامه ای که بسته های RTCP ارسال شده توسط شرکت کنندگان در جلسه RTP، به ویژه گزارش های دریافت را دریافت می کند و کیفیت فعلی خدمات را برای کنترل توزیع، تشخیص خطا و آمار بلند مدت ارزیابی می کند. به طور معمول، عملکرد یک مانیتور به برنامه های مورد استفاده در جلسه بستگی دارد، اما مانیتور همچنین می تواند یک برنامه کاربردی جداگانه باشد که در غیر این صورت استفاده نمی شود، بسته های اطلاعات RTP را ارسال یا دریافت نمی کند. به چنین برنامه هایی مانیتور شخص ثالث می گویند.
ITU-T - بخش استانداردسازی مخابرات اتحادیه بین المللی مخابرات
سیستم پایانی - برنامه ای که محتوای ارسال شده در بسته های RTP را تولید می کند و/یا محتوای بسته های RTP دریافتی را مصرف می کند. یک سیستم پایانی ممکن است به عنوان یک یا چند منبع ساعت (اما معمولا فقط یک) در هر جلسه RTP عمل کند.
بسته RTCP - یک بسته کنترلی متشکل از یک قسمت هدر ثابت، مشابه هدر بسته های اطلاعاتی پروتکل RTP، و به دنبال آن عناصر ساختاری، که بسته به نوع بسته RTCP متفاوت است. به طور معمول، چندین بسته RTCP با هم به عنوان یک بسته RTCP متعدد در یک بسته پروتکل زیربنایی منتقل می شوند. این توسط فیلد طول در هدر ثابت هر بسته RTCP ارائه می شود
بسته RTP - یک واحد داده پروتکل متشکل از یک هدر RTP ثابت، احتمالا لیست خالیشامل منابع، برنامه های افزودنی و ترافیک است. به طور معمول، یک بسته پروتکل اساسی حاوی یک بسته RTP است، اما ممکن است چندین بسته وجود داشته باشد
پورت یک انتزاع است که توسط پروتکل های لایه انتقال برای تمایز بین مقصدهای متعدد در یک کامپیوتر میزبان استفاده می شود. پورت با شماره آن مشخص می شود. بنابراین، شماره پورت عددی است که برنامه خاصی را که داده های ارسال شده برای آن در نظر گرفته شده است، مشخص می کند. این عدد به همراه اطلاعاتی در مورد اینکه کدام پروتکل (مثلاً TCP یا UDP) در لایه بالایی استفاده می‌شود، در میان سایر اطلاعات سرویس در دیتاگرام‌های ارسال شده از طریق اینترنت موجود است. انتخابگرهای حمل و نقل (TSEL) که توسط لایه انتقال OSI استفاده می شود معادل پورت ها هستند
پروفایل (پروفایل) - مجموعه ای از پارامترهای پروتکل های RTP و RTCP برای یک کلاس از برنامه ها که ویژگی های عملکرد آنها را تعیین می کند. نمایه استفاده از فیلدهای بیت نشانگر و نوع ترافیک را در هدر بسته داده RTP، انواع ترافیک، پسوندهای هدر بسته داده RTP، 16 بیت اول پسوند هدر بسته داده RTP، انواع بسته RTCP، فاصله گزارش RTCP، SR تعریف می کند. پسوند بسته /RR، از بسته‌ها، خدمات و الگوریتم‌های SDES برای اطمینان از امنیت ارتباطات و ویژگی‌های استفاده از پروتکل زیربنایی استفاده کنید.
جلسه RTP (جلسه RTP) - ارتباط چند شرکت کننده که از طریق پروتکل RTP در تعامل هستند. برای هر شرکت کننده، یک جلسه با یک جفت آدرس انتقال مقصد مشخص (یک آدرس شبکه به اضافه یک جفت پورت برای RTP و RTCP) تعریف می شود. جفت آدرس حمل و نقل مقصد ممکن است برای همه شرکت کنندگان مشترک باشد (مانند مورد IPM) یا ممکن است برای هر یک متفاوت باشد (یک آدرس شبکه مجزا و یک جفت پورت مشترک، مانند ارتباطات دو طرفه). در یک جلسه چند رسانه ای، هر نوع ترافیک در یک جلسه RTP جداگانه با بسته های RTCP خاص خود حمل می شود. جلسات RTP چندپخشی متفاوت است اعداد مختلفجفت پورت و/یا آدرس های چندپخشی مختلف
وسایل غیر RTP - پروتکل ها و مکانیسم هایی که ممکن است علاوه بر RTP برای ارائه یک سرویس قابل قبول مورد نیاز باشد. مخصوصاً برای کنفرانس چند رسانه ای، یک برنامه کنترل کنفرانس ممکن است آدرس های چندپخشی و کلیدهای رمزگذاری را توزیع کند، درباره الگوریتم رمزگذاری مورد استفاده مذاکره کند، و نگاشت پویا بین مقادیر نوع ترافیک RTP و فرمت های ترافیکی که آنها نمایش می دهند (فرمت هایی که از پیش تعریف شده ندارند) تعیین کند. مقدار). نوع ترافیک). برای کاربردهای ساده نیز می توان استفاده کرد پست الکترونیکیا پایگاه داده کنفرانس
مترجم (مترجم) - یک سیستم میانی که بسته های RTP را بدون تغییر شناسه منبع همگام سازی ارسال می کند. نمونه هایی از مترجم ها: دستگاه هایی که بدون اختلاط رمزگذاری می کنند، تکثیرکننده های چند طرفه یا دو جهته، برنامه های لایه کاربردی در فایروال ها
آدرس حمل و نقل - ترکیبی از آدرس شبکه و شماره پورت که یک نقطه پایانی انتقال را مشخص می کند، مانند آدرس IP و شماره پورت UDP. بسته ها از آدرس حمل و نقل مبدأ به آدرس حمل و نقل مقصد منتقل می شوند
ترافیک RTP - داده های چند رسانه ای منتقل شده در یک بسته پروتکل RTP، مانند نمونه های صوتی یا داده های ویدئویی فشرده شده
PSTN - شبکه های تلفن سوئیچ شده عمومی

عصر بخیر!

به طور خلاصه: سیستم مانیتورینگ مجموعه ای است که در حالت غیر نفوذی به شماره 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 اندازه گیری کرد؟

از توضیحات می توان دریافت که از نقطه نظر اندازه گیری کیفیت در بسته 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 را شناسایی کنیم؟

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

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

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

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

سوال باقی می ماند: چگونه 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 دوربین متصل کرد.

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

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

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

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

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

پروتکل حمل و نقل بلادرنگ 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 را مشخص می کند.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

همانطور که در بالا ذکر شد، یک بسته 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 فهرست شده‌اند که نشان‌دهنده درستی از منابع پیام برای گیرنده است.

3.2. جلسات RTP

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

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

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

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

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

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

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

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

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

3.4. پسوند هدر RTP

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

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

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

1999
2000

هنگام استفاده از پروتکل RTP، دو پورت برای ارتباط باز می شود. یکی برای پخش رسانه (شماره پورت زوج) و دیگری برای سیگنالینگ داده ( بازخوردبرای QoS و کنترل جریان رسانه) - RTCP. مقادیر شماره پورت هاردکد نیستند، اساساً به برنامه مورد استفاده بسیار وابسته هستند.

RTP - پروتکل حمل و نقل بلادرنگ RTCP - پروتکل کنترل بلادرنگ به صورت اختیاری شامل اطلاعاتی در مورد موارد زیر است: از دست دادن بسته بافر بافر "Jitter" تأخیر قدرت سیگنال سنجه کیفیت سیگنال (سنجه های کیفیت تماس) فقدان بازگشت اکو و غیره. RTCP XR - گزارش‌های توسعه‌یافته پروتکل کنترل بلادرنگ همه فیلدهای توصیف شده برای RTCP plus: R Factor - پارامتر کیفیت سیگنال MOS - پارامتر کیفیت سیگنال و موارد دیگر
بسته های حاوی صدای ارسال شده با استفاده از RTP/RTCP برای پروتکلی که برای تماس های VOIP استفاده می شود، ارسال می شود. پروتکل RTP می تواند داده های رسانه شناسایی شده توسط پارامترهایی را که توسط سازمان ثبت شده است انتقال دهد: "مرجع شماره های اختصاص داده شده به اینترنت" - IANA. آنها همچنین برای فیلدهایی در پروتکل که در پیام ها استفاده می شوند استفاده می شوند.

برخی از مقادیر فیلد محموله:

PT	نام کدک	صوتی/تصویری (A/V)	نرخ ساعت (هرتز)	تعداد کانال	سند	0	PCMU	آ	8000	1	RFC3551	3	کلوب جی اس ام	آ	8000	1	RFC3551	4	G723	آ	8000	1	کومار	5	DVI4	آ	8000	1	RFC3551	6	DVI4	آ	16000	1	RFC3551	7	LPC	آ	8000	1	RFC3551	8	PCMA	آ	8000	1	RFC3551	9	G722	آ	8000	1	RFC3551	10	L16	آ	44100	2	RFC3551	11	L16	آ	44100	1	RFC3551	12	QCELP	آ	8000	1	-	13	CN	آ	8000	1	RFC3389	14	MPA	آ	90000		RFC3551، RFC2250	15	G728	آ	8000	1	RFC3551	16	DVI4	آ	11025	1	دی پول	17	DVI4	آ	22050	1	دی پول	18	G729	آ	8000	1		19	رزرو شده است	آ				20	اختصاص داده نشده	آ				21	اختصاص داده نشده	آ				22	اختصاص داده نشده	آ				23	اختصاص داده نشده	آ				24	اختصاص داده نشده	V				25	CelB	V	90000		RFC2029	26	JPEG	V	90000		RFC2435	27	اختصاص داده نشده	V				28	n.v.	V	90000		RFC3551	29	اختصاص داده نشده	V				30	اختصاص داده نشده	V				31	H261	V	90000		RFC2032	32	MPV	V	90000		RFC2250	33	MP2T	AV	90000		RFC2250	34	H263	V	90000		زو	35--71	اختصاص داده نشده				72--76	برای جلوگیری از درگیری برای RTCP رزرو شده است				RFC3550	77--95	اختصاص داده نشده				77--95	پویا			RFC3551

IANA: پارامترهای پروتکل RTP ثبت شده: http://www.iana.org/assignments/rtp-parameters

پروتکل RTP و ترجمه آدرس IP (NAT)

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

مقالات

RTCP XR عملکرد VoIP Network World را در تاریخ 11/17/03 اندازه گیری می کند

اسناد RFC:

IETF RFC 3550 RTP: پروتکل حمل و نقل برای برنامه های بلادرنگ. IETF RFC 3611 RTP Control Extended Reports (RTCP XR) نمایه RTP IETF RFC 1890 برای کنفرانس صوتی و تصویری با حداقل کنترل. فشرده سازی هدر IETF RFC 2508 IP/UDP/RTP برای لینک های کم سرعت. فشرده سازی RTP (CRTP) تقویت شده IETF RFC 3545 برای پیوندهایی با تأخیر بالا، از دست دادن بسته های بالا و ارسال مجدد مکرر.