Fondamentaux du SMPP

Le SMPP — Short Message Peer-to-Peer — est le protocole binaire à sessions que les agrégateurs et les opérateurs exposent pour la messagerie A2P à haut débit. Là où une API REST est pratique et sans état, le SMPP est une connexion TCP persistante conçue pour le volume et la faible latence.

Un ESME (External Short Messaging Entity — votre côté) ouvre une session vers le SMSC et échange des PDU (Protocol Data Units). Le protocole est compact et efficace, ce qui explique pourquoi il reste l'ossature des gros émetteurs même si le REST couvre les usages courants.

La version la plus déployée est SMPP v3.4 ; la v5.0 ajoute une signalisation d'état de congestion et des paramètres enrichis, mais reste rétrocompatible. Vous ne devriez jamais supposer qu'une fonctionnalité v5.0 est disponible tant que la réponse au bind n'a pas confirmé la version négociée.

Avant d'envoyer quoi que ce soit, un ESME doit effectuer un bind — s'authentifier et déclarer un rôle. Un bind transmitter n'envoie que des messages ; un bind receiver ne reçoit que les messages mobile-originated et les accusés de réception ; un bind transceiver fait les deux sur une seule connexion.

Le transceiver est généralement préféré car il réduit de moitié le nombre de connexions et simplifie la corrélation des DLR avec les soumissions. Le nombre de binds simultanés et le débit par bind en messages par seconde (TPS) sont provisionnés par le fournisseur et doivent être respectés.

Le bind transporte un system_id, un password, un system_type et un address_range. Un address_range mal renseigné casse silencieusement le routage des MO et des DLR sur les binds receiver — un bug d'intégration classique qui ne produit aucune erreur, seulement du trafic manquant.

Chaque interaction SMPP est un PDU composé d'un en-tête de commande (longueur, identifiant de commande, statut, numéro de séquence) et d'un corps. Le cheval de bataille est submit_sm, qui transporte un message sortant unique.

Deux paires de champs déterminent l'adressage : source_addr avec son TON/NPI (type-of-number / numbering-plan-indicator) et dest_addr avec les siens propres. Un sender ID alphanumérique utilise le TON 5 ; un MSISDN international utilise le TON 1, NPI 1. Une erreur sur ces champs et le sender ID s'affiche mal, ou le message est rejeté.

Le champ data_coding définit l'encodage — GSM 7 bits (0), 8 bits (4), ou UCS-2 (8) pour l'Unicode. Les messages longs sont concaténés soit avec des octets UDH dans le corps, soit avec les paramètres optionnels SAR (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum) ; choisissez une méthode et restez-y fidèle, car les routes n'acceptent pas toutes les mêmes.

Le SMPP utilise une fenêtre de transmission : un plafond sur le nombre de PDU submit_sm envoyés avant que leurs réponses ne reviennent. Dépasser la fenêtre, ou le TPS provisionné, déclenche ESME_RTHROTTLED (0x58). La bonne réponse consiste à ralentir avec du jitter, pas à réessayer en boucle serrée.

Pour détecter une connexion TCP à moitié ouverte, chaque partie envoie enquire_link sur une minuterie d'inactivité (typiquement toutes les 30 à 60 secondes) et attend un enquire_link_resp. L'absence de réponse signifie que la session est morte et doit être re-bindée avec un backoff exponentiel.

L'arrêt propre utilise unbind / unbind_resp. Les déconnexions inattendues doivent déclencher une reconnexion avec backoff et des tentatives idempotentes, afin qu'une fenêtre coupée ne provoque pas de double soumission ni de double facturation.

Les accusés de réception arrivent sous forme de PDU deliver_sm. Le texte de l'accusé dans le champ short_message transporte id, sub, dlvrd, la date de soumission, la date d'achèvement, le stat final (DELIVRD, UNDELIV, EXPIRED, REJECTD) et un code err.

Corrélez le DLR à votre soumission d'origine à l'aide du message_id du fournisseur, et non du seul texte de l'accusé — le message_id peut être renvoyé en hexadécimal dans le submit_resp mais en décimal dans le DLR, il faut donc normaliser les deux formats.

Répondez toujours par un deliver_sm_resp. Un DLR non acquitté est renvoyé par le SMSC et peut bloquer la fenêtre de réception ; acquittez donc rapidement même si votre traitement en aval est asynchrone.