---
title: "submit_sm"
description: "submit_sm est l'opération SMPP v3.4 (command_id 0x00000004) qu'une application utilise pour soumettre un SMS unique au SMSC. Le SMSC répond par un submit_sm_resp contenant un message_id qui sert à rapprocher les accusés de réception ultérieurs."
canonical: "https://omnichannels.ai/fr/glossary/submit-sm/"
language: "fr"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
---

# submit_sm

Canonical: https://omnichannels.ai/fr/glossary/submit-sm/
Language: fr
Publisher: OmniChannels.ai by BroadNet Technologies

**Définition:** submit_sm est l'opération SMPP v3.4 (command_id 0x00000004) qu'une application utilise pour soumettre un SMS unique au SMSC. Le SMSC répond par un submit_sm_resp contenant un message_id qui sert à rapprocher les accusés de réception ultérieurs.

Les champs clés sont source_addr (l'identifiant d'expéditeur) avec ses TON/NPI, destination_addr, esm_class, registered_delivery (demande d'accusé de réception), data_coding (par exemple 0x00 pour l'alphabet par défaut ou 0x08 pour l'UCS-2), sm_length et short_message.

short_message contient jusqu'à 254 octets. Pour des données utilisateur plus longues, la spécification prévoit de mettre sm_length à zéro et de placer le contenu dans le TLV message_payload.

Si l'expéditeur construit lui-même son en-tête de concaténation, il active le bit UDHI (0x40) dans esm_class et place l'UDH au début de short_message.

Un command_status non nul dans submit_sm_resp signifie que le SMSC a rejeté le message, par exemple ESME_RINVDSTADR (destination invalide) ou ESME_RTHROTTLED (débit dépassé). L'acceptation signifie seulement que le SMSC a pris le message en charge ; l'accusé de réception indique le résultat final.

## Exemple

```
submit_sm: source_addr_ton=5 source_addr="AcmeBank" dest_addr_ton=1 destination_addr="971501234567" registered_delivery=1 data_coding=0x00 short_message="Votre code est 482913"
```

## Sources

- [SMPP Protocol Specification v3.4 (Issue 1.2) — SMPP.org](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)