RTCP: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
(Показать все непатрулированные изменения)
[непроверенная версия][непроверенная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
орфография
 
(не показано 48 промежуточных версий 11 участников)
Строка 12: Строка 12:
}}
}}


'''RTCP''' ({{lang-en|Real-Time Transport Control Protocol}} — протокол управления передачей в реальном времени) — протокол, используемый совместно с [[RTP]]. Протокол описан в RFC 3550,<ref>RFC 3550, ''RTP: A Transport Protocol for Real-Time Applications'', H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, The Internet Society (Июль 2003)</ref>. RTCP базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных.
'''RTCP''' ({{lang-en|Real-Time Transport Control Protocol}} — протокол управления передачей в реальном времени) — [[протокол передачи данных|протокол]], используемый совместно с [[Real-time Transport Protocol|RTP]]. Протокол описан в RFC 3550,<ref>RFC 3550, ''RTP: A Transport Protocol for Real-Time Applications'', H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, The Internet Society (Июль 2003)</ref>. RTCP базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных.


Протокол RTCP используется для передачи информации о задержках и потерях медиа-пакетов, [[джиттер]]-буфере, уровне звукового сигнала. Также передаются метрика качества сигнала (Call Quality Metrics) и Echo Return Loss.
== Функции RTCP ==
RTCP выполняет четыре функции:
* Обеспечение обратной связи для контроля качества при рассылке данных.Обратная связь может быть непосредственно полезна при адаптивном кодировании, но эксперименты с [[IP]] [[Multicast]]'ом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа [[IP]] [[Multicast]], сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети.
* RTCP имеет постоянный идентификатор [[Транспортный уровень|транспортного уровня]] для [[RTP]] источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы.
* Первые две функции требуют, чтобы все участники посылали RTCP-пакеты, следовательно, скорость передачи должна контролироваться, для того чтобы [[RTP]] мог работать с большим числом участников. При посылке каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это число используется при вычислении частоты посылки пакетов.
* Четвертая опциональная функция служит для передачи минимальной управляющей информации, например, идентификаторов участников для [[Графический интерфейс пользователя|графического интерфейса пользователя]]. Это полезно для «слабо управляемых» сессий, когда участники входят и выходят без должного контроля и без согласования параметров. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он необязательно поддерживает все коммуникационные требования приложения.
Первые три функции являются обязательными, когда [[RTP]] используется в среде с [[IP]] [[Multicast]], и рекомендательными для всех остальных сред. Разработчикам приложений RTP рекомендуется избегать механизмов, которые могут работать только в режиме [[Unicast]].


Определены следующие типы сообщений RTCP:
== Формат пакетов RTCP ==
* SR - Sender Report - отчёт отправителя по отправленным медиа-пакетам RTP
Стандарт определяет несколько типов RTCP пакетов, которые предназначены для переноса управляющей информации:<br />
* RR - Receiver Report - отчёт получателя по полученным медиа-пакетам RTP
* SDES - элементы описания источника, включая cname
* BYE - Отмечает прекращение участия в группе
* APP - Специфические функции приложения


В рекомендации RFC 3611 определено также сообщение XR - Extended Report, которое позволяет отправлять большее число параметров, по сравнению со стандартными отчётами, а именно:
'''sr:''' Отчет отправителя. Для статистики приема и передачи участников, которые являются активными отправителями<br />
'''rr:''' Отчет получателя. Для получения статистики от участников, которые не являются активными отправителями<br />
'''sdes:''' Элементы описания источника, включая cname<br />
'''bye:''' Отмечает прекращение участия в группе<br />
'''app:''' Специфические функции приложения<br />


* Время получения пакета
Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется [[RTP]]-пакетами, за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 битам. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, для того чтобы получить составной RTCP-пакет, который посылается в рамках протокола [[Транспортный уровень|транспортного уровня]], например, [[UDP]]. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол [[Транспортный уровень|транспортного уровня]] задаст общую длину и определит конец составного пакета.
* Порядковые номера потерянных пакетов
* Порядковые номера повторяющихся пакетов
* Ожидаемое время доставки
* Задержка с момента приема последнего отчета RTCP Receiver Report
* Общая статистика медиа-пакетов
* Оценка VoIP - направления (MOS и R Factor - параметр характеризующий качество сигнала)


== Шифрование RTCP ==
== Ограничения, накладываемые на протокол RTCP ==
{{Карточка протокола
Каждый индивидуальный RTCP пакет в составном пакете может обрабатываться независимо без каких-либо требований к порядку или комбинации пакетов. Однако для того чтобы выполнить функции протокола, накладываются следующие ограничения:
|Аббр = SRTCP
* Статистика приема (в SR или RR) должна посылаться так часто, как это позволяют ограничения [[Пропускная способность|пропускной способности]], так что каждый периодически посылаемый составной пакет включает в себя пакет отчета.
|Название = Secure Real-Time Transport Control Protocol
* Новые получатели должны приобрести cname для источника как можно быстрее, каждый составной RTCP-пакет должен включать в себя SDES Cname.
|Уровень = Транспортный
* Число типов пакетов, которые могут впервые появиться в составном пакете, должно быть ограничено.
|Семейство = [[стек протоколов TCP/IP|TCP/IP]]
|Создан =
|Порт =
|Назначение = шифрование RTCP
|Спецификация = RFC 3711
|Клиенты =
|Серверы =
}}
{{main|SRTP}}


Существует вариант протокола [[Real-time Transport Protocol|RTP]] c шифрованием Secure Real-time Transport Protocol (SRTP) для обеспечения безопасной передачи данных. И так как RTP тесно связан с RTCP
Таким образом, все RTCP-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат:<br />
(Real-Time Control Protocol), который может использоваться, чтобы
'''Префикс шифрования'''. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета.<br />
управлять сессией RTP, у SRTP также есть родственный протокол, названный
'''SR или RR'''. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP-пакетом в составной [[Дейтаграмма|дейтаграмме]] является Bye.<br />
'''Secure RTCP''' (или [[SRTCP]]).
'''Дополнительные RR'''. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах.<br />
SRTCP обеспечивает те же самые функции, связанные с безопасностью в RTCP, для той же функциональности SRTP в RTP.
'''SDES'''. SDES-пакет, содержащий Cname, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционально добавлены, если этого требует характер приложения и позволяет [[Пропускная способность|пропускная способность]] используемого канала.<br />
'''Bye или APP'''. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться.<br />


Протокол SRTCP описан в <nowiki>RFC 3711</nowiki> об SRTP в главе 3.4.
Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников.
[[Файл:RTCP1.gif|thumb|left|350px|Пример составного RTCP-пакета, который может быть сформирован смесителем.]]


SRTCP добавляет 3 новых обязательных поля "SRTCP index", "encrypt-flag" и "authentication tag" и опциональное поле MKI в описание пакета RTCP.
Приложение может игнорировать RTCP пакеты неизвестного ему типа. Дополнительныетипы RTCP-пакетов могут быть зарегистрированы IANA (internet assigned numbers authority).


Использование SRTP или SRTCP является необязательным при использовании RTP или RTCP, но даже если SRTP/SRTCP используются, все дополнительные возможности (такие как шифрование и установление подлинности) опциональны и могут быть включены или выключены. Единственное исключение — функция аутентификации сообщений, которая обязательна при использовании SRTCP.
Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.


Для шифрования медиа потока (в целях конфиденциальности голосового соединения), SRTP вместе с SRTCP стандартизируют использование только единственного шифра, [[Advanced Encryption Standard|AES]], который может использоваться в двух режимах, превращающих изначально блочный шифр [[Advanced Encryption Standard|AES]] в потоковый шифр.
Протокол [[RTP]] построен так, чтобы позволять приложению изменять число участников от единиц до тысяч. Например, в [[Аудиоконференция|аудиоконференциях]] информационный поток всегда ограничен (сколько бы ни было участников, все они одновременно говорить не могут, так как не смогут ничего понять). Однако [[трафик]] управления таким свойством не обладает. Если доклады о приеме от каждого участника поступают с постоянной частотой, трафик управления будет расти пропорционально числу участников. Следовательно, нужно принимать меры по ограничению трафика.


== См. также ==
Для каждой сессии предполагается, что предельно допустимый информационный трафик сессии делится между участниками. Эта полоса пропускания может быть зарезервирована. Полоса не зависит от метода кодирования, но на выбор метода кодирования может оказать влияние имеющаяся в распоряжении полоса пропускания используемого канала. Определенные ограничения на полосу сессии может накладывать конкретное приложение. Вычисления полосы пропускания, необходимой для управления, требует учета издержек [[Транспортный протокол|транспортных протоколов]] (например, [[UDP]] и [[IP]]).
* [[RTP]]
* [[SRTP]]
* [[ZRTP]]
* [[RTSP]]


== Примечания ==
Трафик управления должен быть ограничен малой долей полной полосы пропускания сессии: настолько малой, чтобы не нанести ущерба основной функции транспортного протокола — переносу информации. Предлагается, чтобы доля трафика сессии, выделенная на RTCP, была фиксирована на уровне не более 5%. Параметры, определяющие трафик, должны быть идентичными для всех участников, так чтобы они могли корректно вычислить период рассылки отчетов. Эти параметры фиксируются в соответствующем профайле.
{{reflist}}

== Алгоритм вычисления периода рассылки составных RTCP-пакетов ==
Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты:
o Отправители коллективно выделяют по крайней мере 1/4 управляющего трафика, так чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали cname узлов отправителей.
o Вычисленный интервал между RTCP-пакетами должен быть больше 5 сек, с тем чтобы избежать превышения допустимого значения трафика при флуктуациях информационного потока, когда число участников мало.
o Интервалы между RTCP-пакетами варьируются случайным образом в пределах от 0.5с. до 1.5с. от вычисленного значения, с тем чтобы избежать непреднамеренной синхронизации работы участников. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала.
o Для того чтобы адаптироваться к количеству пересылаемой контрольной информации, вычисляется среднее значение размера составного пакета для отправляемых и получаемых дейтограмм.


== Ссылки ==
== Ссылки ==
* [http://book.itep.ru/4/44/rtc_4493.htm#5 Транспортный протокол реального времени RTCP] {{Wayback|url=http://book.itep.ru/4/44/rtc_4493.htm#5 |date=20091218170958 }}
{{reflist}}
{2 {http://book.itep.ru/4/44/rtc_4493.htm#2}}


{{IPstack|nocat=1}}
== См. также ==
* [[SRTPC]]
* [[SRTP]]
* [[RTSP]]


[[Категория:Протоколы транспортного уровня]]
{{IPstack}}

[[Категория:Сетевые протоколы]]
[[Категория:Протоколы VoIP]]
[[Категория:Протоколы VoIP]]

[[bg:RTCP]]
[[ca:Real Time Control Protocol]]
[[cs:RTCP]]
[[da:Real time control protocol]]
[[de:RealTime Control Protocol]]
[[en:RTP Control Protocol]]
[[es:Real time control protocol]]
[[fr:Real-time Transport Control Protocol]]
[[it:RTCP]]
[[ja:Real-time Transport Control Protocol]]
[[lt:RTCP]]
[[pl:Real Time Control Protocol]]
[[pms:RTCP]]
[[pt:RTCP]]
[[sv:Real Time Control Protocol]]
[[uk:RTCP]]
[[zh:实时传输控制协议]]

Текущая версия от 21:11, 19 декабря 2022

RTCP
Название Real-Time Transport Control Protocol
Уровень (по модели OSI) Транспортный
Семейство TCP/IP
Спецификация RFC 3550
Логотип Викисклада Медиафайлы на Викискладе

RTCP (англ. Real-Time Transport Control Protocol — протокол управления передачей в реальном времени) — протокол, используемый совместно с RTP. Протокол описан в RFC 3550,[1]. RTCP базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных.

Протокол RTCP используется для передачи информации о задержках и потерях медиа-пакетов, джиттер-буфере, уровне звукового сигнала. Также передаются метрика качества сигнала (Call Quality Metrics) и Echo Return Loss.

Определены следующие типы сообщений RTCP:

  • SR - Sender Report - отчёт отправителя по отправленным медиа-пакетам RTP
  • RR - Receiver Report - отчёт получателя по полученным медиа-пакетам RTP
  • SDES - элементы описания источника, включая cname
  • BYE - Отмечает прекращение участия в группе
  • APP - Специфические функции приложения

В рекомендации RFC 3611 определено также сообщение XR - Extended Report, которое позволяет отправлять большее число параметров, по сравнению со стандартными отчётами, а именно:

  • Время получения пакета
  • Порядковые номера потерянных пакетов
  • Порядковые номера повторяющихся пакетов
  • Ожидаемое время доставки
  • Задержка с момента приема последнего отчета RTCP Receiver Report
  • Общая статистика медиа-пакетов
  • Оценка VoIP - направления (MOS и R Factor - параметр характеризующий качество сигнала)

Шифрование RTCP

[править | править код]
SRTCP
Название Secure Real-Time Transport Control Protocol
Уровень (по модели OSI) Транспортный
Семейство TCP/IP
Назначение протокола шифрование RTCP
Спецификация RFC 3711
Логотип Викисклада Медиафайлы на Викискладе
Основная статья: SRTP

Существует вариант протокола RTP c шифрованием Secure Real-time Transport Protocol (SRTP) для обеспечения безопасной передачи данных. И так как RTP тесно связан с RTCP (Real-Time Control Protocol), который может использоваться, чтобы управлять сессией RTP, у SRTP также есть родственный протокол, названный Secure RTCP (или SRTCP). SRTCP обеспечивает те же самые функции, связанные с безопасностью в RTCP, для той же функциональности SRTP в RTP.

Протокол SRTCP описан в RFC 3711 об SRTP в главе 3.4.

SRTCP добавляет 3 новых обязательных поля "SRTCP index", "encrypt-flag" и "authentication tag" и опциональное поле MKI в описание пакета RTCP.

Использование SRTP или SRTCP является необязательным при использовании RTP или RTCP, но даже если SRTP/SRTCP используются, все дополнительные возможности (такие как шифрование и установление подлинности) опциональны и могут быть включены или выключены. Единственное исключение — функция аутентификации сообщений, которая обязательна при использовании SRTCP.

Для шифрования медиа потока (в целях конфиденциальности голосового соединения), SRTP вместе с SRTCP стандартизируют использование только единственного шифра, AES, который может использоваться в двух режимах, превращающих изначально блочный шифр AES в потоковый шифр.

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ RFC 3550, RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, The Internet Society (Июль 2003)

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=RTCP&oldid=127360380