Протокол описания сеанса

Протокол описания сеанса ( SDP ) — это формат описания мультимедийной связи сеансов с целью объявления и приглашения. Его преимущественное использование — поддержка приложений потокового мультимедиа , таких как передача голоса по IP (VoIP) и видеоконференцсвязь . SDP сам по себе не доставляет никаких медиапотоков, но используется между конечными точками для согласования сетевых метрик, типов мультимедиа и других связанных свойств. Набор свойств и параметров называется профилем сеанса .

SDP является расширяемым для поддержки новых типов и форматов мультимедиа. SDP изначально был компонентом протокола объявления сеанса (SAP). но нашел и другие применения в сочетании с транспортным протоколом реального времени (RTP), протоколом потоковой передачи в реальном времени (RTSP), протоколом инициации сеанса (SIP) и в качестве автономного протокола для описания сеансов многоадресной рассылки .

IETF в апреле 1998 г. ( RFC опубликовал первоначальную спецификацию как предлагаемый стандарт 2327). Пересмотренные спецификации были выпущены в 2006 году (RFC 4566). и в 2021 году (RFC 8866).

Описание сеанса

Протокол описания сеанса описывает сеанс как группу полей в текстовом формате, по одному полю в строке. Форма каждого поля следующая.

<character>=<value><CR><LF>

Где <character> это одиночный , чувствительный к регистру , и символ <value> представляет собой структурированный текст в формате, который зависит от символа. Значения обычно имеют кодировку UTF-8 . Пробелы не допускаются сразу по обе стороны от знака равенства.

Описания сеансов состоят из трех разделов: сеанс, время и описания мультимедиа. Каждое описание может содержать множество описаний синхронизации и мультимедиа. Имена уникальны только внутри связанной синтаксической конструкции.

Поля должны располагаться в указанном порядке; необязательные поля отмечены звездочкой:

• Описание сеанса

    v=  (protocol version number, currently only 0)
    o=  (originator and session identifier : username, id, version number, network address)
    s=  (session name : mandatory with at least one UTF-8-encoded character)
    i=* (session title or short information)
    u=* (URI of description)
    e=* (zero or more email address with optional name of contacts)
    p=* (zero or more phone number with optional name of contacts)
    c=* (connection information—not required if included in all media)
    b=* (zero or more bandwidth information lines)
    One or more time descriptions ("t=" and "r=" lines; see below)
    z=* (time zone adjustments)
    k=* (encryption key)
    a=* (zero or more session attribute lines)
    Zero or more Media descriptions (each one starting by an "m=" line; see below)

• Описание времени (обязательно)

    t=  (time the session is active)
    r=* (zero or more repeat times)

• Описание мультимедиа (необязательно)

    m=  (media name and transport address)
    i=* (media title or information field)
    c=* (connection information — optional if included at session level)
    b=* (zero or more bandwidth information lines)
    k=* (encryption key)
    a=* (zero or more media attribute lines — overriding the Session attribute lines)

Ниже приведен пример описания сеанса из RFC 4566. Этот сеанс инициирован пользователем «jdoe» по адресу IPv4 10.47.16.5. Его название — «Семинар SDP», и расширенная информация о сеансе («Семинар по протоколу описания сеанса») включена вместе со ссылкой для получения дополнительной информации и адресом электронной почты для связи с ответственной стороной, Джейн Доу. Этот сеанс рассчитан на два часа с использованием временных меток NTP с адресом подключения (который указывает адрес, к которому клиенты должны подключиться или — когда предоставляется многоадресный адрес, как здесь — подписаться), указанным как IPv4 224.2.17.12 с TTL равен 127. Получателям этого описания сеанса указано получать только медиафайлы. Предоставляются два описания мультимедиа, оба с использованием профиля аудио-видео RTP. Первый — это аудиопоток на порту 49170, использующий тип полезных данных RTP/AVP 0 (определенный в RFC 3551 как PCMU ), а второй — видеопоток на порту 51372, использующий тип полезных данных RTP/AVP 99 (определяемый как «динамический»). Наконец, включен атрибут, который сопоставляет тип полезной нагрузки RTP/AVP 99 с форматом h263-1998 с тактовой частотой 90 кГц. Подразумеваются порты RTCP для аудио- и видеопотоков 49171 и 51373 соответственно.

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
    s=SDP Seminar
    i=A Seminar on the session description protocol
    u=http://www.example.com/seminars/sdp.pdf
    [email protected] (Jane Doe)
    c=IN IP4 224.2.17.12/127
    t=2873397496 2873404696
    a=recvonly
    m=audio 49170 RTP/AVP 0
    m=video 51372 RTP/AVP 99
    a=rtpmap:99 h263-1998/90000

Спецификация SDP — это просто формат описания сеанса. Он предназначен для распространения по различным транспортным протоколам по мере необходимости, включая SAP , SIP и RTSP . SDP может даже передаваться по электронной почте или в виде полезной нагрузки HTTP.

Атрибуты

SDP использует атрибуты для расширения основного протокола. Атрибуты могут появляться в разделах «Сеанс» или «Медиа» и соответственно имеют область действия «уровень сеанса» или «уровень мультимедиа» . Новые атрибуты время от времени добавляются в стандарт посредством регистрации в IANA.

Атрибуты — это либо свойства, либо значения:

• Свойство: флаг a= передает логическое свойство носителя или сеанса.
• a= Значение: атрибут : значение предоставляет именованный параметр.

Два из этих атрибутов определены специально:

• a=charset: кодировка используется в разделах сеанса или мультимедиа для указания другой кодировки символов (как зарегистрировано в реестре IANA). ) от рекомендуемого значения по умолчанию ( UTF-8 ) для ключей стандартного протокола. Эти значения содержат текст, предназначенный для отображения пользователю.
• a=sdplang: код используется для указания языка текста. Альтернативный текст на нескольких языках может передаваться в сеансе и автоматически выбираться пользовательским агентом в соответствии с предпочтениями пользователя.

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

Параметры v , s и o являются обязательными, не должны быть пустыми и должны быть в кодировке UTF-8. Они используются в качестве идентификаторов и не предназначены для отображения пользователям.

В примере также присутствует несколько других атрибутов: атрибут уровня сеанса (например, атрибут в форме свойства a=recvonly ), или как атрибут уровня мультимедиа (например, атрибут в форме значения a=rtpmap:99 h263-1998/90000 для видео в примере).

Форматы времени и повторы

Абсолютное время представлено в формате протокола сетевого времени (NTP) (количество секунд с 1900 года). Если время остановки равно 0, сеанс неограничен . Если время начала также равно нулю, сеанс считается постоянным . Неограниченные и постоянные сеансы не приветствуются, но не запрещены. Интервалы могут быть представлены временем NTP или в виде типизированного времени: последовательности значений и единиц времени (дни: d , часы: h , минуты: m и секунды: s ).

Таким образом, часовая встреча с 10:00 UTC 1 августа 2010 г. с единственным повторением через неделю в то же время может быть представлена ​​как:

        t=1280656800 1281265200
        r=604800 3600 0

Или используя введенное время:

        t=1280656800 1281265200
        r=7d 1h 0

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

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

Например, если корректировка на дневной свет вычтет 1 час 31 октября 2010 г. в 3:00 UTC (т. е. 60 дней минус 7 часов после времени начала в воскресенье 1 августа 2010 г. в 10:00 UTC), и это будет единственная применимая корректировка на дневной свет. в запланированный период, который произойдет с 1 августа 2010 г. по 28 ноября 2010 г. в 10:00 UTC (время остановки повторяющегося 1-часового сеанса, который повторяется каждую неделю в одно и то же местное время, что происходит через 88 дней), это можно указать как:

        t=1280656800 1290938400
        r=7d 1h 0
        z=1288494000 -1h

Если еженедельная 1-часовая сессия повторялась каждое воскресенье в течение одного полного года, т.е. с 3:00 UTC воскресенья 1 августа 2010 г. до 4:00 UTC воскресенья 26 июня 2011 г. (время окончания последнего повтора, т.е. 360 дней плюс 1 час позже, или 31107600 секунд спустя), чтобы он включал переход обратно на летнее время в воскресенье 27 марта 2011 года в 2 часа ночи (1 час снова добавляется к местному времени, чтобы второй переход на летнее время произошел через 209 дней после первого времени запуска):

        t=1280656800 1290938400
        r=7d 1h 0
        z=1288494000 -1h 1269655200 0

Поскольку объявления SDP о повторных сеансах не должны охватывать очень длительные периоды, превышающие несколько лет, количество корректировок летнего времени, включаемых в параметр z=, должно оставаться небольшим.

Сеансы могут повторяться нерегулярно в течение недели, но планируются одинаково для всех недель периода путем добавления большего количества кортежей в параметр r . Например, чтобы запланировать то же событие и на субботу (в то же время дня), вы должны использовать:

        t=1280656800 1290938400
        r=7d 1h 0 6d
        z=1288494000 -1h 1269655200 0

Протокол SDP не поддерживает ежемесячные и ежегодные расписания повторяющихся сеансов с таким простым временем повторения, поскольку они неравномерно разнесены во времени; дополнительные кортежи t / r вместо этого могут предоставляться для каждого месяца или года.

Внешние ссылки

• Розенберг, Дж.; Шульцринн, Х. (июнь 2002 г.). Модель предложения/ответа с протоколом описания сеанса . IETF . дои : 10.17487/RFC3264 . РФК 3264 .