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

Не путать с Протокол потоковой передачи в реальном времени.

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

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

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 г., только самые современные системы IPTV используют иерархическую агрегацию.[нужна цитата ]

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

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

Документы стандартов

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

Смотрите также

Примечания

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

Рекомендации

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

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