# SMPP deliver_sm: messaggi MO e ricevute

> deliver_sm (command_id 0x00000005) viene inviato dall'SMSC all'ESME per consegnare un messaggio mobile-originated (MO) o una ricevuta di consegna (DLR). Il suo body ricalca quello di submit_sm. Il campo esm_class distingue i due casi: il bit 0x04 contrassegna una ricevuta di consegna. L'ESME deve sempre rispondere con deliver_sm_resp.

- URL canonico: https://www.broadnet.me/it/reference/smpp-deliver-sm
- Lingua: it
- Ultimo aggiornamento: 2026-07-18
- Editore: BroadNet (https://www.broadnet.me)

deliver_sm trasporta due cose dall'SMSC all'ESME: messaggi mobile-originated (MO) e ricevute di consegna. Come distinguerli con esm_class e perché occorre sempre rispondere con deliver_sm_resp.

## Una PDU, due compiti

deliver_sm è la controparte da SMSC a ESME di submit_sm e ne condivide il layout del body. Trasporta un messaggio MO in ingresso (un abbonato che scrive al vostro numero lungo o short code) oppure una ricevuta di consegna che riporta l'esito di un messaggio inviato in precedenza. Il vostro bind receiver o transceiver gestisce entrambi; si distingue in base a esm_class per instradarli correttamente.

## Distinguere MO da DLR con esm_class

I bit di tipo-messaggio di esm_class identificano il payload. Un normale messaggio MO ha i bit di tipo-messaggio di esm_class azzerati. Una ricevuta di consegna imposta il bit 0x04. Quando 0x04 è impostato, short_message contiene il testo della ricevuta secondo l'Appendice B (id, stat, err…) e il TLV receipted_message_id trasporta di norma il message_id originale. Non interpretate il testo della ricevuta come contenuto utente.

*Valori del tipo-messaggio di esm_class su deliver_sm*

| esm_class (bit del tipo di messaggio) | Payload |
|---|---|
| 0x00 | Messaggio normale originato da dispositivo mobile (MO) |
| 0x04 | Ricevuta di consegna SMSC (DLR) |
| 0x08 | Conferma di consegna SME |
| 0x10 | Conferma manuale/dell'utente da parte dell'SME |
| 0x20 | Interruzione della conversazione (CDMA coreano) |
| 0x40 | Notifica di consegna intermedia |

## Rispondete sempre con deliver_sm_resp

Per ogni deliver_sm l'ESME deve restituire un deliver_sm_resp (0x80000005) con sequence_number corrispondente ed ESME_ROK. Se non date riscontro, l'SMSC considera fallita la consegna, la reinvia e — poiché le PDU non riscontrate contano nella finestra — può bloccare l'intera sessione. Riscontrate prontamente ed eseguite l'elaborazione pesante in modo asincrono.

*MO e DLR entrambi riscontrati*

```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 come alternativa

data_sm (0x00000103) è un'operazione più leggera e snella che può trasportare messaggi MO e ricevute tramite TLV (in particolare message_payload) invece del campo fisso short_message. Alcune reti la preferiscono per il traffico interattivo o in stile WAP. Il supporto è opzionale e specifico del provider — verificate prima di farci affidamento.

## Domande frequenti

### Come distinguo una ricevuta di consegna da un messaggio MO in ingresso?

Controllate esm_class sulla deliver_sm. Se il bit di tipo-messaggio 0x04 è impostato, si tratta di una ricevuta di consegna e short_message contiene il testo secondo l'Appendice B. Se quei bit sono azzerati, è un normale messaggio mobile-originated da un abbonato.

### Cosa succede se non invio deliver_sm_resp?

L'SMSC presume che la consegna sia fallita e reinvia la deliver_sm. Le PDU non riscontrate consumano inoltre la finestra, quindi la mancata risposta può bloccare la sessione e produrre un'elaborazione duplicata di MO/DLR.

### deliver_sm ha gli stessi campi di submit_sm?

Sì — deliver_sm riutilizza il layout del body di submit_sm (service_type, indirizzamento TON/NPI, esm_class, data_coding, short_message e così via). Cambiano solo la direzione e l'interpretazione del payload.

### Un singolo messaggio MO può essere concatenato?

Sì. I messaggi lunghi in ingresso arrivano come più PDU deliver_sm con un header di concatenazione UDH (bit UDHI 0x40 di esm_class impostato) o con TLV SAR. Riassemblateli per numero di riferimento e sequenza come fareste con i segmenti in uscita.

## Fonti

- [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)

## Correlati

- [Ricevute di consegna SMPP (formato DLR)](https://www.broadnet.me/it/reference/smpp-delivery-receipts-dlr)
- [Riferimento submit_sm di SMPP](https://www.broadnet.me/it/reference/smpp-submit-sm)
- [Decoder DLR (strumento gratuito)](https://www.broadnet.me/it/tools/dlr-decoder)
- [Parametri opzionali TLV di SMPP](https://www.broadnet.me/it/reference/smpp-tlv-parameters)
- [SMS bidirezionale](https://www.broadnet.me/it/products/sms-api)