Протокол RTP (англ. Real-time Transport Protocol) працює на прикладному рівні і використовується при передачі аудіо і відеоданих через (IP мережі) в режимі реального часу. Протокол був розроблений Audio-Video Transport Working Group в IETF і вперше опублікований в 1996 році як RFC 1889, і замінений у RFC 3550 у 2003 році.
Протокол RTP переносить у своєму заголовку дані, необхідні для відновлення голосу та відео на приймальному вузлі, а також дані про тип кодування інформації (JPEG, MPEG і т. ін.). В заголовку цього протоколу, зокрема, передаються мітка і номер пакету. Ці параметри дозволяють при мінімальних затримках визначити порядок і час декодування кожного пакета, а також інтерполювати втрачені пакети.
RTP не має стандартного зарезервованого номера порту. Єдине обмеження полягає в тому, що з'єднання проходить з використанням парного номера порту, а наступний непарний номер використовується для зв'язку з протоколом RTCP. Той факт, що RTP використовує адреси портів що присвоюються динамічно, створює йому труднощі з проходженням міжмережевих екранів, для обходу цієї проблеми, як правило, використовується .
Встановлення і розрив з'єднання не входить в список можливостей RTP, такі дії виконуються сигнальним протоколом (наприклад, RTSP або SIP протоколом).
Визначення
- Поле даних RTP
- Інформація, яка пересилається в пакеті RTP, наприклад, фрагменти звуку або стислі відео дані.
- Пакет RTP
- Інформаційний пакет, що містить фіксований заголовок. Один пакет нижнього транспортного рівня, наприклад UDP, зазвичай містить один RTP-пакет, але ця вимога не є обов'язковою. Поле джерел інформації може бути порожнім.
- Пакет RTCP
- Керівний пакет, що містить фіксований заголовок подібний до RTP, за яким йдуть структурні елементи, які залежать від типу RTCP-пакету. Зазвичай кілька RTCP-пакетів надсилаються як складова RTCP-пакету, вкладена в дейтаграму нижчого рівня.
- Транспортна адреса
- Комбінація мережевої адреси та порту, яка ідентифікує кінцеву точку каналу (наприклад, IP-адреса і UDP порт). Пакети йдуть від транспортної адреси відправника до транспортної адреси одержувача.
- Сесія RTP
- Період з моменту встановлення групи учасників RTP-обміну до її зникнення. Для кожного з учасників сесія визначається конкретною парою транспортних адрес (мережева адреса і номери портів для RTP і RTCP). Транспортна адреса місця призначення може бути загальною для всіх учасників сесії. Допускається реалізація декількох сесій для кожного з учасників одночасно.
- Джерело синхронізації (SSRC)
- Джерело потоку RTP-пакетів, визначається 32-бітним числовим SSRC-ідентифікатором, який записується в заголовок RTP-пакету і не залежить від мережної адреси. Всі пакети від джерела синхронізації утворюють частину з ідентичною тимчасовою прив'язкою і нумерацією. Ці дані використовуються стороною що приймає при відтворенні. Джерелами синхронізації можуть служити первинні джерела сигналу (мікрофони або відеокамери), а також RTP-змішувачі. SSRC-ідентифікатор являє собою випадкове число, яке є унікальним для даної RTP-сесії. Учасник сесії не повинен використовувати один і той же SSRC-ідентифікатор для всіх RTP-сесій мультимедійного набору. Якщо учасник формує кілька потоків в рамках однієї RTP-сесії (наприклад, від декількох відеокамер), кожен учасник повинен бути забезпечений унікальним SSRC-ідентифікатором.
- Інформаційне джерело CSRC (contributing source)
- Джерело потоку RTP-пакетів, котре робить внесок у загальний потік, що формується RTP-змішувачем. Змішувач вставляє список SSRC-ідентифікаторів, які ідентифікують парціальні джерела, в заголовок RTP-пакетів. Цей список називається CSRC-списком. Прикладом програми може бути аудіоконференція, де змішувач відзначає всіх людей, чий голос породжує вихідні пакети. Це дозволяє стороні що приймає ідентифікувати мовця, хоча всі пакети мають один і той же SSRC-ідентифікатор.
- Кінцева система
- Програма, яка генерує або сприймає дані, які посилають у вигляді RTP-пакетів. Кінцева система може виступати як одне або декілька джерел синхронізації для конкретної сесії.
- Змішувач
- Проміжна система, яка отримує RTP-пакети від одного або декількох джерел, при необхідності змінює їх формат, об'єднує і пересилає їх адресатам. Через те, що тимчасова прив'язка вхідних пакетів може відрізнятися, змішувач здійснює їх синхронізацію і генерує свій власний потік RTP-пакетів. Таким чином увесь зміст пакетів синхронізується змішувачем.
- Транслятор
- Проміжна система, яка переадресує RTP-пакети, не змінюючи їх ідентифікатори джерела синхронізації. Такі пристрої використовуються для перетворення системи кодування, переходу від мультикаст- до традиційної -адресації або при роботі з Firewall.
- Монітор
- Додаток, який отримує RTCP-пакети, надіслані учасниками RTP-сесії, зокрема діагностичні повідомлення, проводить оцінку стану зв'язку, накопичує довгострокову статистику обміну.
Всі цілочисельні поля передаються згідно з мережевим порядком, тобто старший байт слідує за першим (big-endian). Порядок передачі докладно описаний у роботі [3]. Якщо не обумовлено зворотного всі цифрові константи є десятковими. Всі поля заголовка вирівнюються своїми природними кордонами, тобто. 16-бітові поля мають парне зміщення, а 32-бітні мають адреси, кратні 4. Октети-заповнювачі містять нулі.
Абсолютний час видається з допомогою часових позначок згідно з форматом NTP (network time protocol), який характеризує час у секундах від початку доби (UTC) 1 січня 1900 [4]. Мітка часу NTP повної точності визначається 64-бітовим числом з фіксованою комою без знаку. Цілочисельна частина задається першими 32 бітами, а дробова частина останніми. У деяких полях, де припустимо компактніше подання, використовуються тільки середні 32 біти (16 бітів цілочисельна частина і 16 бітів дробова).
Структура пакета
|
Ver. (2 біти) вказує версію протоколу. Поточна версія - 2.
P (один біт) використовується у випадках, коли RTP-пакет доповнюється порожніми байтами на кінці.
X (один біт) використовується для зазначення розширень протоколу, залучених в пакеті.
CC (4 біти) містить кількість CSRC-ідентифікаторів, що йдуть за постійним заголовком.
M (один біт) використовується на рівні програми та визначається профілем. Якщо це поле встановлено, то дані пакету мають якесь особливе значення для програми.
PT (7 бітів) вказує формат payload і визначає її інтерпретацію додатком.
SSRC вказує джерело синхронізації.
Специфікація RTP
Посилання
- http://book.itep.ru/4/44/rtp_4492.htm [ 3 березня 2011 у Wayback Machine.]
- http://cdo.bseu.by/library/ibs1/net_l/tcp_ip/net/rtp.htm [ 21 квітня 2016 у Wayback Machine.]
Це незавершена стаття про комп'ютерні мережі. Ви можете проєкту, виправивши або дописавши її. |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Protokol RTP angl Real time Transport Protocol pracyuye na prikladnomu rivni i vikoristovuyetsya pri peredachi audio i videodanih cherez IP merezhi v rezhimi realnogo chasu Protokol buv rozroblenij Audio Video Transport Working Group v IETF i vpershe opublikovanij v 1996 roci yak RFC 1889 i zaminenij u RFC 3550 u 2003 roci Protokol RTP perenosit u svoyemu zagolovku dani neobhidni dlya vidnovlennya golosu ta video na prijmalnomu vuzli a takozh dani pro tip koduvannya informaciyi JPEG MPEG i t in V zagolovku cogo protokolu zokrema peredayutsya mitka i nomer paketu Ci parametri dozvolyayut pri minimalnih zatrimkah viznachiti poryadok i chas dekoduvannya kozhnogo paketa a takozh interpolyuvati vtracheni paketi RTP ne maye standartnogo zarezervovanogo nomera portu Yedine obmezhennya polyagaye v tomu sho z yednannya prohodit z vikoristannyam parnogo nomera portu a nastupnij neparnij nomer vikoristovuyetsya dlya zv yazku z protokolom RTCP Toj fakt sho RTP vikoristovuye adresi portiv sho prisvoyuyutsya dinamichno stvoryuye jomu trudnoshi z prohodzhennyam mizhmerezhevih ekraniv dlya obhodu ciyeyi problemi yak pravilo vikoristovuyetsya Vstanovlennya i rozriv z yednannya ne vhodit v spisok mozhlivostej RTP taki diyi vikonuyutsya signalnim protokolom napriklad RTSP abo SIP protokolom ViznachennyaPole danih RTP Informaciya yaka peresilayetsya v paketi RTP napriklad fragmenti zvuku abo stisli video dani Paket RTP Informacijnij paket sho mistit fiksovanij zagolovok Odin paket nizhnogo transportnogo rivnya napriklad UDP zazvichaj mistit odin RTP paket ale cya vimoga ne ye obov yazkovoyu Pole dzherel informaciyi mozhe buti porozhnim Paket RTCP Kerivnij paket sho mistit fiksovanij zagolovok podibnij do RTP za yakim jdut strukturni elementi yaki zalezhat vid tipu RTCP paketu Zazvichaj kilka RTCP paketiv nadsilayutsya yak skladova RTCP paketu vkladena v dejtagramu nizhchogo rivnya Transportna adresa Kombinaciya merezhevoyi adresi ta portu yaka identifikuye kincevu tochku kanalu napriklad IP adresa i UDP port Paketi jdut vid transportnoyi adresi vidpravnika do transportnoyi adresi oderzhuvacha Sesiya RTP Period z momentu vstanovlennya grupi uchasnikiv RTP obminu do yiyi zniknennya Dlya kozhnogo z uchasnikiv sesiya viznachayetsya konkretnoyu paroyu transportnih adres merezheva adresa i nomeri portiv dlya RTP i RTCP Transportna adresa miscya priznachennya mozhe buti zagalnoyu dlya vsih uchasnikiv sesiyi Dopuskayetsya realizaciya dekilkoh sesij dlya kozhnogo z uchasnikiv odnochasno Dzherelo sinhronizaciyi SSRC Dzherelo potoku RTP paketiv viznachayetsya 32 bitnim chislovim SSRC identifikatorom yakij zapisuyetsya v zagolovok RTP paketu i ne zalezhit vid merezhnoyi adresi Vsi paketi vid dzherela sinhronizaciyi utvoryuyut chastinu z identichnoyu timchasovoyu priv yazkoyu i numeraciyeyu Ci dani vikoristovuyutsya storonoyu sho prijmaye pri vidtvorenni Dzherelami sinhronizaciyi mozhut sluzhiti pervinni dzherela signalu mikrofoni abo videokameri a takozh RTP zmishuvachi SSRC identifikator yavlyaye soboyu vipadkove chislo yake ye unikalnim dlya danoyi RTP sesiyi Uchasnik sesiyi ne povinen vikoristovuvati odin i toj zhe SSRC identifikator dlya vsih RTP sesij multimedijnogo naboru Yaksho uchasnik formuye kilka potokiv v ramkah odniyeyi RTP sesiyi napriklad vid dekilkoh videokamer kozhen uchasnik povinen buti zabezpechenij unikalnim SSRC identifikatorom Informacijne dzherelo CSRC contributing source Dzherelo potoku RTP paketiv kotre robit vnesok u zagalnij potik sho formuyetsya RTP zmishuvachem Zmishuvach vstavlyaye spisok SSRC identifikatoriv yaki identifikuyut parcialni dzherela v zagolovok RTP paketiv Cej spisok nazivayetsya CSRC spiskom Prikladom programi mozhe buti audiokonferenciya de zmishuvach vidznachaye vsih lyudej chij golos porodzhuye vihidni paketi Ce dozvolyaye storoni sho prijmaye identifikuvati movcya hocha vsi paketi mayut odin i toj zhe SSRC identifikator Kinceva sistema Programa yaka generuye abo sprijmaye dani yaki posilayut u viglyadi RTP paketiv Kinceva sistema mozhe vistupati yak odne abo dekilka dzherel sinhronizaciyi dlya konkretnoyi sesiyi Zmishuvach Promizhna sistema yaka otrimuye RTP paketi vid odnogo abo dekilkoh dzherel pri neobhidnosti zminyuye yih format ob yednuye i peresilaye yih adresatam Cherez te sho timchasova priv yazka vhidnih paketiv mozhe vidriznyatisya zmishuvach zdijsnyuye yih sinhronizaciyu i generuye svij vlasnij potik RTP paketiv Takim chinom uves zmist paketiv sinhronizuyetsya zmishuvachem Translyator Promizhna sistema yaka pereadresuye RTP paketi ne zminyuyuchi yih identifikatori dzherela sinhronizaciyi Taki pristroyi vikoristovuyutsya dlya peretvorennya sistemi koduvannya perehodu vid multikast do tradicijnoyi adresaciyi abo pri roboti z Firewall Monitor Dodatok yakij otrimuye RTCP paketi nadislani uchasnikami RTP sesiyi zokrema diagnostichni povidomlennya provodit ocinku stanu zv yazku nakopichuye dovgostrokovu statistiku obminu Vsi cilochiselni polya peredayutsya zgidno z merezhevim poryadkom tobto starshij bajt sliduye za pershim big endian Poryadok peredachi dokladno opisanij u roboti 3 Yaksho ne obumovleno zvorotnogo vsi cifrovi konstanti ye desyatkovimi Vsi polya zagolovka virivnyuyutsya svoyimi prirodnimi kordonami tobto 16 bitovi polya mayut parne zmishennya a 32 bitni mayut adresi kratni 4 Okteti zapovnyuvachi mistyat nuli Absolyutnij chas vidayetsya z dopomogoyu chasovih poznachok zgidno z formatom NTP network time protocol yakij harakterizuye chas u sekundah vid pochatku dobi UTC 1 sichnya 1900 4 Mitka chasu NTP povnoyi tochnosti viznachayetsya 64 bitovim chislom z fiksovanoyu komoyu bez znaku Cilochiselna chastina zadayetsya pershimi 32 bitami a drobova chastina ostannimi U deyakih polyah de pripustimo kompaktnishe podannya vikoristovuyutsya tilki seredni 32 biti 16 bitiv cilochiselna chastina i 16 bitiv drobova Struktura paketa Biti 0 1 2 3 4 7 8 9 15 16 31 0 Ver P X CC M PT Poryadkovij nomer 32 Mitka chasu 64 SSRC identifikator 96 CSRC identifikatori 96 CC 32 Dodatkovij zagolovok neobov yazkovij mistit dovzhinu bloku danih AHL 96 CC 32 X AHL 16 Dani Ver 2 biti vkazuye versiyu protokolu Potochna versiya 2 P odin bit vikoristovuyetsya u vipadkah koli RTP paket dopovnyuyetsya porozhnimi bajtami na kinci X odin bit vikoristovuyetsya dlya zaznachennya rozshiren protokolu zaluchenih v paketi CC 4 biti mistit kilkist CSRC identifikatoriv sho jdut za postijnim zagolovkom M odin bit vikoristovuyetsya na rivni programi ta viznachayetsya profilem Yaksho ce pole vstanovleno to dani paketu mayut yakes osoblive znachennya dlya programi PT 7 bitiv vkazuye format payload i viznachaye yiyi interpretaciyu dodatkom SSRC vkazuye dzherelo sinhronizaciyi Specifikaciya RTPPosilannyahttp book itep ru 4 44 rtp 4492 htm 3 bereznya 2011 u Wayback Machine http cdo bseu by library ibs1 net l tcp ip net rtp htm 21 kvitnya 2016 u Wayback Machine Ce nezavershena stattya pro komp yuterni merezhi Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi