Analyse du protocole SMPP à l’aide de Wireshark
Cet article vous explique comment analyser le protocole SMPP à l'aide de Wireshark pour Adobe Campaign Classic.
Description description
Environnement
Adobe Campaign Classic (ACC)
Problème/Symptômes
Découvrez comment analyser le trafic SMPP à l’aide de Wireshark.
La plupart des centres de service de messages courts (SMS-C) à haut débit sont compatibles avec le protocole SMPP version 3.4. Ce protocole permet d'envoyer des SMS et de recevoir des informations sur la diffusion de ces SMS. Le protocole SMPP est documenté dans la spécification du protocole SMPP v3.4 disponible sur Internet au format PDF.
Cet article ne remplace pas cette spécification : il fournit des conseils pratiques sur la manière d’interpréter la spécification du protocole et de la faire correspondre à l’affichage Wireshark pour résoudre les problèmes entre Adobe Campaign et le partenaire SMS-C.
Comme le protocole SMPP contient de nombreuses parties à l'interprétation de l'équipe de mise en oeuvre, il existe des différences entre les différents SMS-C.
Lorsque vous résolvez les problèmes, contactez toujours le partenaire SMS-C pour obtenir des informations ou qu’il vous aide à vérifier ce que vous obtenez. Si le SMS-C répond avec une erreur, votre partenaire SMS-C sera la personne la plus indiquée pour vous dire pourquoi il a répondu avec cette erreur. Si vous utilisez un simulateur SMPP au lieu de vous connecter à un véritable SMS-C, vous devez utiliser le code source (ou un débogueur) pour comprendre ce qu’il se passe.
Résolution resolution
Capture du trafic réseau sans Wireshark
Si vous n’avez pas d’accès direct à la machine, il peut être nécessaire de capturer à l’aide d’outils de ligne de commande tels que tcpdump. Si vous connaissez déjà le port TCP de la connexion, appliquez le filtre approprié afin d’éviter de capturer tout le trafic. Voici un exemple de ligne de commande tcpdump pour capturer le port 12345 sur outfile.pcap :
tcpdump -i any -w outfile.pcap tcp port 12345
Le fichier outfile.pcap peut ensuite être ouvert dans Wireshark pour une analyse plus approfondie.
Cette rubrique suppose que vous connaissez les principes de base de Wireshark : la capture de paquets, la définition de filtres simples, la lecture des détails des paquets. Une brève introduction est disponible sur howTogether - How to Use Wireshark to Capture, Filter, and Inspect Packets.
Pour filtrer le trafic SMPP dans Wireshark, il existe trois fonctionnalités importantes :
-
Utilisez un filtre d’affichage sur le port du SMSC. Par exemple, si le SMS-C utilise le port 10000, utilisez le filtre suivant :
tcp.port == 10000 -
Pour isoler des paquets par numéro de téléphone ou par contenu textuel, utilisez la fonction de recherche avec les paramètres suivants :
-
Utilisez l’outil Suivez le flux TCP pour isoler le flux que vous utilisez.
Fermez la fenêtre de texte rouge/bleu qui s’affiche, car elle n’est utile que pour les protocoles de texte qui ne sont pas pertinents pour SMPP.
-
SMPProtocol
Le protocole fonctionne sur TCP et est entièrement binaire, ce qui signifie que des outils spéciaux comme Wireshark (ou un éditeur hexadécimal) sont nécessaires pour déchiffrer le contenu du flux.
Le flux est constitué de PDU indépendants : chaque PDU est un message contenant une commande, un statut, un numéro de séquence et d’autres informations basées sur la commande.
En raison de la nature du protocole TCP en tant que protocole de diffusion, un paquet TCP peut contenir plusieurs PDU et les PDU peuvent couvrir plus de 2 paquets TCP. Wireshark réassemblera correctement les PDU, il est donc principalement transparent pour l'utilisateur Wireshark.
Voici un exemple de PDU qui transite par le réseau lors de l'envoi d'un MT, puis de la réception d'un SR :
Remarque : La liste des commandes standard se trouve dans la section 5.1.2.1 de la spécification SMPP (ensemble de commandes SMPP).
Réponses SMPP
Le protocole SMPP requiert que toutes les commandes soient acquittées par un PDU de réponse :
BIND_TRANSMITTER est reconnu par BIND_TRANSMITTER_RESP, SUBMIT_SM est reconnu par SUBMIT_SM_RESP, etc.
Il existe un délai d’attente pour les réponses, généralement 10, 30 ou 60 secondes. La réponse peut contenir un accusé de réception positif (command_status = 0) ou une erreur (voir 5.1.3 command_status, table 5-2 dans la spécification SMPP pour la liste des erreurs standard). La plupart du temps, ces réponses sont immédiates et un délai d’attente de réponse n’est pas atteint.
Veillez à faire la distinction entre les erreurs de réponse SMPP et les codes d’erreur SR : le même code d’erreur peut signifier différentes choses dans l’erreur de réponse ou dans le champ d’erreur SR. Lorsque vous signalez un code d’erreur, vous devez faire très attention à l’emplacement où vous l’avez trouvé, car la signification de la valeur dépend de son contexte.
Initialisation de la connexion SMPP
La connexion SMPP commence par une connexion via TCP. Ensuite, une opération BIND est envoyée par l’opération, acquittée par un RESP BIND. Ces opérations sont décrites dans la section 4.1 de la spécification SMPP (opération BIND).
L’opération de liaison effectue la vérification de connexion/mot de passe et exchange des informations sur le nom, la version et les autres champs de la plateforme décrits dans la spécification.
Remarque : La connexion se trouve dans le champ system_id .
Dans Campaign, vous devriez voir un paquet BIND_TRANSMITTER lors de l’initialisation d’un transfert MT et un paquet BIND_RECEIVER lorsque nlsm s déclenche une connexion MO/SR.
Émetteur, récepteur et émetteur/récepteur : le connecteur SMPP pour Campaign Classic fonctionne en mode émetteur/récepteur distinct : il existe deux connexions TCP, l’une pour transmettre MT et l’autre pour recevoir MO et SR. Notez que la connexion TCP est toujours lancée par Campaign, même pour le mode récepteur.
SMPP fournit également un mode émetteur-récepteur, mais ce mode n’est pas implémenté dans le connecteur SMPP pour Campaign Classic.
Le connecteur SMPP utilise plusieurs connexions en parallèle pour transmettre MT. Cela ne peut pas être contrôlé en raison de la conception du connecteur.
Réception de MO
Lorsque le récepteur est lié, le SMS-C peut envoyer un MO à tout moment. Le MO est envoyé à l'aide d'un PDU DELIVER_SM avec les bits 2-5 de esm_clas s effacés (souvent, esm_class sera simplement 0).
Le PDU DELIVER_SM doit recevoir une réponse rapide d’un PDU DELIVER_SM_RESP avec le même numéro_séquence.
Envoi de MT
Pour envoyer un MT, l'émetteur doit être lié avec succès. Avant toute autre chose, vérifiez que le processus de création de lien a bien été effectué.
Le MT est envoyé dans un PDU SUBMIT_SM. Le SMS-C doit répondre rapidement avec un PDU SUBMIT_SM_RESP : ce paquet de réponse est spécial car il contient l’identifiant du message dans la base de données du SMS-C (incluez toujours cet identifiant lors de la conversation avec le partenaire SMS-C pour l’aider à trouver le message plus rapidement). Cet identifiant sera présent dans le SR et est le seul moyen de faire correspondre le MT avec son SR correspondant.
Le champ registered_delivery (décrit dans la section 5.2.17 de la spécification) indique au SMSC si un SR est demandé pour ce MT particulier. Si vous ne recevez pas de SR pour un message spécifique, vérifiez que le champ est correctement défini dans le PDU SUBMIT_SM.
Encodage de MT
Attention : l'encodage des SMS est un sujet complexe avec de nombreux pièges et différentes mises en oeuvre.
Il est recommandé de toujours contacter le partenaire SMS-C en cas de problème d'encodage. Votre partenaire SMS possède une connaissance précise de l'encodage pris en charge et des règles spéciales qui peuvent s'appliquer en raison de limitations de sa plateforme technique. Faites-leur vérifier ce que vous leur envoyez et ce qu'ils vous renvoient. C'est le seul chemin vers une interconnexion stable et réussie.
Les messages SMS utilisent un encodage spécial de 7 octets, souvent appelé encodage GSM7. Reportez-vous à Wikipédia GSM 03.38 (en anglais).
Dans le protocole SMPP, le texte GSM7 sera étendu à 8 bits par caractère pour faciliter le résolution des problèmes. Le SMS-C le compresse en 7 bits par caractère avant de l’envoyer au mobile. Cela signifie que le champ short_message du SMS peut comporter jusqu’à 160 octets dans le cadre SMPP, alors qu’il est limité à 140 octets lorsqu’il est envoyé sur le réseau mobile (l’octet le plus important est simplement ignoré).
En cas de problème d’encodage, voici quelques éléments importants à vérifier :
- D’abord, assurez-vous de connaître les caractères qui font partie de l’encodage. GSM7 est tristement célèbre pour sa prise en charge partielle des signes diacritiques (accents). Surtout en français, où « é » et « è » font partie de GSM7, mais « ê », « â » ou « ï » non. La situation n’est pas meilleure en espagnol.
- Le C cédille (ç) n’est présent que dans les majuscules de l’alphabet GSM7, mais certains téléphones le rendent en minuscules ou en lettres « smart » : la recommandation générale est d’éviter complètement la cédille (elle est encore très lisible en français) ou de passer à UCS-2.
- N’utilisez pas la norme ASCII dans les SMS, sauf si le partenaire SMS-C le demande explicitement : cet encodage réduit l’espace, car il contient des caractères 8 octets et une couverture inférieure à celle de GSM7.
- Latin-1 n’est pas toujours pris en charge : vérifiez la compatibilité avec votre partenaire SMS-C avant de tenter d’utiliser Latin-1.
- Les tableaux de conversion de langue nationale ne sont pas pris en charge par le connecteur Adobe Campaign Classic. Vous devez utiliser UCS-2 à la place.
- UCS-2 et UTF-16 sont souvent mélangés par les téléphones. C’est un problème pour les personnes qui envoient des émoticônes et d’autres caractères rarement utilisés qui ne sont pas présents dans UCS-2.
- L'encodage GSM7 n'est pas supporté par Wireshark : les caractères spéciaux ne s'afficheront pas correctement. Si vous devez vérifier si une chaîne GSM7 est correctement encodée, vous devez comparer des codes hexadécimaux avec la table GSM7.
Le champ data_coding vous indique l’encodage utilisé. Le seul problème est que la valeur 0 signifie un encodage SMS-C par défaut dans la spécification, mais en général, elle signifie GSM7. Vérifiez auprès du partenaire SMS-C quel encodage est associé à data_coding = 0 (Adobe Campaign ne prend en charge que GSM7 pour data_coding = 0).
La taille maximale d’un message dépend de son encodage. Ce tableau récapitule toutes les informations pertinentes :
En-tête de données utilisateur (UDH)
UDH (User Data Header) sont de petits en-têtes binaires ajoutés au texte d’un SMS. Ils peuvent déclencher des fonctionnalités spéciales telles que la concaténation SMS, les tableaux de changement de la langue définie, les logos/images (rarement utilisés) ou les notifications push WAP.
Comme l’UDH fait partie du champ de texte (champ SMPP short_message), il raccourcit la taille effective d’un SMS. Par exemple, un UDH SMS concaténé consomme 6 octets par partie SMS (c’est-à-dire 6 vrais octets 8 bits et non des caractères à 7 bits), laissant suffisamment de place pour seulement 152 caractères 7 bits par partie de message.
Wikipedia contient des articles intéressants sur l’en-tête de données utilisateur et les SMS concaténés (en anglais).
Pour savoir si un short_message contient un UDH, vérifiez les bits 6 et 7 de esm_class (voir la section 5.2.12 de la spécification). Wireshark analyse l'UDH dans l'interface et fournit des informations précises.
Dans la capture d'écran ci-dessus, vous pouvez voir l'en-tête de données de l'utilisateur dans le champ de message (1), les informations contenues dans l'UDH (2) et certaines informations supplémentaires qui n'appartiennent pas au paquet mais qui sont calculées par Wireshark (3) : le champ Corps du message court est particulièrement intéressant, car il contient le message complet reconstitué par Wireshark.
Réception de SR
Lorsque le récepteur est lié, le SMS-C peut envoyer du SR à tout moment. Le SR est envoyé à l'aide d'un PDU DELIVER_SM avec les bits 2-5 de esm_class défini.
Le PDU DELIVER_SM doit recevoir une réponse rapide d’un PDU DELIVER_SM_RESP avec le même numéro_séquence. Pour trouver le MT correspondant à ce SR, recherchez un SUBMIT_SM_RESP avec le même ID. Par exemple, il s'agit du MT correspondant au SR :
Les SR sont envoyés uniquement si le champ registered_delivery est défini dans le MT.
Remarque : Le connecteur SMPP Adobe Campaign Classic ne gère pas les SR qui arrivent avant le paquet SUBMIT_SM_RESP. La spécification n’interdit pas explicitement ce comportement, mais il est considéré comme un comportement incorrect (cela signifie que le message a été reçu avant d’être envoyé). Si vous rencontrez ce cas trop souvent, demandez à votre partenaire SMS-C de réparer sa plateforme.
Décryptage du champ short_message du SR
Le champ de texte des PDU SR a un encodage spécial décrit dans l'Annexe B de la spécification du protocole SMPP. Malheureusement, ce format n’est qu’une recommandation et ne fait pas partie du protocole, même si la plupart des SMS-C respectent plus ou moins ce format.
Vous devez demander directement au partenaire SMS-C une documentation sur sa propre mise en oeuvre et vérifier qu'il correspond à ce que vous voyez dans Wireshark. Le plus souvent, les personnes en charge de la mise en œuvre des SMS-C ne connaissent même pas leur propre mise en œuvre, ce qui entraîne des problèmes et des malentendus. N’hésitez pas à demander de l’aide au partenaire SMS-C en cas de doutes sur ce champ (notamment les codes d’erreur).
Le format de base est le suivant :
id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........
Voici des instructions générales pour lire la ligne ci-dessus :
- L'ID est le même que celui qui a été envoyé dans le SUBMIT_SM_RESP du MT correspondant.
- Vous pouvez ignorer les problèmes dans le champ de texte : ce champ est ignoré par Campaign car il est inutile, non fiable et peut même être complètement illisible si le SMS a été envoyé en utilisant un autre encodage que l'ASCII alphanumérique pur. C’est un comportement normal.
- Les noms de champ ne sont pas sensibles à la casse (par exemple, id: sub: Text: peut également être noté en tant qu’ID: SUB: text:).
- Le champ dlvrd n’est généralement pas fiable, sauf s’il est documenté par le partenaire SMS-C.
- Les dates peuvent avoir n’importe quel fuseau horaire, ce qui les rend inutiles, ou elles sont simplement fausses car l’horloge du serveur distant est éteinte.
- Le champ stat peut avoir d’autres valeurs que celles définies dans l’Annexe B. Utilisez le bon sens et la documentation du partenaire SMSC pour comprendre sa signification.
- Le champ err dépend entièrement du SMS-C, et la plupart du temps il est documenté par le partenaire SMS-C. Souvent, le code 000 signifie un succès, tandis que tout autre code indique des erreurs. Le champ est souvent numérique mais peut également être hexadécimal.
Plusieurs SR pour le même MT
Certains SMS-C envoient plusieurs SR pour le même MT pour suivre la progression du MT dans le réseau. Cette opération est principalement inutile, car la plupart du temps le client souhaite uniquement savoir quand le message a été reçu (il s’agit généralement du dernier SR).
En cas de doute, ne travaillez que sur le dernier SR reçu du SMS-C pour trouver l'état d'un message.
Fenêtre SMPP
Les opérations et les réponses étant asynchrones, vous pouvez optimiser les taux de transfert en envoyant plusieurs PDU d’opération avant d’attendre les réponses. Le nombre de messages sans réponse est appelé la fenêtre.
Exemple de transmission avec une fenêtre maximale de 4 :
L’implémentation actuelle ne contrôle pas la fenêtre et s’attend à ce que le SMS-C distant soit suffisamment rapide pour gérer les MT.