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 като основен механизъм за описание на медийни сесии в своята рамка за комуникация в реално време в браузъра. От този момент 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-traversal (ICE) също разчита на SDP за предаване на информация за мрежови кандидати.

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

Структурата на SDP е организирана като последователност от текстови редове, всеки от които следва формата 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-traversal.

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

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

Процесът започва със създаване на SDP предложение — Offer от инициатора (обаждащия се). За целта браузърът извиква метода createOffer() на обекта RTCPeerConnection. Генерираното SDP описание съдържа всички параметри на сесията от страна на инициатора: поддържани кодеци, мрежови адреси, ICE кандидати и изисквания за сигурност.

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

// Създайте SDP предложение на Android
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Изпратете SDP низ на отдалечения участник
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 спецификацията, 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 спецификацията и включва няколко състояния на 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 (2023), оптимизацията на SDP обмена за мобилни устройства включва използване на ICE restart при промяна на мрежата, приоритизиране на кодеци с нисък битрейт (opus за аудио, VP8 за видео) и минимален размер на SDP низа чрез изключване на ненужни медийни потоци. Ключовото предимство е намалено закъснение при установяване на връзка в мобилни мрежи.

Оптимизация на SDP за мобилни мрежи

Една от ключовите задачи при работа с SDP на мобилни устройства е минимизиране на размера на SDP описанието. Пълният SDP за типична WebRTC сесия с аудио и видео може да заема 2–5 KB, което е значително за бавни мрежи. Оптимизацията включва използване на 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.