# SDP: Session Description Protocol

> SDP (Session Description Protocol, RFC 4566) — это текстовый формат, который SIP переносит для описания медиасессии — IP-адрес, порты, типы медиа и кодеки, предлагаемые каждой стороной. Это не транспорт; это описание. SIP использует его в обмене offer/answer (RFC 3264) для согласования медиа, которыми будут обмениваться конечные точки поверх RTP.

- Канонический URL: https://www.broadnet.me/ru/reference/sdp-session-description-protocol
- Язык: ru
- Последнее обновление: 2026-07-18
- Издатель: BroadNet (https://www.broadnet.me)

Как SDP описывает медиасессию внутри SIP: структура строк v=/o=/s=/c=/t=/m=/a=, модель offer/answer (RFC 3264), согласование кодеков через rtpmap и атрибуты направления медиа.

## Что такое SDP

SDP — это небольшой построчный текстовый формат, описывающий мультимедийную сессию: какие медиа (аудио, видео), куда их отправлять (адрес соединения и порт), какие кодеки приемлемы и в каком направлении они могут течь. SIP не интерпретирует сами медиа; он несёт SDP в теле сообщения (Content-Type: application/sdp) и позволяет конечным точкам согласовать параметры. SDP чисто описателен — он не несёт медиа и сам ничего не согласует; согласование возникает из того, как SIP обменивается двумя телами SDP.

## Структура строк

Тело SDP — это последовательность однобуквенных типовых строк в фиксированном порядке, разбитых на секцию уровня сессии, за которой следуют одна или несколько секций уровня медиа, каждая из которых начинается со строки m=. Самые важные — o= (источник и идентификатор сессии), c= (адрес соединения), m= (тип медиа, порт, транспорт и форматы) и строки атрибутов a=, несущие карты кодеков и направление. Строки упорядочены и чувствительны к регистру.

*Типы строк SDP*

| Строка | Имя | Передает |
|---|---|---|
| v= | Версия | Версия SDP (0) |
| o= | Источник | Имя пользователя, идентификатор/версия сессии, сеть/адрес |
| s= | Название сессии | Метка для сессии |
| c= | Соединение | Тип сети, тип адреса и IP-адрес медиа |
| t= | Тайминг | Время начала/окончания (0 0 для неограниченного вызова) |
| m= | Медиаданные | Тип медиа, порт, транспорт (RTP/AVP…) и форматы |
| a= | Атрибуты | rtpmap, fmtp, ptime, direction (sendrecv…) и многое другое |

## Модель offer/answer

SIP согласует медиа моделью offer/answer из RFC 3264. Одна конечная точка отправляет предложение SDP (обычно в INVITE), перечисляющее медиапотоки и каждый кодек, который она готова использовать. Другая возвращает ответ SDP (обычно в 200 OK), выбирая из предложенного — оставляя только кодеки, которые она тоже поддерживает, в своём предпочтительном порядке, и задавая направление. Результат — пересечение, о котором договорились обе стороны. Несовпадение без общего кодека даёт 488 Not Acceptable Here.

*Предложение SDP для одного аудиопотока*

```text
v=0
o=alice 2890844526 2890844526 IN IP4 host.example.com
s=-
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:20
a=sendrecv
```

## Кодеки и типы полезной нагрузки

Строка m= перечисляет номера типов полезной нагрузки RTP, а каждый a=rtpmap сопоставляет номер с кодеком и тактовой частотой. Типы полезной нагрузки 0–95 включают статические назначения (0 = PCMU/G.711 µ-law, 8 = PCMA/G.711 A-law, 9 = G722, 18 = G729), тогда как 96–127 динамические и должны определяться rtpmap. a=fmtp несёт специфичные для кодека параметры, а telephone-event (RFC 4733) — это то, как согласуется DTMF. Перечисление кодеков в порядке предпочтения позволяет отвечающему выбрать лучший взаимно поддерживаемый.

*Распространённые типы полезной нагрузки аудио RTP*

| PT | Кодек | Тактовый сигнал | Примечание |
|---|---|---|---|
| 0 | PCMU (G.711 µ-law) | 8000 | Статический; ~64 кбит/с, качество телефонной связи (toll quality) |
| 8 | PCMA (G.711 A-law) | 8000 | Статический; ~64 кбит/с, качество телефонной связи (toll quality) |
| 9 | G722 | 8000 | Широкополосный (аудиочастота 16 кГц) |
| 18 | G729 | 8000 | Статический; сжатый ~8 кбит/с |
| 96–127 | Динамический (Opus, telephone-event…) | варьируется | Определено a=rtpmap |

## Атрибуты направления медиа

Атрибут направления a= задаёт, как медиа текут для потока. sendrecv — обычное двунаправленное значение по умолчанию. sendonly и recvonly ограничивают поток одним направлением — используются для удержания, объявлений и одностороннего медиа. inactive полностью останавливает медиа, сохраняя сессию. Переключение их (например, sendonly ⇄ sendrecv в re-INVITE) — это то, как реализуются удержание вызова, возобновление и музыка на удержании без разрыва диалога.

*Атрибуты направления SDP*

| Атрибут | Значение |
|---|---|
| a=sendrecv | Отправка и приём медиа (по умолчанию) |
| a=sendonly | Только отправка (например, объявление или удерживаемая сторона) |
| a=recvonly | Только приём (например, сторона, поставленная на удержание) |
| a=inactive | Нет медиа ни в одном направлении; сессия сохраняется |

## Частые вопросы

### Для чего используется SDP в SIP?

SDP описывает медиасессию — IP-адрес, порты, типы медиа и кодеки, предлагаемые каждой конечной точкой. SIP несёт два тела SDP в обмене offer/answer, чтобы согласовать, каким аудио или видео будут обмениваться конечные точки поверх RTP. Сам SDP не несёт медиа.

### Что такое модель offer/answer в SIP?

Определённая в RFC 3264, это то, как SIP согласует медиа: одна сторона отправляет предложение SDP (часто в INVITE), перечисляющее свои медиа и кодеки, а другая возвращает ответ SDP (часто в 200 OK), выбирая подмножество, которое она тоже поддерживает. Согласованное пересечение — это то, что течёт.

### Что означает строка m= в SDP?

Строка m= (media) объявляет медиапоток: его тип (аудио/видео), порт для отправки, транспорт (например, RTP/AVP или RTP/SAVP для SRTP) и список номеров типов полезной нагрузки RTP. Каждый тип полезной нагрузки затем описывается строкой a=rtpmap.

### Как выбираются кодеки в вызове SIP?

Предлагающий перечисляет приемлемые кодеки в порядке предпочтения в SDP. Отвечающий оставляет только те, которые он тоже поддерживает, и возвращает их, фактически выбирая лучший взаимно поддерживаемый кодек. Если наборы не пересекаются, согласование не удаётся, обычно с 488 Not Acceptable Here.

### Как выполняется удержание вызова с помощью SDP?

Изменением атрибута направления медиа в re-INVITE — например, установкой a=sendonly (или исторически нулевого адреса соединения), чтобы поставить дальнюю сторону на удержание, и a=sendrecv для возобновления. Диалог остаётся, меняется только направление медиа.

## Источники

- [IETF RFC 4566 — SDP: Session Description Protocol](https://datatracker.ietf.org/doc/html/rfc4566)
- [IETF RFC 3264 — An Offer/Answer Model with SDP](https://datatracker.ietf.org/doc/html/rfc3264)

## См. также

- [RTP и SRTP медиа](https://www.broadnet.me/ru/reference/rtp-and-srtp-media)
- [Схема вызова SIP](https://www.broadnet.me/ru/reference/sip-call-flow)
- [Методы и запросы SIP](https://www.broadnet.me/ru/reference/sip-methods-and-requests)
- [Заголовки SIP](https://www.broadnet.me/ru/reference/sip-headers)
- [Программируемый голос (продукт)](https://www.broadnet.me/ru/products/voice)