r=*(Поле «r=» определяет интервалы повторения сессий; ноль или большее число повторов)

r=<repeat interval><active duration><list of offsets from start-time>

Например, если сессия активна в 10 утра в понедельник и в 11 утра во вторник в течение одного часа каждую неделю в течение 3х месяцев, тогда <start time> в соответствующем поле «t=» должно представлять собой NTP представление: 10 часов утра первого понедельника, <repeat interval> должен быть равен 1 неделе, <active duration> должен быть 1 час, и сдвиги (offsets) должны быть 0 и 25 часов. Соответствующие поля «t=» времени окончания сессии должно иметь NTP представление окончания последней сессии через 3 месяца.

По умолчанию все поля заполняются в секундах, так поля “r=” и “t=” могут содержать:

t = 3034423619 3042462419

r = 604800 3600 0 90000

Чтобы сделать сообщение более компактным, время также может быть указано в днях, часах и минутах. Синтаксис для этого – число, непосредственно следующее за одиночной буквой, соответствующей конкретному случаю. Дробные единицы не разрешены – вместо них должны использоваться меньшие единицы времени. Допустимы следующие буквы определения единиц времени:

d – день (86400 секунд)

h – час (3600 секунд)

M – минута (60 секунд)

s – секунда (разрешена для полноты, но не рекомендуется)

Таким образом, приведенное выше объявление должно быть записано следующим образом:

r = 7d 1h 0 25 h

12. объявление временной зоны

z=*(объявление временной зоны)

z=<adjustment time> <offset><adjustment time> <offset>

Для составления расписания повторяющейся сессии, которая охватывает переход с летнего времени на стандартное время и обратно, необходимо определить сдвиги времени по отношению к базовому времени повторов сессий. Это требуется, потому что различные временные зоны сменяют время в различные моменты суток, различные страны переходят на летнее время и обратно в разные дни календаря, а некоторые страны вообще не переходят на летнее время. Таким образом, чтобы составить расписание сессии, которая проводится и зимой и летом, должна быть возможность однозначно определить, в какой временной зоне описана сессия. Чтобы упростить задачу приемников, мы допускаем, что передатчик должен определить NTP-время, как отсчет зонового времени и значение сдвига (offset) от момента, когда сессия была впервые внесена в расписание. Поле “z” позволяет определить список этих временных регулировок и сдвигов по отношению к базовому времени. Например:

z=2882844526 –1h 2898848070 0

Данная запись определяет, что во время 2882844526 базовое время, посредством которого рассчитываются повторы сессии, переводится на 1 час назад, и что во время 2898848070 первоначальное базовое время сессии восстанавливается. Регулировки времени всегда рассматриваются относительно определенного стартового времени – они не накапливаются.
Если есть вероятность, что сессия длится несколько лет, ожидается, что описание сессии будет периодически модифицироваться, что предпочтительнее, чем передавать несколько лет изменения одного описания.

13. криптографический ключ (Encryption keys)

k=*(криптографический ключ)

k=<method>

k=<method>:<encryption key>

SDP может использоваться для передачи криптографических ключей. Поле криптографического ключа допустимо перед первым вводом медиа (в этом случае он применяется ко всем медиа данной сессии), или перед вводом каждого медиа – как потребуется.

Формат и использование криптографических ключей находится за рамками данного документа [см. RFC 1890].

14. атрибуты сессии

a=*(ноль или больше строк атрибутов сессии)

a=<attribute>

a=<attribute>:<value>

Атрибуты являются основным средством расширения SDP. Атрибуты могут быть определены для использования как атрибуты «уровня сессии», атрибуты «уровня медиа» или обоими способами.

Описание медиа может содержать любое количество атрибутов (полей «a=»), определяющих особенности медиа. Они применяются как атрибуты «уровня медиа» и дополняют информацию о медиа-потоке. Поля атрибутов также могут быть добавлены перед первым полем медиа; эти атрибуты «уровня сессии» передают дополнительную информацию, которая применяется к конференции в целом, а не к отдельному медиа; примером может служить политика управления пределом (floor) конференции.

Поля атрибутов могут быть двух форматов:

- атрибуты, отражающие свойства; эти атрибуты имеют простой формат: “a=<flag>”. Это двоичные атрибуты, и наличие атрибута передает информацию о свойстве сессии. Например: “a=recvonly”.

- атрибуты, отражающие значения; эти атрибуты имеет форму записи
«a=<attribute>:<value>».Примером может служить, что доска объявлений (whiteboard) должна иметь значение атрибута “a=orient:landscape” (а=ориентировать:горизонтально).

Описание медиа (Ноль или более описаний медиа)

15. имя медиа и адрес транспорта

m=(имя медиа и адрес транспорта)

m=<media> <port> <transport> <fmt list>

Описание сессии может содержать несколько описаний медиа. Каждое описание медиа начинается с поля «m=» и заканчивается или следующим полем «m=» или концом описания сессии. Поле медиа имеет различные подполя.

<media> Первое подполе <media> содержит тип медиа. В настоящее время определены типы медиа “audio”, “video”, “application”, “data” и “control”, хотя этот список может быть расширен, так как появляются новые коммуникационные возможности (например, телеприсутствие). Разница между “application” и “data” заключается в том, что первый представляет собой медиа-поток такой, как информация электронной доски объявлений, а второй – передачу объема данных, таких как многоадресная рассылка исполняемых программ, которые обычно не выводятся на дисплей пользователя. “control” используется для определения дополнительного канала управления конференцией для конкретной сессии.

<port> Второе подполе <port> - это транспортный порт, в который будет передаваться медиа поток. Значение транспортного порта зависит от используемой сети, определяемой в соответствующем поле <c> и от транспортного протокола, который определяется в третьем подполе <transport>. Другие порты, используемые приложениями медиа (такие как RTCP-порт, см. [RFC 1889]) должны алгоритмически определяться в зависимости от базового порта медиа.

Примечание: для транспортных протоколов, основанных на UDP, значение должно выбираться в диапазоне от 1024 до 65535 включительно. Для совместимости с RTP оно должно быть четным числом.

<transport> Третье подполе <transport> - это транспортный протокол. Значения транспортного протокола зависят от значения типа адреса <address type> в полях «с=». Так, поле «с=» IP4 устанавливает, что транспортный протокол проходит над IP4. Для IP4 обычно ожидается, что наибольший медиа-трафик будет переноситься как RTP поверх UDP.

Следующие транспортные протоколы предварительно определены, но могут быть расширены благодаря регистрации новых протоколов с IANA:

- RTP/AVP – RTP протокол IETF, использующий Audio/video профиль, переносимый поверх UDP,

- UDP – User Datagram Protocol.

Если приложение использует одиночный комбинированный собственный (proprietary) формат и транспортный протокол поверх UDP, то в таком случае рекомендуется определить транспортный протокол, как UDP, и использовать поле формата для распознавания комбинированного протокола. Если транспортный протокол используется поверх UDP для передачи нескольких различных типов медиа, которые нужно различать, используя справочник сессии, то в таком случае необходимо отдельно определить транспортный протокол и формат медиа. RTP – это пример транспортного протокола, который переносит различные форматы полезной нагрузки, которые должны характеризоваться указателем сессии, чтобы было известно, как запускать соответствующие инструментальные средства, трансляторы, микшеры или передатчики.

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

Для обработки RTP медиа потоков c профилем RTP Audio/video [RFC 1890 (3)] поле протокола является - “RTP/AVP”. Если в будущем будут определяться другие RTP-профили, они будут специфицироваться таким же образом. Например, поле протокола “RTP/XYZ” должно определять обработку RTP с профилем, короткое имя которого – “XYZ”.

<fmt list> Четвертое и последующие подполя – это форматы медиа. Для аудио и видео обычно это будут типы полезной медиа нагрузки, как определено в профиле RTP Audio/video.

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

Для медиа, чей транспортный протокол не RTP или UDP, поле формата определяется протоколом. Такие форматы должны быть описаны в документе дополнительной спецификации.

Для медиа, использующих транспортный протокол RTP, SDP может использоваться, чтобы обеспечить динамическую привязку способа кодирования данных к типу полезной нагрузки RTP. Наименования кодировок в AV-профиле RTP не определяют уникальные аудио-кодировки (в единицах тактовой частоты и количестве аудио-каналов), и поэтому они не используются непосредственно в полях формата SDP. Чтобы определить формат для типов статической нагрузки, вместо этого должен использоваться номер типа полезной нагрузки, а номер типа нагрузки с дополнительной информацией о кодировании должен использоваться для динамически размещаемых типов нагрузки.

Примером типа статической нагрузки является один аудио канал с u-law PCM кодированием и частотой дискретизации 8 кГц. Он полностью определен в audio/video RTP-профиле как тип нагрузки 0, поэтому поле для определения медиа для такого потока, передаваемого в UDP-порт 49232 имеет следующий вид:

m = video 49232 RTP/AVP 0

Пример типа динамической нагрузки – 16 битовый линейно кодированный стерео аудио сигнал с частотой дискретизации 16 кГц. Если мы хотим использовать динамическую нагрузку RTP/AVP типа 98 для такого потока, требуется дополнительная информация для его декодирования:

m = video 49232 RTP/AVP 98

a = rtpmap: 98 L16/1600/2

Основная форма атрибута rtpmap следующая:

a = rtpmap: <payload type> <encoding name>/<clock rate>[/<encoding parameters>]

Для аудио потоков <encoding parameters> могут определять количество аудио каналов. Этот параметр может быть пропущен, если количество каналов равно одному при условии, что не требуется дополнительных параметров. В настоящее время параметры кодирования для видео потоков не определены.

Параметры, добавленные к атрибуту rtpmap, должны быть только такими, которые требуются каталогу сессии, чтобы выбрать подходящее для участия в сессии медиа-средство. Специфические для кодека параметры должны добавляться в других атрибутах.

Для каждого медиа-формата может быть определено не более одного атрибута rtpmap. Таким образом, мы можем иметь:

m = audio 49230 RTP/AVP 96 97 98

a = rtpmap: 96 L8/8000

a = rtpmap: 97 L16/8000

a = rtpmap: 98 L16/11025/2

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

Экспериментальные форматы кодирования также могут определяться с использованием атрибута rtpmap. RTP-форматы, не зарегистрированные как стандартные имена форматов, должны предваряться знаком «X-». Таким образом, новый экспериментальный аудио поток с избыточным кодированием, названный GSMLPC, использующий тип динамической нагрузки 99 должен быть описан как:

m= video 40232 RTP/AVP 99

a = rtpmap: 99 Х-GSMLPC/8000

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

Отметим, что RTP аудио форматы обычно не включают информацию о скорости пакетизации. Если требуется пакетизация не по-умолчанию, то используется атрибут “ptime”, как описано ниже.
Для более детального знакомства с аудио и видео форматами RTP см. [RFC 1890 (3)].