|
|
Entête SIP
|
| SIP 100 | Essai | Cette réponse indique que la demande a été reçue par le serveur du saut suivant et qu'une certaine action non spécifiée est en train d'être effectuée au titre de cet appel (par exemple, une base de données est consultée). Cette réponse, comme toutes les autres réponses provisoires, arrête les retransmissions d'un INVITE par un UAC. La réponse 100 (En cours d'essai) est différente des autres réponses provisoires, en ce qu'elle n'est jamais transmise vers l'amont par un mandataire à états pleins. |
| SIP 180 | Sonnerie en cours | L'agent utilisateur qui reçoit l'INVITE est en train d'essayer d'alerter l'utilisateur. Cette réponse peut être utilisée pour initialiser la sonnerie de retour d'appel locale. |
| SIP 181 | L'appel est en cours de transmission | Un serveur peut utiliser ce code d'état pour indiquer que l'appel est en train d'être retransmis à un ensemble de destinations différent. |
| SIP 182 | En file d'attente | Le demandé est temporairement indisponible, mais le serveur a décidé de mettre l'appel en file d'attente plutôt que de le rejeter. Lorsque l'appelé devient disponible, il retournera la réponse d'état finale appropriée. La phrase de cause peut donner plus de précisions sur l'état de l'appel, par exemple, "5 appels en file d'attente ; le temps d'attente prévu est de 15 minutes". Le serveur peut produire plusieurs réponses 182 (En file d'attente) pour tenir l'appelant au courant de l'état de l'appel en file d'attente. |
| SIP 183 | Avancement de la session | La réponse 183 (Avancement de la session) est utilisée pour porter des informations sur la progression de l'appel qui n'est pas autrement classifiée. La phrase de cause, le champ d'en-tête, ou le corps de message peuvent être utilisés pour porter plus de précisions sur la progression de l'appel |
2xx Réussite
La demande a réussi.
| SIP 200 | OK | La demande a réussi. Les informations retournées avec la réponse dépendent de la méthode utilisée dans la demande. |
| SIP 202 |
Accepted |
3xx Réorientation
Les réponses 3xx donnent des informations sur la nouvelle localisation de l'utilisateur, ou sur des services de remplacement qui pourraient être capables de satisfaire à l'appel.
| SIP 300 | Choix multiples | L'adresse dans la demande
peut se résoudre en plusieurs choix, chacun avec sa
propre localisation spécifique, et l'utilisateur (ou agent utilisateur) peut
choisir un point de terminaison de communication préféré et rediriger sa demande
sur cette localisation. La réponse peut inclure un corps de message contenant une liste de caractéristiques et localisation(s) de ressources à partir desquelles l'utilisateur ou agent utilisateur peut choisir la plus appropriée, si c'est permis par le champ d'en-tête Accept de la demande. Cependant, aucun type MIME n'a été défini pour ce corps de message. Les choix devraient aussi être énumérés comme champs Contact. A la différence de HTTP, la réponse SIP peut contenir plusieurs champs Contact ou une liste d'adresses dans un champ Contact. Les agents d'utilisateur peuvent utiliser la valeur du champ d'en-tête Contact pour une redirection automatique ou peuvent demander à l'utilisateur de confirmer un choix. Cependant, la présente spécification ne définit aucune norme pour une telle sélection automatique. Cette réponse d'état est appropriée si l'appelé peut être joint à plusieurs localisations différentes et le serveur ne peut pas ou préfère ne pas mandater la demande. |
| SIP 301 | Déplacement définitif | L'utilisateur ne peut plus être joint à l'adresse figurant dans l'URI-de-demande, et le client demandeur devrait réessayer à la nouvelle adresse donnée par le champ d'en-tête Contact. Le demandeur devrait mettre à jour tout répertoire local, carnet d'adresses, et mémoires caches de localisation d'utilisateur avec cette nouvelle valeur et rediriger les demandes futures sur la ou les adresses listées. |
| SIP 302 | Temporairement déplacé | Le client demandeur
devrait réessayer la demande à la ou aux nouvelles adresses
données par le champ d'en-tête Contact. L'URI-de-demande de
la nouvelle demande 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 par un champ d'en-tête Expires ou un paramètre expires dans le champ d'en-tête Contact. Les mandataires et les agents d'utilisateur peuvent tous deux mettre cet URI en mémoire cache pour la durée du délai d'expiration. Si il n'y a pas de délai d'expiration explicite, l'adresse n'est valide pour recommencer qu'une seule fois, et NE doit PAS être cachée pour des transactions ultérieures. Si l'URI caché tiré du champ d'en-tête Contact échoue, l'URI-de-demande de la demande redirigée peut être essayé encore une seule fois. L'URI temporaire peut être périmé plus tôt que le délai d'expiration, et un nouvel URI temporaire peut être disponible. |
| SIP 305 | Utiliser un mandataire | On doit accéder à la ressource demandée par l'intermédiaire du mandataire donné par le champ Contact. Le champ Contact donne l'URI du mandataire. Le receveur est censé répéter cette seule demande via le mandataire. Les réponses 305 (Utiliser un mandataire) DOIVENT être générées par les seuls UAS. |
| SIP 380 | Service de remplacement | L'appel n'a pas réussi, mais des services de remplacement sont possibles. Les services de remplacement sont décrits dans le corps de message de la réponse. Les formats pour de tels corps ne sont pas définis ici, et pourront être le sujet d'une normalisation future. |
4xx Défaillance de la demande
Les réponses 4xx sont des réponses d'échec bien déterminées provenant d'un serveur particulier. Le client NE devrait PAS réessayer la même demande sans modification (par exemple, en ajoutant l'autorisation appropriée). Cependant, la même demande sur un serveur différent pourrait réussir.
| SIP 400 | Mauvaise demande | La demande n'a pas pu être comprise à cause d'une syntaxe mal formée. La phrase de cause devrait identifier le problème de syntaxe plus en détail, par exemple, "Champ d'en-tête Call-ID manquant". |
| SIP 401 | Non autorisé | La demande exige une authentification de l'utilisateur. Cette réponse est produite par les UAS et registraires, alors que la réponse 407 (Authentification du mandataire exigée) est utilisée par les serveurs mandataires. |
| SIP 402 | Payement exigé | Réservé pour utilisation future. |
| SIP 403 | Interdit | Le serveur comprend la demande, mais refuse d'y satisfaire. L'autorisation n'y fera rien, et la demande NE devrait PAS être répétée. |
| SIP 404 | Pas trouvé | Le serveur a des informations certaines que l'utilisateur n'existe pas au domaine spécifié dans l'URI-de-demande. Cet état est aussi retourné si le domaine dans l'URI-de-demande ne correspond à aucun des domaines traités par le receveur de la demande. |
| SIP 405 | Méthode non autorisée | La méthode spécifiée dans la ligne de demande est comprise, mais non autorisée
pour l'adresse identifiée par l'URI-de-demande. La réponse doit inclure un champ d'en-tête Allow contenant une liste de méthodes valides pour l'adresse indiquée. |
| SIP 406 | Non acceptable | La ressource identifiée par la demande est seulement capable de générer des entités de réponse qui ont des caractéristiques de contenu non acceptables en fonction du champ d'en-tête Accept envoyé dans la demande. |
| SIP 407 | Authentification du mandataire requise |
Ce code est similaire à 401 (Non autorisé), mais indique que le client
doit d'abord s'authentifier avec le mandataire. Ce code d'état peut être utilisé pour des applications où, plutôt que le demandé, l'accès au canal de communication (par exemple, une passerelle de téléphonie) exige l'authentification. |
| SIP 408 | Expiration du délai de demande | Le serveur n'a pas pu produire une réponse dans le délai requis, par exemple, s'il n'a pas pu déterminer la localisation de l'utilisateur dans les temps. Le client peut répéter la demande sans modifications à tout moment ultérieurement. |
| SIP 410 | Parti | La ressource demandée n'est plus disponible au serveur et aucune adresse de retransmission n'est connue. Cette condition est supposée être permanente. Si le serveur ne connaît pas, ou n' aucune facilite pour déterminer si la condition est permanente ou non, c'est le code d'état 404 (Non trouvé) qui devrait être utilisé à la place. |
| SIP 412 | Conditional Request Failed | |
| SIP 413 | Entité de demande trop longue | Le serveur refuse de traiter une demande parce que l'entité corps de la demande
est supérieure à ce que le serveur est désireux ou capable de traiter. Le
serveur peut fermer la connexion pour empêcher le client de continuer la
demande. Si la condition est temporaire, le serveur devrait inclure un champ d'en-tête Retry-After pour indiquer qu'elle est temporaire et après quel délai le client peut réessayer. |
| SIP 414 | URI de demande trop long | Le serveur refuse de servir la demande car l'URI-de-demande est plus long que ce que le serveur désire interpréter. |
| SIP 415 | Type de support non accepté | Le serveur refuse de servir la demande parce que le corps de message de la demande est dans un format qui n'est pas accepté par le serveur pour la méthode demandée. Le serveur doit retourner une liste de formats acceptables en utilisant les champs d'en-tête Accept, Accept-Encoding, ou Accept-Language, selon le problème spécifique du contenu. |
| SIP 416 | Schéma d'URI non accepté | Le serveur ne peut pas traiter la demande parce que le schéma de l'URI dans l'URI-de-demande est inconnu du serveur. |
| SIP 417 | Unknown Resource-Priority | |
| SIP 420 | Mauvaise extension | Le serveur n'a pas compris l'extension de protocole spécifiée dans un champ d'en-tête Proxy-Require ou Require. Le serveur doit inclure une liste des extensions non prises en charge dans un champ d'en-tête Unsupported dans la réponse. |
| SIP 421 | Extension requise |
L'UAS a besoin d'une extension particulière pour traiter la demande,
mais cette extension ne figure pas dans la liste du champ d'en-tête
Supported dans la demande. Les réponses avec ce code d'état DOIVENT
contenir un champ d'en-tête Require faisant la liste des extensions
requises. Un UAS NE devrait utiliser cette réponse que s'il ne peut vraiment fournir aucun service utile au client. Au lieu de cela, si une extension souhaitable ne figure pas sur la liste du champ d'en-tête Supported, les serveurs devraient traiter la demande en utilisant les capacités SIP de base et toute extension acceptée par le client. |
| SIP 422 | Session Interval Too Small | |
| SIP 423 | Intervalle trop bref | Le serveur rejette la demande parce que le délai d'expiration des ressources rafraîchi par la demande est trop court. Cette réponse peut être utilisée par un registraire pour rejeter un enregistrement dont le délai d'expiration du champ d'en-tête Contact est trop bref. |
| 428 | Use Identity Header | |
| 429 | Provide Referrer Identity | |
| 433 | Anonymity Disallowed | |
| 436 | Bad Identity-Info | |
| 437 | Unsupported Certificate | |
| 438 | Invalid Identity Header | |
| 440 | Max-Breadth Exceeded | |
| 470 | Consent Needed | |
| SIP 480 | Temporairement indisponible | Le système de terminaison du demandé a été contacté avec succès mais le demandé
est actuellement indisponible (par exemple, il n'est pas enregistré, ou bien il
est enregistré mais se trouve dans un état qui empêche les communications avec
l'appelé, ou il a activé le dispositif "ne pas déranger"). La réponse
peut
indiquer un meilleur moment pour appeler dans le champ d'en-tête Retry-After.
L'utilisateur peut aussi être disponible ailleurs (à l'insu de ce serveur). La
phrase de cause devrait indiquer une raison plus précise comme pourquoi l'appelé
est indisponible. Cette valeur devrait être réglable par l'agent utilisateur.
L'état 486 (Occupé ici) peut être utilisé pour indiquer plus précisément une
raison particulière pour l'échec de l'appel. Cet état est aussi retourné par une redirection ou un serveur mandataire qui reconnaît l'utilisateur identifié par l'URI-de-demande, mais n'a pas actuellement de localisation de retransmission valide pour cet utilisateur. |
| SIP 481 | L'appel/transaction n'existe pas | Cet état indique que l'UAS a reçu une demande qui ne correspond à aucun dialogue ou transaction existant. |
| SIP 482 | Boucle détectée | Le serveur a détecté une boucle. |
| SIP 483 | Trop de bonds | Le serveur a reçu une demande qui contient un champ d'en-tête Max-Forwards avec la valeur zéro. |
| SIP 484 | Adresse incomplète | Le serveur a reçu une demande avec un URI-de-demande incomplet. Des informations
supplémentaires devraient être fournies dans la phrase de cause. Ce code d'état permet la numérotation en recouvrement. Avec la numérotation en recouvrement, le client ne connaît pas la longueur de la chaîne de numérotation. Il envoie des chaînes de longueur croissante, pressant l'utilisateur d'envoyer des entrées supplémentaires, jusqu'à ce qu'il ne reçoive plus de réponse d'état 484 (Adresse incomplète). |
| SIP 485 | Ambiguïté | L'URI-de-demande est ambigu. La réponse
peut contenir une liste d'adresses
possibles non ambiguës dans le champ d'en-tête Contact. Révéler les solutions de
remplacement peut porter une atteinte à la vie privée de l'utilisateur ou de
l'organisation. Il doit être possible de configurer un serveur pour qu'il
réponde par l'état 404 (Pas trouvé) ou de supprimer la liste des choix possibles
pour les URI-de-demande ambigus. Exemple de réponse à une demande avec l'URI-de-demande sip:lee@example.com : SIP/2.0 485 Ambigu Contact: Carol Lee <sip:carol.lee@example.com> Contact: Ping Lee <sip:p.lee@example.com> Contact: Lee M. Foote <sips:lee.foote@example.com> Certains systèmes de messagerie électronique et de messagerie vocale fournissent cette fonction. Un code d'état distinct de 3xx est utilisé dans la mesure où les sémantiques sont différentes : pour 300, il est supposé que la même personne ou service sera joint par les choix fournis. Alors qu'un choix automatisé ou une recherche séquentielle a un sens pour une réponse 3xx, une intervention de l'utilisateur est requise pour une réponse 485 (Ambigu). |
| SIP 486 | Occupé ici | Le système de terminaison de l'appelé a été contacté avec succès, mais l'appelé ne peut ou ne veut pas actuellement prendre un appel supplémentaire sur ce système de terminaison. La réponse peut indiquer un meilleur moment pour appeler dans le champ d'en-tête Retry-After. L'utilisateur pourrait aussi être disponible ailleurs, comme sur un service de messagerie vocale. L'état 600 (Occupé partout) devrait être utilisé si le client sait qu'aucun autre système de terminaison ne sera capable d'accepter cet appel. |
| SIP 487 | Demande terminée | La demande a été terminée par un BYE ou une demande CANCEL. Cette réponse n'est jamais retournée pour une demande CANCEL elle-même. |
| SIP 488 | Non acceptable ici | La réponse a la même signification que 606 (Non acceptable), mais s'applique
seulement aux ressources spécifiques adressées par l'URI-de-demande et la
demande peut réussir ailleurs. Un corps de message qui contient une description de capacités support peut être présente dans la réponse, qui est formatée conformément au champ d'en-tête Accept dans l'INVITE (ou l'application/sdp si il n'est pas présent), comme un corps de message dans une réponse 200 (OK) à une demande OPTIONS. |
| 489 | Bad Event | |
| SIP 491 | Demande en cours | La demande a été reçue par un UAS qui avait une demande en cours dans le même dialogue. |
| SIP 493 | Indéchiffrable | La demande a été reçue par un UAS qui contenait un corps MIME chiffré pour lequel le receveur ne possède pas ou ne fournira pas de clé de déchiffrement appropriée. Cette réponse peut avoir un seul corps contenant une clé publique appropriée qui devrait être utilisée pour chiffrer les corps MIME envoyés à cet agent utilisateur. |
| 494 | Security Agreement Required |
5xx Défaillance de serveur
Les réponses 5xx sont des réponses d'échec qui indique que le serveur lui-même s'est trompé.
| SIP 500 | Erreur interne du serveur | Le serveur a rencontré une condition inattendue qui l'a empêché de satisfaire la
demande. Le client peut afficher la condition d'erreur spécifique et peut
réessayer la demande après plusieurs secondes. Si la condition est temporaire, Le serveur peut indiquer quand le client peut réessayer la demande en utilisant le champ d'en-tête Retry-After. |
| SIP 501 | Non mis en oeuvre | Le serveur ne prend pas en charge la fonctionnalité requise pour satisfaire la
demande. C'est la réponse appropriée lorsqu'un UAS ne reconnaît pas la méthode
de demande et n'est pas capable de la prendre en charge pour les utilisateurs.
(Les mandataires transmettent toutes les demandes sans considération de la
méthode.) Noter qu'une réponse 405 (Méthode non admise) est envoyée lorsque le serveur reconnaît la méthode de demande, mais que cette méthode est non autorisée ou non prise en charge. |
| SIP 502 | Mauvaise passerelle | Le serveur, alors qu'il agit comme une passerelle ou un mandataire, a reçu une réponse invalide de la part du serveur aval auquel il a accédé en essayant de satisfaire la demande. |
| SIP 503 | Service indisponible | Le serveur est temporairement incapable de traiter la demande du fait d'une
surcharge temporaire ou de la maintenance du serveur. Le serveur peut indiquer
quand le client devrait réessayer la demande dans un champ d'en-tête Retry-After.
Si aucun Retry-After n'est donné, le client doit agir comme s'il avait reçu une
réponse 500 (Erreur interne du serveur). Un client (mandataire ou UAC) recevant une 503 (Service indisponible) devrait essayer de transmettre la demande sur un serveur de remplacement. Il NE devrait PAS transmettre d'autres demandes à ce serveur pour la durée spécifiée dans le champ d'en-tête Retry-After, s'il est présent. Les serveurs peuvent refuser la connexion ou abandonner la demande au lieu de répondre avec 503 (Service indisponible). |
| SIP 504 | Expiration du délai de serveur | Le serveur n'a pas reçu de réponse dans les temps d'un serveur externe auquel il a accédé en essayant de traiter la demande. La réponse 408 (Expiration du délai de réponse) devrait être utilisée à la place s'il n'y a pas de réponse dans la période spécifiée dans le champ d'en-tête Expires de la part du serveur amont. |
| SIP 505 | Version non acceptée | Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version de protocole SIP qui a été utilisée dans la demande. Le serveur indique qu'il n'est pas en mesure ou ne veut pas achever la demande en utilisant la même version majeure que le client, autrement qu'avec ce message d'erreur. |
| SIP 513 | Message trop long | Le serveur n'a pas été capable de traiter la demande car la longueur du message excède ses capacités. |
| 580 | Precondition Failure |
6xx Echecs totaux
Les réponses 6xx indiquent qu'un serveur a des informations certaines sur un utilisateur particulier, et non pas seulement sur l'instance particulière indiquée dans l'URI-de-demande.
| SIP 600 | Occupé partout | Le système de terminaison de l'appelé a été contacté avec succès mais l'appelé est occupé et ne souhaite pas prendre l'appel en ce moment. La réponse peut indiquer un meilleur moment pour appeler dans le champ d'en-tête Retry-After. Si l'appelé ne souhaite pas révéler la raison pour laquelle il décline l'appel, il utilise à la place le code d'état 603 (Refus). Cette réponse d'état n'est retournée que si le client sait qu'aucun autre point d'extrémité (tel qu'une messagerie vocale) ne répondra à la demande. Autrement, 486 (Occupé ici) devrait être retournée. |
| SIP 603 | Refus | La machine de l'appelé a été contactée avec succès mais l'utilisateur souhaite explicitement ne pas participer , ou ne le peut pas. La réponse peut indiquer un meilleur moment pour appeler dans le champ d'en-tête Retry-After. Cette réponse d'état n'est retournée que si le client sait qu'aucun autre point d'extrémité ne répondra à la demande. |
| SIP 604 | N'existe nulle part | Le serveur a des informations certaines que l'utilisateur indiqué dans l'URI-de-demande n'existe nulle part. |
| SIP 606 | Non acceptable | L'agent d'utilisateur a été contacté avec succès mais certains aspects de la
description de session, tels que le support demandé, la bande passante, ou le
style d'adressage ne sont pas acceptables. Une réponse 606 (Non acceptable) signifie que l'utilisateur souhaite communiquer, mais ne peut pas prendre en charge de façon adéquate la session décrite. La réponse 606 (Non acceptable) peut contenir une liste des raisons dans un champ d'en-tête Warning décrivant pourquoi la session décrite ne peut être prise en charge. Un corps de message contenant une description des capacités support peut être présente dans la réponse, et elle est formatée conformément au champ d'en-tête Accept dans l'INVITE (ou l'application/sdp si elle n'est pas présente), identique au corps de message dans une réponse 200 (OK) à une demande OPTIONS. Il est souhaité qu'il ne soit pas trop fréquemment nécessaire de recourir à la négociation, et quand un nouvel utilisateur est invité à se joindre à une conférence déjà existante, la négociation peut n'être pas possible. Il appartient à l'initiateur de l'invitation de décider d'agir ou non par une réponse 606 (Non acceptable). Cette réponse d'état n'est retournée que si le client sait qu'aucun autre point d'extrémité ne répondra à la demande. |
6 - Discussion autour de la documentation
Vous pouvez poser toutes vos questions, vos remarques et vos expériences à propos de l'entête du protocole SIP. Pour cela, rendez-vous sur le Forum "ToIP - VoIP".
7 - Suivi du document
Le 14 février 2009, par _SebF, création du document.
|
|
|