loader image
01 60 12 76 80

Services

Offres

Teqtel

Contact

Demander un devis
01 60 12 76 80

Documentation

Comprendre la VOip

Codes de réponses SIP

Les codes de réponse SIP reprennent et étendent les codes de réponse HTTP/1.1. Certains codes HTTP/1.1 sont cependant inappropriés et seuls ceux qui sont utiles sont décrits. Une nouvelle classe de codes (6xx) est apportée par SIP.

Provisional (1xx)

Requêtes reçues et en cours de traitement

Cette réponse indique que la requête a été reçue par le serveur suivant et qu’une action doit être réalisée pour les besoins de l’appel (par exemple la consultation du solde d’un compte SIP). Cette réponse, comme toutes les autres réponses de classe 1xx met fin aux retransmissions éventuelles de requêtes INVITE par un client UAC.
Le client qui a reçu la requête INVITE présente l’appel à l’utilisateur. Cette réponse peut-être utilisée pour transmettre une tonalité de sonnerie distante lorsqu’elle comprend une description de session.

Un serveur peut utiliser ce code de réponse pour indiquer que l’appel a fait l’objet d’un renvoi vers une ou plusieurs destinations.

L’appelé est temporairement indisponible mais le serveur a décidé de placer l’appel en file d’attente plutôt que de le rejeter. Lorsque l’appelé est à nouveau disponible, une indication de l’état est communiquée. Il est possible de fournir des informations plus précises telles que le nombre d’appels en attente et le temps estimé avant réponse. Plusieurs messages 182 Queued peuvent se succéder pour un même appel de façon à informer l’appelant de la progression de son appel.

La réponse 183 Session Progress est utilisée pour communiquer des informations sur l’avancement de la session non couvertes par les autres codes 1xx. Un texte explicatif, les champs d’en-tête et le corps du message peuvent être utilisés pour fournir ces informations.

Success (2xx)​

La requête a été traitée avec succès.​

La réponse 200 OK confirme que le traitement de la requête est effectué avec succès. Les informations accompagnant la réponse dépendent de la méthode utilisée pour la requête.

La réponse 202 confirme l’acceptation d’une requête. Le code 202 Accepted a la même signification que celle définie dans HTTP/1.1. Ce code de réponse a été ajouté par la RFC3265.

Redirection (3xx)

Les réponses 3xx fournissent des informations relatives à la nouvelle localisation de l'utilisateur appelé ou à des services alternatifs à même de satisfaire la demande.

La résolution de l’adresse présente dans la requête a fourni plusieurs choix à des localisations différentes et le client peut sélectionner l’une d’elles en redirigeant sa demande au bon endroit. La réponse peut inclure un corps de messages contenant une liste de caractéristiques de ressources et de localisations parmi lesquelles le client choisira la plus appropriée.

L’utilisateur ne peut plus être joint à l’adresse indiquée (URI) et le demandeur devrait essayer à nouveau à l’adresse fournie dans le champ Contact de l’entête.
L’utilisateur devrait renvoyer la requête à la nouvelle adresse fournie dans le champ Contact de l’entête. La durée pendant laquelle le correspondant peut-être joint à la nouvelle adresse est fournie dans le champ Expires de l’entête. Si aucune durée n’est fournie, la nouvelle adresse est considérée comme valide uniquement pour l’appel en cours.
La ressource demandée doit être utilisée au travers du proxy indiqué dans le champ Contact.
L’appel n’a pu aboutir mais des services alternatifs restent possibles. Les services alternatifs sont décrits dans le corps du message de la réponse.

Request Failure (4xx)​

Les réponses de la classe 4xx caractérisent un échec de la tentative de réalisation de la requête. La requête ne devrait pas être renvoyée sans modification (par exemple l'authentification ou la modification de la période d'expiration de la session). Il est néanmoins possible que la même requête puisse être traitée avec succès par un autre serveur.

La requête n’a pas été comprise car elle comporte une syntaxe mal formée. Le texte informatif joint à la réponse devrait identifier le problème détecté et fournir des détails tels que “Missing Call-ID header field” [Champ Call-ID manquant dans l’entête]
La requête nécessite une authentification de l’utilisateur. Cette réponse est fournie par le serveur d’enregistrement (Registrar) tandis que la réponse 407 Proxy Authentication Required est utilisée par les serveurs Proxy.
L’utilisateur ne dispose pas d’un crédit suffisant pour que la requête soit réalisée.
Le serveur a compris la requête mais refuse de la réaliser. La requête ne devrait pas être répétée.
Le serveur a la certitude que l’utilisateur appelé n’existe pas dans le domaine spécifié dans le Request-URI. Cette réponse est également renvoyée lorsque le domaine présent dans le Request-URI ne correspond à aucun des domaines gérés par le récepteur de la requête.
Ce code est similaire à 401 Unauthorized mais il indique au client qu’il doit s’authentifier lui même auprès du Proxy. Ce code de réponse peut être utilisé pour des applications où l’accès à un canal de communication (par exemple une passerelle téléphonique) nécessite une authentification.
Le serveur n’a pas pu produire une réponse dans un délai convenable, par exemple, s’il n’a pas pu localiser un utilisateur à temps. Le client peut répeter la requête ultérieurement sans modification.

La ressource requise n’est plus disponible sur le serveur et aucun adresse de renvoi n’est connue.

Cette condition est supposée permanente. Si le serveur ne sait pas ou n’a aucun moyen de déterminer si la condition est permanente, le code de retour 404 Not Found devrait être utilisé à la place.

Le serveur refuse de traiter la requête car le corps de l’entité est plus grand que ce que le serveur veut bien ou est capable de traiter. Le serveur devrait fermer la connexion afin d’empêcher le client de continuer la demande.

Si la condition est temporaire, le serveur devrait inclure un champ Retry-After dans l’entête pour indiquer que c’est temporaire et après quel délai le client pourrait essayer à nouveau.

Le serveur refuse de traiter la requête car le champ Request-URI est plus long que ce qu’il est prêt à traiter.
Le serveur refuse de traiter la demande car le corps du message est dans un format non supporté par le serveur pour la méthode requise. Le serveur doit retourner une liste de formats acceptables en utilisant les champs d’entête Accept, Accept-Encoding ou Accept-Language, suivant la spécificité du problème avec le contenu.
Le serveur ne peut traiter la requête car le plan de l’URI dans le champ Request-URI est inconnu du serveur.
Le serveur n’a pas compris l’extension du protocole spécifiée dans le champ d’entête Proxy-Require ou Require. Le serveur doit inclure une liste d’extension non supportées dans un champ d’entête Unsupported dans la réponse.
Le serveur a besoin d’une extension particulière pour traiter la demande, mais cette extension n’est pas listée dans le champ d’entête Supported de la requête. Les réponses avec ce code de réponse doivent contenir un champ d’entête Require listant les extensions requises.
Le serveur rejette la requête car la durée d’expiration de la ressource reffraichie par la requête est trop brève. Cette réponse peut-être utilisée par un serveur d’enregistrement (Registrar) pour rejeter un enregistrement dont la durée d’expiration est trop courte.
Le système associé à l’appelé a bien été contacté mais l’appelé est présentement indisponible (par exemple, non enregistré). La réponse peut indiquer un meilleur moment pour appeler dans le champ d’entête Retry-After.
Ce code indique que le serveur a reçu une requête qui ne correspond à aucun dialogue ou transaction existants.
Le serveur a détecté une boucle.
Le serveur a reçu une requête qui contient un champ d’entête Max-Forwards égal à zéro.
Le serveur a reçu une requête comprenant un Request-URI incomplet. Le texte informatif devrait donner des informations additionnelles dans la réponse.
Le Request-URI est ambigu. La réponse peut contenir une liste d’adresses ambigües possibles.
Le système associé à l’appelé a bien été contacté mais l’appelé ne souhaite pas recevoir ou n’est pas en mesure de recevoir de nouveaux appels. La réponse peut indiquer un meilleur moment pour appeler dans le champ d’en-tête Retry-After. L’utilisateur peut également être disponible ailleurs, tel que par l’intermédiaire d’un service de messagerie vocale.
La requête a été terminée par une requête BYE ou CANCEL.
Cette réponse a la même signification que 606 Not Acceptable, mais elle s’applique seulement aux ressources spécifiques adressées par le Request-URI tandis que le même requete pourrait être traitée avec succès ailleurs. Un corps de message contenant une description des capacités média peut être présent dans la réponse qui est formattée selon le champ d’entête Accept dans l’INVITE.
La requête a été reçue par le serveur qui a déjà une requête en attente pour le même dialogue.
La requête a été reçue par un serveur avec un corps MIME crypté qu’il ne sais pas déchiffrer ou pour lequel il ne possède pas la clé de décryptage.

Server Failure (5xx)

Les réponses de classe 5xx sont renvoyées lorsque le serveur rencontre un problème pour traiter la requête.

Le serveur a rencontré un problème inattendu qui ne lui permet pas de traiter la requête. Si le problème est temporaire, le client peut renouveler la requête en utilisant la valeur du champ d’entête Retry-After.
Le serveur ne supporte pas la fonctionnalité demandée pour accomplir la requête. Cette réponse est renvoyée lorsque le serveur ne reconnaît pas la méthode présente dans la requête. Il est à noter que la réponse 405 Method Not Allowed en renvoyée lorsque le serveur reconnaît la méthode mais que celle-ci n’est pas supportée.
Le serveur, agissant en qualité de passerelle ou de proxy, a reçu une reponse non valide du serveur en aval auquel il a tenté d’accéder pour traiter la requête.

Le serveur est temporairement dans l’incapacité de traiter la requête par suite d’une surcharge ou d’une opération de maintenance. Le serveur peut indiquer au client un délai dans le champ d’entête Retry-After pour renouveler sa demande. Si aucun champ Retry-After n’est fourni, le client doit considérer qu’il a reçu une réponse 500 Internal Server Error.

Un client ayant reçu une réponse 503 Service Unavailable devrait tenter d’envoyer la requête à un serveur alternatif. Il ne doit pas renvoyer la requête au serveur initial avant la durée spécifiée dans le champ d’entête Retry-After, s’il est présent.

Le serveur n’a pas reçu de réponse d’un autre serveur externe dans le délai imparti pour traiter la requête. La réponse 408 Request Timeout devrait être utilisée à la place si aucune réponse n’est rénvoyée par le serveur en amont dans le délai spécifié dans le champ d’entête Expires.
Le serveur ne supporte pas ou refuse de supporter la version du protocole SIP utilisée dans la raquête. Le serveur indique qu’il est incapacble ou ne souhaite pas traiter la requête en utilisant la même version majeure que le client, autrement qu’en retournant cette réponse.
Le serveur a été dans l’incapacité de traiter la requête car la longueur du message reçu dépasse ses capacités de traitement.

Global Failures (6xx)

Les réponses de la classe 6xx indiquent que le serveur a des informations définitives pour un utilisateur particulier et pas seulement pour une instance particulière identifiée par le Request-URI.

Le système final où se trouve l’appelé a bien été contacté mais l’appelé est occupé et ne souhaite pas prendre l’appel à cet instant. La réponse peut indiquer un meilleur moment pour appeler dans le champ d’entête Retry-After. Si l’appelé ne souhaite pas révéler la raison du rejet de l’appel, le code de retour 603 Decline doit être utilisé à la place.

Ce code de réponse doit seulement être retourné si le client ne connait pas d’autre point de terminaison (tel qu’une messagerie vocale) qui pourrait répondre. Dans le cas contraire, la réponse 486 Busy Here devrait être retournée.

L’équipement de l’appelé a bien été contacté mais l’utilisateur ne souhaite pas ou ne peut pas participer. La réponse peut indiquer un meilleur moment pour appeler dans le champ d’entête Retry-After. Ce code de réponse est seulement rétourné lorsque le client sait qu’aucun autre point de terminaison ne peut répondre à la requête.
Le serveur a une information l’autorisant à répondre que l’utilisateur indiqué dans le Request-URI n’existe nulle part ailleurs.

L’utilisateur a été contacté avec succès mais certains aspects de la description de session tels que le média, la bande passante ou le mode d’adressage n’étaient pas acceptables.

Une réponse 606 Not Accetable signifie que l’utilisateur souhaite effectivement communiquer mais pas en supportant la session décrite. La réponse 606 Not Acceptable peut contenir une liste de raisons dans le champs d’entête Warning dévrivant les raisons pour lesquelles la session décrite ne peut être supportée.

Un corps de message contenant la description des capacités media peut être présente dans la réponse qui est formatée selon le champ d’entête Accept de l’INVITE.

Il est supposé que la négociation ne sera pas fréquemment nécessaire et que lorsqu’un nouvel utilisateur sera invité à joindre une conférence existante, la négociation pourrait ne pas être possible. Ce sera à l’initiateur de la conférence de décider d’agir ou non sur une réponse 606 Not Acceptable.

Ce code de réponse est retourné seulement lorsque le client sait qu’aucune autre terminaison ne peut répondre à la requête.

© 2025 Agence la chamade - Mentions légales