# Simulateur de session SMPP.

- URL canonique: https://www.broadnet.me/fr/tools/smpp-simulator
- Langue: fr
- Dernière mise à jour: 2026-10-21
- Éditeur: BroadNet (https://www.broadnet.me)
- Version Markdown de la page, générée à partir de la page affichée.

Outil de développement gratuit · Protocole

Observez une véritable conversation SMPP 3.4 : l’échange de données de protocole PDU entre un ESME et un SMSC, octet par octet. Sélectionnez une PDU pour visualiser la correspondance entre ses champs et les octets transmis.

**Cela n'envoie jamais de message**

Tout le contenu de cette page est calculé dans votre navigateur. Aucune connexion réseau n'est établie, aucune requête n'est envoyée à BroadNet ou à un tiers, et aucun message n'est transmis à un réseau. Les identifiants et horodatages des messages sont dérivés de vos données saisies ; par conséquent, les mêmes données saisies produisent toujours le même résultat. Ces informations sont données à titre d'exemple et ne sont pas réelles.

non lié

## Session

## Message

segments 1 × 160

Fits one PDU (160 characters at this encoding).

## Comportement SMSC

Le cas nominal : bind accepté, message accepté, l’accusé indique DELIVRD.

fil — ESME ⇄ SMSC 0 PDU

ESME SMSC

Rien n'est encore arrivé sur le réseau. Lancez la session pour observer l'échange PDU, ESME et SMSC, puis sélectionnez-en un pour afficher ses octets.

## Comment se déroule réellement une session SMPP

1. **1 · Lier.** Votre application établit une connexion TCP avec le SMSC et envoie la commande bind_transceiver avec un identifiant système et un mot de passe. Tant que le SMSC n'a pas répondu avec le code d'état de commande 0, aucune autre commande n'est acceptée.
2. **2 · Soumettre.** Chaque message est une PDU submit_sm. La réponse vous donne un message_id — il s'agit d'une acceptation, et non d'une livraison.
3. **3 · Reçu.** Si vous en avez fait la demande, le SMSC envoie ensuite un deliver_sm contenant esm_class 0x04 et un corps de reçu faisant référence à ce message_id.
4. **4 · Rester en vie.** enquire_link toutes les 30 à 60 secondes permet de confirmer que la connexion est toujours active. Si vous manquez cette vérification, le SMSC vous déconnectera.
5. **5 · Délier.** Raccrochez poliment pour que l'opérateur ne considère pas cela comme une déconnexion anormale.

## Questions que se posent les ingénieurs

**Ce simulateur envoie-t-il de vrais SMS ?**

Non. Aucune connexion n'est ouverte ni aucun message envoyé depuis cette page. Chaque PDU et chaque réponse SMSC sont calculées dans votre navigateur à partir des valeurs que vous saisissez ; ainsi, les mêmes entrées produisent toujours le même résultat. Il s'agit d'un outil pédagogique pour le protocole, et non d'un outil d'envoi.

**Qu'est-ce qu'une liaison dans SMPP ?**

Une liaison (bind) correspond à l'établissement d'une session entre un ESME (votre application) et le SMSC (centre de messagerie de l'opérateur). L'émetteur (bind_transmitter) ne peut qu'envoyer des données, le récepteur (bind_receiver) ne peut qu'en recevoir, et le récepteur (bind_transceiver) effectue les deux opérations sur une même connexion — ce qui est le comportement le plus courant des intégrations. Aucune autre donnée n'est acceptée sur la session tant que la liaison n'est pas établie.

**Que fait la fonction registered_delivery ?**

Définir registered_delivery sur 1 demande au SMSC de confirmer le résultat final. Cette confirmation arrive ultérieurement sous la forme d'une PDU deliver_sm distincte contenant esm_class 0x04 — l'accusé de réception — qui fait référence à l'identifiant de message (message_id) fourni dans submit_sm_resp. Sans cette confirmation, vous savez seulement que le SMSC a accepté le message, et non qu'il a été reçu par un terminal.

**Pourquoi mon message est-il divisé en plusieurs segments ?**

Un seul PDU SMS transporte 160 caractères en alphabet GSM-7 ou 70 en UCS-2. Les textes plus longs sont concaténés : chaque segment utilise 6 octets pour l’en-tête de données utilisateur, permettant ainsi au terminal de les réassembler et de conserver 153 ou 67 caractères par segment. La présence d’un seul caractère arabe ou d’un seul emoji force l’encodage du message entier en UCS-2 ; c’est pourquoi un message arabe de 100 caractères nécessite deux segments.

**Quelle est la différence entre submit_sm_resp et un accusé de réception de livraison ?**

submit_sm_resp est synchrone et indique uniquement que le SMSC a accepté le PDU et lui a attribué un `message_id`. L'accusé de réception arrive de manière asynchrone, souvent quelques secondes ou minutes plus tard, et indique le résultat réel : `DELIVRD`, `UNDELIV`, `EXPIRED` ou `REJECTD`. Considérer submit_sm_resp comme une preuve de livraison est l'erreur la plus fréquente lors d'une première intégration SMPP.

**Qu'est-ce qu'une fenêtre SMPP et pourquoi limite-t-elle mon débit ?**

La fenêtre correspond au nombre PDU pouvant avoir été envoyés mais non acquittés lors d'une liaison à un instant donné. Le SMPP étant asynchrone, vous n'attendez pas la réponse de chaque submit_sm_resp avant d'envoyer le suivant ; toutefois, la fenêtre limite l'avance possible. Si sa valeur par défaut est de 1, la liaison se réduit à un modèle requête/réponse et votre débit chute à un message par aller-retour, indépendamment du débit convenu avec l'opérateur.

[Décodez une véritable PDU que vous avez capturée](https://www.broadnet.me/fr/tools/smpp-pdu-decoder) [Référence du code d'erreur SMPP](https://www.broadnet.me/fr/tools/smpp-error-codes) [Aperçu du protocole SMPP](https://www.broadnet.me/fr/reference/smpp-protocol-overview) [Cours de base sur SMPP](https://www.broadnet.me/fr/academy/smpp-fundamentals) [Connexion à BroadNet via SMPP](https://www.broadnet.me/fr/developers/smpp)