RTCP

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

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

Функции RTCP

RTCP выполняет четыре функции:

• Обеспечение обратной связи для контроля качества при рассылке данных.Обратная связь может быть непосредственно полезна при адаптивном кодировании, но эксперименты с IP Multicast'ом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP Multicast, сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети.
• RTCP имеет постоянный идентификатор транспортного уровня для RTP источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы.
• Первые две функции требуют, чтобы все участники посылали RTCP-пакеты, следовательно, скорость передачи должна контролироваться, для того чтобы RTP мог работать с большим числом участников. При посылке каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это число используется при вычислении частоты посылки пакетов.
• Четвертая опциональная функция служит для передачи минимальной управляющей информации, например, идентификаторов участников для графического интерфейса пользователя. Это полезно для «слабо управляемых» сессий, когда участники входят и выходят без должного контроля и без согласования параметров. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он необязательно поддерживает все коммуникационные требования приложения.

Первые три функции являются обязательными, когда RTP используется в среде с IP Multicast, и рекомендательными для всех остальных сред. Разработчикам приложений RTP рекомендуется избегать механизмов, которые могут работать только в режиме Unicast.

Формат пакетов RTCP

Стандарт определяет несколько типов RTCP пакетов, которые предназначены для переноса управляющей информации:

sr: Отчет отправителя. Для статистики приема и передачи участников, которые являются активными отправителями
rr: Отчет получателя. Для получения статистики от участников, которые не являются активными отправителями
sdes: Элементы описания источника, включая cname
bye: Отмечает прекращение участия в группе
app: Специфические функции приложения

Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется RTP-пакетами, за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 битам. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, для того чтобы получить составной RTCP-пакет, который посылается в рамках протокола транспортного уровня, например, UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол транспортного уровня задаст общую длину и определит конец составного пакета.

Ограничения, накладываемые на протокол RTCP

Каждый индивидуальный RTCP пакет в составном пакете может обрабатываться независимо без каких-либо требований к порядку или комбинации пакетов. Однако для того чтобы выполнить функции протокола, накладываются следующие ограничения:

• Статистика приема (в SR или RR) должна посылаться так часто, как это позволяют ограничения пропускной способности, так что каждый периодически посылаемый составной пакет включает в себя пакет отчета.
• Новые получатели должны приобрести cname для источника как можно быстрее, каждый составной RTCP-пакет должен включать в себя SDES Cname.
• Число типов пакетов, которые могут впервые появиться в составном пакете, должно быть ограничено.

Таким образом, все RTCP-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат:
Префикс шифрования. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета.
SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP-пакетом в составной дейтаграмме является Bye.
Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах.
SDES. SDES-пакет, содержащий Cname, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционально добавлены, если этого требует характер приложения и позволяет пропускная способность используемого канала.
Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться.

Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников.

Файл:RTCP1.gif

Пример составного RTCP-пакета, который может быть сформирован смесителем.

Приложение может игнорировать RTCP пакеты неизвестного ему типа. Дополнительныетипы RTCP-пакетов могут быть зарегистрированы IANA (internet assigned numbers authority).

Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.

Протокол RTP построен так, чтобы позволять приложению изменять число участников от единиц до тысяч. Например, в аудиоконференциях информационный поток всегда ограничен (сколько бы ни было участников, все они одновременно говорить не могут, так как не смогут ничего понять). Однако трафик управления таким свойством не обладает. Если доклады о приеме от каждого участника поступают с постоянной частотой, трафик управления будет расти пропорционально числу участников. Следовательно, нужно принимать меры по ограничению трафика.

Для каждой сессии предполагается, что предельно допустимый информационный трафик сессии делится между участниками. Эта полоса пропускания может быть зарезервирована. Полоса не зависит от метода кодирования, но на выбор метода кодирования может оказать влияние имеющаяся в распоряжении полоса пропускания используемого канала. Определенные ограничения на полосу сессии может накладывать конкретное приложение. Вычисления полосы пропускания, необходимой для управления, требует учета издержек транспортных протоколов (например, UDP и IP).

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

Алгоритм вычисления периода рассылки составных RTCP-пакетов

Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты:

o Отправители коллективно выделяют по крайней мере 1/4 управляющего трафика, так чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали cname узлов отправителей.

o Вычисленный интервал между RTCP-пакетами должен быть больше 5 сек, с тем чтобы избежать превышения допустимого значения трафика при флуктуациях информационного потока, когда число участников мало.

o Интервалы между RTCP-пакетами варьируются случайным образом в пределах от 0.5с. до 1.5с. от вычисленного значения, с тем чтобы избежать непреднамеренной синхронизации работы участников. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала.

o Для того чтобы адаптироваться к количеству пересылаемой контрольной информации, вычисляется среднее значение размера составного пакета для отправляемых и получаемых дейтограмм.

Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания RTCP должна быть равна 5% от этого значения.

Вычисление периода рассылки RTCP-пакетов зависит от оценки числа узлов, участвующих в сессии. Новые узлы добавляются к этому числу, когда они услышаны и соответствующие записи занесены в таблицы SSRC или CSRC-идентификаторов. Новые записи не рассматриваются, как действующие, до тех пор, пока не будет получено несколько пакетов с новым SSRC. Записи могут быть стерты из таблицы, когда приходит пакет RTCP Bye с соответствующим идентификатором SSRC.

Пакеты отчета RTCP

Файл:RTCP2.gif

Формат RTCP пакета сообщения отправителя.

Пакет отчета отправителя состоит из трех секций, за которыми может следовать четвертая, которая определяется, если необходимо, профайлом.

Первая секция - заголовок, имеет 8 октет (информатика)'ов. Эта секция содержит следующие поля:

Версия (v): 2 бита

Идентифицирует версию протокола RTP, которая совпадает с версией RTCP-пакетов. Для данной спецификации v=2.

Заполнитель (p): 1 бит

Если бит заполнителя p=1, то этот пакет RTCP содержит некоторые октет (информатика)'ы заполнителя после управляющей информации. Последний октет (информатика)' заполнителя содержит число октетов заполнителя. Заполнитель может быть нужен при некоторых алгоритмах шифрования, использующих фиксированные блоки. В составных RTCP-пакетах, заполнитель может быть нужен только последнему пакету, так как составной пакет шифруется как целое.

Число отчетов о приеме (RC): 5 бит

Число блоков отчетов о приеме, содержащихся в этом пакете. Допустимо значение нуль.

Тип пакета (pt): 8 бит

Содержит константу 200 для пакетов RTCP SR.

Длина: 16 бит

Длина RTCP-пакета в 32-битных словах минус один, включая заголовок и заполнитель.

ssrc: 32 бит

Идентификатор источника синхронизации для отправителя sr-пакета.

Вторая секция информации из 20 октет (информатика)'ов присутствует в каждом пакете отправителя. Поля этой секции имеют следующие значения:

Временная метка NTP: 64 бита

Указывает абсолютное время, когда данный доклад был послан, оно может быть использовано в комбинации с временными метками, присланными в докладах о приеме другими получателями, для измерения RTT до этих получателей.

Временная метка RTP: 32 бита

Соответствует тому же времени, что и временная метка ntp, но измеряется в тех же единицах и с тем же произвольным смещением, что и временные метки информационных пакетов RTP. Это соответствие может использоваться для внутри- и межсредовой синхронизации для источников, чьи временные метки NTP синхронизованы, и может быть использовано получателями, независящими от среды для оценки номинальной задающей частоты RTP. В большинстве случаев эти временные метки не будут равны временным меткам RTP в любых последовательных информационных пакетах.

Число пакетов отправителя: 32 бита

Полное число информационных RTP-пакетов, переданных отправителем от начала передачи до момента генерации SR-пакета. Число сбрасывается в нуль, если отправитель изменяет свой SSRC-идентификатор.

Число октет (информатика)'ов отправителя: 32 бита

Полное число октет (информатика)'ов поля данных (исключая заголовки и заполнители), переданных в информационных RTP-пакетах отправителем, начиная с начала передачи до момента генерации SR-пакета. Это число сбрасывается в нуль, когда отправитель меняет свой SSRC-идентификатор. Это поле может быть использовано для оценки среднего потока данных.

Третья секция состоит из нуля или более блоков отчета о приеме в зависимости от числа источников, пакеты от которых приняты с момента последнего отчета. Каждый блок отчета о приеме несет в себе статистику получения RTP-пакетов, поступающих от одного из источников синхронизации. Получатель не сохраняет статистику, когда источник изменяет свой ssrc-идентификатор.

SSRC_n (идентификатор источника): 32 бита

SSRC-идентификатор источника, к которому относится информация, содержащаяся в блоке отчета о получении.

Доля потерянных (пакетов): 8 бит

Часть информационных RTP-пакетов от источника ssrc_n потерянная с момента посылки предыдущего SR или RR-пакетов, представленная в виде числа с фиксированной запятой, помещенной слева. Это эквивалентно целому, полученному после умножения данного числа на 256. Эта доля получается в результате деления числа потерянных пакетов на ожидаемое число пакетов. Если потери из-за дубликатов оказались отрицательны, доля потерянных пакетов объявляется равной нулю. Заметим, что от источника, все пакеты которого были потеряны при транспортировке отчета о приеме послано не будет.

Суммарное число потерянных пакетов: 24 бита

Полное число информационных RTP-пакетов от источника SSRC_n, которые были потеряны с момента начала передачи. Это число определяется как разность между ожидаемым и полученным числами пакетов, где число полученных включает в себя и дубликаты. Таким образом, пакеты, пришедшие с опозданием, не считаются потерянными, а число потерянных пакетов может оказаться отрицательным, если получены дубликаты пакетов. Число ожидаемых пакетов определяется как разность между номером последнего полученного пакета и номером первого пакета.

Наибольший номер из числа полученных пакетов: 32 бита

Младшие 16 бит содержит наибольший порядковый номер полученного от источника SSRC_n информационного RTP-пакета. Старшие 16 бит несут в себе число циклов нумерации (переполнения счетчика номеров пакетов). Заметим, что различные получатели в рамках одной и той же сессии генерируют разные коды циклов нумерации (расширений), если они начали свою работу в разное время.

Разброс времени доставки: 32 бита

Оценка статистической вариации периода прихода RTP-пакетов, измеряемого с помощью временных меток и характеризуемого целым числом. Разброс периода прихода пакетов j определяется как усредненное отклонение разности D расстояния между пакетами со стороны получателя по отношению к той же величине для стороны отправителя. Эта величина характеризует относительный разброс времени транспортировки пакетов.

Если s_i равно временной метке i-го пакета RTP, а r_i - время прибытия в единицах временной метки пакета i, тогда для двух пакетов i и j D может быть выражено как

d_i,j =(r_j-r_i)-(s_j-s_i)=(r_j-s_j)-(r_i-s_i)

Разброс времени доставки вычисляется непрерывно для каждого пребывающего от SSRC_n пакета i, используя разность D для данного пакета и предыдущего пакета i-1 согласно формуле

j=j+(|d_i-1,i|-j)/16

Вычисление разброса времени доставки позволяет мониторам, независимым от профайла, осуществлять интерпретацию докладов, приходящих от различных приложений. Этот алгоритм является оптимальным первым приближением и масштабный параметр 1/16 обеспечивает приемлемое уменьшение влияние шума и разумную скорость сходимости.

Последняя временная метка (LSR) (last SR): 32 бита

Средние 32 бита из 64 во временной метке NTP, полученной как часть последнего отчета RTCP-отправителя (SR) об источнике SSRC_n. Если SR пока не получено, в поле заносится нуль.

Задержка с момента последнего SR (DLSR- delay of last sr): 32 бита

Задержка, выраженная в единицах 1/65536 секунды, между моментом получения последнего SR-пакета от источника SSRC_n и временем посылки блока отчета о приеме. Если ни одного пакета SR от ssrc_n пока не получено, в поле DLSR заносится нуль.

Файл:RTCP3.gif

Формат пакета отчета о приеме (RR).

Формат пакета отчета о приеме (RR) аналогичен формату SR пакета за исключением того, что поле типа содержит код 201 и опущены первые пять слов информации об отправителе (это NTP/RTP временные метки, а также число пакетов и октетов отправителя). Остальные поля имеют то же самое значение, как и для пакета SR.

Когда нет информации об отправке или приеме, в начало составного RTCP-пакета вставляется пустой RR-пакет (RC = 0).

Профайл должен определять специфические для приложения расширения в докладах получателей и отправителей, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно сообщаться. Этот метод предпочтительнее, чем описание нового типа RTCP-пакета, так как не требует дополнительных издержек: меньше октетов в пакете (нет RTCP-заголовка или поля SSRC); проще и быстрее разбор, так как приложение, работающее под управлением профайла, будет запрограммировано всегда ожидать поля расширения с известным их положением в пакетах отчетов.

Если необходима дополнительная информация, она должна быть включена в первую очередь в расширение для отчета отправителя, но не будет присутствовать в отчетах о приеме. Если должна быть подключена информация о получателях, эти данные могут структуризоваться в виде массива блоков дополнительно к существующему массиву блоков-отчетов, т.е., число блоков будет задано полем RC.

Ожидается, что качество обратной связи важно не только для отправителя и получателей, но и для независимых мониторов. Отправитель может модифицировать свою передачу на основе обратной связи, получатели могут определить, являются ли проблемы локальными, региональными или глобальными. Менеджер сети может использовать независимые мониторы, которые получают только RTCP-пакеты, а не соответствующие информационные RTP-пакеты, для оценки эксплуатационных параметров своей сети для мультикастного обмена.

На основе информации отправителя независимый монитор может вычислить усредненное значение потока данных, не получая этих данных. Если можно предположить независимость вероятности потери пакета от его размера, тогда число полученных пакетов, умноженное на средний размер поля данных, может дать оценку для пропускной способности получателя.

Для RTCP допустимо расщепление составных пакетов на пакеты нижележащего уровня, один зашифрованный и один открытый. Например, информация SDES может быть зашифрована, в то время как отчеты о приеме будут посылаться открыто для обеспечения мониторинга.

См. также

• SRTPC
• SRTP
• RTSP