# SMPP deliver_sm : messages MO et accusés

> deliver_sm (command_id 0x00000005) est envoyé du SMSC vers l'ESME pour remettre soit un message mobile-originated (MO), soit un accusé de réception (DLR). Son corps reprend celui de submit_sm. Le champ esm_class distingue les deux : le bit 0x04 marque un accusé de réception. L'ESME doit toujours répondre par un deliver_sm_resp.

- URL canonique: https://www.broadnet.me/fr/reference/smpp-deliver-sm
- Langue: fr
- Dernière mise à jour: 2026-07-18
- Éditeur: BroadNet (https://www.broadnet.me)

deliver_sm porte deux choses du SMSC vers l'ESME : les messages mobile-originated (MO) et les accusés de réception. Comment les distinguer avec esm_class, et pourquoi il faut toujours répondre deliver_sm_resp.

## Une PDU, deux fonctions

deliver_sm est l'homologue SMSC-vers-ESME de submit_sm et partage la même disposition de corps. Il porte soit un message MO entrant (un abonné qui envoie un SMS à votre numéro long ou à un code court), soit un accusé de réception rapportant le sort d'un message soumis précédemment. Votre bind receiver ou transceiver gère les deux ; vous branchez sur esm_class pour les router correctement.

## Distinguer MO et DLR avec esm_class

Les bits de type de message d'esm_class identifient la charge utile. Un message MO ordinaire a ses bits de type de message à zéro. Un accusé de réception positionne le bit 0x04. Lorsque 0x04 est positionné, short_message contient le texte d'accusé de l'Annexe B (id, stat, err…) et le TLV receipted_message_id porte généralement le message_id d'origine. N'analysez pas le texte d'accusé comme du contenu utilisateur.

*Valeurs du type de message d'esm_class sur deliver_sm*

| esm_class (bits de type de message) | Payload |
|---|---|
| 0x00 | Message normal d'origine mobile (MO) |
| 0x04 | Accusé de réception SMSC (DLR) |
| 0x08 | Accusé de réception de livraison SME |
| 0x10 | Acquittement manuel/utilisateur du SME |
| 0x20 | Interruption de conversation (CDMA coréen) |
| 0x40 | Notification de livraison intermédiaire |

## Toujours répondre par deliver_sm_resp

Pour chaque deliver_sm, l'ESME doit renvoyer un deliver_sm_resp (0x80000005) avec le même sequence_number et ESME_ROK. Si vous n'acquittez pas, le SMSC considère la remise comme échouée, la renvoie, et — parce que les PDU non acquittées comptent dans la fenêtre — peut bloquer toute la session. Acquittez rapidement et effectuez les traitements lourds de façon asynchrone.

*MO et DLR tous deux acquittés*

```text
SMSC → ESME  deliver_sm  seq=88  esm_class=0x00  (MO: user text)
ESME → SMSC  deliver_sm_resp seq=88  status=ESME_ROK
SMSC → ESME  deliver_sm  seq=89  esm_class=0x04  (DLR: id:... stat:DELIVRD)
ESME → SMSC  deliver_sm_resp seq=89  status=ESME_ROK
```

## data_sm comme alternative

data_sm (0x00000103) est une opération plus légère et épurée qui peut porter des messages MO et des accusés à l'aide de TLV (notamment message_payload) plutôt que du champ fixe short_message. Certains réseaux la préfèrent pour le trafic interactif ou de type WAP. Sa prise en charge est optionnelle et propre au fournisseur — confirmez avant de vous y fier.

## Questions fréquentes

### Comment distinguer un accusé de réception d'un message MO entrant ?

Vérifiez esm_class sur le deliver_sm. Si le bit de type de message 0x04 est positionné, c'est un accusé de réception et short_message contient le texte d'accusé de l'Annexe B. Si ces bits sont à zéro, c'est un message mobile-originated ordinaire d'un abonné.

### Que se passe-t-il si je n'envoie pas deliver_sm_resp ?

Le SMSC suppose que la remise a échoué et renvoie le deliver_sm. Les PDU non acquittées consomment aussi votre fenêtre, si bien que l'absence de réponse peut bloquer la session et produire des traitements MO/DLR en double.

### deliver_sm a-t-il les mêmes champs que submit_sm ?

Oui — deliver_sm réutilise la disposition du corps de submit_sm (service_type, adressage TON/NPI, esm_class, data_coding, short_message, etc.). Seuls le sens et l'interprétation de la charge utile diffèrent.

### Un même message MO peut-il être concaténé ?

Oui. Les longs messages entrants arrivent sous forme de plusieurs PDU deliver_sm avec un en-tête de concaténation UDH (bit UDHI 0x40 d'esm_class positionné) ou des TLV SAR. Réassemblez-les par numéro de référence et de séquence, comme pour les segments sortants.

## Sources

- [SMPP v3.4 specification — §4.6 deliver_sm](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [SMPP v3.4 specification — Appendix B (receipt format)](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)

## Voir aussi

- [Accusés de réception SMPP (format DLR)](https://www.broadnet.me/fr/reference/smpp-delivery-receipts-dlr)
- [Référence submit_sm SMPP](https://www.broadnet.me/fr/reference/smpp-submit-sm)
- [Décodeur de DLR (outil gratuit)](https://www.broadnet.me/fr/tools/dlr-decoder)
- [Paramètres optionnels TLV SMPP](https://www.broadnet.me/fr/reference/smpp-tlv-parameters)
- [SMS bidirectionnel](https://www.broadnet.me/fr/products/sms-api)