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 à Wireshark pour une analyse plus approfondie.

Manipulation de Wireshark

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 - Comment utiliser Wireshark pour capturer, filtrer et Inspect des paquets.

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 :

    smpp1

  • Utilisez la variable 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.

    smpp2

Protocole SMPP

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 :
smpp3
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 acquitté par  BIND_TRANSMITTER_RESPSUBMIT_SM  est acquitté 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_statustableau 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).

smpp4 L’opération de liaison effectue la vérification de connexion/mot de passe et échange 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, une  BIND_TRANSMITTER  paquet lors de l’initialisation d’un transfert MT et d’un  BIND_RECEIVER  packet quand  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 des MO
Lorsque le récepteur est lié, le SMS-C peut envoyer un MO à tout moment. Le MO est envoyé à l’aide d’un  DELIVER_SM  PDU avec les bits 2 à 5 de  esm_clas s  clear (souvent,  esm_class  sera simplement 0).

smpp5 La variable *DELIVER_SM* Le PDU doit recevoir une réponse rapide d'un *DELIVER_SM_RESP* PDU avec le même *sequence_number*.

Envoi 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  SUBMIT_SM  PDU. Le SMS-C doit rapidement répondre avec une  SUBMIT_SM_RESP  PDU : 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 à la section 5.2.17 de la spécification) indique au SMSC si un SR est demandé pour ce MT spécifique. Si vous ne recevez pas de SR pour un message spécifique, vérifiez que le champ est correctement défini dans la variable  SUBMIT_SM  PDU.

smpp5

Encodage des 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.

La variable  data_coding  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érifier avec le SMS-C  partenaire 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 :

Encodage
data_coding
Taille du message (caractères)
Taille de partie pour SMS à plusieurs parties
Caractères disponibles
GSM 7
0
160
152
Jeu de caractères de base GSM7 + extension (les caractères étendus prennent 2 caractères)
Latin -1
3
140
134
ISO-8859-1
UCS-2 UTF-16
8
70
67
Unicode (varie d’un téléphone à l’autre)

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.

smpp7 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éfinie.

smpp8

La variable  DELIVER_SM  Le PDU doit recevoir une réponse rapide d'un  DELIVER_SM_RESP  PDU avec le même  sequence_number. 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 :

smpp9

Les SR ne sont envoyés que si la variable  registered_delivery  est défini dans le MT.

Remarque : Le connecteur SMPP Adobe Campaign Classic ne gère pas les SR qui arrivent avant  SUBMIT_SM_RESP  packet. 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 la variable  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:).
  • La variable  dlvrd n’est généralement pas fiable, sauf si le partenaire SMS-C le documente.
  • 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.
  • La variable  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.
  • La variable  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 :
smpp10
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.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f