SDP — cos'è, formato di descrizione delle sessioni e ruolo in WebRTC

Cos'è SDP (Session Description Protocol)?

SDP è un protocollo a livello applicativo progettato per descrivere parametri di sessioni multimediali in formato testuale. È stato sviluppato all'interno del gruppo di lavoro MMUSIC (Multiparty Multimedia Session Control) dell'IETF e standardizzato per la prima volta nella RFC 2327 nel 1998. Nel 2021 è stata pubblicata la specifica corrente RFC 8866, che ha sostituito la versione precedente RFC 4566.

Il compito principale di SDP è fornire ai partecipanti alla sessione tutte le informazioni necessarie per stabilire una connessione: quali flussi multimediali verranno trasmessi, quali codec sono supportati e attraverso quali indirizzi di rete e porte avverrà la trasmissione. SDP non trasmette i dati multimediali stessi, ma descrive solo come deve essere organizzata la connessione.

Secondo IETF RFC 8866, il formato SDP consiste in un insieme di righe, ciascuna delle quali inizia con un tipo di una singola lettera, seguita da un segno di uguale e un valore. Ad esempio, la riga m=audio 5004 RTP/AVP 0 significa che la sessione include un flusso audio sulla porta 5004 con protocollo di trasporto RTP/AVP e codec PCMU (tipo 0).

Storia e standardizzazione di SDP

La prima versione di SDP è stata pubblicata nella RFC 2327 nell'aprile 1998 come risultato del lavoro del gruppo MMUSIC. Il protocollo è stato originariamente creato per annunciare sessioni multicast all'interno di Mbone (Multicast Backbone). Con lo sviluppo di VoIP e videoconferenze, l'ambito di applicazione di SDP si è ampliato e nel 2006 è stata pubblicata la specifica aggiornata RFC 4566.

Una vera svolta nell'uso di SDP è avvenuta con l'avvento di WebRTC nel 2011. Google ha integrato SDP come meccanismo principale per descrivere sessioni multimediali nel suo framework per la comunicazione in tempo reale basata su browser. Da allora, SDP è diventato un componente obbligatorio di qualsiasi implementazione WebRTC — dai browser alle applicazioni mobili su iOS e Android.

Nel 2021, il gruppo di lavoro IETF ha pubblicato RFC 8866 — la specifica corrente di SDP, che ha sostituito RFC 4566. La versione aggiornata ha chiarito l'elaborazione di ICE (Interactive Connectivity Establishment), il supporto di DTLS (Datagram Transport Layer Security) e ha ampliato le capacità di descrizione delle sessioni di gruppo.

Differenza tra SDP e protocolli di trasporto

SDP differisce fondamentalmente dai protocolli di trasporto in quanto non partecipa alla trasmissione dei dati. Svolge una funzione puramente descrittiva — simile ai metadati di un file multimediale. Mentre RTP (Real-time Transport Protocol) trasmette pacchetti audio e video, e RTCP controlla la qualità di trasmissione, SDP specifica solo quali codec e porte utilizzare.

Un'analogia dallo sviluppo web: SDP è come il markup HTML che descrive la struttura della pagina, mentre RTP sono le immagini e il testo reali. Senza SDP, i partecipanti alla sessione non sanno come connettersi tra loro, anche se la connessione di rete è già stabilita. Il meccanismo di NAT traversal (ICE) si basa anche su SDP per trasmettere informazioni sui candidati di rete.

Come è strutturato SDP

La struttura SDP è organizzata come una sequenza di righe di testo, ciascuna delle quali segue il formato type=value. Il tipo di una singola lettera definisce lo scopo della riga e il valore contiene il valore corrispondente. Tutte le righe sono separate da un carattere CRLF.

Lo standard RFC 8866 definisce diversi campi obbligatori e opzionali. I campi obbligatori includono la versione del protocollo (v=), il nome della sessione (s=) e l'ora di inizio e fine della sessione (t=). I campi rimanenti sono opzionali, ma per le sessioni WebRTC sono necessarie anche le descrizioni dei supporti (m=), gli attributi (a=) e le informazioni di rete (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

L'esempio sopra mostra un segmento SDP tipico per una sessione WebRTC. La riga v=0 indica la versione del protocollo. Il campo o= contiene l'identificatore del proprietario della sessione e la sua versione. La riga s=- specifica il nome della sessione (un trattino significa nome vuoto). Il campo t=0 0 indica che la sessione non è limitata nel tempo.

Il campo a=group:BUNDLE audio video è un attributo che raggruppa più flussi multimediali in un unico canale di trasporto. Il meccanismo BUNDLE consente di risparmiare risorse di rete trasmettendo audio e video attraverso una singola connessione. Ciò è particolarmente importante per i dispositivi mobili con larghezza di banda limitata.

Campi obbligatori di SDP

La specifica RFC 8866 definisce un insieme di campi obbligatori e opzionali. I campi obbligatori includono v= (versione), s= (nome sessione) e t= (tempo). Il campo o= (proprietario), sebbene non sia strettamente obbligatorio secondo RFC, è quasi sempre presente nelle implementazioni reali.

Il campo m= (media) è uno dei più importanti. Descrive un flusso multimediale specifico e contiene il tipo di supporto (audio, video, text, application), la porta, il protocollo di trasporto e l'elenco dei codec supportati. In WebRTC, i tipi più comunemente utilizzati sono audio e video con protocolli di trasporto RTP/SAVPF (Secure Audio/Video Profile with Feedback) o UDP/TLS/RTP/SAVPF.

Il campo a= (attribute) è il più flessibile ed estensibile. Può contenere rtpmap (mappatura del numero del codec al nome), fmtp (parametri del codec), fingerprint (impronta digitale della chiave DTLS), ice-ufrag e ice-pwd (credenziali ICE) e molti altri attributi. È attraverso gli attributi che SDP supporta i moderni meccanismi di sicurezza e NAT traversal.

Come funziona SDP in WebRTC

Nell'architettura WebRTC, SDP funge da protocollo di segnalazione per descrivere e negoziare i parametri della sessione multimediale tra due partecipanti. SDP stesso non definisce il meccanismo per trasmettere queste descrizioni — questo compito è gestito dal canale di segnalazione, che lo sviluppatore implementa autonomamente tramite WebSocket, HTTP o un altro protocollo.

Il processo inizia quando l'iniziatore (chiamante) crea un'offerta SDP (Offer). Per fare ciò, il browser chiama il metodo createOffer() sull'oggetto RTCPeerConnection. La descrizione SDP generata contiene tutti i parametri di sessione dal lato dell'iniziatore: codec supportati, indirizzi di rete, candidati ICE e requisiti di sicurezza.

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

// Aggiungi tracce multimediali prima di createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Crea SDP Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Invia SDP al peer remoto tramite canale di segnalazione
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Dopo aver creato l'Offer e impostato la descrizione locale tramite setLocalDescription(), l'iniziatore invia la stringa SDP al partecipante remoto attraverso il canale di segnalazione. Il partecipante remoto, ricevuto l'SDP Offer, crea una risposta SDP (Answer) e la reinvia. Questo scambio è chiamato scambio di segnalazione ed è un passaggio obbligatorio prima di stabilire una connessione peer-to-peer.

Secondo la specifica W3C WebRTC, lo scambio SDP dovrebbe avvenire prima dell'inizio dei candidati ICE. In pratica, molte implementazioni inviano candidati ICE in parallelo con SDP utilizzando il meccanismo ICE trickle. Ciò riduce il tempo di stabilimento della connessione, specialmente per le reti mobili con alta latenza.

Il ruolo di ICE in SDP

ICE (Interactive Connectivity Establishment) è un meccanismo che utilizza attributi SDP per trasmettere informazioni sui candidati di rete. I candidati ICE descrivono possibili percorsi di connessione: host (indirizzo locale), srflx (indirizzo dopo NAT, ottenuto tramite STUN) e relay (indirizzo del server TURN).

In SDP, i candidati ICE vengono trasmessi tramite attributi a=candidate:, nonché tramite i campi ice-ufrag e ice-pwd per l'autenticazione del traffico ICE. Ogni candidato include il protocollo di trasporto (UDP, TCP), l'indirizzo IP, la porta e la priorità. Una connessione riuscita viene stabilita tramite il primo candidato che supera i controlli di connettività. Il meccanismo ICE restart consente di aggiornare la connessione al cambiamento della rete.

Per le applicazioni mobili, i candidati ICE sono particolarmente importanti perché i dispositivi sono spesso dietro NAT o firewall aziendali. Il meccanismo ICE consente di trovare un percorso funzionante anche in condizioni di rete complesse, e SDP funge da contenitore di trasporto per queste informazioni.

Sicurezza di SDP in WebRTC

SDP in WebRTC include necessariamente attributi di sicurezza, in particolare l'impronta digitale DTLS e i parametri SRTP. Il campo a=fingerprint:sha-256 contiene l'impronta digitale del certificato DTLS, utilizzato per l'autenticazione e la crittografia del flusso multimediale. Senza questo attributo, la connessione WebRTC non verrà stabilita.

Meccanismi di sicurezza aggiuntivi includono l'attributo a=setup:, che definisce il ruolo dell'handshake DTLS (active, passive, actpass), e a=ice-lite: per un'implementazione ICE semplificata sul lato server. Tutti questi parametri vengono trasmessi all'interno di SDP e verificati da entrambe le parti prima dell'inizio della trasmissione dei dati multimediali.

Tipi di SDP: Offer e Answer

Nel modello WebRTC, esistono due tipi di messaggi SDP: Offer (offerta) e Answer (risposta). L'Offer viene creata dall'iniziatore della connessione e contiene una descrizione completa della sessione multimediale desiderata. La Answer viene creata dal partecipante remoto in risposta all'Offer e contiene le proprie capacità tenendo conto dei vincoli imposti dall'offerta.

La differenza principale tra Offer e Answer risiede nella semantica degli attributi. L'Offer elenca tutti i codec, i protocolli di trasporto e gli indirizzi di rete supportati che l'iniziatore può proporre. La Answer seleziona un sottoinsieme di queste capacità che la parte remota supporta. Ad esempio, se l'Offer propone opus, ISAC e PCMU, la Answer può selezionare solo opus come codec più preferito.

Il processo di scambio è regolato dalla specifica W3C WebRTC e include diversi stati di RTCPeerConnection. Dopo aver creato l'Offer tramite createOffer() e averla impostata come descrizione locale, la connessione entra nello stato have-local-offer. Dopo aver ricevuto la Answer e averla impostata come descrizione remota tramite setRemoteDescription(), la connessione entra nello stato stable — lo stato finale pronto per la trasmissione multimediale.

Utilizzo di SDP negli SDK mobili

Gli SDK mobili per WebRTC — Google WebRTC per Android e WebRTC.framework per iOS — supportano completamente lo scambio SDP tramite Offer e Answer. Su Android, la classe PeerConnection con il metodo createOffer() viene utilizzata per creare un'Offer, simile all'API del browser. La descrizione SDP risultante viene trasmessa come stringa tramite il canale di segnalazione.

Su iOS, il lavoro con SDP viene effettuato tramite la classe RTCSessionDescription del framework WebRTC. Durante l'inizializzazione, vengono specificati il tipo (RTCSdpTypeOffer o RTCSdpTypeAnswer) e la stringa SDP. La piattaforma analizza automaticamente l'SDP e configura la connessione secondo i parametri trasmessi.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Crea SDP Offer su Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Invia stringa SDP al peer remoto
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

La capacità di lavorare direttamente con la stringa SDP offre flessibilità agli sviluppatori: possono modificare l'SDP prima dell'invio, aggiungendo o rimuovendo codec specifici, configurando parametri ICE o aggiungendo attributi personalizzati. Per le applicazioni Android, è spesso necessario disabilitare il video in SDP quando la larghezza di banda della rete è bassa — ciò viene fatto rimuovendo le righe m= corrispondenti dalla descrizione SDP.

SDP nello sviluppo mobile

Nello sviluppo mobile, SDP viene utilizzato principalmente nel contesto di WebRTC — per creare applicazioni con videochiamate, chat vocali e streaming. Le applicazioni mobili su Android e iOS possono agire sia come iniziatore che come ricevitore di messaggi SDP, consentendo connessioni peer-to-peer simmetriche.

Una caratteristica delle applicazioni mobili è la necessità di lavorare con SDP in condizioni di qualità di rete variabile. Durante il passaggio tra Wi-Fi e Internet mobile, nonché al variare della larghezza di banda, potrebbe essere necessaria la generazione di una nuova descrizione SDP. Ciò viene fatto utilizzando il meccanismo di rinegoziazione — uno scambio SDP ripetuto tramite createOffer() e setLocalDescription().

Secondo il team Google WebRTC (2023), l'ottimizzazione dello scambio SDP per dispositivi mobili include l'uso di ICE restart durante i cambi di rete, la priorità dei codec a basso bitrate (opus per audio, VP8 per video) e la minimizzazione della dimensione della stringa SDP escludendo flussi multimediali non necessari. Il vantaggio principale è la riduzione della latenza durante lo stabilimento di una connessione in condizioni di reti mobili.

Ottimizzazione di SDP per reti mobili

Uno dei compiti principali quando si lavora con SDP su dispositivi mobili è minimizzare la dimensione della descrizione SDP. Un SDP completo per una tipica sessione WebRTC con audio e video può occupare 2–5 KB, il che è significativo per reti lente. L'ottimizzazione include l'uso di BUNDLE (multiplexing dei flussi), la rimozione di codec non supportati e la compressione dei candidati ICE.

Un problema aggiuntivo per i dispositivi mobili è la durata limitata dell'SDP. In condizioni di connessione instabile, l'SDP può diventare obsoleto prima che il partecipante remoto possa elaborarlo. La soluzione è utilizzare timeout brevi per ricevere la Answer e reinviare l'SDP se necessario. Il meccanismo ICE restart consente di aggiornare la connessione senza ricreare completamente il RTCPeerConnection. L'attributo a=ice-lite semplifica l'implementazione ICE sul lato server.

Librerie popolari per lavorare con SDP

Gli sviluppatori di applicazioni mobili hanno accesso a librerie pronte che semplificano il lavoro con SDP. libjingle_peerconnection (Google WebRTC) è la libreria principale per Android, che fornisce un'API completa per la gestione di SDP. Per iOS, viene utilizzato WebRTC.framework con funzionalità simili. Entrambe le librerie generano e analizzano automaticamente l'SDP, ma forniscono accesso alla stringa SDP grezza quando necessario.

Per un controllo più preciso sull'SDP, esistono soluzioni di terze parti: sdp-transform (JavaScript o Node.js) per analizzare e modificare SDP, NICENICE (Java) per lavorare con candidati ICE e SDK pronti di fornitori di infrastruttura WebRTC che gestiscono tutto lo scambio di segnalazione, incluso SDP.