# RTP e SRTP: il flusso media

> RTP (Real-time Transport Protocol, RFC 3550) trasporta la voce o il video effettivo dopo che SIP negozia la sessione, operando su UDP con un header compatto (numero di sequenza, timestamp, SSRC). RTCP ne riporta la qualità in parallelo. SRTP (RFC 3711) aggiunge cifratura e autenticazione a RTP, con keying tramite SDES nell'SDP o DTLS-SRTP.

- URL canonico: https://www.broadnet.me/it/reference/rtp-and-srtp-media
- Lingua: it
- Ultimo aggiornamento: 2026-07-18
- Editore: BroadNet (https://www.broadnet.me)

Come fluiscono i media una volta che SIP ha instaurato una chiamata: l'header e il payload RTP, i report di qualità RTCP e la cifratura e autenticazione SRTP con keying tramite SDES o DTLS-SRTP.

## RTP: il trasporto dei media

Una volta che SIP e SDP hanno concordato la sessione, i media stessi fluiscono su RTP — quasi sempre su UDP, perché l'audio in tempo reale preferisce la consegna tempestiva a quella garantita. Ogni pacchetto RTP trasporta un blocco di audio codificato (una trama di codec come 20 ms di G.711) dietro un header di 12 byte. RTP è un flusso separato dalla segnalazione SIP, sulle porte negoziate dall'SDP, e di norma fluisce direttamente tra gli endpoint o attraverso un media relay anziché seguire il percorso di segnalazione.

## L'header RTP

L'header RTP di 12 byte fornisce al ricevente tutto ciò che serve per ricostruire un flusso in tempo reale. Il numero di sequenza rileva perdite e riordinamenti. Il timestamp riflette l'istante di campionamento affinché il ricevente riproduca l'audio alla cadenza corretta e rimuova il jitter con un jitter buffer. L'SSRC identifica univocamente la sorgente media all'interno della sessione. Il payload type richiama il codec concordato nell'SDP. Il marker bit segnala eventi come il primo pacchetto dopo un periodo di silenzio.

*Campi dell'header RTP (12 byte)*

| Campo | Dimensione | Scopo |
|---|---|---|
| V / P / X / CC | 1 byte | Versione, riempimento, estensione, flag di conteggio CSRC |
| M (marker) + PT | 1 byte | Bit marker + tipo di payload (codec da SDP) |
| Numero di sequenza | 2 byte | Rileva perdita e riordino dei pacchetti |
| Timestamp | 4 byte | Istante di campionamento; governa il playout / jitter buffer |
| SSRC | 4 byte | Sorgente di sincronizzazione: identifica il flusso |
| CSRC (0–15) | 0–60 byte | Fonti che contribuiscono (dai mixer) |

## RTCP: feedback di qualità

RTP viaggia con un protocollo di controllo companion, RTCP, sulla porta adiacente (dispari). RTCP non trasporta media; invece ciascun lato invia periodicamente Sender Report e Receiver Report che descrivono lo stato del flusso — pacchetti inviati e persi, perdita cumulativa, jitter di interarrivo e round-trip time derivato dai timestamp dei report. Queste metriche sono la materia prima per le stime di MOS e per diagnosticare audio unidirezionale, jitter e perdita su una chiamata VoIP. RTCP trasporta anche la source description (CNAME) e BYE per l'abbattimento del flusso.

*Metriche chiave riportate da RTCP*

| Metrica | Cosa ti dice |
|---|---|
| Perdita di pacchetti (frazione + cumulativa) | Quanto audio viene perso |
| Jitter interarrivo | Variazione nella temporizzazione dei pacchetti: difficoltà di riproduzione |
| Tempo di andata e ritorno | Latenza del percorso (dai timestamp SR/RR) |
| Sequenza più alta ricevuta | Rilevamento di avanzamento e perdite per sorgente |

## SRTP: cifrare i media

RTP semplice non è cifrato, quindi chiunque sia sul percorso può catturare e riprodurre l'audio. SRTP (RFC 3711) lo protegge: cifra il payload RTP (di default AES in counter mode) e appone un tag di autenticazione (di default HMAC-SHA1) che protegge l'integrità e fornisce protezione dai replay, lasciando leggibile l'header RTP affinché router e jitter buffer continuino a funzionare. Il trasporto compare nell'SDP come RTP/SAVP anziché RTP/AVP. SRTP protegge riservatezza e integrità ma dipende interamente da come vengono scambiate le sue chiavi.

## Keying di SRTP: SDES vs DTLS-SRTP

SRTP necessita di una master key a ciascuna estremità, e i due modi comuni per consegnarla differiscono nettamente in sicurezza. SDES (RFC 4568) inserisce la chiave in una riga a=crypto nell'SDP — semplice, ma sicura solo quanto la segnalazione SIP, quindi deve essere trasportata su TLS o la chiave è esposta. DTLS-SRTP (RFC 5763/5764) esegue invece un handshake DTLS nel percorso media per derivare le chiavi, così la chiave non compare mai nella segnalazione; è il modello che WebRTC impone. Scegliete DTLS-SRTP dove gli endpoint lo supportano e proteggete sempre SDES con SIP su TLS.

*Metodi di keying SRTP*

| Metodo | RFC | Dove si trova la chiave | Nota |
|---|---|---|---|
| SDES | RFC 4568 | a=linea crypto nell'SDP | Richiede SIP su TLS per essere sicuro |
| DTLS-SRTP | RFC 5763/5764 | Derivata da un handshake DTLS nel percorso dei media | Chiave mai nella segnalazione; utilizzata da WebRTC |
| MIKEY | RFC 3830 | Carico utile per la gestione delle chiavi | Utilizzato in alcune implementazioni IMS |

## Domande frequenti

### Qual è la differenza tra SIP e RTP?

SIP è la segnalazione che instaura, modifica e termina una chiamata; RTP è il trasporto media che trasporta la voce o il video effettivo una volta instaurata la chiamata. Operano come flussi separati su porte separate — SIP negozia la sessione, RTP la consegna.

### Perché RTP opera su UDP invece che su TCP?

L'audio in tempo reale privilegia la tempestività sull'affidabilità. La ritrasmissione e il head-of-line blocking di TCP aggiungerebbero latenza e jitter che danneggiano una chiamata dal vivo più di un pacchetto perso occasionale. RTP su UDP consente al ricevente di occultare piccole perdite mantenendo il flusso in tempo.

### Cosa fa RTCP?

RTCP è il canale di controllo companion di RTP. Non trasporta media; riporta periodicamente la qualità del flusso — perdita di pacchetti, jitter e round-trip time tramite Sender e Receiver Report — che serve a stimare la qualità della chiamata (MOS) e a diagnosticare problemi come l'audio unidirezionale.

### Che cos'è SRTP?

SRTP (RFC 3711) è il profilo sicuro di RTP. Cifra il payload media (di norma AES counter mode) e autentica ogni pacchetto (di norma HMAC-SHA1) con protezione dai replay, mantenendo in chiaro l'header RTP. Nell'SDP compare come trasporto RTP/SAVP.

### Qual è la differenza tra SDES e DTLS-SRTP?

Entrambi effettuano il keying di SRTP. SDES trasporta la chiave in una riga SDP a=crypto, quindi è sicuro solo se la segnalazione SIP stessa è protetta con TLS. DTLS-SRTP deriva le chiavi tramite un handshake DTLS nel percorso media, così la chiave non tocca mai la segnalazione — l'approccio richiesto da WebRTC.

## Fonti

- [IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications](https://datatracker.ietf.org/doc/html/rfc3550)
- [IETF RFC 3711 — The Secure Real-time Transport Protocol (SRTP)](https://datatracker.ietf.org/doc/html/rfc3711)

## Correlati

- [SDP: Session Description Protocol](https://www.broadnet.me/it/reference/sdp-session-description-protocol)
- [Flusso di chiamata SIP](https://www.broadnet.me/it/reference/sip-call-flow)
- [SIP trunking e il session border controller](https://www.broadnet.me/it/reference/sip-trunking-and-sbc)
- [Panoramica del protocollo SIP](https://www.broadnet.me/it/reference/sip-protocol-overview)
- [Voce programmabile (prodotto)](https://www.broadnet.me/it/products/voice)