RFC 3261: Il DNA del VoIP – Capitolo 7
INVITE e nascita della sessione SIP

Dopo i capitoli dedicati al comportamento degli User Agent, alla costruzione delle richieste SIP e a REGISTER, in questo capitolo ci concentriamo su INVITE, cioè sul messaggio con cui una sessione SIP viene proposta e avviata. L’obiettivo è capire come nasce davvero una chiamata dal punto di vista della segnalazione, che cosa succede prima della risposta finale e quali controlli conviene fare nel tracciato pcap.

Che cosa dice la RFC

Per questo capitolo i riferimenti principali sono la sezione 13.1 e la sezione 13.2 della RFC 3261, dedicate all’avvio della sessione e al lato UAC dell’INVITE.

“When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session.”
Quando un user agent client vuole avviare una sessione, per esempio audio, video o altro, formula una richiesta INVITE. La richiesta INVITE chiede a un server di stabilire una sessione.

La RFC è molto chiara. L’INVITE è il metodo con cui un User Agent Client prova ad avviare una sessione. La richiesta può attraversare uno o più proxy, arrivare a uno o più UAS e ricevere risposte provvisorie o finali. Se arriva una risposta 2xx, la sessione viene accettata. Se arriva una risposta finale non 2xx, la sessione non nasce. È importante notare che un UA che supporta INVITE deve supportare anche ACK, CANCEL e BYE, perché fanno parte del comportamento minimo necessario per avviare, confermare, interrompere o chiudere correttamente una chiamata.

Questo passaggio va fissato bene. Vedere uscire un INVITE non significa che la chiamata sia già stabilita. Significa che un soggetto ha formulato una proposta di sessione. La differenza è pratica, non teorica. In un tracciato pcap è normale trovare INVITE inviati correttamente ma seguiti da rifiuti, timeout, errori di negoziazione o percorsi interrotti.

Perché l’INVITE conta così tanto

La RFC definisce l’INVITE come il metodo più importante del protocollo per una ragione semplice: è quello che consente di avviare una sessione tra partecipanti. Inoltre è l’unico metodo definito nella specifica che può creare un dialog. Il documento lo dice in modo esplicito quando descrive la struttura del protocollo e il ruolo dei dialoghi.

Nei sistemi reali questo ha almeno tre conseguenze operative.

La prima è che l’INVITE non va letto come un messaggio isolato. Va letto insieme alle risposte che produce.

La seconda è che molti problemi di chiamata non nascono nel media, ma prima ancora, nella fase di proposta e accettazione della sessione.

La terza è che da questo messaggio dipende una parte importante della futura correlazione del dialogo: identità coinvolte, Call-ID, tag, Contact e offerta SDP.

La forma del messaggio

Dal punto di vista sintattico, un INVITE resta una normale richiesta SIP. La RFC ricorda nella sezione 7 che ogni messaggio SIP è composto da start-line, uno o più header, una riga vuota obbligatoria e un body opzionale. Per le richieste, la Request-Line è definita nella sezione 7.1 ed è formata da Method, Request-URI e SIP-Version.

Un esempio semplice può essere questo:

INVITE sip:matteo@user.voipvoice.it SIP/2.0
Via: SIP/2.0/UDP user.voipvoice.it;branch=z9hG4bK-7a81c2
Max-Forwards: 70
From: <sip:daniele@user.voipvoice.it>;tag=4f92aa
To: <sip:matteo@user.voipvoice.it>
Call-ID: 8c7d9f31@user.voipvoice.it
CSeq: 1 INVITE
Contact: <sip:daniele@192.168.1.50:5060>
Content-Type: application/sdp
Content-Length: 187

v=0
o=daniele 53655765 2353687637 IN IP4 192.168.1.50
s=-
c=IN IP4 192.168.1.50
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

L’esempio serve a familiarizzare con il messaggio. All’inizio non serve discutere ogni dettaglio del body SDP. In questa fase della collana l’obiettivo è leggere correttamente la funzione del messaggio e capire dove guardare nel tracciato pcap.

Gli header minimi

La RFC richiede nella sezione 8.1.1 che una richiesta SIP valida contenga almeno sei header fondamentali: To, From, CSeq, Call-ID, Max-Forwards e Via. Sono questi gli elementi che permettono il routing delle risposte, l’identificazione della transazione, l’ordinamento dei messaggi e il controllo della propagazione della richiesta.

Nel lavoro quotidiano conviene controllarli in quest’ordine:

Request-URI

Indica il bersaglio operativo della richiesta (per esempio nella riga iniziale: INVITE sip:100@user.voipvoice.it SIP/2.0). Non coincide sempre con il destinatario dichiarato nel To. Questo diventa importante quando i proxy riscrivono il percorso o quando la rete separa identità logica e destinazione operativa. Se la Request-URI è errata, la chiamata può essere instradata verso il nodo sbagliato anche quando gli altri header sembrano coerenti.

To

Indica verso chi la richiesta era originariamente diretta (per esempio: To: <sip:matteo@user.voipvoice.it>). Rappresenta la destinazione logica iniziale, non necessariamente il nodo finale che risponderà. Per questo motivo il To aiuta a capire l’intenzione della chiamata, ma da solo non basta a spiegare il percorso reale della richiesta. Nell’INVITE iniziale il To normalmente non contiene ancora un tag: il To-tag arriva nella risposta ed è uno degli elementi che contribuiranno a identificare il dialogo.

From

Identifica l’origine logica della richiesta e contiene anche il tag locale (per esempio: From: <sip:daniele@user.voipvoice.it>;tag=4f92aa), utile per la successiva costruzione del dialogo. Quando si analizza un tracciato pcap, questo header serve anche a distinguere in modo stabile il lato chiamante dalle altre informazioni che possono essere riscritte lungo il percorso.

Call-ID

Deve essere unico e consente di correlare i messaggi che fanno parte della stessa chiamata dal punto di vista logico (per esempio: Call-ID: 8c7d9f31@user.voipvoice.it). È uno dei primi valori da controllare quando bisogna ricostruire il flusso completo tra più messaggi e più nodi di rete.

CSeq

Lega numero di sequenza e metodo (per esempio: CSeq: 1 INVITE). Serve a ordinare correttamente le richieste. Se il numero non è coerente con lo stato del dialogo o con il metodo inviato, la richiesta può essere rifiutata o interpretata come anomala.

Via

Permette il ritorno delle risposte e identifica la transazione (per esempio: Via: SIP/2.0/UDP user.voipvoice.it;branch=z9hG4bK-7a81c2). Per le implementazioni conformi, il valore di branch deve iniziare con z9hG4bK. Se il Via è costruito male o viene alterato in modo incoerente, la correlazione tra richiesta e risposta diventa subito più difficile.

Max-Forwards

Limita il numero di salti della richiesta e aiuta a contenere loop e instradamenti errati (per esempio: Max-Forwards: 70). Quando arriva a zero, la richiesta non può proseguire e questo aiuta a capire se il problema è nel routing della rete SIP.

Il ruolo del Contact

Per l’INVITE c’è un header che merita attenzione particolare: Contact. La RFC richiede nella sezione 8.1.1.8 che una richiesta capace di stabilire un dialog, quindi l’INVITE, contenga esattamente un URI SIP o SIPS nel campo Contact. Questo URI rappresenta il punto a cui il UA desidera ricevere le richieste successive.

Nel tracciato pcap questo punto si vede subito. Il Via serve al ritorno delle risposte della transazione corrente. Il Contact serve invece a indicare dove inviare richieste future verso quella specifica istanza del terminale.

Un errore frequente consiste nel confondere Contact con l’identità pubblica dell’utente. Non è così. Il Contact non è l’Address-of-Record (per esempio sip:matteo@user.voipvoice.it). È il recapito operativo di quella istanza specifica del UA (per esempio Contact: <sip:matteo@192.168.1.44:5060>).

INVITE e body SDP

La RFC ricorda più volte che SIP non descrive direttamente i dettagli della sessione media. Queste informazioni vengono portate nel body del messaggio, spesso in formato SDP. Anche nell’esempio classico della RFC, l’INVITE contiene Content-Type: application/sdp e una descrizione dei parametri media proposta dal chiamante.

Questo chiarisce perché l’INVITE abbia un peso così grande nel troubleshooting. Non avvia solo la segnalazione. Trasporta spesso anche l’offerta iniziale di codec, porte, indirizzi e attributi media. Se quella parte è incoerente, il setup SIP può anche sembrare corretto e il problema comparirà subito dopo, con audio assente, audio a una sola direzione o negoziazione fallita.

In Wireshark conviene controllare almeno quattro campi del body SDP: l’indirizzo in c=, la porta nel campo m=audio, l’elenco dei payload e la presenza di attributi che possono cambiare il comportamento del terminale o della centrale.

Le risposte all’INVITE

Una volta inviato l’INVITE, il UAC può ricevere una o più risposte provvisorie e poi una risposta finale. La sezione 13.1 e la sezione 13.2.2 lo spiegano con precisione. I 1xx servono a segnalare avanzamento. Una risposta 2xx indica accettazione della sessione. Le risposte 3xx, 4xx, 5xx e 6xx indicano che la richiesta non è stata accettata, ciascuna con significato diverso.

Nel comportamento reale della rete, le più comuni da osservare nella fase iniziale sono queste:

SIP/2.0 100 Trying
SIP/2.0 180 Ringing
SIP/2.0 200 OK

100 Trying segnala che la richiesta è stata ricevuta e che il sistema la sta elaborando. 180 Ringing segnala che il destinatario viene allertato. 200 OK segnala che la sessione è stata accettata. La differenza tra questi passaggi va letta bene, perché nel tracciato pcap racconta esattamente dove si trova la chiamata nel suo ciclo di avvio.

Vale la pena ricordare anche il caso delle risposte 3xx. In SIP non indicano solo un fallimento generico: possono restituire nuovi indirizzi nel campo Contact, che il chiamante può usare per tentare la richiesta verso una destinazione alternativa. Nel troubleshooting questo aiuta a capire che una deviazione o un nuovo tentativo dopo una 3xx può essere un comportamento previsto dalla rete, non per forza un’anomalia.

Quando nasce davvero la sessione

La RFC dice nella sezione 13.2.2.4 che una risposta 2xx a un INVITE stabilisce una sessione e crea anche un dialog tra il UA che ha inviato l’INVITE e quello che ha generato la risposta 2xx. Se l’INVITE è stato inoltrato con forking e arrivano più risposte 2xx da rami diversi, ogni risposta crea un dialog distinto.

Questo è uno dei punti che più spesso generano letture superficiali. Il 180 Ringing non crea ancora la sessione. Il 200 OK sì. E quando c’è forking, il comportamento si complica perché una sola richiesta INVITE può produrre più dialog confermati.

Sul campo questo problema compare quando un tecnico guarda solo il primo esito visibile e non controlla se siano arrivate risposte multiple. In reti semplici succede raramente. In ambienti enterprise o provider può succedere molto più facilmente, soprattutto con gruppi di risposta, instradamenti paralleli o logiche di raggiungibilità su più contatti.

Il forking sull’invite

Nel SIP, il forking è il comportamento con cui un proxy inoltra lo stesso INVITE verso più destinazioni possibili invece di sceglierne una sola. In pratica, la rete prova a raggiungere lo stesso utente su più contatti registrati o su più terminali nello stesso momento.

Un caso tipico è questo: Matteo è registrato sia sul telefono da scrivania sia sul softphone del portatile. Quando arriva un INVITE per sip:matteo@user.voipvoice.it, il proxy può inoltrarlo a entrambi i contatti. Se uno dei due risponde con una 2xx, quella risposta accetta la sessione. Se rispondono più rami con una 2xx, il chiamante può ricevere più risposte finali di successo.

Questo punto è importante perché cambia il modo di leggere il tracciato pcap. Una sola richiesta INVITE può generare più rami, più risposte provvisorie e, in alcuni casi, più risposte 200 OK. Non è un errore di per sé. È un comportamento previsto dalla logica SIP quando la rete cerca lo stesso utente su più destinazioni.

Dal punto di vista pratico, il forking compare spesso in ambienti con più dispositivi registrati, gruppi di risposta o instradamenti paralleli. Quando succede, non basta fermarsi al primo messaggio visibile. Bisogna controllare se esistono più risposte allo stesso INVITE e se i rami appartengono davvero alla stessa chiamata logica.

Errori di lettura frequenti

Il primo errore consiste nel pensare che l’INVITE sia già la chiamata. In realtà è la richiesta con cui il chiamante propone l’avvio di una sessione. La chiamata può dirsi accettata solo quando arriva una risposta finale di successo, cioè una 2xx, tipicamente 200 OK.

Il secondo consiste nel considerare To come destinazione operativa assoluta. Spesso non lo è. Per leggere bene la richiesta bisogna distinguere tra destinatario dichiarato e bersaglio operativo.

Il terzo consiste nel ignorare il body SDP. In molte analisi si guarda solo la segnalazione e si trascura la negoziazione media contenuta nel body.

Il quarto consiste nel usare il Contact come se fosse l’identità pubblica dell’utente. Non lo è. È il recapito di quella specifica istanza del UA.

Il quinto consiste nel fermarsi a 180 Ringing e considerare il setup completato. La sessione viene accettata solo con una risposta 2xx. L’ACK completa poi la conferma finale, ma quel passaggio lo affronteremo nel capitolo successivo, come previsto dal piano editoriale.

Conclusione

In questo capitolo abbiamo visto che l’INVITE non è un semplice messaggio di avvio chiamata. È la richiesta con cui un UAC propone una sessione, definisce il contesto iniziale della segnalazione e porta spesso con sé l’offerta media in SDP. La RFC lo colloca al centro della nascita della sessione SIP e del futuro dialogo tra i partecipanti.

Nel prossimo capitolo vedremo ACK, cioè la conferma finale della sessione accettata. È il passaggio che chiude correttamente il ciclo dell’INVITE e che, nei problemi reali, merita sempre un controllo separato e molto attento.