RFC 3261: Il DNA del VoIP – Capitolo 2
Come opera il protocollo SIP

Nel capitolo precedente abbiamo chiarito che cosa sia il SIP e, soprattutto, che cosa non sia. Abbiamo visto che non trasporta direttamente la voce, che non coincide con il piano media e che non va letto come una semplice imitazione della telefonia tradizionale su rete IP. Abbiamo anche fissato un punto decisivo: il SIP è un protocollo di signaling che governa la nascita, la modifica e la chiusura di una sessione.

A questo punto dobbiamo fare un passo in avanti. Non basta sapere che il SIP è un protocollo di segnalazione. Dobbiamo vedere come si comporta quando entra davvero in funzione. È qui che la teoria RFC smette di essere astratta e comincia a mostrarsi come una sequenza di eventi leggibili. Per chi lavora con Wireshark, con un tracciato PCAP SIP e con problemi reali di interoperabilità, questo è il passaggio in cui lo studio del protocollo inizia a diventare veramente utile.

In questo capitolo analizzeremo quindi il modello operativo del SIP partendo soprattutto dalla Sezione 2, dalla Sezione 4 e, come base formale del messaggio, dalla Sezione 7 della RFC 3261. Il punto non è memorizzare una lista di metodi o di codici. Il punto è capire la meccanica con cui una sessione viene proposta, presa in carico, fatta progredire, accettata, confermata e poi chiusa.

C’è anche una scelta didattica molto interessante, nella RFC, che vale la pena esplicitare subito. Il documento introduce presto un esempio di flusso SIP, nella sezione panoramica sul funzionamento, anche se non ha ancora spiegato in modo completo tutta la grammatica del protocollo. È una scelta voluta: prima si abitua il lettore a vedere i messaggi in movimento, poi si entra nella loro anatomia formale.

Questo approccio è molto sensato anche per chi studia oggi il SIP. In questa fase non è importante capire tutto subito nei minimi dettagli. Non serve ancora scomporre ogni header, ogni parametro o ogni regola sintattica. Serve piuttosto iniziare a familiarizzare con i messaggi SIP, con la loro forma generale e con il modo in cui raccontano l’evoluzione della sessione. La grammatica completa arriverà dopo. Intanto conviene prendere confidenza con il linguaggio del protocollo.

Il SIP descrive un processo, non una linea telefonica

Come riportato nella RFC 3261, il SIP può stabilire sessioni, modificarle e terminarle. È una frase molto semplice, ma contiene già tutto il nucleo del comportamento operativo del protocollo.

“SIP can establish sessions, modify them, and terminate them.”
“SIP può creare sessioni, modificarle e terminarle.”

Questo punto è decisivo. Nel SIP non esiste una chiamata vista come blocco unico, rigido, quasi materiale. Esiste invece una sessione che attraversa fasi diverse. Nasce con una proposta, può essere aggiornata durante la comunicazione e viene chiusa con un atto esplicito. Il protocollo, da questo punto di vista, è molto più rigoroso di quanto sembri.

Nel lavoro quotidiano questa distinzione fa la differenza. Quando si apre un tracciato PCAP e si scorrono i messaggi, il rischio è leggere tutto come una sequenza piatta di pacchetti. In realtà il SIP racconta un processo. Ogni messaggio ha una funzione precisa, ogni risposta descrive uno stato, ogni passaggio colloca la sessione in un momento diverso della sua vita operativa.

È anche il motivo per cui i problemi reali diventano molto più leggibili quando il tecnico smette di dire genericamente “la chiamata non parte” e comincia invece a chiedersi dove, nel processo, la logica si sia interrotta. La richiesta è stata generata? È stata presa in carico? Il destinatario è stato raggiunto? La sessione è stata accettata? L’ACK è arrivato? La chiusura è stata ordinata? Sono queste le domande che cambiano davvero la qualità del troubleshooting.

Il principio che regge tutto: richieste e risposte

La RFC 3261, nella sezione introduttiva del comportamento operativo, chiarisce che il SIP è un protocollo basato su richieste e risposte. È qui che si vede la sua parentela concettuale con i modelli transazionali testuali, ma anche la sua specificità operativa nel mondo delle comunicazioni in tempo reale.

“SIP is a request-response protocol.”
“SIP è un protocollo basato su richieste e risposte.”

Questo significa che il modello non si affida a stati impliciti o a magie nascoste dentro la rete. Un soggetto genera una richiesta. La rete la prende in carico, la inoltra se necessario e la consegna al nodo corretto. Da quel momento arrivano una o più risposte che descrivono che cosa sta accadendo. È una grammatica molto chiara. Proprio per questo il SIP è così potente da leggere nei tracciati.

Un errore frequente consiste nel pensare che il protocollo “faccia accadere” la comunicazione e basta. In realtà il SIP la racconta mentre la costruisce. Dice quando una richiesta è stata ricevuta, quando il terminale sta squillando, quando la sessione è stata accettata, quando il ciclo è stato confermato e quando la comunicazione viene terminata. Questa trasparenza è uno dei grandi punti di forza del protocollo.

Nel tracciato SIP questo passaggio si vede in modo molto netto. Una richiesta iniziale come INVITE produce tipicamente risposte provvisorie e finali. La differenza tra una risposta e l’altra non è cosmetica. È informazione operativa. È qui che un tecnico inizia davvero a leggere il protocollo, invece di limitarsi a guardarlo.

La struttura minima del messaggio SIP

Per leggere il modello operativo serve anche una base minima sulla struttura del messaggio. La Sezione 7 chiarisce che un messaggio SIP è composto da una start-line, da uno o più header, da una linea vuota e, quando presente, da un message-body. Questo non è ancora il capitolo dedicato agli header, ma il principio va fissato subito perché senza questa struttura il call flow resta difficile da interpretare.

Detto così può sembrare un dettaglio. In realtà non lo è. Quando osserviamo un INVITE, la prima riga ci dice quale metodo stiamo invocando e verso quale risorsa. Gli header ci danno il contesto logico della richiesta. Il body, spesso con SDP, porta la descrizione della sessione proposta. Il protocollo non si limita quindi a dire “voglio chiamare”. Dice anche chi sta chiamando, dove desidera ricevere le risposte, come correlare i messaggi e quali parametri di comunicazione intende proporre.

È proprio in questo passaggio che molti tracciati iniziano a essere letti male. Chi non distingue bene start-line, header e body tende a confondere il controllo della sessione con il contenuto negoziale o addirittura con il piano media. In Wireshark conviene abituarsi fin da subito a separare questi tre livelli logici.

Perché la RFC mostra subito un esempio di flusso

La cosa interessante, a questo punto, è che la RFC 3261 non aspetta di aver definito ogni dettaglio sintattico prima di mostrare il protocollo in azione. Al contrario, nella parte introduttiva sul funzionamento presenta subito un esempio di chiamata SIP con il classico scenario tra Alice e Bob, passando per i proxy di rete. Dal punto di vista didattico è una scelta molto intelligente.

Il messaggio implicito è chiaro: non bisogna pretendere di capire tutto immediatamente. All’inizio è più importante vedere la sequenza generale dei messaggi, riconoscere l’aspetto di un INVITE, abituarsi a incontrare risposte come 100 Trying, 180 Ringing e 200 OK, e iniziare a percepire che il SIP racconta una progressione ordinata. Il dettaglio fine della grammatica, degli header e delle regole di costruzione verrà dopo.

Questo significa che, leggendo il flusso introduttivo della RFC, non dobbiamo avere l’ansia di interpretare ogni singola riga. In questa fase è sufficiente fare una cosa molto più utile: prendere familiarità con la forma dei messaggi SIP. Guardarli, riconoscerli, iniziare a distinguere richieste e risposte, e capire che ogni messaggio occupa un posto preciso nella meccanica della sessione.

Naturalmente la RFC usa i suoi esempi classici, come Alice e Bob. Noi, nella collana e con un taglio più vicino alla nostra sensibilità, useremo spesso nomi come Matteo, Daniele o Simone. Non cambia nulla dal punto di vista del protocollo. Cambia solo la vicinanza narrativa dell’esempio, che in italiano aiuta a leggere con più naturalezza il flusso senza alterarne la logica tecnica.

Come nasce una sessione: l’INVITE

La sessione SIP nasce con una richiesta. Nel caso più rappresentativo, questa richiesta è l’INVITE. Non stiamo parlando ancora di dialog, transaction o comportamento dettagliato degli User Agent, che affronteremo più avanti. Qui ci interessa il fatto essenziale: l’INVITE è l’atto con cui una sessione viene proposta.

Immaginiamo un caso molto semplice. Daniele vuole parlare con Matteo. Daniele invia una richiesta verso l’identità SIP di Matteo, ad esempio sip:matteo@user.voipvoice.it. In quel momento non esiste ancora audio, non esiste ancora una sessione accettata e non esiste ancora un media stream attivo. Esiste una proposta di sessione.

INVITE sip:matteo@user.voipvoice.it SIP/2.0
Via: SIP/2.0/UDP pbx.user.voipvoice.it;branch=z9hG4bK-12345
From: <sip:daniele@user.voipvoice.it>;tag=abc123
To: <sip:matteo@user.voipvoice.it>
Call-ID: 123456@pbx.user.voipvoice.it
CSeq: 1 INVITE
Contact: <sip:daniele@user.voipvoice.it>
Content-Type: application/sdp

Questo esempio non serve ancora a fare anatomia completa degli header. Serve a vedere il comportamento. Il metodo dichiara l’azione. La Request-URI indica la destinazione logica. Gli header iniziano a costruire il contesto di correlazione. Il body SDP, che qui non mostriamo per intero, contiene l’offerta di sessione. Nel tracciato SIP questo è il primo punto da fissare bene: l’INVITE non è la chiamata già avvenuta, ma la proposta formale con cui il protocollo cerca di farla nascere.

Che cosa raccontano le risposte provvisorie

Una delle caratteristiche più eleganti del SIP è che il protocollo non aspetta la fine per dire come stanno andando le cose. Tra la richiesta iniziale e la risposta finale possono comparire una o più risposte provvisorie. Sono messaggi che non chiudono ancora la transaction, ma raccontano il progresso dell’elaborazione.

I due casi più noti, soprattutto in fase introduttiva, sono 100 Trying e 180 Ringing. Nella pratica sembrano vicini, ma descrivono due momenti molto diversi.

SIP/2.0 100 Trying
SIP/2.0 180 Ringing

Il 100 Trying significa che la richiesta è stata ricevuta e che il nodo che la sta trattando ha iniziato a elaborarla. Non ci dice ancora che il destinatario finale stia squillando. Ci dice che la rete, o comunque l’elemento che ha preso in carico il messaggio, sta lavorando sulla richiesta.

Il 180 Ringing, invece, ci porta più avanti nel processo. Qui il terminale del destinatario è stato raggiunto e sta effettivamente allertando l’utente. Nel tracciato SIP questa differenza è importantissima, perché separa la presa in carico della richiesta dalla sua consegna operativa al destinatario.

Un errore frequente consiste proprio nel confondere questi due passaggi. Sul campo capita spesso di sentire dire che “la chiamata arriva” solo perché compare un 100 Trying. In realtà quel messaggio non prova ancora che il terminale remoto stia squillando. Prova soltanto che qualcuno ha iniziato a trattare la richiesta. La differenza è enorme, soprattutto quando si devono diagnosticare problemi di instradamento, localizzazione o policy di rete.

La risposta finale di successo: 200 OK

Il punto di svolta del modello operativo arriva con la risposta finale di successo. Nel caso dell’INVITE, il messaggio più emblematico è il 200 OK. Qui la rete, o più precisamente il destinatario che ha accettato la richiesta, certifica che la proposta di sessione è stata accettata.

SIP/2.0 200 OK

Questo è il punto da fissare bene. La sessione non nasce davvero quando l’INVITE parte. In quel momento viene proposta. La sessione prende forma quando quella proposta riceve un’accettazione esplicita. Il 200 OK non è quindi una formalità. È il momento in cui il sistema dice che la richiesta è stata compresa, accettata e resa operativa.

Nei casi reali il 200 OK contiene spesso anche il body SDP di risposta. Questo significa che il protocollo, oltre ad accettare la sessione, sta anche completando la negoziazione dei parametri con cui il media potrà fluire. È qui che si vede bene, ancora una volta, la separazione tra signaling e media. Il SIP non trasporta la voce, ma negozia le condizioni che permetteranno alla voce di esistere in modo coerente.

Nel tracciato SIP il sintomo tipico di una sessione formalmente accettata è proprio la comparsa di questo messaggio. Ma attenzione: una sessione accettata sul piano del signaling non garantisce ancora che il media sarà corretto. È qui che il tecnico deve rimanere disciplinato e non fermarsi alla prima evidenza apparentemente rassicurante.

Perché l’ACK è indispensabile

Dopo il 200 OK arriva l’ACK. Questo messaggio è uno dei passaggi più istruttivi di tutto il modello operativo SIP, perché mostra in modo limpido come il protocollo lavori per conferme ordinate e non per impliciti.

ACK sip:matteo@user.voipvoice.it SIP/2.0

L’ACK non è una risposta. È una nuova richiesta. Ed è proprio questo che rende il SIP così rigoroso da leggere. Una richiesta apre la trattativa. Una risposta finale la accetta. Una nuova richiesta ne conferma la corretta ricezione. Questa triade INVITE, 200 OK, ACK completa il setup della sessione dal punto di vista del signaling.

Nel lavoro quotidiano questa distinzione ha un peso enorme. I problemi che bloccano l’ACK sono spesso subdoli, perché a colpo d’occhio sembra che tutto sia andato bene. L’INVITE è arrivato. Il 200 OK è tornato indietro. Ma se l’ACK non raggiunge il destinatario, il ciclo di instaurazione non si chiude in modo coerente. Sul campo questo problema compare spesso in presenza di errori di routing, NAT gestito male, indirizzi di contatto errati o incoerenze tra ciò che il nodo dichiara e ciò che è realmente raggiungibile.

In Wireshark conviene controllare sempre se, dopo un 200 OK a un INVITE, compare l’ACK coerente. Quando manca, il sintomo tipico è una sessione che sembra accettata ma si interrompe subito, oppure un comportamento instabile che viene attribuito genericamente al provider o al PBX quando invece nasce da un problema di percorso o di correlazione del messaggio finale.

Dove finisce il SIP e dove inizia la trasmissione audio RTP

Arrivati a questo punto il modello operativo ci aiuta a fissare definitivamente un principio che, nel VoIP, torna continuamente: il SIP governa il controllo della sessione, ma non coincide con il media. Quando il ciclo INVITE, 200 OK, ACK si è chiuso correttamente, il protocollo ha fatto il suo mestiere sul piano di signaling. Ha costruito e negoziato il contesto della comunicazione.

La voce, però, non passa nel SIP. Passa tipicamente su RTP. Questo significa che una chiamata può essere perfetta dal punto di vista della segnalazione e problematica dal punto di vista audio. Possiamo osservare un flusso SIP formalmente corretto e avere comunque audio assente, audio monodirezionale o qualità scadente.

È proprio in questo passaggio che molti tracciati iniziano a essere letti male. Il tecnico vede il setup completato e conclude troppo in fretta che il problema non esista. In realtà la sessione può essere nata correttamente dal punto di vista del protocollo e fallire subito dopo sul percorso media, a causa di NAT, porte RTP, SDP incoerente, firewall o instradamenti non simmetrici. Il SIP, da questo punto di vista, è innocente rispetto a molti guasti che però continuano a essergli attribuiti.

Nel lavoro quotidiano conviene quindi usare una regola semplice: prima verificare che il signaling sia coerente, poi verificare che il media lo sia davvero. Invertire questo ordine porta spesso a diagnosi confuse.

La chiusura ordinata della sessione

Se il SIP può creare, modificare e terminare una sessione, allora anche la chiusura deve seguire la stessa logica ordinata che abbiamo visto fin qui. Ed è proprio così che avviene. La comunicazione si chiude con una nuova richiesta, il BYE, a cui segue una risposta di conferma.

BYE sip:daniele@user.voipvoice.it SIP/2.0
SIP/2.0 200 OK

Qui si vede molto bene la coerenza del modello. Anche la chiusura non è implicita, non è lasciata all’interpretazione e non è un semplice effetto collaterale del fatto che i due lati non si parlino più. Qualcuno decide di terminare la sessione. Lo dichiara con una richiesta. L’altro lato conferma di averla ricevuta. Il protocollo continua quindi a essere leggibile fino all’ultimo passaggio.

Dal punto di vista diagnostico, anche questo è molto utile. Una chiusura pulita lascia nel tracciato una sequenza chiara. Una chiusura anomala lascia invece sintomi diversi: time-out, ritrasmissioni, messaggi mancanti o interruzioni improvvise del media senza corrispettivo sul piano SIP. Ed è proprio per questo che il SIP continua a essere uno dei protocolli più interessanti da studiare per chi vuole capire che cosa sta accadendo davvero in una comunicazione VoIP.

Che cosa guardare nei tracciati SIP con Wireshark

Dopo aver visto il modello operativo, possiamo già fissare alcune verifiche pratiche che conviene fare in ogni tracciato PCAP di base. Non sono ancora analisi avanzate di dialog, transaction o proxy routing, ma costituiscono una griglia molto utile per non perdersi nei primi flussi reali.

• verificare che la richiesta iniziale sia stata generata correttamente e inviata verso la destinazione attesa;
• controllare se compare un 100 Trying, distinguendolo dal vero allarme del terminale remoto;
• controllare se la progressione arriva a 180 Ringing o ad altra risposta coerente con il contesto;
• verificare la presenza del 200 OK finale;
• controllare se l’ACK completa davvero il ciclo di setup;
• se il signaling è corretto ma l’audio manca, spostare l’analisi sul piano media e su RTP;
• in fase di chiusura, verificare se il BYE e il relativo 200 OK descrivono una terminazione ordinata.

Questo schema semplice aiuta molto a non mescolare problemi diversi. È anche una buona disciplina mentale per evitare l’errore classico di attribuire a un singolo messaggio tutto il destino della comunicazione. In SIP conta la sequenza, non il pacchetto isolato.

Il vero valore del modello operativo

Arrivati qui, la lezione più importante del capitolo dovrebbe essere chiara. Il SIP non va imparato come una lista di metodi e codici. Va letto come una meccanica. Una richiesta parte, entra nella rete, produce risposte provvisorie, arriva a una risposta finale, viene confermata, abilita il piano media e poi chiude la sessione con una nuova richiesta ordinata.

Quando si interiorizza questa dinamica cambiano due cose fondamentali. La prima è la lettura dei tracciati: non si vedono più pacchetti, ma stati del processo. La seconda è il troubleshooting: non si cerca più genericamente dove “non va la chiamata”, ma si individua il punto preciso in cui la logica del protocollo si è interrotta.

È qui che il SIP comincia davvero a diventare leggibile. Ed è qui che la RFC 3261 smette di sembrare un testo da consultare solo nei casi disperati e si trasforma in una guida concreta per capire che cosa sta facendo la rete.

Conclusione

In questo capitolo abbiamo visto il SIP in azione. Non come definizione, ma come comportamento. Abbiamo seguito la logica con cui una sessione viene proposta, presa in carico, fatta progredire, accettata, confermata e infine chiusa. Abbiamo anche visto perché il modello request/response sia il cuore del protocollo e perché la distinzione tra segnalazione e media debba restare sempre nitida.

A questo punto possiamo proseguire in modo ordinato. Nel prossimo capitolo entreremo nella Sezione 6 e costruiremo il vocabolario operativo del protocollo. Perché dopo aver visto come il SIP si muove, dobbiamo capire chi compie le azioni che abbiamo osservato. E quando i ruoli non sono chiari, anche il tracciato più semplice diventa difficile da interpretare.