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-траверсала (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-траверсала.

Како 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.