Войти
Протокол управления RTP (RTCP ) является родственным протоколом транспортного протокола реального времени (RTP). Его основные функции и структура пакета определены в RFC 3550. RTCP предоставляет внеполосную статистику и управляющую информацию для сеанса RTP. Он сотрудничает с RTP в доставке и упаковке мультимедийных данных, но не передает сами мультимедийные данные.
Основная функция RTCP - обеспечивать обратную связь по качеству обслуживания (QoS) при распространении мультимедиа путем периодической отправки статистической информации, такой как переданный октет и количество пакетов., потеря пакета, изменение задержки пакета и время задержки приема-передачи для участников сеанса потоковой передачи мультимедиа. Приложение может использовать эту информацию для управления параметрами качества обслуживания, возможно, путем ограничения потока или использования другого кодека .
Обычно RTP отправляется на порт с четным номером UDP, а сообщения RTCP отправляются через следующий порт с нечетным номером, имеющий более высокий номер.
Сам протокол RTCP этого не делает. предоставлять любые методы шифрования или аутентификации потока. Такие механизмы могут быть реализованы, например, с безопасным транспортным протоколом реального времени (SRTP), определенным в RFC 3711.
RTCP обеспечивает базовые функции, которые, как ожидается, будут реализованы во всех сеансах 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 | Версия | P | RC | PT | длина | ||||||||||||||||||||||||||||
| 32 | SSRC | ||||||||||||||||||||||||||||||||
RTCP различает несколько типов пакетов: отчет отправителя, отчет получателя, источник описание и до свидания. Кроме того, протокол является расширяемым и позволяет передавать пакеты RTCP для конкретных приложений. Стандартным расширением RTCP является расширенный тип пакета отчета, представленный в RFC 3611.
В крупномасштабных приложениях, таких как Интернет-телевидение (IPTV), могут возникать очень большие задержки (от нескольких минут до часов) между отчетами RTCP из-за RTCP Механизм управления полосой пропускания, необходимый для управления перегрузкой (см. Функции протокола). Приемлемые частоты обычно меньше одной в минуту. Это создает возможность несоответствующего отчета о релевантной статистике получателем или может привести к тому, что оценка отправителя мультимедийных данных будет неточной относительно текущего состояния сеанса. Были введены методы для решения проблем: фильтрация RTCP, смещение RTCP и иерархическая агрегация.
Иерархическая агрегация (или также известная как иерархия обратной связи RTCP) - это оптимизация обратной связи RTCP. Модель, и ее цель состоит в дальнейшем изменении максимального числа пользователей вместе с измерением качества обслуживания (QoS). Пропускная способность RTCP постоянна и занимает всего 5% пропускной способности сеанса. Следовательно, интервал между отчетами о QoS зависит, среди прочего, от количества участников сеанса, и для очень больших сеансов он может стать очень большим (минуты или даже часы). Однако приемлемый интервал составляет около 10 секунд для сообщения. Большие значения могут привести к смещению во времени и очень неточному сообщению о текущем статусе сеанса, а любая оптимизация, сделанная отправителем, может даже оказать негативное влияние на сеть или условия QoS.
Иерархическое агрегирование используется с многоадресной рассылкой, зависящей от источника, где разрешен только один источник, то есть IPTV. Другой тип многоадресной рассылки может быть Многоадресная рассылка от любого источника, но он не очень подходит для крупномасштабных приложений с огромным количеством пользователей.
По состоянию на июнь 2007 года только самые современные системы IPTV используют иерархическую агрегацию.
Целевая обратная связь - это новый тип элемента, который был впервые представлен Интернет-проект draft-ietf-avt-rtcpssm-13. Расширены функциональные возможности метода иерархической агрегации. Функция этого элемента состоит в том, чтобы получать отчеты получателя (RR) (см. RTCP ) и повторно передавать сводные RR-пакеты, так называемую сводную информацию о получателе (RSI), отправителю (в случае одноуровневой иерархии).
