# SMPP deliver_sm: MO-Nachrichten und Berichte

> deliver_sm (command_id 0x00000005) wird vom SMSC an die ESME gesendet, um entweder eine mobil-originierte (MO) Nachricht oder einen Zustellbericht (DLR) zuzustellen. Der Body entspricht dem von submit_sm. Das Feld esm_class unterscheidet die beiden: Bit 0x04 kennzeichnet einen Zustellbericht. Die ESME muss stets mit deliver_sm_resp antworten.

- Kanonische URL: https://www.broadnet.me/de/reference/smpp-deliver-sm
- Sprache: de
- Zuletzt aktualisiert: 2026-07-18
- Herausgeber: BroadNet (https://www.broadnet.me)

deliver_sm trägt zwei Dinge vom SMSC zur ESME: mobil-originierte (MO) Nachrichten und Zustellberichte. Wie man sie über esm_class unterscheidet und warum man stets mit deliver_sm_resp antworten muss.

## Eine PDU, zwei Aufgaben

deliver_sm ist das Gegenstück zu submit_sm in Richtung SMSC-zu-ESME und teilt dasselbe Body-Layout. Es trägt entweder eine eingehende MO-Nachricht (ein Teilnehmer, der Ihre Langnummer oder Ihren Short Code anschreibt) oder einen Zustellbericht, der über das Schicksal einer zuvor eingereichten Nachricht informiert. Ihr Receiver- oder Transceiver-Bind verarbeitet beides; Sie verzweigen anhand von esm_class, um sie korrekt zu routen.

## MO von DLR mit esm_class unterscheiden

Die Nachrichtentyp-Bits von esm_class identifizieren die Nutzlast. Eine reine MO-Nachricht hat die Nachrichtentyp-Bits von esm_class gelöscht. Ein Zustellbericht setzt Bit 0x04. Ist 0x04 gesetzt, enthält short_message den Berichtstext gemäß Appendix B (id, stat, err …), und das receipted_message_id-TLV trägt üblicherweise die ursprüngliche message_id. Parsen Sie den Berichtstext nicht als Benutzerinhalt.

*esm_class-Nachrichtentyp-Werte bei deliver_sm*

| esm_class (Message-Type-Bits) | Payload |
|---|---|
| 0x00 | Normale mobil initiierte (MO) Nachricht |
| 0x04 | SMSC-Zustellbestätigung (DLR) |
| 0x08 | SME-Zustellbestätigung |
| 0x10 | Manuelle/Benutzerbestätigung durch das SME |
| 0x20 | Gesprächsabbruch (koreanisches CDMA) |
| 0x40 | Zwischenbenachrichtigung zur Zustellung |

## Antworten Sie stets mit deliver_sm_resp

Für jedes deliver_sm muss die ESME ein deliver_sm_resp (0x80000005) mit passender sequence_number und ESME_ROK zurückgeben. Bestätigen Sie nicht, behandelt das SMSC die Zustellung als fehlgeschlagen, sendet sie erneut und kann — weil ausstehende, unbestätigte PDUs auf das Fenster angerechnet werden — die gesamte Sitzung blockieren. Bestätigen Sie umgehend und erledigen Sie aufwendige Verarbeitung asynchron.

*MO und DLR beide bestätigt*

```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 als Alternative

data_sm (0x00000103) ist eine leichtgewichtigere, verschlankte Operation, die MO-Nachrichten und Berichte über TLVs (insbesondere message_payload) statt über das feste Feld short_message tragen kann. Manche Netze bevorzugen es für interaktiven oder WAP-artigen Verkehr. Die Unterstützung ist optional und anbieterspezifisch — bestätigen Sie diese, bevor Sie sich darauf verlassen.

## Häufige Fragen

### Wie unterscheide ich einen Zustellbericht von einer eingehenden MO-Nachricht?

Prüfen Sie esm_class im deliver_sm. Ist das Nachrichtentyp-Bit 0x04 gesetzt, handelt es sich um einen Zustellbericht, und short_message enthält den Berichtstext gemäß Appendix B. Sind diese Bits gelöscht, ist es eine normale mobil-originierte Nachricht eines Teilnehmers.

### Was passiert, wenn ich kein deliver_sm_resp sende?

Das SMSC nimmt an, die Zustellung sei fehlgeschlagen, und sendet das deliver_sm erneut. Unbestätigte PDUs verbrauchen zudem Ihr Fenster, sodass eine ausbleibende Antwort die Sitzung blockieren und eine doppelte MO/DLR-Verarbeitung verursachen kann.

### Hat deliver_sm dieselben Felder wie submit_sm?

Ja — deliver_sm verwendet das Body-Layout von submit_sm wieder (service_type, TON/NPI-Adressierung, esm_class, data_coding, short_message usw.). Nur die Richtung und die Interpretation der Nutzlast unterscheiden sich.

### Kann eine einzelne MO-Nachricht verkettet sein?

Ja. Lange eingehende Nachrichten treffen als mehrere deliver_sm-PDUs mit einem UDH-Verkettungs-Header (esm_class-UDHI-Bit 0x40 gesetzt) oder SAR-TLVs ein. Setzen Sie sie anhand von Referenznummer und Sequenz genauso wieder zusammen wie ausgehende Segmente.

## Quellen

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

## Verwandte Seiten

- [SMPP-Zustellbestätigungen (DLR-Format)](https://www.broadnet.me/de/reference/smpp-delivery-receipts-dlr)
- [SMPP submit_sm Referenz](https://www.broadnet.me/de/reference/smpp-submit-sm)
- [DLR-Decoder (kostenloses Tool)](https://www.broadnet.me/de/tools/dlr-decoder)
- [Optionale SMPP-TLV-Parameter](https://www.broadnet.me/de/reference/smpp-tlv-parameters)
- [Zwei-Wege-SMS](https://www.broadnet.me/de/products/sms-api)