# SMPP submit_sm : tous les champs obligatoires

> submit_sm (command_id 0x00000004) envoie un message mobile-terminated de l'ESME vers le SMSC. Son corps est une séquence fixe de champs obligatoires — adressage (TON/NPI + adresse), esm_class, protocol_id, priority_flag, planification, registered_delivery, data_coding, sm_length et short_message — éventuellement suivie de TLV. submit_sm_resp renvoie le message_id du SMSC.

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

Une référence complète champ par champ de submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message et le reste — avec les valeurs qui comptent vraiment.

## L'ordre complet des champs obligatoires

Le corps de submit_sm est une séquence fixe et ordonnée — il n'y a pas d'étiquettes de champ, donc l'ordre et la taille sont primordiaux. Le tableau liste tous les paramètres obligatoires dans l'ordre du fil. short_message peut être vide lorsque le texte est porté à la place dans un TLV message_payload ; ne renseignez pas les deux.

*Paramètres obligatoires de submit_sm (dans l'ordre du fil)*

| # | Champ | Type | Notes |
|---|---|---|---|
| 1 | service_type | C-Octet String (6) | Catégorie de service ; généralement vide |
| 2 | source_addr_ton | Integer (1) | Type de numéro de l'expéditeur |
| 3 | source_addr_npi | Integer (1) | Plan de numérotation de l'expéditeur |
| 4 | source_addr | C-Octet String (21) | Adresse de l'expéditeur / identifiant alphanumérique |
| 5 | dest_addr_ton | Integer (1) | Type de numéro du destinataire |
| 6 | dest_addr_npi | Integer (1) | Plan de numérotation du destinataire |
| 7 | destination_addr | C-Octet String (21) | MSISDN du destinataire |
| 8 | esm_class | Integer (1) | Mode de message + type + indicateur UDHI |
| 9 | protocol_id | Integer (1) | GSM TP-PID ; généralement 0 |
| 10 | priority_flag | Integer (1) | 0 (normal) – 3 (maximum) |
| 11 | schedule_delivery_time | C-Octet String (1\|17) | Vide = immédiat |
| 12 | validity_period | C-Octet String (1\|17) | Vide = SMSC par défaut |
| 13 | registered_delivery | Integer (1) | Demander un accusé de réception |
| 14 | replace_if_present_flag | Integer (1) | 0 = non, 1 = remplacer |
| 15 | data_coding | Integer (1) | Encodage / DCS |
| 16 | sm_default_msg_id | Integer (1) | Identifiant du message prédéfini ; généralement 0 |
| 17 | sm_length | Integer (1) | Longueur de short_message (0–254) |
| 18 | short_message | Octet String (0–254) | La charge utile du message |

## Adressage : TON et NPI

source_addr et destination_addr portent chacun un Type of Number (TON) et un Numbering Plan Indicator (NPI). Pour un MSISDN international, utilisez TON 1 (International) avec NPI 1 (ISDN/E.164). Pour un identifiant d'expéditeur alphanumérique, utilisez TON 5 (Alphanumeric) — source_addr contient alors jusqu'à 11 caractères GSM-7. Un TON/NPI erroné est une cause majeure de trafic non remis ou mal routé.

*Valeurs courantes de TON et NPI*

| TON | Signification | NPI | Signification |
|---|---|---|---|
| 0 | Inconnu | 0 | Inconnu |
| 1 | International | 1 | ISDN (E.163/E.164) |
| 2 | National | 3 | Données (X.121) |
| 3 | Spécifique au réseau | 4 | Telex (F.69) |
| 4 | Numéro d'abonné | 6 | Mobile terrestre (E.212) |
| 5 | Alphanumérique | 8 | National |
| 6 | Abrégé | 9 | Privé |

## esm_class

esm_class est un champ de bits qui définit le mode de messagerie, le type de message et des fonctions propres au GSM. Le bit le plus important pour les expéditeurs est UDHI (0x40) : positionnez-le lorsque short_message commence par un User Data Header, par exemple un en-tête de concaténation. Le bit 0x80 demande le reply path GSM.

*Signification des bits d'esm_class (sélection)*

| Bits | Champ | Valeur → signification |
|---|---|---|
| 1–0 | Mode de messagerie | 0 par défaut · 1 datagramme · 2 transfert · 3 stockage et retransmission |
| 5–2 | Type de message | 0 par défaut · 0x04 accusé de réception · 0x08 acquittement de remise · 0x10 acquittement utilisateur |
| 6 | UDHI | 0x40 = short_message begins with a UDH |
| 7 | Chemin de réponse | 0x80 = set GSM reply path |

## data_coding, registered_delivery et validité

data_coding sélectionne l'encodage du texte : 0x00 = défaut du SMSC (généralement GSM 7 bits), 0x04 = binaire 8 bits, 0x08 = UCS-2 pour l'Unicode. Les deux bits de poids faible de registered_delivery contrôlent les accusés : 0 = aucun, 1 = accusé au succès ou à l'échec final, 2 = à l'échec seulement. validity_period et schedule_delivery_time utilisent la forme absolue YYMMDDhhmmsstnnp ou une forme relative ; une chaîne vide signifie remise immédiate et validité par défaut du SMSC. Gardez validity_period court pour les OTP afin qu'un code retardé expire plutôt que d'arriver périmé.

*data_coding — les valeurs que vous utilisez réellement*

| Valeur | Encodage |
|---|---|
| 0x00 | Alphabet par défaut du SMSC (généralement GSM 7 bits) |
| 0x03 | Latin-1 (ISO-8859-1) |
| 0x04 | binaire 8 bits (octet non spécifié) |
| 0x08 | UCS-2 (UTF-16BE) — Unicode |

## La réponse

submit_sm_resp (0x80000004) renvoie command_status et, en cas de succès, un message_id (C-Octet String, jusqu'à 65 caractères) que le SMSC attribue au message. Conservez-le : c'est la clé que vous rapprochez du receipted_message_id dans l'accusé de réception. Méfiez-vous des divergences de format — certains SMSC renvoient l'id en hexadécimal au submit et en décimal dans le DLR, aussi normalisez les deux lors de la corrélation.

## Questions fréquentes

### Quels TON/NPI utiliser pour un identifiant d'expéditeur alphanumérique ?

Utilisez source_addr_ton = 5 (Alphanumeric) et source_addr_npi = 0 (Unknown). source_addr contient alors jusqu'à 11 caractères GSM-7. Les identifiants d'expéditeur alphanumériques sont en affichage seul et ne peuvent recevoir de réponses.

### Comment demander un accusé de réception dans submit_sm ?

Positionnez registered_delivery = 1 pour un accusé à la remise finale ou à l'échec, ou 2 pour l'échec seulement. Ne demandez des accusés que là où vous les consommez réellement, car des DLR non lus gaspillent du débit.

### Quelle est la longueur maximale de short_message ?

Le champ short_message contient jusqu'à 254 octets, sm_length en donnant le nombre exact. Pour un texte plus long, soit segmentez avec un UDH sur plusieurs PDU submit_sm, soit portez toute la charge utile dans le TLV message_payload au lieu de short_message.

### Puis-je renseigner à la fois short_message et message_payload ?

Non. Renseignez l'un ou l'autre. Les fournisseurs rejettent un submit_sm qui porte le message à la fois dans le champ obligatoire short_message et dans le TLV message_payload.

### Comment envoyer un message Unicode ?

Positionnez data_coding = 0x08 (UCS-2) et encodez le texte en UTF-16 big-endian dans short_message. Un SMS UCS-2 unique contient 70 caractères ; un texte Unicode plus long est segmenté à 67 caractères par partie.

## Sources

- [SMPP v3.4 specification — §4.4 submit_sm](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [3GPP TS 23.040 — SMS technical realization](https://www.3gpp.org/dynareport/23040.htm)

## Voir aussi

- [deliver_sm et messages MO SMPP](https://www.broadnet.me/fr/reference/smpp-deliver-sm)
- [Schéma de codage des données (DCS)](https://www.broadnet.me/fr/reference/data-coding-scheme-dcs)
- [Segmentation SMS et UDH](https://www.broadnet.me/fr/reference/sms-segmentation-concatenation-udh)
- [Décodeur de PDU SMPP (outil gratuit)](https://www.broadnet.me/fr/tools/smpp-pdu-decoder)
- [Produit API SMS](https://www.broadnet.me/fr/products/sms-api)