# SDP: il Session Description Protocol

> SDP (Session Description Protocol, RFC 4566) è il formato di testo che SIP trasporta per descrivere una sessione multimediale — l'indirizzo IP, le porte, i tipi di media e i codec che ciascun lato offre. Non è un trasporto; è una descrizione. SIP lo usa in uno scambio offer/answer (RFC 3264) per negoziare i media che gli endpoint scambieranno su RTP.

- URL canonico: https://www.broadnet.me/it/reference/sdp-session-description-protocol
- Lingua: it
- Ultimo aggiornamento: 2026-07-18
- Editore: BroadNet (https://www.broadnet.me)

Come SDP descrive una sessione multimediale all'interno di SIP: la struttura delle righe v=/o=/s=/c=/t=/m=/a=, il modello offer/answer (RFC 3264), la negoziazione dei codec tramite rtpmap e gli attributi di direzione dei media.

## Che cos'è SDP

SDP è un piccolo formato di testo basato su righe che descrive una sessione multimediale: quali media (audio, video), dove inviarli (indirizzo di connessione e porta), quali codec sono accettabili e in quale direzione possono fluire. SIP non interpreta i media stessi; trasporta l'SDP nel body del messaggio (Content-Type: application/sdp) e lascia che gli endpoint concordino i parametri. SDP è puramente descrittivo — non veicola alcun media e non negozia nulla da solo; la negoziazione deriva da come SIP scambia due body SDP.

## La struttura delle righe

Un body SDP è una sequenza di righe di tipo a lettera singola in ordine fisso, suddivisa in una sezione a livello di sessione seguita da una o più sezioni a livello di media che iniziano ciascuna con una riga m=. Le più importanti sono o= (origine e session id), c= (indirizzo di connessione), m= (tipo di media, porta, trasporto e formati) e le righe di attributo a= che trasportano le mappe dei codec e la direzione. Le righe sono ordinate e case-sensitive.

*Tipi di riga SDP*

| Linea | Nome | Trasporta |
|---|---|---|
| v= | Versione | Versione SDP (0) |
| o= | Origine | Nome utente, ID/versione sessione, rete/indirizzo |
| s= | Nome della sessione | Un'etichetta per la sessione |
| c= | Connessione | Tipo di rete, tipo di indirizzo e indirizzo IP dei media |
| t= | Tempistica | Ora di inizio/fine (0 0 per una chiamata illimitata) |
| m= | Media | Tipo di media, porta, trasporto (RTP/AVP…) e formati |
| a= | Attributi | rtpmap, fmtp, ptime, direction (sendrecv…) e altro |

## Il modello offer/answer

SIP negozia i media con il modello offer/answer di RFC 3264. Un endpoint invia un'offerta SDP (di norma nell'INVITE) elencando i flussi media e ogni codec che è disposto a usare. L'altro restituisce una risposta SDP (di norma nel 200 OK) selezionando tra ciò che è stato offerto — mantenendo solo i codec che supporta anch'esso, nel suo ordine preferito, e impostando la direzione. Il risultato è l'intersezione su cui entrambi i lati hanno concordato. Una mancata corrispondenza senza codec comune è ciò che produce un 488 Not Acceptable Here.

*Un'offerta SDP per un singolo flusso audio*

```text
v=0
o=alice 2890844526 2890844526 IN IP4 host.example.com
s=-
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:20
a=sendrecv
```

## Codec e payload type

La riga m= elenca i numeri di payload type RTP e ogni a=rtpmap mappa un numero su un codec e una clock rate. I payload type 0–95 includono assegnazioni statiche (0 = PCMU/G.711 µ-law, 8 = PCMA/G.711 A-law, 9 = G722, 18 = G729), mentre 96–127 sono dinamici e devono essere definiti da un rtpmap. a=fmtp trasporta parametri specifici del codec, e telephone-event (RFC 4733) è il modo in cui si negoziano i DTMF. Elencare i codec in ordine di preferenza consente al rispondente di scegliere il migliore reciprocamente supportato.

*Payload type RTP audio comuni*

| PT | Codec | Clock | Nota |
|---|---|---|---|
| 0 | PCMU (G.711 µ-law) | 8000 | Statico; ~64 kbit/s, qualità telefonica (toll quality) |
| 8 | PCMA (G.711 A-law) | 8000 | Statico; ~64 kbit/s, qualità telefonica (toll quality) |
| 9 | G722 | 8000 | Wideband (audio a 16 kHz) |
| 18 | G729 | 8000 | Statico; compresso a circa 8 kbit/s |
| 96–127 | Dinamico (Opus, telephone-event…) | varia | Definito da a=rtpmap |

## Attributi di direzione dei media

Un attributo di direzione a= imposta come fluiscono i media per un flusso. sendrecv è il normale valore predefinito bidirezionale. sendonly e recvonly limitano il flusso a una direzione — usati per hold, annunci e media unidirezionali. inactive arresta del tutto i media mantenendo attiva la sessione. Commutare questi (ad esempio sendonly ⇄ sendrecv in un re-INVITE) è il modo in cui si implementano hold, ripresa e musica di attesa senza abbattere il dialogo.

*Attributi di direzione SDP*

| Attributo | Significato |
|---|---|
| a=sendrecv | Invio e ricezione di contenuti multimediali (impostazione predefinita) |
| a=sendonly | Solo invio (ad es. annuncio, o la parte messa in attesa) |
| a=recvonly | Solo ricezione (ad es. la parte messa in attesa) |
| a=inactive | Nessun media in nessuna delle due direzioni; la sessione resta attiva |

## Domande frequenti

### A cosa serve SDP in SIP?

SDP descrive la sessione multimediale — l'indirizzo IP, le porte, i tipi di media e i codec che ciascun endpoint offre. SIP trasporta due body SDP in uno scambio offer/answer per negoziare quale audio o video gli endpoint scambieranno su RTP. SDP di per sé non veicola alcun media.

### Che cos'è il modello offer/answer di SIP?

Definito in RFC 3264, è il modo in cui SIP negozia i media: un lato invia un'offerta SDP (spesso nell'INVITE) elencando i suoi media e codec, e l'altro restituisce una risposta SDP (spesso nel 200 OK) selezionando il sottoinsieme che supporta anch'esso. Ciò che fluisce è l'intersezione concordata.

### Cosa significa la riga m= in SDP?

La riga m= (media) dichiara un flusso media: il suo tipo (audio/video), la porta a cui inviare, il trasporto (ad esempio RTP/AVP o RTP/SAVP per SRTP) e la lista dei numeri di payload type RTP offerti. Ogni payload type è poi descritto da una riga a=rtpmap.

### Come si scelgono i codec in una chiamata SIP?

L'offerente elenca i codec accettabili in ordine di preferenza nell'SDP. Il rispondente mantiene solo quelli che supporta anch'esso e li restituisce, selezionando di fatto il miglior codec reciprocamente supportato. Se gli insiemi non si intersecano, la negoziazione fallisce, di norma con un 488 Not Acceptable Here.

### Come si mette in hold una chiamata con SDP?

Cambiando l'attributo di direzione dei media in un re-INVITE — ad esempio impostando a=sendonly (o storicamente un indirizzo di connessione a zero) per mettere in hold il lato remoto, e a=sendrecv per riprendere. Il dialogo resta attivo; cambia solo la direzione dei media.

## Fonti

- [IETF RFC 4566 — SDP: Session Description Protocol](https://datatracker.ietf.org/doc/html/rfc4566)
- [IETF RFC 3264 — An Offer/Answer Model with SDP](https://datatracker.ietf.org/doc/html/rfc3264)

## Correlati

- [RTP e SRTP: il flusso media](https://www.broadnet.me/it/reference/rtp-and-srtp-media)
- [Flusso di chiamata SIP](https://www.broadnet.me/it/reference/sip-call-flow)
- [Metodi e richieste SIP](https://www.broadnet.me/it/reference/sip-methods-and-requests)
- [Header SIP](https://www.broadnet.me/it/reference/sip-headers)
- [Voce programmabile (prodotto)](https://www.broadnet.me/it/products/voice)