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=0o=- 1815849 0 IN IP4 194.167.15.181s=Cisco SDP 0c=IN IP4 194.167.15.181t=0 0m=audio 20062 RTP/AVP 99 18 101 100a=rtpmap:99 G.729b/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=rtpmap:100 X-NSE/8000a=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

• Протоколы VoIP
• Протоколы прикладного уровня
• Интернет-протоколы

• Страницы, использующие волшебные ссылки RFC