SDP — что это такое, формат описания сессий и роль в WebRTC

Что такое SDP (Session Description Protocol)?

SDP — это протокол прикладного уровня, предназначенный для описания параметров мультимедийных сессий в текстовом формате. Он был разработан в рамках рабочей группы MMUSIC (Multiparty Multimedia Session Control) IETF и впервые стандартизирован в RFC 2327 в 1998 году. В 2021 году вышла актуальная спецификация RFC 8866, заменившая предыдущую версию RFC 4566.

Основная задача SDP — предоставить участникам сессии всю необходимую информацию для установления соединения: какие медиа-потоки будут передаваться, какие кодеки поддерживаются, по каким сетевым адресам и портам будет идти передача. SDP не передаёт сами медиаданные, а только описывает, как должно быть организовано соединение.

По данным IETF RFC 8866, формат SDP состоит из набора строк, каждая из которых начинается с однобуквенного типа, за которым следует знак равенства и значение. Например, строка m=audio 5004 RTP/AVP 0 означает, что сессия включает аудиопоток на порту 5004 с транспортным протоколом RTP/AVP и кодеком PCMU (тип 0).

История и стандартизация SDP

Первая версия SDP была опубликована в RFC 2327 в апреле 1998 года как результат работы группы MMUSIC. Протокол изначально создавался для анонсирования multicast-сессий в рамках Mbone (Multicast Backbone). С развитием VoIP и видеоконференций сфера применения SDP расширилась, и в 2006 году вышла обновлённая спецификация RFC 4566.

Настоящий прорыв в использовании SDP произошёл с появлением WebRTC в 2011 году. Google интегрировала SDP как основной механизм описания медиа-сессий в своём фреймворке для браузерного real-time общения. С этого момента SDP стал обязательным компонентом любой WebRTC-реализации — от браузеров до мобильных приложений на iOS и Android.

В 2021 году рабочая группа IETF опубликовала RFC 8866 — актуальную спецификацию SDP, которая заменила RFC 4566. Обновлённая версия уточнила обработку ICE (Interactive Connectivity Establishment), поддержку DTLS (Datagram Transport Layer Security) и расширила возможности описания групповых сессий.

Отличие SDP от транспортных протоколов

SDP принципиально отличается от транспортных протоколов тем, что не участвует в передаче данных. Он выполняет исключительно описательную функцию — подобно метаданным мультимедийного файла. В то время как RTP (Real-time Transport Protocol) передаёт аудио- и видеопакеты, а RTCP контролирует качество передачи, SDP лишь указывает, какие кодеки и порты использовать.

Аналогия из веб-разработки: SDP — это HTML-разметка, описывающая структуру страницы, а RTP — это сами изображения и текст. Без SDP участники сессии не знают, как подключиться друг к другу, даже если сетевое соединение уже установлено. Механизм NAT-траверсала (ICE) также полагается на SDP для передачи информации о сетевых кандидатах.

Как устроена структура SDP

Структура SDP организована в виде последовательности текстовых строк, каждая из которых следует формату type=value. Однобуквенный type определяет назначение строки, а value содержит соответствующее значение. Все строки разделены символом перевода строки CRLF.

Стандарт RFC 8866 определяет несколько обязательных и опциональных полей. Обязательные поля включают версию протокола (v=), имя сессии (s=), время начала и окончания сессии (t=). Остальные поля — опциональные, но для WebRTC-сессий необходимы также описания медиа (m=), атрибутов (a=) и сетевой информации (c=).

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

В приведённом примере показан типичный SDP-сегмент для WebRTC-сессии. Строка v=0 указывает версию протокола. Поле o= содержит идентификатор владельца сессии и её версию. Строка s=- задаёт имя сессии (дефис означает пустое имя). Поле t=0 0 указывает, что сессия не ограничена по времени.

Поле a=group:BUNDLE audio video — это атрибут, группирующий несколько медиа-потоков в один транспортный канал. Механизм BUNDLE позволяет экономить сетевые ресурсы, передавая аудио и видео через одно соединение. Это особенно важно для мобильных устройств с ограниченной пропускной способностью.

Обязательные поля SDP

Спецификация RFC 8866 определяет набор обязательных и опциональных полей. К обязательным относятся v= (версия), s= (имя сессии) и t= (время). Поле o= (владелец), хотя и не является строго обязательным по RFC, практически всегда присутствует в реальных реализациях.

Поле m= (media) — одно из самых важных. Оно описывает конкретный медиа-поток и содержит тип медиа (audio, video, text, application), порт, транспортный протокол и список поддерживаемых кодеков. В WebRTC наиболее часто используются типы audio и video с транспортными протоколами RTP/SAVPF (Secure Audio/Video Profile with Feedback) или UDP/TLS/RTP/SAVPF.

Поле a= (attribute) — наиболее гибкое и расширяемое. Оно может содержать rtpmap (сопоставление номера кодека с названием), fmtp (параметры кодека), fingerprint (отпечаток DTLS-ключа), ice-ufrag и ice-pwd (учётные данные для ICE) и множество других атрибутов. Именно через атрибуты SDP обеспечивает поддержку современных механизмов безопасности и NAT-траверсала.

Как SDP работает в WebRTC

В архитектуре WebRTC SDP выполняет роль сигнального протокола для описания и согласования параметров медиа-сессии между двумя участниками. Сам SDP не определяет механизм передачи этих описаний — эту задачу решает сигнальный канал, который разработчик реализует самостоятельно через WebSocket, HTTP или другой протокол.

Процесс начинается с того, что инициатор (caller) создаёт SDP-предложение — Offer. Для этого браузер вызывает метод createOffer() на объекте RTCPeerConnection. Сгенерированное SDP-описание содержит все параметры сессии со стороны инициатора: поддерживаемые кодеки, сетевые адреса, ICE-кандидаты и требования к безопасности.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Add media tracks before createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Create SDP Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

После создания Offer и установки локального описания через setLocalDescription(), инициатор отправляет SDP-строку удалённому участнику через сигнальный канал. Удалённый участник, получив SDP Offer, создаёт SDP-ответ — Answer — и отправляет его обратно. Этот обмен называется сигнальным обменом (signaling exchange) и является обязательным этапом перед установкой peer-to-peer соединения.

По данным W3C WebRTC Specification, SDP-обмен должен происходить до начала ICE-кандидатов. На практике многие реализации отправляют ICE-кандидаты параллельно с SDP, используя механизм ICE trickle. Это сокращает время установки соединения, особенно для мобильных сетей с высокими задержками.

Роль ICE в SDP

ICE (Interactive Connectivity Establishment) — это механизм, использующий SDP-атрибуты для передачи информации о сетевых кандидатах. ICE-кандидаты описывают возможные пути соединения: host (локальный адрес), srflx (адрес после NAT, полученный через STUN) и relay (адрес TURN-сервера).

В SDP ICE-кандидаты передаются через атрибуты a=candidate:, а также через поля ice-ufrag и ice-pwd для аутентификации ICE-трафика. Каждый кандидат включает транспортный протокол (UDP, TCP), IP-адрес, порт и приоритет. Успешное соединение устанавливается по первому кандидату, который проходит проверку связности. Механизм ICE restart позволяет обновить соединение при смене сети.

Для мобильных приложений ICE-кандидаты особенно важны, так как устройства часто находятся за NAT или корпоративными файрволами. Механизм ICE позволяет найти рабочий путь даже в сложных сетевых условиях, а SDP служит транспортным контейнером для этой информации.

Безопасность SDP в WebRTC

SDP в WebRTC обязательно включает атрибуты безопасности, в частности DTLS fingerprint и параметры SRTP. Поле a=fingerprint:sha-256 содержит отпечаток сертификата DTLS, используемый для аутентификации и шифрования медиа-потока. Без этого атрибута WebRTC-соединение не будет установлено.

Дополнительные механизмы безопасности включают атрибут a=setup:, который определяет роль DTLS-рукопожатия (active, passive, actpass), и a=ice-lite: для упрощённой ICE-реализации на стороне сервера. Все эти параметры передаются внутри SDP и проверяются обеими сторонами до начала передачи медиаданных.

Типы SDP: Offer и Answer

В модели WebRTC существует два типа SDP-сообщений: Offer (предложение) и Answer (ответ). Offer создаётся инициатором соединения и содержит полное описание желаемой медиа-сессии. Answer создаётся удалённым участником в ответ на Offer и содержит его возможности с учётом ограничений, наложенных предложением.

Основное различие между Offer и Answer — в семантике атрибутов. Offer перечисляет все поддерживаемые кодеки, транспортные протоколы и сетевые адреса, которые может предложить инициатор. Answer выбирает подмножество этих возможностей, поддерживаемое удалённой стороной. Например, если Offer предлагает opus, ISAC и PCMU, Answer может выбрать только opus как наиболее предпочтительный кодек.

Процесс обмена регулируется W3C WebRTC specification и включает несколько состояний RTCPeerConnection. После создания Offer через createOffer() и установки как локального описания, соединение переходит в состояние have-local-offer. После получения Answer и установки его как удалённого описания через setRemoteDescription(), соединение переходит в stable — финальное состояние, готовое к передаче медиа.

Использование SDP в мобильных SDK

Мобильные SDK для WebRTC — Google WebRTC для Android и WebRTC.framework для iOS — полностью поддерживают SDP-обмен через Offer и Answer. На Android для создания Offer используется класс PeerConnection с методом createOffer(), аналогичным браузерному API. Полученное SDP-описание передаётся как строка через сигнальный канал.

На iOS работа с SDP строится через класс RTCSessionDescription из фреймворка WebRTC. При инициализации указываются тип (RTCSdpTypeOffer или RTCSdpTypeAnswer) и SDP-строка. Платформа автоматически парсит SDP и настраивает соединение согласно переданным параметрам.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

Возможность напрямую работать с SDP-строкой даёт разработчикам гибкость: можно модифицировать SDP перед отправкой, добавляя или удаляя определённые кодеки, настраивая параметры ICE или добавляя пользовательские атрибуты. Для Android приложений часто требуется отключать видео в SDP при низкой пропускной способности сети — это делается удалением соответствующих m= строк из SDP-описания.

SDP в мобильной разработке

В мобильной разработке SDP используется преимущественно в контексте WebRTC — для создания приложений с видеозвонками, голосовыми чатами и стримингом. Мобильные приложения на Android и iOS могут выступать как в роли инициатора, так и в роли получателя SDP-сообщений, что позволяет строить симметричные peer-to-peer соединения.

Особенность мобильных приложений — необходимость работать с SDP в условиях переменного качества сети. При переключении между Wi-Fi и мобильным интернетом, а также при изменении пропускной способности может потребоваться генерация нового SDP-описания. Для этого используется механизм renegotiation — повторный обмен SDP через createOffer() и setLocalDescription().

По данным Google WebRTC team (2023), оптимизация SDP-обмена для мобильных устройств включает использование ICE restart при смене сети, приоритизацию кодеков с низким битрейтом (opus для аудио, VP8 для видео) и минимальный размер SDP-строки за счёт исключения ненужных медиа-потоков. Ключевое преимущество — снижение задержки при установке соединения в условиях мобильных сетей.

Оптимизация SDP для мобильных сетей

Одна из ключевых задач при работе с SDP на мобильных устройствах — минимизация размера SDP-описания. Полный SDP для типовой WebRTC-сессии с аудио и видео может занимать 2–5 КБ, что существенно для медленных сетей. Оптимизация включает использование BUNDLE (объединение потоков), удаление неподдерживаемых кодеков и сжатие ICE-кандидатов.

Дополнительная проблема мобильных устройств — ограниченное время жизни SDP. В условиях нестабильного соединения SDP может устареть до того, как удалённый участник успеет его обработать. Решение — использование коротких таймаутов на получение Answer и повторная отправка SDP при необходимости. Механизм ICE restart позволяет обновить соединение без полного пересоздания RTCPeerConnection. Атрибут a=ice-lite упрощает ICE-реализацию на серверной стороне.

Популярные библиотеки для работы с SDP

Разработчикам мобильных приложений доступны готовые библиотеки, упрощающие работу с SDP. libjingle_peerconnection (Google WebRTC) — основная библиотека для Android, предоставляющая полный API для управления SDP. Для iOS используется WebRTC.framework с аналогичным функционалом. Обе библиотеки автоматически генерируют и парсят SDP, но дают доступ к сырой SDP-строке при необходимости.

Для более тонкого контроля над SDP существуют сторонние решения: sdp-transform (JavaScript или Node.js) для парсинга и модификации SDP, NICENICE (Java) для работы с ICE-кандидатами и готовые SDK от провайдеров WebRTC-инфраструктуры, берущие на себя весь сигнальный обмен, включая SDP.