Quando si ha a che fare con un qualsiasi protocollo che utilizza e crea oggetti e messaggi per funzionare, il primo aspetto che risulta utile analizzare è il dialogo. La RFC 3261, al capitolo 12 e successivi, descrive ampiamente le funzionalità di creazione, richiesta, funzionamento e conclusione di un dialogo SIP.
Riportando esattamente quanto enunciato nel capitolo 12: un dialogo SIP costituisce una relazione di tipo peer-to-peer tra due User Agent che viene mantenuta per un certo periodo di tempo. La finestra di dialogo facilita la sequenza di scambio di messaggi tra gli User Agent e il corretto instradamento delle richieste tra di essi. Il dialogo rappresenta il contesto nel quale interpretare i messaggi SIP.
Gli elementi identificativi di una finestra di dialogo SIP
In ambito SIP possiamo identificare un dialogo sulla base di alcuni elementi caratteristici, chiamati genericamente dialog-ID.
- Un identificativo specifico della chiamata, che prende il nome di Call-ID.
- Un identificativo locale (tag) specifico associato all’header From del messaggio.
- Un identificativo remoto (tag) specifico associato all’header To del messaggio.
Un dialogo SIP è anche comunemente e formalmente conosciuto con il termine inglese Call Leg.
Come abbiamo già avuto modo di evidenziare nell’articolo relativo all’analisi delle header SIP, il Call-ID è l’intestazione che identifica ogni chiamata SIP e che deve necessariamente essere presente sia nella richiesta sia nella risposta SIP.
Esso deve essere univoco a livello globale e dovrebbe essere associato all’indirizzo IP del mittente, come ad esempio:
Call-ID: a6de70db011d1d55-Acc136-B2b414@10.13.22.8
A questo punto occorre però introdurre un ulteriore elemento di novità per chi ha sempre e unicamente sentito parlare del Call-ID come identificativo univoco di una chiamata VoIP. Il Call-ID non è purtroppo sufficiente, da solo, per garantire l’unicità di un dialogo SIP che parte dall’UAC (User Agent Client) e attraversa la rete per giungere a destinazione.
I vari elementi di rete e i diversi passaggi specifici possono infatti far venir meno tale unicità.
Cosa accade nel caso di trasferimento di chiamata a più UA contemporaneamente?
Il caso più tipico che impone l’utilizzo di tag aggiuntivi rispetto al Call-ID è dato dal trasferimento di una chiamata a più destinatari contemporaneamente.
Supponiamo di trasferire una determinata chiamata a un collega che dispone di diversi dispositivi registrati in parallelo (fork-id), come ad esempio: telefono fisso, telefono mobile e PC.
In questo caso il singolo messaggio SIP di INVITE deve essere trasformato dal PBX in più messaggi di INVITE paralleli con destinazioni diverse. Il singolo identificativo Call-ID non è quindi più sufficiente per garantire l’unicità del dialogo: ne occorrono di distinti.
È proprio in questa circostanza che entrano in gioco i tag locali e remoti.
Abbiamo quindi compreso che l’obiettivo di un tag (locale o remoto) è quello di lavorare in sinergia con il Call-ID per rendere univoco un dialogo SIP anche quando esistono più fork (ramificazioni parallele) di una stessa sessione SIP.
Il tag SIP locale (header From):
viene assegnato dal mittente del messaggio, ovvero dall’UAC (User Agent Client). L’UAC inserisce il proprio tag nell’header From del messaggio SIP.
Il tag SIP remoto (header To):
viene assegnato dal destinatario del messaggio, ovvero dall’UAS (User Agent Server). L’UAS inserisce il proprio tag nell’header To del messaggio SIP.
Il meccanismo di scambio dei tag SIP tra UAC e UAS
Proviamo ora a descrivere il flusso tipico di un trasferimento di chiamata attraverso un esempio di richiesta INVITE.
Quando un UAC invia il messaggio di INVITE, inserisce un tag nell’header From. In quel momento, nell’header To non è presente alcun tag.
INVITE
…
To: sip:0550935400@user.voipvoice.it
From: “0550935402” <sip:0550935402@user.voipvoice.it>;tag=AIC095F311D471D768
…
Quando un UAS riceve il messaggio e risponde con una risposta SIP (ad esempio 100 Trying), aggiunge un tag all’header To in modo che la risposta possa essere univoca a livello di tag.
Se più client ricevessero il messaggio originale, come nel caso del fork-id indicato nel paragrafo precedente, ciascuno aggiungerebbe il proprio valore di tag specifico.
180 RINGING
…
To: sip:0550935400@user.voipvoice.it;tag=0081f4.Ab2b134.Pb2b206.B2b36
From: “0550935402” <sip:0550935402@user.voipvoice.it>;tag=AIC095F311D471D768
…
È quindi evidente che tutti questi messaggi SIP avranno lo stesso tag From, ma, a seconda di chi sta rispondendo, avranno tag To differenti. Questo comportamento è assolutamente normale perché, in caso contrario, si verrebbe a creare un’enorme confusione.
Nel caso in cui l’INVITE riguardasse, come nell’esempio citato in precedenza, il trasferimento di una chiamata verso tre possibili dispositivi SIP (telefono fisso, telefono mobile e PC), avremmo ulteriori messaggi di risposta caratterizzati da un differente tag To.
180 RINGING
…
To: sip:0550935400@user.voipvoice.it;tag=0058978.BR4502926.U12bkdfoi8
From: “0550935402” <sip:0550935402@user.voipvoice.it>;tag=AIC095F311D471D768
…
La chiamata proseguirà ovviamente fino all’ottenimento di una risposta definitiva di tipo 200 OK. In questo momento tutti i dialoghi SIP in parallelo (fork) verranno cancellati.
I singoli tag, insieme al Call-ID, permetteranno quindi di distinguere la chiamata SIP da mantenere rispetto a quelle da terminare.
Dialogo SIP e transazioni: una distinzione necessaria
È utile, a questo punto, chiarire la differenza tra dialogo SIP e transazione SIP, due concetti spesso confusi ma profondamente diversi.
Una transazione SIP rappresenta lo scambio di una singola richiesta e delle relative risposte, fino all’ottenimento di una risposta finale. Il dialogo SIP, invece, è un contesto più ampio e persistente, che può includere più transazioni successive, come ad esempio INVITE, re-INVITE e BYE.
Questa distinzione permette di interpretare correttamente il comportamento della segnalazione SIP nel tempo e per analizzare in modo efficace i flussi di chiamata.
Il ruolo del dialogo SIP nella segnalazione successiva alla chiamata
Una volta che un dialogo SIP è stato stabilito, tutte le richieste successive devono fare riferimento allo stesso dialogo. Questo avviene mantenendo invariata la combinazione di Call-ID, tag From e tag To.
Messaggi come BYE, re-INVITE o UPDATE vengono quindi associati al dialogo esistente, consentendo agli User Agent e agli apparati di rete di riconoscere correttamente il contesto della comunicazione.
Perché il dialogo SIP è fondamentale nel troubleshooting
Dal punto di vista operativo, la corretta identificazione di un dialogo SIP è uno degli elementi chiave nelle attività di troubleshooting.
Durante l’analisi di una cattura SIP, la possibilità di seguire un dialogo attraverso Call-ID e tag permette di distinguere i vari rami di forking, identificare il dialogo effettivamente stabilito e comprendere eventuali anomalie nel flusso di segnalazione.
Errori nella gestione dei tag o incongruenze nel Call-ID possono causare problemi tipici, come chiamate che squillano senza instaurarsi o chiamate che non vengono correttamente terminate.
Dialogo SIP e apparati di rete
È importante ricordare che il comportamento del dialogo SIP può variare in funzione degli apparati di rete coinvolti.
Proxy SIP, B2BUA e SBC possono infatti gestire i dialoghi in modo differente, talvolta terminando un dialogo e creandone uno nuovo. Questo comportamento spiega perché, in architetture complesse, una singola chiamata VoIP possa essere rappresentata da più dialoghi SIP distinti.
La comprensione di queste dinamiche è essenziale per interpretare correttamente i tracciati SIP e per progettare infrastrutture VoIP affidabili e scalabili.