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

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

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

IETF опубликовал оригинальную спецификацию в качестве предлагаемого стандарта в апреле 1998 года ^[3] Пересмотренные спецификации были выпущены в 2006 году (RFC 4566), ^[1] и в 2021 году (RFC 8866). ^[4] .

Описание сеанса [ править ]

Протокол описания сеанса описывает сеанс как группу полей в текстовом формате, по одному полю в строке. ^{[примечание 1]} Форма каждого поля следующая.

<символ >= <значение ><CR> <LF>

Где <character> - это отдельный символ с учетом регистра, а <value> - это структурированный текст в формате, который зависит от символа. Значения обычно имеют кодировку UTF-8 . ^{[примечание 2]} Пробелы не допускаются сразу по обе стороны от знака равенства. ^{[1] : Раздел 5}

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

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

Описание сеанса v = (номер версии протокола, в настоящее время только 0) o = (инициатор и идентификатор сеанса: имя пользователя, идентификатор, номер версии, сетевой адрес) s = (имя сеанса: обязательно с хотя бы одним символом в кодировке UTF-8) i = * (название сеанса или краткая информация) u = * (URI описания) e = * (ноль или более адресов электронной почты с необязательными именами контактов) p = * (ноль или более телефонных номеров с дополнительными именами контактов) c = * (информация о подключении - не требуется, если присутствует на всех носителях) b = * (ноль или более строк информации о пропускной способности) Одно или несколько временных описаний (строки "t =" и "r ="; см. Ниже) z = * (настройки часового пояса) k = * (ключ шифрования) a = * (ноль или более строк атрибутов сеанса) Ноль или более описаний мультимедиа (каждое начинается строкой "m ="; см. Ниже)

Описание времени (обязательно) t = (время активности сеанса) r = * (ноль или более повторений)

Описание СМИ (необязательно) m = (имя носителя и транспортный адрес) i = * (заголовок медиа или информационное поле) c = * (информация о подключении - необязательно, если включена на уровне сеанса) b = * (ноль или более строк информации о пропускной способности) k = * (ключ шифрования) a = * (ноль или более строк атрибутов мультимедиа - переопределение строк атрибутов сеанса)

Ниже приведен пример описания сеанса из 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 В IP4 10.47.16.5 s = Семинар SDP i = Семинар по протоколу описания сеанса u = http: //www.example.com/seminars/sdp.pdf [email protected] (Джейн Доу) c = В IP4 224.2.17.12/127 т = 2873397496 2873404696 a = recvonly m = аудио 49170 RTP / AVP 0 m = видео 51372 RTP / AVP 99 a = rtpmap: 99 ч263-1998 / 90000

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

Атрибуты [ править ]

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

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

• Свойство: a = flag передает логическое свойство носителя или сеанса.
• Value: a = attribute : value предоставляет именованный параметр.

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

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

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

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

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

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

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

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

 т = 1280656800 1281265200 г = 604800 3600 0

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

 т = 1280656800 1281265200 г = 7д 1ч 0

Если указано время повтора, время начала каждого повтора может потребоваться отрегулировать так, чтобы оно происходило в одно и то же местное время в определенном часовом поясе в течение периода между временем начала и временем окончания (которые все еще указываются в NTP. формат в UTC).

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

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

 т = 1280656800 1290938400 г = 7д 1ч 0 z = 1288494000 -1ч

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

 т = 1280656800 1290938400 г = 7д 1ч 0 z = 1288494000 -1ч 1269655200 0

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

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

 т = 1280656800 1290938400 г = 7д 1ч 0 6д z = 1288494000 -1ч 1269655200 0

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

Заметки [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

• Rosenberg, J .; Шульцринн, Х. (июнь 2002 г.). «Модель предложения / ответа с протоколом описания сеанса (RFC 3264)» . IETF . Проверено 25 июля 2010 .