Транспортный протокол реального времени
| Протокол связи | |
| Аббревиатура | RTP |
|---|---|
| Цель | Доставка аудио и видео |
| Разработчик(и) | Рабочая группа по транспортировке аудио-видео IETF |
| Введение | январь 1996 г |
| На основе | Сетевой голосовой протокол [1] |
| RFC(ы) | RFC 1889 , 3550 , 3551 |
| Набор интернет-протоколов |
|---|
| Прикладной уровень |
| Транспортный уровень |
| Интернет-слой |
| Слой связи |
Транспортный протокол реального времени ( RTP ) — это сетевой протокол для доставки аудио и видео по IP-сетям . RTP используется в системах связи и развлечений, которые включают в себя потоковую передачу мультимедиа , таких как телефония , приложения для видеотелеконференций, включая WebRTC , телевизионные услуги и веб- функции «нажми и говори» .
RTP обычно работает через протокол пользовательских дейтаграмм (UDP). RTP используется вместе с протоколом управления RTP (RTCP). В то время как RTP передает медиапотоки (например, аудио и видео), RTCP используется для мониторинга статистики передачи и качества обслуживания (QoS) и способствует синхронизации нескольких потоков. RTP является одной из технических основ передачи голоса по IP и в этом контексте часто используется в сочетании с протоколом сигнализации , таким как протокол инициации сеанса (SIP), который устанавливает соединения по сети.
RTP был разработан рабочей группой по транспортировке аудио-видео Инженерной рабочей группы Интернета (IETF) и впервые опубликован в 1996 году как RFC 1889, который затем был заменен RFC 3550 в 2003 году. [2]
Обзор [ править ]
Исследования аудио и видео в сетях с коммутацией пакетов начались в начале 1970-х годов. Рабочая группа по проектированию Интернета (IETF) опубликовала RFC 741 в 1977 году и начал разработку RTP в 1992 году. [1] и продолжит разработку протокола объявления сеанса (SAP), протокола описания сеанса (SDP) и протокола инициирования сеанса (SIP).
RTP предназначен для сквозной в режиме реального времени передачи потокового мультимедиа . Протокол предоставляет средства компенсации дрожания и обнаружения потери пакетов и доставки с нарушением порядка , которые являются обычными, особенно во время передачи UDP в IP-сети. RTP позволяет передавать данные нескольким адресатам посредством многоадресной IP-адресации . [3] RTP считается основным стандартом передачи аудио/видео в IP-сетях и используется со связанным профилем и форматом полезной нагрузки. [4] Конструкция RTP основана на архитектурном принципе, известном как кадрирование уровня приложения , где функции протокола реализуются в приложении, а не в стеке протоколов операционной системы .
в реальном времени Приложения потоковой передачи мультимедиа требуют своевременной доставки информации и часто могут допустить некоторую потерю пакетов для достижения этой цели. Например, потеря пакета в аудиоприложении может привести к потере доли секунды аудиоданных, которую можно сделать незаметной с помощью подходящих алгоритмов маскирования ошибок . [5] Протокол управления передачей (TCP), хотя и стандартизирован для использования RTP, [6] обычно не используется в приложениях RTP, поскольку TCP предпочитает надежность своевременности. Вместо этого большинство реализаций RTP построено на протоколе пользовательских дейтаграмм (UDP). [5] Другими транспортными протоколами, специально разработанными для мультимедийных сеансов, являются SCTP. [7] и ДЦКП , [8] хотя по состоянию на 2012 год [update]они не получили широкого распространения. [9]
RTP был разработан рабочей группой по транспортировке аудио/видео организации по стандартизации IETF. RTP используется в сочетании с другими протоколами, такими как H.323 и RTSP . [4] Спецификация RTP описывает два протокола: RTP и RTCP. RTP используется для передачи мультимедийных данных, а RTCP используется для периодической отправки управляющей информации и параметров QoS. [10]
Протокол передачи данных RTP передает данные в реальном времени. Информация, предоставляемая этим протоколом, включает метки времени (для синхронизации), порядковые номера (для обнаружения потери пакетов и изменения порядка) и формат полезной нагрузки, который указывает закодированный формат данных. [11] Протокол управления RTCP используется для обратной связи по качеству обслуживания (QoS) и синхронизации между медиапотоками. Пропускная способность трафика RTCP по сравнению с RTP невелика, обычно около 5%. [11] [12]
Сеансы RTP обычно инициируются между взаимодействующими узлами с использованием протокола сигнализации, такого как H.323, протокола инициирования сеанса (SIP), RTSP или Jingle ( XMPP ). Эти протоколы могут использовать протокол описания сеанса для указания параметров сеансов. [13]
Сеанс RTP устанавливается для каждого мультимедийного потока. Аудио- и видеопотоки могут использовать отдельные сеансы RTP, что позволяет получателю выборочно принимать компоненты определенного потока. [14] Конструкция RTP и RTCP не зависит от транспортного протокола. Приложения чаще всего используют UDP с номерами портов в непривилегированном диапазоне (от 1024 до 65535). [15] Протокол передачи управления потоком (SCTP) и протокол управления перегрузкой дейтаграмм (DCCP) могут использоваться, когда требуется надежный транспортный протокол. Спецификация RTP рекомендует четные номера портов для RTP и использование следующего нечетного номера порта для связанного сеанса RTCP. [16] : 68 Один порт можно использовать для RTP и RTCP в приложениях, мультиплексирующих протоколы. [17]
RTP используется мультимедийными приложениями реального времени, такими как передача голоса по IP , аудио по IP , WebRTC и телевидение по интернет-протоколу .
Профили и форматы полезной нагрузки [ править ]
RTP предназначен для передачи множества мультимедийных форматов, что позволяет разрабатывать новые форматы без пересмотра стандарта RTP. С этой целью информация, требуемая конкретным приложением протокола, не включается в общий заголовок RTP. Для каждого класса приложений (например, аудио, видео) RTP определяет профиль и связанные с ним форматы полезной нагрузки . [10] Для каждого экземпляра RTP в конкретном приложении требуются спецификации профиля и формата полезной нагрузки. [16] : 71
Профиль определяет кодеки, используемые для кодирования данных полезной нагрузки и их сопоставление с кодами формата полезной нагрузки в поле протокола Тип полезной нагрузки (PT) заголовка RTP. Каждый профиль сопровождается несколькими спецификациями формата полезной нагрузки, каждая из которых описывает транспортировку определенных закодированных данных. [4] Примерами форматов аудиополезных данных являются G.711 , G.723 , G.726 , G.729 , GSM , QCELP , MP3 и DTMF , а примерами видеополезных данных являются H.261 , H.263 , H.264 , H. .265 и MPEG-1 / MPEG-2 . [18] Сопоставление аудио/видео потоков MPEG-4 с пакетами RTP указано в Полезные данные видео RFC 3016 и H.263 описаны в разделе РФК 2429 . [19]
Примеры профилей RTP включают в себя:
- Профиль RTP для аудио- и видеоконференций с минимальным контролем ( RFC 3551 ) определяет набор статических назначений типов полезных данных и динамический механизм сопоставления между форматом полезных данных и значением PT с использованием протокола описания сеанса (SDP).
- Безопасный транспортный протокол реального времени (SRTP) ( RFC 3711 ) определяет профиль RTP, который предоставляет криптографические услуги для передачи полезных данных. [20]
- Экспериментальный профиль управляющих данных для RTP (RTP/CDP) для межмашинной связи. [21]
Заголовок пакета [ править ]
Пакеты RTP создаются на уровне приложений и передаются на транспортный уровень для доставки. Каждая единица мультимедийных данных RTP, созданная приложением, начинается с заголовка пакета RTP.
| Смещения | Октет | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Октет | Кусочек [а] | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | ||
| 0 | 0 | Версия | П | Х | СС | М | ПТ | Порядковый номер | |||||||||||||||||||||||||||
| 4 | 32 | Временная метка | |||||||||||||||||||||||||||||||||
| 8 | 64 | идентификатор SSRC | |||||||||||||||||||||||||||||||||
| 12 | 96 | Идентификаторы CSRC ... | |||||||||||||||||||||||||||||||||
| 12+4×CC | 96+32×CC | Идентификатор заголовка расширения, специфичный для профиля | Длина заголовка расширения | ||||||||||||||||||||||||||||||||
| 16+4×CC | 128+32×CC | Заголовок расширения ... | |||||||||||||||||||||||||||||||||
Заголовок RTP имеет минимальный размер 12 байт. После заголовка могут присутствовать дополнительные расширения заголовка. Далее следует полезная нагрузка RTP, формат которой определяется конкретным классом приложения. [22] Поля в заголовке следующие:
- Версия : (2 бита) Указывает версию протокола. Текущая версия 2. [23]
- P (Заполнение) : (1 бит). Используется для указания наличия дополнительных байтов заполнения в конце пакета RTP. Заполнение может использоваться для заполнения блока определенного размера, например, как того требует алгоритм шифрования. Последний байт заполнения содержит количество добавленных байтов заполнения (включая его самого). [16] : 12 [23]
- X (Расширение) : (1 бит) Указывает наличие заголовка расширения между заголовком и данными полезной нагрузки. Заголовок расширения зависит от приложения или профиля. [23]
- CC (счетчик CSRC) : (4 бита) Содержит количество идентификаторов CSRC (определенных ниже), следующих за SSRC (также определенных ниже). [16] : 12
- M (Маркер) : (1 бит) Сигнализация, используемая на уровне приложения в зависимости от профиля. Если он установлен, это означает, что текущие данные имеют особое значение для приложения. [16] : 13
- PT (тип полезной нагрузки) : (7 бит) Указывает формат полезной нагрузки и, таким образом, определяет ее интерпретацию приложением. Значения зависят от профиля и могут назначаться динамически. [24]
- Порядковый номер : (16 бит). Порядковый номер увеличивается для каждого отправленного пакета данных RTP и должен использоваться получателем для обнаружения потери пакета. [3] и обеспечить доставку вне заказа . Начальное значение порядкового номера должно быть рандомизировано, чтобы затруднить атаки с использованием известного открытого текста на безопасный транспортный протокол реального времени . [16] : 13
- Временная метка : (32 бита) Используется приемником для воспроизведения полученных образцов в соответствующее время и интервал. Когда присутствует несколько медиапотоков, временные метки могут быть независимыми в каждом потоке. [б] Детализация времени зависит от приложения. Например, аудиоприложение, которое производит выборку данных каждые 125 мкс (8 кГц, обычная частота дискретизации в цифровой телефонии), будет использовать это значение в качестве разрешения тактовой частоты. Видеопотоки обычно используют тактовую частоту 90 кГц. Детализация часов — это одна из деталей, указанная в профиле RTP для приложения. [25]
- SSRC : (32 бита) Идентификатор источника синхронизации однозначно идентифицирует источник потока. Источники синхронизации в рамках одного сеанса RTP будут уникальными. [16] : 15
- CSRC : (каждый по 32 бита, количество записей указывается полем счетчика CSRC ). Идентификаторы источников, вносящих вклад, перечисляют источники, вносящие вклад в поток, который был сгенерирован из нескольких источников. [16] : 15
- Расширение заголовка : (необязательно, наличие указывается полем расширения ). Первое 32-битное слово содержит идентификатор профиля (16 бит) и спецификатор длины (16 бит), который указывает длину расширения в 32-битных единицах, исключая 32 бита заголовка расширения. Далее следуют данные заголовка расширения. [16] : 18
Дизайн приложения [ править ]
Функциональное мультимедийное приложение требует других протоколов и стандартов, используемых вместе с RTP. Такие протоколы, как SIP, Jingle , RTSP, H.225 и H.245, используются для инициации, управления и завершения сеанса. Другие стандарты, такие как H.264, MPEG и H.263, используются для кодирования данных полезной нагрузки, как указано в соответствующем профиле RTP. [26]
Отправитель RTP захватывает мультимедийные данные, затем кодирует их, формирует и передает их в виде пакетов RTP с соответствующими временными метками и увеличивающимися временными метками и порядковыми номерами. Отправитель устанавливает поле типа полезных данных в соответствии с согласованием соединения и используемым профилем RTP. Получатель RTP обнаруживает недостающие пакеты и может изменить их порядок. Он декодирует медиаданные в пакетах в соответствии с типом полезной нагрузки и представляет поток своему пользователю. [26]
Документы по стандартам [ править ]
- 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 7164 , RTP и дополнительные секунды
- RFC 7587 , формат полезной нагрузки RTP для Opus речевого и аудиокодека
- RFC 7798 , Формат полезной нагрузки RTP для высокоэффективного кодирования видео (HEVC)
См. также [ править ]
Примечания [ править ]
- ^ Биты упорядочены от наиболее значимого к наименее значимому; Смещение бита 0 — это старший бит первого октета. Октеты передаются в сетевом порядке . Порядок передачи битов зависит от среды.
- ^ RFC 7273 предоставляет средства для сигнализации взаимосвязи между часами мультимедиа разных потоков.
Ссылки [ править ]
- ↑ Перейти обратно: Перейти обратно: а б Перкинс 2003 , с. 6.
- ^ Райт, Гэвин. «Что такое транспортный протокол реального времени (RTP)?» . ТехТаржет . Проверено 10 ноября 2022 г.
- ↑ Перейти обратно: Перейти обратно: а б Дэниел Харди (2002). Сеть . Университет Де Бек. п. 298 .
- ↑ Перейти обратно: Перейти обратно: а б с Перкинс 2003 , с. 55
- ↑ Перейти обратно: Перейти обратно: а б Перкинс 2003 , с. 46
- ^ RFC 4571
- ^ Фаррел, Адриан (2004). Интернет и его протоколы . Морган Кауфманн. п. 363. ИСБН 978-1-55860-913-6 .
- ^ Озактас, Халдун М.; Левент Онурал (2007). ТРЕХМЕРНОЕ ТЕЛЕВИДЕНИЕ . Спрингер. п. 356. ИСБН 978-3-540-72531-2 .
- ^ Хогг, Скотт. «А как насчет протокола передачи управления потоком (SCTP)?» . Сетевой мир . Архивировано из оригинала 30 августа 2014 года . Проверено 4 октября 2017 г.
- ↑ Перейти обратно: Перейти обратно: а б Ларри Л. Петерсон (2007). Компьютерные сети . Морган Кауфманн. п. 430 . ISBN 978-1-55860-832-0 .
- ↑ Перейти обратно: Перейти обратно: а б Перкинс 2003 , с. 56
- ^ Петерсон и Дэви 2007 , с. 435
- ^ RFC 4566 : SDP: протокол описания сеанса , М. Хэндли, В. Джейкобсон, К. Перкинс, IETF (июль 2006 г.)
- ^ Журавски, Ричард (2004). «Протоколы RTP, RTCP и RTSP» . Справочник по промышленным информационным технологиям . ЦРК Пресс. стр. 28–7 . ISBN 978-0-8493-1985-3 .
- ^ Коллинз, Дэниел (2002). «Передача голоса с помощью IP». Голосовая связь операторского класса по IP . МакГроу-Хилл Профессионал. стр. 47 . ISBN 978-0-07-136326-6 .
- ↑ Перейти обратно: Перейти обратно: а б с д и ж г час я РФК 3550
- ^ Мультиплексирование данных RTP и пакетов управления на одном порту . IETF. Апрель 2010 г. doi : 10.17487/RFC5761 . РФК 5761 . Проверено 21 ноября 2015 г.
- ^ Перкинс 2003 , с. 60
- ^ Чоу, Филип А.; Михаэла ван дер Шаар (2007). Мультимедиа по IP и беспроводным сетям . Академическая пресса. стр. 514 . ISBN 978-0-12-088480-3 .
- ^ Перкинс 2003 , с. 367
- ^ Бриз, Финли (2010). Последовательная связь через RTP/CDP . Совет директоров - Книги по запросу. стр. [1] . ISBN 978-3-8391-8460-8 .
- ^ Петерсон и Дэви 2007 , с. 430
- ↑ Перейти обратно: Перейти обратно: а б с Петерсон и Дэви 2007 , с. 431
- ^ Перкинс 2003 , с. 59
- ^ Петерсон, с. 432
- ↑ Перейти обратно: Перейти обратно: а б Перкинс 2003 , стр. 11–13.
- Перкинс, Колин (2003). RTP: аудио и видео для Интернета . Аддисон-Уэсли. ISBN 978-0-672-32249-5 .
- Петерсон, Ларри Л.; Дэви, Брюс С. (2007). Компьютерные сети (4-е изд.). Морган Кауфманн. ISBN 978-0-12-374013-7 .
Дальнейшее чтение [ править ]
- «РТП» . Справочник по сетевым протоколам . Джаввин Технологии. 2005. ISBN 978-0-9740945-2-6 .
Внешние ссылки [ править ]
- Страница RTP Хеннинга Шульцринна (включая часто задаваемые вопросы )
- GNU CCRTP
- JRTPLIB, библиотека RTP C++.
- Управляемая агрегация мультимедиа. Архивировано 9 января 2018 г. на Wayback Machine : .NET C# RFC-совместимая реализация RTP/RTCP, написанная на полностью управляемом коде.
- «RTP» , Широкополосные сети , Министерство человеческих ресурсов, Индия, 2008 г., заархивировано из оригинала 18 ноября 2021 г.