SMPP : le guide complet du protocole.

Qu'est-ce qu'un SMPP et où s'applique-t-il ?

Une session SMPP comporte toujours deux rôles. L'ESME (External Short Messaging Entity) est votre application — une plateforme de SMS en masse, un service OTP, un système d'alerte. Le SMSC (Short Message Service Centre), appelé MC (Message Centre) dans la v5.0, est le nœud de l'opérateur ou de l'agrégateur qui stocke et retransmet les messages vers et depuis les terminaux via le réseau mobile. L'ESME se connecte au SMSC ; le SMSC se connecte au réseau SS7 / cœur de réseau mobile.

SMPP est l'épine dorsale de A2P (Application-Personne) Messagerie — codes de vérification, reçus, alertes, marketing — par opposition à P2P Messagerie texte (de personne à personne) entre deux téléphones portables. A2P Le trafic est volumineux, généré automatiquement et repose sur la confirmation de livraison, ce qui correspond exactement à ce pour quoi le protocole SMPP a été conçu.

Pourquoi un protocole TCP binaire plutôt que HTTP ? Une seule liaison SMPP correspond à une socket persistante. Une fois ouverte, vous évitez une négociation TCP et TLS par message, vous pouvez gérer plusieurs messages simultanément (fenêtre asynchrone), et le SMSC renvoie les accusés de réception et les messages entrants directement sur la même connexion. À haut débit soutenu, cette méthode est nettement plus efficace qu'une API HTTP requête/réponse ; c'est pourquoi les opérateurs et les grands expéditeurs l'adoptent comme standard.

Historique des versions

• SMPP v3.3 — la première version largement déployée ; elle a introduit l’ensemble de PDU de base, mais elle est antérieure aux TLV (paramètres optionnels) et à la liaison de l’émetteur-récepteur.
• SMPP v3.4 — la version dominante en production aujourd'hui. Ajout de la liaison de l'émetteur-récepteur, des paramètres TLV optionnels, de message_payload et de data_sm. Presque toutes les intégrations concrètes que vous développerez utilisent la version 3.4.
• SMPP v5.0 — La toute dernière version. Elle renomme SMSC en MC et ajoute : les PDU de diffusion (broadcast_sm), la signalisation de l’état de congestion et davantage de TLV standardisés. Son adoption est limitée ; privilégiez d’abord la version 3.4 et considérez la version 5.0 comme optionnelle.

Architecture et types de liaison

La topologie est simple : l’ESME ouvre une connexion TCP avec le SMSC/MC et s’authentifie. system_id et passwordLa direction dans laquelle la session est autorisée à acheminer le trafic est fixée lors de la liaison en choisissant l'une des trois options suivantes : modes de liaisonChaque mode correspond à une PDU de liaison différente.

Un quatrième acteur est routageLe SMSC détermine, pour chaque message, la route ou l'interconnexion en aval qu'emprunte un message soumis vers le terminal de destination, et à quel ESME lié appartient un message entrant (d'origine mobile).

Sur le réseau, le protocole SMPP utilise TCP. Le port par défaut enregistré auprès de l'IANA est : 2775 pour les connexions simples. SMPPS Le protocole SMPP chiffré avec TLS ne possède pas de port standard unique ; les fournisseurs l'exposent sur un port de leur choix (3550, 8775 et 2776 sont couramment utilisés). Utilisez toujours le port chiffré attribué par votre fournisseur pour la production.

Le cycle de vie de la session

Chaque session SMPP suit le même cycle : ouverture du protocole TCP, liaison, maintien de la connexion, échange de messages et d’accusés de réception, puis déconnexion et fermeture. Le schéma ci-dessous illustre une session complète d’émetteur-récepteur : chaque ligne représente une PDU, en bleu de l’ESME vers le SMSC, en vert pour le retour.

Deux détails importants. Premièrement, submit_sm_resp Le retour est immédiat et signifie seulement « accepté pour livraison » — le résultat final arrive plus tard. deliver_sm reçu. Deuxièmement, chaque PDU de requête a une correspondance _resp qui fait écho à son sequence_number, c'est ainsi que les réponses asynchrones sont mises en relation avec les requêtes.

Anatomie du PDU

Tout sur une connexion SMPP est un PDUChaque PDU commence par une valeur fixe En-tête de 16 octets de quatre entiers de 4 octets (32 bits, big-endian), suivis d'un corps spécifique à la commande. Lisez d'abord l'en-tête et vous saurez exactement comment lire le reste.

Le corps se termine par un nombre quelconque de TLV — Paramètres optionnels encodés sous forme de Tag (2 octets), Longueur (2 octets), Valeur (Longueur en octets). Les TLV permettent à la version 3.4 d'étendre le protocole sans impacter la compatibilité avec les versions précédentes : message_payload, receipted_message_id, les champs de concaténation sar_* et bien d'autres tous ces éléments sont gérés par des TLV.

Le numéro_de_séquence est la clé du fenêtrage. Étant donné que SMPP est asynchrone, un ESME peut envoyer plusieurs PDU submit_sm — chacune avec un numéro de séquence incrémenté — avant la réception de toute réponse. Lorsque les PDU submit_sm_resp reviennent, leur numéro de séquence indique à quelle soumission chacune répond. Le nombre de PDU non acquittés autorisés en transit est le taille de la fenêtre.

Référence des PDU de base

Voici les opérations que vous utiliserez concrètement. Chaque requête possède une PDU de réponse dont l'identifiant de commande (command_id) correspond à l'identifiant de la requête avec le bit de poids fort activé (0x80000000). Ainsi, submit_sm 0x00000004 est associé à submit_sm_resp 0x80000004.

submit_sm champ par champ

submit_sm Il s'agit du PDU que vous enverrez le plus souvent. Son corps est une séquence de paramètres obligatoires, puis de TLV optionnels. Ce sont ces champs qui importent en pratique.

Codage et concaténation des données

Le data_coding Le champ (le schéma de codage des données, DCS) indique au combiné comment interpréter les octets et détermine le nombre de caractères contenus dans un SMS. SMS

Un message de plus d'un segment est divisé puis réassemblé sur le combiné à l'aide d'un UDH (En-tête de données utilisateur) ajouté au début de chaque partie. L'élément de concaténation utilise IEI 0x00 (8 bits référence) — un en-tête de 6 octets contenant un numéro de référence, le nombre total de parties et l'index de cette partie. Ces 6 octets expliquent pourquoi les limites par partie tombent à 153 (GSM 7 bits) et 67 (UCS-2). Lorsque vous envoyez un UDH dans short_message, vous devez également activer le bit UDHI (0x40) dans esm_class.

Il existe deux façons d'envoyer du contenu long : soit créer vous-même les parties segmentées UDH (chacune étant un submit_sm avec un ensemble UDHI), soit transmettre le corps entier au SMSC dans le message_payload TLV et laissez-le segmenter. Certains SMSC acceptent plutôt les TLV sar_msg_ref_num / sar_total_segments / sar_segment_seqnum pour décrire la concaténation sans UDH.

Accusés de réception (DLR)

Lorsque vous définissez registered_delivery = 1, le SMSC vous informe ultérieurement du sort du message en vous envoyant un deliver_sm avec le bit de réception de livraison défini dans esm_class (0x04Le texte du reçu se trouve dans le champ short_message sous forme de chaîne de caractères générique :

id:1a2b3c4d5e sub:001 dlvrd:001 submit date:2607251432 done date:2607251432 stat:DELIVRD err:000 text:Your code is 8

Le id correspond à l'identifiant de message que vous avez reçu en retour dans submit_sm_resp (également affiché dans le TLV receipted_message_id 0x001E). stat Le champ indique l'état final :

Répondez toujours à un deliver_sm par un deliver_sm_respSi vous ne le faites pas, le SMSC, renverra le reçu et pourra limiter ou interrompre la liaison. Veuillez noter que le format des reçus n'est pas parfaitement standardisé : l'ordre des champs et la correspondance des codes d'erreur varient légèrement d'un fournisseur à l'autre.

Codes d'erreur / d'état de commande

Chaque PDU de réponse transporte un command_status dans son en-tête — un ESME_R* Le code zéro signifie succès ; toute autre valeur explique pourquoi la requête a été refusée. Ce sont les cas les plus fréquents.

Le registre complet, y compris les gammes de fournisseurs spécifiques à chaque prestataire, est consultable dans le Référence des codes d'erreur SMPP

Débit, fenêtrage et limitation

Le débit en SMPP est mesuré en TPS — transactions (submit_sm) par seconde — et ce débit est régi par deux facteurs : le débit autorisé par le SMSC et le nombre de messages en transit. Comme SMPP est asynchrone, vous n’avez pas besoin d’attendre chaque réponse submit_sm_resp avant d’envoyer le PDU suivant. Le nombre de soumissions non acquittées autorisées simultanément est votre taille de la fenêtre (généralement de 10 à 100). Une fenêtre plus large masque la latence aller-retour et augmente le TPS effectif, jusqu'au plafond du SMSC.

• Respectez l'accélérateur. Lorsque le SMSC renvoie ESME_RTHROTTLED (0x58), il est conseillé de patienter : faites une pause et réessayez avec un délai exponentiel plutôt que de solliciter fortement la connexion ce qui pourrait entraîner une déconnexion.
• Restez en vie à un rythme régulier. Envoyer enquire_link environ toutes les 30 secondes en cas d'inactivité ; si plusieurs requêtes restent sans réponse, considérer que le lien est rompu.
• Reconnectez-vous délibérément. En cas de déconnexion, reconnectez-vous et rétablissez la liaison avec un délai d'attente et une gigue ; n'effectuez pas de boucle serrée. Suivez les numéros de séquence en attente afin de pouvoir rapprocher les reçus après une reconnexion.
• Montez en charge avec plusieurs binds, avec précaution. Un TPS agrégé plus élevé provient généralement de plusieurs liaisons, mais seulement dans la limite autorisée par votre fournisseur par compte.

Exemple de code

Un exemple de flux de connexion → liaison → soumission en pseudocode de type Node. Les bibliothèques SMPP réelles (par exemple, node-smpp, jSMPP pour Java ou python-smpplib) gèrent l'encodage des PDU ; cet exemple illustre la structure de la session, et non l'API d'une bibliothèque spécifique.

import smpp from "smpp";

// 1. Open a TCP (or TLS) session to the SMSC.
const session = smpp.connect({
  // Host, port and bind credentials come with your test access.
  // Plain SMPP conventionally uses 2775; the TLS port is provided with your account.
  url: process.env.SMPP_URL!,             // e.g. smpp://<host>:2775 (plain) or smpps://<host>:<tls-port>
  auto_enquire_link_period: 30000,        // keepalive every 30s
});

// 2. Bind as a transceiver.
session.bind_transceiver(
  {
    system_id: "YOUR_SYSTEM_ID",
    password:  "YOUR_PASSWORD",
    system_type: "",
  },
  (pdu) => {
    if (pdu.command_status !== 0) {
      throw new Error("bind failed: 0x" + pdu.command_status.toString(16));
    }

    // 3. Submit a Unicode message, asking for a delivery receipt.
    session.submit_sm(
      {
        source_addr_ton: 5,                // alphanumeric Sender ID
        source_addr:      "BroadNet",
        dest_addr_ton:    1,               // international E.164
        destination_addr: "447700900123",
        registered_delivery: 1,            // request a DLR
        data_coding: 8,                    // UCS-2 (Unicode)
        short_message: "Your code is 8123",
      },
      (submitResp) => {
        // submit_sm_resp returns the SMSC message_id.
        console.log("accepted, message_id =", submitResp.message_id);
      }
    );
  }
);

// 4. Receive delivery receipts on the same session.
session.on("deliver_sm", (pdu) => {
  if ((pdu.esm_class & 0x04) === 0x04) {   // delivery-receipt bit
    console.log("DLR:", pdu.short_message.message);
  }
  session.send(pdu.response());            // ALWAYS deliver_sm_resp
});

BroadNet SMPP

BroadNet exploite une passerelle SMSC de qualité opérateur qui accepte les liaisons SMPP v3.4 via TLS. Vous bénéficiez ainsi : de liaisons d'émetteur-récepteur, d'un débit TPS élevé avec fenêtrage asynchrone, d'accusés de réception complets, de la prise en charge Unicode et de la concaténation, et d'une connexion autorisée par liste blanche IP pour joindre les opérateurs du monde entier. Il s'agit du même protocole que celui présenté sur cette page, configuré pour des routes réelles.

Foire aux questions

Outils et documents associés