RTP и RTCP: протоколы для IP-телефонии

4.4. Пакет описания источника (SDES)

Пакет SDES протокола RTCP состоит из заголовка и нуля или более частей, каждая из которых включает пункты, описывающие источник, идентифицированный в этой части. Форматы данных пунктов рассмотрены в последующих разделах. Заголовок пакета включает следующие поля.

Версия (V), дополнение (P), длина: Данные поля соответствуют полям пакета SR (см. раздел 4.3.1).

Тип пакета (PT — packet type): 8 бит. Содержит константу 202 для идентификации пакета, как пакета SDES протокола RTCP.

Счетчик источника (SC — source count): 5 бит. Число частей SSRC/CSRC, содержащихся в этом пакете SDES. Нулевая величина является допустимой, но неиспользуемой.

Каждая часть пакета SDES состоит из идентификатора SSRC/CSRC, за которым следует список из нуля или более пунктов с информацией о SSRC/CSRC. Каждая часть выравнена по 32-разрядной границе. Каждый пункт состоит из восьмиразрядного поля типа, восьмиразрядного счетчика октетов, указывающего на длину текста (не включая этот двухоктетный заголовок), и непосредственно текста. Заметим, что размер текст не должен превышать 255 октетов, это обусловливается необходимостью ограничения затрат полосы пропускания для RTCP.

Текст кодируется согласно стандарта UTF-2, описанного в приложении F стандарта ISO 10646. Этот тип кодирования также известен, как UTF-8 или UTF-FSS. Код US-ASCII является подмножеством этого типа кодирования и не требует никакой дополнительной обработки. Использование многооктетного кодирования обозначается уставкой в единицу старшего бита символа.

Пункты передаются непрерывно, то есть они индивидуально не дополняются до 32-разрядной границы. Текст не должен заканчиваться нулем. Список пунктов в каждой части заканчивается одним или более нулевых октетов, первый из которых интерпретируется как нулевой тип пункта для обозначения конца списка, а остальные необходимы для дополнения до 32-разрядной границы. Часть с нулевыми пунктами (четыре нулевых октета) допустима, но не используема.

Оконечные системы посылают один пакет SDES, содержащий их собственный идентификатор источника (такой же, как идентификатор SSRC в фиксированном заголовке протокола RTP). Микшер посылает один пакет SDES, содержащий часть для каждого включаемого источника, от которого он получает информацию SDES, или множество полных пакетов SDES в формате, приведенном выше, если имеются более, чем 31 таких источников.

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

4.4.1. Пункт канонического имени оконечной точки (CNAME)

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

Так как выбираемый случайным образом идентификатор SSRC может в процессе работы изменяться при обнаружении конфликта или перезапуска программы, то для обеспечения идентификации источника сообщений требуются сведению о его неизменяемом каноническом имени (требуется пункт CNAME в пакете SDES).

Как и идентификатор SSRC, идентификатор CNAME также должен быть уникальным для всех участников в рамках одного сеанса связи RTP.

Чтобы обеспечить взаимодействие множества мультимедийных программных средств, используемых одним участником (для каждой программы — свой сеанс RTP), этот участник должен иметь единый идентификатор CNAME.

Когда это возможно, CNAME следует получать алгоритмически, а не вводить вручную. Пункт CNAME должен иметь следующий формат (если только профиль не определяет альтернативный синтаксис или семантику): «пользователь@хост» или «хост» (если имя пользователя отсутствует, как для систем с единственным пользователем). Для обоих форматов «хост» - это или полное доменное имя хоста, являющегося источником данных реального времени, которое формируется согласно RFC 1034, RFC 1035 и п.2.1 из RFC 1123; или стандартное представление в коде ASCII числового адреса хоста. Например, стандартное ASCII- представление адреса IP версии 4 — это четверка десятичных цифр, разделенных точками. Другие типы адреса, как ожидается, будут иметь представления ASCII, которые являются взаимно уникальными. Полное доменное имя более удобно для человеческого восприятия и, кроме того, может устранить потребность в пересылке пункта NAME, но в некоторых случаях его надежное использование может быть затруднено или невозможно. Тогда вместо этого приложения должны использовать представление адреса в коде ASCII.

Примеры идентификатора CNAME для многопользовательской системы: «їdoe@sleepy.megacorp.com» или «doe@192.0.2.89». Примеры для системы без имени пользователя: «sleepy.megacorp.com» или «192.0.2.89». Имя пользователя должно быть именем входа в систему, а не персональным именем человека. Имя хоста не обязательно должно быть идентично имени в адресе электронной почты участника.

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

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

Разработчики прикладных программ должны сознавать, что конкретные назначения сетевых адресов (такие как назначения Net-10, предложенные в RFC 1597) могут создавать сетевые адреса, не являющиеся глобально уникальными. Это приводит к неуникальности канонических имен CNAMES, если хосты с частными адресами и без прямой IP-связи с сетью Internet направляют пакеты RTP в Internet через транслятор RTP-уровня (см. RFC 1627). Чтобы отрабатывать этот случай, приложения могут обеспечивать средства конфигурации уникального CNAME.

4.4.2. Пункт имени пользователя (NAME)

Пункт NAME пакета SDES содержит реальное имя, используемое для описания источника, например, «John Doe, Bit Recycler, Megacorp». Оно может быть в любой определяемой пользователем форме. Для приложений типа конференцсвязи, эта форма имени может быть наиболее желательна при заполнении списков участников и, следовательно, могла бы передаваться гораздо более чаще, чем CNAME. Профили могут устанавливать подобного рода приоритеты. Значение NAME остается постоянным, по крайней мере, в течение сеанса связи. Не следует полагать, что оно обязательно будет уникальным среди всех участников сеанса связи.

4.4.3. Пункт адреса электронной почты (EMAIL)

Адрес электронной почты формируется согласно RFC 822, например, «John.Doe@megacorp.com». Величина EMAIL в течение сеанса связи остается постоянной.

4.4.4. Пункт телефонного номера (PHONE)

Номер телефона должен формироваться со знаком «плюс», заменяющим код международного префикса. Например, «+1 908 555 1212» для номера в США.

4.4.5. Пункт географического местоположения пользователя (LOC)

В зависимости от приложения, этому пункту соответствуют различные степени подробности. Для приложений конференцсвязи, такая строка, как «Murray Hill, New Jersey» может быть достаточна, в то время как, для активной системы поиска могла бы подойти строка типа «Room 2A244, AT&T BL MH». Степень детализации оставлена на откуп приложения или пользователя, но формат и содержание могут предписываться в соответствии с профилем. Значение пункта LOC для всех хостов, кроме мобильных, остается постоянным на протяжении всего сеанса связи.

4.4.6. Пункт имени приложения или средства (TOOL)

Пункт TOOL пакета SDES включает строку, содержащую имя и, возможно, версию приложения, генерирующего поток, например, «videotool 1.2». Эта информация может быть полезна для целей отладки и подобна заголовкам SMTP типа «Mailer» или «Mail-System-Version». В течение всего сеанса связи значение пункта TOOL остается постоянным.

4.4.7. Пункт заметок/статуса (NOTE)

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

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

4.4.8. Пункт частных расширений (PRIV)

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

Заметим, что префикс использует некоторое пространство в пределах общей длины пункта 255 октетов, так что он должен быть по возможности более коротким. Это средство и получаемая полоса пропускания RTCP не должны быть перегружены; оно не предназначено для удовлетворения всех требований управления связи всех приложений.

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

4.5. Пакет завершения связи (BYE)

Пакет BYE указывает, что один или более источников становятся не активными. В составе пакета имеются следующие поля.

• Поля версии (V), дополнения (P) и длины - такие же, как и для пакета SR (см. раздел 4.3.1).
• Тип пакета (PT): 8 бит. Содержит константу 203 для распознавания этого пакета, как пакета BYE протокола RTCP.
• Счетчик источника (SC): 5 бит.
• Число идентификаторов SSRC/CSRC также включено в пакет BYE. Нулевая величина допустима, но не используется.

Если пакет BYE получен микшером, то микшер передает пакет BYE с неизменным идентификатором (идентификаторами) SSRC/CSRC. Если микшер выключается, он посылает пакет BYE, содержащий все включаемые источники, с которыми он работает, а также свой собственный идентификатор SSRC. Пакет BYE может также включать (необязательно) восьми разрядный счетчик октетов, за которым передается соответствующее количество октетов текста с указанием причины завершения связи, например, «неисправность видеокамеры» или «обнаружение зацикливания RTP». Строка имеет тот же тип кодирования, что описан для SDES. Если строка не заполняет пакет до 32-разрядной границы, то она дополняется нулевыми октетами.

4.6. Пакет, определяемый приложением (APP)ss

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

Поля версии (V), дополнения (P) и длины соответствуют описаниям данных полей для пакета SR (см. раздел 4.3.1).

Подтип: 5 бит. Может использоваться как подтип для предоставления множеству пакетов APP возможности иметь одно уникальное имя или для любых данных, определяемых приложением.

Тип пакета (PT): 8 бит. Содержит константу 204 для распознавания данного пакета, как пакета APP протокола RTCP.

Имя: 4 октета. Имя, выбранное разработчиком приложения, определяет множество пакетов APP и является уникальным по отношению ко всем другим пакетам APP, которые это приложение может получать. Имя интерпретируется как последовательность четырех символов ASCII (символы верхнего и нижнего регистра при этом трактуются различно).

Данные, определяемые приложением: переменная длина. Данные, зависимые от приложения, могут появляться или не появляться в пакете APP. Они интерпретируется приложением, а не непосредственно протоколом RTP. Длина этого поля должна быть кратна 32 битам.