Session Description Protocol

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

SDP (англ. Session Description Protocol) — сетевой протокол прикладного уровня, предназначенный для описания сессии передачи потоковых данных, включая телефонию (ТФОП и VoIP), Интернет-радио, приложения мультимедиа.

Сессия SDP может реализовывать несколько потоков данных. В протоколе SDP в настоящее время определены аудио, видео, данные, управление и приложения (поточные), сходные с MIME типами электронной почты в Интернет-адресах.

Сообщение SDP, передаваемое от одного узла другому, может указывать:

  • адреса места назначения, которые могут быть для медиа-потоков мультикастинг-адресами
  • номера UDP портов для отправителя и получателя
  • медиа-форматы (например кодеки, описываемые профилем), которые могут применяться во время сессии
  • время старта и остановки. Используется в случае широковещательных сессий, например, телевизионных или радиопрограмм. Можно внести время начала, завершения и времена повторов сессии

Несмотря на то, что SDP предоставляет возможность описания мультимедиа-данных, в нём не хватает механизмов согласования параметров сессии, которые намерены использовать партнеры. Документ RFC 3264 предоставляет модель согласования на основе механизма предложения / отклика, в которой узлы обмениваются SDP-сообщениями с целью достичь согласия относительно формата данных, в котором будет осуществляться обмен.

Поля сообщения протокола SDP нередко включаются в сообщения сигнальных протоколов телефонии, таких, например как SIP и MGCP. Таким образом SDP дополняет процесс управления вызовом, выполняя функции описания параметров медиа-сессии.


Поля, используемые в протоколе[править | править вики-текст]

Рассмотрим, какие поля могут использоваться в сообщениях SDP. Необязательные элементы отмечены в списке символом `*'.

Примечание: Подробное описание всех возможны полей и требований к значениям, приводится в RFC 4566.

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

v= (версия протокола, в данный момент версия всегда 0)
o= (идентификаторы создателя/владельца и сессии).
s= (имя сессии, не может быть пустым)
i=* (информация о сессии)
u=* (URI - адрес, используемый WWW-клиентами, с дополнительной информацией о сессии)
e=* (E-mail адрес лица, ответственного за конференцию)
p=* (номер телефона лица, ответственного за конференцию)
c=* (информация для соединения - не требуется, если есть в описании всех медиаданных)
b=* (информация о занимаемой полосе пропускания канала связи)
Одна и более строк с описанием параметров времени (Смотри ниже)
z=* (установка для временной зоны)
k=* (ключ шифрования)
a=* (одна или несколько строк с описанием атрибутов сессии, см. ниже)

Описание параметров времени[править | править вики-текст]

t= (время активности сеанса)
r=* (число попыток повторов, от нуля и больше)


Описание данных передачи мультимедиа[править | править вики-текст]

m= (тип медиаданных и транспортный адрес устройства)

Строка m= содержит точное название медиаданных (возможные значения audio, video или message), точный транспортный адрес (порт) и перечисление поддерживаемых типов данных по номерам (payload type).

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

Атрибуты медиа сессии[править | править вики-текст]

Строка a= может содержать следующие параметры:

  • a=rtpmap:PT КОДЕК - уточнение типа кодека, если это необходимо, где PT - цифровое значение payload type, а кодек - название кодека и частота дискретизации.
  • a=fmtp - дополнительные атрибуты кодека, например использование VAD или рекомендуемый битрейт.
  • a=ptime:FPP - размер RTP-пакета - или продолжительность (в миллисекундах) передаваемого отрезка медиа-данных в одном пакете RTP. В данном случае значение FPP это произведение длины одного фрейма оцифрованного звука на количества фреймов в одном RTP-пакете. Таким образом, если для кодека используется 10 мс в каждом фрейме, а фреймов в одном пакете 3, то ptime примет значение 30. Поле не является обязательным, но может использоваться для изменения влияния "накладных расходов" на пропускную способность сети при кодирования/декодирования и передаче аудио или видео потока. Чем выше число фреймов в пакете, тем больше размер пакета (снижается число дополнительных заголовков для каждого пакета, а значит и нагрузка на сеть). С другой стороны, при передаче пакетов большого размера по UDP (а он используется в качестве основы RTP в большинстве случаев), характерная для UDP потеря части пакетов, может привести к потери значительной части полезных данных. Для большинства стандартных кодеков определён рекомендуемый размер RTP-пакета и чаще всего имеет значение 20 мс (см. Профили данных RTP).
  • a=РЕЖИМ - режим приёма и передачи, может принимать значения: sendonly - только отправка данных, recvonly - только приём, sendrecv - режим одновременных приёма и передачи (полнодуплексный режим), inactive - медиа-сессия не активна

Пример SDP сообщения[править | править вики-текст]

v=0
o=- 1815849 0 IN IP4 194.67.15.181
s=Cisco SDP 0
c=IN IP4 194.67.15.181
t=0 0
m=audio 20062 RTP/AVP 99 18 101 100
a=rtpmap:99 G.729b/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202

В приведенном выше примере сообщения SDP содержится следующая информация. Медиа-трафик будет ожидаться на устройстве Cisco с IP-адресом 194.167.15.181, порту 20062. Параметр IN указывает на сетевой протокол создателя сессии, в данном примере “IN”- интернет, IP4 - тип IP-адреса создателя сессии, в данном примере IPv4.

Данное устройство поддерживает несколько разновидностей аудио-трафика (кодеков), описанных при помощи типов (payload type) 99, 18, 100 и 101. Это указано в строке m=audio. Ниже, в строчках a=rtpmap приводится уточнение параметров типов данных - атрибутов кодеков, так как некоторые типы являются динамическими и не могут быть определены однозначно, просто по строке m=audio. Так, под типом данных 99 данное устройство подразумевает голосовой кодек G.729b (G.729 Annex B, с поддержкой подавления шума). Динамически тип данных 101 в данном случае, это возможность приёма тональных сигналов DTMF (telephone event) по стандарту, описанному в RFC 2833. Согласно строке a=ftmp для типа 101, устройство может работать с событиями DTMF от 0 до 16. Все SIP устройства должны поддерживать DTMF события от 0 до 15, которые являются цифрами 0-9 (номера), 10 - это символ "звёздочка" (*), 11 - "решётка" (#) и 12 -15 являются символами A-D.

X-NSE с типом 100 - это специфичный кодек NSE используемый Cisco как внутренняя версия стандартных именованных событий телефонии IETF (NTEs), которые представляют собой специально помеченные пакеты данных, используемые для цифровой передачи тональных сигналов и событий телефонии.

Для payload type 18 уточнений нет, и это может означать, что устройство поддерживает голосовой кодек G.729, вместе с более простой вариацией того же кодека описанного в приложении Annex A (или кодек G.729a), так как тип данных 18 однозначно закреплён за этими кодеками.

Приведённый порядок перечисления кодеков, также указывает на приоритеты выбора того или иного кодека, с точки зрения данного устройства.

см. также[править | править вики-текст]

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

  • RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP)
  • RFC 4566: SDP: Session Description Protocol