21. Codes de réponse (Response Codes)

21 Codes de réponse

Les codes de réponse correspondent aux codes de réponse HTTP/1.1 et les étendent. Tous les codes de réponse HTTP/1.1 ne sont pas appropriés, et seuls ceux qui le sont sont présentés ici. Les autres codes de réponse HTTP/1.1 ne doivent pas être utilisés. De plus, SIP définit une nouvelle classe 6xx.

21.1 Provisoire 1xx

Les réponses provisoires (aussi appelées réponses informationnelles) indiquent que le serveur connecté effectue une action supplémentaire et n'a pas encore de réponse finale. Le serveur envoie une réponse 1xx si l'obtention d'une réponse finale devrait prendre plus de 200 ms. Notez que les réponses 1xx sont envoyées de manière non fiable. Elles ne provoquent jamais l'envoi d'un ACK par le client. Une réponse provisoire (1xx) peut inclure un corps de message contenant une description de session.

21.1.1 100 Trying

Cette réponse indique que la requête a été reçue par le serveur du saut suivant et qu'une action non spécifiée est en cours d'exécution pour ce appel (par exemple, une base de données est interrogée). Cette réponse, comme toutes les autres réponses provisoires, arrête la retransmission de l'INVITE par le UAC. La réponse 100 (Trying) n'est jamais transmise en amont par un proxy avec état, contrairement aux autres réponses provisoires.

21.1.2 180 Ringing

Le UA ayant reçu une INVITE essaie d'avertir l'utilisateur. Cette réponse peut être utilisée pour démarrer une tonalité de rappel locale.

21.1.3 181 Call Is Being Forwarded

Le serveur peut utiliser ce code d'état pour indiquer que l'appel est transféré vers un ensemble d'autres destinations.

21.1.4 182 Queued

Le correspondant n'est pas disponible temporairement, mais le serveur a décidé de mettre l'appel en file d'attente plutôt que de le rejeter. Lorsque le correspondant devient disponible, une réponse d'état final appropriée est renvoyée. La phrase de raison peut donner plus de détails sur l'état de l'appel. Par exemple « 5 appels en file d'attente. Temps d'attente estimé 15 minutes ». Le serveur peut émettre plusieurs réponses 182 (Queued) pour informer l'appelant de l'état de l'appel en file d'attente.

21.1.5 183 Session Progress

La réponse 183 (Session Progress) est utilisée pour transmettre des informations sur la progression de l'appel qui ne sont autrement pas classées. Elle peut transmettre des détails sur la progression de l'appel en utilisant la Reason-Phrase, les champs d'en-tête ou le corps du message.

21.2 Succès 2xx

La requête a réussi.

21.2.1 200 OK

La requête a réussi. Les informations renvoyées avec la réponse dépendent de la méthode utilisée dans la requête.

21.3 Redirection 3xx

Les réponses 3xx donnent des informations sur le nouvel emplacement de l'utilisateur ou sur un service alternatif susceptible de satisfaire l'appel.

21.3.1 300 Multiple Choices

L'adresse dans la requête s'est résolue en plusieurs choix, chacun ayant son propre emplacement spécifique, et l'utilisateur (ou le UA) peut sélectionner le point de terminaison de communication préféré et rediriger la requête vers cet emplacement.

La réponse peut inclure un corps de message contenant une liste des caractéristiques et des emplacements des ressources que l'utilisateur ou le UA peut choisir la plus appropriée, mais seulement si autorisé par le champ d'en-tête de requête Accept. Cependant, le type MIME de ce corps de message n'est pas défini.

Les choix doivent également être listés comme champs Contact (section 20.10). Contrairement à HTTP, une réponse SIP peut inclure plusieurs champs Contact, ou une liste d'adresses dans un champ Contact. Le UA peut utiliser la valeur du champ d'en-tête Contact pour la redirection automatique, ou demander confirmation du choix à l'utilisateur. Cependant, cette spécification ne définit pas de norme pour une telle sélection automatique.

  Ce code d'état de réponse est approprié lorsque le correspondant est joignable à plusieurs emplacements différents et que le serveur ne peut pas ou ne veut pas proxifier la requête.

21.3.2 301 Moved Permanently

L'utilisateur n'existe plus à l'adresse dans le Request-URI, et l'émetteur de la requête doit réessayer avec la nouvelle adresse donnée dans le champ d'en-tête Contact (section 20.10). L'émetteur de la requête doit mettre à jour son annuaire local, son carnet d'adresses et son cache de position utilisateur avec cette nouvelle valeur, et rediriger les requêtes futures vers l'adresse listée.

21.3.3 302 Moved Temporarily

L'émetteur de la requête doit réessayer la requête avec la nouvelle adresse donnée dans le champ d'en-tête Contact (section 20.10). Le Request-URI de la nouvelle requête utilise la valeur du champ d'en-tête Contact dans la réponse.

La durée de validité de l'URI Contact peut être indiquée via le champ d'en-tête Expires (section 20.19) ou le paramètre expires dans le champ d'en-tête Contact. Les proxys et les UA peuvent mettre en cache cet URI pour la durée de validité. En l'absence d'expiration explicite, l'adresse n'est valide qu'une seule fois pour la récursion et ne doit pas être mise en cache pour les transactions futures.

Si l'URI mis en cache à partir du champ d'en-tête Contact échoue, le Request-URI de la requête redirigée peut être réessayé une seule fois.

  Une URI temporaire peut devenir périmée plus tôt que sa durée de validité, et une nouvelle URI temporaire peut être disponible.

21.3.4 305 Use Proxy

La ressource demandée doit être accédée via le proxy donné dans le champ Contact. Le champ Contact donne l'URI du proxy. Le destinataire est censé répéter cette requête unique via le proxy. La réponse 305 (Use Proxy) ne peut être générée que par un UAS.

21.3.5 380 Alternative Service

L'appel a échoué mais un service alternatif est possible.

Le service alternatif est décrit dans le corps du message de la réponse. Le format d'un tel corps n'est pas défini ici et pourrait faire l'objet d'une future standardisation.

21.4 Échec de requête 4xx

Les réponses 4xx sont des réponses d'échec définitives d'un serveur particulier. Le client ne doit pas réessayer la même requête sans modification (par exemple, en ajoutant l'authentification appropriée). Cependant, la même requête à un serveur différent peut réussir.

21.4.1 400 Bad Request

La requête n'a pas pu être comprise en raison d'une syntaxe mal formatée. La Reason-Phrase doit identifier plus en détail le problème de syntaxe. Par exemple « Call-ID header field missing ».

21.4.2 401 Unauthorized

La requête nécessite l'authentification de l'utilisateur. Cette réponse est émise par le UAS et le registraire, et 407 (Proxy Authentication Required) est utilisé par le serveur proxy.

21.4.3 402 Payment Required

Réservé pour un usage futur.

21.4.4 403 Forbidden

Le serveur a compris la requête mais refuse de l'exécuter. L'authentification est inutile et la requête ne doit pas être répétée.

21.4.5 404 Not Found

Le serveur a des informations définitives qu'aucun utilisateur n'existe dans le domaine spécifié par le Request-URI. Ce statut est également renvoyé lorsque le domaine dans le Request-URI ne correspond à aucun des domaines traités par le destinataire de la requête.

21.4.6 405 Method Not Allowed

La méthode spécifiée dans la Request-Line est comprise mais non autorisée pour l'adresse identifiée par le Request-URI.

La réponse doit inclure un champ d'en-tête Allow contenant la liste des méthodes valides pour l'adresse indiquée.

21.4.7 406 Not Acceptable

La ressource identifiée par la requête n'est capable de générer qu'une entité de réponse ayant des caractéristiques de contenu qui ne sont pas acceptables selon le champ d'en-tête Accept envoyé dans la requête.

21.4.8 407 Proxy Authentication Required

Ce code est similaire à 401 (Unauthorized) mais indique que le client doit d'abord s'authentifier auprès du proxy. L'authentification d'accès SIP est décrite dans les sections 26 et 22.3.

Ce code d'état peut être utilisé dans des applications nécessitant une authentification pour accéder au canal de communication (par exemple une passerelle téléphonique).

21.4.9 408 Request Timeout

Le serveur n'a pas pu générer une réponse dans le temps approprié. Par exemple, il n'a pas pu déterminer l'emplacement de l'utilisateur à temps. Le client peut réessayer la requête à un moment ultérieur arbitraire sans modification.

21.4.10 410 Gone

La ressource demandée n'est plus disponible sur le serveur et l'adresse de transfert n'est pas connue non plus. Cet état est censé être permanent. Si le serveur ne sait pas ou ne peut pas déterminer si l'état est permanent, il doit utiliser le code d'état 404 (Not Found) à la place.

21.4.11 413 Request Entity Too Large

Le serveur refuse de traiter la requête parce que l'entité du corps de la requête est plus grande que la taille que le serveur souhaite ou est capable de traiter. Le serveur peut fermer la connexion pour empêcher le client de continuer la requête.

Si la condition est temporaire, le serveur doit inclure un champ d'en-tête Retry-After indiquant qu'elle est temporaire et quand le client peut réessayer.

21.4.12 414 Request-URI Too Long

Le serveur refuse de traiter la requête parce que le Request-URI est plus long que ce que le serveur souhaite interpréter.

21.4.13 415 Unsupported Media Type

Le serveur refuse de traiter la requête parce que le corps du message de la requête est dans un format non pris en charge par le serveur pour la méthode demandée. Le serveur doit renvoyer une liste des formats acceptables en utilisant les champs d'en-tête Accept, Accept-Encoding ou Accept-Language selon le problème spécifique du contenu. Le traitement UAC de cette réponse est décrit dans la section 8.1.3.5.

21.4.14 416 Unsupported URI Scheme

Le serveur ne peut pas traiter la requête parce que le schéma de l'URI dans le Request-URI est inconnu du serveur. Le traitement client de cette réponse est décrit dans la section 8.1.3.5.

21.4.15 420 Bad Extension

Le serveur n'a pas compris l'extension de protocole spécifiée dans le champ d'en-tête Proxy-Require (section 20.29) ou Require (section 20.32). Le serveur doit inclure dans la réponse la liste des extensions non prises en charge dans le champ d'en-tête Unsupported. Le traitement UAC de cette réponse est décrit dans la section 8.1.3.5.

21.4.16 421 Extension Required

Le UAS nécessite une extension particulière pour traiter la requête, mais cette extension n'est pas listée dans le champ d'en-tête Supported de la requête. La réponse avec ce code d'état doit inclure un champ d'en-tête Require listant l'extension requise.

Le UAS ne doit pas utiliser cette réponse sauf s'il ne peut pas réellement fournir un service utile au client. Au lieu de cela, si l'extension souhaitée n'est pas listée dans le champ d'en-tête Supported, le serveur doit traiter la requête en utilisant les fonctionnalités SIP de base et les extensions prises en charge par le client.

21.4.17 423 Interval Too Brief

Le serveur rejette la requête parce que l'intervalle de validité de la ressource mise à jour par la requête est trop court. Cette réponse peut être utilisée par un registraire pour rejeter une inscription dont l'expiration du champ d'en-tête Contact est trop courte. L'utilisation de cette réponse et du champ d'en-tête Min-Expires associé est décrite dans les sections 10.2.8, 10.3 et 20.23.

21.4.18 480 Temporarily Unavailable

Le système terminal du correspondant est correctement connecté, mais le correspondant n'est pas disponible pour le moment (par exemple non connecté, connecté mais dans un état empêchant la communication avec le correspondant, ou ayant activé une fonction « refus d'appel »). La réponse peut indiquer un meilleur moment d'appel via le champ d'en-tête Retry-After. L'utilisateur peut être disponible ailleurs (inconnu de ce serveur). La Reason-Phrase doit indiquer la cause précise de l'indisponibilité du correspondant. Cette valeur doit être configurable par le UA. Le statut 486 (Busy Here) peut être utilisé pour indiquer plus précisément la raison de l'échec de l'appel.

Ce statut est également renvoyé par un serveur de redirection ou de proxy qui reconnaît l'utilisateur identifié par le Request-URI mais n'a actuellement pas d'emplacement de transfert valide pour cet utilisateur.

21.4.19 481 Call/Transaction Does Not Exist

Ce statut indique qu'un UAS a reçu une requête qui ne correspond à aucun dialogue ou transaction existant.

21.4.20 482 Loop Detected

Le serveur a détecté une boucle (élément 4 de la section 16.3).

21.4.21 483 Too Many Hops

Le serveur a reçu une requête contenant un champ d'en-tête Max-Forwards (section 20.22) avec une valeur de zéro.

21.4.22 484 Address Incomplete

Le serveur a reçu une requête dont le Request-URI est incomplet. Des informations supplémentaires doivent être fournies dans la Reason-Phrase.

  Ce code d'état permet la numérotation par chevauchement. Avec la numérotation par chevauchement, le client ne connaît pas la longueur de la chaîne composée. Il envoie une chaîne de longueur croissante tout en invitant l'utilisateur à plus d'entrées, et continue jusqu'à ce qu'il ne reçoive plus de réponse d'état 484 (Address Incomplete).

21.4.23 485 Ambiguous

Le Request-URI était ambigu. La réponse peut inclure la liste des adresses clairement possibles dans le champ d'en-tête Contact. Rendre les alternatives évidentes peut enfreindre la vie privée de l'utilisateur ou de l'organisation. Il doit être possible de configurer le serveur pour répondre avec 404 (Not Found) au Request-URI ambigu, ou pour supprimer la liste des choix possibles.

Exemple de réponse à une requête dont le Request-URI est 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]>`

  Certains systèmes de courrier électronique et de messagerie vocale fournissent cette fonctionnalité. Un code d'état distinct des 3xx est utilisé car il a une sémantique différente de 3xx. Dans le cas de 300, il est supposé que les choix fournis atteignent la même personne ou le même service. La sélection automatique ou la recherche séquentielle a un sens pour les réponses 3xx, mais une réponse 485 (Ambiguous) nécessite l'intervention de l'utilisateur.

21.4.24 486 Busy Here

Le système terminal du correspondant est correctement connecté, mais le correspondant ne souhaite ou ne peut pas accepter d'autre appel pour le moment. La réponse peut indiquer un meilleur moment d'appel via le champ d'en-tête Retry-After. L'utilisateur peut être disponible ailleurs, comme un service de messagerie vocale. Si le client sait que d'autres systèmes terminaux ne peuvent pas accepter cet appel, il doit utiliser 600 (Busy Everywhere).

21.4.25 487 Request Terminated

La requête a été terminée par une requête BYE ou CANCEL. Cette réponse n'est jamais renvoyée à la requête CANCEL elle-même.

21.4.26 488 Not Acceptable Here

La réponse a la même signification que 606 (Not Acceptable) mais s'applique uniquement à la ressource particulière adressée par le Request-URI, et la requête pourrait réussir ailleurs.

Un corps de message contenant une description des capacités média formatée selon le champ d'en-tête Accept dans l'INVITE (ou application/sdp s'il est absent) peut être présent dans la réponse. Cela est identique au corps de message dans une réponse 200 (OK) à une requête OPTIONS.

21.4.27 491 Request Pending

La requête a été reçue par un UAS ayant une requête en attente dans le même dialogue. La manière dont une telle situation de « glare » est résolue est décrite dans la section 14.2.

21.4.28 493 Undecipherable

La requête a été reçue par un UAS contenant un corps MIME chiffré que le destinataire ne possède pas ou ne fournit pas la clé de déchiffrement appropriée. Cette réponse peut avoir un corps unique contenant la clé publique appropriée à utiliser pour chiffrer le corps MIME envoyé à ce UA. Les détails de l'utilisation de ce code de réponse se trouvent dans la section 23.2.

21.5 Échec de serveur 5xx

Les réponses 5xx sont des réponses d'échec données lorsque le serveur lui-même a commis une erreur.

21.5.1 500 Server Internal Error

Le serveur a rencontré une condition inattendue qui l'a empêché d'exécuter la requête. Le client peut afficher une erreur spécifique et réessayer la requête après quelques secondes.

Si la condition est temporaire, le serveur peut indiquer via le champ d'en-tête Retry-After quand le client peut réessayer la requête.

21.5.2 501 Not Implemented

Le serveur ne prend pas en charge les fonctionnalités nécessaires pour satisfaire la requête. C'est la réponse appropriée lorsqu'un UAS ne reconnaît pas la méthode de requête et ne peut la prendre en charge pour aucun utilisateur. (Un proxy transmet toutes les requêtes quelle que soit la méthode.)

Notez que si le serveur reconnaît la méthode de requête mais qu'elle n'est pas autorisée ou prise en charge, un 405 (Method Not Allowed) est envoyé.

21.5.3 502 Bad Gateway

Le serveur, agissant en tant que passerelle ou proxy, a reçu une réponse non valide du serveur en aval auquel il a accédé pour satisfaire la requête.

21.5.4 503 Service Unavailable

Le serveur est temporairement incapable de traiter la requête en raison d'une surcharge temporaire ou d'une maintenance du serveur. Le serveur peut indiquer via le champ d'en-tête Retry-After quand le client doit réessayer la requête. En l'absence de Retry-After, le client doit agir comme s'il avait reçu une réponse 500 (Server Internal Error).

Le client (proxy ou UAC) ayant reçu un 503 (Service Unavailable) doit tenter de transmettre la requête à un serveur alternatif. Il ne doit pas transmettre d'autres requêtes à ce serveur pendant la période spécifiée (le cas échéant) dans le champ d'en-tête Retry-After.

Le serveur peut rejeter la connexion ou ignorer la requête au lieu de répondre avec 503 (Service Unavailable).

21.5.5 504 Server Time-out

Le serveur n'a pas reçu de réponse en temps utile du serveur externe auquel il a accédé pour traiter la requête. Si aucune réponse n'a été reçue dans la période spécifiée par le champ d'en-tête Expires du serveur en amont, un 408 (Request Timeout) doit être utilisé à la place.

21.5.6 505 Version Not Supported

Le serveur ne prend pas en charge ou refuse de prendre en charge la version du protocole SIP utilisée dans la requête. Le serveur indique qu'il ne peut ou ne veut pas compléter la requête en utilisant la même version majeure que le client, sauf pour ce message d'erreur.

21.5.7 513 Message Too Large

Le serveur n'a pas pu traiter la requête parce que la longueur du message dépassait sa capacité.

21.6 Échec global 6xx

Les réponses 6xx indiquent que le serveur a des informations définitives concernant un utilisateur particulier, et pas seulement l'instance particulière indiquée par le Request-URI.

21.6.1 600 Busy Everywhere

Le système terminal du correspondant est correctement connecté, mais le correspondant est occupé et ne souhaite pas accepter d'autre appel pour le moment. La réponse peut indiquer un meilleur moment d'appel via le champ d'en-tête Retry-After. Si le correspondant ne veut pas révéler la raison du refus d'appel, il utilise à la place le code d'état 603 (Decline). Cette réponse d'état n'est renvoyée que si le client sait que d'autres points de terminaison (comme un système de messagerie vocale) ne répondront pas à la requête. Sinon, un 486 (Busy Here) doit être renvoyé.

21.6.2 603 Decline

La machine du correspondant est correctement connectée, mais l'utilisateur a explicitement refusé de participer ou ne le peut pas. La réponse peut indiquer un meilleur moment d'appel via le champ d'en-tête Retry-After. Cette réponse d'état n'est renvoyée que si le client sait que d'autres points de terminaison ne répondront pas à la requête.

21.6.3 604 Does Not Exist Anywhere

Le serveur a des informations faisant autorité que l'utilisateur indiqué par le Request-URI n'existe nulle part.

21.6.4 606 Not Acceptable

L'agent utilisateur de l'utilisateur est correctement connecté, mais certains aspects de la description de session, tels que le média demandé, la bande passante ou le style d'adressage, n'ont pas été acceptés.

Une réponse 606 (Not Acceptable) signifie que l'utilisateur souhaite communiquer mais ne peut pas prendre en charge de manière adéquate la session décrite. Une réponse 606 (Not Acceptable) peut inclure une liste de raisons dans le champ d'en-tête Warning expliquant pourquoi la session décrite ne peut pas être prise en charge. Les codes de raison Warning sont listés dans la section 20.43.

Il est souhaitable que la négociation ne soit pas fréquemment nécessaire. Et lorsqu'un nouvel utilisateur est invité à une conférence existante, la négociation peut être impossible. Il est de la responsabilité de l'initiateur de l'invitation de décider s'il faut agir sur la base d'une réponse 606 (Not Acceptable).

Cette réponse d'état n'est renvoyée que si le client sait que d'autres points de terminaison ne répondront pas à la requête.