Протокол SDP¶

SDP (Session Description Protocol, протокол описания сеанса) — это текстовый протокол прикладного уровня, предназначенный для описания параметров мультимедийных сеансов связи. SDP не является транспортным протоколом; он служит для передачи информации о типе медиа (аудио, видео, текст), кодеках, IP-адресах, портах и других характеристиках, необходимых для установления и управления сеансом. Протокол определён в спецификации RFC 8866 (ранее — RFC 4566) и широко используется в системах IP-телефонии, видеоконференций, потокового вещания и других приложениях реального времени.

¶История и развитие

Протокол SDP был впервые опубликован в 1998 году как RFC 2327, разработанный рабочей группой MMUSIC (Multiparty Multimedia Session Control) инженерного совета Интернета (IETF). Основной целью создания SDP было обеспечение стандартизированного способа описания мультимедийных сеансов для протоколов приглашения к участию, таких как SIP (Session Initiation Protocol) и RTSP (Real-Time Streaming Protocol). В 2006 году вышла обновлённая версия RFC 4566, которая уточнила синтаксис, расширила типы полей и исправила ошибки предыдущей спецификации. В 2020 году стандарт был переиздан как RFC 8866 с незначительными изменениями и уточнениями, сохранив обратную совместимость.

Изначально SDP разрабатывался для описания сеансов многоадресной рассылки (multicast), но со временем его применение распространилось на одноадресные (unicast) сеансы и гибридные сценарии. Протокол остаётся одним из ключевых компонентов в архитектуре VoIP и WebRTC, хотя в последние годы в некоторых областях его вытесняют более современные форматы, такие как JSON-описания.

¶Структура и синтаксис

SDP-описание представляет собой текстовый блок, состоящий из последовательности строк, каждая из которых начинается с однобуквенного идентификатора (типа строки) и содержит знак равенства «=» между типом и значением. Строки разделяются символом возврата каретки и перевода строки (CRLF). Обязательные и опциональные строки строго регламентированы.

Основные типы строк SDP (по порядку следования в описании):

• v= (версия протокола) — обязательная строка, обычно v=0.
• o= (владелец/создатель сеанса) — содержит имя пользователя, идентификатор сеанса, версию, тип сети (IN — Internet), тип адреса (IP4 или IP6) и адрес.
• s= (название сеанса) — обязательная текстовая строка.
• i= (информация о сеансе) — опциональное текстовое описание.
• u= (URI) — опциональная ссылка на дополнительную информацию.
• e= (электронная почта) — контактные данные.
• p= (телефон) — контактный номер.
• c= (данные соединения) — содержит тип сети, тип адреса и адрес (может быть указан на уровне сеанса или медиа).
• b= (полоса пропускания) — опциональная строка для указания требуемой пропускной способности (например, b=AS:64 для аудио 64 кбит/с).
• t= (время сеанса) — обязательная строка, задающая время начала и окончания сеанса (в секундах от эпохи Unix). Для постоянных сеансов используется t=0 0.
• r= (повтор) — опциональная строка для указания повторяющихся сеансов.
• z= (коррекция часовых поясов) — опциональная строка.
• k= (ключ шифрования) — устаревшая строка, не рекомендуется к использованию.
• a= (атрибуты) — опциональные строки, расширяющие описание. Могут быть как глобальными, так и медиа-специфичными.
• m= (описание медиа) — обязательная строка для каждого медиапотока. Содержит тип медиа (audio, video, text, application, message), порт, транспортный протокол (например, RTP/AVP, UDP/TLS/RTP/SAVPF) и список форматов (кодеков).

Пример минимального SDP-описания для аудиосеанса:

`` v=0 o=alice 2890844526 2890844526 IN IP4 192.168.1.10 s=Audio Session c=IN IP4 192.168.1.10 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ``

¶Основные компоненты

¶Медиа-описания

Каждый медиапоток в сеансе описывается строкой m=. В одном SDP-описании может быть несколько строк m=, соответствующих разным потокам (например, аудио и видео). Для каждого потока указываются:

• Тип медиа: audio, video, text, application, message.
• Порт: номер UDP/TCP порта, на который ожидается приём данных. Для RTP-сеансов обычно указывается чётный порт, а нечётный резервируется для RTCP.
• Транспортный протокол: например, RTP/AVP (RTP over UDP), RTP/SAVP (RTP с SRTP), UDP/TLS/RTP/SAVPF (RTP over DTLS-SRTP).
• Форматы: список идентификаторов кодеков (например, 0 для PCMU, 8 для PCMA, 96 для динамического кодека).

¶Атрибуты

Строки a= предоставляют дополнительную информацию, не охваченную стандартными полями. Наиболее распространённые атрибуты:

• a=rtpmap:<payload_type> <encoding_name>/<clock_rate>[/<channels>] — описание кодека.
• a=fmtp:<payload_type> <parameters> — параметры кодека (например, размер пакета, режим работы).
• a=sendrecv, a=sendonly, a=recvonly, a=inactive — направление потока.
• a=ptime:<milliseconds> — рекомендуемая длительность пакета (например, 20 мс для G.711).
• a=group:<group_type> <group_id> — группировка медиапотоков (например, для FEC или стерео).
• a=msid:<stream_id> <track_id> — идентификаторы потоков и дорожек в WebRTC.

¶Соединение и адресация

Строка c= задаёт адрес, на который должны отправляться медиаданные. Для одноадресных сеансов это IP-адрес получателя, для многоадресных — multicast-адрес. Если адрес не указан на уровне медиа, он наследуется из сеансового уровня. В современных реализациях (например, WebRTC) адреса часто указываются только в c= на уровне медиа, так как сеансовый адрес может отсутствовать.

¶Применение

¶IP-телефония (VoIP)

В системах VoIP на базе протокола SIP, SDP используется для согласования параметров вызова. После установления SIP-сессии (INVITE, 200 OK) стороны обмениваются SDP-описаниями, в которых указывают поддерживаемые кодеки, IP-адреса и порты для приёма RTP-потоков. Это позволяет двум устройствам (например, IP-телефонам или софтфонам) начать передачу голоса в согласованном формате.

¶Видеоконференции и WebRTC

В технологии WebRTC, которая используется в браузерах и мобильных приложениях для аудио- и видеосвязи, SDP играет центральную роль. Протокол JavaScript Session Establishment Protocol (JSEP) определяет, как SDP-описания создаются и обрабатываются браузером. В WebRTC SDP используется для описания медиапотоков, кодеков (Opus, VP8, H.264), параметров ICE (Interactive Connectivity Establishment) и DTLS-SRTP. В отличие от классического VoIP, в WebRTC SDP часто содержит несколько медиа-секций (m=) для разных дорожек (аудио, видео, экран).

¶Потоковое вещание (RTSP)

Протокол RTSP (Real-Time Streaming Protocol) использует SDP для описания медиаконтента, доступного для потоковой передачи. Сервер RTSP предоставляет клиенту SDP-файл, в котором указаны кодеки, битрейты, временные метки и адреса для получения потоков. Это позволяет клиентам (например, медиаплеерам) настроить декодирование и воспроизведение.

¶Многоадресная рассылка

SDP изначально разрабатывался для многоадресных сеансов, где одно описание может использоваться для всех участников. В таких сценариях SDP-файлы распространяются через протокол SAP (Session Announcement Protocol) или размещаются на веб-серверах. Применяется в IPTV, дистанционном обучении и видеонаблюдении.

¶Ограничения и критика

Несмотря на широкое распространение, SDP имеет ряд недостатков:

• Текстовый формат: хотя текстовый формат упрощает отладку, он менее эффективен по сравнению с бинарными протоколами (например, XMPP или JSON). Размер SDP-описания может быть значительным при большом количестве медиапотоков.
• Отсутствие гибкости: SDP жёстко привязан к порядку строк и синтаксису. Расширение функциональности требует добавления новых атрибутов, что может приводить к несовместимости между реализациями.
• Сложность согласования: в многопользовательских конференциях или при использовании шлюзов (например, SIP-H.323) согласование SDP-описаний может требовать дополнительных механизмов (например, offer/answer model в SIP).
• Устаревшие элементы: некоторые поля (например, k= для ключей шифрования) объявлены устаревшими, но всё ещё могут встречаться в старых системах, что создаёт риски безопасности.

В современных реализациях (особенно в WebRTC) часть этих ограничений компенсируется использованием расширенных атрибутов и дополнительных протоколов (ICE, STUN, TURN), но базовый SDP остаётся основой для описания медиасеансов.

¶Интересные факты

• SDP не является протоколом в полном смысле слова, поскольку не определяет механизмы установления или завершения сеанса — он лишь описывает его параметры.
• Идентификатор сеанса в строке o= должен быть уникальным для каждого нового описания, чтобы избежать конфликтов в многоадресных сценариях.
• В WebRTC SDP-описания могут содержать до нескольких десятков медиа-секций (например, для множества видеодорожек), что делает их громоздкими, но необходимыми для точного описания.
• Протокол SDP используется не только в интернете, но и в локальных сетях, в том числе в системах видеонаблюдения и межкомнатной связи.

¶Источники

• RFC 8866 — Session Description Protocol, 2020.
• RFC 4566 — Session Description Protocol, 2006.
• RFC 2327 — Session Description Protocol, 1998.
• RFC 3264 — An Offer/Answer Model with Session Description Protocol (SDP), 2002.
• RFC 8829 — JavaScript Session Establishment Protocol (JSEP), 2021.
• «Understanding SDP» — документация WebRTC (W3C).
• «SIP: Understanding the Session Initiation Protocol» — Alan B. Johnston, Artech House, 2004.