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

редактировать
формат файла для описания сетевых аудио- и видеопотоков

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

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

IETF опубликовал исходную спецификацию как Предлагаемый стандарт в апреле 1998 г., а затем опубликовал пересмотренную спецификацию как RFC 4566 в июле 2006 г..

Содержание

  • 1 Описание сеанса
  • 2 Атрибуты
  • 3 Форматы времени и повторения
  • 4 Примечания
  • 5 Ссылки
  • 6 Внешние ссылки

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

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

=

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

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

Необязательные значения указываются с помощью = *, и каждое поле должно появляться в указанном ниже порядке.

Описание сеанса v = (номер версии протокола, в настоящее время только 0) o = (инициатор и идентификатор сеанса: имя пользователя, идентификатор, номер версии, сетевой адрес) s = (имя сеанса: обязательно с хотя бы одним UTF- 8-значный символ) i = * (название сеанса или краткая информация) u = * (URI описания) e = * (ноль или более адресов электронной почты с необязательным именем контактов) p = * (ноль или более телефонных номеров с необязательным именем контактов) c = * (информация о соединении - не требуется, если включена во все носители) b = * (ноль или несколько строк с информацией о пропускной способности) Одно или несколько описаний времени ("t =" и "r =" строк; см. ниже) z = * (корректировка часового пояса) k = * (ключ шифрования) a = * (ноль или более строк атрибутов сеанса) Ноль или более Описания носителей (каждое начинается с "m = "строка; см. ниже)
Описание времени (обязательно) t = (время, когда сеанс активен) r = * (ноль или более повторений)
Описание носителя (необязательно) m = (название носителя и транспортный адрес) i = * (заголовок носителя или информация fie ld) 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 IN IP4 10.47.16.5 s = Семинар SDP i = Семинар по протоколу описания сеанса u = http: //www.example.com/seminars/sdp.pdf e [email#160;protected] (Джейн Доу) 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: encoding
  • a=sdplang : code

Первый используется в разделах Session или Media для указания другой кодировки символов (зарегистрированной в реестре IANA), чем настоятельно рекомендованная по умолчанию (UTF-8), где она используется в стандартных ключах протокола, значения которых содержат текст, предназначенный для отображения пользователю. Второй используется, чтобы указать, на каком языке он написан (альтернативные тексты на нескольких языках могут передаваться в протоколе и выбираться автоматически пользовательским агентом в соответствии с предпочтениями пользователя. В обоих случаях каждое текстовое поле в протоколе, которое не интерпретируется символически самим протоколом, будет интерпретироваться как непрозрачные строки, но отображаться для пользователя или приложения со значениями, указанными в последнем вхождении charsetи sdplangв текущем Медиа раздел или, иначе, их последнее значение в разделе Сессия).

Первые 3 обязательных параметра (v=, s=и o = ), даже если они кажутся содержащими отображаемый текст, не предназначены для отображения пользователям и перевода. Поля, присутствующие в их значениях, рассматриваются в протоколе как непрозрачные строки, они используются как идентификаторы, точно так же, как пути в URL-адресе или имена файлов в файловой системе: стандарт SDP указывает, что все они не должны быть пустыми и должны быть в формате UTF- 8 закодировано.

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

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

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

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

t = 1280656800 1281265200 r = 604800 3600 0

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

t = 1280656800 1281265200 r = 7d 1h 0

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

Вместо того, чтобы указывать этот часовой пояс и поддерживать базу данных часовых поясов, чтобы знать, когда и где потребуется корректировка дневного света, предполагается, что время повтора определяется в одном часовом поясе, а 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 утра по всемирному координированному времени, до воскресенья, 26 июня 2011 года, 4 утра по всемирному координированному времени (время остановки последнего повтора, т. е. 360 дней плюс 1 час позже или 31107600 секунд позже), чтобы он включал переход обратно к Летнее время в воскресенье, 27 марта 2011 г., в 2 часа ночи (к местному времени снова добавляется 1 час, чтобы второй переход на летнее время произошел через 209 дней после пихты. st start time):

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.

Примечания

Ссылки

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

Последняя правка сделана 2021-06-08 01:32:05
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте