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 протоколом).


1. Опис протоколу

RTP був розроблений як протокол реального часу, з кінця в кінець (end-to-end), для передачі потокових даних. В протокол закладена можливість компенсації джиттера і детектування порушення послідовності пакетів даних - типових подій при передачі через IP-мережі. RTP підтримує передачу даних для декількох адресатів через Multicast. [1] RTP розглядається як основний стандарт для передачі голосу й відео в IP-мережах і спільно з кодеками.

Додатки, що формують потоки реального часу, вимагають своєчасної доставки інформації і для досягнення цієї мети можуть допустити деяку втрату пакетів. Наприклад, втрата пакета в аудіо-додатку може призвести до частки секунди тиші, яка може бути непомітна при використанні підходящих алгоритмів приховування помилок. [2] Протокол TCP, хоча і стандартизований для передачі RTP, [3] як правило не використовується в RTP-додатках, так як надійність передачі в TCP формує тимчасові затримки. Замість цього, більшість реалізацій RTP базується на UDP. Крім цього, існують інші специфікації для транспортних протоколів SCTP і DCCP, але вони мало поширені. [4] [5]


2. Компоненти протоколу

Специфікація RTP описує два під-протоколу:

  • Протокол передачі даних, RTP, який взаємодіє з передачею даних реального часу. Інформація, яка надається за допомогою цього протоколу включає тайм-стемп (для синхронізації), послідовний номер (для детектування втрати і дублювання пакетів) і формат корисного навантаження, який визначає формат кодування даних.
  • Протокол контролю, RTCP, використовуваний для визначення якості обслуговування ( QOS), зворотного зв'язку та синхронізації між медіа-потоками. Займана смуга пропускання RTCP - мала у порівнянні з RTP, зазвичай близько 5%.
  • Керуючий сигнальний протокол, такий як SIP, H.323, MGCP або H.248. Сигнальні протоколи управляють відкриттям, модифікацією та закриттям RTP-сесій між пристроями і додатками реального часу.
  • Керуючий протокол опису медіа, такий як Session Description Protocol.

3. Сесії

RTP-сесія встановлюється для кожного потоку мультимедіа. Сесія складається з IP-адреси і пари портів для RTP і RTCP. Наприклад, аудіо і відео потоки будуть мати різні RTP-сесії, що дозволяють приймачу для цього виділити конкретний потік. [6] Порти, які утворюють сесію, зв'язуються один з одним засобами інших протоколів, таких як SIP (містить у своїх повідомленнях протокол SDP [7 ]) і RTSP (використовуючи SDP в методі Setup). У відповідності зі специфікацією, RTP не має стандартного зарезервованого номера порту. Єдине обмеження полягає в тому, що з'єднання проходить з використанням парного номера, а наступний непарний номер використовується для зв'язку по протоколу RTCP. RTP і RTCP зазвичай використовують непривілейованих UDP-порти (16k-32k), але можуть використовувати й інші протоколи, оскільки сам протокол RTP незалежний від транспортного рівня.


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

+ Біти 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),
if X == 1
Додатковий заголовок (необов'язковий), містить довжину блоку даних - "AHL"
96 + (CC 32)
+ (X (AHL +16))

Дані

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


5. Специфікація RTP