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.
bind_transceiverOuvrir et authentifier la sessionbind_transceiver_respSession acceptéesubmit_smEnvoyer un messagesubmit_sm_respAccepté, ID du message renvoyédeliver_smAccusé de réception ou message entrantdeliver_sm_respConfirméenquire_linkKeepalive en cas d'inactivité
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.
| # | 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é.
| 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.
| 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é.
| 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équemment posées
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.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.