Протокол управления 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 секунд.
Заголовок пакета
Смещения | Октет | 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 | Версия | п | RC | PT | длина | ||||||||||||||||||||||||||||
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 г.[Обновить], только самые современные системы IPTV используют иерархическую агрегацию. [ необходима цитата ]
Цель обратной связи
Целевая обратная связь - это новый тип участников, впервые представленный в Интернет-проекте draft-ietf-avt-rtcpssm-13. [8] Метод иерархической агрегации расширил свои функциональные возможности. Функция этого элемента состоит в том, чтобы получать отчеты получателя (RR) (см. RTCP ) и повторно передавать обобщенные RR-пакеты, так называемую сводную информацию получателя (RSI) [8], отправителю (в случае одноуровневой иерархии).
Стандарты документов
Смотрите также
Заметки
- ^ Биты отсортированы от наиболее значимого до наименее значимого; битовое смещение 0 - это самый старший бит первого октета. Октеты передаются в сетевом порядке . Порядок передачи битов зависит от среды.
Рекомендации
- ^ К. Уитема (октябрь 2003 г.). Атрибут протокола управления в реальном времени (RTCP) в протоколе описания сеанса (SDP) . RFC 3605 .
- ^ Б с д е е г ч Jacobson, V .; Frederick, R .; Casner, S .; Шульцринн, Х. RTP: транспортный протокол для приложений реального времени . DOI : 10,17487 / RFC3550 . RFC 3550 .
- ^ RFC 3611, Расширенные отчеты протокола управления RTP (RTCP XR) , Т. Фридман (ред.), Р. Касерес, А. Кларк (ред.), The Internet Society (ноябрь 2003 г.)
- ^ Vít Novotný, Dan Komosný, Large-Scale RTCP Feedback Optimization , Journal of Networks, Vol.3 (3), март 2008 г.
- ^ Протокол управления в реальном времени и его улучшения для телевидения по Интернет-протоколу
- ^ КОМОСНЫЙ Д., НОВОТНЫЙ В. Древовидная структура для многоадресной рассылки от конкретного источника с агрегацией обратной связи, в ICN07 - Шестая международная конференция по сетям. Мартиника, 2007 г.ISBN 0-7695-2805-8
- ^ НОВОТНЫЙ, В., КОМОСНЫЙ, Д. Оптимизация крупномасштабных отчетов обратной связи RTCP в ICWMC 2007. ICWMC 2007 - Третья международная конференция по беспроводной и мобильной связи. Гваделупа, 2007 г.ISBN 0-7695-2796-5
- ^ а б Дж. Отт; Дж. Честерфилд; Э. Школьник. Расширения RTCP для многоадресных сеансов с одним источником с одноадресной обратной связью . RFC 5760 .
дальнейшее чтение
- Перкинс, Колин (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.