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 — медиа-сессия неактивна

v=0 o=- 1815849 0 IN IP4 194.167.15.181 s=Cisco SDP 0 c=IN IP4 194.167.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 содержится следующая информация. Пользователь, не имеющий буквенного идентификатора, запрашивает SDP сессию с идентификатором 1815849 и 0 версией. Параметр IN указывает на сетевой протокол создателя сессии, в данном примере «IN» — интернет, IP4 — тип IP-адреса создателя сессии, в данном примере IPv4. Адрес инициатора сессии 194.167.15.181. Имя устройства, инициирующего сессию — Cisco. Медиа-трафик будет ожидаться на устройстве с IP-адресом 194.167.15.181, на порту 20062.

Время начала и окончания сессии жестко не ограничены (t=0 0).

Данное устройство поддерживает набор параметров RTP потока мультимедиа-данных и методы его кодирования (профилей RTP), описанных при помощи типов (payload type) 99, 18, 100 и 101. Это указано в строке m=audio. Ниже, в строчках a=rtpmap, приводится уточнение параметров типов данных — атрибутов кодеков, так как некоторые типы являются динамическими и не могут быть определены однозначно, просто по строке m=audio.

Так, под типом данных 99 данное устройство подразумевает голосовой кодек G.729b и частотой дискретизации 8000Гц (G.729 Annex B, с поддержкой подавления шума). Динамически тип данных 101 в данном случае — это возможность приёма тональных сигналов DTMF (telephone event) по стандарту, описанному в RFC 2833. Согласно строке a=fmtp для типа 101, устройство может работать с событиями DTMF от 0 до 15. Все 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 однозначно закреплён за этими кодеками.

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

• MGCP
• SIP
• Профили данных RTP

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