VoIP, SIP e protocollo SDP: come funziona davvero la negoziazione dei media

Quando si parla di VoIP (Voice over IP), molti pensano subito al protocollo SIP come “il protocollo del VoIP”. In realtà una chiamata VoIP è il risultato del lavoro congiunto di più protocolli: SIP per la segnalazione, SDP (Session Description Protocol) per descrivere la sessione multimediale e RTP/RTCP per il trasporto e il controllo del flusso audio/video. Guide tecniche come l’articolo di 3CX su cos’è il Session Description Protocol chiariscono proprio questo ruolo di SDP come “lingua comune” con cui gli endpoint si dichiarano le proprie capacità media.

In questa guida vediamo cos’è il protocollo SDP, come si inserisce nei messaggi SIP, come funziona il modello di offer/answer, quali informazioni contiene (IP, porte, codec, direzione del flusso) e perché è cruciale quando si fa troubleshooting di problemi audio nel VoIP. Se vuoi un’introduzione più ampia al lessico della telefonia IP, puoi partire da contenuti dedicati al VoIP aziendale e agli acronimi fondamentali del VoIP.

Perché SIP da solo non basta: il “pacchetto” VoIP

SIP, SDP, RTP e RTCP: i quattro pilastri

In una tipica chiamata VoIP SIP entrano in gioco quattro protocolli:

SIP (Session Initiation Protocol), definito nella RFC 3261, gestisce la segnalazione: instaurare, modificare e terminare le sessioni;
SDP (Session Description Protocol), definito nella RFC 4566, descrive le caratteristiche della sessione multimediale (media, codec, IP, porte);
RTP (Real‑time Transport Protocol), definito nella RFC 3550, trasporta in tempo reale il flusso audio/video;
RTCP (Real‑time Control Protocol), complementare a RTP, fornisce statistiche e feedback sulla qualità della trasmissione.

Un buon modo per ricordarlo è: SIP prepara la “telefonata”, SDP negozia come deve avvenire, RTP trasporta la voce e RTCP controlla che la qualità resti accettabile.

Panoramica del flusso SIP + SDP + RTP

Una chiamata tipica segue una sequenza simile a quella descritta nella guida Understanding the SIP Protocol:

l’endpoint A (User Agent, telefono IP o softphone) invia un SIP INVITE con un blocco SDP (offer);
l’endpoint B risponde con un 200 OK che contiene un SDP di answer;
A invia un ACK e i due endpoint iniziano a scambiarsi traffico RTP/RTCP sulle porte concordate.

Capire cosa c’è negli SDP di offer e answer è fondamentale per capire quali codec verranno usati, su quali IP e porte avverrà il traffico e perché, a volte, l’audio manca o è monodirezionale.

Cos’è il protocollo SDP (Session Description Protocol)

Definizione e RFC di riferimento

Secondo la RFC 4566 dell’IETF, SDP è un formato testuale per descrivere sessioni multimediali (audio, video, dati) ai fini di annuncio, invito e partecipazione. Non è un protocollo di trasporto: è un formato che può viaggiare su vari protocolli, tra cui SIP, SAP, RTSP, email e HTTP.

In pratica, SDP è un blocco di testo strutturato che indica:

quali media fanno parte della sessione (audio, video, ecc.);
su quali indirizzi IP e porte verranno inviati i flussi;
quali codec/formati sono supportati e con quali parametri;
altri attributi (banda, direzione del flusso, opzioni di sicurezza).

SDP come descrizione della sessione, non trasporto dei media

È importante sottolineare che SDP non trasporta i media: è solo un contenitore di metadati che descrive i media. Il trasporto vero e proprio viene poi effettuato da RTP (per la voce e il video) e da protocolli complementari come RTCP.

Dove si trova l’SDP nei messaggi SIP

Nel contesto SIP VoIP, l’SDP è di solito inserito nel body dei messaggi SIP, con content-type application/sdp. In particolare:

può essere presente nell’INVITE iniziale (SDP offer);
compare nella risposta 200 OK (SDP answer);
può essere usato in messaggi successivi (re‑INVITE, UPDATE) per modificare la sessione.

Il modello offer/answer: come SDP decide IP, porte e codec

Chi invia l’offer e chi risponde con l’answer

Il modello offer/answer, formalizzato nella RFC 3264 e ampiamente usato in SIP e WebRTC, prevede che:

una parte invii una offerta SDP con la lista dei media e dei codec che supporta;
l’altra parte risponda con una answer SDP, selezionando un sottoinsieme compatibile di media/codec.

Questo permette ai due endpoint (User Agent) di negoziare dinamicamente come scambiare audio e video, pur partendo da capacità diverse.

Negoziazione dei codec e fallimenti di compatibilità

L’offer SDP può elencare codec come G.711 (PCMU/PCMA), G.729, Opus, GSM, ciascuno identificato da un payload type. La answer SDP indicherà solo i codec accettati: se non esiste un codec comune, la sessione non può essere stabilita e la chiamata va in errore.

Per chi fa troubleshooting, controllare i campi m= e a=rtpmap nell’SDP è il modo più rapido per capire perché due sistemi non riescono a parlarsi (ad esempio, un IP‑PBX che supporta solo G.711 e un trunk che accetta solo G.729).

Modifica di una sessione in corso: re‑INVITE e UPDATE

Una volta stabilita una SIP session, è possibile cambiare parametri media (ad esempio mettere in hold, aggiungere video, cambiare codec) tramite un nuovo SDP scambiato in re‑INVITE o UPDATE. Anche in questo caso si utilizza il modello offer/answer per negoziare i cambiamenti.

Struttura di base di un messaggio SDP

Le tre sezioni principali

Un messaggio SDP si divide in tre macro‑sezioni:

Session Description: informazioni generali sulla sessione;
Time Description: quando la sessione è attiva;
Media Description: dettagli dei singoli flussi media (audio, video, ecc.).

Campi di sessione più usati

Tra i campi più importanti a livello di sessione troviamo:

v= versione del protocollo SDP;
o= origin (identifica chi ha creato la sessione, id e versione);
s= session name;
c= connection info (IP di riferimento, se non ridefinito sui media);
b= bandwidth;
a= attribute (attributi generali di sessione).

Descrizione temporale (t=, r=) e media (m=, a=)

La sezione temporale usa campi come t= (start/stop time) e r= (ripetizioni), ma nel VoIP spesso si usa un valore “sempre attivo”. La sezione media descrive invece ciascun flusso con:

m= (es. m=audio 4000 RTP/AVP 0 8 18): tipo media, porta, protocollo (RTP/AVP, RTP/SAVP, ecc.) e payload type;
a= a livello media: a=rtpmap, a=fmtp, a=sendrecv, a=ptime, a=rtcp, ecc.

Campi SDP “da troubleshooting”

m=audio, a=rtpmap, a=fmtp: capire codec e parametri

Il campo m=audio definisce porta e lista di payload type; a=rtpmap mappa ogni payload type a un codec (es. 0 → PCMU, 8 → PCMA, 96 → Opus), mentre a=fmtp specifica parametri come bitrate, modalità e profili. Articoli divulgativi come quello di 3CX su SDP in ambito SIP mostrano esempi di queste righe in contesti reali.

a=sendrecv, sendonly, recvonly, inactive

Gli attributi di direzione:

a=sendrecv (default): endpoint invia e riceve media;
a=sendonly: invia soltanto;
a=recvonly: riceve soltanto;
a=inactive: flusso sospeso da entrambe le parti.

Questi flag sono essenziali per capire perché, ad esempio, una parte sente ma non viene sentita o perché una conferenza risulta muta da un lato.

a=ptime, a=rtcp, a=rtcp-mux

Altri attributi comuni:

a=ptime: tempo di packetizzazione (es. 20 ms, 30 ms);
a=rtcp: porta RTCP se diversa da quella RTP+1;
a=rtcp-mux: indica che RTP e RTCP condividono la stessa porta (multiplexing).

SDP, NAT e firewall: perché a volte l’audio non si sente

Il problema dell’IP privato nel campo c=

Uno dei problemi più comuni nel VoIP è vedere, nel campo c= dell’SDP, un indirizzo IP privato (es. 192.168.x.x) che non è raggiungibile dall’altro endpoint perché si trova dietro NAT o firewall. In questa situazione, anche se SIP funziona, i pacchetti RTP non raggiungono la destinazione corretta.

SIP ALG, STUN, TURN, ICE e attributi SDP correlati

Per correggere questi problemi si usano meccanismi come:

SIP ALG (a volte più dannoso che utile, se mal implementato);
STUN/TURN/ICE, che permettono ai client di scoprire il proprio IP pubblico e negoziare percorsi media funzionali;
attributi SDP come a=ice-ufrag, a=ice-pwd, a=candidate, a=end-of-candidates, molto usati in WebRTC e in soluzioni VoIP moderne.

La RFC 8839 (offer/answer per ICE) spiega nel dettaglio come SDP venga esteso per includere credenziali e candidate ICE necessari a far funzionare i media dietro NAT complessi.

Cosa controllare nell’SDP quando l’audio manca o è monodirezionale

In fase di troubleshooting, le prime domande sono:

l’IP nel c= e la porta nel m=audio sono raggiungibili dall’altro lato?
un eventuale SBC o firewall sta riscrivendo correttamente IP/porte nel body SDP?
il flusso RTP arriva ma è bloccato da direzioni errate (sendonly/recvonly)?

SDP e sicurezza: da RTP a SRTP

Come indicare SRTP in SDP

Per proteggere la voce si usa spesso SRTP (Secure RTP), che cifra il flusso audio/video. In SDP questo viene indicato usando profili come RTP/SAVP o RTP/SAVPF nel campo m=, e attributi come a=crypto (modelli più vecchi) o a=setup, a=connection per DTLS‑SRTP.

Perché il campo k= è obsoleto

Storicamente SDP prevedeva il campo k= per indicare chiavi di cifratura, ma oggi è considerato obsoleto e insicuro. Le implementazioni moderne preferiscono negoziare le chiavi tramite protocolli sicuri come DTLS (nel caso di DTLS‑SRTP) o altre procedure out‑of‑band.

SIP su TLS e privacy del body SDP

Usare SIP su TLS protegge l’intero messaggio SIP, incluso il body SDP, durante il transito tra client e server o tra server. Questo rende più difficile l’intercettazione delle informazioni su IP, porte e codec, anche se la vera protezione della voce richiede comunque SRTP per cifrare il flusso media.

Esempio completo: chiamata SIP con SDP offer/answer

Un tipico flusso semplificato, come illustrato in guide operative sul SIP, è:

INVITE con SDP (offer) dall’endpoint A all’endpoint B;
risposte provvisorie (100 Trying, 180 Ringing);
200 OK con SDP (answer) dall’endpoint B;
ACK da A a B;
scambio di pacchetti RTP/RTCP sui parametri negoziati.

Analizzando l’INVITE e il 200 OK con strumenti come Wireshark si può vedere esattamente quali codec sono stati offerti/accettati, quali IP e porte sono stati scelti e se SRTP è stato negoziato correttamente.

Checklist pratica: leggere l’SDP quando qualcosa non funziona

Quando si fa troubleshooting su sip sdp rtp, una checklist utile è:

IP e porte: gli indirizzi in c= e le porte in m= hanno senso da entrambe le parti?
Codec: c’è almeno un codec audio comune (G.711, G.729, Opus, ecc.) tra offer e answer?
Direzione: gli attributi a=sendrecv/sendonly/recvonly sono coerenti con l’effetto desiderato?
NAT: c’è un dispositivo (SBC, firewall, NAT) che riscrive correttamente l’SDP?
Sicurezza: se si usa SRTP, gli attributi a=crypto o DTLS‑SRTP sono presenti e corretti?

Una buona comprensione del Session Description Protocol è quindi essenziale non solo per chi sviluppa soluzioni VoIP o WebRTC, ma anche per chi gestisce centralini IP, trunk SIP e infrastrutture di telefonia IP aziendale. Approfondire termini e protocolli legati a SIP, SDP e RTP ti aiuterà a sfruttare meglio tutte le potenzialità del VoIP aziendale.

epiclink