Réponses SIP
Ce chapitre sera probablement précieux dans une perspective de dépannage et de diagnostic du protocole. On rappellera toutefois que l’implémentation de ces codes dépend surtout du suivi et de la volonté des concepteurs d’application.
Il existe six classes de réponses SIP identifiées par la valeur du premier numéro du code de réponse.
- 1xx “Provisional” : Requête reçue et traitement de la requête.
- 2xx “Success” : L’action a été reçue, comprise et acceptée avec succès.
- 3xx “Redirection” : Une action plus éloignée est nécessaire pour achever la requête.
- 4xx “Client Error” : La requête contient une mauvaise syntaxe ou ne peut pas être prise en charge par le serveur.
- 5xx “Server Error” : Le serveur a échoué à prendre en charge une requête valide.
- 6xx “Global Failure” : La requête ne peut être prise en charge par aucun serveur.
On accordera une attention particulière aux erreurs “4xx Client Error” :
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
- 406 Not Acceptable
- 407 Proxy Authentication Required
- 408 Request Timeout
- 422 Session Timer Interval Too Small
- 423 Interval Too Brief
- 480 Temporarily Unavailable
- 481 Dialog/Transaction Does Not Exist
- 483 Too Many Hops
- 486 Busy Here
- 487 Request Terminated
- 488 Not Acceptable Here
1. Informational (1xx)
Les réponses Informational (1xx) sont utilisées pour indiquer la progression des appels. Normalement, les réactions sont de bout en bout (à l’exception de 100 Trying). L’objectif principal des réponses d’information est d’arrêter la retransmission de demandes INVITE.
Les réponses d’information comprennent les réponses suivantes.
1.1. 100 Trying
Cette réponse est seulement une demande “hop-by-hop” qui doit être “routée”.
Elle n’est jamais transférée et peut contenir un corps de message.
Elle est utilisée pour éviter la retransmission de messages INVITE lors de l’initialisation d’un dialogue.
1.2. 180 Ringing
Cette réponse est utilisée pour indiquer qu’une invitation a été reçue par l’agent utilisateur et que l’alerte est en cours.
1.3. 181 Call is Being Forwarded
Cette réponse est utilisée pour indiquer que l’appel a été transmis à un autre point de terminaison.
Elle est envoyée lorsque l’information peut être utile à l’appelant.
Elle donne le statut de l’appelant, comme par exemple, une opération de transfert allonge le temps de réponse de l’appel.
1.4. 182 Call Queued
Cette réponse est utilisée pour indiquer que le message INVITE a été reçu et que la demande est traitée dans une file d’attente.
1.5. 183 Session Progress
La réponse “183 Session Progress” indique que des informations sur l’état d’avancement d’une session peut être présent dans un corps de message ou flux média.
Contrairement à une réponse “100 Trying”, une réponse “183 Session Progress” est une réponse de bout en bout et établit un dialogue.
Une utilisation typique de cette réponse est de permettre à un UAC d’entendre une sonnerie, une tonalité d’occupation, ou l’annonce enregistrée dans les appels via une passerelle vers le réseau PSTN.
2. Success (2xx)
Cette classe de réponses sert à indiquer qu’une demande a été acceptée. Elle comprend les réponses suivantes.
2.1. 200 OK
200 OK signifie qu’une demande a été acceptée. Il indique une réussite de la demande.
2.2. 202 Accepted
202 Accepted indique qu’un UAS a reçu et compris la demande, mais la demande peut ne pas avoir été autorisée ou traitée par le serveur.
Ce code est couramment utilisé dans les réponses aux méthodes SUBSCRIBE et REFER.
3. Redirection (3xx)
En général, cette classe de réponses est envoyée par les serveurs de redirection en réponse à un INVITE. Ces réponses sont aussi appelées classe de réponses redirigées. Elle comprend les réponses suivantes.
3.1. 300 Multiple Choices
Cette réponse contient plusieurs champs d’en-tête de Contact pour indiquer que le service de localisation a rendu plusieurs emplacements possibles pour l’URI SIP dans la requête URI.
3.2. 301 Moved Permanently
Cette réponse de redirection contient un champ d’en-tête Contact avec la nouvelle URI permanente de la partie appelée.
L’adresse peut être enregistrée et utilisée dans les futures demandes INVITE.
3.3. 302 Moved Temporarily
Cette réponse de redirection contient un URI qui est en cours de validité, mais elle n’est pas permanente. L’emplacement est valable pour la durée du temps spécifié.
3.4. 305 Use Proxy
Cette réponse contient un URI qui pointe vers un serveur proxy ayant des informations faisant autorité sur la partie appelante.
Cette réponse pourrait être envoyée par un UAS utilisant un proxy pour le filtrage d’appel entrant.
3.5. 380 Alternative Service
Cette réponse renvoie un URI qui indique le type de service que la partie appelée souhaite.
Par exemple, un appel pourrait être redirigé vers un serveur de messagerie vocale.
4. Client Error (4xx)
Les réponses d’erreur client indiquent que la demande ne peut être satisfaite et que des erreurs sont identifiées du côté UAC. Les codes de réponse sont généralement envoyés par l’UAS. Lors de la réception d’un message d’erreur, le client doit renvoyer la demande en la modifiant en fonction de la réponse. Voici quelques-unes des réponses importantes 4XX.
4.1. 400 Bad Request
Ce code de réponse indique que la demande n’a pas été comprise par le serveur.
La requête peut manquer de champs d’en-tête nécessaires tels que To, From, Call-ID ou CSeq.
4.2. 401 Unauthorized
Ce message indique que la demande exige que l’utilisateur réalise une authentification.
401 Unauthorized est normalement envoyée par un serveur d’enregistrement de la demande REGISTER.
La réponse contient champ d’en-tête WWW-Authenticate qui demande des informations d’identification correcte de l’agent utilisateur (UA) appelant.
4.3. 403 Forbidden
Le code 403 est envoyé lorsque le serveur a compris la demande, a trouvé que la demande soit formulée correctement, mais qu’il ne pourra pas traiter la demande.
Cette réponse n’est pas utilisée lorsque l’autorisation est nécessaire.
4.4. 404 Not Found
404 Not Found indique que l’utilisateur identifié par l’URI SIP dans la requête ne peut pas être localisé par le serveur.
4.5. 405 Method Not Allowed
405 Method Not Allowed indique que le serveur ou l’agent utilisateur (UA) a reçu et compris une demande mais n’est pas prêt à y répondre.
Exemple: Une demande REGISTER qui est envoyée à un agent utilisateur au lieu d’un serveur REGISTRAR.
Un champ Allow doit être présent dans la réponse pour informer l’UAC quelles méthodes sont acceptables.
4.6. 406 Not Acceptable
Cette réponse indique que la demande ne peut pas être traitée en raison d’une exigence dans le message de demande.
Le champ d’en-tête Accept dans la demande ne contenait aucune des options prises en charge par le UAS.
4.7. 407 Proxy Authentication Required
Cette demande est envoyée par un mandataire (proxy) qui indique que l’UAC doit d’abord s’authentifier auprès du mandataire avant que la demande puisse être traitée.
La réponse devrait contenir des informations sur le type d’informations d’identification requises par le proxy dans un champ d’en-tête Proxy-Authenticate.
La demande peut être présentée à nouveau avec les informations d’identification appropriées dans un champ d’en-tête Proxy-Authorization.
4.8. 408 Request Timeout
Cette réponse est envoyée lorsqu’un champ d’en-tête Expires est présent en une requête INVITE et que la période de temps spécifiée est dépassée.
Ce message peut être envoyé par un proxy ou un fork agent utilisateur.
La demande peut être relancée à tout moment par l’UAC.
4.9. 422 Session Timer Interval Too Small
La réponse est utilisée pour rejeter une demande contenant un champ d’en-tête Session-Expires.
L’intervalle minimum autorisé est indiqué dans le champ d’en-tête requis Min-SE.
L’initiateur de l’appel peut réessayer la demande sans le champ d’en-tête ou avec une valeur Session-Expires inférieure ou égale au minimum spécifié.
4.10. 423 Interval Too Brief
La réponse est renvoyée par un serveur d’enregistrement (REGISTRAR) qui rejette une demande d’enregistrement parce que le délai d’expiration demandé sur un ou plusieurs Contacts est trop court.
La réponse doit contenir un champ d’en-tête Min-Expires qui liste l’intervalle d’expiration minimum que le REGISTRAR acceptera.
4.11. 480 Temporarily Unavailable
Cette réponse indique que la demande a atteint la bonne destination, mais que la partie appelée n’est pas disponible pour une raison quelconque.
La réponse doit contenir un en-tête de Retry-After avoir indiqué lorsque la demande peut être prise en charge.
4.12. 481 Dialog/Transaction Does Not Exist
Cette réponse indique qu’une réponse faisant référence à un appel existant ou d’une transaction a été reçue pour laquelle le serveur n’a pas de session (record) ou d’information d’état.
4.13. 483 Too Many Hops
Cette réponse indique que la demande a été transférée un nombre maximal de fois fixé par l’en-tête Max-Forwards dans la demande.
Ceci est indiqué par la réception d’un Max-Forward fixé à la valeur 0 dans l’en-tête de la demande.
4.14. 486 Busy Here
Cela indique l’agent utilisateur est occupé et qu’il ne peut pas accepter l’appel.
4.15. 487 Request Terminated
Cette réponse peut être envoyée par un UA qui a reçu une demande CANCEL pour une demande INVITE en attente.
Une réponse 200 OK est envoyée pour confirmer (acknowledge) le CANCEL et une réponse 487 est envoyée pour annuler la transaction INVITE.
4.16. 488 Not Acceptable Here
Certains aspects dans la description de la session (SDP) ou dans le Request-URI n’est pas acceptable, au sens où l’utilisateur ne peut pas supporter de manière adéquate la session. Il peut entre autre s’agir d’un problème de Codec.
Par exemple, un UA n’a activé aucun codec dans sa configuaration : sip-488-Not-Acceptable-Here-codec-null.pcapng. Au autre exemple est celui d’un refus de re-négociation de paramètres de session dans un re-INVITE.
5. Server Failure (5xx)
Cette classe de réponse est utilisée pour indiquer que la demande ne peut pas être traitée en raison d’une erreur avec le serveur. Le serveur n’a pas réussi à satisfaire une demande apparemment valide. La réponse peut contenir un champ d’en-tête Retry-After. La demande peut être essayée à d’autres endroits, car il n’y a pas d’erreurs indiquées dans la demande. Certaines des réponses importantes de défaillance du serveur sont présentées ci-dessous.
5.1. 500 Server Internal Error
500 indique que le serveur a connu une erreur qui empêche de traiter la demande.
C’est une sorte de défaillance typique du serveur qui indique au client de réessayer la demande à nouveau au bout de quelques secondes.
5.2. 501 Not Implemented
Ce code indique que le serveur est incapable de traiter la demande car il est pas pris en charge.
Cette réponse peut être utilisée pour refuser une demande contenant une méthode inconnue ou qui n’est pas prise en charge.
5.2. 502 Bad Gateway
Cette réponse est envoyée par un mandataire (proxy) qui agit comme une passerelle vers un autre réseau.
Il indique qu’un un problème dans d’autres réseaux empêche la demande d’être traitée.
5.3. 503 Service Unavailable
Cette réponse indique que le service est temporairement indisponible à ce moment-là.
La demande peut être relancée après quelques secondes, ou après l’expiration du champ d’en-tête Retry-After.
Une erreur fatale de transport rapportée par la couche transport (généralement due à des erreurs fatales d’ICMP dans UDP ou des défaillances de connexion dans TCP) dans la demande implique une réponse 503 Service Unavailable.
5.4. 504 Gateway Timeout
Cette réponse intervient quand la demande a échouée en raison d’un délai d’attente qui a eu lieu dans un autre réseau auquel la passerelle se connecte.
C’est une classe d’erreur de serveur, car l’appel échoue en raison d’une défaillance d’accès du serveur aux ressources en dehors du réseau SIP.
5.5. 505 Version Not Supported
Le serveur refuse une demande quand il est livré avec un autre numéro de version SIP. Le refus est indiqué dans ce message.
À l’heure actuelle la version SIP 2.0 est la seule version implémentée.
5.6. 513 Message Too Large
Cette réponse est utilisée par un UAS pour indiquer que la taille de la demande était trop grande être traitée.
5.7. 580 Preconditions Failure
Cette réponse permet de rejeter une offre SDP qui exigerait des conditions préalables qui ne peuvent être satisfaites.
6. Global Error (6xx)
Cette classe de réponse indique que le serveur sait que la demande échouera où qu’elle soit tentée . En conséquence, la demande ne devrait pas être envoyé à d’autres endroits.
Seul un serveur ayant des connaissances définitives de l’utilisateur identifié par la requête devrait envoyer tous les cas possibles une réponse globale de la classe d’erreur. Dans le cas contraire, une réponse de classe d’erreur client doit être envoyé.
Un champ d’en-tête Retry-After peut être utilisé pour indiquer que la demande pourrait être couronnée de succès. Certaines des réponses importantes sont présentées ci-dessous.
6.1. 600 Busy Everywhere
Ce code de réponse indique que l’appel dans la requête spécifiée devrait trouver réponse auprès d’autres endroits.
6.2. 603 Decline
Cette réponse pourrait indiquer la partie appelée est occupée, ou simplement ne veut pas accepter l’appel.
6.3. 604 Does Not Exist Anywhere
Cette réponse est semblable à la réponse 404 Not Found, mais indique que l’utilisateur dans la requête ne peut être trouvé nulle part.
Cette réponse devrait seulement être envoyée par un serveur ayant accès à toutes les informations sur l’utilisateur.
6.4. 606 Not Acceptable
Cette réponse indique que certains aspects de la session souhaitée n’est pas acceptable pour l’UAS, et par conséquent, la session ne peut pas être établie.
La réponse peut contenir un champ d’en-tête Warning avec un code numérique décrivant exactement ce qui était pas acceptable.
La demande peut être relancée avec différentes informations de sessions médias.
