Протоколы Internet
Транспортный протокол реального времени RTCP
4.4.9.3 Транспортный протокол реального времени RTCP
Семенов Ю.А. (ГНЦ ИТЭФ)
1. Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных. Обратная связь может быть непосредственно полезна при адаптивном кодировании [1,2], но эксперименты с IP мультикастингом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP-мультикастинга, сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети.
2. RTCP имеет постоянный идентификатор транспортного уровня для RTP источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы.
3. Первые две функции требуют, чтобы все участники посылали RTCP-пакеты, следовательно скорость передачи должна контролироваться для того, чтобы RTP мог работать с большим числом участников. При посылке каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это число используется при вычислении частоты посылки пакетов.
Таким образом, все rtcp-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат:
Префикс шифрования. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета.
SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP -пакетом в составной дейтограмме является Bye.
Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах.
SDES. SDES-пакет, содержащий Cname, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционно добавлены, если этого требует характер приложения и позволяет пропускная способность используемого канала.
Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться.
Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников. Пример составного RTCP-пакета, который может быть сформирован смесителем, представлен на рис. 4.4.9.3.1. Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.
Приложение может игнорировать RTCP пакеты неизвестного ему типа. Дополнительныетипы RTCP-пакетов могут быть зарегистрированы IANA (internet assigned numbers authority).
Рис. 4.4.9.3.1. Пример составного пакета RTCP (#: SSRC/CSRC)
Протокол RTP построен так, чтобы позволять приложению изменять число участников от единиц до тысяч. Например, при аудио конференциях информационный поток всегда ограничен (сколько бы не было участников, все они одновременно говорить не могут, так как не смогут ничего понять). Однако, трафик управления таким свойством не обладает. Если доклады о приеме от каждого участника поступают с постоянной частотой, трафик управления будет расти пропорционально числу участников. Следовательно, нужно принимать меры по ограничению трафика.
Для каждой сессии предполагается, что предельно допустимый информационный трафик сессии делится между участниками. Эта полоса пропускания может быть зарезервирована. Полоса не зависит от метода кодирования, но на выбор метода кодирования может оказать влияние имеющаяся в распоряжении полоса пропускания используемого канала. Определенные ограничения на полосу сессии может накладывать конкретное приложение. Вычисления полосы пропускания, необходимой для управления, требует учета издержек транспортных протоколов (например, UDP и IP).
Трафик управления должен быть ограничен малой долей полной полосы пропускания сессии: настолько малой, чтобы не нанести ущерба основной функции транспортного протокола – переносу информации. Предлагается, чтобы доля трафика сессии, выделенная на RTCP была фиксирована на уровне не более 5%. Параметры, определяющие трафик, должны быть идентичными для всех участников, так чтобы они могли корректно вычислить период рассылки отчетов. Эти параметры фиксируются в соответствующем профайле.
Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты:
o Отправители коллективно выделяют по крайней мере 1/4 управляющего трафика, так чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали cname узлов отправителей.
o Вычисленный интервал между RTCP-пакетами должен быть больше 5 сек, с тем чтобы избежать превышения допустимого значения трафика при флуктуациях информационного потока, когда число участников мало.
o Интервалы между RTCP-пакетами варьируются случайным образом в пределах [0.5-1.5] от вычисленного значения, с тем чтобы избежать непреднамеренной синхронизации работы участников [3]. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала.
o Для того чтобы адаптироваться к количеству пересылаемой контрольной информации, вычисляется среднее значение размера составного пакета для отправляемых и получаемых дейтограмм.
Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания RTCP должна быть равна 5% от этого значения.
Вычисление периода рассылки RTCP-пакетов зависит от оценки числа узлов, участвующих в сессии. Новые узлы добавляются к этому числу, когда они услышаны и соответствующие записи занесены в таблицы SSRC или CSRC-идентификаторов. Новые записи не рассматриваются, как действующие, до тех пор, пока не будет получено несколько пакетов с новым SSRC. Записи могут быть стерты из таблицы, когда приходит пакет RTCP Bye с соответствующим идентификатором SSRC.
Участник может пометить другой узел как пассивный, или удалить его из списка, если от него не получено RTP или RTCP-пакетов в течение нескольких периодов RTCP-отчетов (пороговое число периодов предлагается сделать равным 5). Это обеспечивает определенную устойчивость против случайной потери пакетов. Все узлы должны вычислить период RTCP-отчетов, чтобы корректно оценить время тайм-аута.
Если зарегистрированный узел помечен как пассивный, он будет оставаться в списках достаточно долго и учитываться при вычислении распределения полосы пропускания для RTCP. Значение тайм-аута предлагается сделать равным 30 минутам. Заметим, что это значение почти в 5 раз больше, чем наибольшая величина периода рассылки RTCP-отчетов, который составляет 2-5 мин.
Данная спецификация определяет несколько элементов описания источника (SDES). Сюда входит CNAME (каноническое имя), Name (персональное имя) и Email (электронный адрес). Спецификация предлагает также средства для определения типа RTCP-пакетов, специфического для конкретного приложения. Приложения должно проявлять определенную осторожность при выделении полосы для любой дополнительной информации, так как это неизбежно вызовет замедление скорости предоставления отчетов и задержит присылку. Рекомендуется, чтобы дополнительная информация индивидуального участника не занимала более 20% полосы, выделенной для RTCP. Более того, даже не предполагается, что все элементы SDES будут включаться каждым приложением. Например, приложение может посылать только CNAME, name и email и не посылать более никакой дополнительной информации. name может быть присвоен более высокий приоритет чем email, так как name будет отображаться пользовательским интерфейсом приложения постоянно, в то время как Email может отображаться только при запросе. При каждой RTCP рассылке, должны посылаться RR- и SDES-пакеты. Последний содержит элемент Cname. Для небольших сессий, работающих с минимальными периодами рассылки, это будет делаться в среднем каждые 5 секунд. Каждая третья рассылка (15 секунд) может содержать один дополнительный элемент в пакете SDES. Семь из восьми раз это будет элемент name, и каждый восьмой раз (2 минуты) это будет элемент Email.
Когда несколько приложений работают одновременно, например, в случае мультимедиа конференции, допускается, чтобы дополнительная информация пересылалась только в рамках одной RTP-сессии. Остальные сессии будут использовать только элемент cname.
RTP-получатели обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственным различием между формами отчета отправителя (SR) и получателя (rr), помимо кода типа пакета, является то, что отчет отправителя содержит 20-байтовую секцию информации об отправителе. SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отправляется пакет RR.
Как SR так и RR-формы включают в себя нуль или более блоков отчетов о приеме, один для каждого источника синхронизации, от которого получатель принял информационные RTP-пакеты с момента последнего отчета. Отчеты не направляются для источников, перечисленных в списке CSRC. Каждый блок отчета о приеме содержит статистику данных, полученных от конкретного источника. Так как в SR или RR-пакет можно поместить максимум 31 блок отчетов, дополнительные RR-пакеты укладываются после исходного SR или RR-пакета.
Пакет отчета отправителя состоит из трех секций (см. рис. 4.4.9.3.2), за которыми может следовать четвертая, которая определяется, если необходимо, профайлом. Первая секция – заголовок, имеет 8 октетов. Эта секция содержит следующие поля:
Версия (v): 2 бита
Идентифицирует версию протокола RTP, которая совпадает с версией RTCP-пакетов. Для данной спецификации v=2.
Заполнитель (p): 1 бит
Если бит заполнителя p=1, то этот пакет RTCP содержит некоторые октеты заполнителя после управляющей информации. Последний октет заполнителя содержит число октетов заполнителя. Заполнитель может быть нужен при некоторых алгоритмах шифрования, использующих фиксированные блоки. В составных RTCP-пакетах, заполнитель может быть нужен только последнему пакету, так как составной пакет шифруется как целое.
Рис. 4.4.9.3.2. Формат 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 расстояния между пакетами со стороны получателя по отношению к той же величине для стороны отправителя. Эта величина характеризует относительный разброс времени транспортировки пакетов.
Если si равно временной метке i-го пакета RTP, а ri – время прибытия в единицах временной метки пакета i, тогда для двух пакетов i и j D может быть выражено как
di,j =(rj-ri)-(sj-si)=(rj-sj)-(ri-si)
Разброс времени доставки вычисляется непрерывно для каждого пребывающего от SSRC_n пакета i, используя разность D для данного пакета и предыдущего пакета i-1 согласно формуле
j=j+(|di-1,i|-j)/16
Вычисление разброса времени доставки позволяет мониторам, независимым от профайла, осуществлять интерпретацию докладов, приходящих от различных приложений. Это алгоритм является оптимальным первым приближением и масштабный параметр 1/16 обеспечивает приемлемое уменьшение влияние шума и разумную скорость сходимости [4].
Последняя временная метка (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 заносится нуль.
Пусть SSRC_r обозначает получателя, отправляющего отчет о приеме. Источник SSRC_n может вычислить циклическую задержку маршрута RTT для SSRC_r путем записи времени a, когда этот блок доклада о приеме был получен. Он вычисляет полное время RTT A-LSR, используя поле последней временной метки SR (LSR), и затем путем вычитания получает (A - LSR- DLSR). Это проиллюстрировано на рис. 4.4.9.3.3.
Это может быть использовано в качестве меры расстояния до кластера получателей, хотя некоторые связи имеют весьма асимметричный характер задержек.
rr: rtcp-пакет отчета о приеме (RFC-1889)
[10 nov 1995 11:33:25.125] [10 nov 1995 11:33:36.5]
n sr(n) a=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992016.125 s) v ^
r v ^ rr(n)
---------------------------------------------------------------->
||
(5.250 s)
a 0xb710:8000 (46864.500 s)
dlsr -0x0005:4000 ( 5.250 s)
lsr -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x 6:2000 ( 6.125 s)
Рис. 4.4.9.3.3. Пример вычисления rtt
Рис. 4.4.9.3.4. Формат пакета отчета о приеме (RR)
Формат пакета отчета о приеме (RR) аналогичен формату SR пакета за исключением того, что поле типа содержит код 201 и опущены первые пять слов информации об отправителе (это NTP/RTP временные метки, а также число пакетов и октетов отправителя). Остальные поля имеют то же самое значение, как и для пакета SR.
Когда нет информации об отправке или приеме, в начало составного RTCP-пакета вставляется пустой RR-пакет (RC = 0).
Профайл должен определять специфические для приложения расширения в докладах получателей и отправителей, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно сообщаться. Этот метод предпочтительнее, чем описание нового типа RTCP-пакета, так как не требует дополнительных издержек:
- меньше октетов в пакете (нет rtcp-заголовка или поля SSRC);
- проще и быстрее разбор, так как приложение, работающее под управлением профайла, будет запрограммировано всегда ожидать поля расширения с известным их положением в пакетах отчетов.
Если необходима дополнительная информация, она должна быть включена в первую очередь в расширение для отчета отправителя, но не будет присутствовать в отчетах о приеме. Если должна быть подключена информация о получателях, эти данные могут структуризоваться в виде массива блоков дополнительно к существующему массиву блоков-отчетов, т.е., число блоков будет задано полем RC.
Ожидается, что качество обратной связи важно не только для отправителя и получателей, но и для независимых мониторов. Отправитель может модифицировать свою передачу на основе обратной связи, получатели могут определить, являются ли проблемы локальными, региональными или глобальными. Менеджер сети может использовать независимые мониторы, которые получают только RTCP-пакеты, а не соответствующие информационные RTP-пакеты, для оценки эксплуатационных параметров своей сети для мультикастного обмена.
На основе информации отправителя независимый монитор может вычислить усредненное значение потока данных, не получая этих данных. Если можно предположить независимость вероятности потери пакета от его размера, тогда число полученных пакетов, умноженное на средний размер поля данных, может дать оценку для пропускной способности получателя.
Для RTCP допустимо расщепление составных пакетов на пакеты нижележащего уровня, один зашифрованный и один открытый. Например, информация SDES может быть зашифрована, в то время как отчеты о приеме будут посылаться открыто для обеспечения мониторинга. В примере, представленном на рис. 4.4.9.3.5 информация SDES должна быть присоединена к RR-пакету, не содержащему отчета. Таким образом, соблюдается правило о том, что все составные пакеты начинаются с SR или RR пакетов.
Рис. 4.4.9.3.5. Зашифрованный и незашифрованный RTCP-пакеты (#ssrc)
SDES: RTCP-пакет описания источника
Рис. 4.4.9.3.6. Формат пакета SDES
Пакет SDES состоит из заголовка и нескольких фрагментов, каждый из которых содержит элементы описания источника, соответствующего данному фрагменту (число фрагментов может быть равно нулю).
Поля версия (v), заполнитель (p) и длина имеют то же назначения что и в случае SR-пакетов.
Тип пакета (pt): 8 бит
Содержит константу 202, которая идентифицирует данный пакет как RTCP SDES.
Число источников (SC): 5 бит
Число фрагментов SSRC/CSRC, содержащихся в данном SDES-пакете. Значение нуль допустимо, но бесполезно.
Каждый фрагмент состоит из идентификатора SSRC/CSRC, за которым следует список элементов описания источника SSRC/CSRC (число элементов может равняться нулю). Каждый фрагмент начинается на 32-битовой границе. Каждый элемент состоит из 8-битового поля типа, 8-битового поля числа октетов, характеризующего длину текста, исключая эти 2 октета заголовка, и собственно текста. Заметьте, что текст не может содержать более 255 октетов, но это вполне согласуется с требованиями ограничений на полосу, выделяемую для RTCP-пакетов.
Текст кодируется согласно требованиям UTF-2, описанным в стандарте 10646 [5,6], annex F ISO. Эта кодировка известна также под названием UTF-8 или UTF-FSS. Она описана в документе "File System Safe UCS Transformation Format (FSS_UTF)", “X/open preliminary specification”, документ номер P316 и “Unicode Technical Report #4". US-ASCII являются модификациями данного кодирования и требуют определенных доработок. Присутствие многооктетного кодирования задается путем установления старшего бита октета символа равным 1.
Описания элементов плотно прилегают друг к другу, т.е., их описания не выравниваются на 32-битовые границы путем индивидуального заполнения. Текст не завершается нулем, так как мультиоктетное кодирование может включать в себя нули. Список элементов в каждом фрагменте завершается одним или несколькими нулевыми октетами, первый из которых интерпретируется как тип элемента нуль, завершающий список, а последующие служат для заполнения до 32-битовой границы. Фрагменты, содержащие только нулевые элементы (4 нулевых октета), допускаются, но бесполезны.
Оконечные системы посылают один пакет SDES, содержащий их собственный идентификатор источника (то же, что и SSRC в фиксированных RTP-заголовках). Смеситель посылает один пакет SDES, содержащий фрагмент для каждого источника, от которого поступает SDES-информация, или несколько SDES-пакетов описанного выше формата в случае, когда число таких источников больше 31.
Из числа SDES-элементов только cname является обязательным. Некоторые элементы, описанные ниже, могут оказаться полезными только для определенных профайлов, но типы элементов выделяются из общего кодового пространства, с тем чтобы обеспечить совместную работу различных приложений. Дополнительные элементы могут быть определены в профайле путем регистрации их кодов IANA.
cname: Канонический идентификатор конечной системы (рис. 4.4.9.3.7).
Рис. 4.4.9.3.7. Формат Cname
Идентификатор cname имеет следующие свойства:
Следовательно, cname должно по возможности получаться алгоритмически, а не вводиться вручную. Чтобы удовлетворить этому требованию следует использовать описанный ниже формат, если другой синтаксис или семантика не задана. Элемент cname должен иметь формат "user@host", или "host", если имя пользователя не доступно, как это бывает в однопользовательских системах. Для обоих форматов, "host" является либо полным именем домена ЭВМ, откуда поступают данные в реальном масштабе времени, форматированные согласно требованиям документов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [9]; или стандартным ASCII-представлением цифрового, сетевого адреса интерфейса ЭВМ, используемого для RTP-обмена. Например, стандартное ASCII-представление IP-адреса (версия 4) в "точечно-цифровом" виде. Стандартное полное имя домена более удобно для человека и исключает необходимость посылать в дополнение элемент Name, но в некоторых обстоятельствах его может быть трудно или невозможно получить. Примерами могут служить "dwarf@sleepy.beauty.com" или "dwarf@192.166.148.9" для мультипользовательских систем. В системах, где нельзя получить имя пользователя, можно применить “sleepy.beauty.com" или "192.166.148.9".
Имя пользователя должно иметь форму, которая может быть использована в запросах "Finger" или "Talk", т.е., это скорее имя, вводимое при аутентификации, чем истинное имя пользователя. Имя ЭВМ не обязательно идентично электронному почтовому адресу участника.
Этот синтаксис не обеспечит уникальность имени в тех случаях, когда приложение позволяет пользователю сформировать несколько источников на своей ЭВМ. Такое приложение должно полагаться на SSRC для дополнительной идентификации источника, или на профайл, для которого приложение должно будет специфицировать синтаксис идентификаторов cname.
Если каждое приложение создает свои cname независимо, в результате можно получить дублирующие имена. Если необходимо осуществить связь между сессиями, работающими в разных средах, должны быть использованы специальные средства, которые с одной стороны обеспечат уникальность имен, а с другой припишут идентичные имена источникам, размещенным в одной ЭВМ, но работающих с разными средами.
Разработчики приложений должны учитывать возможность того, что использование сетевого адреса, например, для Net-10 (описано в документе RFC-1597 [10]) может привести к появлению имен дубликатов. Дубликаты имен могут возникать, когда ЭВМ с частными адресами, не имеющие выхода в Интернет, переадресуют свои RTP-пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-1627 [11].) Для того чтобы разрешать такие конфликты приложение должно иметь средства для выработки и присвоения уникальных имен cname.
Name: Имя пользователя (рис. 4.4.9.3.8).
Рис. 4.4.9.3.8. Формат элемента Name
Это настоящее имя, используемое для описания источника, напр., "Иван Дурак, russia.com". Оно может быть сформировано пользователем в произвольной форме. Для приложений типа конференций эта форма имени может быть наиболее желательной при отображении в списках участников и, следовательно, может посылаться более часто, чем любые другие элементы помимо cname. Такой приоритет может быть установлен профайлом. Значение name предполагается неизменным, по крайней мере в пределах сессии. В то же время не требуется, чтобы оно было уникальным для группы участников сессии.
Email: Адрес электронной почты (рис. 4.4.9.3.9).
Рис. 4.4.9.3.9. Формат элемента Email
Адрес электронной почты должен иметь формат, согласующийся с требованиями документа RFC-822 [12], например, "yuri.semenov@itep.ru". Значение элемента Email предполагается неизменным в пределах сессии.
phone: Телефонный номер
Рис. 4.4.9.3.10. Формат элемента phone
Телефонный номер должен иметь формат с символом плюс, замещающим международный код. Например, , "+7 095 129 9442" для номера в России.
LOC: Географический адрес пользователя
Рис. 4.4.9.3.11. Формат элемента LOC
Различная детализация этого элемента сильно зависит от приложения. Для использования во время конференций строки типа "Zuzino, Moscow" может быть достаточно, в то время как для активной системы поиска сотрудников приемлемой может стать строка "room 322, itep bl 180". Значение LOC предполагается неизменным на время сессии. Исключение могут составлять мобильные ЭВМ.
TOOL: Имя приложения или программного средства
Рис. 4.4.9.3.12. Формат элемента TOOL
Строка, сообщающая имя и, возможно, версию приложения, формирующего поток, напр., "VC 2.1". Эта информация может быть полезной для отладочных целей и сходна с SMTP-заголовками. Предполагается, что значение TOOL остается постоянным в течение сессии.
Note: Уведомление/статус
Рис. 4.4.9.3.13. Формат элемента Note
Для этого элемента предлагается следующая семантика (она может быть определена профайлом). Элемент note предназначен для сообщений, характеризующих текущее состояние источника, напр., "on the phone, can't talk". Или, во время семинара этот элемент может быть использован для передачи темы обсуждения. Он может служить только для передачи необычной информации и не должен включаться в систематическую рассылку, так как замедлит скорость передачи отчетов. В частности, он не должен включаться в конфигурационный файл пользователя.
Так как может быть важно отобразить элемент Note (в случае, когда он активен), скорость, с которой передаются другие элементы (кроме cname), такие как Name, может быть уменьшена с тем, чтобы передать элемент Note. Когда сообщение становится не актуальным, элемент note передается еще несколько раз с той же частотой, но с длиной строки, равной нулю. Однако, получатели должны рассматривать элемент Note потерявшим актуальность, если они не получают его, например, на протяжении 20-30 RTCP-интервалов.
PRIV: Элемент частного расширения SDES
Рис. 4.4.9.3.14. Формат элемента расширения PRIV
Этот элемент используется, для того чтобы определить экспериментальные или специфические для приложения расширения SDES. Элемент содержит префикс, включающий в себя субполя длины и строки префикса, за которыми следует строка значения, занимающая остальное пространство элемента, и несущая необходимую информацию. Поле длины префикса занимает 8 бит. Строка префикса представляет собой имя, определенное человеком, который сформировал элемент PRIV. Это имя должно быть уникальным и никакой другой элемент priv не может иметь такое же. Разработчик приложения может выбрать имя приложения плюс, если необходимо, дополнение.
Заметьте, что префикс занимает некоторое место, из числа 255 октетов элемента, по этой причине желательно, чтобы он был короче.
Префиксы SDESpriv не нужно регистрировать в IANA. Если некоторая форма элемента PRIV окажется достаточно универсальной, она должна быть приписана некоторому регулярному типу элемента SDES, зарегистрированному IANA, так что необходимость в префиксе отпадет. Это упростит использование и увеличит эффективность передачи.
Bye: Пакет завершения сессии RTCP
Рис. 4.4.9.3.15. Формат пакета Bye
Пакет Bye указывает на то, что один или более источников покинули сессию.
Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов
Тип пакета (PT): 8 бит
Содержит код 203, который указывает на то, что это RTCP пакет Bye.
Число источников (SC): 5 бит
Число фрагментов SSRC/CSRC, содержащихся в данном bye-пакете. Значение нуль допустимо, но бесполезно.
Если пакет bye получен смесителем, он переадресует этот пакет с идентификаторами SSRC/CSRC без изменений. Если сам смеситель отключается, он должен послать пакет Bye, перечислив все источники, вносившие вклад в поток, с которым он работал, а также свой идентификатор SSRC. Опционно пакет Bye может содержать 8-битовое число октетов, за которым следует текст соответствующей длины, объясняющий причину отключения, например "camera malfunction" или "RTP loop detected". Строка имеет то же кодирование, что описано для SDES. Если строка заполняет пакет до очередной 32-битовой границы, то в конце ее не будет нуля. В противном случае, пакет Bye дополняется нулевыми октетами.
app: RTCP-пакет, определенный приложением
Рис. 4.4.9.3.16. Формат пакета, задаваемого приложением
Пакет APP предназначен для экспериментального использования при разработке новых приложений или новых функций. Здесь не требуется регистрация типа пакета. APP-пакеты с не узнанными именами должны игнорироваться. После тестирования, когда предполагается широкое использование, рекомендуется новый APP-пакет переопределить без субтипа и поля имени, после чего его следует зарегистрировать в IANA (Internet Assigned Numbers Authority), как новый тип RTCP-пакета.
Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов.
Субтип: 5 бит
Может использоваться в качестве субтипа, допуская описание набора APP-пакетов с уникальным именем, или для любых данных, специфических для конкретного приложения.
Тип пакета (PT): 8 бит
Содержит код 204, который указывает на то, что это RTCP пакет APP.
Имя: 4 октета
Имя, выбираемое разработчиком, который определил набор APP-пакетов. Это имя должно быть уникальным и не совпадать ни с одним другим именем другого APP-пакета данного приложения. Разработчик приложения может использовать для данной цели имя приложения. При этом новые типы пакетов приложения будут отличаться друг от друга кодом субтипа. Имя интерпретируется как последовательность четырех ASCII-символов, где строчные и прописные буквы не являются тождественными.
Поле информация, зависящая от приложения имеет переменную длину.
Информация, зависящая от приложения используется в APP-пакетах опционно. Она интерпретируется приложением, а не самим RTP. Размер поля должен быть кратным 32 бит.
Обработка RTCP в трансляторах
Кроме переадресации информационных пакетов (иногда с некоторой модификацией) трансляторы и мультиплексоры должны также обрабатывать RTCP-пакеты. Во многих случаях они разделяют на составные части комбинированные RTCP-пакеты, полученные от оконечных систем, собирают SDES-информацию и модифицируют SR или RR-пакеты. Пересылка этой информации может инициироваться приходом пакета или RTCP-таймером транслятора или смесителя.
Транслятор, который не модифицирует информационные пакеты, например такой, который осуществляет связь между мультикастными и уникастными адресами, может просто переадресовывать RTCP-пакеты. Транслятор, который каким-то образом модифицирует поле данных, должен выполнить соответствующие преобразования в SR и RR-информации, так чтобы она отражала качество приема. Такие трансляторы не должны просто переадресовывать RTCP-пакеты. Вообще транслятор не должен объединять SR и RR-пакеты от различных источников, так как это ухудшит точность измерения задержки распространения, использующего поля LSR и DLSR.
Информация отправителя SR. Транслятор не генерирует своей собственной информации отправителя, а переадресует SR-пакеты, полученные из одной области и адресованные в другие области. SSRC остается неизменным, но, если необходима трансляция, информация отправителя должна быть модифицирована. Если транслятор изменяет кодировку данных, он должен изменить поле число октетов отправителя. Если он объединяет несколько информационных пакетов в один, то нужно изменить поле число пакетов отправителя. Если он изменяет частоту временных меток, нужно модифицировать поле временная метка RTP в SR-пакете.
Блоки отчетов о приеме SR/RR: Транслятор переадресует доклады о приеме, полученные из одной области сети в другие. Заметим, что эти сообщения движутся в направлении противоположном данным. SSRC при этом остается неизменным. Если транслятор объединяет несколько информационных пакетов в один выходной пакет, и, следовательно, изменяет номер по порядку, он должен позаботиться о модификации полей потерянных пакетов и наибольший номер из числа полученных пакетов.
Транслятор не нуждается в своем собственном SSRC-идентификаторе, но может и завести такой идентификатор, для того чтобы посылать отчеты о том, что получено. Такие отчеты будут посылаться во все области сети, подключенные к транслятору.
SDES. Трансляторы осуществляют переадресацию без изменения SDES-информации, полученной из сетевых областей, участвующих в сессии. Но они могут, например, решить отфильтровывать некоторую информацию, если этого требуют ограничения пропускной способности. Транслятор, который генерирует свои собственные RR-пакеты, должен посылать SDES CNAME-информацию о самом себе в область сети, куда он шлет эти RR-пакеты.
BYE. Трансляторы переадресуют пакеты BYE без изменений. Трансляторы, имеющие свой собственный SSRC должны генерировать пакеты BYE с этим SSRC-идентификатором, если они намереваются прекратить свою работу по переадресации.
APP. Трансляторы переадресовывают APP-пакеты без каких-либо изменений.
Обработка RTCP в смесителях
Так как смеситель генерирует, свой собственный информационный поток, он не пропускает через себя SR или RR-пакеты и вынужден формировать новые пакеты для отправки в обоих направлениях.
Информация отправителя SR. Смеситель не пропускает через себя данные об отправителе от источников, которые он объединяет, так как характеристики потока при смешении кардинально меняются. Как источник синхронизации смеситель генерирует свои собственные SR-пакеты с информацией отправителя и посылает их в том же направлении, что и смешанный поток.
Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую.
SDES. Смесители обычно переадресуют без изменений SDES-информацию, которую они получают из сетевых областей зоны обслуживания, но могут отфильтровывать любую SDES-информацию помимо CNAME в случае ограничения полосы пропускания. CNAME должны доставляться, чтобы обеспечить работу по обслуживанию столкновений идентификаторов SSRC. (Идентификатор в списке CSRC, сгенерированный смесителем может вызвать столкновение с SSRC-идентификатором, сформированным оконечной системой.) Смеситель должен послать SDES CNAME информацию о самом себе той сетевой области, куда он посылает SR или RR пакеты.
Так как смесители не переадресуют SR или RR пакеты, они обычно извлекают SDES-пакеты из составных RTCP-пакетов. Для того чтобы минимизировать издержки, фрагменты из SDES-пакетов могут быть уложены в один SDES-пакет, который вкладывается в SR или RR пакет, посылаемый смесителем.
Смеситель, который не вводит идентификаторы CSRC, может также воздерживаться от пересылки SDES CNAME. В этом случае пространства идентификаторов SSRC для обоих сетевых областей оказываются независимыми.
BYE. Смесители должны переадресовывать пакеты BYE. Они должны генерировать пакеты BYE со своим собственным идентификатором SSRC, если они намериваются прервать пересылку пакетов.
APP. Обработка APP-пакетов смесителями зависит от вида приложения.
Таблица 4.4.9.3.1. Типы пакетов RTCP
Сокращенное название |
Имя |
Значение |
| SR | sender report – сообщение отправителя | 200 |
| RR | receiver report – сообщение получателя | 201 |
| SDES | source description – описание источника | 202 |
| BYE | goodbye - завершение | 203 |
| APP | application-defined – определен приложением | 204 |
Другие константы определены IANA. Экспериментаторам предлагается зарегистрировать числа, которые им нужны, а затем аннулировать регистрацию, если необходимость в них отпадет.
Таблица 4.4.9.3.2. Типы SDES
Сокращенное название |
Имя |
Значение |
| END | Конец списка SDES | 0 |
| CNAME | Каноническое имя | 1 |
| NAME | Имя пользователя | 2 |
| Электронный адрес пользователя | 3 | |
| PHONE | Телефонный номер пользователя | 4 |
| OC | geographic user location | 5 |
| TOOL | Имя приложения или программного средства | 6 |
| NOTE | notice about the source | 7 |
| PRIV | Частные расширения | 8 |
Период отчетов RTCP. Профайл должен специфицировать, какие значения констант будут использоваться для вычисления периода посылки RTCP докладов. Это доля полосы пропускания выделенная для RTCP, минимальный период посылки отчетов.
Расширения SR/RR. Секция расширения может быть определена для RTCP SR и RR пакетов, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно передаваться.
Проверка корректности заголовка RTCP
Пакеты RTCP подвергаются следующим проверкам.
Фрагмент приведенной ниже программы выполняет все рассмотренные проверки (текст взят из ссылки, приведенной в начале раздела). Тип пакета для последующих пакетов не проверяется, так как не известный тип пакета должен игнорироваться.
u_int32 len; /* Длина составного RTCP пакета в словах */
rtcp_t *r; /* заголовок RTCP */
rtcp_t *end; /* Конец составного RTCP пакета */
if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
/* что-то не в порядке с форматом пакета */
}
end = (rtcp_t *)((u_int32 *)r + len);
do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
while (r < end && r->common.version == 2);
if (r != end) {
/* что-то не в порядке с форматом пакета */
}
Генерирование пакетов SDES RTCP
Эта функция формирует фрагмент SDES, состоящий из элементов argc, взятых из массивов type, в буфере b.
char *rtp_write_sdes(char *b, u_int32 src, int argc,
rtcp_sdes_type_t type[], char *value[],
int length[])
{
rtcp_sdes_t *s = (rtcp_sdes_t *)b;
rtcp_sdes_item_t *rsp;
int i;
int len;
int pad;
/* SSRC header */
s->src = src;
rsp = &s->item[0];
/* SDES items */
for (i = 0; i < argc; i++) {
rsp->type = type[i];
len = length[i];
if (len > RTP_MAX_SDES) {
/* неверная длина, возможно нужны другие действия */
len = RTP_MAX_SDES;
}
rsp->length = len;
memcpy(rsp->data, value[i], len);
rsp = (rtcp_sdes_item_t *)&rsp->data[len];
}
/* завершить конечным маркером и заполнителем на очередной 4-октетной границе */
len = ((char *) rsp) - b;
pad = 4 - (len & 0x3);
b = (char *) rsp;
while (pad--) *b++ = RTCP_SDES_END;
return b;
}
Разбор пакетов RTCP SDES
Эта функция осуществляет разбор пакета SDES, вызывая функции find_member() для поиска указателя на информацию для члена сессии с идентификатором SSRC и member_sdes() для запоминания новой информации SDES для этого участника. Этой функции необходим указатель на заголовок пакета RTCP.
void rtp_read_sdes(rtcp_t *r)
{
int count = r->common.count;
rtcp_sdes_t *sd = &r->r.sdes;
rtcp_sdes_item_t *rsp, *rspn;
rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
((u_int32 *)r + r->common.length + 1);
source *s;
while (--count >= 0) {
rsp = &sd->item[0];
if (rsp >= end) break;
s = find_member(sd->src);
for (; rsp->type; rsp = rspn ) {
rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
if (rspn >= end) {
rsp = rspn;
break;
}
member_sdes(s, rsp->type, rsp->data, rsp->length);
}
sd = (rtcp_sdes_t *)
((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
}
if (count >= 0) {
/* некорректный формат пакета */
}
}
Вычисление периода рассылки RTCP
Следующая функция в качестве результата выдает время между посылками RTCP-пакетов, измеренное в секундах. Она должна вызываться после посылки одного составного RTCP-пакета для вычисления времени до посылки следующего пакета. Эта функция должна также вызываться для вычисления времени посылки первого RTCP-пакета при запуске. Это исключает любые кластеры RTCP-пакетов, если приложение запущено в нескольких узлах одновременно, например, в результате объявления об открытии сессии.
Параметры имеют следующий смысл:
rtcp_bw: Предельная полоса RTCP, т.е., полная пропускная способность, которая будет использоваться для RTCP-пакетов всеми участниками сессии, выраженная в октетах в секунду. Она должна быть порядка 5% от "полосы сессии", этот параметр задается при конфигурировании приложения.
senders: Число активных отправителей на момент посылки последнего отчета, известно из конструкции отчетов получателя.
members: Оценка числа членов сессии, включая нас самих. Инкрементируется, когда мы обнаруживаем новых членов сессии при получении RTP или RTCP-пакетов, и декрементируется, когда какой-либо участник покидает сессию (послав RTCP BYE) или он объявлен таковым по тайм-ауту (рекомендуемое время 30 минут). При первом вызове этот параметр должен иметь значение 1.
we_sent: Флаг, который равен true, если мы послали данные за время последних двух интервалов RTCP. Если флаг равен true, составной только что посланный пакет RTCP содержит SR пакет.
packet_size: Размер составного только что посланного пакета RTCP, в октетах, включая сетевую инкапсуляцию (напр., 28 октетов для UDP поверх IP).
avg_rtcp_size: Указатель оценщика размера составных пакетов RTCP; инициализируется и актуализуется для только что посланного пакета этой функцией, актуализуется также идентичной строкой программы приема пакетов RTCP для каждого пакета RTCP, полученного от другого участника сессии.
initial: Флаг, который равен true для первого вызова при инициализации с целью вычисления момента посылки первого отчета.
#include
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
int packet_size,
int *avg_rtcp_size,
int initial)
{
/*
* Минимальное время между пакетами RTCP от данного узла (в секундах). Это время
* предотвращает группирование отчетов, когда в сессии участвует малое число
* участников. Это препятствует чрезмерному уменьшению интервалов межу отчетами.
*/
double const RTCP_MIN_TIME = 5.;
/*
* Доля полосы RTCP, которая должна быть поделена между активными участниками.
* (Эта доля была выбрана так, чтобы в типовой сессии с одним или двумя
* активными отправителями, вычисленный период посылки отчетов был примерно
* равен минимальному интервалу между отчетами. Доля получателя должна равняться
* 1 – доля отправителя.
*/
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
/*
* Коэффициент преобразования (сглаживающая константа) для полосового
* фильтра, который используется при оценке среднего размера RTCP пакетов.
*/
double const RTCP_SIZE_GAIN = (1./16.);
double t; /* интервал */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* число участников, используемое при вычислении */
/*
* Самый первый вызов приложения использует вдвое меньшую
* минимальную задержку для ускорения оповещения, в то же время оставляя
* некоторое время до отчета для рэндомизации и получения информации
* о других источниках. Таким образом, установление корректного периода
* отчетов произойдет быстрее. Средний размер RTCP пакета
* устанавливается в начальный момент равным 128 октетам
* (предполагается, что все остальные генерируют SR вместо RR:
* 20 IP + 8 UDP + 52 SR + 48 SDES CNAME октетов).
*/
if (initial) {
rtcp_min_time /= 2;
*avg_rtcp_size = 128;
}
/*
* Если имелись активные отправители, надо им дать
* по крайней мере минимальную долю полосы RTCP.
* В противном случае все участники будут делить полосу RTCP поровну
*/
n = members;
if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) {
if (we_sent) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION;
n = senders;
} else {
rtcp_bw *= RTCP_RCVR_BW_FRACTION;
n -= senders;
}
}
/*
* Актуализация оценки среднего размера пакета отчета с учетом
* только что посланного пакета.
*/
*avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN;
/*
* Эффективное число узлов, умножаем на средний размер пакета отчета
* и получаем полное число посланных октетов, если каждый из узлов
* посылает отчет. Деля это число на эффективную полосу,
* получаем средний временной интервал посылки пакетов-отчетов.
*/
t = (*avg_rtcp_size) * n / rtcp_bw;
if (t < rtcp_min_time) t = rtcp_min_time;
/*
* Для того чтобы избежать всплесков трафика из-за непреднамеренной
* синхронизации с другими узлами мы выбираем следующий интервал
* отчета равным случайному числу с равномерным распределением в
* диапазоне 0.5*t - 1.5*t.
*/
return t * (drand48() + 0.5);
}
Библиография
| [1] | I. Busse, B. Deffner, and H. Schulzrinne, " Dynamic QoS control of multimedia applications based on RTP," Computer Communications , Jan. 1996. |
| [2] | S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, Sept. 1993. also in [24] |
| [3] | J. A. Cadzow, Foundations of digital signal processing and data analysis New York, New York: Macmillan, 1987 |
| [4] | International Standards Organization, "ISO/IEC DIS 10646-1:1993 information technology -- universal multiple-octet coded character set (UCS) -- part I: Architecture and basic multilingual plane," 1993 |
| [5] | The Unicode Consortium, The Unicode Standard New York, New York: Addison-Wesley, 1991 |
| [6] | Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987 |
| [7] | Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987 |
| [8] | Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989 |
| [9] | Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994 |
| [10] | Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon Graphics, Inc., July 1994 |
| [11] | Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982 |
| [12] | W. Feller, An Introduction to Probability Theory and its Applications, Volume 1 , vol. 1. New York, New York: John Wiley and Sons, third ed., 1968 |
