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

04-03-03 Кодеки и параметры медиа в SIP/SDP

04-03-03

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

Понимание структуры и содержания SDP-описания — ключевой навык для инженера, работающего с видеосвязью. Ошибки в согласовании кодеков, несовпадение параметров или неправильная настройка транспорта могут привести к тому, что вызов установится, но видео не будет отображаться, или звук будет односторонним. Часто причина таких сбоев скрыта в тонких различиях в строках SDP, которые на первый взгляд выглядят корректно.

Как SDP описывает медиапотоки​

SDP — это текстовый формат, описывающий параметры мультимедийной сессии. Он используется как в SIP, так и в WebRTC, и позволяет сторонам сообщить друг другу:

  • Какие типы медиа поддерживаются (аудио, видео, шаринг экрана и т.д.),
  • Какие кодеки доступны,
  • На каких портах и по какому протоколу ожидается приём медиа,
  • В каком направлении может идти поток (отправка, приём, оба),
  • Какие дополнительные параметры кодеков требуются.

Каждый медиапоток в SDP описывается отдельной медиалинией, начинающейся с символа m=.

Структура медиалинии m=​

Формат строки m= выглядит так:

m=<тип_медиа> <порт> <транспорт> <форматы>

Разберём на примере:

m=video 5004 RTP/AVP 96 97
  • video — тип медиа: может быть audio, video, application (например, для DTMF или шаринга), text и др.
  • 5004 — UDP-порт, на котором ожидается приём видеопотока.
  • RTP/AVP — транспортный протокол. Здесь:
    • RTP — Real-time Transport Protocol, основа передачи аудио/видео.
    • AVP — Audio/Video Profile, базовый профиль RTP для мультимедиа.
  • 96 97 — так называемые payload type (PT) — числовые идентификаторы форматов, которые будут использоваться в этом потоке. Эти числа не имеют смысла сами по себе — их значение раскрывается в последующих строках.

💡 Важно: payload type — это локальный идентификатор в рамках одной SDP-сессии. Он не стандартизирован глобально (кроме некоторых зарезервированных значений, например, PT=0 — PCMU). Поэтому без дополнительных строк (rtpmap, fmtp) невозможно понять, что именно означает PT=96.

Сопоставление кодеков: директива rtpmap​

Чтобы указать, какой кодек соответствует тому или иному payload type, используется строка a=rtpmap:. Её формат:

a=rtpmap:<PT> <название_кодека>/<частота>

Пример:

a=rtpmap:96 H264/90000

Здесь:

  • 96 — payload type из строки m=,
  • H264 — название видео-кодека (H.264),
  • 90000 — частота временной шкалы (clock rate), используемая в RTP. Для H.264 она всегда 90 000 Гц — это стандарт, обеспечивающий достаточную точность при синхронизации видео.

📌 Пояснение: частота 90 000 Гц означает, что временные метки в RTP-пакетах увеличиваются на 90 000 за каждую секунду реального времени. Это позволяет точно измерять задержки, синхронизировать аудио и видео, а также обрабатывать потоки с разным FPS (например, 30 или 60 кадров в секунду).

Другой пример — аудио:

a=rtpmap:8 PCMA/8000
  • 8 — payload type,
  • PCMA — кодек A-закон (аналог PCM, используемый в телефонии),
  • 8000 — частота дискретизации, 8 кГц, стандартная для голоса.

Дополнительные параметры кодека: fmtp​

Многие кодеки требуют более точной настройки, чем просто название и частота. Для этого используется директива a=fmtp: (format parameters). Она передаёт параметры, специфичные для конкретного кодека.

Пример для H.264​

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

Разберём ключевые параметры:

profile-level-id​

Это трёхсимвольное шестнадцатеричное значение, описывающее профиль и уровень кодека H.264.

  • Профиль (profile) определяет, какие функции кодека разрешены (например, поддержка B-кадров, множественных резолюций, сложного сжатия).
  • Уровень (level) задаёт ограничения по разрешению, битрейту, частоте кадров и нагрузке на декодер.

Пример: profile-level-id=42e01f

  • 42 — указывает на Baseline Profile (базовый профиль),
  • e0 — уровень 3.1,
  • 1f — дополнительные параметры (например, поддержка определённых разрешений).

🎯 Практическое значение: если один участник поддерживает Baseline Profile, а другой — Main или High, но не совместим с Baseline, согласование не пройдёт. Это частая причина «чёрного экрана» при видеозвонке, даже если оба устройства заявляют поддержку H.264.

packetization-mode​

Определяет способ упаковки видеоданных в RTP-пакеты.

  • packetization-mode=0 — упрощённый режим (не поддерживает фрагментацию NAL-единиц),
  • packetization-mode=1 — расширенный режим, обязательный для передачи по сети.

⚠️ Критически важно: если один участник отправляет packetization-mode=1, а другой ожидает mode=0, они не смогут согласовать видеопоток. Даже формальная поддержка H.264 с обеих сторон не гарантирует совместимость.

Пример сбоя:

  • Устройство A: fmtp:96 profile-level-id=42e01f; packetization-mode=1
  • Устройство B: fmtp:96 profile-level-id=42e01f; packetization-mode=0

→ Согласование не пройдёт, видео не будет работать.

Поддержка нескольких медиапотоков​

SDP позволяет описывать не один, а несколько независимых медиапотоков — каждый со своей строкой m=. Это особенно важно в современных сценариях видеосвязи.

Пример:

m=audio 5002 RTP/AVP 8 0
m=video 5004 RTP/AVP 96
m=video 5006 RTP/AVP 98

Здесь:

  • Первая строка — аудиопоток (G.711 PCMA и PCMU),
  • Вторая — основное видео (H.264),
  • Третья — дополнительное видео, например, шаринг экрана.

Каждый поток использует отдельные порты и может иметь свои кодеки и параметры. Это позволяет организовать сложные сессии, например:

  • Два видео: основная камера + презентация,
  • Несколько аудиопотоков (например, для разных языков),
  • Потоки с разными направлениями (sendonly, recvonly).

Направление медиапотока: a=sendrecv, a=sendonly, a=recvonly​

SDP позволяет указать, в каком направлении может идти поток:

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

Пример:

m=video 5004 RTP/AVP 96
a=sendonly

Такой участок сообщает: «Я готов отправлять видео, но не буду его принимать». Это полезно при инициализации вызова или при управлении ресурсами.

Почему SDP — это механизм переговоров, а не просто объявление​

SDP не гарантирует автоматическую совместимость. Он — инструмент переговоров (negotiation). Успешное согласование происходит только тогда, когда:

  1. Есть хотя бы один общий payload type,
  2. Для этого PT указан один и тот же кодек в rtpmap,
  3. Все параметры в fmtp совпадают или совместимы,
  4. Порты и IP-адреса доступны (с учётом NAT),
  5. Направления потоков согласованы.

🔍 Инженерная практика: при диагностике проблем с видео нужно:

  • Сравнить SDP-описания обеих сторон,
  • Найти общие payload type,
  • Проверить, совпадают ли rtpmap и fmtp,
  • Убедиться, что packetization-mode и profile-level-id совместимы.

Таблица: пример полного описания аудио- и видеопотоков в SDP​

ЭлементПримерПояснение
m=audiom=audio 5002 RTP/AVP 8 0Аудиопоток на порту 5002, PT=8 (PCMA), PT=0 (PCMU)
a=rtpmap (аудио)a=rtpmap:8 PCMA/8000PCMA, 8 кГц, 1 канал
a=rtpmap (видео)a=rtpmap:96 H264/90000H.264, временная шкала 90 кГц
a=fmtpa=fmtp:96 profile-level-id=42e01f; packetization-mode=1Baseline Profile, уровень 3.1, режим фрагментации включён
a=sendrecva=sendrecvДвусторонняя передача
c=c=IN IP4 192.168.1.100IP-адрес для приёма медиа

Заключение: SDP как инструмент диагностики​

SDP — это не просто техническая деталь. Это ключ к пониманию, почему видеосвязь работает или не работает. Инженер, умеющий читать SDP, может:

  • Быстро находить причины сбоев (например, несовпадение packetization-mode),
  • Диагностировать проблемы совместимости между устройствами разных производителей,
  • Настроить шлюзы и медиасерверы для корректного согласования параметров,
  • Понимать, как WebRTC и SIP используют одни и те же принципы описания медиа.

🛠 Совет: при работе с SIP-устройствами или WebRTC-приложениями всегда сохраняйте и анализируйте SDP-предложения (offer) и ответы (answer). Именно в них скрыта настоящая причина большинства проблем с медиа.