Quando si cerca di spiegare il funzionamento del Protocollo SIP si inizia, in genere, dagli elementi più importanti e immediatamente visibili nel complesso del protocollo stesso. Spesso si rimanda ad un momento successivo l’approfondimento degli aspetti particolari ma non meno indispensabili. Oggi è quindi giunto il momento di parlare di dialogo in ambito SIP e degli elementi che lo identificano.
Quando in genere si ha a che fare con un qualsiasi protocollo che utilizza e crea oggetti e messaggi per funzionare, il primo aspetto che è utile analizzare è il dialogo. La RFC3261 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 SIP 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 che nella risposta SIP. Esso deve essere necessariamente 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 di Call-ID quale 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 vari passaggi specifici possono infatti fare sparire 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 Caller-ID è dato dal trasferimento di una chiamata a più destinatari contemporaneamente. Supponiamo di trasferire una determinata chiamata ad un collega che dispone di diversi dispositivi registrati in parallelo (fork-id) come ad esempio: telefono fisso, telefono mobile, PC. In questo caso il singolo messaggio SIP di INVITE deve essere trasformato dal PBX in più messaggi di INVITE paralleli con destinazioni diverse. In questo caso il singolo identificativo Call-ID non è più sufficiente per garantire l’unicità del dialogo; ne occorrono 3 differenziati. E’ 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 (From header): Viene assegnato dal mittente del messaggio o dall’UAC (User Agent Client). L’UAC inserisce il proprio tag nell’header From del messaggio SIP.
Il Tag SIP remoto (To header): Viene assegnato dal destinatario del messaggio o 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 a descrivere il flusso tipico di un trasferimento di chiamata attraverso un esempio di richiesta di 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 quel messaggio e risponde con una risposta SIP (ad es. 100 trying), esso 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 al paragrafo precedente, essi aggiungerebbero tutti i propri valori di tag specifici.
180 RINGING
…
To: sip:0550935400@user.voipvoice.it; tag=0081f4.Ab2b134.Pb2b206.B2b36
From: “0550935402” <sip:0550935402@user.voipvoice.it>;tag=AIC095F311D471D768
…
E’ quindi evidente che, tutti quei messaggi SIP avranno lo stesso tag From, ma a seconda di chi sta rispondendo, ci saranno tag To diversi. Questo comportamento è assolutamente normale perché , in caso contrario si verrebbe a creare un’enorme confusione.
Nel caso in cui il l’INVITE riguardasse, come nell’esempio citato in preferenza, il trasferimento di una chiamata a tre possibili dispositivi SIP (telefono fisso, telefono mobile, PC) avremmo altri 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 ad ottenere una possibile risposta definitiva di 200 OK. In questo caso tutti i dialoghi SIP in parallelo (fork) verranno cancellate. I singoli Tag, insieme al Call-ID permetteranno quindi di distinguere la chiamata SIP da mantenere, rispetto a quelle da cancellare.
