19. Componenti comuni dei messaggi (Common Message Components)
Vi sono alcuni componenti dei messaggi SIP che appaiono in varie posizioni nei messaggi SIP (e talvolta all'esterno di essi) che meritano una discussione separata.
19.1 Indicatore di risorsa uniforme SIP e SIPS (SIP and SIPS Uniform Resource Indicators)
Un URI SIP o SIPS identifica una risorsa di comunicazione. Come tutti gli URI, gli URI SIP e SIPS possono essere posti in pagine web, messaggi di posta elettronica o documenti stampati. Essi contengono informazioni sufficienti per avviare e mantenere una sessione di comunicazione con la risorsa.
Esempi di risorse di comunicazione includono:
o un utente di un servizio online
o un'apparizione su un telefono multiline
o una casella di posta su un sistema di messaggistica
o un numero PSTN su un servizio di gateway
o un gruppo (come «sales» o «helpdesk») in un'organizzazione
Un URI SIPS specifica che la risorsa deve essere contattata in modo sicuro. Ciò significa, in particolare, che TLS deve essere utilizzato tra il UAC e il dominio che possiede l'URI. Da lì, le comunicazioni sicure sono utilizzate per raggiungere l'utente, il meccanismo di sicurezza specifico dipendendo dalla politica del dominio. Qualsiasi risorsa descritta da un URI SIP può essere «aggiornata» a un URI SIPS cambiando semplicemente lo schema, se si desidera comunicare con tale risorsa in modo sicuro.
19.1.1 Componenti degli URI SIP e SIPS (SIP and SIPS URI Components)
Gli schemi «sip:» e «sips:» seguono le linee guida della RFC 2396 [5]. Essi utilizzano una forma simile all'URL mailto, permettendo la specifica dei campi di intestazione della richiesta SIP e del corpo del messaggio SIP. Ciò consente di specificare l'oggetto, il tipo di supporto o l'urgenza delle sessioni avviate utilizzando un URI su una pagina web o in un messaggio di posta elettronica. La sintassi formale di un URI SIP o SIPS è presentata nella sezione 25. La sua forma generale, nel caso di un URI SIP, è:
sip:user:password@host:port;uri-parameters?headers
Il formato di un URI SIPS è lo stesso, eccetto che lo schema è «sips» anziché sip. Questi token, e alcuni dei token nelle loro espansioni, hanno i significati seguenti:
user: L'identificatore di una risorsa particolare sull'host indirizzato. Il termine «host» in questo contesto si riferisce frequentemente a un dominio. L'«userinfo» di un URI è composto da questo campo user, dal campo password e dal segno @ che li segue. La parte userinfo di un URI è opzionale e PUÒ essere assente quando l'host di destinazione non ha il concetto di utente o quando l'host stesso è la risorsa identificata. Se il segno @ è presente in un URI SIP o SIPS, il campo user NON DEVE essere vuoto.
Se l'host indirizzato può gestire numeri di telefono, ad esempio un gateway di telefonia Internet, un campo telephone-subscriber definito nella RFC 2806 [9] PUÒ essere utilizzato per riempire il campo user. Vi sono regole di escape speciali per la codifica dei campi telephone-subscriber negli URI SIP e SIPS descritte nella sezione 19.1.2.
password: Una password associata all'utente. Sebbene la sintassi dell'URI SIP e SIPS permetta la presenza di questo campo, il suo utilizzo NON È RACCOMANDATO, poiché il passaggio di informazioni di autenticazione in chiaro (come gli URI) si è rivelato un rischio di sicurezza in quasi tutti i casi in cui è stato utilizzato. Ad esempio, trasportare un PIN in questo campo espone il PIN.
Si noti che il campo password è solo un'estensione della parte user. Le implementazioni che non desiderano dare significato particolare alla parte password del campo POSSONO semplicemente trattare «user:password» come una singola stringa.
host: L'host che fornisce la risorsa SIP. La parte host contiene o un nome di dominio completamente qualificato o un indirizzo IPv4 o IPv6 numerico. L'uso della forma del nome di dominio completamente qualificato è RACCOMANDATO ove possibile.
port: Il numero di porta a cui inviare la richiesta.
Parametri URI: Parametri che influenzano una richiesta costruita dall'URI.
I parametri URI sono aggiunti dopo il componente hostport e sono separati da punti e virgola.
I parametri URI assumono la forma:
parameter-name "=" parameter-value
Sebbene un numero arbitrario di parametri URI possa essere incluso in un URI, un parameter-name dato NON DEVE apparire più di una volta.
Questo meccanismo estensibile include i parametri transport, maddr, ttl, user, method e lr.
Il parametro transport determina il meccanismo di trasporto da utilizzare per l'invio dei messaggi SIP, come specificato in [4]. SIP può usare qualsiasi protocollo di trasporto di rete. Sono definiti nomi di parametri per UDP (RFC 768 [14]), TCP (RFC 761 [15]) e SCTP (RFC 2960 [16]). Per un URI SIPS, il parametro transport DEVE indicare un trasporto affidabile.
Il parametro maddr indica l'indirizzo del server da contattare per questo utente, sovrascrivendo qualsiasi indirizzo derivato dal campo host. Quando un parametro maddr è presente, i componenti port e transport dell'URI si applicano all'indirizzo indicato nel valore del parametro maddr. [4] descrive l'interpretazione appropriata di transport, maddr e hostport per ottenere l'indirizzo, la porta e il trasporto di destinazione per l'invio di una richiesta.
Il campo maddr è stato utilizzato come una forma semplice di routing a sorgente libera. Esso permette a un URI di specificare un proxy che deve essere attraversato verso la destinazione. Il proseguimento dell'uso del parametro maddr in questo modo è fortemente sconsigliato (i meccanismi che lo abilitano sono obsoleti). Le implementazioni dovrebbero invece usare il meccanismo Route descritto in questo documento, stabilendo un insieme di route preesistente se necessario (vedere la sezione 8.1.1.1). Ciò fornisce un URI completo per descrivere il nodo da attraversare.
Il parametro ttl determina il valore di durata (time-to-live) del pacchetto UDP multicast e NON DEVE essere utilizzato se non quando maddr è un indirizzo multicast e il protocollo di trasporto è UDP. Ad esempio, per specificare una chiamata a [email protected] utilizzando il multicast verso 239.255.255.1 con un ttl di 15, sarebbe utilizzato l'URI seguente:
sip:[email protected];maddr=239.255.255.1;ttl=15
L'insieme delle stringhe telephone-subscriber valide è un sottoinsieme delle stringhe user valide. Il parametro URI user esiste per distinguere i numeri di telefono dai nomi utente che assomigliano casualmente a numeri di telefono. Se la stringa user contiene un numero di telefono formattato come un telephone-subscriber, il valore del parametro user «phone» DEVE essere presente. Anche senza questo parametro, i destinatari di URI SIP e SIPS POSSONO interpretare la parte prima della @ come un numero di telefono se le restrizioni locali sullo spazio dei nomi del nome utente lo permettono.
Il metodo della richiesta SIP costruita dall'URI può essere specificato con il parametro method.
Il parametro lr, quando presente, indica che l'elemento responsabile di questa risorsa implementa i meccanismi di routing specificati in questo documento. Questo parametro sarà utilizzato negli URI che i proxy inseriscono nei valori dei campi di intestazione Record-Route, e può apparire negli URI di un insieme di route preesistente.
Questo parametro è utilizzato per ottenere la compatibilità con i sistemi che implementano i meccanismi di routing stretto della RFC 2543 e le bozze rfc2543bis fino a bis-05. Un elemento che si prepara a inviare una richiesta basata su un URI che non contiene questo parametro può supporre che l'elemento ricevente implementi il routing stretto e riformattare il messaggio per preservare le informazioni nel Request-URI.
Poiché il meccanismo uri-parameter è estensibile, gli elementi SIP DEVONO ignorare silenziosamente qualsiasi uri-parametro che non comprendono.
Intestazioni: Campi di intestazione da includere in una richiesta costruita dall'URI.
I campi di intestazione nella richiesta SIP possono essere specificati con il meccanismo «?» in un URI. I nomi e i valori delle intestazioni sono codificati come coppie hname = hvalue separate da e commerciali. Lo speciale hname «body» indica che l'hvalue associata è il corpo del messaggio della richiesta SIP.
La tabella 1 riassume l'uso dei componenti degli URI SIP e SIPS in base al contesto in cui l'URI appare. La colonna external descrive gli URI che appaiono ovunque all'esterno di un messaggio SIP, ad esempio su una pagina web o un biglietto da visita. Le voci contrassegnate «m» sono obbligatorie, quelle contrassegnate «o» sono opzionali e quelle contrassegnate «-» non sono consentite. Gli elementi che elaborano gli URI DOVREBBERO ignorare qualsiasi componente non consentito se presente. La seconda colonna indica il valore predefinito di un elemento opzionale se assente. «--» indica che l'elemento è o non opzionale o non ha un valore predefinito.
Gli URI nei campi di intestazione Contact hanno restrizioni diverse a seconda del contesto in cui il campo di intestazione appare. Un insieme si applica ai messaggi che stabiliscono e mantengono i dialoghi (INVITE e la sua risposta 200 (OK)). L'altro si applica ai messaggi di registrazione e reindirizzamento (REGISTER, la sua risposta 200 (OK) e risposte di classe 3xx a qualsiasi metodo).
19.1.2 Requisiti di escape dei caratteri (Character Escaping Requirements)
dialog
reg./redir. Contact/
default Req.-URI To From Contact R-R/Route external
user -- o o o o o o password -- o o o o o o host -- m m m m m m port (1) o - - o o o user-param ip o o o o o o method INVITE - - - - - o maddr-param -- o - - o o o ttl-param 1 o - - o - o transp.-param (2) o - - o o o lr-param -- o - - - o o other-param -- o o o o o o headers -- - - - o - o
(1): Il valore di porta predefinito dipende dal trasporto e dallo schema. Il valore predefinito è 5060 per sip: che usa UDP, TCP o SCTP. Il valore predefinito è 5061 per sip: che usa TLS su TCP e sips: su TCP.
(2): Il trasporto predefinito dipende dallo schema. Per sip:, è UDP. Per sips:, è TCP.
Tabella 1: Uso e valori predefiniti dei componenti URI per i valori dei campi di intestazione SIP, Request-URI e riferimenti
SIP segue i requisiti e le linee guida della RFC 2396 [5] nel definire l'insieme dei caratteri che devono essere escapati in un URI SIP, e usa il suo meccanismo «%» HEX HEX per l'escape. Estratto dalla RFC 2396 [5]:
L'insieme dei caratteri effettivamente riservati all'interno di un dato componente URI è definito da quel componente. In generale, un carattere è riservato se la semantica dell'URI cambia se il carattere è sostituito dalla sua codifica US-ASCII escapata [5]. I caratteri US-ASCII esclusi (RFC 2396 [5]), come spazi e caratteri di controllo e i caratteri usati come delimitatori URI, DEVONO essere anch'essi escapati. Gli URI NON DEVONO contenere spazi e caratteri di controllo non escapati.
Per ogni componente, l'insieme delle espansioni BNF valide definisce esattamente quali caratteri possono apparire non escapati. Tutti gli altri caratteri DEVONO essere escapati.
Ad esempio, «@» non è nell'insieme dei caratteri del componente user, quindi l'utente «j@s0n» deve avere almeno il segno @ codificato, come in «j%40s0n».
L'espansione dei token hname e hvalue della sezione 25 mostra che tutti i caratteri riservati URI nei nomi e valori dei campi di intestazione DEVONO essere escapati.
Il sottoinsieme telephone-subscriber del componente user ha considerazioni di escape speciali. L'insieme dei caratteri non riservati nella descrizione telephone-subscriber della RFC 2806 [9] contiene un numero di caratteri in vari elementi di sintassi che devono essere escapati quando utilizzati in URI SIP. Qualsiasi carattere che appare in un telephone-subscriber che non appare in un'espanzione della BNF per la regola user DEVE essere escapato.
Si noti che l'escape dei caratteri non è consentito nel componente host di un URI SIP o SIPS (il carattere % non è valido nella sua espansione). Ciò probabilmente cambierà in futuro man mano che i requisiti per i nomi di dominio internazionalizzati saranno finalizzati. Le implementazioni attuali NON DEVONO tentare di migliorare la robustezza trattando i caratteri escapati ricevuti nel componente host come equivalenti letteralmente alle loro controparti non escapate. Il comportamento richiesto per soddisfare i requisiti IDN può essere significativamente diverso.
19.1.3 Esempi di URI SIP e SIPS (Example SIP and SIPS URIs)
sip:[email protected] sip:alice:[email protected];transport=tcp sips:[email protected]?subject=project%20x&priority=urgent sip:+1-212-555-1212:[email protected];user=phone sips:[email protected] sip:[email protected] sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=[email protected]
Il valore del campo user dell'esempio di URI più recente sopra è «alice;day=tuesday». Le regole di escape definite sopra permettono al punto e virgola di apparire non escapato in questo campo. Ai fini di questo protocollo, questo campo è opaco. La struttura del suo valore è utile solo per l'elemento SIP responsabile di tale risorsa.
19.1.4 Confronto degli URI (URI Comparison)
Alcune operazioni di questa specifica devono determinare se due URI SIP o SIPS sono equivalenti. Questa specifica richiede che i registrar confrontino le associazioni dell'URI Contact in una richiesta REGISTER (vedere la sezione 10.3). Gli URI SIP e SIPS sono confrontati per uguaglianza secondo le seguenti regole:
o Un URI SIP e un URI SIPS non sono mai equivalenti.
o Il confronto dell'userinfo degli URI SIP e SIPS fa distinzione tra maiuscole e minuscole. Ciò include l'userinfo contenente una password o formattato come un telephone-subscriber. Il confronto di tutti gli altri componenti dell'URI non fa distinzione tra maiuscole e minuscole, salvo diversa definizione esplicita.
o L'ordine dei parametri e dei campi di intestazione non è significativo nel confronto degli URI SIP e SIPS.
o I caratteri non nell'insieme «riservato» (vedere RFC 2396 [5]) sono equivalenti alla loro codifica «%» HEX HEX.
o Un indirizzo IP risultante da una ricerca DNS del nome host non è uguale a quel nome host.
o Affinché due URI siano uguali, i componenti user, password, host e port devono corrispondere.
Un URI che omette il componente user non corrisponde a un URI che lo include. Un URI che omette il componente password non corrisponde a un URI che lo include.
Un URI che omette un componente con un valore predefinito non corrisponde a un URI che include esplicitamente quel componente con il suo valore predefinito. Ad esempio, un URI che omette il componente port opzionale non corrisponde a un URI che dichiara esplicitamente la porta 5060. Lo stesso vale per i componenti transport-parameter, ttl-parameter, user-parameter e method.
Definire sip:user@host come non equivalente a sip:user@host:5060 è una modifica rispetto alla RFC 2543. Nel derivare un indirizzo da un URI, URI equivalenti sono attesi per dare indirizzi equivalenti. L'URI sip:user@host:5060 è sempre risolto alla porta 5060. L'URI sip:user@host può essere risolto ad altre porte tramite il meccanismo DNS SRV dettagliato in [4].
o I componenti uri-parameter dell'URI sono confrontati come segue.
- Qualsiasi uri-parameter che appare in entrambi gli URI deve corrispondere.
- Un uri-parameter user, ttl o method che appare solo in uno degli URI non corrisponde mai, anche se include un valore predefinito.
- Un URI che include il parametro maddr non corrisponde a un URI che non include il parametro maddr.
- Tutti gli altri uri-parameter che appaiono solo in uno degli URI sono ignorati nel confronto degli URI.
o I componenti header di un URI non sono mai ignorati. I componenti header presenti devono apparire in entrambi gli URI e corrispondere affinché gli URI corrispondano. Le regole di corrispondenza sono definite per ogni campo di intestazione nella sezione 20.
Gli URI in ciascuno dei seguenti insiemi sono equivalenti.
sip:%[email protected];transport=TCP sip:[email protected];Transport=tcp
sip:[email protected] sip:[email protected];newparam=5 sip:[email protected];security=on
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
sip:[email protected]?subject=project%20x&priority=urgent sip:[email protected]?priority=urgent&subject=project%20x
Gli URI in ciascuno dei seguenti insiemi non sono equivalenti.
SIP:[email protected];Transport=udp (nome utente diverso) sip:[email protected];Transport=UDP
sip:[email protected] (potrebbe essere risolto a una porta diversa) sip:[email protected]:5060
sip:[email protected] (potrebbe essere risolto a un trasporto diverso) sip:[email protected];transport=udp
sip:[email protected] (potrebbe essere risolto a una porta e trasporto diversi) sip:[email protected]:6000;transport=tcp
sip:[email protected] (componenti header diversi) sip:[email protected]?Subject=next%20meeting
sip:[email protected] (anche se questo è la risoluzione di sip:[email protected] phone21.boxesbybob.com)
Si noti che l'uguaglianza non è transitiva.
o sip:[email protected] e sip:[email protected];security=on sono equivalenti
o sip:[email protected] e sip:[email protected];security=off sono equivalenti
o sip:[email protected];security=on e
sip:[email protected];security=off non sono equivalenti
19.1.5 Formazione di richieste da un URI (Forming Requests from a URI)
Le implementazioni devono essere prudenti quando costruiscono direttamente richieste da URI. Gli URI provenienti da biglietti da visita, pagine web o persino fonti interne al protocollo (come contatti registrati) possono contenere campi di intestazione o parti del corpo inappropriati.
Le implementazioni DEVONO includere i parametri transport, maddr, ttl o user forniti nel Request-URI della richiesta costruita. Se l'URI contiene un parametro method, il suo valore DEVE essere utilizzato come metodo della richiesta. Il parametro method NON DEVE essere posto nel Request-URI. I parametri URI sconosciuti DEVONO essere posti nel Request-URI del messaggio.
Le implementazioni DOVREBBERO trattare la presenza di componenti header o body nell'URI come un'indicazione che essi devono essere inclusi nel messaggio, e scegliere di soddisfare tale richiesta componente per componente.
Le implementazioni NON DOVREBBERO rispondere a questi campi di intestazione manifestamente pericolosi: From, Call-ID, CSeq, Via e Record-Route.
Le implementazioni NON DOVREBBERO rispondere ai valori dei campi di intestazione Route richiesti, per non servire da agenti inconsapevoli in un attacco dannoso.
Le implementazioni NON DOVREBBERO rispondere alle richieste di campi di intestazione che potrebbero causare la pubblicizzazione falsa della loro posizione o capacità. Ciò include Accept, Accept-Encoding, Accept-Language, Allow, Contact (usato in un dialogo), Organization, Supported e User-Agent.
Le implementazioni DOVREBBERO validare l'accuratezza dei campi di intestazione descrittivi richiesti includendo Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date e Timestamp.
Se una richiesta formata costruendo un messaggio da un determinato URI non è una richiesta SIP valida, l'URI è non valido. Le implementazioni NON DEVONO procedere con l'invio della richiesta. Esse dovrebbero invece intraprendere le azioni appropriate per un URI non valido nel contesto in cui si è verificato.
Una richiesta costruita può essere non valida in molti modi. Ciò include, senza limitarsi a, errori di sintassi dei campi di intestazione, combinazioni non valide di parametri URI o descrizioni errate del corpo del messaggio.
L'invio di una richiesta formata da un determinato URI può richiedere capacità non disponibili per l'implementazione. Ad esempio, l'URI può indicare l'uso di un trasporto o di un'estensione non implementati. Le implementazioni DOVREBBERO rifiutare di inviare queste richieste piuttosto che modificarle per adattarle alle loro capacità. Le implementazioni NON DEVONO inviare richieste che richiedono estensioni che non supportano.
Ad esempio, tali richieste possono essere formate tramite la presenza di un parametro Require di intestazione o di un parametro method URI con un valore sconosciuto o esplicitamente non supportato.
19.1.6 Correlazione di URI SIP e URL tel (Relating SIP URIs and tel URLs)
Quando un URL tel (RFC 2806 [9]) è convertito in un URI SIP o SIPS, l'intera parte telephone-subscriber dell'URL tel (parametri inclusi) è posta nella parte userinfo dell'URI SIP o SIPS.
Pertanto, tel:+358-555-1234567;postd=pp22 diventa
sip:+358-555-1234567;[email protected];user=phone
o sips:+358-555-1234567;postd=[email protected];user=phone
ma NON
sip:[email protected];postd=pp22;user=phone
o
sips:[email protected];postd=pp22;user=phone
In generale, URL «tel» equivalenti convertiti in URI SIP o SIPS in questo modo non producono necessariamente URI SIP o SIPS equivalenti. L'userinfo degli URI SIP e SIPS è confrontato come una stringa che distingue tra maiuscole e minuscole. Le differenze nelle parti non sensibili alle maiuscole di un URL tel, o la riordinazione dei parametri di un URL tel, non influenzano l'equivalenza dell'URL tel, ma influenzano l'equivalenza degli URI SIP formati da essi.
Ad esempio,
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
sono equivalenti, ma
sip:+358-555-1234567;[email protected];user=phone
sip:+358-555-1234567;[email protected];user=phone
non lo sono.
Allo stesso modo,
tel:+358-555-1234567;postd=pp22;isub=1411
tel:+358-555-1234567;isub=1411;postd=pp22
sono equivalenti, ma
sip:+358-555-1234567;postd=pp22;[email protected];user=phone
sip:+358-555-1234567;isub=1411;[email protected];user=phone
non lo sono.
Per mitigare questo problema, gli elementi che formano il campo telephone-subscriber posto nella parte userinfo di un URI SIP o SIPS DOVREBBERO ripiegare in minuscolo tutte le parti non sensibili alle maiuscole del telephone-subscriber e riordinare i parametri telephone-subscriber in ordine lessicografico dei nomi dei parametri, ad eccezione di isdn-subaddress e post-dial che appaiono per primi e in quell'ordine. (Tutti i componenti eccetto le estensioni future degli URL tel sono definiti per essere confrontati senza distinzione tra maiuscole e minuscole.)
Seguendo questa proposta, entrambi
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
diventano
sip:+358-555-1234567;[email protected];user=phone
e entrambi
tel:+358-555-1234567;tsp=a.b;phone-context=5
tel:+358-555-1234567;phone-context=5;tsp=a.b
diventano
sip:+358-555-1234567;phone-context=5;[email protected];user=phone
19.2 Tag di opzione (Option Tags)
Un tag di opzione è un identificatore unico utilizzato per specificare una nuova opzione (estensione) in SIP. Questi tag sono utilizzati nei campi di intestazione Require (sezione 20.32), Proxy-Require (sezione 20.29), Supported (sezione 20.37) e Unsupported (sezione 20.40). Si noti che queste opzioni appaiono come parametri in questi campi di intestazione, nella forma option-tag = token (vedere la sezione 25 per la definizione di token).
I tag di opzione sono definiti nelle RFC di tipo Standards Track. Ciò è un cambiamento rispetto alle pratiche passate, introdotto per garantire l'interoperabilità continua tra fornitori (vedere le discussioni delle sezioni 20.32 e 20.37). Un registro IANA dei tag di opzione è utilizzato per facilitare il riferimento.
19.3 Tag (Tags)
Il parametro «tag» è utilizzato nei campi di intestazione To e From dei messaggi SIP. Esso funge da meccanismo generale per identificare i dialoghi, che sono la combinazione della Call-ID e di due tag (uno ciascuno) di ciascun partecipante al dialogo. Quando un UA invia una richiesta fuori dialogo, essa include solo un tag From, fornendo la «metà» dell'identificatore di dialogo. Il dialogo è completato da una risposta, ciascuna fornendo la seconda metà nel campo di intestazione To. Le richieste SIP possono essere biforcate, permettendo di stabilire più dialoghi da una singola richiesta. Ciò spiega anche la necessità di un identificatore di dialogo da entrambi i lati. Senza il contributo del destinatario, il chiamante non può distinguere chiaramente i molteplici dialoghi stabiliti da una singola richiesta.
Quando un tag è generato da un UA per inserimento in una richiesta o risposta, DEVE essere globalmente unico e crittograficamente casuale con almeno 32 bit di entropia. Come conseguenza di questo requisito di scelta, un UA pone un tag nell'intestazione From di un INVITE diverso dal tag che pone nell'intestazione To di una risposta a quello stesso INVITE. Ciò è necessario affinché un UA possa invitare se stesso a una sessione (un caso comune di «hairpinning» in un gateway PSTN). Allo stesso modo, due INVITE per chiamate diverse hanno tag From diversi, e due risposte per chiamate diverse hanno tag To diversi.
Oltre al requisito di unicità globale, l'algoritmo di generazione del tag è specifico dell'implementazione. I tag sono utili nei sistemi tolleranti agli errori in cui il ripristino del dialogo su un server di backup è necessario dopo un guasto. Un UAS può scegliere un tag tale che il server di backup possa riconoscere la richiesta come parte di un dialogo sul server guasto, e quindi decidere di tentare di ripristinare quel dialogo e l'altro stato a esso associato.