BroadNet
SIP / VoIPMedia

RTP e SRTP: il flusso media

Aggiornato il 4 min di letturaBasato su standard
Risposta diretta

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.

§01

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.

§02

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)
CampoDimensioneScopo
V / P / X / CC1 byteVersione, riempimento, estensione, flag di conteggio CSRC
M (marker) + PT1 byteBit marker + tipo di payload (codec da SDP)
Numero di sequenza2 byteRileva perdita e riordino dei pacchetti
Timestamp4 byteIstante di campionamento; governa il playout / jitter buffer
SSRC4 byteSorgente di sincronizzazione: identifica il flusso
CSRC (0–15)0–60 byteFonti che contribuiscono (dai mixer)
§03

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
MetricaCosa ti dice
Perdita di pacchetti (frazione + cumulativa)Quanto audio viene perso
Jitter interarrivoVariazione nella temporizzazione dei pacchetti: difficoltà di riproduzione
Tempo di andata e ritornoLatenza del percorso (dai timestamp SR/RR)
Sequenza più alta ricevutaRilevamento di avanzamento e perdite per sorgente
§04

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.

§05

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
MetodoRFCDove si trova la chiaveNota
SDESRFC 4568a=linea crypto nell'SDPRichiede SIP su TLS per essere sicuro
DTLS-SRTPRFC 5763/5764Derivata da un handshake DTLS nel percorso dei mediaChiave mai nella segnalazione; utilizzata da WebRTC
MIKEYRFC 3830Carico utile per la gestione delle chiaviUtilizzato in alcune implementazioni IMS
FAQ

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.

Riferimenti

Specifiche della fonte

Gli standard pubblicati su cui si basa questa pagina. Si apre in una nuova scheda.

BNGestito dal team di ingegneri BroadNet·Servizi di messaggistica di livello carrier dal 2003
Mettilo sul filo

Realizzato con un vero binding SMPP e un'API REST.

Richiedi l'accesso di prova con chiavi di test reali: invia prima al tuo numero verificato, poi passa alla produzione in oltre 200 paesi una volta approvata l'identità del mittente e i percorsi.