Nel precedente articolo abbiamo costruito una mappa completa delle RFC del protocollo SIP, concentrandoci sulla segnalazione: metodi, header, dialoghi, routing e logiche operative. È però importante fermarsi un attimo e fare un passo in più. Perché chi lavora davvero con il VoIP sa che il SIP, da solo, non basta a spiegare cosa succede durante una chiamata.
Il SIP decide come instaurare, modificare e terminare una sessione. Ma la voce, i toni DTMF, la qualità audio, i problemi legati al NAT e alla rete non passano dal SIP: viaggiano su protocolli diversi, regolati da altre RFC. È proprio in questa separazione tra piano di segnalazione e piano media che si trovano molti dei problemi reali che incontriamo ogni giorno su PBX, SBC, gateway e terminali.
In questo articolo andremo quindi a completare il quadro, analizzando le principali RFC che, pur non essendo SIP in senso stretto, sono fondamentali per capire il funzionamento reale del VoIP. L’obiettivo è collegare i concetti già visti con il comportamento effettivo del Voice over IP
DTMF: quando la segnalazione incontra il piano media
Uno dei casi più classici è la gestione dei toni DTMF. Chi ha fatto troubleshooting su IVR, gateway o centralini sa quanto questo tema sia critico. Dal punto di vista SIP, i DTMF vengono semplicemente negoziati tramite SDP. Ma il loro trasporto reale avviene a livello RTP.
La prima RFC che ha standardizzato questo comportamento è la RFC 2833, poi aggiornata dalla RFC 4733, oggi riferimento principale. In questo modello, i toni non vengono inviati come audio, ma come eventi codificati all’interno del flusso RTP, tipicamente con il payload “telephone-event”.
Accanto a questo approccio esistono altre due modalità: l’invio in banda audio (inband) e l’uso del metodo SIP INFO. Ed è proprio qui che nascono molti problemi di interoperabilità. Apparati diversi possono supportare modalità diverse o configurazioni non allineate, generando malfunzionamenti difficili da diagnosticare se non si ha chiara la distinzione tra segnalazione e media.
RTP e RTCP: dove viaggia davvero la voce
Se il SIP costruisce la chiamata, è l’RTP a trasportare la voce. Il riferimento principale è la RFC 3550, che definisce il Real-time Transport Protocol, affiancata dalla RFC 3551 che specifica i profili per audio e video.
RTP introduce concetti fondamentali come timestamp, sequence number e sincronizzazione dei flussi. Accanto a RTP troviamo RTCP, utilizzato per fornire statistiche sulla qualità della trasmissione: jitter, perdita di pacchetti, latenza. Questi parametri sono spesso invisibili a livello SIP, ma sono determinanti per la qualità percepita dall’utente.
Capire RTP significa anche comprendere perché una chiamata può risultare silenziosa, monodirezionale o disturbata pur avendo una segnalazione SIP perfettamente corretta.
SDP e negoziazione dei codec
Il ponte tra SIP e RTP è rappresentato dal protocollo SDP, definito nella RFC 4566. È all’interno dell’SDP che vengono negoziati codec, porte, indirizzi IP e parametri del flusso media.
Il modello di negoziazione è descritto nella RFC 3264, basato sul meccanismo offer/answer. È qui che si decide, ad esempio, se una chiamata utilizzerà G.711, G.729 o altri codec, e con quali parametri.
Molti problemi reali derivano proprio da questa fase: codec non compatibili, payload type dinamici interpretati in modo diverso, porte RTP non raggiungibili. Anche in questo caso, il SIP fa solo da contenitore: il comportamento reale è determinato da ciò che viene negoziato nell’SDP.
NAT traversal: il vero problema del VoIP moderno
Uno dei temi più critici nel VoIP è la gestione del NAT. Il SIP, per sua natura, include indirizzi IP e porte nei messaggi. Quando questi attraversano dispositivi NAT, le informazioni possono diventare incoerenti, causando problemi di audio o di raggiungibilità.
Per affrontare questo problema sono state definite diverse tecnologie. La RFC 5389 descrive STUN, utilizzato per scoprire l’indirizzo pubblico e il tipo di NAT. La RFC 5766 introduce TURN, che consente di fare relay del traffico media quando la comunicazione diretta non è possibile.
Il modello più completo è definito dalla RFC 8445, che descrive ICE. ICE combina STUN e TURN per testare diversi percorsi e selezionare automaticamente quello funzionante.
Accanto a queste tecnologie troviamo meccanismi di keep-alive, spesso implementati tramite messaggi SIP o CRLF, fondamentali per mantenere aperte le associazioni NAT. Anche qui, la distinzione tra segnalazione e media è centrale: il problema nasce nella rete, ma si manifesta come sintomo SIP.
QoS e qualità della voce
La qualità di una chiamata VoIP non dipende solo dai protocolli, ma anche dal comportamento della rete. Le RFC 2474 e 4594 introducono il modello DiffServ, che consente di classificare e prioritizzare il traffico.
Nel caso della voce, viene spesso utilizzata la classe EF (Expedited Forwarding), che garantisce bassa latenza e jitter ridotto. Senza una corretta gestione della QoS, anche una configurazione SIP perfetta può risultare in una qualità audio scadente.
La sicurezza del flusso media
Un altro aspetto fondamentale è la sicurezza. Se il SIP può essere protetto tramite TLS, il traffico RTP deve essere cifrato separatamente. La RFC 3711 definisce SRTP, il protocollo per la cifratura del flusso audio.
Meccanismi come quelli descritti nella RFC 4568 e nella RFC 5764 permettono di negoziare le chiavi e proteggere la comunicazione end-to-end. Anche in questo caso, il SIP trasporta le informazioni, ma la sicurezza reale si applica al media.
Fax over IP e i limiti pratici
Un caso particolare, ma ancora molto diffuso, è quello del fax su IP. La RFC 3362 descrive le problematiche legate al trasporto fax su reti IP.
Il trasporto diretto via audio (G.711) può fallire a causa di perdita di pacchetti o jitter. Per questo motivo è stato introdotto il protocollo T.38, che converte il fax in un flusso dati più robusto. È un esempio perfetto di come il comportamento reale del VoIP dipenda da fattori che vanno ben oltre il SIP.
Mettere insieme i pezzi: il VoIP come sistema
A questo punto dovrebbe essere chiaro un aspetto fondamentale: il VoIP non è il SIP. È un sistema composto da più livelli, ciascuno regolato da protocolli e RFC differenti. Il SIP costruisce la chiamata, l’SDP negozia i parametri, l’RTP trasporta la voce, STUN e ICE risolvono i problemi di rete, SRTP protegge i dati, e la QoS determina la qualità finale.
È proprio nell’interazione tra questi elementi che si gioca la vera complessità del VoIP. Ed è per questo che, quando si analizza un problema, limitarsi alla segnalazione SIP raramente è sufficiente. Serve una visione completa, capace di collegare le RFC tra loro e di interpretare il comportamento dell’intero sistema.
Se non hai ancora approfondito il funzionamento del protocollo SIP e delle sue RFC principali, ti consiglio di partire da questo articolo, dove ho costruito una mappa completa della segnalazione VoIP:
Le RFC del protocollo SIP: guida completa ai documenti core
Fonti utili per approfondire
Per chi volesse approfondire gli argomenti trattati, ecco alcune fonti online utili: