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

Протокол управления 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 секунд.

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

• Версия : (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 ^{[Обновить]}года только самые современные системы IPTV используют иерархическую агрегацию. ^{[ необходима цитата ]}

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

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

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

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

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

• Потоковое мультимедиа
• Качество обслуживания
• Голос по Интернет-протоколу

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

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

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

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