Протокол описания сеанса - Session Description Protocol

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

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

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

IETF опубликовал оригинальную спецификацию в качестве предлагаемого стандарта в апреле 1998 года Пересмотренные спецификации были выпущены в 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 = flag передает логическое свойство носителя или сеанса.
  • Value: a = attribute : value предоставляет именованный параметр.

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

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

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

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

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

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

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

Таким образом, часовая встреча с 10:00 по всемирному координированному времени 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 часа ночи по всемирному координированному времени (т.е. 60 дней минус 7 часов после времени начала в воскресенье, 1 августа 2010 года в 10 часов утра по всемирному координированному времени), и это будет единственная применяемая корректировка дневного света. в запланированный период, который будет иметь место с 1 августа 2010 г. по 28 ноября 2010 г. в 10 часов утра по всемирному координированному времени (время остановки повторяющегося 1-часового сеанса, который повторяется каждую неделю в одно и то же местное время, которое происходит через 88 дней), это можно указать как: 

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

Если еженедельный 1-часовой сеанс повторялся каждое воскресенье в течение одного полного года, то есть с воскресенья, 1 августа 2010 г., 3:00 UTC до воскресенья, 26 июня 2011 г., 4:00 UTC (время остановки последнего повтора, т.е. 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 .

Примечания

использованная литература

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