Протокол управления RTP

Протокол управления RTP
Протокол связи
Аббревиатура	RTCP
Цель	Оставить отзыв о качестве обслуживания
Разработчик(и)	Колумбийский университет
Введение	июль 2003 г .; 21 год назад
RFC(ы)	РФК 3550

Протокол управления RTP ( RTCP с двоичным кодированием ) — это протокол внеполосной сигнализации , который работает вместе с транспортным протоколом реального времени (RTP). Его базовые функции и структура пакетов определены в RFC 3550. RTCP предоставляет статистику и управляющую информацию для сеанса RTP. Он сотрудничает с RTP в доставке и упаковке мультимедийных данных, но сам не передает никаких мультимедийных данных.

Основная функция RTCP — обеспечить обратную связь о качестве обслуживания (QoS) при распространении мультимедиа путем периодической отправки статистической информации, такой как переданных октетов количество и пакетов, потеря пакетов , изменение задержки пакета и время двусторонней задержки участникам сети. потоковая мультимедийная сессия. Приложение может использовать эту информацию для управления параметрами качества обслуживания, возможно, путем ограничения потока или использования другого кодека .

Функции протокола

Обычно RTP отправляется на порт UDP с четным номером , а сообщения RTCP отправляются через порт с более высоким нечетным номером. ^[1]

Сам RTCP не предоставляет никаких методов шифрования потока или аутентификации. Такие механизмы могут быть реализованы, например, с помощью безопасного транспортного протокола реального времени (SRTP), определенного в RFC 3711.

RTCP предоставляет основные функции, которые, как ожидается, будут реализованы во всех сеансах RTP:

Основная функция RTCP — сбор статистики по аспектам качества распространения мультимедиа во время сеанса и передача этих данных медиаисточнику сеанса и другим участникам сеанса. Такая информация может использоваться источником для адаптивного кодирования мультимедиа ( кодек ) и обнаружения ошибок передачи. Если сеанс передается по многоадресной сети, это позволяет осуществлять ненавязчивый мониторинг качества сеанса.
RTCP предоставляет канонические идентификаторы конечной точки (CNAME) всем участникам сеанса. Хотя ожидается, что идентификатор источника (SSRC) потока RTP будет уникальным, мгновенная привязка идентификаторов источника к конечным точкам может измениться во время сеанса. CNAME устанавливает уникальную идентификацию конечных точек в экземпляре приложения (многократное использование медиа-инструментов) и для стороннего мониторинга.
Предоставление функций управления сеансом. RTCP — это удобный способ связи со всеми участниками сеанса, тогда как сам RTP им не является. RTP передается только медиа-источником.

Ожидается, что отчеты RTCP будут отправляться всеми участниками, даже в сеансе многоадресной рассылки, в котором могут участвовать тысячи получателей. Такой трафик будет увеличиваться пропорционально количеству участников. Таким образом, чтобы избежать перегрузки сети, протокол должен включать управление полосой пропускания сеанса. Это достигается за счет динамического управления частотой передачи отчетов. Использование полосы пропускания RTCP обычно не должно превышать 5% от общей пропускной способности сеанса. Кроме того, 25% пропускной способности RTCP должно всегда резервироваться для медиа-источников, чтобы в крупных конференциях новые участники могли получать идентификаторы CNAME отправителей без чрезмерной задержки.

Интервал отчетов RTCP рандомизирован, чтобы предотвратить непреднамеренную синхронизацию отчетов. Рекомендуемый минимальный интервал отчетов RTCP для каждой станции составляет 5 секунд. Станции не должны передавать отчеты RTCP чаще, чем раз в 5 секунд.

Заголовок пакета

Заголовок пакета RTCP
Смещения	Октет	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	Версия		П	ЖК					ПТ								длина
	32	идентификатор SSRC

Версия : (2 бита) Идентифицирует версию RTP, которая одинакова в пакетах RTCP и в пакетах данных RTP. Версия, определенная данной спецификацией, равна двум (2). ^[2]
P (Заполнение) : (1 бит) Указывает, есть ли дополнительные байты заполнения в конце пакета RTP. Заполнение может использоваться для заполнения блока определенного размера, например, как того требует алгоритм шифрования. Последний байт заполнения содержит количество добавленных байтов заполнения (включая его самого). ^[2]
RC (Счетчик отчета о приеме) : (5 бит) Количество блоков отчета о приеме, содержащихся в этом пакете. Нулевое значение является допустимым. ^[2]
PT (тип пакета) : (8 бит). Содержит константу для идентификации типа пакета RTCP. ^[2]
Длина : (16 бит). Указывает длину этого пакета RTCP (включая сам заголовок) в 32-битных единицах минус один. ^[2]
SSRC : (32 бита) Идентификатор источника синхронизации однозначно идентифицирует источник потока. ^[2]

Обратите внимание, что несколько отчетов могут быть объединены в один составной пакет RTCP, каждый из которых имеет собственный заголовок пакета.

Типы сообщений

RTCP различает несколько типов пакетов: отчет отправителя , отчет получателя , описание источника и прощание . Кроме того, протокол является расширяемым и позволяет использовать пакеты RTCP для конкретных приложений. Основанное на стандартах расширение RTCP — это расширенный тип пакета отчета, введенный в RFC 3611. ^[3]

Отчет об отправителе (SR): Отчет об отправителе периодически отправляется активными отправителями в конференции, чтобы сообщить статистику передачи и приема для всех пакетов RTP, отправленных в течение интервала. Отчет отправителя включает в себя две отдельные временные метки: абсолютную временную метку, представленную в формате временной метки сетевого протокола времени (NTP) (которая выражается в секундах относительно полуночи по всемирному координированному времени 1 января 1900 года), и временную метку RTP, соответствующую тому же времени, что и временную метку NTP, но в тех же единицах измерения и с тем же случайным смещением, что и временные метки RTP в пакетах данных, описанных в этом отчете отправителя. ^[2]^: 12, 37 Абсолютная временная метка позволяет получателю синхронизировать сообщения RTP. Это особенно важно, когда аудио и видео передаются одновременно, поскольку аудио и видео потоки используют независимые относительные метки времени.
Отчет получателя (RR): Отчет получателя предназначен для пассивных участников, которые не отправляют пакеты RTP. Отчет информирует отправителя и других получателей о качестве обслуживания.
Описание источника (СДЕС): Сообщение «Описание источника» используется для отправки элемента CNAME участникам сеанса. Его также можно использовать для предоставления дополнительной информации, такой как имя, адрес электронной почты, номер телефона и адрес владельца или контролера источника.
До свидания (ПОКА): Источник отправляет сообщение BYE для закрытия потока. Это позволяет конечной точке объявить, что она покидает конференцию. Хотя другие источники могут обнаружить отсутствие источника, это сообщение является прямым объявлением. Это также полезно для медиа-микшера.
Сообщение, специфичное для приложения (APP): Сообщение, специфичное для приложения, предоставляет механизм для разработки специфичных для приложения расширений протокола RTCP.

Масштабируемость в крупных развертываниях

В крупномасштабных приложениях, таких как телевидение по Интернет-протоколу (IPTV), могут возникать очень большие задержки (от минут до часов) между отчетами RTCP из-за механизма управления полосой пропускания RTCP, необходимого для контроля перегрузки (см. Функции протокола ). Приемлемые частоты обычно составляют менее одного в минуту. Это создает возможность неправильного сообщения соответствующей статистики получателем или приводит к тому, что оценка отправителя мультимедиа будет неточной относительно текущего состояния сеанса. Для решения проблем были предложены следующие методы: ^[4] Фильтрация RTCP, смещение RTCP и иерархическая агрегация . ^[5]

Иерархическая агрегация

Иерархическая агрегация (или также известная как иерархия обратной связи RTCP) представляет собой оптимизацию модели обратной связи RTCP, и ее цель состоит в том, чтобы еще больше сдвинуть ограничение максимального количества пользователей вместе с измерением качества обслуживания (QoS). ^[6]^[7] Пропускная RTCP способность постоянна и занимает всего 5% пропускной способности сеанса. Таким образом, интервал отчетов о QoS зависит, среди прочего, от количества участников сеанса и для очень больших сеансов может стать очень большим (минуты или даже часы). ^[2] Однако приемлемый интервал составляет около 10 секунд сообщения. Большие значения могут привести к смещению во времени и очень неточному сообщению о текущем состоянии сеанса, а любая оптимизация, выполненная отправителем, может даже оказать негативное влияние на сеть или условия QoS.

Иерархическое агрегирование используется с многоадресной рассылкой с указанием источника , где разрешен только один источник, т. е. IPTV . Другим типом многоадресной рассылки может быть многоадресная рассылка из любого источника , но она не очень подходит для крупномасштабных приложений с огромным количеством пользователей.

По состоянию на июнь 2007 г. ^[update], только самые современные системы IPTV используют иерархическую агрегацию. ^{[ нужна ссылка ]}

Цель обратной связи

Цель обратной связи — это новый тип участников, впервые представленный в интернет-проекте Draft-ietf-avt-rtcpssm-13. ^[8] Метод иерархической агрегации расширил свои функциональные возможности. Функция этого члена заключается в получении отчетов получателя (RR) (см. RTCP ) и повторной передаче сводных пакетов RR, так называемой сводной информации получателя (RSI). ^[8] отправителю (в случае одноуровневой иерархии).

Стандартные документы

RFC 3550 , Стандарт 64, RTP: транспортный протокол для приложений реального времени.

См. также

Примечания

^ Биты упорядочены от наиболее значимого к наименее значимому; Смещение бита 0 — это старший бит первого октета. Октеты передаются в сетевом порядке . Порядок передачи битов зависит от среды.

Ссылки

^ К. Хуитема (октябрь 2003 г.). Атрибут протокола управления в реальном времени (RTCP) в протоколе описания сеанса (SDP) . РФК 3605 .
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час Джейкобсон, В.; Фредерик, Р.; Каснер, С.; Шульцринн, Х. RTP: транспортный протокол для приложений реального времени . дои : 10.17487/RFC3550 . РФК 3550 .
^ RFC 3611, Расширенные отчеты протокола управления RTP (RTCP XR) , Т. Фридман (ред.), Р. Касерес, А. Кларк (ред.), The Internet Society (ноябрь 2003 г.)
^ Вит Новотны, Дэн Комосный, Крупномасштабная оптимизация обратной связи RTCP , Журнал сетей, Том 3 (3), март 2008 г.
^ Протокол управления в реальном времени и его улучшения для интернет-телевидения.
^ КОМОСНЫЙ Д., НОВОТНЫЙ В. Древовидная структура для многоадресной рассылки по конкретному источнику с агрегацией обратной связи, в ICN07 - Шестая международная конференция по сетям. Мартиника, 2007 г. ISBN 0-7695-2805-8
^ НОВОТНЫЙ В., КОМОСНЫЙ Д. Оптимизация крупномасштабных отчетов об обратной связи RTCP в ICWMC 2007. ICWMC 2007 - Третья международная конференция по беспроводной и мобильной связи. Гваделупа, 2007 г. ISBN 0-7695-2796-5
^ Перейти обратно: ^а ^б Дж. Отт; Дж. Честерфилд; Э. Шулер. Расширения RTCP для сеансов многоадресной рассылки с одним источником и обратной связью одноадресной рассылки . РФК 5760 .

Дальнейшее чтение

Перкинс, Колин (2003). РТП . Аддисон-Уэсли. п. 414. ИСБН 978-0-672-32249-5 .
Петерсон, Ларри Л.; Брюс С. Дэви (2007). Компьютерные сети (4-е изд.). Морган Кауфманн. п. 806. ИСБН 978-0-12-374013-7 .
«РТКП» . Справочник по сетевым протоколам . Джаввин Технологии. 2005. ISBN 978-0-9740945-2-6 .

[2] Биты упорядочены от наиболее значимого к наименее значимому; Смещение бита 0 — это старший бит первого октета. Октеты передаются в сетевом порядке . Порядок передачи битов зависит от среды.

[1] К. Хуитема (октябрь 2003 г.). Атрибут протокола управления в реальном времени (RTCP) в протоколе описания сеанса (SDP) . РФК 3605 .

[RFC3550-3] Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час Джейкобсон, В.; Фредерик, Р.; Каснер, С.; Шульцринн, Х. RTP: транспортный протокол для приложений реального времени . дои : 10.17487/RFC3550 . РФК 3550 .

[4] RFC 3611, Расширенные отчеты протокола управления RTP (RTCP XR) , Т. Фридман (ред.), Р. Касерес, А. Кларк (ред.), The Internet Society (ноябрь 2003 г.)

[5] Вит Новотны, Дэн Комосный, Крупномасштабная оптимизация обратной связи RTCP , Журнал сетей, Том 3 (3), март 2008 г.

[6] Протокол управления в реальном времени и его улучшения для интернет-телевидения.

[HA1-7] КОМОСНЫЙ Д., НОВОТНЫЙ В. Древовидная структура для многоадресной рассылки по конкретному источнику с агрегацией обратной связи, в ICN07 - Шестая международная конференция по сетям. Мартиника, 2007 г. ISBN 0-7695-2805-8

[HA2-8] НОВОТНЫЙ В., КОМОСНЫЙ Д. Оптимизация крупномасштабных отчетов об обратной связи RTCP в ICWMC 2007. ICWMC 2007 - Третья международная конференция по беспроводной и мобильной связи. Гваделупа, 2007 г. ISBN 0-7695-2796-5

[HA4-9] Перейти обратно: ^а ^б Дж. Отт; Дж. Честерфилд; Э. Шулер. Расширения RTCP для сеансов многоадресной рассылки с одним источником и обратной связью одноадресной рассылки . РФК 5760 .

[1]

[а]

[2]

[3]

[4]

[5]

[6]

[7]

[8]