Алгоритмы мультимедиа

10.4. Протокол управления RTP (RTCP)

Управляющий протокол RTCP (RTP control protocol; см. RFC-3550, "RTP: A Transport Protocol for RealTime Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и применяется лишь совместно с RTP (смотри также http://book.itep.ru/4/44/rtc_4493.htm). Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. RTCP выполняет четыре функции.

1. Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных. Обратная связь может быть непосредственно полезна при адаптивном кодировании [10.1],[10.2], но эксперименты с IP-мультикастингом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP-мультикастинга сервис-провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети.
2. RTCP имеет постоянный идентификатор транспортного уровня для RTP-источника, который называется каноническим именем или CNAME. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в CNAME, чтобы отслеживать каждого из участников. Получателям также нужно CNAME, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видеоканалы.
3. Первые две функции требуют, чтобы все участники посылали RTCP-пакеты, следовательно, скорость передачи должна контролироваться и RTP мог работать с большим числом участников. При посылке каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это число используется при вычислении частоты посылки пакетов.
4. Четвертая опционная функция служит для передачи минимальной управляющей информации, например, идентификаторов участников, для графического интерфейса пользователя. Это полезно для "слабо управляемых" сессий, когда участники входят и выходят без должного контроля и без согласования параметров. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он не обязательно поддерживает все коммуникационные требования приложения.

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

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

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

SR: Отчет отправителя. Для статистики приема и передачи участников, которые являются активными отправителями

RR: Отчет получателя. Для получения статистики от участников, которые не являются активными отправителями

SDES: Элементы описания источника, включая CNAME

BYE: Отмечает прекращение участия в группе

APP: Специфические функции приложения

Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется RTP-пакетами; за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например, UDP. Не существует специального счетчика индивидуальных 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-пакеты от нескольких источников. Пример составного RTCP-пакета, который может быть сформирован смесителем, представлен на рис. 10.7. Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.

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

Рис. 10.7. Пример составного пакета RTCP

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

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

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

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

• Отправители коллективно выделяют, по крайней мере, 1/4 управляющего трафика, чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали CNAME узлов отправителей.
• Вычисленный интервал между RTCP-пакетами должен быть больше 5 сек, чтобы избежать превышения допустимого значения трафика при флуктуациях информационного потока, когда число участников мало.
• Интервалы между RTCP-пакетами варьируются случайным образом в пределах [0.5-1.5] от вычисленного значения, чтобы избежать непреднамеренной синхронизации работы участников [10.3]. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала.
• Чтобы адаптироваться к количеству пересылаемой контрольной информации, вычисляется среднее значение размера составного пакета для отправляемых и получаемых дейтограмм.

Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания 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 будет отображаться пользовательским интерфейсом приложения постоянно, в то время как E-mail может отображаться тол ько при запросе. При каждой RTCP рассылке должны посылаться RR- и SDES-пакеты. Последний содержит элемент CNAME. Для небольших сессий, работающих с минимальными периодами рассылки, это будет происходить в среднем каждые 5 секунд. Каждая третья рассылка (15 секунд) может содержать один дополнительный элемент в пакете SDES. Семь из восьми раз это будет элемент Name и каждый восьмой раз (2 минуты) — элемент E-mail.

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

RTP-получатели обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственное различие между формами отчета отправителя (SR) и получателя (RR), помимо кода типа пакета: отчет отправителя содержит 20-байтовую секцию информации об отправителе. SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отсылается пакет RR.

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

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

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

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

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

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

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

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

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

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

Длина: 16 бит

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

Длина 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_jr_i)(s_js_i)=(r_js_j)(r_is_i)

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

j=j+(|D_i-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). Это проиллюстрировано на рис. 10.9.

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

rr: RTCO-пакет отчета о приеме (RFC-1889)

Рис. 10.9. Пример вычисления RTT

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

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

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

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

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

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

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

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

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

Рис. 10.11. Зашифрованный и незашифрованный RTCP-пакеты (#ssrc)

SDES: RTCP-пакет описания источника

Рис. 10.12. Формат пакета 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 [10.5],[10.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-элементов только СNAME является обязательным. Некоторые элементы, описанные ниже, могут оказаться полезными только для определенных профайлов, но типы элементов выделяются из общего кодового пространства, чтобы обеспечить совместную работу различных приложений. Дополнительные элементы могут быть определены в профайле путем регистрации их кодов IANA.

CNAME: Канонический идентификатор конечной системы (рис. 10.13).

Рис. 10.13. Формат CNAME

Идентификатор CNAME имеет следующие свойства.

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

Следовательно, CNAME должно по возможности получаться алгоритмически, а не вводиться вручную. Чтобы удовлетворить этому требованию, следует использовать описанный ниже формат, если другой синтаксис или семантика не заданы. Элемент CNAME должен иметь формат user@host, или host, если имя пользователя не доступно, как это бывает в однопользовательских системах. Для обоих форматов host является либо полным именем домена ЭВМ, откуда поступают данные в реальном масштабе времени, форматированные согласно требованиям документов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [10.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.10]) может привести к появлению имен-дубликатов. Дубликаты имен могут возникать, когда ЭВМ с частными адресами, не имеющие выхода в Интернет, переадресуют свои RTP-пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-1627 [10.11].) Чтобы разрешать такие конфликты, приложение должно иметь средства для выработки и присвоения уникальных имен CNAME.

Name: Имя пользователя (рис. 10.14).

Рис. 10.14. Формат элемента Name

Это настоящее имя, используемое для описания источника, например, "Иван Дурак, russia.com". Оно может быть сформировано пользователем в произвольной форме. Для приложений типа конференций эта форма имени может быть наиболее желательной при отображении в списках участников и, следовательно, может посылаться более часто, чем любые другие элементы помимо CNAME. Такой приоритет может быть установлен профайлом. Значение NAME предполагается неизменным, по крайней мере, в пределах сессии. В то же время не требуется, чтобы оно было уникальным для группы участников сессии.

Email: Адрес электронной почты (рис. 10.15).

Рис. 10.15. Формат элемента Email

Адрес электронной почты должен иметь формат, согласующийся с требованиями документа RFC-822, например, ivan.durak@itep.ru. Значение элемента Email предполагается неизменным в пределах сессии.

phone: Телефонный номер

Рис. 10.16. Формат элемента phone

Телефонный номер должен иметь формат с символом плюс, замещающим международный код. Например, +7 095 129 9442 для номера в России.

LOC: Географический адрес пользователя

Рис. 10.17. Формат элемента LOC

Различная детализация этого элемента сильно зависит от приложения. Для использования во время конференций строки типа "Zuzino, Moscow" может быть достаточно, в то время как для активной системы поиска сотрудников приемлемой может стать строка "room 205, itep bl 143". Значение LOC предполагается неизменным на время сессии. Исключение могут составлять мобильные ЭВМ.

TOOL: Имя приложения или программного средства

Рис. 10.18. Формат элемента TOOL

Строка, сообщающая имя и, возможно, версию приложения, формирующего поток, например, "VC 2.1". Эта информация может быть полезной для отладочных целей и сходна с SMTP-заголовками. Предполагается, что значение TOOL остается постоянным в течение сессии.

Note: Уведомление/статус

Рис. 10.19. Формат элемента Note

Для этого элемента предлагается следующая семантика (она может быть определена профайлом). Элемент NOTE предназначен для сообщений, характеризующих текущее состояние источника, например, "on the phone, can't talk". Или, во время семинара этот элемент может быть использован для передачи темы обсуждения. Он может служить только для передачи необычной информации и не должен включаться в систематическую рассылку, так как замедлит скорость передачи отчетов. В частности, он не должен включаться в конфигурационный файл пользователя.

Так как может быть важно отобразить элемент Note (в случае, когда он активен), скорость, с которой передаются другие элементы (кроме CNAME), может быть уменьшена ради того, чтобы передать элемент Note. Когда сообщение становится не актуальным, элемент NOTE передается еще несколько раз с той же частотой, но с длиной строки, равной нулю. Однако получатели должны рассматривать элемент Note как потерявший актуальность, если они не получают его, например, на протяжении 20-30 RTCP-интервалов.

PRIV: Элемент частного расширения SDES

Рис. 10.20. Формат элемента расширения PRIV

Этот элемент используется, чтобы описать экспериментальные или специфические для приложения расширения SDES. Элемент содержит префикс, включающий в себя субполя длины и строки префикса, за которыми следует строка значения, занимающая остальное пространство элемента и несущая необходимую информацию. Поле длины префикса занимает 8 бит. Строка префикса представляет собой имя, определенное человеком, который сформировал элемент PRIV. Это имя должно быть уникальным, и никакой другой элемент PRIV не может иметь такое же. Разработчик приложения может выбрать имя приложения и, если необходимо, субтип дополнения.

Заметьте, что префикс занимает некоторое количество из 255 октетов элемента, поэтому желательно, чтобы он был короче.

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

Bye: Пакет завершения сессии RTCP

Рис. 10.21. Формат пакета Bye

Пакет Bye указывает на то, что один или более источников покинули сессию.

Поля версия (V), заполнитель (P) и длина имеют те же назначения, что и в случае SR-пакетов

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

Содержит код 203, который указывает на то, что это RTCP пакет Bye.

Число источников (SC): 5 бит

Число фрагментов SSRC/CSRC, содержащихся в данном пакете. Значение нуль допустимо, но бесполезно.

Если пакет bye получен смесителем, он переадресует этот пакет с идентификаторами SSRC/CSRC без изменений. Если сам смеситель отключается, он должен послать пакет Bye, перечислив все источники, вносившие вклад в поток, с которым он работал, а также свой идентификатор SSRC. Опционно пакет Bye может содержать 8-битовое число октетов, за которым следует текст соответствующей длины, объясняющий причину отключения, например, "camera malfunction" или "RTP loop detected". Строка имеет то же кодирование, что описано для SDES. Если строка заполняет пакет до очередной 32-битовой границы, то в конце ее не будет нуля. В противном случае, пакет Bye дополняется нулевыми октетами.

APP: RTCPпакет, определенный приложением

Рис. 10.22. Формат пакета, задаваемого приложением

Пакет 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 бит.