BroadNet
SMPPOperationen

SMPP deliver_sm: MO-Nachrichten und Berichte

Aktualisiert am 2 Min. LesezeitStandardsbasiert
Direkte Antwort

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.

DiagrammEine SMPP-Sitzung zwischen Ihrer Plattform und BroadNet
Ihre Plattform (ESME)
BroadNet SMSC
Eine dauerhafte TCP/TLS-Verbindung
  1. bind_transceiverSitzung öffnen und authentifizieren
  2. bind_transceiver_respSitzung akzeptiert
  3. submit_smNachricht senden
  4. submit_sm_respAkzeptiert, Nachrichten-ID zurückgegeben
  5. deliver_smZustellungsbericht oder eingehende Nachricht
  6. deliver_sm_respBestätigt
  7. enquire_linkKeepalive im Leerlauf
§01

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.

§02

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
0x00Normale mobil initiierte (MO) Nachricht
0x04SMSC-Zustellbestätigung (DLR)
0x08SME-Zustellbestätigung
0x10Manuelle/Benutzerbestätigung durch das SME
0x20Gesprächsabbruch (koreanisches CDMA)
0x40Zwischenbenachrichtigung zur Zustellung
§03

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ätigttext
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
§04

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äufig gestellte Fragen

Häufig gestellte 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.

Referenzen

Quellenspezifikationen

Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)

BNWird vom BroadNet -Entwicklungsteam betreut.·Messaging in Carrier-Qualität seit 2003
Hänge es an den Draht

Entwicklung mit echtem SMPP Binding und REST-API.

Fordern Sie Testzugriff mit echten Testschlüsseln an: Senden Sie zunächst an Ihre eigene verifizierte Nummer und gehen Sie dann in über 200 Ländern zum Produktivbetrieb über, sobald Ihre Absenderidentität und die Routen genehmigt wurden.