RTP

Протокол RTP (англ. Real-time Transport Protocol) працює на транспортному рівні і використовується при передачі трафіку реального часу. Протокол був розроблений Audio-Video Transport Working Group в IETF і вперше опублікований в 1996 році як RFC 1889, і замінений в RFC 3550 в 2003 році.

Протокол RTP переносить у своєму заголовку дані, необхідні для відновлення голосу та відео на приймальному вузлі, а також дані про тип кодування інформації (JPEG, MPEG і т. п.). В заголовку цього протоколу, зокрема, передаються мітка і номер пакету. Ці параметри дозволяють при мінімальних затримки визначити порядок і час декодування кожного пакета, а також інтерполювати втрачені пакети.

RTP не має стандартного зарезервованого номера порту. Єдине обмеження полягає в тому, що з'єднання проходить з використанням парного номери, а наступний непарний номер використовується для зв'язку з протоколом RTCP. Той факт, що RTP використовує динамічно назначаємі адреси портів, створює йому труднощі для проходження міжмережевих екранів, для обходу цієї проблеми, як правило, використовується STUN-сервер.

Встановлення і розрив з'єднання не входить в список можливостей 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 біт дробова). Структура пакету

Структура пакета

+ Біти 0-1 2 3 4-7 8 9-15 16-31 0 Ver. P X CC M PT Порядковий номер 32 Мітка часу 64 SSRC-идентификатор 96 … CSRC-идентификатори … 96+(CC×32) Додатковий заголовок (необов'язковий), містить довжину блоку даних — «AHL» 96+(CC×32) + (X×(AHL+16))   Дані

Ver. (2 біта) вказує версію протоколу. Поточна версія - 2. P (один біт) використовується у випадках, коли RTP-пакет доповнюється порожніми байтами на кінці. X (один біт) використовується для вказівки розширень протоколу, задіяних в пакеті. CC (4 біти) містить кількість CSRC-ідентифікаторів, наступних за постійним заголовком. M (один біт) використовується на рівні програми і визначається профілем. Якщо це поле встановлено, то дані пакету мають якесь особливе значення для програми. P T (7 біт) вказує формат payload і визначає її інтерпретацію додатком. SSRC вказує джерело синхронізації. CC (4 біта)містить кількість CSRC-ідентифікаторів, наступних за постійним заголовком". 'M"' (один біт) використовується на рівні програми і визначається профілем. Якщо це поле встановлено, то дані пакету мають якесь особливе значення для програми. "'PT"' (7 біт) вказує формат payload і визначає її інтерпретацію додатком."'SSRC"' вказує джерело синхронізації.

Специіикація RTP

• STD 64. RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. July 2003.
• STD 65. RTP Profile for Audio and Video Conferences with Minimal Control. H. Schulzrinne, S. Casner. July 2003.

Посилання

• http://book.itep.ru/4/44/rtp_4492.htm
• http://cdo.bseu.by/library/ibs1/net_l/tcp_ip/net/rtp.htm
• http://www.masters.donntu.edu.ua/2004/kita/schitnikova/library/3.htm