Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой
  • ARP
  • Пнр
  • OSPF
  • Туннели
    • L2TP
  • PPP
  • MAC
    • Ethernet
    • Вай-фай
    • DSL
    • ISDN
    • FDDI
  • более...
  • v
  • т
  • е

В режиме реального времени Transport Protocol ( RTP ) является сетевым протоколом для доставки аудио и видео по сетям IP . RTP используется в системах связи и развлечений, которые включают потоковое мультимедиа , например в телефонии , в приложениях для видеоконференций, включая WebRTC , телевизионных услугах и функциях push-to-talk на основе Интернета .

RTP обычно работает по протоколу дейтаграмм пользователя (UDP). RTP используется вместе с протоколом управления RTP (RTCP). В то время как RTP передает потоки мультимедиа (например, аудио и видео), RTCP используется для мониторинга статистики передачи и качества обслуживания (QoS) и помогает синхронизировать несколько потоков. RTP является одной из технических основ передачи голоса по IP и в этом контексте часто используется в сочетании с протоколом сигнализации, таким как протокол инициации сеанса (SIP), который устанавливает соединения по сети.

Протокол RTP был разработан Рабочей группой аудио-видео транспорта Инженерной группы Интернета (IETF) и впервые опубликован в 1996 году как RFC  1889, который затем был заменен RFC 3550 в 2003 году. 

Обзор [ править ]

RTP предназначен для конца в конец , в режиме реального времени передачи потокового мультимедиа . Протокол предоставляет возможности для компенсации джиттера и обнаружения потери пакетов и доставки с нарушением порядка , которые часто встречаются, особенно во время передачи UDP в IP-сети. RTP позволяет передавать данные в несколько пунктов назначения через многоадресную IP-рассылку . [1] RTP считается основным стандартом для передачи аудио / видео в IP-сетях и используется с соответствующим профилем и форматом полезной нагрузки. [2] Дизайн RTP основан на архитектурном принципе, известном как формирование кадров на уровне приложений.где функции протокола реализуются в приложении, а не в стеке протоколов операционной системы .

Приложения потоковой передачи мультимедиа в реальном времени требуют своевременной доставки информации и часто могут допускать некоторую потерю пакетов для достижения этой цели. Например, потеря пакета в аудиоприложении может привести к потере доли секунды аудиоданных, которую можно сделать незаметной с помощью подходящих алгоритмов маскирования ошибок . [3] Протокол управления передачей (TCP), хотя стандартизирована для использования протокола RTP, [4] , обычно не используется в приложениях , RTP , поскольку TCP способствует надежности за своевременностью. Вместо этого большинство реализаций RTP построено на протоколе пользовательских дейтаграмм (UDP). [3]Другие транспортные протоколы , предназначенные специально для мультимедийных сеансов являются SCTP [5] и DCCP , [6] , хотя, как в 2012 году , они не являются широко используются. [7]

Протокол RTP был разработан рабочей группой Audio / Video Transport организации по стандартизации IETF. RTP используется вместе с другими протоколами, такими как H.323 и RTSP . [2] Спецификация RTP описывает два протокола: RTP и RTCP. RTP используется для передачи мультимедийных данных, а RTCP используется для периодической отправки управляющей информации и параметров QoS. [8]

Протокол передачи данных RTP передает данные в реальном времени. Информация, предоставляемая этим протоколом, включает отметки времени (для синхронизации), порядковые номера (для обнаружения потери пакетов и переупорядочения) и формат полезной нагрузки, который указывает закодированный формат данных. [9] Протокол управления RTCP используется для обратной связи по качеству обслуживания (QoS) и синхронизации между медиапотоками. Пропускная способность трафика RTCP по сравнению с RTP мала, обычно около 5%. [9] [10]

Сеансы RTP обычно инициируются между взаимодействующими одноранговыми узлами с использованием протокола сигнализации, такого как H.323, протокол инициации сеанса (SIP), RTSP или Jingle ( XMPP ). Эти протоколы могут использовать протокол описания сеанса для определения параметров сеансов. [11]

Сеанс RTP устанавливается для каждого мультимедийного потока. Аудио- и видеопотоки могут использовать отдельные сеансы RTP, что позволяет приемнику выборочно принимать компоненты определенного потока. [12] Схема RTP и RTCP не зависит от транспортного протокола. Приложения обычно используют UDP с номерами портов в непривилегированном диапазоне (от 1024 до 65535). [13] поток Протокол управления передачи (SCTP , ) и дейтаграммы перегрузки протокол управления (DCCP) могут быть использованы , когда надежный транспортный протокол желательно. Спецификация RTP рекомендует четные номера портов для RTP и использование следующего нечетного номера порта для соответствующего сеанса RTCP. [14] : 68Один порт может использоваться для RTP и RTCP в приложениях, которые мультиплексируют протоколы. [15]

RTP используется мультимедийными приложениями в реальном времени, такими как передача голоса по IP , аудио по IP , WebRTC и телевидение по Интернет-протоколу.

Профили и форматы полезной нагрузки [ править ]

Основная статья: форматы полезной нагрузки RTP

RTP предназначен для передачи множества мультимедийных форматов, что позволяет разрабатывать новые форматы без пересмотра стандарта RTP. С этой целью информация, требуемая конкретным приложением протокола, не включается в общий заголовок RTP. Для каждого класса приложений (например, аудио, видео) RTP определяет профиль и связанные форматы полезной нагрузки . [8] Каждая реализация RTP в конкретном приложении требует спецификации профиля и формата полезной нагрузки. [14] : 71

Профиль определяет кодеки, используемые для кодирования данных полезной нагрузки, и их сопоставление с кодами формата полезной нагрузки в поле протокола Payload Type (PT) заголовка RTP. Каждый профиль сопровождается несколькими спецификациями формата полезной нагрузки, каждая из которых описывает транспортировку определенных закодированных данных. [2] Примерами форматов полезной нагрузки аудио являются G.711 , G.723 , G.726 , G.729 , GSM , QCELP , MP3 и DTMF , а примерами полезных данных видео - H.261 , H.263 , H. 264 , H.265 и MPEG-1/ MPEG-2 . [16] Отображение потоков аудио / видео MPEG-4 в пакеты RTP указано в RFC 3016 , а полезные данные видео H.263 описаны в RFC 2429 . [17]  

Примеры профилей RTP включают:

  • Профиль RTP для аудио и видео конференций с минимальным контролем ( RFC 3551 ) определяет набор статических заданий типа полезной нагрузки, а также динамический механизм для отображения между форматом полезной нагрузки и значением СТ с помощью Session Description Protocol (SDP). 
  • Протокол защищенной передачи в реальном времени (SRTP) ( RFC 3711 ) определяет профиль RTP, который предоставляет криптографические службы для передачи данных полезной нагрузки. [18] 
  • Экспериментальный профиль управляющих данных для RTP (RTP / CDP) для межмашинной связи. [19]

Заголовок пакета [ править ]

Пакеты RTP создаются на прикладном уровне и передаются транспортному уровню для доставки. Каждая единица медиаданных RTP, созданная приложением, начинается с заголовка пакета RTP.

Заголовок пакета RTP
СмещенияОктет0123
ОктетБит [а]0123456789101112131415161718192021 год2223242526 год2728 год293031 год
00ВерсияпИксCCMPTПоследовательность чисел
432Отметка времени
864Идентификатор SSRC
1296Идентификаторы CSRC
...
12 + 4 × СС96 + 32 × ССИдентификатор заголовка расширения, зависящего от профиляДлина заголовка расширения
16 + 4 × СС128 + 32 × CCЗаголовок расширения
...

Заголовок RTP имеет минимальный размер 12 байтов. После заголовка могут присутствовать необязательные расширения заголовка. За ним следует полезная нагрузка RTP, формат которой определяется конкретным классом приложения. [20] Поля в заголовке следующие:

  • Версия : (2 бита) Указывает версию протокола. Текущая версия - 2. [21]
  • P (Padding) : (1 бит) Используется, чтобы указать, есть ли дополнительные байты заполнения в конце пакета RTP. Заполнение может использоваться для заполнения блока определенного размера, например, в соответствии с требованиями алгоритма шифрования. Последний байт заполнения содержит количество добавленных байтов заполнения (включая его самого). [14] : 12 [21]
  • X (Расширение) : (1 бит) Указывает на наличие заголовка расширения между заголовком и данными полезной нагрузки. Заголовок расширения зависит от приложения или профиля. [21]
  • CC (счетчик CSRC) : (4 бита). Содержит количество идентификаторов CSRC (определенных ниже), следующих за SSRC (также определенным ниже). [14] : 12
  • M (Маркер) : (1 бит) Сигнализация, используемая на уровне приложения в зависимости от профиля. Если он установлен, это означает, что текущие данные имеют особое отношение к приложению. [14] : 13
  • PT (Тип полезной нагрузки) : (7 бит). Указывает формат полезной нагрузки и, таким образом, определяет ее интерпретацию приложением. Значения зависят от профиля и могут быть присвоены динамически. [22]
  • Порядковый номер : (16 бит) Порядковый номер увеличивается для каждого отправленного пакета данных RTP и должен использоваться получателем для обнаружения потери пакета [1] и для обеспечения доставки вне очереди . Начальное значение порядкового номера должно быть рандомизировано, чтобы затруднить атаки с использованием известного открытого текста на безопасный транспортный протокол в реальном времени . [14] : 13
  • Отметка времени : (32 бита) Используется приемником для воспроизведения полученных отсчетов в соответствующее время и интервал. Когда присутствует несколько медиапотоков, отметки времени могут быть независимыми в каждом потоке. [b] Детализация синхронизации зависит от приложения. Например, аудиоприложение, которое производит выборку данных каждые 125 мкс (8 кГц, обычная частота дискретизации в цифровой телефонии), будет использовать это значение в качестве своего тактового разрешения. Для видеопотоков обычно используется частота 90 кГц. Детализация часов - это одна из деталей, которая указывается в профиле RTP для приложения. [23]
  • SSRC : (32 бита) Идентификатор источника синхронизации однозначно определяет источник потока. Источники синхронизации в рамках одного сеанса RTP будут уникальными. [14] : 15
  • CSRC : (32 бита каждый, количество записей указывается полем счетчика CSRC ) Идентификаторы вспомогательных источников перечисляют вспомогательные источники для потока, который был сгенерирован из нескольких источников. [14] : 15
  • Расширение заголовка : (необязательно, присутствие указывается полем Extension ) Первое 32-битное слово содержит идентификатор профиля (16 бит) и спецификатор длины (16 бит), который указывает длину расширения в 32-битных единицах, исключая 32 бита заголовка расширения. Далее следуют данные заголовка расширения. [14] : 18

Дизайн приложения [ править ]

Функциональное мультимедийное приложение требует других протоколов и стандартов, используемых вместе с RTP. Такие протоколы, как SIP, Jingle , RTSP, H.225 и H.245 , используются для инициирования, управления и завершения сеанса. Другие стандарты, такие как H.264, MPEG и H.263, используются для кодирования данных полезной нагрузки, как указано в соответствующем профиле RTP. [24]

Отправитель RTP захватывает мультимедийные данные, затем кодирует, кадры и передает их в виде пакетов RTP с соответствующими отметками времени и увеличивающимися отметками времени и порядковыми номерами. Отправитель устанавливает поле типа полезной нагрузки в соответствии с согласованием соединения и используемым профилем RTP. Приемник RTP обнаруживает отсутствующие пакеты и может переупорядочить пакеты. Он декодирует мультимедийные данные в пакетах в соответствии с типом полезной нагрузки и представляет поток своему пользователю. [24]

Документы стандартов [ править ]

  • RFC  3550 , стандарт 64, RTP: транспортный протокол для приложений реального времени
  • RFC  3551 , Standard 65, профиль RTP для аудио- и видеоконференций с минимальным контролем
  • RFC  4855 , Регистрация типа носителя для форматов полезной нагрузки RTP
  • RFC  4856 , Регистрация типа носителя для форматов полезной нагрузки в профиле RTP для аудио- и видеоконференций
  • RFC  7656 , Таксономия семантики и механизмов для источников протокола передачи в реальном времени (RTP)
  • RFC  3190 , формат полезной нагрузки RTP для 12-битного аудио DAT и 20- и 24-битного линейно дискретизированного аудио
  • RFC  6184 , формат полезной нагрузки RTP для видео H.264
  • RFC  3640 , Формат полезной нагрузки RTP для транспортировки элементарных потоков MPEG-4
  • RFC  6416 , формат полезной нагрузки RTP для аудиовизуальных потоков MPEG-4
  • RFC  2250 , формат полезной нагрузки RTP для видео MPEG1 / MPEG2
  • RFC  4175 , формат полезной нагрузки RTP для несжатого видео
  • RFC  6295 , формат полезной нагрузки RTP для MIDI
  • RFC  4696 , Руководство по внедрению RTP MIDI
  • RFC  7587 , формат полезной нагрузки RTP для речевого и аудиокодека Opus
  • RFC  7798 , формат полезной нагрузки RTP для высокоэффективного кодирования видео (HEVC)

См. Также [ править ]

  • Протокол потоковой передачи в реальном времени
  • Реальный перенос данных
  • ZRTP

Заметки [ править ]

  1. ^ Биты отсортированы от наиболее значимого до наименее значимого; битовое смещение 0 - это самый старший бит первого октета. Октеты передаются в сетевом порядке . Порядок передачи битов зависит от среды.
  2. ^ RFC 7273 предоставляет средства для сигнализации взаимосвязи между тактовыми частотами мультимедиа различных потоков. 

Ссылки [ править ]

  1. ^ a b Дэниел Харди (2002). Сеть . De Boeck Université. п. 298 .
  2. ^ a b c Perkins 2003 , стр. 55
  3. ^ a b Perkins 2003 , стр. 46
  4. ^ RFC 4571 
  5. ^ Фаррел, Адриан (2004). Интернет и его протоколы . Морган Кауфманн. п. 363. ISBN. 978-1-55860-913-6.
  6. ^ Ozaktas, Haldun M .; Левент Онурал (2007). ТРЕХМЕРНОЕ ТЕЛЕВИДЕНИЕ . Springer. п. 356. ISBN. 978-3-540-72531-2.
  7. ^ Хогг, Скотт. "А как насчет протокола передачи управления потоком (SCTP)?" . Сетевой мир . Проверено 4 октября 2017 .
  8. ^ a b Ларри Л. Петерсон (2007). Компьютерные сети . Морган Кауфманн. п. 430 . ISBN 978-1-55860-832-0.
  9. ^ a b Perkins 2003 , стр. 56
  10. Перейти ↑ Peterson 2007 , p. 435
  11. ^ RFC 4566 : SDP: протокол описания сеанса , М. Хэндли, В. Якобсон, К. Перкинс, IETF (июль 2006 г.) 
  12. ^ Zurawski, Ричард (2004). «Протоколы RTP, RTCP и RTSP» . Справочник по промышленным информационным технологиям . CRC Press. С.  28–7 . ISBN 978-0-8493-1985-3.
  13. ^ Коллинз, Дэниел (2002). «Передача голоса с использованием IP». Передача голоса операторского класса по IP . McGraw-Hill Professional. С.  47 . ISBN 978-0-07-136326-6.
  14. ^ a b c d e f g h i RFC 3550 
  15. ^ Мультиплексирование данных RTP и пакетов управления на одном порте . IETF. Апрель 2010 г. doi : 10.17487 / RFC5761 . RFC 5761 . Проверено 21 ноября 2015 года .
  16. Перейти ↑ Perkins 2003 , p. 60
  17. ^ Чоу, Филип А .; Михаэла ван дер Шаар (2007). Мультимедиа по IP и беспроводным сетям . Академическая пресса. С.  514 . ISBN 978-0-12-088480-3.
  18. Перейти ↑ Perkins 2003 , p. 367
  19. ^ Breese, Финли (2010). Последовательная связь через RTP / CDP . Совет директоров - Книги по запросу. стр.  [1] . ISBN 978-3-8391-8460-8.
  20. Перейти ↑ Peterson 2007 , p. 430
  21. ^ a b c Петерсон 2007 , стр. 431
  22. Перейти ↑ Perkins 2003 , p. 59
  23. ^ Петерсон, стр. 432
  24. ^ a b Perkins 2003 , стр. 11–13
  • Перкинс, Колин (2003). RTP . Эддисон-Уэсли. ISBN 978-0-672-32249-5.
  • Петерсон, Ларри Л .; Дэви, Брюс С. (2007). Компьютерные сети (4-е изд.). Морган Кауфманн. ISBN 978-0-12-374013-7.

Дальнейшее чтение [ править ]

  • «RTP» . Справочник по сетевым протоколам . Javvin Technologies. 2005. ISBN 978-0-9740945-2-6.

Внешние ссылки [ править ]

  • Страница RTP Хеннинга Шульцринна (включая FAQ )
  • GNU ccRTP
  • JRTPLIB, библиотека C ++ RTP
  • Управляемая агрегация мультимедиа : реализация RTP / RTCP, совместимая с .NET C # RFC, написанная в полностью управляемом коде.
  • «RTP» , широкополосные сети , Министерство человеческих ресурсов, Индия, 2008 г.