Passa al contenuto principale

8. Comportamento generale dell'user agent (General User Agent Behavior)

8 Comportamento generale dell'user agent (General User Agent Behavior)

Un user agent rappresenta un sistema terminale. Esso comprende un user agent client (UAC), che genera richieste, e un user agent server (UAS), che vi risponde. Un UAC è in grado di generare una richiesta sulla base di una stimolazione esterna (l'utente fa clic su un pulsante, o un segnale su una linea PSTN) ed elaborare una risposta. Un UAS è in grado di ricevere una richiesta e generare una risposta basata su un input utente, una stimolazione esterna, il risultato dell'esecuzione di un programma, o un altro meccanismo.

Quando un UAC invia una richiesta, tale richiesta passa attraverso una serie di server proxy, che la inoltrano verso il UAS. Quando il UAS genera una risposta, questa viene inoltrata verso il UAC.

Le procedure UAC e UAS dipendono fortemente da due fattori. In primo luogo, se la richiesta o la risposta è all'interno o all'esterno di un dialog, e in secondo luogo, dal method della richiesta. I dialog sono discussi in dettaglio nella Sezione 12; essi rappresentano una relazione peer-to-peer tra user agent ed sono stabiliti da specifici method SIP, come INVITE.

In questa sezione discutiamo le regole indipendenti dal method per il comportamento UAC e UAS quando si elaborano richieste che sono al di fuori di un dialog. Ciò include, ovviamente, le richieste che stabiliscono esse stesse un dialog.

Le procedure di sicurezza per le richieste e le risposte al di fuori di un dialog sono descritte nella Sezione 26. Specificamente, esistono meccanismi affinché il UAS e il UAC si autentichino reciprocamente. Un insieme limitato di funzionalità di privacy è anch'esso supportato tramite la crittografia dei body tramite S/MIME.

8.1 Comportamento UAC (UAC Behavior)

Questa sezione tratta il comportamento UAC al di fuori di un dialog.

8.1.1 Generazione della richiesta (Generating the Request)

Una richiesta SIP valida formulata da un UAC DEVE, come minimo, contenere i seguenti header field: To, From, CSeq, Call-ID, Max-Forwards e Via; tutti questi header field sono obbligatori in tutte le richieste SIP. Questi sei header field sono i blocchi costruttivi fondamentali di un messaggio SIP, poiché forniscono congiuntamente la maggior parte dei servizi critici di routing dei messaggi, includendo l'indirizzamento dei messaggi, il routing delle risposte, la limitazione della propagazione dei messaggi, l'ordinamento dei messaggi e l'identificazione univoca delle transazioni. Questi header field si aggiungono alla riga di richiesta obbligatoria, che contiene il method, il Request-URI e la versione SIP.

Esempi di richieste inviate al di fuori di un dialog includono un INVITE per stabilire una session (Sezione 13) e un OPTIONS per interrogare le capacità (Sezione 11).

8.1.1.1 Request-URI

Il Request-URI iniziale del messaggio DOVREBBE (SHOULD) essere impostato sul valore dell'URI nel campo To. Un'eccezione notevole è il method REGISTER; il comportamento per impostare il Request-URI di REGISTER è nella Sezione 10. Per ragioni di privacy o di comodità, può anche essere indesiderabile impostare questi campi allo stesso valore (specialmente se il UA origine si aspetta che il Request-URI venga modificato durante il transito).

In alcune circostanze speciali, la presenza di un pre-existing route set (insieme di route preesistente) può influenzare il Request-URI del messaggio. Un pre-existing route set è un insieme ordinato di URI che identificano una catena di server, verso i quali un UAC invierà le richieste in uscita che sono al di fuori di un dialog. Comunemente, essi sono configurati sul UA manualmente da un utente o da un fornitore di servizi, o tramite un altro meccanismo non-SIP. Quando un fornitore desidera configurare un UA con un outbound proxy, si RACCOMANDA (RECOMMENDED) di farlo fornendogli un pre-existing route set con un singolo URI, quello dell'outbound proxy.

Quando è presente un pre-existing route set, DEVONO (MUST) essere seguite le procedure per riempire il Request-URI e il campo Route header dettagliate nella Sezione 12.2.1.1 (anche se non esiste un dialog), utilizzando il Request-URI desiderato come remote target URI.

8.1.1.2 To

Il campo To header indica anzitutto il destinatario "logico" desiderato della richiesta, o l'address-of-record dell'utente o della risorsa che è il target di questa richiesta. Ciò può o non può essere il destinatario finale della richiesta. Il campo To header PUÒ (MAY) contenere un URI SIP o SIPS, ma può anche fare uso di altri scheme di URI (l'URL tel (RFC 2806 [9]), per esempio) quando appropriato. Tutte le implementazioni SIP DEVONO (MUST) supportare lo scheme di URI SIP. Qualsiasi implementazione che supporti TLS DEVE supportare lo scheme di URI SIPS. Il campo To header consente un display name.

Un UAC può apprendere come compilare il campo To header per una richiesta particolare in diversi modi. Generalmente, l'utente suggerirà il campo To header tramite un'interfaccia umana, forse inserendo manualmente l'URI o selezionandolo da una sorta di rubrica. Frequentemente, l'utente non inserirà un URI completo, ma piuttosto una stringa di cifre o lettere (per esempio, "bob"). Sta alla discrezione del UA scegliere come interpretare questo input. Usare la stringa per formare la user part di un URI SIP implica che il UA desideri che il nome sia risolto nel dominio a destra del segno chiocciola (@) nell'URI SIP (per esempio, sip:[email protected]). Usare la stringa per formare la user part di un URI SIPS implica che il UA desideri comunicare in modo sicuro, e che il nome debba essere risolto nel dominio a destra del segno chiocciola. Il lato destro (RHS) sarà frequentemente il home domain del richiedente, il che permette al home domain di trattare la richiesta in uscita. Ciò è utile per funzionalità come la "composezione abbreviata" (speed dial) che richiedono l'interpretazione della user part nel home domain. L'URL tel PUÒ essere usata quando il UA non desidera specificare il dominio che deve interpretare un numero di telefono inserito dall'utente. Piuttosto, ogni dominio attraverso cui passa la richiesta riceve questa opportunità. Per esempio, un utente in un aeroporto potrebbe collegarsi e inviare richieste tramite un outbound proxy nell'aeroporto. Se inseriscono "411" (questo è il numero di telefono per l'assistenza abbonati locale negli Stati Uniti), ciò deve essere interpretato ed elaborato dal outbound proxy dell'aeroporto, non dal home domain dell'utente. In questo caso, tel:411 sarebbe la scelta corretta.

Una richiesta al di fuori di un dialog NON DEVE (MUST NOT) contenere un To tag; il tag nel campo To di una richiesta identifica il peer del dialog. Poiché nessun dialog è stabilito, non è presente alcun tag.

Per maggiori informazioni sul campo To header, vedere la Sezione 20.39. Ecco un esempio di campo To header valido:

  To: Carol `<sip:[email protected]>`

8.1.1.3 From

Il campo From header indica l'identità logica dell'iniziatore della richiesta, possibilmente l'address-of-record dell'utente. Come il campo To header, esso contiene un URI e opzionalmente un display name. È usato dagli elementi SIP per determinare quali regole di elaborazione applicare a una richiesta (per esempio, il rifiuto automatico delle chiamate). Come tale, è molto importante che l'URI From non contenga indirizzi IP o il FQDN dell'host su cui il UA è in esecuzione, poiché questi non sono nomi logici.

Il campo From header consente un display name. Un UAC DOVREBBE (SHOULD) usare il display name "Anonymous", con un URI altrimenti privo di significato ma sintatticamente corretto (come sip:[email protected]), se l'identità del client deve rimanere nascosta.

Generalmente, il valore che compila il campo From header nelle richieste generate da un UA particolare è pre-provisionato dall'utente o dagli amministratori del dominio locale dell'utente. Se un UA particolare è usato da più utenti, potrebbe avere profili commutabili che includono un URI corrispondente all'identità dell'utente profilato. I destinatari delle richieste possono autenticare l'iniziatore di una richiesta per verificare che siano effettivamente coloro che il loro campo From header afferma (vedere la Sezione 22 per i dettagli sull'autenticazione).

Il campo From DEVE (MUST) contenere un nuovo parametro "tag", scelto dal UAC. Vedere la Sezione 19.3 per i dettagli sulla scelta di un tag.

Per maggiori informazioni sul campo From header, vedere la Sezione 20.20. Esempi:

  From: "Bob" `<sips:[email protected]>` ;tag=a48s
  From: sip:[email protected];tag=887s
  From: Anonymous `<sip:[email protected]>`;tag=hyh8

8.1.1.4 Call-ID

Il campo Call-ID header agisce come un identificatore univoco per raggruppare una serie di messaggi. Esso DEVE (MUST) essere lo stesso per tutte le richieste e le risposte inviate da uno qualsiasi dei due UA in un dialog. Esso DOVREBBE (SHOULD) essere lo stesso in ogni registrazione di un UA.

In una nuova richiesta creata da un UAC al di fuori di qualsiasi dialog, il campo Call-ID header DEVE (MUST) essere selezionato dal UAC come un identificatore globalmente univoco nello spazio e nel tempo a meno che non venga sostituito da un comportamento specifico del method. Tutti i UA SIP devono avere un mezzo per garantire che i campi Call-ID che producono non vengano generati per errore da un altro UA. Notare che quando le richieste vengono riprovate dopo alcune risposte di fallimento che richiedono una modifica alla richiesta (per esempio, una challenge di autenticazione), questi nuovi tentativi non sono considerati nuove richieste, e quindi non richiedono nuovi campi Call-ID; vedere la Sezione 8.1.3.5.

L'uso di identificatori crittograficamente casuali (RFC 1750 [12]) nella generazione dei Call-ID è RACCOMANDATO (RECOMMENDED). Le implementazioni POSSONO (MAY) usare la forma "localid@host". I Call-ID sono sensibili alle maiuscole/minuscole e sono semplicemente confrontati byte per byte.

  L'uso di identificatori crittograficamente casuali fornisce una certa protezione contro l' hijacking di sessione e riduce la probabilità di collisioni involontarie di Call-ID.

Nessun provisioning o interfaccia umana è richiesto per la selezione del valore del campo Call-ID header per una richiesta.

Per maggiori informazioni sul campo Call-ID header, vedere la Sezione 20.8.

Esempio:

  Call-ID: [email protected]

8.1.1.5 CSeq

Il campo CSeq header serve a identificare e ordinare le transazioni. Esso consiste in un numero di sequenza e un method. Il method DEVE (MUST) corrispondere a quello della richiesta. Per le richieste non-REGISTER al di fuori di un dialog, il valore del numero di sequenza è arbitrario. Il valore del numero di sequenza DEVE (MUST) essere rappresentabile come un intero senza segno a 32 bit e DEVE essere inferiore a 2**31. Finché segue le linee guida sopra, un client può usare qualsiasi meccanismo per selezionare i valori del campo CSeq header.

La Sezione 12.2.1.1 discute la costruzione del CSeq per le richieste all'interno di un dialog.

Esempio:

  CSeq: 4711 INVITE

8.1.1.6 Max-Forwards

Il campo Max-Forwards header serve a limitare il numero di hop che una richiesta può attraversare lungo il percorso verso la sua destinazione. Esso consiste in un intero che viene decrementato di uno a ogni hop. Se il valore Max-Forwards raggiunge 0 prima che la richiesta raggiunga la sua destinazione, essa sarà rifiutata con una risposta di errore 483 (Too Many Hops).

Un UAC DEVE (MUST) inserire un campo Max-Forwards header in ogni richiesta che emette con un valore che DOVREBBE (SHOULD) essere 70. Questo numero è stato scelto abbastanza grande da garantire che una richiesta non venga scartata in una qualsiasi rete SIP in assenza di loop, ma abbastanza piccolo da non consumare eccessive risorse proxy quando si verifica un loop. Valori più bassi dovrebbero essere usati con cautela e solo nelle reti la cui topologia è nota al UA.

8.1.1.7 Via

Il campo Via header indica il transport usato per la transazione e identifica il luogo in cui la risposta deve essere inviata. Un valore di campo Via header viene aggiunto solo dopo che il transport che sarà usato per raggiungere il prossimo hop è stato selezionato (ciò può comportare l'uso delle procedure di [4]).

Quando il UAC crea una richiesta, DEVE (MUST) inserire un Via in questa richiesta. Il nome del protocollo e la versione del protocollo nel campo header DEVONO (MUST) essere rispettivamente SIP e 2.0. Il valore del campo Via header DEVE (MUST) contenere un parametro branch. Questo parametro è usato per identificare la transazione creata da questa richiesta. Questo parametro è usato sia dal client che dal server.

Il valore del parametro branch DEVE (MUST) essere univoco nello spazio e nel tempo per tutte le richieste inviate dal UA. Le eccezioni a questa regola sono CANCEL e ACK per le risposte non-2xx. Come discusso sotto, una richiesta CANCEL avrà lo stesso valore di parametro branch della richiesta che annulla. Come discusso nella Sezione 17.1.1.3, un ACK per una risposta non-2xx avrà anch'esso lo stesso branch ID dell'INVITE di cui conferma la risposta.

  La proprietà di unicità del parametro branch ID, per facilitarne l'uso come identificatore di transazione, non faceva parte della RFC 2543.

L'identificatore branch inserito da un elemento conforme a questa specifica DEVE (MUST) sempre iniziare con i caratteri "z9hG4bK". Questi 7 caratteri sono usati come un magic cookie (7 è considerato sufficiente per garantire che un'implementazione RFC 2543 più vecchia non sceglierebbe tale valore), in modo che i server riceventi la richiesta possano determinare che l'identificatore branch è stato costruito nel modo descritto da questa specifica (cioè, globalmente univoco). Oltre a questo requisito, il formato esatto del token branch è definito dall'implementazione.

I componenti maddr, ttl e sent-by dell'header Via saranno impostati quando la richiesta viene elaborata dalla livello transport (Sezione 18).

L'elaborazione Via per i proxy è descritta nella Sezione 16.6 Elemento 8 e Sezione 16.7 Elemento 3.

8.1.1.8 Contact

Il campo Contact header fornisce un URI SIP o SIPS che può essere usato per contattare questa specifica istanza del UA per le richieste successive. Il campo Contact header DEVE (MUST) essere presente e contenere esattamente un URI SIP o SIPS in qualsiasi richiesta che possa comportare la creazione di un dialog. Per i method definiti in questa specifica, ciò include solo la richiesta INVITE. Per queste richieste, la portata del Contact è globale. Cioè, il valore del campo Contact header contiene l'URI dove il UA desidera ricevere le richieste, e questo URI DEVE (MUST) essere valido anche se usato in richieste successive al di fuori di un dialog.

Se il Request-URI o il valore del campo Route header superiore contiene un URI SIPS, anche il campo Contact header DEVE (MUST) contenere un URI SIPS.

Per maggiori informazioni sul campo Contact header, vedere la Sezione 20.10.

8.1.1.9 Supported e Require

Se il UAC supporta estensioni a SIP che possono essere applicate dal server alla risposta, il UAC DOVREBBE (SHOULD) includere un campo Supported header nella richiesta che elenca i tag di opzione (Sezione 19.2) per queste estensioni.

I tag di opzione elencati NON DEVONO (MUST NOT) fare riferimento solo a estensioni definite in RFC di standards-track. Ciò è per impedire ai server di insistere affinché i client implementino funzionalità non standard definite dal fornitore per ricevere il servizio. Le estensioni definite da RFC sperimentali e informative sono esplicitamente escluse dall'uso con il campo Supported header in una richiesta, poiché sono anch'esse frequentemente usate per documentare estensioni definite dal fornitore.

Se il UAC desidera insistere affinché un UAS comprenda un'estensione che il UAC applicherà alla richiesta per elaborarla, DEVE (MUST) inserire un campo Require header nella richiesta che elenca il tag di opzione per tale estensione. Se il UAC desidera applicare un'estensione alla richiesta e insistere affinché tutti i proxy attraversati comprendano tale estensione, DEVE (MUST) inserire un campo Proxy-Require header nella richiesta che elenca il tag di opzione per tale estensione.

Come con il campo Supported header, i tag di opzione nei campi Require e Proxy-Require NON DEVONO (MUST NOT) fare riferimento solo a estensioni definite in RFC di standards-track.

8.1.1.10 Componenti di messaggio aggiuntivi (Additional Message Components)

Dopo che una nuova richiesta è stata creata e che gli header field descritti sopra sono stati correttamente costruiti, vengono aggiunti tutti gli header field opzionali aggiuntivi, così come gli header field specifici del method.

Le richieste SIP POSSONO (MAY) contenere un message-body codificato MIME. Indipendentemente dal tipo di body che una richiesta contiene, certi header field devono essere formulati per caratterizzare il contenuto del body. Per maggiori informazioni su questi header field, vedere le Sezioni 20.11 a 20.15.

8.1.2 Invio della richiesta (Sending the Request)

La destinazione della richiesta viene quindi calcolata. Salvo diversa indicazione di una politica locale, la destinazione DEVE (MUST) essere determinata applicando le procedure DNS descritte in [4] come segue. Se il primo elemento nel route set indicava un strict router (risultando nella formazione della richiesta come descritto nella Sezione 12.2.1.1), le procedure DEVONO (MUST) essere applicate al Request-URI della richiesta. Altrimenti, le procedure sono applicate al primo valore del campo Route header nella richiesta (se presente), o al Request-URI della richiesta se non è presente alcun campo Route header. Queste procedure producono un insieme ordinato di indirizzo, porta e transport da provare. Indipendentemente dall'URI usato come input alle procedure in [4], se il Request-URI specifica una risorsa SIPS, il UAC DEVE (MUST) seguire le procedure in [4] come se l'URI di input fosse un URI SIPS.

La politica locale PUÒ (MAY) specificare un insieme alternativo di destinazioni da provare. Se il Request-URI contiene un URI SIPS, qualsiasi destinazione alternativa DEVE (MUST) essere contattata usando TLS. Oltre a ciò, non ci sono restrizioni sulle destinazioni alternative se la richiesta non contiene un campo Route header. Ciò fornisce una semplice alternativa a un pre-existing route set come mezzo per specificare un outbound proxy. Tuttavia, questo approccio per configurare un outbound proxy non è RACCOMANDATO (NOT RECOMMENDED); si DOVREBBE (SHOULD) usare un pre-existing route set con un singolo URI. Se la richiesta contiene un campo Route header, la richiesta DOVREBBE (SHOULD) essere inviata ai luoghi derivati dal suo valore più alto, ma PUÒ (MAY) essere inviata a qualsiasi server di cui il UA è certo che onorerà le politiche Route e Request-URI specificate in questo documento (in contrasto con quelle della RFC 2543). In particolare, un UAC configurato con un outbound proxy DOVREBBE (SHOULD) tentare di inviare la richiesta al luogo indicato nel primo valore del campo Route header invece di adottare la politica di invio di tutti i messaggi all'outbound proxy.

  Ciò garantisce che gli outbound proxy che non aggiungono valori di campo Record-Route si discostino dal percorso delle richieste successive. Permette agli endpoint che non possono risolvere il primo Route URI di delegare tale compito a un outbound proxy.

Il UAC DOVREBBE (SHOULD) seguire le procedure definite in [4] per gli elementi con stato, provando ciascun indirizzo fino a quando un server non viene contattato. Ogni tentativo costituisce una nuova transazione, e pertanto ciascuno porta un valore di campo Via header superiore diverso con un nuovo parametro branch. Inoltre, il valore del transport nel campo Via header è impostato sul transport determinato per il server target.

8.1.3 Elaborazione delle risposte (Processing Responses)

Le risposte sono prima elaborate dalla livello transport e poi passate alla livello transazione. La livello transazione esegue la sua elaborazione e poi passa la risposta al TU. La maggior parte dell'elaborazione delle risposte nel TU è specifica del method. Tuttavia, ci sono alcuni comportamenti generali indipendenti dal method.

8.1.3.1 Errori del livello transazione (Transaction Layer Errors)

In alcuni casi, la risposta restituita dalla livello transazione non sarà un messaggio SIP, ma piuttosto un errore del livello transazione. Quando viene ricevuto un timeout error dalla livello transazione, esso DEVE (MUST) essere trattato come se fosse stato ricevuto un codice di stato 408 (Request Timeout). Se viene riportato un errore di transport fatale dalla livello transport (generalmente, dovuto a errori ICMP fatali in UDP o a fallimenti di connessione in TCP), la condizione DEVE (MUST) essere trattata come un codice di stato 503 (Service Unavailable).

8.1.3.2 Risposte non riconosciute (Unrecognized Responses)

Un UAC DEVE (MUST) trattare qualsiasi risposta finale non riconosciuta come equivalente al codice di risposta x00 di quella classe, e DEVE essere in grado di elaborare il codice di risposta x00 per tutte le classi. Per esempio, se un UAC riceve un codice di risposta non riconosciuto 431, può presumere in sicurezza che ci fosse un problema con la sua richiesta e trattare la risposta come se avesse ricevuto un codice di risposta 400 (Bad Request). Un UAC DEVE (MUST) trattare qualsiasi risposta provvisoria non riconosciuta diversa da 100 come 183 (Session Progress). Un UAC DEVE (MUST) essere in grado di elaborare le risposte 100 e 183.

8.1.3.3 Vias

Se più di un valore di campo Via header è presente in una risposta, il UAC DOVREBBE (SHOULD) scartare il messaggio.

  La presenza di valori di campo Via header aggiuntivi precedenti l'iniziatore della richiesta suggerisce che il messaggio è stato instradato erroneamente o possibilmente corrotto.

8.1.3.4 Elaborazione delle risposte 3xx (Processing 3xx Responses)

Al ricevimento di una risposta di reindirizzamento (per esempio, un codice di stato di risposta 301), i client DOVREBBERO (SHOULD) usare gli URI nel campo Contact header per formulare una o più nuove richieste basate sulla richiesta reindirizzata. Questo processo è simile a quello di un proxy che esegue una ricorsione su una risposta di classe 3xx come dettagliato nelle Sezioni 16.5 e 16.6. Un client inizia con un target set iniziale contenente esattamente un URI, il Request-URI della richiesta originale. Se un client desidera formulare nuove richieste basate su una risposta di classe 3xx a questa richiesta, colloca gli URI da provare nel target set. Fatto salvo i limiti di questa specifica, un client può scegliere quali URI Contact inserire nel target set. Come con la ricorsione di proxy, un client che elabora risposte di classe 3xx NON DEVE (MUST NOT) aggiungere un URI dato al target set più di una volta. Se la richiesta originale aveva un URI SIPS nel Request-URI, il client PUÒ (MAY) scegliere di reindirizzare ricorsivamente verso un URI non-SIPS, ma DOVREBBE (SHOULD) informare l'utente del reindirizzamento verso un URI non sicuro.

  Una nuova richiesta può essa stessa ricevere risposte 3xx contenenti l'URI originale come contact. Due luoghi possono essere configurati per reindirizzarsi a vicenda. Inserire qualsiasi URI dato nel target set una sola volta previene loop di reindirizzamento infiniti.

Man mano che il target set cresce, il client PUÒ (MAY) generare nuove richieste verso gli URI in qualsiasi ordine. Un meccanismo comune è ordinare l'insieme per il valore del parametro "q" del valore del campo Contact header. Le richieste verso gli URI POSSONO (MAY) essere generate in serie o in parallelo. Un approccio è elaborare in serie gruppi di valori q decrescenti ed elaborare in parallelo gli URI in ogni gruppo di valore q. Un altro approccio è eseguire solo l'elaborazione in serie in ordine di valore q decrescente, scegliendo arbitrariamente tra i contact con valore q uguale.

Se contattare un indirizzo nell'elenco fallisce (come definito nel paragrafo seguente), l'elemento passa al successivo indirizzo nell'elenco, finché l'elenco non è esaurito. Se l'elenco è esaurito, allora la richiesta è fallita.

I fallimenti DOVREBBERO (SHOULD) essere rilevati tramite codici di risposta di fallimento (codici superiori a 399); per gli errori di rete, la client transaction riporterà qualsiasi fallimento del livello transport all'user transaction. Notare che alcuni codici di risposta (dettagliati in 8.1.3.5) indicano che la richiesta può essere riprovata; le richieste che vengono ripetute non dovrebbero essere considerate fallimenti.

Al ricevimento di un fallimento per un particolare indirizzo di contact, il client DOVREBBE (SHOULD) provare il successivo indirizzo di contact. Ciò implica la creazione di una nuova client transaction per consegnare una nuova richiesta.

Al fine di creare una richiesta basata su un indirizzo di contact in una risposta 3xx, un UAC DEVE (MUST) copiare l'intero URI dal target set nel Request-URI, ad eccezione dei parametri URI "method-param" e "header" (vedere la Sezione 19.1.1 per una definizione di questi parametri). Esso usa i parametri "header" per creare valori di campo header per la nuova richiesta, sovrascrivendo i valori di campo header associati alla richiesta reindirizzata conformemente alle linee guida della Sezione 19.1.5.

Notare che in alcuni casi, i campi header che sono stati comunicati nell'indirizzo di contact possono invece essere aggiunti ai campi di richiesta header esistenti nella richiesta reindirizzata originale. Come regola generale, se il campo header accetta una lista di valori separati da virgole, allora il nuovo valore di campo header PUÒ (MAY) essere aggiunto a tutti i valori esistenti nella richiesta reindirizzata originale. Se il campo header non accetta valori multipli, il valore nella richiesta reindirizzata originale PUÒ (MAY) essere sovrascritto dal valore di campo header comunicato nell'indirizzo di contact. Per esempio, se un indirizzo di contact viene restituito con il seguente valore:

  sip:user@host?Subject=foo&Call-Info=`\`http://www.foo.com\``

Allora qualsiasi campo Subject header nella richiesta reindirizzata originale è sovrascritto, ma l'URL HTTP è semplicemente aggiunto a tutti i valori di campo Call-Info header esistenti.

È RACCOMANDATO che il UAC riutilizzi lo stesso To, From e Call-ID usati nella richiesta reindirizzata originale, ma il UAC PUÒ (MAY) anche scegliere di aggiornare il valore del campo Call-ID header per le nuove richieste, per esempio.

Infine, una volta costruita la nuova richiesta, essa viene inviata usando una nuova client transaction, e pertanto DEVE (MUST) avere un nuovo branch ID nel campo Via superiore come discusso nella Sezione 8.1.1.7.

A tutti gli altri riguardi, le richieste inviate al ricevimento di una risposta di reindirizzamento DOVREBBERO (SHOULD) riutilizzare i campi header e i body della richiesta originale.

In alcuni casi, i valori del campo Contact header possono essere memorizzati nella cache dal UAC temporaneamente o permanentemente a seconda del codice di stato ricevuto e della presenza di un intervallo di scadenza; vedere le Sezioni 21.3.2 e 21.3.3.

8.1.3.5 Elaborazione delle risposte 4xx (Processing 4xx Responses)

Alcuni codici di risposta 4xx richiedono una specifica elaborazione UA indipendente dal method.

Se viene ricevuta una risposta 401 (Unauthorized) o 407 (Proxy Authentication Required), il UAC DOVREBBE (SHOULD) seguire le procedure di autenticazione delle Sezioni 22.2 e 22.3 per riprovare la richiesta con le credenziali.

Se viene ricevuta una risposta 413 (Request Entity Too Large) (Sezione 21.4.11), la richiesta conteneva un body più lungo di quanto il UAS fosse disposto ad accettare. Se possibile, il UAC DOVREBBE (SHOULD) riprovare la richiesta, omettendo il body o usando un body di lunghezza minore.

Se viene ricevuta una risposta 415 (Unsupported Media Type) (Sezione 21.4.13), la richiesta conteneva tipi di media non supportati dal UAS. Il UAC DOVREBBE (SHOULD) riprovare l'invio della richiesta, questa volta usando solo contenuto con i tipi elencati nel campo Accept header della risposta, con le codifiche elencate nel campo Accept-Encoding header della risposta, e con le lingue elencate nell'Accept-Language della risposta.

Se viene ricevuta una risposta 416 (Unsupported URI Scheme) (Sezione 21.4.14), il Request-URI usava uno scheme di URI non supportato dal server. Il client DOVREBBE (SHOULD) riprovare la richiesta, questa volta usando un URI SIP.

Se viene ricevuta una risposta 420 (Bad Extension) (Sezione 21.4.15), la richiesta conteneva un campo Require o Proxy-Require che elencava un tag di opzione per una funzionalità non supportata da un proxy o UAS. Il UAC DOVREBBE (SHOULD) riprovare la richiesta, questa volta omettendo tutte le estensioni elencate nel campo Unsupported header della risposta.

In tutti i casi sopra, la richiesta viene riprovata creando una nuova richiesta con le modifiche appropriate. Questa nuova richiesta costituisce una nuova transazione e DOVREBBE (SHOULD) avere lo stesso valore di Call-ID, To e From della richiesta precedente, ma il CSeq deve contenere un nuovo numero di sequenza superiore di uno al precedente.

Con altre risposte 4xx, incluse quelle ancora da definire, un nuovo tentativo può o non può essere possibile a seconda del method e del caso d'uso.

8.2 Comportamento UAS (UAS Behavior)

Quando un UAS elabora una richiesta al di fuori di un dialog, esso segue un insieme di regole di elaborazione indipendenti dal method. La Sezione 12 fornisce indicazioni su come un UAS possa dire se una richiesta è all'interno o all'esterno di un dialog.

Notare che l'elaborazione della richiesta è atomica. Se una richiesta viene accettata, tutti i cambiamenti di stato a essa associati DEVONO (MUST) essere eseguiti. Se viene rifiutata, nessun cambiamento di stato DEVE (MUST NOT) essere eseguito.

I UAS DOVREBBERO (SHOULD) elaborare le richieste nell'ordine dei passi che seguono in questa sezione (cioè, iniziando con l'autenticazione, poi ispezionando il method, i campi header, e così via per il resto di questa sezione).

8.2.1 Ispezione del metodo (Method Inspection)

Una volta che una richiesta è autenticata (o l'autenticazione è saltata), il UAS DEVE (MUST) ispezionare il method della richiesta. Se il UAS riconosce ma non supporta il method di una richiesta, DEVE (MUST) generare una risposta 405 (Method Not Allowed). Le procedure per generare risposte sono descritte nella Sezione 8.2.6. Il UAS DEVE (MUST) anche aggiungere un campo Allow header alla risposta 405 (Method Not Allowed). Il campo Allow header DEVE (MUST) elencare l'insieme dei method supportati dal UAS che genera il messaggio. Il campo Allow header è presentato nella Sezione 20.5.

Se il method è quello supportato dal server, l'elaborazione continua.

8.2.2 Ispezione dell'intestazione (Header Inspection)

Se un UAS non comprende un campo header in una richiesta (cioè, il campo header non è definito in questa specifica o in un'estensione supportata), il server DEVE (MUST) ignorare questo campo header e continuare l'elaborazione del messaggio. Un UAS DOVREBBE (SHOULD) ignorare qualsiasi campo header mal formato non necessario all'elaborazione delle richieste.

8.2.2.1 To e Request-URI

Il campo To header identifica il destinatario originale della richiesta designato dall'utente identificato nel campo From. Il destinatario originale può o non può essere il UAS che elabora la richiesta, a causa di un inoltro di chiamata o di altre operazioni proxy. Un UAS PUÒ (MAY) applicare qualsiasi politica desideri per determinare se accetta le richieste quando il campo To header non è l'identità del UAS. Tuttavia, è RACCOMANDATO che un UAS accetti le richieste anche se non riconosce lo scheme di URI (per esempio, un URI tel:) nel campo To header, o se il campo To header non è indirizzato a un utente noto o attuale di questo UAS. Se, d'altra parte, il UAS decide di rifiutare la richiesta, DOVREBBE (SHOULD) generare una risposta con codice di stato 403 (Forbidden) e passarla alla server transaction per la trasmissione.

Tuttavia, il Request-URI identifica il UAS che deve elaborare la richiesta. Se il Request-URI usa uno scheme non supportato dal UAS, DOVREBBE (SHOULD) rifiutare la richiesta con una risposta 416 (Unsupported URI Scheme). Se il Request-URI non identifica un indirizzo per cui il UAS è disposto ad accettare le richieste, DOVREBBE (SHOULD) rifiutare la richiesta con una risposta 404 (Not Found). Tipicamente, un UA che usa il method REGISTER per legare il suo address-of-record a un indirizzo di contact specifico vedrà richieste il cui Request-URI è uguale a tale indirizzo di contact. Altre fonti potenziali di Request-URI ricevuti includono i campi Contact header delle richieste e delle risposte inviate dal UA che stabiliscono o aggiornano i dialog.

8.2.2.2 Richieste unite (Merged Requests)

Se la richiesta non ha alcun tag nel campo To header, il UAS core DEVE (MUST) verificare la richiesta rispetto alle transazioni in corso. Se From tag, Call-ID e CSeq corrispondono esattamente a quelli associati a una transazione in corso, ma la richiesta non corrisponde a tale transazione (basato sulle regole di corrispondenza della Sezione 17.2.3), il UAS core DOVREBBE (SHOULD) generare una risposta 482 (Loop Detected) e passarla alla server transaction.

  La stessa richiesta è arrivata al UAS più di una volta, seguendo percorsi probabilmente diversi, molto probabilmente a causa di un forking. Il UAS elabora la prima di queste richieste ricevute e risponde 482 (Loop Detected) al resto di esse.

8.2.2.3 Require

Nell'ipotesi che il UAS decida di essere l'elemento appropriato per elaborare la richiesta, esamina il campo Require header, se presente.

Il campo Require header è usato da un UAC per indicare a un UAS le estensioni SIP che il UAC si aspetta che il UAS supporti per elaborare correttamente la richiesta. Il suo formato è descritto nella Sezione 20.32. Se un UAS non comprende un tag di opzione elencato in un campo Require header, DEVE (MUST) rispondere generando una risposta con codice di stato 420 (Bad Extension). Il UAS DEVE (MUST) aggiungere un campo Unsupported header, e elencare in esso le opzioni che non comprende tra quelle del campo Require header della richiesta.

Notare che Require e Proxy-Require NON DEVONO (MUST NOT) essere usati in una richiesta SIP CANCEL, o in una richiesta ACK inviata per una risposta non-2xx. Questi campi header DEVONO (MUST) essere ignorati se presenti in queste richieste.

Una richiesta ACK per una risposta 2xx NON DEVE (MUST) contenere che i valori Require e Proxy-Require presenti nella richiesta iniziale.

Esempio:

  UAC->UAS:   INVITE sip:[email protected] SIP/2.0
              Require: 100rel

  UAS->UAC:   SIP/2.0 420 Bad Extension
              Unsupported: 100rel

  Questo comportamento garantisce che l'interazione client-server proceda senza ritardo quando tutte le opzioni sono comprese da entrambi i lati, e rallenti solo se le opzioni non sono comprese (come nell'esempio sopra). Per una coppia client-server ben accoppiata, l'interazione procede rapidamente, risparmiando l'andirivieni spesso richiesto dai meccanismi di negoziazione. Inoltre, elimina l'ambiguità quando il client richiede funzionalità che il server non comprende. Alcune funzionalità (come i campi di gestione delle chiamate) interessano solo i sistemi terminali.

8.2.3 Elaborazione del contenuto (Content Processing)

Nell'ipotesi che il UAS comprenda tutte le estensioni richieste dal client, il UAS esamina il body del messaggio e i campi header che lo descrivono. Se ci sono body il cui tipo (indicato dal Content-Type), lingua (indicata dal Content-Language) o codifica (indicata dal Content-Encoding) non sono compresi, e quella parte di body non è opzionale (come indicato dal campo Content-Disposition header), il UAS DEVE (MUST) rifiutare la richiesta con una risposta 415 (Unsupported Media Type). La risposta DEVE (MUST) contenere un campo Accept header che elenca i tipi di tutti i body che comprende, nel caso in cui la richiesta contenesse body di tipi non supportati dal UAS. Se la richiesta conteneva codifiche di contenuto non comprese dal UAS, la risposta DEVE (MUST) contenere un campo Accept-Encoding header che elenca le codifiche comprese dal UAS. Se la richiesta conteneva contenuto in lingue non comprese dal UAS, la risposta DEVE (MUST) contenere un campo Accept-Language header che indica le lingue comprese dal UAS. Oltre a questi controlli, l'elaborazione del body dipende dal method e dal tipo. Per maggiori informazioni sull'elaborazione dei campi header specifici del contenuto, vedere la Sezione 7.4 nonché le Sezioni 20.11 a 20.15.

8.2.4 Applicazione delle estensioni (Applying Extensions)

Un UAS che desidera applicare un'estensione nella generazione della risposta NON DEVE (MUST NOT) farlo a meno che il supporto di tale estensione non sia indicato nel campo Supported header della richiesta. Se l'estensione desiderata non è supportata, il server DOVREBBE (SHOULD) fare affidamento solo sul SIP di base e su qualsiasi altra estensione supportata dal client. In rare circostanze, in cui il server non può elaborare la richiesta senza l'estensione, il server PUÒ (MAY) inviare una risposta 421 (Extension Required). Questa risposta indica che la risposta appropriata non può essere generata senza il supporto di un'estensione specifica. L'estensione(i) necessaria(e) DEVE (MUST) essere inclusa in un campo Require header nella risposta. Questo comportamento non è RACCOMANDATO (NOT RECOMMENDED), poiché generalmente rompe l'interoperabilità.

Tutte le estensioni applicate a una risposta non-421 DEVONO (MUST) essere elencate in un campo Require header incluso nella risposta. Certamente, il server NON DEVE (MUST NOT) applicare estensioni non elencate nel campo Supported header della richiesta. Di conseguenza, il campo Require header in una risposta conterrà solo tag di opzione definiti in RFC di standards-track.

8.2.5 Elaborazione della richiesta (Processing the Request)

Nell'ipotesi che tutti i controlli delle sotto-sezioni precedenti siano superati, l'elaborazione UAS diventa specifica del method. La Sezione 10 tratta la richiesta REGISTER, la Sezione 11 tratta la richiesta OPTIONS, la Sezione 13 tratta la richiesta INVITE, e la Sezione 15 tratta la richiesta BYE.

8.2.6 Generazione della risposta (Generating the Response)

Quando un UAS desidera costruire una risposta a una richiesta, segue le procedure generali dettagliate nelle sotto-sezioni seguenti. Comportamenti aggiuntivi specifici del codice di risposta in questione, che non sono dettagliati in questa sezione, possono anch'essi essere richiesti.

Una volta completate tutte le procedure associate alla creazione di una risposta, il UAS restituisce la risposta alla server transaction da cui ha ricevuto la richiesta.

8.2.6.1 Invio di una risposta provvisoria (Sending a Provisional Response)

Una direttiva ampiamente indipendente dal method per la generazione di risposte è che i UAS NON DOVREBBERO (SHOULD NOT) emettere una risposta provvisoria per una richiesta non-INVITE. Piuttosto, i UAS DOVREBBERO (SHOULD) generare una risposta finale a una richiesta non-INVITE il prima possibile.

Quando viene generata una risposta 100 (Trying), qualsiasi campo Timestamp header presente nella richiesta DEVE (MUST) essere copiato in questa risposta 100 (Trying). Se c'è un ritardo nella generazione della risposta, il UAS DOVREBBE (SHOULD) aggiungere un valore di ritardo nel valore Timestamp della risposta. Questo valore DEVE (MUST) contenere la differenza tra il tempo di invio della risposta e la ricezione della richiesta, misurata in secondi.

8.2.6.2 Intestazioni e tag (Headers and Tags)

Il campo From della risposta DEVE (MUST) essere uguale al campo From header della richiesta. Il campo Call-ID header della risposta DEVE (MUST) essere uguale al campo Call-ID header della richiesta. Il campo CSeq header della risposta DEVE (MUST) essere uguale al campo CSeq della richiesta. I valori del campo Via header nella risposta DEVONO (MUST) essere uguali ai valori del campo Via header nella richiesta e DEVONO mantenere lo stesso ordine.

Se una richiesta conteneva un To tag nella richiesta, il campo To header nella risposta DEVE (MUST) essere uguale a quello della richiesta. Tuttavia, se il campo To header nella richiesta non conteneva alcun tag, l'URI nel campo To header nella risposta DEVE (MUST) essere uguale all'URI nel campo To header; inoltre, il UAS DEVE (MUST) aggiungere un tag al campo To header nella risposta (ad eccezione della risposta 100 (Trying), in cui un tag PUÒ (MAY) essere presente). Ciò serve a identificare il UAS che risponde, risultando possibilmente in un componente di un ID di dialog. Lo stesso tag DEVE (MUST) essere usato per tutte le risposte a questa richiesta, sia finali che provvisorie (ancora una volta ad eccezione del 100 (Trying)). Le procedure per la generazione di tag sono definite nella Sezione 19.3.

8.2.7 Comportamento UAS senza stato (Stateless UAS Behavior)

Un stateless UAS è un UAS che non mantiene lo stato di transazione. Esso risponde normalmente alle richieste, ma scarta qualsiasi stato che sarebbe normalmente trattenuto da un UAS dopo l'invio di una risposta. Se uno stateless UAS riceve una ritrasmissione di una richiesta, rigenera la risposta e la ritrasmette, come se stesse rispondendo alla prima istanza della richiesta. Un UAS può essere senza stato solo se l'elaborazione della richiesta per quel method produce sempre la stessa risposta se le richieste sono identiche. Ciò esclude, per esempio, i registrar senza stato. Gli stateless UAS non usano la livello transazione; essi ricevono le richieste direttamente dalla livello transport e inviano le risposte direttamente alla livello transport.

Il ruolo dello stateless UAS è principalmente necessario per elaborare le richieste non autenticate per le quali viene emessa una risposta di challenge. Se le richieste non autenticate fossero elaborate con stato, allora inondazioni maliziose di richieste non autenticate potrebbero creare enormi quantità di stato di transazione che potrebbero rallentare o fermare completamente l'elaborazione delle chiamate in un UAS, creando effettivamente una condizione di denial of service; vedere la Sezione 26.1.5 per i dettagli.

I comportamenti più importanti di uno stateless UAS sono i seguenti:

  o  Uno stateless UAS NON DEVE (MUST NOT) inviare risposte provvisorie (1xx).

  o  Uno stateless UAS NON DEVE (MUST NOT) ritrasmettere risposte.

  o  Uno stateless UAS DEVE (MUST) ignorare le richieste ACK.

  o  Uno stateless UAS DEVE (MUST) ignorare le richieste CANCEL.

  o  I To header tag DEVONO (MUST) essere generati in modo senza stato - in un modo che genererà lo stesso tag per la stessa richiesta in modo coerente. Per la costruzione di tag vedere la Sezione 19.3.

A tutti gli altri riguardi, uno stateless UAS si comporta esattamente come un stateful UAS. Un UAS può operare in modalità con o senza stato per ogni nuova richiesta.

8.3 Server di reindirizzamento (Redirect Server)

In alcune architetture, può essere desiderabile ridurre il carico di elaborazione sui server proxy responsabili del routing delle richieste e migliorare la robustezza del percorso di segnalazione, facendo affidamento sul reindirizzamento.

Il reindirizzamento consente ai server di respingere le informazioni di routing per una richiesta in una risposta al client, sottraendosi così dal loop di messaggistica aggiuntivo per questa transazione mentre continuano ad aiutare a localizzare il target della richiesta. Quando l'iniziatore della richiesta riceve il reindirizzamento, invierà una nuova richiesta basata sull'URI (o sugli URI) ricevuto. Propagando gli URI dal cuore della rete ai suoi bordi, il reindirizzamento consente una considerevole scalabilità di rete.

Un redirect server è costituito logicamente da una server transaction layer e da un transaction user che ha accesso a un qualche tipo di location service (vedere la Sezione 10 per maggiori informazioni su registrar e location service). Questo location service è effettivamente un database contenente mappature tra un singolo URI e un insieme di uno o più luoghi alternativi dove il target di quel URI può essere trovato.

Un redirect server non emette alcuna richiesta SIP propria. Dopo aver ricevuto una richiesta diversa da CANCEL, il server rifiuta la richiesta o raccoglie l'elenco dei luoghi alternativi dal location service e restituisce una risposta finale di classe 3xx. Per le richieste CANCEL ben formate, DOVREBBE (SHOULD) restituire una risposta 2xx. Questa risposta termina la transazione SIP. Il redirect server mantiene lo stato di transazione per un'intera transazione SIP. È responsabilità dei client rilevare i loop di inoltro tra i redirect server.

Quando un redirect server restituisce una risposta 3xx a una richiesta, inserisce l'elenco dei luoghi alternativi (uno o più) nel campo Contact header. Un parametro "expires" per i valori del campo Contact header PUÒ (MAY) anche essere fornito per indicare la durata dei dati Contact.

Il campo Contact header contiene URI che danno i nuovi luoghi o nomi utente da provare, o può semplicemente specificare parametri di transport aggiuntivi. Una risposta 301 (Moved Permanently) o 302 (Moved Temporarily) PUÒ (MAY) anche dare lo stesso luogo e nome utente target dalla richiesta iniziale ma specificare parametri di transport aggiuntivi come un server diverso o un indirizzo multicast da provare, o un cambiamento del transport SIP da UDP a TCP (o viceversa).

Tuttavia, i redirect server NON DEVONO (MUST NOT) reindirizzare una richiesta a un URI uguale a quello nel Request-URI; invece, a condizione che l'URI non punti a se stesso, il server PUÒ (MAY) proxare la richiesta all'URI di destinazione, o PUÒ (MAY) rifiutarla con un 404.

  Se un client usa un outbound proxy, e quel proxy reindirizza effettivamente le richieste, sorge un potenziale di loop di reindirizzamento infiniti.

Notare che un valore di campo Contact header PUÒ (MAY) anche riferirsi a una risorsa diversa da quella inizialmente chiamata. Per esempio, una chiamata SIP connessa a un gateway PSTN può dover consegnare un annuncio informativo speciale come "The number you have dialed has been changed".

Un campo Contact header di risposta può contenere qualsiasi URI appropriato che indichi dove la parte chiamata può essere raggiunta, non limitato agli URI SIP. Per esempio, può contenere URI per telefono, fax o irc (se definiti) o un URL mailto: (RFC 2368 [32]). La Sezione 26.4.4 discute le implicazioni e le limitazioni del reindirizzamento di un URI SIPS a un URI non-SIPS.

Il parametro "expires" di un valore di campo Contact header indica per quanto tempo l'URI è valido. Il valore del parametro è un numero che indica secondi. Se questo parametro non viene fornito, il valore del campo Expires header determina per quanto tempo l'URI è valido. I valori mal formati DOVREBBERO (SHOULD) essere trattati come equivalenti a 3600.

  Ciò fornisce un moderato livello di compatibilità con la RFC 2543, che consentiva ore assolute in questo campo header. Se viene ricevuta un'ora assoluta, essa sarà trattata come mal formata, poi per impostazione predefinita a 3600.

I redirect server DEVONO (MUST) ignorare le funzionalità non comprese (inclusi campi header non riconosciuti, tag di opzione sconosciuti in Require, o anche nomi di method) e procedere con il reindirizzamento della richiesta in questione.