Panne de connectivité ou dégradation d’une route A2P SMS : isoler la cause à partir des faits

Connectivité, acceptation et livraison sont des signaux distincts

Un incident SMS A2P peut survenir à différents endroits du parcours. La connexion peut échouer avant l’envoi du message ; la plateforme ou le SMSC peut le rejeter ; l’envoi peut être accepté sans qu’un résultat final soit encore disponible ; ou une panne peut survenir après l’acceptation. Chaque situation nécessite des éléments de preuve différents.

En SMPP, une réponse positive à submit_sm indique que le SMSC a accepté le message pour un envoi ultérieur. Elle ne confirme pas, à elle seule, que le message est arrivé sur le téléphone. De même, ENQUIRE_LINK et ENQUIRE_LINK_RESP vérifient la connexion applicative entre l’ESME et le SMSC, et non la livraison par le réseau mobile.

• Connexion ou session : vérifiez si le client peut établir et maintenir la communication avec l’interface.
• Réponse à l’envoi : déterminez si la requête a été acceptée ou rejetée et consignez le motif disponible.
• Résultat ultérieur : corrélez les rapports d’état avec le message d’origine et vérifiez quelle entité les a émis.
• Réception par une personne : ne déduisez pas qu’une personne a lu le SMS à partir d’une réponse de protocole ou d’un DLR.

Délimitez le parcours et conservez les identifiants

Avant de modifier des routes ou la configuration, dessinez le parcours réellement emprunté par le trafic : application cliente, intégration HTTP ou session SMPP, plateforme, fournisseur et destination mobile. Notez où chaque journal est créé et qui génère chaque réponse. Le fonctionnement interne d’un Service Centre peut dépasser ce qu’une interface ou une spécification permet d’observer ; tenez compte de cette limite dans l’analyse.

Conservez suffisamment d’horodatages et de références pour relier les différentes étapes. En SMPP, consignez le numéro de séquence de la requête et de la réponse, l’identifiant de message renvoyé et, si un reçu arrive, sa référence au message d’origine. Pour HTTP, conservez l’identifiant de requête disponible, l’heure, le point de terminaison et la réponse. Ne supposez pas que les identifiants de systèmes différents sont interchangeables.

• Consignez l’heure d’envoi et le fuseau horaire, la destination au format normalisé, l’expéditeur, le type de trafic et la route sélectionnée.
• Conservez le code HTTP ou l’état SMPP, le corps de la réponse ou les champs d’erreur pertinents, ainsi que l’identifiant de corrélation disponible.
• Ajoutez l’heure et la source de chaque callback ou DLR, ainsi que sa référence au message.
• Protégez les données personnelles et limitez l’accès aux journaux conformément aux politiques applicables.

Commencez par vérifier l’intégration

Commencez par la partie que vous contrôlez. En HTTP, distinguez les erreurs de transport des réponses HTTP et examinez le code, le corps de la réponse et toute indication de nouvelle tentative. Un 503 signifie que le serveur ne peut temporairement pas traiter la requête ; cela peut notamment être lié à une surcharge ou à une maintenance, et Retry-After peut indiquer le délai à respecter. Un 429 signifie que le serveur estime qu’un trop grand nombre de requêtes a été envoyé sur une période donnée ; la réponse peut également inclure Retry-After. Un 502 signale un problème de passerelle ou de proxy lié à une réponse non valide du serveur upstream, mais ne permet pas, à lui seul, d’identifier le composant à l’origine du problème.

En SMPP, vérifiez l’état du bind, les déconnexions, les délais d’attente, les réponses aux requêtes et l’état de la session. ESME_RTHROTTLED (0x58) indique que l’ESME a dépassé les limites autorisées sur cette interface. C’est un indice de limitation du débit à cet endroit, et non la preuve d’une dégradation d’une route de destination.

Vérifiez également la file d’attente locale, la confirmation de réception des callbacks et la logique de nouvelles tentatives. SMPP ne garantit pas à lui seul l’idempotence. En cas de dépassement du délai d’attente, ce seul signal peut ne pas permettre de savoir si le SMSC a traité la requête. Avant de réessayer, utilisez les mécanismes documentés de corrélation et de consultation d’état disponibles, le cas échéant ; ne supposez pas qu’il est toujours possible de déterminer si l’opération a déjà été acceptée.

• En cas d’échec de connexion ou de bind, examinez d’abord les identifiants, la configuration de session, la connectivité et les limites de l’interface.
• Si vous recevez des rejets, regroupez-les par code et conservez les réponses d’origine avant de modifier les paramètres.
• En présence de 429 ou de ESME_RTHROTTLED, comparez le volume et le débit des requêtes aux limites convenues ; ne les qualifiez pas automatiquement de panne de couverture.
• En cas de 503 ou de 502, contactez le responsable du composant ayant répondu et fournissez l’heure, l’identifiant et la réponse observée.

Recherchez des tendances selon la destination et les attributs du trafic

Pour enquêter sur une dégradation de route, recherchez des différences reproductibles entre des segments plutôt que d’examiner un message isolé. Comparez les destinations, les opérateurs lorsque l’information est fiable, les expéditeurs, le type de trafic, la route et la période. Dans la mesure du possible, maintenez constants les autres attributs pertinents : comparer des envois différents peut confondre l’effet de la route avec des changements de destinataire, d’expéditeur, de contenu ou de configuration.

Consignez le segment en échec et celui utilisé comme référence. Si l’incident coïncide avec un opérateur de destination, cela constitue une piste de délimitation, mais ne prouve pas que le réseau de cet opérateur en est la cause. Vérifiez que l’échantillon et les paramètres sont comparables et demandez des éléments de preuve supplémentaires aux parties qui contrôlent les étapes non observables.

• Regroupez les cas par pays ou destination, opérateur connu, expéditeur, type de trafic (OTP, transactionnel ou marketing), route et période.
• Comparez séparément les taux d’acceptation, de rejet et les états finaux ; ne mélangez pas des indicateurs dont les définitions diffèrent.
• Vérifiez que les messages comparés ont une configuration équivalente et que les périodes sont cohérentes.
• Notez les changements de configuration, de volume ou de comportement du client qui coïncident avec le début du problème.

Comparez des échantillons contrôlés sans confondre corrélation et causalité

Sélectionnez des échantillons équivalents et définissez à l’avance le signal que vous allez comparer : réponse à l’envoi, délai avant une réponse, réception d’un callback ou état signalé. Évitez de regrouper dans un même indicateur des événements qui surviennent à des étapes différentes. Une différence observée entre deux segments aide à formuler des hypothèses, mais ne suffit pas à établir un lien de causalité.

Lorsque cela est sûr et autorisé, effectuez des comparaisons limitées à partir de trafic légitime et consenti. Ne modifiez pas plusieurs variables à la fois : si vous changez simultanément la route, l’expéditeur et la configuration, il sera plus difficile de comprendre ce qui a influencé le résultat. Coordonnez les essais avec les responsables concernés et évitez de générer du trafic supplémentaire inutile.

• Définissez le groupe affecté, un groupe de comparaison et la période avant d’examiner les résultats.
• Contrôlez la destination, l’expéditeur, le type de message, la configuration et les conditions d’envoi pertinentes.
• Séparez les mesures d’acceptation des mesures de livraison et signalez les données manquantes.
• Répétez la comparaison sur une autre période si le volume ou la composition de l’échantillon peut expliquer la différence.

Interprétez les DLR selon leur origine et leur portée

Un DLR est un signal dont la signification dépend de son émetteur et de sa définition dans l’intégration. Dans la spécification 3GPP, un rapport du Service Centre confirme la réception par le centre, pas nécessairement par le terminal ; un rapport émis par la station mobile confirme la réception par le terminal, mais pas que l’utilisateur a lu le message. Vérifiez l’origine du rapport et l’état qu’il représente avant de l’utiliser comme élément de preuve.

Un SMS-STATUS-REPORT renseigne sur l’état de l’envoi, mais ne constitue pas automatiquement une confirmation de réception par une personne. Il peut également y avoir des différences entre ce qu’une interface désigne comme « livré » et l’événement technique qui sous-tend cet état. Si l’émetteur du DLR ou sa sémantique ne sont pas clairs, documentez cette incertitude et demandez des précisions au fournisseur.

• Corrélez le rapport avec l’identifiant du message d’origine et conservez son horodatage.
• Demandez quelle entité génère l’état, quel événement il confirme et quels états d’échec il peut représenter.
• Distinguez l’absence de DLR, le retard du rapport et un état d’échec ; ne les traitez pas comme des situations équivalentes.
• N’utilisez pas un DLR isolé pour attribuer le problème au réseau mobile, au fournisseur ou au terminal.

Arbre de décision pour isoler le problème et le faire remonter

Appliquez le diagnostic dans l’ordre, de la première étape observable jusqu’au résultat ultérieur. Arrêtez l’analyse à la première étape pour laquelle vous ne disposez pas d’éléments de preuve et demandez les journaux nécessaires ; ne passez pas d’un symptôme d’intégration à une conclusion sur le réseau de destination.

Si le service est dégradé, privilégiez des mesures sûres et réversibles : réduisez ou suspendez le trafic affecté s’il existe un risque de doublon, d’utilisation abusive ou d’impact opérationnel, et suivez la procédure convenue pour changer de route. Ne supposez pas qu’une route alternative existe, offre le même comportement ou est autorisée pour ce trafic.

• Absence de connexion HTTP ou de bind SMPP : recueillez les heures, les erreurs de transport, l’état de la session et les changements récents ; transmettez le problème à l’équipe responsable de la connectivité ou de l’intégration.
• Session établie, mais envoi rejeté : regroupez les codes et les réponses. Vérifiez le format et les limites de l’interface ; transmettez des exemples corrélables.
• Envoi accepté, mais résultat manquant : vérifiez les callbacks, les délais d’attente et la signification du DLR. Demandez au fournisseur l’état de l’étape ultérieure ; l’acceptation ne prouve pas la livraison.
• Les rapports font apparaître des échecs concentrés sur un segment : vérifiez que les échantillons sont équivalents et communiquez la tendance au fournisseur et aux parties concernées en aval, sans déclarer de cause avant de disposer d’éléments de preuve à cette étape.
• Résultats contradictoires ou identifiants impossibles à corréler : suspendez les conclusions, vérifiez les horloges, les références et les doublons, puis reconstituez le parcours à partir des journaux d’origine.

Consignez les éléments de preuve, les incertitudes et les actions

Un bon rapport permet à une autre équipe de reproduire le raisonnement sans présumer de la cause. Distinguez les faits observés, les hypothèses et les conclusions ; précisez quels systèmes ont fourni chaque journal et quelle partie du parcours reste invisible. Joignez un échantillon restreint et représentatif, en protégeant les données, plutôt que de simples captures agrégées sans identifiants.

Les normes définissent des limites et des signaux différents pour chaque étape : connexion, acceptation et rapports d’état. Le diagnostic doit tenir compte de ces limites et distinguer les observations vérifiables des hypothèses qui nécessitent encore des éléments de preuve.

• Résumez l’impact, les heures de début et de fin connues, les segments affectés et non affectés, ainsi que les changements récents.
• Incluez les horodatages, les identifiants, les réponses d’origine et la définition de chaque état analysé.
• Étiquetez chaque élément comme fait, hypothèse, donnée en attente ou action effectuée.
• Indiquez qui doit fournir le prochain élément de preuve et quand le diagnostic sera réexaminé.