21. Codici di risposta (Response Codes)

21 Codici di risposta

I codici di risposta corrispondono ai codici di risposta HTTP/1.1 e li estendono. Non tutti i codici di risposta HTTP/1.1 sono appropriati, e qui sono presentati solo quelli appropriati. Gli altri codici di risposta HTTP/1.1 non devono essere utilizzati. Inoltre, SIP definisce una nuova classe 6xx.

21.1 Provvisorio 1xx

Le risposte provvisorie (anche chiamate risposte informative) indicano che il server connesso sta eseguendo un'azione aggiuntiva e non ha ancora una risposta finale. Il server invia una risposta 1xx se il conseguimento di una risposta finale dovrebbe richiedere più di 200 ms. Si noti che le risposte 1xx sono inviate in modo non affidabile. Esse non provocano mai l'invio di un ACK da parte del client. Una risposta provvisoria (1xx) può includere un corpo del messaggio contenente una descrizione di sessione.

21.1.1 100 Trying

Questa risposta indica che la richiesta è stata ricevuta dal server dell'hop successivo e che un'azione non specificata è in esecuzione per questa chiamata (ad esempio, un database viene interrogato). Questa risposta, come tutte le altre risposte provvisorie, ferma la ritrasmissione dell'INVITE da parte del UAC. La risposta 100 (Trying) non è mai inoltrata a monte da un proxy con stato, a differenza delle altre risposte provvisorie.

21.1.2 180 Ringing

Un UA che ha ricevuto una INVITE sta cercando di avvisare l'utente. Questa risposta può essere utilizzata per avviare un segnale di richiamo locale.

21.1.3 181 Call Is Being Forwarded

Il server può utilizzare questo codice di stato per indicare che la chiamata è inoltrata a un insieme di altre destinazioni.

21.1.4 182 Queued

Il chiamato non è temporaneamente disponibile, ma il server ha deciso di accodare la chiamata anziché rifiutarla. Quando il chiamato diventa disponibile, viene restituita una risposta di stato finale appropriata. La Reason-Phrase può dare ulteriori dettagli sullo stato della chiamata. Ad esempio «5 chiamate in coda. Tempo di attesa stimato 15 minuti». Il server può emettere più risposte 182 (Queued) per informare il chiamante dello stato della chiamata accodata.

21.1.5 183 Session Progress

La risposta 183 (Session Progress) è utilizzata per trasmettere informazioni sul progresso della chiamata che altrimenti non sono classificate. Può trasmettere dettagli sul progresso della chiamata utilizzando la Reason-Phrase, i campi di intestazione o il corpo del messaggio.

21.2 Successo 2xx

La richiesta ha avuto successo.

21.2.1 200 OK

La richiesta ha avuto successo. Le informazioni restituite con la risposta dipendono dal metodo utilizzato nella richiesta.

21.3 Reindirizzamento 3xx

Le risposte 3xx forniscono informazioni sulla nuova posizione dell'utente o su un servizio alternativo che potrebbe soddisfare la chiamata.

21.3.1 300 Multiple Choices

L'indirizzo nella richiesta si è risolto in più scelte, ciascuna con la propria posizione specifica, e l'utente (o il UA) può selezionare il punto di terminazione di comunicazione preferito e reindirizzare la richiesta a tale posizione.

La risposta può includere un corpo del messaggio contenente un elenco delle caratteristiche e delle posizioni delle risorse tra cui l'utente o il UA può scegliere la più appropriata, ma solo se consentito dal campo di intestazione di richiesta Accept. Tuttavia, il tipo MIME di tale corpo del messaggio non è definito.

Le scelte devono essere inoltre elencate come campi Contact (sezione 20.10). A differenza di HTTP, una risposta SIP può includere più campi Contact, o un elenco di indirizzi in un campo Contact. Il UA può utilizzare il valore del campo di intestazione Contact per il reindirizzamento automatico, o richiedere conferma della scelta all'utente. Tuttavia, questa specifica non definisce uno standard per tale selezione automatica.

  Questo codice di stato di risposta è appropriato quando il chiamato è raggiungibile in più posizioni diverse e il server non può o non vuole proxare la richiesta.

21.3.2 301 Moved Permanently

L'utente non esiste più all'indirizzo nel Request-URI, e il mittente della richiesta deve riprovare con il nuovo indirizzo fornito nel campo di intestazione Contact (sezione 20.10). Il mittente della richiesta deve aggiornare la sua rubrica locale, la sua agenda e la sua cache della posizione utente con questo nuovo valore, e reindirizzare le richieste future all'indirizzo elencato.

21.3.3 302 Moved Temporarily

Il mittente della richiesta deve riprovare la richiesta con il nuovo indirizzo fornito nel campo di intestazione Contact (sezione 20.10). Il Request-URI della nuova richiesta utilizza il valore del campo di intestazione Contact nella risposta.

La durata di validità dell'URI Contact può essere indicata tramite il campo di intestazione Expires (sezione 20.19) o il parametro expires nel campo di intestazione Contact. I proxy e i UA possono memorizzare nella cache questo URI per la durata di validità. In assenza di scadenza esplicita, l'indirizzo è valido solo una volta per la ricorsione e non deve essere memorizzato nella cache per le transazioni future.

Se l'URI memorizzato nella cache dal campo di intestazione Contact fallisce, il Request-URI della richiesta reindirizzata può essere riprovato una sola volta.

  Un URI temporaneo può diventare obsoleto prima della sua durata di validità, e un nuovo URI temporaneo potrebbe essere disponibile.

21.3.4 305 Use Proxy

La risorsa richiesta deve essere accessa tramite il proxy fornito nel campo Contact. Il campo Contact fornisce l'URI del proxy. Il destinatario è tenuto a ripetere questa singola richiesta tramite il proxy. La risposta 305 (Use Proxy) può essere generata solo da un UAS.

21.3.5 380 Alternative Service

La chiamata non è riuscita ma un servizio alternativo è possibile.

Il servizio alternativo è descritto nel corpo del messaggio della risposta. Il formato di tale corpo non è definito qui e potrebbe essere oggetto di futura standardizzazione.

21.4 Errore di richiesta 4xx

Le risposte 4xx sono risposte di errore definitive da un particolare server. Il client non deve riprovare la stessa richiesta senza modifica (ad esempio, aggiungendo l'autenticazione appropriata). Tuttavia, la stessa richiesta a un server diverso potrebbe avere successo.

21.4.1 400 Bad Request

La richiesta non poteva essere compresa a causa di una sintassi mal formattata. La Reason-Phrase deve identificare più dettagliatamente il problema di sintassi. Ad esempio «Call-ID header field missing».

21.4.2 401 Unauthorized

La richiesta richiede l'autenticazione dell'utente. Questa risposta è emessa dal UAS e dal registrar, e 407 (Proxy Authentication Required) è utilizzato dal server proxy.

21.4.3 402 Payment Required

Riservato per uso futuro.

21.4.4 403 Forbidden

Il server ha compreso la richiesta ma rifiuta di eseguirla. L'autenticazione è inutile e la richiesta non deve essere ripetuta.

21.4.5 404 Not Found

Il server ha informazioni definitive che nessun utente esiste nel dominio specificato dal Request-URI. Questo stato è restituito anche quando il dominio nel Request-URI non corrisponde a nessuno dei domini gestiti dal destinatario della richiesta.

21.4.6 405 Method Not Allowed

Il metodo specificato nella Request-Line è compreso ma non consentito per l'indirizzo identificato dal Request-URI.

La risposta deve includere un campo di intestazione Allow contenente l'elenco dei metodi validi per l'indirizzo indicato.

21.4.7 406 Not Acceptable

La risorsa identificata dalla richiesta è in grado di generare solo un'entità di risposta avente caratteristiche di contenuto che non sono accettabili secondo il campo di intestazione Accept inviato nella richiesta.

21.4.8 407 Proxy Authentication Required

Questo codice è simile a 401 (Unauthorized) ma indica che il client deve prima autenticarsi presso il proxy. L'autenticazione di accesso SIP è descritta nelle sezioni 26 e 22.3.

Questo codice di stato può essere utilizzato in applicazioni che richiedono l'autenticazione per accedere al canale di comunicazione (ad esempio un gateway telefonico).

21.4.9 408 Request Timeout

Il server non ha potuto generare una risposta entro il tempo appropriato. Ad esempio, non ha potuto determinare la posizione dell'utente in tempo utile. Il client può riprovare la richiesta in un arbitrario momento futuro senza modifiche.

21.4.10 410 Gone

La risorsa richiesta non è più disponibile sul server e l'indirizzo di inoltro non è neppure noto. Questo stato è considerato permanente. Se il server non sa o non può determinare se lo stato è permanente, deve utilizzare il codice di stato 404 (Not Found) al suo posto.

21.4.11 413 Request Entity Too Large

Il server rifiuta di elaborare la richiesta perché l'entità del corpo della richiesta è più grande della dimensione che il server desidera o è in grado di elaborare. Il server può chiudere la connessione per impedire al client di continuare la richiesta.

Se la condizione è temporanea, il server deve includere un campo di intestazione Retry-After che indica che è temporanea e quando il client può riprovare.

21.4.12 414 Request-URI Too Long

Il server rifiuta di elaborare la richiesta perché il Request-URI è più lungo della lunghezza che il server desidera interpretare.

21.4.13 415 Unsupported Media Type

Il server rifiuta di elaborare la richiesta perché il corpo del messaggio della richiesta è in un formato non supportato dal server per il metodo richiesto. Il server deve restituire un elenco dei formati accettabili utilizzando i campi di intestazione Accept, Accept-Encoding o Accept-Language a seconda del problema specifico del contenuto. L'elaborazione UAC di questa risposta è descritta nella sezione 8.1.3.5.

21.4.14 416 Unsupported URI Scheme

Il server non può elaborare la richiesta perché lo schema dell'URI nel Request-URI è sconosciuto al server. L'elaborazione client di questa risposta è descritta nella sezione 8.1.3.5.

21.4.15 420 Bad Extension

Il server non ha compreso l'estensione di protocollo specificata nei campi di intestazione Proxy-Require (sezione 20.29) o Require (sezione 20.32). Il server deve includere nella risposta l'elenco delle estensioni non supportate nel campo di intestazione Unsupported. L'elaborazione UAC di questa risposta è descritta nella sezione 8.1.3.5.

21.4.16 421 Extension Required

Un UAS richiede un'estensione particolare per elaborare la richiesta, ma questa estensione non è elencata nel campo di intestazione Supported della richiesta. La risposta con questo codice di stato deve includere un campo di intestazione Require che elenca l'estensione richiesta.

Un UAS non deve utilizzare questa risposta a meno che non possa effettivamente fornire un servizio utile al client. Invece, se l'estensione desiderata non è elencata nel campo di intestazione Supported, il server deve elaborare la richiesta utilizzando le funzionalità SIP di base e le estensioni supportate dal client.

21.4.17 423 Interval Too Brief

Il server rifiuta la richiesta perché l'intervallo di validità della risorsa aggiornata dalla richiesta è troppo breve. Questa risposta può essere utilizzata da un registrar per rifiutare una registrazione la cui scadenza nel campo di intestazione Contact era troppo breve. L'uso di questa risposta e del campo di intestazione Min-Expires associato è descritto nelle sezioni 10.2.8, 10.3 e 20.23.

21.4.18 480 Temporarily Unavailable

Il sistema terminale del chiamato è correttamente connesso, ma il chiamato non è attualmente disponibile (ad esempio non connesso, connesso ma in uno stato che impedisce la comunicazione con il chiamato, o con la funzione «rifiuto di chiamata» attivata). La risposta può indicare un momento migliore per la chiamata tramite il campo di intestazione Retry-After. L'utente potrebbe essere disponibile altrove (sconosciuto a questo server). La Reason-Phrase deve indicare la causa precisa dell'indisponibilità del chiamato. Questo valore deve essere configurabile dal UA. Il codice di stato 486 (Busy Here) può essere utilizzato per indicare più precisamente il motivo specifico dell'errore di chiamata.

Questo stato è restituito anche da un server di reindirizzamento o proxy che riconosce l'utente identificato dal Request-URI ma non ha attualmente una posizione di inoltro valida per tale utente.

21.4.19 481 Call/Transaction Does Not Exist

Questo stato indica che un UAS ha ricevuto una richiesta che non corrisponde a nessun dialogo o transazione esistente.

21.4.20 482 Loop Detected

Il server ha rilevato un loop (elemento 4 della sezione 16.3).

21.4.21 483 Too Many Hops

Il server ha ricevuto una richiesta contenente un campo di intestazione Max-Forwards (sezione 20.22) con valore zero.

21.4.22 484 Address Incomplete

Il server ha ricevuto una richiesta il cui Request-URI è incompleto. Ulteriori informazioni devono essere fornite nella Reason-Phrase.

  Questo codice di stato consente la composizione sovrapposta. Con la composizione sovrapposta, il client non conosce la lunghezza della stringa composta. Invia una stringa di lunghezza crescente mentre invita l'utente a ulteriori input, e continua finché non riceve più una risposta di stato 484 (Address Incomplete).

21.4.23 485 Ambiguous

Il Request-URI era ambiguo. La risposta può includere l'elenco degli indirizzi chiaramente possibili nel campo di intestazione Contact. Rendere evidenti le alternative può violare la privacy dell'utente o dell'organizzazione. Deve essere possibile configurare il server per rispondere con 404 (Not Found) a un Request-URI ambiguo, o per sopprimere l'elenco delle possibili scelte.

Esempio di risposta a una richiesta il cui Request-URI è sip:[email protected] :

  SIP/2.0 485 Ambiguous
  Contact: Carol Lee `&lt;sip:[email protected]>`
  Contact: Ping Lee `&lt;sip:[email protected]>`
  Contact: Lee M. Foote `&lt;sips:[email protected]>`

  Alcuni sistemi di posta elettronica e casella vocale forniscono questa funzionalità. Un codice di stato distinto dai 3xx è utilizzato perché ha una semantica diversa dai 3xx. Nel caso di 300, si suppone che le scelte fornite raggiungano la stessa persona o lo stesso servizio. La selezione automatica o la ricerca sequenziale hanno senso per le risposte 3xx, ma una risposta 485 (Ambiguous) richiede l'intervento dell'utente.

21.4.24 486 Busy Here

Il sistema terminale del chiamato è correttamente connesso, ma il chiamato non desidera o non può accettare un'altra chiamata al momento. La risposta può indicare un momento migliore per la chiamata tramite il campo di intestazione Retry-After. L'utente potrebbe essere disponibile altrove, come un servizio di casella vocale. Se il client sa che altri sistemi terminali non possono accettare questa chiamata, deve utilizzare 600 (Busy Everywhere).

21.4.25 487 Request Terminated

La richiesta è stata terminata da una richiesta BYE o CANCEL. Questa risposta non è mai restituita alla richiesta CANCEL stessa.

21.4.26 488 Not Acceptable Here

La risposta ha lo stesso significato di 606 (Not Acceptable) ma si applica solo alla risorsa particolare indirizzata dal Request-URI, e la richiesta potrebbe avere successo altrove.

Un corpo del messaggio contenente una descrizione delle capacità multimediali formattata secondo il campo di intestazione Accept nella INVITE (o application/sdp se assente) può essere presente nella risposta. Ciò è identico al corpo del messaggio in una risposta 200 (OK) a una richiesta OPTIONS.

21.4.27 491 Request Pending

La richiesta è stata ricevuta da un UAS che ha una richiesta in sospeso nello stesso dialogo. Come tale situazione di «glare» sia risolta è descritto nella sezione 14.2.

21.4.28 493 Undecipherable

La richiesta è stata ricevuta da un UAS contenente un corpo MIME crittografato per il quale il destinatario non possiede o non fornisce la chiave di decrittazione appropriata. Questa risposta può avere un singolo corpo contenente la chiave pubblica appropriata da utilizzare per crittografare il corpo MIME inviato a questo UA. I dettagli dell'uso di questo codice di risposta si trovano nella sezione 23.2.

21.5 Errore di server 5xx

Le risposte 5xx sono risposte di errore date quando il server stesso ha commesso un errore.

21.5.1 500 Server Internal Error

Il server ha incontrato una condizione imprevista che lo ha impedito di eseguire la richiesta. Il client può visualizzare un errore specifico e riprovare la richiesta dopo alcuni secondi.

Se la condizione è temporanea, il server può indicare tramite il campo di intestazione Retry-After quando il client può riprovare la richiesta.

21.5.2 501 Not Implemented

Il server non supporta le funzionalità necessarie per soddisfare la richiesta. Questa è la risposta appropriata quando un UAS non riconosce il metodo di richiesta e non può supportarlo per alcun utente. (Un proxy inoltra tutte le richieste indipendentemente dal metodo.)

Si noti che se il server riconosce il metodo di richiesta ma non è consentito o supportato, viene inviato un 405 (Method Not Allowed).

21.5.3 502 Bad Gateway

Il server, agendo come gateway o proxy, ha ricevuto una risposta non valida dal server downstream a cui ha accesso per soddisfare la richiesta.

21.5.4 503 Service Unavailable

Il server è temporaneamente incapace di elaborare la richiesta a causa di un sovraccarico temporaneo o di manutenzione del server. Il server può indicare tramite il campo di intestazione Retry-After quando il client deve riprovare la richiesta. In assenza di Retry-After, il client deve agire come se avesse ricevuto una risposta 500 (Server Internal Error).

Il client (proxy o UAC) che ha ricevuto un 503 (Service Unavailable) deve tentare di inoltrare la richiesta a un server alternativo. Non deve inoltrare altre richieste a questo server durante il periodo specificato (se presente) nel campo di intestazione Retry-After.

Il server può rifiutare la connessione o ignorare la richiesta invece di rispondere con 503 (Service Unavailable).

21.5.5 504 Server Time-out

Il server non ha ricevuto una risposta tempestiva dal server esterno a cui ha accesso per elaborare la richiesta. Se non è stata ricevuta alcuna risposta entro il periodo specificato dal campo di intestazione Expires del server upstream, deve essere utilizzato invece un 408 (Request Timeout).

21.5.6 505 Version Not Supported

Il server non supporta o rifiuta di supportare la versione del protocollo SIP utilizzata nella richiesta. Il server indica che non può o non vuole completare la richiesta utilizzando la stessa versione maggiore del client, fatta eccezione per questo messaggio di errore.

21.5.7 513 Message Too Large

Il server non ha potuto elaborare la richiesta perché la lunghezza del messaggio superava la sua capacità.

21.6 Errore globale 6xx

Le risposte 6xx indicano che il server ha informazioni definitive riguardo a un particolare utente, e non solo all'istanza particolare indicata dal Request-URI.

21.6.1 600 Busy Everywhere

Il sistema terminale del chiamato è correttamente connesso, ma il chiamato è occupato e non desidera accettare un'altra chiamata al momento. La risposta può indicare un momento migliore per la chiamata tramite il campo di intestazione Retry-After. Se il chiamato non vuole rivelare il motivo del rifiuto di chiamata, utilizza invece il codice di stato 603 (Decline). Questa risposta di stato è restituita solo se il client sa che altri endpoint (come un sistema di casella vocale) non risponderanno alla richiesta. Altrimenti, deve essere restituito un 486 (Busy Here).

21.6.2 603 Decline

La macchina del chiamato è correttamente connessa, ma l'utente ha esplicitamente rifiutato di partecipare o non può. La risposta può indicare un momento migliore per la chiamata tramite il campo di intestazione Retry-After. Questa risposta di stato è restituita solo se il client sa che altri endpoint non risponderanno alla richiesta.

21.6.3 604 Does Not Exist Anywhere

Il server ha informazioni autorevoli che l'utente indicato dal Request-URI non esiste da nessuna parte.

21.6.4 606 Not Acceptable

L'agente utente dell'utente è correttamente connesso, ma alcuni aspetti della descrizione di sessione, come il media richiesto, la larghezza di banda o lo stile di indirizzamento, non sono stati accettati.

Una risposta 606 (Not Acceptable) significa che l'utente desidera comunicare ma non può supportare adeguatamente la sessione descritta. Una risposta 606 (Not Acceptable) può includere un elenco di motivi nel campo di intestazione Warning che spiegano perché la sessione descritta non può essere supportata. I codici di motivo Warning sono elencati nella sezione 20.43.

È desiderabile che la negoziazione non sia frequentemente necessaria. E quando un nuovo utente è invitato a una conferenza esistente, la negoziazione potrebbe essere impossibile. È responsabilità dell'iniziatore dell'invito decidere se agire sulla base di una risposta 606 (Not Acceptable).

Questa risposta di stato è restituita solo se il client sa che altri endpoint non risponderanno alla richiesta.