Перейти к основному содержимому

SDP — протокол описания мультимедийных сессий

04-02-02

Session Description Protocol (SDP) — это текстовый формат, предназначенный для описания параметров мультимедийной сессии. Он играет ключевую роль в современных системах видеосвязи (SIP-телефония, WebRTC и IP-видеонаблюдение). SDP не является протоколом передачи данных и не отвечает за доставку аудио или видео. Вместо этого он служит языком описания, который передаётся внутри других протоколов и позволяет участникам заранее договориться о том, как именно будет организована передача медиаданных.

Понимание SDP необходимо инженеру, поскольку этот формат используется повсеместно: от установки видеозвонка в браузере до настройки взаимодействия между IP-камерой и видеоконференц-системой. Благодаря своей простоте и открытости, SDP является важным инструментом диагностики и анализа.

Что такое SDP: назначение и место в стеке протоколов​

SDP — это не протокол сигнализации, а формат описания сессии. Его задача — передать технические параметры медиасоединения: какие медиапотоки используются (аудио, видео), по каким адресам и портам, с какими кодеками и в каком направлении.

Где используется SDP?​

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

  • SIP (Session Initiation Protocol) — в теле сообщений INVITE и 200 OK передаётся SDP, чтобы согласовать параметры вызова.
  • WebRTC — используется для обмена описаниями сессии между браузерами (в формате offer и answer).
  • RTSP (в редких случаях) — может применяться для описания медиапотоков при инициализации стрима.
  • IP-видеонаблюдение — некоторые камеры и платформы используют SDP для передачи параметров видеопотока при подключении к видеосерверу.

💡 Аналогия: Представьте, что вы собираетесь позвонить другу. Вы не можете начать разговор, пока не договоритесь: кто будет говорить, кто слушать, на каком языке, с какой скоростью и по какому каналу. SDP — это как технический меморандум, в котором всё это описано до начала разговора.

Структура SDP: основные поля и их значение​

SDP-описание представляет собой последовательность текстовых строк, каждая из которых начинается с одной буквы, знака равенства и значения. Формат простой и легко читаемый, что делает его удобным для анализа.

Общая структура SDP включает глобальные параметры сессии и описание отдельных медиапотоков.

Основные поля SDP​

ПолеНазначение
v=Версия протокола SDP
o=Информация об инициаторе сессии
s=Тема (название) сессии
c=Сетевой адрес для медиапотоков
t=Время активности сессии (обычно t=0 0 для бессрочной)
m=Описание медиапотока (тип, порт, протокол, кодеки)
a=Дополнительные атрибуты (направление, кодеки, параметры)

Разберём каждый элемент подробнее.

Поле v= — версия протокола​

Пример:

v=0

Это поле указывает версию SDP. На практике всегда используется значение 0, так как спецификация SDP (RFC 4566) не претерпела изменений, требующих увеличения версии. Это поле присутствует для совместимости и всегда должно быть первым.

Поле o= — информация об инициаторе​

Пример:

o=jdoe 2890844526 2890844526 IN IP4 192.0.2.1

Формат:
o=<username> <session-id> <version> <nettype> <addrtype> <unicast-address>

  • username — имя пользователя или идентификатор. Часто ставится - (не используется).
  • session-id — уникальный идентификатор сессии. Изменяется при пересоздании сессии.
  • version — версия описания сессии. Увеличивается при изменениях.
  • nettype — тип сети. Обычно IN (Internet).
  • addrtype — тип адреса. IP4 или IP6.
  • unicast-address — IP-адрес инициатора.

📌 Это поле помогает идентифицировать источник сессии и отслеживать изменения конфигурации.

Поле s= — тема сессии​

Пример:

s=SDP Seminar

Указывает краткое название сессии. В реальных системах часто содержит имя вызова, идентификатор конференции или просто заглушку вроде Session. Не несёт технической нагрузки, но полезно для диагностики.

Поле c= — сетевой адрес​

Пример:

c=IN IP4 192.0.2.1

Определяет сетевой адрес, по которому будут передаваться медиаданные. Если указано глобально (до блоков m=), действует для всех потоков. Может быть переопределён внутри каждого m=.

  • IN — тип сети (Internet).
  • IP4 или IP6 — версия IP.
  • 192.0.2.1 — IP-адрес (часто публичный или NAT-преобразованный).

⚠️ Важно: если сессия проходит через NAT, в этом поле должен быть указан внешний (публичный) IP-адрес, иначе второй участник не сможет подключиться.

Блок m= — описание медиапотока​

Пример:

m=audio 49170 RTP/AVP 0 8 9 101

Это ключевое поле SDP. Каждый медиапоток (аудио, видео, общий доступ к экрану) описывается отдельной строкой m=.

Формат:
m=<media> <port> <proto> <fmt> ...

  • media — тип медиа: audio, video, application (например, для DTMF), text.
  • port — UDP-порт для приёма медиапотока. Обычно чётный (например, 49170). Следующий нечётный порт (49171) используется для RTCP.
  • proto — транспортный протокол: RTP/AVP (RTP по UDP), RTP/SAVP (защищённый RTP), UDP/TLS/RTP/SAVPF (шифрование через DTLS).
  • fmt — список поддерживаемых Payload Type (PT), идентификаторов кодеков.

💡 Payload Type (PT) — это числовое обозначение кодека в рамках сессии. Например, 0 — это G.711 μ-law, 8 — G.711 A-law, 101 — часто используется для DTMF.

Поле a= — атрибуты: уточнение параметров​

Атрибуты задаются строками a=... и могут быть глобальными (действуют на всю сессию) или локальными (применяются к конкретному m=).

Наиболее важные типы атрибутов:

1. a=rtpmap — мапинг кодека​

Пример:

a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000

Формат:
a=rtpmap:<payload-type> <encoding-name>/<clock-rate>[/<encoding-params>]

  • PCMU — G.711 с кодированием μ-law, 8 кГц.
  • PCMA — G.711 с кодированием A-law.
  • G722 — широкополосный аудиокодек.
  • telephone-event — используется для передачи DTMF-сигналов.

📌 Без rtpmap нельзя понять, какой кодек скрывается за числовым PT.

2. a=fmtp — параметры формата (format parameters)​

Пример (для H.264):

a=fmtp:96 profile-level-id=42e01f;packetization-mode=1

Используется для передачи дополнительных параметров кодека, особенно для видео. В примере:

  • profile-level-id=42e01f — профиль и уровень H.264 (Baseline Profile, Level 3.1).
  • packetization-mode=1 — режим упаковки (обязателен для WebRTC).

❗ Несовпадение profile-level-id — частая причина "нет видео" в SIP/WebRTC.

3. a=sendrecv, a=sendonly, a=recvonly — направление потока​

Пример:

a=sendrecv

Определяет, как будет использоваться медиапоток:

  • sendrecv — двусторонняя передача (по умолчанию).
  • sendonly — только передача (например, презентация).
  • recvonly — только приём (например, слушатель в конференции).
  • inactive — поток не используется.

💡 Это поле критично для правильной настройки дуплекса и управления потоками.

4. a=ice-ufrag, a=ice-pwd, a=candidate — параметры ICE​

Пример:

a=ice-ufrag:UaDj
a=ice-pwd:WseZ1mZ2Rn5a6789012345678901234
a=candidate:1234567890 1 udp 2130706431 192.0.2.1 49170 typ host

Эти атрибуты используются в WebRTC и современных SIP-системах для обхода NAT:

  • ice-ufrag и ice-pwd — учетные данные для аутентификации ICE.
  • candidate — сетевой кандидат (IP, порт, тип соединения), полученный через STUN/TURN.

🔄 ICE (Interactive Connectivity Establishment) — механизм, который позволяет установить прямое соединение между участниками, даже если они за NAT.

Пример полного SDP-описания​

Ниже приведён пример SDP для аудио-видео вызова:

v=0
o=jdoe 2890844526 2890844526 IN IP4 192.0.2.1
s=SDP Example
c=IN IP4 192.0.2.1
t=0 0
m=audio 49170 RTP/AVP 0 8 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 51372 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1
a=sendrecv

Разбор:

  • Аудиопоток: порт 49170, кодеки G.711, G.722, DTMF.
  • Видеопоток: порт 51372, H.264 с профилем Baseline.
  • Оба потока — двусторонние (sendrecv).

SDP в WebRTC и SIP: сходства и различия​

ХарактеристикаSIPWebRTC
Передача SDPВ теле INVITE и 200 OKЧерез сигнальный канал (WebSocket, HTTP)
ШифрованиеSRTP (ключ через SDES или DTLS)SRTP (ключ через DTLS)
NAT-обходICE, STUN, TURN (в атрибутах a=)ICE, STUN, TURN (в атрибутах a=)
Динамические PTДаДа
Использование rtpmapДаДа (но браузеры могут опускать стандартные кодеки)

🔍 Важно: в WebRTC SDP генерируется автоматически браузером, но его можно модифицировать через JavaScript API (RTCPeerConnection).

SDP как инструмент диагностики​

Поскольку SDP передаётся в открытом виде, он является ключевым элементом при анализе проблем в видеосвязи.

Типичные проблемы, выявляемые по SDP:​

ПроблемаПризнак в SDP
Нет аудио/видеоОтсутствует соответствующий блок m=
Односторонний звукa=sendonly на одной стороне, a=recvonly на другой
Несовместимость кодековНет общих PT в списках m=
Проблемы с H.264Разные profile-level-id или packetization-mode
Проблемы с NATОтсутствуют a=candidate или не совпадают IP/порты

🛠️ Совет: при отладке видеозвонка всегда проверяйте SDP в логах сигнализации (SIP-трафик или WebRTC-сообщения). Это первый шаг к пониманию, почему соединение не установилось.

Заключение: почему SDP важен для инженера​

SDP — это мост между сигнализацией и медиатранспортом. Он позволяет участникам сессии точно согласовать:

  • Какие медиапотоки используются,
  • По каким адресам и портам,
  • С какими кодеками и параметрами,
  • В каком направлении.

Хотя SDP выглядит как простой текст, он несёт критически важную информацию, от которой зависит совместимость устройств, качество связи и возможность диагностики.