SDP — ce este, formatul de descriere a sesiunilor și rolul în WebRTC

Ce este SDP (Session Description Protocol)?

SDP — este un protocol la nivel de aplicație destinat descrierii parametrilor sesiunilor multimedia în format text. A fost dezvoltat în cadrul grupului de lucru MMUSIC (Multiparty Multimedia Session Control) al IETF și standardizat pentru prima dată în RFC 2327 în 1998. În 2021 a fost publicată specificația actuală RFC 8866, care a înlocuit versiunea anterioară RFC 4566.

Sarcina principală a SDP este de a furniza participanților la sesiune toate informațiile necesare pentru stabilirea conexiunii: ce fluxuri media vor fi transmise, ce codecuri sunt suportate, pe ce adrese de rețea și porturi se va face transmisia. SDP nu transmite datele media propriu-zise, ci doar descrie cum trebuie organizată conexiunea.

Conform IETF RFC 8866, formatul SDP constă dintr-un set de linii, fiecare începând cu un tip de o singură literă, urmat de semnul egal și o valoare. De exemplu, linia m=audio 5004 RTP/AVP 0 înseamnă că sesiunea include un flux audio pe portul 5004 cu protocolul de transport RTP/AVP și codecul PCMU (tipul 0).

Istoria și standardizarea SDP

Prima versiune a SDP a fost publicată în RFC 2327 în aprilie 1998 ca rezultat al muncii grupului MMUSIC. Protocolul a fost creat inițial pentru anunțarea sesiunilor multicast în cadrul Mbone (Multicast Backbone). Odată cu dezvoltarea VoIP și a videoconferințelor, domeniul de aplicare al SDP s-a extins, iar în 2006 a fost publicată specificația actualizată RFC 4566.

Adevărata descoperire în utilizarea SDP a avut loc odată cu apariția WebRTC în 2011. Google a integrat SDP ca mecanism principal de descriere a sesiunilor media în cadrul său pentru comunicarea în timp real în browser. De atunci, SDP a devenit o componentă obligatorie a oricărei implementări WebRTC — de la browsere la aplicații mobile pe iOS și Android.

În 2021, grupul de lucru IETF a publicat RFC 8866 — specificația actuală SDP, care a înlocuit RFC 4566. Versiunea actualizată a clarificat gestionarea ICE (Interactive Connectivity Establishment), suportul pentru DTLS (Datagram Transport Layer Security) și a extins capacitățile de descriere a sesiunilor de grup.

Diferența dintre SDP și protocoalele de transport

SDP diferă fundamental de protocoalele de transport prin faptul că nu participă la transmiterea datelor. Îndeplinește exclusiv o funcție descriptivă — similar cu metadatele unui fișier multimedia. În timp ce RTP (Real-time Transport Protocol) transmite pachetele audio și video, iar RTCP controlează calitatea transmisiei, SDP doar indică ce codecuri și porturi să fie utilizate.

O analogie din dezvoltarea web: SDP este marcajul HTML care descrie structura paginii, iar RTP sunt imaginile și textul propriu-zise. Fără SDP, participanții la sesiune nu știu cum să se conecteze unul la altul, chiar dacă conexiunea de rețea este deja stabilită. Mecanismul de NAT-traversal (ICE) se bazează de asemenea pe SDP pentru transmiterea informațiilor despre candidații de rețea.

Cum este structurat SDP

Structura SDP este organizată ca o secvență de linii text, fiecare urmând formatul type=value. Tipul de o singură literă determină scopul liniei, iar valoarea conține valoarea corespunzătoare. Toate liniile sunt separate prin caracterul de linie nouă CRLF.

Standardul RFC 8866 definește mai multe câmpuri obligatorii și opționale. Câmpurile obligatorii includ versiunea protocolului (v=), numele sesiunii (s=), timpul de începere și sfârșit al sesiunii (t=). Celelalte câmpuri sunt opționale, dar pentru sesiunile WebRTC sunt necesare și descrierile media (m=), atributele (a=) și informațiile de rețea (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

În exemplul de mai sus este arătat un segment SDP tipic pentru o sesiune WebRTC. Linia v=0 indică versiunea protocolului. Câmpul o= conține identificatorul proprietarului sesiunii și versiunea acesteia. Linia s=- setează numele sesiunii (cratima înseamnă nume gol). Câmpul t=0 0 indică faptul că sesiunea nu este limitată în timp.

Câmpul a=group:BUNDLE audio video este un atribut care grupează mai multe fluxuri media într-un singur canal de transport. Mecanismul BUNDLE permite economisirea resurselor de rețea prin transmiterea audio și video printr-o singură conexiune. Acest lucru este deosebit de important pentru dispozitivele mobile cu lățime de bandă limitată.

Câmpurile obligatorii SDP

Specificația RFC 8866 definește un set de câmpuri obligatorii și opționale. Câmpurile obligatorii includ v= (versiunea), s= (numele sesiunii) și t= (timpul). Câmpul o= (proprietarul), deși nu este strict obligatoriu conform RFC, este practic întotdeauna prezent în implementările reale.

Câmpul m= (media) este unul dintre cele mai importante. Descrie un flux media specific și conține tipul media (audio, video, text, application), portul, protocolul de transport și lista codecurilor suportate. În WebRTC, cele mai frecvent utilizate sunt tipurile audio și video cu protocoalele de transport RTP/SAVPF (Secure Audio/Video Profile with Feedback) sau UDP/TLS/RTP/SAVPF.

Câmpul a= (attribute) este cel mai flexibil și extensibil. Poate conține rtpmap (maparea numărului de codec la nume), fmtp (parametrii codecului), fingerprint (amprenta cheii DTLS), ice-ufrag și ice-pwd (datele de autentificare ICE) și multe alte atribute. Prin intermediul atributelor, SDP asigură suportul pentru mecanismele moderne de securitate și NAT-traversal.

Cum funcționează SDP în WebRTC

În arhitectura WebRTC, SDP joacă rolul de protocol de semnalizare pentru descrierea și negocierea parametrilor sesiunii media între doi participanți. SDP însuși nu definește mecanismul de transmitere a acestor descrieri — această sarcină este rezolvată de canalul de semnalizare pe care dezvoltatorul îl implementează independent prin WebSocket, HTTP sau alt protocol.

Procesul începe cu crearea unei oferte SDP — Offer de către inițiator (apelant). Pentru aceasta, browserul apelează metoda createOffer() pe obiectul RTCPeerConnection. Descrierea SDP generată conține toți parametrii sesiunii din partea inițiatorului: codecurile suportate, adresele de rețea, candidații ICE și cerințele de securitate.

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

// Creați oferta SDP pe Android
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Trimiteți șirul SDP participantului distant
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

După crearea Offer și setarea descrierii locale prin setLocalDescription(), inițiatorul trimite șirul SDP participantului distant prin canalul de semnalizare. Participantul distant, după primirea SDP Offer, creează un răspuns SDP — Answer — și îl trimite înapoi. Acest schimb se numește schimb de semnalizare (signaling exchange) și este o etapă obligatorie înainte de stabilirea conexiunii peer-to-peer.

Conform Specificației W3C WebRTC, schimbul SDP trebuie să aibă loc înainte de începerea schimbului de candidați ICE. În practică, multe implementări trimit candidații ICE în paralel cu SDP, folosind mecanismul ICE trickle. Acest lucru reduce timpul de stabilire a conexiunii, în special pentru rețelele mobile cu latență mare.

Rolul ICE în SDP

ICE (Interactive Connectivity Establishment) — este un mecanism care utilizează atributele SDP pentru transmiterea informațiilor despre candidații de rețea. Candidații ICE descriu căile posibile de conexiune: host (adresa locală), srflx (adresa după NAT, obținută prin STUN) și relay (adresa serverului TURN).

În SDP, candidații ICE sunt transmiși prin atributele a=candidate:, precum și prin câmpurile ice-ufrag și ice-pwd pentru autentificarea traficului ICE. Fiecare candidat include protocolul de transport (UDP, TCP), adresa IP, portul și prioritatea. Conexiunea reușită se stabilește prin primul candidat care trece testul de conectivitate. Mecanismul ICE restart permite reîmprospătarea conexiunii la schimbarea rețelei.

Pentru aplicațiile mobile, candidații ICE sunt deosebit de importanți, deoarece dispozitivele se află adesea în spatele NAT sau al firewall-urilor corporative. Mecanismul ICE permite găsirea unei căi funcționale chiar și în condiții complexe de rețea, iar SDP servește ca container de transport pentru aceste informații.

Securitatea SDP în WebRTC

SDP în WebRTC include obligatoriu atribute de securitate, în special amprenta DTLS (fingerprint) și parametrii SRTP. Câmpul a=fingerprint:sha-256 conține amprenta certificatului DTLS utilizată pentru autentificarea și criptarea fluxului media. Fără acest atribut, conexiunea WebRTC nu va fi stabilită.

Mecanismele suplimentare de securitate includ atributul a=setup:, care determină rolul strângerii de mână DTLS (active, passive, actpass), și a=ice-lite: pentru o implementare simplificată ICE pe partea serverului. Toți acești parametri sunt transmiși în interiorul SDP și verificați de ambele părți înainte de începerea transmisiei datelor media.

Tipuri de SDP: Offer și Answer

În modelul WebRTC există două tipuri de mesaje SDP: Offer (ofertă) și Answer (răspuns). Offer este creat de inițiatorul conexiunii și conține descrierea completă a sesiunii media dorite. Answer este creat de participantul distant ca răspuns la Offer și conține capacitățile sale ținând cont de limitările impuse de ofertă.

Diferența principală între Offer și Answer constă în semantica atributelor. Offer enumeră toate codecurile, protocoalele de transport și adresele de rețea suportate pe care inițiatorul le poate oferi. Answer selectează un subset al acestor capacități suportate de partea distantă. De exemplu, dacă Offer oferă opus, ISAC și PCMU, Answer poate alege doar opus ca codec cel mai preferat.

Procesul de schimb este reglementat de specificația W3C WebRTC și include mai multe stări ale RTCPeerConnection. După crearea Offer prin createOffer() și setarea sa ca descriere locală, conexiunea trece în starea have-local-offer. După primirea Answer și setarea sa ca descriere distantă prin setRemoteDescription(), conexiunea trece în starea stable — starea finală gata pentru transmiterea media.

Utilizarea SDP în SDK-urile mobile

SDK-urile mobile pentru WebRTC — Google WebRTC pentru Android și WebRTC.framework pentru iOS — suportă complet schimbul SDP prin Offer și Answer. Pe Android, pentru crearea Offer se utilizează clasa PeerConnection cu metoda createOffer(), similară API-ului browserului. Descrierea SDP obținută este transmisă ca șir prin canalul de semnalizare.

Pe iOS, lucrul cu SDP se bazează pe clasa RTCSessionDescription din cadrul WebRTC. La inițializare se specifică tipul (RTCSdpTypeOffer sau RTCSdpTypeAnswer) și șirul SDP. Platforma analizează automat SDP și configurează conexiunea conform parametrilor transmiși.

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())

Posibilitatea de a lucra direct cu șirul SDP oferă dezvoltatorilor flexibilitate: se poate modifica SDP înainte de trimitere, adăugând sau eliminând anumite codecuri, configurând parametrii ICE sau adăugând atribute personalizate. Pentru aplicațiile Android este adesea necesară dezactivarea video în SDP la lățime de bandă redusă — acest lucru se face prin eliminarea liniilor m= corespunzătoare din descrierea SDP.

SDP în dezvoltarea mobilă

În dezvoltarea mobilă, SDP este utilizat preponderent în contextul WebRTC — pentru crearea aplicațiilor cu apeluri video, chat-uri vocale și streaming. Aplicațiile mobile pe Android și iOS pot acționa atât în rolul de inițiator, cât și în rolul de receptor al mesajelor SDP, permițând construirea de conexiuni peer-to-peer simetrice.

Particularitatea aplicațiilor mobile este necesitatea de a lucra cu SDP în condiții de calitate variabilă a rețelei. La comutarea între Wi-Fi și internetul mobil, precum și la modificarea lățimii de bandă, poate fi necesară generarea unei noi descrieri SDP. Pentru aceasta se utilizează mecanismul renegotiation — schimbul repetat de SDP prin createOffer() și setLocalDescription().

Conform echipei Google WebRTC (2023), optimizarea schimbului SDP pentru dispozitivele mobile include utilizarea ICE restart la schimbarea rețelei, prioritizarea codecurilor cu rată de biți redusă (opus pentru audio, VP8 pentru video) și dimensiunea minimă a șirului SDP prin excluderea fluxurilor media inutile. Avantajul cheie este reducerea latenței la stabilirea conexiunii în rețelele mobile.

Optimizarea SDP pentru rețelele mobile

Una dintre sarcinile cheie la lucrul cu SDP pe dispozitivele mobile este minimizarea dimensiunii descrierii SDP. SDP-ul complet pentru o sesiune WebRTC tipică cu audio și video poate ocupa 2–5 KB, ceea ce este semnificativ pentru rețelele lente. Optimizarea include utilizarea BUNDLE (combinarea fluxurilor), eliminarea codecurilor nesuportate și compresia candidaților ICE.

O problemă suplimentară a dispozitivelor mobile este durata de viață limitată a SDP. În condiții de conexiune instabilă, SDP poate expira înainte ca participantul distant să reușească să-l proceseze. Soluția este utilizarea timeout-urilor scurte pentru primirea Answer și retrimiterea SDP la nevoie. Mecanismul ICE restart permite reîmprospătarea conexiunii fără recrearea completă a RTCPeerConnection. Atributul a=ice-lite simplifică implementarea ICE pe partea serverului.

Biblioteci populare pentru lucrul cu SDP

Dezvoltatorii de aplicații mobile au la dispoziție biblioteci gata făcute care simplifică lucrul cu SDP. libjingle_peerconnection (Google WebRTC) — biblioteca principală pentru Android, care oferă un API complet pentru gestionarea SDP. Pentru iOS se utilizează WebRTC.framework cu funcționalitate similară. Ambele biblioteci generează și analizează automat SDP, dar oferă acces la șirul SDP brut la nevoie.

Pentru un control mai fin asupra SDP, există soluții terțe: sdp-transform (JavaScript sau Node.js) pentru analiza și modificarea SDP, NICENICE (Java) pentru lucrul cu candidații ICE și SDK-uri gata făcute de la furnizorii de infrastructură WebRTC, care preiau întregul schimb de semnalizare, inclusiv SDP.