Découvrir ce qui est arrivé à cet appel
Vous avez un numéro, et peut-être une heure. Vous devez savoir où l’appel a échoué et à qui revient la faute. C’est de loin la demande la plus fréquente adressée à Butler.
Quelqu’un s’est plaint d’abord. C’est presque toujours comme ça que tout commence, que la plainte vienne d’un utilisateur final, d’un revendeur ou d’un collègue sur un autre canal, et ce qui vous parvient se résume à un seul identifiant : un numéro composé, parfois une heure, parfois rien de plus que « à l’instant ».
Y répondre aujourd’hui suppose d’ouvrir un outil de trace, de savoir quel contrôleur de session en bordure (SBC) examiner, de retrouver l’appel, de lire un diagramme SIP et de savoir ce que signifie un 480 dans ce contexte. Butler réduit tout cela à une phrase tapée dans la fenêtre de chat que vous avez déjà ouverte.
Choisissez une question et lisez l’échange complet
Ces échanges proviennent tous d’un même après-midi, sans retouche, avec les identifiants masqués. Lisez le deuxième pour voir ce que fait Butler quand il n’a pas les données demandées.
- L’appel a été décroché à 10:16:10 UTC
- Durée de 87 secondes, avec de l’audio dans les deux sens
- Libération normale par l’appelant, et les deux tronçons indiquent release_source ConnectedLeg : le côté opérateur était donc établi et connecté à la fin de l’appel
Un opérateur niait avoir reçu un appel et citait un Call-ID pour le prouver. Butler a retrouvé l’appel, puis a remarqué le détail qui clôt le débat : le Call-ID cité correspond au saut entre deux de nos propres SBC, donc l’opérateur ne pouvait pas le voir. Il a fourni celui que l’opérateur devait chercher, et confirmé que l’appel avait été décroché et avait duré 87 secondes. Cela représente vingt minutes dans une capture de paquets, et le résultat est une phrase que vous pouvez envoyer telle quelle à l’opérateur.
- Le release_source de chaque tronçon sortant est LocalLeg, avec un sip_final_response 503
- L’original_cause est 503_SERVICE_UNAVAIL(503)
- Votre SBC a envoyé l’INVITE et l’opérateur a renvoyé 503 Service Unavailable
C’est le premier message qui vaut la peine d’être lu. Interrogé sur « un appel qui a échoué avec un 503 ce matin », Butler n’a pas choisi un appel au hasard en espérant tomber juste. Il a demandé un numéro, une heure approximative et un SBC, puis l’a retrouvé grâce à un filtre côté serveur sur le code de réponse, au lieu de parcourir les lignes une à une. La réponse cite les preuves utilisées avant de tirer sa conclusion, et c’est ce qui permet de transmettre la dernière ligne telle quelle.
- Le 180 Ringing a été envoyé par le commutateur de terminaison, pas par le terminal de l’utilisateur final
- La sonnerie visible dans le diagramme n’est que de la signalisation : l’extrémité distante indiquait qu’elle tentait d’alerter la destination
- Le 486 est revenu 20 ms plus tard, si bien que le combiné n’a très probablement jamais eu le temps de sonner physiquement
Les deux parties avaient raison, et c’est pour cela que la discussion tournait en rond. Le réseau a bien tenté l’acheminement et le téléphone n’a pas sonné : vingt millisecondes suffisent à tout expliquer. Remarquez que Butler n’a pas choisi un camp pour le défendre. Il a lu ce que disait réellement la signalisation, qui s’est révélée plus précise que chacune des deux parties.
Un chiffre qui ne dit rien, découpé en deux chiffres qui disent quelque chose. Sur près de trois secondes d’établissement, 295 millisecondes relevaient du délai post-numérotation, c’est-à-dire du routage et du traitement propre à la destination, et les 2,9 secondes restantes correspondaient au correspondant qui ne décrochait pas. La première partie concerne la plateforme, la seconde non, et les confondre, c’est passer un après-midi à dépanner le mauvais système.
L’objection habituelle quand on place un assistant devant un support, c’est qu’il va noyer l’équipe sous les détails. En voici le contre-exemple. Derrière cette réponse, Butler a parcouru une chaîne de trois sauts et six tronçons, puis en a écarté presque tout : pas de codes de réponse, pas de noms de NAP, pas de topologie. Trois phrases simples que la personne qui a ouvert le ticket peut vraiment lire.
L’ingénieur disait que les appels avaient échoué. Les preuves disaient le contraire, et Butler l’a dit, diagramme à l’appui. Remarquez aussi que personne n’a rien eu à répéter : au troisième message, la question se résume à « pour l’appel 1 », et Butler a toujours les deux appels en tête. Une réponse digne de confiance, c’est une réponse capable de vous contredire.
Les requêtes, et où chacune mène
Copiez-en une et remplacez les numéros par les vôtres. Les relances comptent plus que la question de départ.
Quelqu’un s’est plaint et vous n’avez que le numéro. Pas d’heure, pas de sens d’appel, pas de SBC.
L’appel, la cause de déconnexion et le tronçon qui l’a provoquée.
Vous êtes sur le point d’ouvrir un ticket auprès d’un opérateur en amont et il doit être incontestable.
Le NAP d’entrée, le NAP de sortie, la source de libération et la cause de déconnexion, qui transforment « l’appel a échoué » en « il est sorti par cette jonction et cet opérateur l’a refusé ».
Le code d’état n’est pas la réponse. Vous voulez le texte exact de l’en-tête de motif.
La phrase de motif, plus tout en-tête Reason ou Warning qui l’accompagne, c’est-à-dire la partie qu’un tableau de bord ne peut pas vous montrer.
Une plainte audio, et l’offre SDP liste cinq codecs qui ne vous apprennent rien.
Le codec négocié pour chaque tronçon, lu dans les enregistrements des tronçons plutôt que dans l’offre.
Comment lire ce qui revient
Qu’est-il arrivé à cet appel ?
Un numéro, et peut-être une heure. Butler retrouve l’appel et indique de quel côté il a été terminé.
Décomptes, regroupements, seuils et KPI sur un ensemble d’appels.
Tables de routage, expressions régulières et profils SDP en langage clair.
Posez vos questions en français, en espagnol ou en portugais et obtenez la réponse tirée de la documentation en anglais.
Modifications, rapports, fichiers et e-mails, chacun attendant votre feu vert.
Collez la réclamation dans les mots du client et laissez Butler retrouver l’appel.
Interrogez Butler sur votre propre appel échoué
Déployé en 48 heures, sans engagement, dans l’application de messagerie que votre équipe utilise déjà.
En soumettant ce formulaire, vos informations seront traitées conformément à notre Politique de confidentialité.