Codes de réponse SIP : le guide complet des 1xx, 2xx, 3xx, 4xx, 5xx et 6xx

Chaque appel SIP se termine par l’un d’une trentaine de codes de statut, et ce code est le signal le plus fiable dont vous disposez pour savoir ce qui s’est réellement passé. Un appel qui échoue avec 486 Busy Here vous apprend quelque chose de fondamentalement différent d’un appel qui échoue avec 503 Service Unavailable, même si l’appelant entend la même tonalité d’occupation rapide dans les deux cas. Lire le code est la première chose que fait tout ingénieur voix quand un appel n’aboutit pas, et la différence entre chercher une panne à tâtons et la trouver réside souvent dans la connaissance de ce que signifie chaque code et du comportement qu’il déclenche dans le reste du réseau.

Cet article est la référence pour chaque code de réponse SIP que vous êtes susceptible de rencontrer en production. Nous couvrons les six classes (1xx provisoire, 2xx succès, 3xx redirection, 4xx erreur client, 5xx erreur serveur, 6xx échec global), les codes spécifiques au sein de chaque classe, le comportement de retransmission et de nouvelle tentative que chacun est censé déclencher, et la façon dont un Session Border Controller normalise les codes de réponse entre des équipements qui ne s’accordent pas sur le code à envoyer. Pour les fondamentaux du protocole, SIP Signaling Fundamentals couvre les rôles, les en-têtes et l’architecture.

Les six classes de codes de réponse

Les codes de réponse SIP suivent la même structure à six classes que HTTP, définie dans RFC 3261. Le premier chiffre identifie la classe, les deux chiffres restants identifient le code spécifique au sein de la classe. La classe est l’élément le plus important car elle contrôle la façon dont le reste du réseau est censé réagir : s’il doit continuer à attendre, réessayer sur un chemin différent, abandonner entièrement, ou traiter l’appel comme terminé.

Les réponses 1xx Provisoire confirment que la requête est en cours de traitement. Elles ne sont pas finales, ne terminent pas la transaction et ne sont pas acquittées. L’agent utilisateur de l’appelant cesse de retransmettre la requête dès qu’un code 1xx arrive, mais l’appel n’est pas encore résolu.

Les réponses 2xx Succès indiquent que la requête a réussi. Pour un INVITE, un 2xx signifie que l’appel a été décroché et qu’un ACK doit suivre pour compléter la poignée de main en trois étapes. Le 2xx est la seule classe qui établit un dialogue.

Les réponses 3xx Redirection invitent l’appelant à essayer un URI différent. La requête d’origine n’a pas abouti, mais la réponse contient un en-tête Contact pointant vers un autre emplacement où l’appel devrait être réessayé.

Les réponses 4xx Échec client indiquent que la requête elle-même présentait un problème que l’appelant peut corriger : syntaxe incorrecte, authentification manquante, un point terminal occupé, un numéro qui n’existe pas. La requête ne devrait pas être réessayée telle quelle à la même destination.

Les réponses 5xx Échec serveur indiquent que la requête était syntaxiquement valide mais que le serveur n’a pas pu la traiter. Contrairement aux codes 4xx, la même requête peut réussir sur un serveur différent, de sorte que le 5xx est la classe qui déclenche typiquement l’avancement de route vers un chemin secondaire.

Les réponses 6xx Échec global indiquent que la requête ne peut être satisfaite par aucun serveur, nulle part. Un code 6xx stoppe les tentatives de bifurcation au niveau des proxies, termine les groupes de recherche parallèles et indique à l’appelant de ne pas essayer de routes alternatives.

Réponses provisoires 1xx

Les réponses provisoires maintiennent la transaction SIP active pendant que le réseau détermine la marche à suivre. Elles n’ont généralement pas de corps, ne déclenchent jamais ACK et servent principalement à stopper la retransmission et à informer l’appelant que quelque chose se passe. Un appel ne peut pas aboutir sur un 1xx seul ; une réponse finale (2xx à 6xx) doit toujours suivre.

100 Trying est envoyé par le prochain saut SIP dès qu’il accepte l’INVITE pour traitement. Il est strictement saut par saut, n’atteint jamais l’écran de l’appelant en tant qu’événement, et existe pour une seule raison : indiquer à l’agent utilisateur en amont de cesser de retransmettre l’INVITE pendant que le saut suivant effectue son travail. Si vous ne voyez pas de 100 Trying dans une trace UDP, vous êtes face à un problème de transport avant même d’être face à un problème SIP.

180 Ringing est la réponse provisoire de bout en bout du point terminal de destination indiquant que la partie appelée est en cours d’alerte. C’est le code qui amène le téléphone de l’appelant à jouer une tonalité de retour d’appel locale. Certains opérateurs et PBX préfèrent générer eux-mêmes cette tonalité en envoyant 183 Session Progress avec de l’early media à la place, ce qui leur permet d’injecter des annonces réseau (numéro non attribué, veuillez patienter) avant même que l’appel soit décroché.

181 Call Is Being Forwarded est une réponse provisoire de courtoisie indiquant que l’appel a été redirigé vers un autre point terminal. Il est rarement utilisé dans les réseaux modernes car le renvoi est généralement géré de manière transparente par une redirection 3xx ou par un SBC qui réécrit la destination.

182 Queued indique à l’appelant que la destination a accepté l’appel mais l’a placé dans une file d’attente, typiquement dans un centre de contact où tous les agents sont occupés. C’est un moyen de maintenir le dialogue actif sans sonnerie pendant que l’appelant attend.

183 Session Progress est la réponse provisoire la plus importante après 100 et 180. Elle indique une progression et, de façon cruciale, peut transporter un corps SDP qui établit de l’early media avant que l’appel soit décroché. Les opérateurs utilisent le 183 avec de l’early media pour diffuser des annonces, des tonalités de retour d’appel ou des délais post-numérotation en bande. Un early media mal configuré est une source courante de problèmes d’audio unidirectionnel car l’appelant entend l’annonce de l’opérateur mais le point terminal réellement appelé ne voit aucun chemin média avant le 200 OK.

Les réponses provisoires fiables (PRACK, définies dans RFC 3262) étendent cette classe avec des acquittements pour que les messages 1xx ne soient pas perdus sur des liens peu fiables. PRACK est obligatoire pour certaines interconnexions (notamment Microsoft Teams Direct Routing dans certaines configurations) et optionnel ailleurs.

Réponses de succès 2xx

Les réponses de succès sont courtes et déterminantes. Un 2xx en réponse à un INVITE établit un dialogue, ce qui signifie que l’état de routage doit être maintenu à chaque intermédiaire jusqu’à la fin de l’appel avec BYE.

200 OK est la réponse de succès pour presque toutes les requêtes SIP. Pour un INVITE, il signifie que l’appel a été décroché et que le corps de la réponse contient la réponse SDP du destinataire qui complète la négociation média. Pour un BYE, il confirme que le dialogue a été démonté. Pour un CANCEL, il acquitte l’annulation elle-même, séparément du 487 Request Terminated qui sera envoyé pour l’INVITE d’origine. Pour un OPTIONS, il retourne les méthodes et codecs supportés par le répondeur, ce qui est le fonctionnement de la supervision SIP par keepalive.

202 Accepted indique que la requête a été acceptée pour traitement mais que le résultat n’est pas encore connu. Il est le plus souvent rencontré comme réponse à une requête REFER lors d’un transfert d’appel : le transféré acquitte le fait qu’il tentera le transfert et rendra compte de la progression via des messages NOTIFY dans le dialogue.

Le comportement caractéristique de toute réponse 2xx à un INVITE est qu’elle doit être acquittée par un ACK, et cet ACK est de bout en bout. Contrairement à toute autre requête, l’ACK pour un 2xx voyage dans sa propre transaction et doit traverser le même chemin Record-Route que l’INVITE d’origine. Oublier l’existence de Record-Route est une source courante de tickets « l’appel décroche mais raccroche immédiatement » lors de l’analyse de trace.

Réponses de redirection 3xx

Les réponses de redirection indiquent à l’appelant d’essayer un URI différent. La réponse comprend un ou plusieurs en-têtes Contact nommant la nouvelle cible, et l’agent utilisateur de l’appelant (ou l’intermédiaire qui gère la redirection en son nom) est censé réessayer la requête vers ces contacts.

300 Multiple Choices liste plusieurs destinations possibles et laisse l’appelant choisir. Il est rare en production car la plupart des agents utilisateurs SIP ne présentent pas plusieurs choix à l’utilisateur ; l’appel aboutit soit contre le premier Contact, soit échoue.

301 Moved Permanently indique que la partie appelée a une nouvelle adresse permanente et que les caches doivent être mis à jour en conséquence. Il est peu fréquent dans les réseaux voix mais apparaît dans les scénarios d’enregistrement.

302 Moved Temporarily est de loin le 3xx le plus utile en production. L’appelant doit réessayer la requête contre l’URI dans l’en-tête Contact pour cet appel uniquement, sans mettre en cache la nouvelle adresse. Les intégrations de prévention de fraude et STIR/SHAKEN retournent souvent un 302 pour rediriger un appel d’un groupe de jonctions vers un autre en fonction d’un score en temps réel. Les systèmes de routage au moindre coût utilisent le 302 pour acheminer un appel vers un opérateur différent sans que le point terminal d’origine ne sache que la route a changé.

305 Use Proxy demande à l’appelant de réessayer via un proxy spécifique. Il est presque jamais vu dans les réseaux d’opérateurs en production.

380 Alternative Service suggère que l’appel devrait être tenté via un service entièrement différent (par exemple, un protocole différent). Il est occasionnellement utilisé lorsqu’un point terminal SIP ne peut pas accepter un appel mais connaît un service associé qui le peut.

Ce qu’il faut savoir en pratique sur les réponses 3xx, c’est que tous les équipements ne les traitent pas de la même façon. Un proxy SIP ou B2BUA consomme généralement le 3xx lui-même, réessaie la requête au nom de l’appelant, et retourne soit un 200 OK en cas de succès, soit un code d’échec différent à l’appelant d’origine. Un agent utilisateur nu sans cette logique échouera simplement l’appel lorsqu’il ne peut pas suivre la redirection. C’est l’une des raisons les plus courantes pour lesquelles les appels « fonctionnent depuis le SBC mais échouent depuis le point terminal » lors des tests.

Réponses d’échec client 4xx

La classe 4xx couvre tout ce qui ne va pas avec la requête elle-même. La requête ne réussira pas si elle est réessayée telle quelle à la même destination, mais elle peut réussir si l’appelant corrige le problème (ajoute des identifiants, corrige l’URI, change la méthode) ou choisit une destination différente.

Authentification et autorisation

401 Unauthorized est envoyé par un UAS qui exige que l’appelant s’authentifie avant de traiter la requête. La réponse contient un en-tête WWW-Authenticate avec un realm et un nonce, et l’appelant est censé réessayer la même requête avec un en-tête Authorization contenant le digest. Les opérateurs de SIP trunking et les PBX qui requièrent un enregistrement challengent les nouveaux INVITE avec 401.

407 Proxy Authentication Required est le même principe mais émis par un proxy intermédiaire plutôt que par le point terminal final. Le challenge apparaît dans un en-tête Proxy-Authenticate et la réponse revient sous forme de Proxy-Authorization. La cause la plus fréquente de « l’enregistrement fonctionne mais les appels échouent » est une non-concordance de realm dans le challenge 407 entre le SBC et le fournisseur en amont.

403 Forbidden signifie que l’appelant est identifié et authentifié mais n’est pas autorisé à effectuer cette requête. Les déclencheurs courants incluent un appel depuis une IP absente de la liste de contrôle d’accès de l’opérateur, une tentative de composer un numéro en dehors de la plage assignée, ou un échec d’attestation STIR/SHAKEN. Le 403 est final et l’appelant ne devrait pas réessayer sans modifier quelque chose au préalable.

Problèmes d’adresse et de méthode

400 Bad Request indique que la requête était malformée : un en-tête requis manquant, un URI syntaxiquement invalide, un corps non analysable. Certains opérateurs retournent 400 lorsqu’ils reçoivent un en-tête qu’ils considèrent non conforme, ce qui est l’une des raisons pour lesquelles la normalisation SIP est une fonction SBC fondamentale.

404 Not Found signifie que l’URI de destination n’existe pas sur le serveur répondant. En production, le 404 est surchargé : un vrai « numéro inexistant » retourne 404, mais également un manqué ACL sur certaines plateformes, et certains services de prévention de fraude utilisent 404 pour indiquer « aucune fraude détectée, avancement de route vers le chemin suivant ». Sur ProSBC, le comportement par défaut consistant à stopper l’appel sur 404 est couramment remplacé par « continuer l’appel » spécifiquement pour que les codes de retour des services de prévention de fraude s’intègrent correctement dans la logique de routage.

405 Method Not Allowed indique que le répondeur ne supporte pas la méthode SIP qui a été demandée. La réponse inclut un en-tête Allow listant les méthodes supportées, ce qui est utile pour les diagnostics. Un REGISTER envoyé à un serveur qui n’accepte que les INVITE retournera 405 avec Allow listant INVITE, ACK, BYE et CANCEL.

415 Unsupported Media Type signifie généralement que le corps SDP a proposé un codec ou un type de média que le répondeur ne peut pas gérer. La réponse inclut un en-tête Accept listant ce qui serait acceptable, ce qui permet à l’appelant de réessayer avec une offre SDP plus restreinte.

Temporisation et état du point terminal

408 Request Timeout est retourné lorsque le réseau a maintenu la requête suffisamment longtemps pour qu’une réponse sensée aurait dû être revenue. Il est généré par les intermédiaires lorsqu’aucune réponse en aval n’est reçue dans l’intervalle de temporisation SIP (Timer B, typiquement 32 secondes pour UDP), et indique à l’appelant que la destination était inaccessible pour une raison non précisée.

410 Gone indique que l’adresse de destination existait autrefois mais n’est plus en service de façon permanente. Certains opérateurs l’utilisent à la place du 404 pour distinguer « nous savons que ce numéro a déjà fonctionné » de « ce numéro est inconnu ».

480 Temporarily Unavailable est envoyé par le point terminal appelé lorsqu’il ne souhaite pas prendre l’appel pour l’instant mais que l’adresse est par ailleurs valide. C’est la réponse standard lorsqu’un temporisateur de non-réponse expire (le téléphone a sonné longtemps sans réponse) et que l’appel est abandonné avant d’être décroché. Le 480 signifie que l’appel a atteint le point terminal et que celui-ci l’a refusé selon sa propre politique, ce qui est différent du 408 où l’appel n’est jamais parvenu aussi loin.

484 Address Incomplete indique à l’appelant que le numéro composé semble être une chaîne de numérotation partielle. L’appelant devrait saisir plus de chiffres et réessayer. Il s’agit largement d’un héritage de la numérotation en bloc dans les passerelles TDM vers SIP.

486 Busy Here est la réponse « je suis sur un autre appel » du point terminal appelé. Le dialogue se termine immédiatement et l’agent utilisateur de l’appelant joue typiquement une tonalité d’occupation. Le 486 est un code par point terminal : la partie appelée est occupée, mais un point terminal différent pour le même utilisateur (une deuxième ligne, un jumeau mobile) pourrait encore être joignable.

487 Request Terminated est la réponse à un INVITE qui a été annulé avant d’être décroché. C’est le pendant SIP d’une requête CANCEL : quand Alice raccroche pendant qu’elle entend encore la tonalité de retour d’appel, le côté de Bob envoie un 200 OK au CANCEL lui-même et un 487 à l’INVITE d’origine. Lire le 487 comme un appel en échec plutôt que comme un appel abandonné est une source courante de métriques ASR (Answer-Seizure Ratio) incorrectes dans l’analyse brute des CDR.

488 Not Acceptable Here indique que le point terminal appelé a compris la requête mais ne peut pas accepter la session telle qu’elle est proposée, presque toujours en raison d’un problème SDP : une liste de codecs incompatibles, un type de média que le point terminal ne supporte pas, une plage de ports qu’il ne peut pas utiliser. C’est l’échec de négociation de codec le plus souvent rencontré entre des opérateurs utilisant des ordres de codecs par défaut différents.

491 Request Pending gère une condition de compétition où les deux côtés d’un dialogue envoient un re-INVITE presque simultanément. Le côté perdant retourne 491, attend un intervalle aléatoire court, et réessaie.

Réponses d’échec serveur 5xx

La classe 5xx est l’alliée du dépanneur : elle signifie que la requête elle-même était correcte mais que le répondeur n’a pas pu la traiter, ce qui laisse fortement entendre qu’un serveur différent pourrait réussir. La majorité du comportement d’avancement de route et de basculement en production est piloté par les codes 5xx.

500 Server Internal Error est le code générique « quelque chose ne va pas chez moi ». Le répondeur a accepté la requête mais a rencontré un problème qu’il ne peut pas décrire plus précisément. Des 500 persistants depuis un seul opérateur pointent généralement vers un défaut logiciel sur le commutateur de cet opérateur.

501 Not Implemented indique que la méthode de requête est reconnue mais que le serveur ne l’implémente pas. Un REFER envoyé à un opérateur qui ne supporte pas le transfert d’appel retournera 501.

502 Bad Gateway signifie que le serveur a reçu une réponse invalide d’un serveur en aval. Dans une chaîne de SBC et de proxies, un 502 de l’amont signifie généralement que l’aval a retourné quelque chose qui ne pouvait pas être analysé ou qui violait le contrat.

503 Service Unavailable est le cheval de bataille du basculement. Il indique à l’appelant que le serveur est temporairement surchargé ou en maintenance et que la même requête devrait être réessayée ailleurs. La limitation de débit côté opérateur retourne généralement 503 lorsqu’une limite de sessions est atteinte, ce qui est exactement le signal dont le SBC de l’appelant a besoin pour passer à un trunk de secours.

504 Server Time-out indique que le serveur n’a pas reçu de réponse en temps utile d’un serveur dont il dépendait. C’est l’équivalent du 408 dans les systèmes en chaîne.

505 Version Not Supported indique que la version SIP dans la ligne de requête n’est pas supportée. Il s’agit effectivement d’une pièce de musée : SIP 2.0 est la seule version déployée depuis deux décennies.

La raison pour laquelle les codes 5xx sont importants pour la conception du routage est qu’ils justifient presque toujours l’avancement de route. Un SBC correctement configuré doit associer les réponses 5xx reçues de n’importe quel opérateur à une décision « essayer la route suivante », tandis que les réponses 4xx ne devraient généralement pas déclencher d’avancement (la requête elle-même a été rejetée, la réessayer contre un autre opérateur réussira rarement). L’exception est le cas du 404 surchargé mentionné précédemment.

Réponses d’échec global 6xx

Une réponse 6xx est la forme la plus forte de « non » en SIP. Elle indique à l’appelant que la requête ne peut être satisfaite par aucun serveur dans aucun emplacement, de sorte que l’avancement de route et la bifurcation parallèle doivent tous deux s’arrêter. Dans un groupe de recherche ou une configuration de répartition de charge qui essaierait normalement plusieurs destinations en séquence, un 6xx reçu de l’une d’elles termine l’ensemble de la recherche.

600 Busy Everywhere signifie que l’utilisateur appelé est occupé sur chaque point terminal qu’il a enregistré. Contrairement au 486 Busy Here, qui est par point terminal, le 600 est par utilisateur. Un proxy qui bifurque un INVITE vers un téléphone de bureau, un jumeau mobile et un softphone cessera de bifurquer dès que l’un d’eux retourne 600.

603 Decline indique que la partie appelée a explicitement rejeté l’appel (appui sur le bouton de rejet). L’appelant ne devrait pas réessayer. Le 603 est également couramment utilisé par les services de prévention de fraude pour indiquer « cet appel doit être bloqué » ; dans ce contexte, le SBC doit terminer l’appel plutôt que de passer à une route de secours. Le comportement par défaut « continuer l’appel » de ProSBC sur 603 est explicitement remplacé dans les déploiements intégrés à la détection de fraude afin qu’un 603 provenant du service de scoring stoppe effectivement l’appel.

604 Does Not Exist Anywhere indique à l’appelant que l’adresse de destination n’est en service nulle part sur le réseau répondant. Il est rare dans le SIP moderne car le 404 a effectivement absorbé son cas d’usage.

606 Not Acceptable est le pendant en échec global du 488 Not Acceptable Here. Il indique que la session décrite dans la requête ne peut être acceptée par aucun serveur, souvent parce que le codec ou les paramètres de session sont complètement en dehors de ce que le réseau répondant supporte.

En pratique, les réponses 6xx sont plus rares que les 4xx et 5xx. Lorsque vous en voyez un, traitez-le comme faisant autorité : la requête ne réussira sur aucun chemin de nouvelle tentative.

Lecture des codes de réponse dans une trace de production

Le comportement de retransmission et de nouvelle tentative lié à chaque classe détermine la façon dont un appel SIP se comporte réellement en production. Mémoriser les codes est la partie facile ; prédire comment le reste du réseau réagit à chacun d’eux est la compétence plus difficile, et c’est la différence entre le dépannage et les suppositions.

Sur le transport UDP, l’agent utilisateur de l’appelant retransmet l’INVITE avec un retrait exponentiel (Timer A, démarrant à 500 ms) jusqu’à l’arrivée d’une réponse provisoire ou finale. Le 100 Trying que le saut suivant renvoie est ce qui stoppe la retransmission. Si vous voyez le même INVITE sept fois dans une trace sans réponse, vous êtes face à un problème de joignabilité du transport, pas à un problème SIP ; le saut suivant ne traite même pas la requête. Le transport TCP et TLS ne retransmet pas car la couche transport gère la livraison, donc un appel bloqué sur TCP ressemble à quelque chose de complètement différent dans une trace d’un appel bloqué sur UDP.

Les réponses finales à un INVITE exigent toujours ACK. La forme de l’ACK dépend de la réponse : un ACK pour un 2xx est de bout en bout et voyage dans sa propre transaction, tandis qu’un ACK pour un 3xx à 6xx est saut par saut et fait partie de la transaction INVITE d’origine. Un ACK manquant après 200 OK est la raison la plus fréquente des symptômes « l’appel décroche mais raccroche au bout de quelques secondes », car le point terminal appelé démontera le dialogue lorsque ses retransmissions du 200 OK resteront sans acquittement.

Les réponses provisoires ne requièrent jamais ACK. Un 1xx qui reste sans réponse ne fait rien de préjudiciable en lui-même, mais un 1xx suivi de silence (pas de réponse finale, pas d’autres réponses provisoires) est un signal fort que quelque chose en aval a cessé de traiter. PRACK est l’exception dans les environnements qui l’activent : un 1xx fiable (un 1xx avec un en-tête Require : 100rel) doit être acquitté avec PRACK.

L’interaction entre 4xx et 5xx détermine l’avancement de route. Un script de routage SBC bien conçu traite le 5xx comme « essayer la route suivante », traite la plupart des 4xx comme « arrêter, cet appel ne peut pas aboutir », et applique des remplacements par code pour les cas réels désordonnés (404 utilisé comme autorisation de fraude, 503 utilisé comme rejet de capacité par un opérateur sain, 603 utilisé pour bloquer un appel frauduleux). Bien configurer ces remplacements est ce qui fait la différence entre un déploiement avec 5 % d’appels échoués mais réessayables et un avec 0,1 %.

Comment un SBC normalise les codes de réponse entre dialectes

Chaque opérateur et chaque constructeur de PBX retourne des codes de réponse légèrement différents pour la même condition sous-jacente. Un opérateur envoie 503 lorsqu’une limite de sessions est atteinte ; un autre envoie 486. Un PBX retourne 480 lorsqu’un utilisateur est déconnecté ; un autre retourne 404. Les points terminaux en aval de ces incohérences ne sont généralement pas assez intelligents pour les traiter comme équivalentes, donc des appels échouent alors qu’ils auraient dû avancer, et des appels qui auraient dû s’arrêter avancent plutôt et accumulent des minutes vers des destinations frauduleuses.

C’est dans cette partie de l’interopérabilité SIP qu’un SBC gagne sa valeur. Un SBC B2BUA comme ProSBC voit la réponse sur la jambe entrante et génère une réponse fraîche sur la jambe sortante, ce qui signifie qu’il peut réécrire le code, modifier la décision de routage qu’il déclenche, et ajouter ou supprimer des Reason headers selon les besoins. La fonctionnalité Reason Cause Mapping permet à chaque NAP (groupe de jonctions) de remplacer le comportement par défaut par code : 404 peut être configuré en « continuer l’appel » afin que la réponse positive d’un service de scoring de fraude passe à la route suivante ; 603 peut être configuré en « stopper l’appel » afin que la réponse de blocage du même service le stoppe effectivement ; 302 peut être configuré en « traiter le routage d’appel » afin qu’une redirection du routage au moindre coût soit consommée par le SBC plutôt que transmise en amont ; 503 peut être configuré en « continuer l’appel » sur un primaire sain afin qu’un rejet de capacité bascule proprement.

Le même mécanisme gère la traduction de dialectes vendeurs dans le sens le plus simple. Un 503 Service Unavailable en aval peut être traduit en un 486 Busy Here en amont lorsque le système en amont gère mieux le 486. Un 488 Not Acceptable Here peut être normalisé en un 415 Unsupported Media Type lorsqu’un PBX plus ancien attend un 415. Un X-header propriétaire d’un vendeur portant des informations de cause supplémentaires peut être supprimé, ou, à l’inverse, un Reason header avec une valeur de cause Q.850 peut être injecté lors du pontage depuis une passerelle TDM afin que l’opérateur SIP en amont voie le contexte d’échec PSTN complet.

Ce même contrôle sur les codes de réponse est ce qui fait de la manipulation d’en-têtes SIP et de l’architecture B2BUA la bonne réponse pour les interconnexions multi-vendeurs, Microsoft Teams Direct Routing, et tout environnement où trois opérateurs ou plus, deux constructeurs de PBX ou plus, et une plateforme UCaaS doivent tous s’interconnecter via le même point de démarcation.

Référence rapide de dépannage

Les codes les plus fréquemment rencontrés en production, ce qu’ils signifient concrètement, et la première chose à vérifier lorsque chacun apparaît :

401 / 407 (challenge d’authentification) signifie que la requête nécessite des identifiants. Si la nouvelle tentative avec les identifiants échoue encore, vérifiez que le realm dans le challenge correspond à ce pour quoi l’appelant est configuré pour s’authentifier, et que l’algorithme de digest SIP (MD5 ou SHA-256) est supporté des deux côtés.

403 Forbidden après authentification signifie qu’une ACL ou une politique bloque l’appel. Vérifiez l’IP source contre la liste de contrôle d’accès du répondeur, et vérifiez l’attestation STIR/SHAKEN si l’opérateur impose des niveaux d’attestation minimum.

404 Not Found signifie soit que le numéro n’existe pas, soit que le répondeur utilise 404 comme signal « aucune correspondance ». Confirmez que le numéro est provisionné et, si le répondeur est un service de scoring de fraude, que le 404 est configuré en « continuer l’appel » dans le SBC.

408 Request Timeout signifie que rien en aval n’a répondu. Vérifiez d’abord la joignabilité du transport (UDP/5060 est-il réellement ouvert ?) avant de supposer un problème au niveau SIP.

480 Temporarily Unavailable signifie que le point terminal existe et refuse l’appel pour l’instant. Vérifiez le temporisateur de non-réponse, l’état Ne pas déranger, ou le statut d’enregistrement de la destination.

486 Busy Here signifie que le point terminal appelé est sur un autre appel. Si le 486 apparaît à grande échelle sur un seul trunk, suspectez que les limites de sessions sont atteintes et que l’opérateur retourne 486 au lieu du plus précis 503.

487 Request Terminated n’est pas un échec : c’est le pendant d’un CANCEL. Filtrez les 487 des métriques d’échec ; rapportez-les plutôt sous les appels abandonnés.

488 Not Acceptable Here est un problème de codec ou de SDP. Comparez la liste de codecs proposée aux codecs supportés par le répondeur, et vérifiez si le SBC impose un codec que l’aval ne supporte pas.

503 Service Unavailable à la frontière d’un trunk signifie presque toujours que l’opérateur est surchargé ou limite le débit. Confirmez que le comportement d’avancement de route du SBC est configuré pour basculer sur 503 ; si ce n’est pas le cas, c’est votre première correction à apporter.

603 Decline provenant d’un service de scoring de fraude est une décision de blocage. Confirmez que le Reason Cause Mapping du SBC pour le 603 est configuré en « stopper l’appel » sur ce NAP afin que le blocage termine effectivement l’appel.

Conclusion

Les codes de réponse SIP constituent un vocabulaire petit et structuré qui porte presque tous les signaux dont un ingénieur voix a besoin pour lire un appel. Six classes, moins d’une trentaine de codes en usage régulier en production, et un ensemble cohérent de règles sur les codes qui déclenchent la retransmission, ceux qui requièrent ACK, ceux qui justifient l’avancement de route, et ceux qui terminent l’appel définitivement. Les codes eux-mêmes sont stables ; ce qui varie entre les déploiements, c’est quel code exact chaque vendeur retourne pour quelle condition sous-jacente, et cette variance est précisément là où le mappage de codes de réponse d’un SBC fait le travail de faire se comporter un réseau multi-vendeur comme un système unique et cohérent.

Pour les ingénieurs voix qui construisent des interconnexions SIP trunking, déploient Teams Direct Routing, ou dépannent des appels en échec dans un environnement multi-opérateurs, la maîtrise de ces codes (ce que chacun signifie, quel comportement il déclenche, quand un opérateur l’utilise de façon idiomatique) est le fondement sur lequel tout le reste se construit. Le guide pas à pas du flux d’appel SIP montre les codes dans le contexte d’une trace complète ; cet article est le dictionnaire que vous gardez ouvert à côté.