SDP (Session Description Protocol, RFC 4566) — это текстовый формат, который SIP переносит для описания медиасессии — IP-адрес, порты, типы медиа и кодеки, предлагаемые каждой стороной. Это не транспорт; это описание. SIP использует его в обмене offer/answer (RFC 3264) для согласования медиа, которыми будут обмениваться конечные точки поверх RTP.
Что такое SDP
SDP — это небольшой построчный текстовый формат, описывающий мультимедийную сессию: какие медиа (аудио, видео), куда их отправлять (адрес соединения и порт), какие кодеки приемлемы и в каком направлении они могут течь. SIP не интерпретирует сами медиа; он несёт SDP в теле сообщения (Content-Type: application/sdp) и позволяет конечным точкам согласовать параметры. SDP чисто описателен — он не несёт медиа и сам ничего не согласует; согласование возникает из того, как SIP обменивается двумя телами SDP.
Структура строк
Тело SDP — это последовательность однобуквенных типовых строк в фиксированном порядке, разбитых на секцию уровня сессии, за которой следуют одна или несколько секций уровня медиа, каждая из которых начинается со строки m=. Самые важные — o= (источник и идентификатор сессии), c= (адрес соединения), m= (тип медиа, порт, транспорт и форматы) и строки атрибутов a=, несущие карты кодеков и направление. Строки упорядочены и чувствительны к регистру.
| Строка | Имя | Передает |
|---|---|---|
| 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.
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. Перечисление кодеков в порядке предпочтения позволяет отвечающему выбрать лучший взаимно поддерживаемый.
| 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) — это то, как реализуются удержание вызова, возобновление и музыка на удержании без разрыва диалога.
| Атрибут | Значение |
|---|---|
| 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 для возобновления. Диалог остаётся, меняется только направление медиа.
Технические характеристики источника
На этой странице представлены опубликованные стандарты, на которых они основаны. (Открывается в новой вкладке)