20. Campi di intestazione (Header Fields)
20 Campi di intestazione
La sintassi generale dei campi di intestazione è trattata nella sezione 7.3. Questa sezione elenca l'insieme completo dei campi di intestazione con annotazioni sulla sintassi, sulla semantica e sull'utilizzo. In questa sezione, [HX.Y] è usato per fare riferimento alla sezione X.Y della specifica HTTP/1.1 corrente, RFC 2616 [8]. Sono presentati esempi di ciascun campo di intestazione.
Le informazioni sui campi di intestazione relative ai metodi e all'elaborazione del proxy sono riepilogate nelle tabelle 2 e 3.
La colonna «where» descrive i tipi di richieste e risposte in cui il campo di intestazione può apparire. I valori di questa colonna sono i seguenti:
R: Il campo di intestazione può apparire solo nelle richieste.
r: Il campo di intestazione può apparire solo nelle risposte.
2xx, 4xx, ecc.: Un numero o un intervallo indica il codice di risposta in cui il campo di intestazione può essere utilizzato.
c: Il campo di intestazione è copiato dalla richiesta alla risposta.
Se la colonna «where» è vuota, ciò indica che il campo di intestazione può essere presente in tutte le richieste e risposte.
La colonna «proxy» descrive le operazioni che un proxy può eseguire sul campo di intestazione.
a: Un proxy può aggiungere o concatenare il campo di intestazione se assente.
m: Un proxy può modificare un valore di campo di intestazione esistente.
d: Un proxy può rimuovere il valore del campo di intestazione.
r: Un proxy deve essere in grado di leggere il campo di intestazione, quindi questo campo di intestazione non può essere crittografato.
Le sei colonne seguenti riguardano la presenza del campo di intestazione nei metodi.
c: Condizionale. Il requisito per il campo di intestazione dipende dal contesto del messaggio.
m: Il campo di intestazione è obbligatorio.
m*: Il campo di intestazione è consigliato (SHOULD) che sia inviato, ma il client/server deve essere pronto a ricevere un messaggio senza questo campo di intestazione.
o: Il campo di intestazione è opzionale.
t: Il campo di intestazione è consigliato (SHOULD) che sia inviato, ma il client/server deve essere pronto a ricevere un messaggio senza questo campo di intestazione.
Quando un protocollo basato su flusso (come TCP) è usato come trasporto, il campo di intestazione deve essere inviato.
*: Il campo di intestazione è obbligatorio se il corpo del messaggio non è vuoto. Vedi sezioni 20.14, 20.15 e 7.4 per maggiori dettagli.
-: Il campo di intestazione non è applicabile.
«Opzionale» significa che un elemento PUÒ includere il campo di intestazione in una richiesta o risposta, e che un UA PUÒ ignorare il campo di intestazione se presente in una richiesta o risposta (fatta eccezione per il campo di intestazione Require discusso nella sezione 20.32). Un campo di intestazione «obbligatorio» deve essere presente in una richiesta e deve essere compreso dal UAS che riceve la richiesta. Un campo di intestazione di risposta «obbligatorio» deve essere presente nella risposta e il campo di intestazione deve essere compreso dal UAC che elabora la risposta. «Non applicabile» significa che il campo di intestazione NON DEVE essere presente in una richiesta. Se posto erroneamente in una richiesta, deve essere ignorato dal UAS che riceve la richiesta. Allo stesso modo, un campo di intestazione etichettato «non applicabile» per una risposta significa che il UAS non deve inserire il campo di intestazione nella risposta, e che il UAC deve ignorare il campo di intestazione nella risposta.
Un UA dovrebbe ignorare i parametri di estensione del campo di intestazione che non comprende.
Alcune abbreviazioni di alcuni nomi di campi di intestazione comuni sono definite anche per l'uso quando la dimensione complessiva del messaggio è un problema.
I campi di intestazione Contact, From e To contengono URI. Se un URI contiene una virgola, un punto interrogativo o un punto e virgola, l'URI deve essere racchiuso tra parentesi angolari («<» e «>»). I parametri URI sono inclusi all'interno di queste parentesi. Se l'URI non è racchiuso tra parentesi angolari, i parametri separati da punto e virgola sono parametri di intestazione, non parametri URI.
20.1 Accept
Il campo di intestazione Accept segue la sintassi definita in [H14.1]. La semantica è anch'essa identica, con l'eccezione che se il campo di intestazione Accept è assente, il server dovrebbe assumere il valore predefinito application/sdp.
Un campo di intestazione Accept vuoto significa che non è accettato alcun formato.
Esempio:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
Authentication-Info 2xx - o - o o o
Authorization R o o o o o o
Call-ID c r m m m m m m
Call-Info ar - - - o o o
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
Content-Disposition o o - o o o
Content-Encoding o o - o o o
Content-Language o o - o o o
Content-Length ar t t t t t t
Content-Type * * - * * *
CSeq c r m m m m m m
Date a o o o o o o
Error-Info 300-699 a - o o o o o
Expires - - - o - o
From c r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R amr m m m m m m
Min-Expires 423 - - - - - m
MIME-Version o o - o o o
Organization ar - - - o o o
Tabella 2: Riepilogo dei campi di intestazione, A–O
Header field where proxy ACK BYE CAN INV OPT REG
Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o
Tabella 3: Riepilogo dei campi di intestazione, P–Z; (1): copiato con possibile aggiunta di tag
Accept: application/sdp;level=1, application/x-private, text/html
20.2 Accept-Encoding
Il campo di intestazione Accept-Encoding è simile ad Accept, ma si limita ai content-coding [H3.5] accettabili nella risposta. Vedi [H14.3]. La semantica in SIP è identica a quella definita in [H14.3].
Un campo di intestazione Accept-Encoding vuoto è consentito. Esso è equivalente a Accept-Encoding: identity, cioè solo il coding identity, che significa senza codifica, è consentito.
Se il campo di intestazione Accept-Encoding è assente, il server dovrebbe assumere il valore predefinito identity.
Ciò differisce leggermente dalla definizione HTTP. La definizione HTTP indica che se è assente, qualsiasi coding può essere utilizzato, ma il coding identity è preferito.
Esempio:
Accept-Encoding: gzip
20.3 Accept-Language
Il campo di intestazione Accept-Language è usato in una richiesta per indicare la lingua preferita per la frase di motivo trasportata nel corpo del messaggio della risposta, la descrizione di sessione o la risposta di stato. Se il campo di intestazione Accept-Language è assente, il server dovrebbe assumere che tutte le lingue siano accettabili dal client.
Il campo di intestazione Accept-Language segue la sintassi definita in [H14.4]. Le regole di ordinamento delle lingue basate sul parametro «q» si applicano anche a SIP.
Esempio:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
20.4 Alert-Info
Quando presente in una richiesta INVITE, il campo di intestazione Alert-Info specifica una suoneria alternativa per il UAS. Quando presente in una risposta 180 (Ringing), il campo di intestazione Alert-Info specifica una suoneria alternativa per il UAC. L'uso tipico consiste in un proxy che inserisce questo campo di intestazione per fornire una funzionalità di suoneria distintiva.
Il campo di intestazione Alert-Info può presentare un rischio di sicurezza. Questi rischi e il loro trattamento sono discussi nella sezione 20.9 che tratta il campo di intestazione Call-Info, poiché i rischi sono identici.
Inoltre, l'utente dovrebbe essere in grado di disabilitare questa funzionalità in modo selettivo.
Ciò aiuta a prevenire confusione che può derivare dall'uso di questo campo di intestazione da parte di un elemento non affidabile.
Esempio:
Alert-Info: <http://www.example.com/sounds/moo.wav>
20.5 Allow
Il campo di intestazione Allow enumera l'insieme dei metodi supportati dal UA che genera il messaggio.
Tutti i metodi compresi dal UA (inclusi ACK e CANCEL) devono essere inclusi nell'elenco dei metodi del campo di intestazione Allow, se presente. L'assenza del campo di intestazione Allow non deve essere interpretata come significato che il UA che invia il messaggio non supporta alcun metodo. Piuttosto, significa che non fornisce alcuna informazione sui metodi supportati dal UA.
L'inclusione del campo di intestazione Allow in una risposta a un metodo diverso da OPTIONS riduce il numero di messaggi necessari.
Esempio:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
20.6 Authentication-Info
Il campo di intestazione Authentication-Info fornisce autenticazione reciproca tramite HTTP Digest. Un UAS può includere questo campo di intestazione in una risposta 2xx a una richiesta autenticata con successo tramite digest basato sul campo di intestazione Authorization.
La sintassi e la semantica seguono quelle specificate nella RFC 2617 [17].
Esempio:
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
20.7 Authorization
Il campo di intestazione Authorization contiene le credenziali di autenticazione del UA. Un riepilogo dell'uso del campo di intestazione Authorization è nella sezione 22.2, e la sintassi e la semantica quando usato per l'autenticazione HTTP sono descritte nella sezione 22.4.
Questo campo di intestazione, insieme a Proxy-Authorization, infrange le regole generali riguardanti i campi di intestazione multipli. Non è un elenco separato da virgole, ma questo nome di campo di intestazione può apparire più volte e non deve essere fuso in una singola riga di intestazione usando le regole usuali descritte nella sezione 7.3.
Nel seguente esempio, non ci sono virgolette attorno ai parametri Digest.
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
20.8 Call-ID
Il campo di intestazione Call-ID identifica in modo univoco un invito particolare o tutte le registrazioni di un client particolare. Una singola conferenza multimediale può, ad esempio, se un utente invita più volte una singola persona alla stessa conferenza (di lunga durata), produrre diversi inviti con Call-ID diversi. Il Call-ID distingue tra maiuscole e minuscole ed è semplicemente confrontato byte per byte.
L'abbreviazione del campo di intestazione Call-ID è i.
Esempio:
Call-ID: [email protected]
i:[email protected]
20.9 Call-Info
Il campo di intestazione Call-Info fornisce informazioni aggiuntive sul chiamante o sul chiamato, a seconda che si tratti di una richiesta o di una risposta. Lo scopo dell'URI è descritto dal parametro «purpose». Il parametro «icon» specifica un'immagine appropriata come rappresentazione iconica del chiamante o del chiamato. Il parametro «info» descrive il chiamante o il chiamato in generale, ad esempio tramite una pagina web. Il parametro «card» fornisce un biglietto da visita, ad esempio in formato vCard [36] o LDIF [37]. Token aggiuntivi possono essere registrati usando l'IANA e le procedure della sezione 27.
L'uso del campo di intestazione Call-Info può presentare un rischio di sicurezza. Se l'utente recupera un URI fornito da un chiamante malintenzionato, può essere esposto a rischi quali contenuti inappropriati o offensivi, contenuti pericolosi o illegali. Pertanto, un UA non dovrebbe mostrare le informazioni del campo di intestazione Call-Info a meno che non possa autenticare la provenienza dell'elemento che ha emesso il campo di intestazione e non si fidi di esso. Ciò non deve essere il UA peer. Un proxy può inserire questo campo di intestazione in una richiesta.
Esempio:
Call-Info: http://wwww.example.com/alice/photo.jpg ;purpose=icon, http://www.example.com/alice/ ;purpose=info
20.10 Contact
Il valore del campo di intestazione Contact fornisce un URI il cui significato dipende dal tipo di richiesta o risposta in cui è incluso.
Un valore del campo di intestazione Contact può includere un nome visualizzato, un URI con parametri URI e parametri di intestazione.
Questo documento definisce i parametri Contact «q» ed «expires». Questi parametri sono usati solo quando Contact è presente in una richiesta o risposta REGISTER, o in una risposta 3xx. Parametri aggiuntivi possono essere definiti in altre specifiche.
Se il valore del campo di intestazione contiene un nome visualizzato, l'URI inclusi tutti i parametri URI è racchiuso tra «<» e «>». In assenza di «<» e «>», tutti i parametri dopo l'URI sono parametri di intestazione, non parametri URI. Il nome visualizzato può essere un token, o una stringa tra virgolette se è desiderato un set di caratteri più ampio.
Se il «display-name» è vuoto, la forma «name-addr» deve essere usata se l'«addr-spec» contiene una virgola, un punto interrogativo o un punto e virgola. Può esserci o non esserci un LWS tra il nome visualizzato e «<».
Queste regole per l'analisi del nome visualizzato, dell'URI, dei parametri URI e dei parametri di intestazione si applicano anche ai campi di intestazione To e From.
Il campo di intestazione Contact ha un ruolo simile al campo di intestazione Location di HTTP. Tuttavia, il campo di intestazione HTTP consente solo un singolo indirizzo senza virgolette. Gli URI possono contenere virgole e punti e virgola come caratteri riservati, e potrebbero essere confusi rispettivamente con il separatore di intestazione o di parametro.
L'abbreviazione del campo di intestazione Contact è m (per «moved»).
Esempio:
Contact: "Mr. Watson" <sip:[email protected]>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:[email protected]> ;q=0.1
m: <sips:[email protected]>;expires=60
20.11 Content-Disposition
Il campo di intestazione Content-Disposition descrive come il corpo del messaggio, o nel caso di un messaggio multiparte la parte del corpo del messaggio, deve essere interpretato dal UAC o UAS. Questo intestazione SIP estende il Content-Type MIME (RFC 2183 [18]).
Diversi nuovi «disposition-type» dell'intestazione Content-Disposition sono definiti da SIP. Il valore «session» indica che la parte del corpo descrive una sessione, sia per la chiamata sia per i media iniziali (prima della chiamata). Il valore «render» indica che la parte del corpo deve essere mostrata all'utente o altrimenti resa. Il valore «render» è usato invece di «inline» per evitare l'implicazione che il corpo MIME sia mostrato come parte del rendering dell'intero messaggio (poiché il corpo MIME di un messaggio SIP spesso non è mostrato all'utente). Per compatibilità con le versioni precedenti, se il campo di intestazione Content-Disposition è assente, un server dovrebbe assumere che un corpo di tipo di contenuto application/sdp abbia la disposizione «session», e gli altri tipi di contenuto la disposizione «render».
Il tipo di disposizione «icon» indica che la parte del corpo contiene un'immagine appropriata come rappresentazione iconica del chiamante o del chiamato, che può essere resa dall'agente utente come informazione al ricevimento di un messaggio, o resa in modo continuo durante un dialogo. Il valore «alert» indica che la parte del corpo contiene informazioni (come un clip audio) che devono essere rese dall'agente utente per avvisare l'utente della ricezione di una richiesta (generalmente una richiesta che avvia un dialogo). Questo corpo di avviso può essere reso come suoneria di una chiamata telefonica, ad esempio dopo l'invio di una risposta provvisoria 180 Ringing.
Qualsiasi corpo MIME con un «disposition-type» che rende contenuti all'utente non deve essere elaborato a meno che il messaggio non sia correttamente autenticato.
Il parametro handling (handling-param) descrive la reazione del UAS quando riceve un corpo di messaggio il cui tipo di contenuto o tipo di disposizione non comprende. Il parametro ha i valori predefiniti «optional» e «required». Se il parametro handling è assente, dovrebbe essere assunto il valore «required». Il parametro handling è descritto nella RFC 3204 [19].
Se questo campo di intestazione è assente, il tipo MIME determina la disposizione di contenuto predefinita. In sua assenza, è assunto «render».
Esempio:
Content-Disposition: session
20.12 Content-Encoding
Il campo di intestazione Content-Encoding è usato come modificatore del «media-type». Se presente, il suo valore indica quale content-coding aggiuntivo è stato applicato al corpo dell'entità, e quindi quale meccanismo di decodifica deve essere applicato per ottenere il media-type referenziato dal campo di intestazione Content-Type. Content-Encoding è usato principalmente per consentire di comprimere il corpo senza perdere l'identità del media-type sottostante.
Se più codifiche sono state applicate al corpo dell'entità, i content-coding devono essere enumerati nell'ordine in cui sono stati applicati.
Tutti i valori content-coding non distinguono tra maiuscole e minuscole. L'IANA funge da registro per i token di valore content-coding. Vedi [H3.5] per la definizione della sintassi di content-coding.
Un client può applicare un content-coding al corpo in una richiesta. Un server può applicare un content-coding al corpo in una risposta. Un server deve usare solo le codifiche enumerate nel campo di intestazione Accept-Encoding della richiesta.
L'abbreviazione del campo di intestazione Content-Encoding è e.
Esempio:
Content-Encoding: gzip
e: tar
20.13 Content-Language
Vedi [H14.12]. Esempio:
Content-Language: fr
20.14 Content-Length
Il campo di intestazione Content-Length indica la dimensione del corpo del messaggio inviato al destinatario come numero decimale di ottetti. Le applicazioni dovrebbero usare questo campo per indicare la dimensione del corpo del messaggio trasmesso, indipendentemente dal media-type dell'entità. Quando un protocollo basato su flusso (come TCP) è usato come trasporto, il campo di intestazione deve essere usato.
La dimensione del corpo del messaggio non include il CRLF che separa i campi di intestazione dal corpo. Qualsiasi valore Content-Length maggiore o uguale a zero è un valore valido. Se il messaggio non ha un corpo, il valore del campo di intestazione Content-Length deve essere impostato a 0.
Il fatto che Content-Length possa essere omesso semplifica la creazione di script di tipo cgi che generano dinamicamente risposte.
L'abbreviazione del campo di intestazione è l.
Esempio:
Content-Length: 349
l: 173
20.15 Content-Type
Il campo di intestazione Content-Type indica il media-type del corpo del messaggio inviato al destinatario. L'elemento «media-type» è definito in [H3.7]. Se il corpo non è vuoto, il campo di intestazione Content-Type deve essere presente. Se il corpo è vuoto e il campo di intestazione Content-Type è presente, indica che un corpo di un tipo particolare ha lunghezza zero (ad esempio un file audio vuoto).
L'abbreviazione del campo di intestazione è c.
Esempio:
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
20.16 CSeq
Il campo di intestazione CSeq contiene un singolo numero di sequenza decimale e il metodo di richiesta in una richiesta. Il numero di sequenza deve essere rappresentabile come intero senza segno a 32 bit. La parte metodo di CSeq distingue tra maiuscole e minuscole. Il campo di intestazione CSeq fornisce un mezzo per ordinare le transazioni in un dialogo, identificare in modo univoco una transazione e distinguere una nuova richiesta da una ritrasmissione di richiesta. Due campi di intestazione CSeq sono considerati uguali se il numero di sequenza e il metodo di richiesta sono identici. Esempio:
CSeq: 4711 INVITE
20.17 Date
Il campo di intestazione Date contiene la data e l'ora. A differenza di HTTP/1.1, SIP supporta solo le date nel formato RFC 1123 [20] più recente. Come [H3.3], SIP limita il fuso orario di SIP-date a «GMT», mentre la RFC 1123 consente qualsiasi fuso orario. Le date RFC 1123 distinguono tra maiuscole e minuscole.
Il campo di intestazione Date riflette l'ora in cui la richiesta o la risposta è stata originariamente inviata.
Il campo di intestazione Date può essere usato da un sistema terminale semplice senza orologio backup per ottenere un concetto di ora corrente. Tuttavia, con il formato GMT, il client deve conoscere il proprio scostamento da GMT.
Esempio:
Date: Sat, 13 Nov 2010 23:29:00 GMT
20.18 Error-Info
Il campo di intestazione Error-Info fornisce un puntatore a informazioni aggiuntive su una risposta di stato di errore.
Le funzionalità dell'interfaccia utente dei UAC SIP vanno da finestre pop-up e suoni su un client software PC, a solo suono su un telefono «nero» o endpoint collegato tramite gateway. Invece di forzare il server che genera l'errore a inviare un codice di stato di errore con una frase di motivo dettagliata e a riprodurre una registrazione audio, il campo di intestazione Error-Info consente di inviare entrambi. Il UAC può quindi scegliere l'indicatore di errore da mostrare al chiamante.
Un UAC può trattare un URI SIP o SIPS nel campo di intestazione Error-Info come se fosse un Contact in un reindirizzamento, e generare una nuova INVITE, portando all'istituzione di una sessione di annuncio registrata. Un URI non SIP può essere mostrato all'utente.
Esempio:
SIP/2.0 404 The number you have dialed is not in service
Error-Info: <sip:[email protected]>
20.19 Expires
Il campo di intestazione Expires dà il tempo relativo dopo il quale il messaggio (o il contenuto) scade.
Il significato preciso di ciò dipende dal metodo.
La scadenza in una INVITE non ha effetto sulla durata della sessione reale che potrebbe derivare dall'invito. Tuttavia, il protocollo di descrizione di sessione può fornire la possibilità di esprimere un limite di tempo sulla durata della sessione.
Il valore di questo campo è un numero intero decimale di secondi nell'intervallo 0–(2**32)-1, misurato a partire dalla ricezione della richiesta.
Esempio:
Expires: 5
20.20 From
Il campo di intestazione From indica l'iniziatore della richiesta. Ciò può differire dall'iniziatore del dialogo. Una richiesta inviata dal chiamato al chiamante usa l'indirizzo del chiamato nel campo di intestazione From.
Il «display-name» opzionale è destinato a essere mostrato dall'interfaccia utente umana. Se le credenziali del client sono nascoste, il sistema dovrebbe usare il nome visualizzato «Anonymous». Se il «display-name» è vuoto, la forma «name-addr» deve essere usata se l'«addr-spec» contiene una virgola, un punto interrogativo o un punto e virgola. I problemi di sintassi sono discussi nella sezione 7.3.1.
Due campi di intestazione From sono equivalenti se i loro URI corrispondono e se i loro parametri corrispondono. Un parametro di estensione presente in uno dei campi di intestazione ma non nell'altro è ignorato ai fini del confronto. Ciò significa che la presenza o l'assenza del nome visualizzato e delle parentesi angolari non influisce sulla corrispondenza.
Vedi la sezione 20.10 per le regole di analisi del nome visualizzato, dell'URI, dei parametri URI e dei parametri di intestazione.
L'abbreviazione del campo di intestazione From è f.
Esempio:
From: "A. G. Bell" <sip:[email protected]> ;tag=a48s
From: sip:[email protected];tag=887s
f: Anonymous <sip:[email protected]>;tag=hyh8
20.21 In-Reply-To
Il campo di intestazione In-Reply-To enumera i Call-ID a cui questa chiamata fa riferimento o risponde. Questi Call-ID possono essere stati memorizzati nella cache dal client e inclusi nel campo di intestazione di questa chiamata di risposta.
Ciò consente a un sistema di distribuzione delle chiamate automatizzato di instradare una chiamata di risposta al chiamante della chiamata iniziale. Consente inoltre al chiamato di filtrare le chiamate, accettando solo le risposte alle chiamate che ha emesso. Questo campo non è un sostituto per l'autenticazione della richiesta.
Esempio:
In-Reply-To: [email protected], [email protected]
20.22 Max-Forwards
Il campo di intestazione Max-Forwards è usato con qualsiasi metodo SIP e deve limitare il numero di proxy o gateway attraverso i quali la richiesta può essere inoltrata al server downstream successivo. Ciò è utile anche quando un client tenta di tracciare una catena di richieste che sembra essere fallita o in loop lungo il percorso.
Il valore Max-Forwards è un intero nell'intervallo 0–255 che indica quante volte questa richiesta di messaggio può essere ancora inoltrata. Questo contatore è decrementato da ogni server che inoltra la richiesta. Il valore iniziale consigliato è 70.
Questo campo di intestazione dovrebbe essere inserito da un elemento che non può garantire il rilevamento del loop altrimenti. Ad esempio, un B2BUA dovrebbe inserire il campo di intestazione Max-Forwards.
Esempio:
Max-Forwards: 6
20.23 Min-Expires
Il campo di intestazione Min-Expires trasmette l'intervallo di aggiornamento minimo supportato per gli elementi di stato software gestiti da questo server. Ciò include i campi di intestazione Contact memorizzati da un registrar. Il campo di intestazione contiene un numero intero decimale di secondi nell'intervallo 0–(2**32)-1. L'uso del campo di intestazione in una risposta 423 (Interval Too Brief) è descritto nelle sezioni 10.2.8, 10.3 e 21.4.17.
Esempio:
Min-Expires: 60
20.24 MIME-Version
Vedi [H19.4.1].
Esempio:
MIME-Version: 1.0
20.25 Organization
Il campo di intestazione Organization trasmette il nome dell'organizzazione a cui appartiene l'elemento SIP che emette la richiesta o la risposta.
Questo campo può essere usato dal software client per filtrare le chiamate.
Esempio:
Organization: Boxes by Bob
20.26 Priority
Il campo di intestazione Priority indica l'urgenza della richiesta così come riconosciuta dal client. Il campo di intestazione Priority descrive la priorità che la richiesta SIP dovrebbe avere per la persona ricevente o il suo agente. Ad esempio, può essere incorporata nelle decisioni di instradamento e di accettazione della chiamata. In queste decisioni, un messaggio senza campo di intestazione Priority deve essere trattato come se specificasse la priorità «normal». Il campo di intestazione Priority non influisce sull'uso delle risorse di comunicazione quali la priorità di inoltro dei pacchetti in un router o l'accesso al circuito in un gateway PSTN. Il campo di intestazione può assumere i valori «non-urgent», «normal», «urgent» ed «emergency», sebbene valori aggiuntivi possano essere definiti altrove. Il valore «emergency» è raccomandato solo quando vita, integrità fisica o beni sono in pericolo immediato. Altrimenti, non è definita alcuna semantica per questo campo di intestazione.
Questi sono i valori della RFC 2076 [38] con l'aggiunta di «emergency».
Esempio:
Subject: A tornado is heading our way!
Priority: emergency
Oppure
Subject: Weekend plans
Priority: non-urgent
20.27 Proxy-Authenticate
Il valore del campo di intestazione Proxy-Authenticate contiene una sfida di autenticazione.
L'uso di questo campo di intestazione è definito in [H14.33]. Vedi la sezione 22.3 per maggiori dettagli sul suo uso.
Esempio:
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
20.28 Proxy-Authorization
Il campo di intestazione Proxy-Authorization consente a un client di identificarsi presso un proxy che richiede l'autenticazione del client. Il valore del campo Proxy-Authorization consiste in credenziali contenenti le informazioni di autenticazione dell'agente utente per il proxy e/o il realm della risorsa richiesta.
Vedi la sezione 22.3 per la definizione dell'uso di questo campo di intestazione.
Questo campo di intestazione, insieme a Authorization, infrange le regole generali riguardanti i nomi di campi di intestazione multipli. Non è un elenco separato da virgole, ma questo nome di campo di intestazione può apparire più volte e non deve essere fuso in una singola riga di intestazione usando le regole usuali descritte nella sezione 7.3.1.
Esempio:
Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022"
20.29 Proxy-Require
Il campo di intestazione Proxy-Require è usato da un UAC per specificare le funzionalità che un proxy deve supportare per elaborare questa richiesta. Il campo di intestazione Require (sezione 20.32) è usato per specificare le funzionalità supportate sia dal UAC sia dal UAS.
Come il campo di intestazione Require, se il campo di intestazione Proxy-Require contiene una funzionalità non supportata, il proxy deve restituire una risposta 420 (Bad Extension) e elencare le funzionalità non supportate nel campo di intestazione Unsupported. Questo campo di intestazione non dovrebbe essere usato in una richiesta che potrebbe essere inviata all'esterno di una catena di proxy fidata. Questo campo di intestazione esiste specificamente per informare un proxy della funzionalità di cui ha bisogno per elaborare la richiesta, in modo che la funzionalità funzioni correttamente se il proxy la supporta, piuttosto che per forzare il proxy a implementare la funzionalità.
Esempio:
Proxy-Require: foo
20.30 Record-Route
Il campo di intestazione Record-Route è usato da un proxy per inserirsi in una richiesta e forzare il passaggio delle richieste successive nel dialogo attraverso questo proxy.
Il campo di intestazione Record-Route non contribuisce all'ID del dialogo (sezione 12). Tuttavia, gli URI inclusi nel campo di intestazione Record-Route sono usati per stabilire l'insieme di route su cui le richieste successive nel dialogo sono inviate.
Un UA non è autorizzato a rimuovere elementi da uno qualsiasi degli URI del campo di intestazione Record-Route, o dagli URI che appaiono nel campo di intestazione Route. Il campo di intestazione Record-Route può essere aggiunto da un proxy che elabora la richiesta, e può puntare ad altri proxy basandosi sulle decisioni di routing discusse nell'elemento 5 della sezione 16.6. Gli URI che non contengono il parametro pp (sezione 19.1.1) dovrebbero includere il parametro lr per la compatibilità di routing con gli elementi RFC 2543.
Vedi la sezione 12 per maggiori dettagli su come il campo di intestazione Record-Route è usato per instradare le richieste in un dialogo.
Esempio:
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
20.31 Reply-To
Il campo di intestazione Reply-To, quando incluso in un messaggio di richiesta, contiene un URI SIP o SIPS a cui inviare una risposta al metodo richiesto (ad esempio INVITE). Se questo URI è assente, la risposta è inviata all'indirizzo fornito dal valore del campo di intestazione From o Contact. In alcuni casi, la chiamata è avviata da un indirizzo diverso dall'indirizzo di risposta. Questo campo di intestazione consente di specificare l'indirizzo di risposta indipendentemente dall'indirizzo di destinazione.
Questo campo può essere usato per instradare una risposta tra più indirizzi del destinatario. Ad esempio, il destinatario potrebbe desiderare che la chiamata arrivi su un telefono SIP di lavoro, ma che la risposta sia inviata a un telefono cellulare.
Esempio:
Reply-To: <sip:[email protected]>
20.32 Require
Il campo di intestazione Require è usato da un UAC per specificare le funzionalità che il UAS (e i proxy) deve supportare per elaborare la richiesta. Se un proxy o UAS non può comprendere una funzionalità elencata nel campo di intestazione Require di una richiesta ricevuta, tale elemento deve restituire una risposta 420 (Bad Extension) (sezione 20.40) contenente le funzionalità non supportate nel campo di intestazione Unsupported.
In contrasto, le funzionalità non elencate nel campo di intestazione Require avrebbero potuto essere elaborate in modo appropriato dal UAS se la funzionalità non era essenziale per la semantica della richiesta.
Una funzionalità può apparire come formato del messaggio SIP, o come media-type nella descrizione di sessione, o come parametro, o come altra funzionalità. I tag di opzione del campo di intestazione Require fanno riferimento a diverse funzionalità contrassegnate, come descritto nella sezione 19.2. Alcune funzionalità sono limitate ai proxy (ad esempio «re-route»). Queste sono specificate usando il campo di intestazione Proxy-Require (sezione 20.29).
Se il campo di intestazione Require è incluso in un messaggio di richiesta, deve essere copiato nel messaggio di risposta.
Le implementazioni di questa specifica devono prestare estrema attenzione a generare correttamente il campo di intestazione Require.
Il campo di intestazione Require porta a molte situazioni in cui le implementazioni desiderano comunicare ma supportano estensioni contraddittorie. La negoziazione delle estensioni correttamente implementata è difficile. Se una funzionalità supportata dal UA è posta nel campo di intestazione Require, il peer che non la supporta rifiuta la richiesta. Pertanto, il campo di intestazione Require deve essere usato solo per le funzionalità che il UA ritiene ragionevolmente supportate. Tutte le altre funzionalità dovrebbero essere specificate nel campo di intestazione Supported. I tag di opzione disponibili per il campo di intestazione Require sono definiti solo in RFC di tipo Standards Track. Ciò garantisce che solo poche funzionalità standardizzate (e in particolare quelle che influenzano sia UAS sia UAC) ottengano un tag di opzione. Il rigoroso processo di revisione per i tag di opzione impedisce che il campo di intestazione Require sia facile da usare e diffuso.
Esempio:
Require: 100rel
20.33 Retry-After
Il campo di intestazione Retry-After consente a un server di indicare il periodo dopo il quale un client può ritentare la sua richiesta. Può contenere un numero di secondi relativo all'ora corrente, o facoltativamente un valore di data SIP. Quando presente in una risposta che rifiuta la richiesta (ad esempio 500, 503 o 600), il valore indica il periodo dopo il quale il server accetterà o potrà tentare la chiamata. Quando presente in una risposta 503 (Service Unavailable), questo campo di intestazione indica l'ora in cui il sovraccarico verificatosi dovrebbe terminare.
Se il valore retry-after è maggiore di 0, il client deve attendere tale periodo prima di ritentare la richiesta. Se questo valore è 0, il client può ritentare la richiesta immediatamente.
Il parametro opzionale «comment» contiene testo leggibile dall'uomo. Il parametro opzionale «duration» rappresenta il periodo (in secondi) durante il quale una chiamata non deve essere tentata, anche dopo che il server ha determinato di poter tentare la chiamata.
Esempio:
Retry-After: 18000;duration=3600
Retry-After: 120;duration=3600
20.34 Route
Il campo di intestazione Route esiste per forzare un flusso preferito che il UAC usa per instradare la sessione. Un proxy è anche responsabile di soddisfare l'insieme di route in una richiesta ricevuta. Vedi la sezione 8.1.1.1.
Esempio:
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
20.35 Server
Il campo di intestazione Server contiene informazioni sul server che elabora la risposta e può includere informazioni sul software dell'agente utente server. Come il campo di intestazione HTTP simile, questo campo di intestazione può essere omesso per ragioni di sicurezza.
L'uso del campo di intestazione Server segue le stesse regole definite in [H14.38] per HTTP/1.1.
Esempio:
Server: HomeServer v2
20.36 Subject
Il campo di intestazione Subject fornisce una breve descrizione della natura o dell'argomento della chiamata.
L'uso della riga «Subject» da parte dell'agente utente ha la stessa semantica definita nella RFC 822 [39].
Esempio:
Subject: Need more boxes
20.37 Supported
Il campo di intestazione Supported elenca l'insieme delle funzionalità supportate dal UAC o UAS. In molti casi, le funzionalità sono elencate come tag di opzione (sezione 19.2).
Se il campo di intestazione Supported è inviato da un UAC, il UAS può rispondere al UAC con le funzionalità supportate nel campo di intestazione Supported.
Se il campo di intestazione Supported è inviato da un UAS, il UAC può ignorarlo.
Require e Supported possono entrambi essere inclusi in una risposta 2xx.
Se il campo di intestazione Supported è incluso in un messaggio di richiesta, deve essere copiato nel messaggio di risposta.
Le implementazioni di questa specifica devono prestare estrema attenzione a generare correttamente il campo di intestazione Supported.
Come spiegato nella discussione del campo di intestazione Require, un UA non deve porre sul campo di intestazione Require solo funzionalità identificate da tag di opzione standardizzati. Tentare di usare il campo di intestazione Require per forzare estensioni non standardizzate o specifiche dell'azienda può ridurre l'interoperabilità. Pertanto, tutte le opzioni supportate dovrebbero essere elencate nel campo di intestazione Supported. I tag di opzione disponibili per il campo di intestazione Require sono definiti solo in RFC di tipo Standards Track. Ciò garantisce che solo poche funzionalità standardizzate (e in particolare quelle che influenzano sia UAS sia UAC) ottengano un tag di opzione. Il rigoroso processo di revisione per i tag di opzione impedisce che il campo di intestazione Require sia facile da usare e diffuso.
Esempio:
Supported: 100rel
20.38 Timestamp
Il campo di intestazione Timestamp riflette l'ora in cui la richiesta del UAC è stata generata. Il client può usare l'ora restituita al server per calcolare il tempo di attesa di una risposta.
Esempio:
Timestamp: 54
20.39 To
Il campo di intestazione To specifica la seconda parte (o la risorsa logicamente indirizzata) a cui la richiesta è stata inizialmente indirizzata. Questo campo di intestazione specifica generalmente l'utente o la risorsa invitata dopo che il UAS ha accettato la richiesta.
Il campo di intestazione To deve essere incluso in tutti i messaggi SIP nelle richieste e nelle risposte.
Quando il campo di intestazione To è generato da un UAS, il UAS deve aggiungere un parametro «tag» al campo di intestazione To per fungere da parte dell'ID del dialogo.
Un UAS può aggiungere un tag al campo di intestazione To anche se rifiuta la richiesta per qualche motivo.
Vedi la sezione 19.3 per maggiori dettagli sulla generazione dei tag.
Due campi di intestazione To sono equivalenti se i loro URI corrispondono e se i loro parametri corrispondono. Un parametro di estensione presente in uno dei campi di intestazione ma non nell'altro è ignorato ai fini del confronto. Ciò significa che la presenza o l'assenza del nome visualizzato e delle parentesi angolari non influisce sulla corrispondenza.
Vedi la sezione 20.10 per le regole di analisi del nome visualizzato, dell'URI, dei parametri URI e dei parametri di intestazione.
L'abbreviazione del campo di intestazione To è t.
Esempio:
To: "A. G. Bell" <sip:[email protected]>;tag=a6c85cf
20.40 Unsupported
Il campo di intestazione Unsupported elenca le funzionalità non supportate dal server. Questo campo di intestazione è generato quando un server rifiuta una richiesta contenente il campo di intestazione Require (sezione 20.32).
Esempio:
Unsupported: foo
20.41 User-Agent
Il campo di intestazione User-Agent contiene informazioni sull'agente utente che avvia la richiesta. Come il campo di intestazione HTTP simile, questo campo di intestazione può essere omesso per ragioni di sicurezza.
Esempio:
User-Agent: Softphone Release 1.0
20.42 Via
Il campo di intestazione Via indica il protocollo di trasporto usato per inviare la richiesta, e gli indirizzi degli agenti (proxy, redirector e agenti utente) che l'hanno trasportata nell'ordine in cui la richiesta ha raggiunto la rete. I campi di intestazione Via nelle richieste e nelle risposte tracciano la rotta che la richiesta ha preso e prevengono loop nell'invio delle risposte.
Il campo di intestazione Via elenca il protocollo usato dall'applicazione per inviare la richiesta e non deve essere confuso con il protocollo di trasporto usato per trasferire messaggi tra applicazioni. Ad esempio, un messaggio SIP può essere trasferito tra applicazioni su UDP, ma l'applicazione SIP usa SIP/2.0/TCP per indicare il protocollo usato per inviare il messaggio su TCP.
L'indirizzo elencato nel quadro del campo di intestazione Via è l'indirizzo a cui la risposta è inviata. La parte responsabile (generalmente l'elemento upstream più vicino) può aggiungere un parametro «received» al campo di intestazione Via ricevuto per aiutare il proxy a determinare da dove deve ricevere la risposta.
Vedi le sezioni 18.2.1 e 18.2.2 per maggiori dettagli sui parametri «received» e «rport» del campo di intestazione Via, rispettivamente.
Un UA o un proxy che genera una risposta include un valore del campo di intestazione Via che elenca il protocollo usato per generare il messaggio. Questo valore non deve essere confuso con il protocollo usato per inviare la risposta. Come per la richiesta, il valore del campo di intestazione Via può attraversare più elementi (ad esempio, se la risposta è rispedita attraverso una catena di proxy).
Un valore del campo di intestazione Via contiene il protocollo usato per inviare la richiesta, un identificatore di branch e l'indirizzo dell'applicazione di invio. Il parametro branch è usato per identificare la transazione. L'elemento upstream più vicino (e talvolta il proxy) può includere un parametro «received» che aggiunge per instradare la risposta. Il valore del parametro branch è scelto dall'elemento, ma deve soddisfare i seguenti requisiti. Ciò consente all'applicazione di distinguere la richiesta, il trasporto usato per inviare la richiesta, e l'indirizzo (parzialmente insensibile alle maiuscole) dell'istanza di trasporto usata per inviare la richiesta.
o Il valore del parametro branch deve contenere il nome host o le informazioni di identificazione dell'elemento.
o Il valore del parametro branch può essere modificato per riflettere la creazione o la modifica di parti della richiesta di un messaggio che sono modificate senza modificare l'indirizzo, la porta e il protocollo di trasporto dell'elemento.
Vedi la sezione 17 per maggiori dettagli sul parametro «branch».
L'abbreviazione di questo campo di intestazione è V.
Esempio:
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776sgdkse
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK77ef4z