Was ist SMPP? Das Sitzungsprotokoll für SMS
SMPP ohne Fachjargon erklärt: Binds, Fenster, PDUs und der Weg der Zustellberichte – und warum die Form der Sitzung bei hohem Volumen zählt.
SMPP ist das Protokoll, mit dem eine Plattform über eine dauerhafte Sitzung Kurznachrichten mit einem Message-Center austauscht. Ein Bind legt die Richtung fest, die Sitzung trägt ein Durchsatzfenster, und Zustellberichte kommen als PDUs zurück. Es ist keine API nach dem Muster Anfrage und Antwort.
Eckdaten
- SMPP ist eine dauerhafte Sitzung mit einer festgelegten Bind-Richtung.
- Ein Bind trägt eine Durchsatzzuteilung und ein Fenster laufender Anfragen.
- Eine PDU hat einen 16-Byte-Header und einen befehlsspezifischen Body.
- Zustellberichte kommen asynchron über die Sitzung an; ordnen Sie sie über die Message-ID zu.
Auf dieser Seite
Eine Sitzung, kein Aufruf
SMPP hält eine Verbindung zwischen Ihrer Plattform und einem Message-Center offen. Die Plattform authentifiziert sich einmal, legt fest, was sie tun will, und sendet dann über dieselbe Sitzung Nachrichten und empfängt Ereignisse. Das Message-Center wartet nicht auf eine neue Anfrage, um einen Zustellbericht oder eine eingehende Nachricht zu senden; es schickt eine PDU, sobald es etwas zu melden hat.
Diese Form passt zu einem gleichmäßigen Strom. Der Aufwand pro Nachricht ist gering, weil der Sitzungszustand bereits besteht und der Kanal für Zustellberichte bereits offen ist. Es bedeutet aber auch, dass Ihr Client einen Zustand verwaltet, den ein HTTP-Client nicht hat: den Bind-Status, das Fenster laufender Anfragen, das Keep-Alive-Timing und das Verhalten beim Wiederverbinden.
Binds legen eine Richtung fest
Ein Bind ist die authentifizierte Sitzung plus eine Richtung. Ein Transmitter-Bind sendet Nachrichten. Ein Receiver-Bind empfängt vom Mobilgerät gesendete Nachrichten (MO) und Zustellberichte. Ein Transceiver-Bind erledigt beides über eine Sitzung. Der Anbieter vergibt Zugangsdaten für jeden Bind und kann begrenzen, wie viele Binds Sie öffnen dürfen.
Skalieren Sie durch zusätzliche Binds, nicht indem Sie einen Bind über seine Zuteilung hinaus belasten. Ein Bind trägt eine Durchsatzzuteilung und ein Fenster laufender Anfragen. Braucht Ihre Spitzenlast mehr, fragen Sie nach einem weiteren Bind und verteilen Sie den Verkehr. Ein einzelner Bind, der über sein Fenster hinaus betrieben wird, erzeugt Drosselung, Timeouts und Wiederholungen, die wie ein Netzfehler aussehen, aber im Client beginnen.
Bind, Submit, Zustellbericht
- Anwendung (ESME)
- bind_transceiver Sitzung öffnen
- SMSC
- submit_sm_resp Zur Zustellung angenommen
- Zustellbestätigung
Textbeschreibung
Die Anwendung öffnet einen Bind, und das Message-Center antwortet. Die Anwendung sendet eine Kurznachricht mit submit_sm und erhält submit_sm_resp mit einer Message-ID. Später sendet das Message-Center eine deliver_sm-PDU, die den Zustellbericht enthält. Die Anwendung bestätigt sie mit deliver_sm_resp. Ein Unbind schließt die Sitzung, wenn die Arbeit erledigt ist.
Das Fenster ist die Vereinbarung
Das Fenster ist die Zahl der Anfragen, die Ihr Client offen haben darf, bevor er auf Antworten wartet. Es ist keine Empfehlung. Senden Sie mehr, als das Fenster zulässt, drosselt Sie das Message-Center; wiederholen Sie weiter mit derselben Rate, wächst die Warteschlange. Lesen Sie den Antwortcode jedes Submits, verlangsamen Sie bei Drosselung und lassen Sie das Fenster leerlaufen, bevor der nächste Schub kommt.
Keep-Alive-Verkehr hält die Sitzung offen. Ein Client, der nie enquire_link sendet, kann auf einer toten Verbindung sitzen, bis der erste Submit fehlschlägt. Ein Client, der sich nach jedem Abbruch sofort neu verbindet, kann den Anbieter überlasten. Nutzen Sie ein Backoff, begrenzen Sie die Rate der Wiederverbindungen und lösen Sie einen Alarm aus, wenn der Bind länger ausgefallen ist, als Ihr Verkehr verkraftet.
Eine PDU, Feld für Feld
- command_length
- 53
- command_id
- 0x00000004
- command_status
- 0x00000000
- sequence_number
- 1
- service_type
- source_addr_ton
- 1
- source_addr_npi
- 1
- source_addr
- 12345
- dest_addr_ton
- 1
- dest_addr_npi
- 1
- destination_addr
- 15551234567
- esm_class
- 0x00
- protocol_id
- 0x00
- priority_flag
- 0
- schedule_delivery_time
- validity_period
- registered_delivery
- 0x01
- replace_if_present_flag
- 0x00
- data_coding
- 0x00
- sm_default_msg_id
- 0x00
- sm_length
- 4
- short_message
- 54657374
- Text
- Test
Textbeschreibung
Jede PDU beginnt mit einer Befehlslänge von vier Byte, einer Befehls-ID von vier Byte, einem Befehlsstatus von vier Byte und einer Sequenznummer von vier Byte. Danach folgt der Body. Bei submit_sm enthält er Quell- und Zieladresse, die Kurznachricht, die Datenkodierung und das Flag für registered delivery. Optionale Parameter werden als Tag-Length-Value-Felder übertragen.
Ein Tag im Leben einer Nachricht
Der Client öffnet einen Transceiver-Bind und liest die Bind-Antwort. Er sendet eine Nachricht und speichert die Message-ID aus der Antwort. Das Message-Center leitet die Nachricht an das Zielnetz weiter. Minuten später kommt eine deliver_sm-PDU mit dem Zustellbericht an: die ursprüngliche Message-ID, ein Status und oft ein Netzcode. Der Client bestätigt den Zustellbericht und gleicht den Status mit seinem eigenen Datensatz ab.
Jeder Schritt hat ein eigenes Fehlerbild. Ein Bind kann wegen falscher Zugangsdaten oder einer falschen Schnittstellenversion abgelehnt werden. Ein Submit kann gedrosselt oder abgelehnt werden oder angenommen werden und dann im Zustellbericht scheitern. Ein Zustellbericht kann ankommen, nachdem der Code abgelaufen ist. Gestalten Sie den Client so, dass er die Message-ID speichert, einen verspäteten Zustellbericht annimmt und den eigenen Zustand der Anwendung als maßgebliche Quelle dafür behält, was der Nutzer getan hat.
Dekodieren Sie einen Zustellbericht, bevor Sie eine Route untersuchen
Fügen Sie einen Zustellbericht in den SMPP- und DLR-Decoder ein und lesen Sie die Felder. Prüfen Sie die Message-ID, den Status, das Abschlussdatum und den Fehlercode. Lautet der Status nicht DELIVRD, kann der Fehlercode, gelesen anhand der Codetabelle des Anbieters, darauf hinweisen, ob die Nummer, das Endgerät oder das Netz die Nachricht abgelehnt hat. Tun Sie das, bevor Sie den Anbieter bitten, die Route zu ändern.
Zustellberichte und Fehlersuche
Ein Zustellbericht ist asynchron. Er kommt über die Sitzung als deliver_sm-PDU an, und sein Format hängt vom Message-Center ab. Neuere Implementierungen übertragen den Status in einem message_state-Feld im Tag-Length-Value-Format. Ältere legen einen Textbericht in das Feld short_message, mit Schlüssel-Wert-Paaren wie id, stat und err. Werten Sie beide Formen aus, statt von einer auszugehen.
Ordnen Sie über die Message-ID zu, nicht über die Reihenfolge des Eingangs. Zwei Nachrichten, die im Abstand von einer Sekunde gesendet wurden, können in umgekehrter Reihenfolge zurückkommen, und eine Wiederholung kann ein Duplikat erzeugen. Speichern Sie die ID beim Submit, aktualisieren Sie den Datensatz, wenn der Zustellbericht ankommt, und ignorieren Sie einen zweiten Zustellbericht für dieselbe ID, sofern sein Status nicht neuer ist. Der Verbindungsleitfaden macht daraus einen Betriebsablauf.
Prüfen Sie Ihr Wissen
-
Warum hilft ein zweiter Bind mehr als eine höhere Wiederholungsrate?
Ein Bind trägt ein Fenster. Ein zusätzlicher Bind schafft Kapazität; Wiederholungen gegen ein volles Fenster erzeugen Warteschlange und Verzögerung.
-
Woher kommt die Message-ID?
Das Message-Center gibt sie in submit_sm_resp zurück. Speichern Sie sie und ordnen Sie den späteren Zustellbericht über diese ID zu.
-
Was beweist ein Zustellbericht mit dem Status zugestellt?
Dass das Netz die Nachricht angenommen und an den Übertragungsweg zum Endgerät zugestellt hat. Er beweist nicht, dass ein Mensch sie gelesen hat.
Antworten werden auf Wunsch angezeigt. Nichts wird bewertet, gespeichert oder gesendet.
FAQ
Brauchen wir SMPP für den Start?
Was ist ein Bind?
Was ist eine PDU?
Können wir SMPP über das öffentliche Internet nutzen?
Wie werden lange Nachrichten behandelt?
Verwandte Inhalte
- Anbindung über SMPP und HTTP
Bringen Sie eine Testroute in die Produktion, ohne Binds, Fenster oder Zustellberichte zu stören: Bind, Durchsatz, Keep-Alive, Kodierung, Callbacks und Fehlerbehandlung.
- Vorlagenpaket für RFQ und RFP
Feldlisten für Anfragen zu SMS-Großhandel, eSIM und Daten, IoT und China-Konnektivität sowie die Online-Checkliste, die als Angebotsanfrage gesendet wird.
- Musterbericht zum Routentest
Ein anonymisiertes, statisches Muster eines Routentestberichts: was ein Routentest prüft, wie Fehler zu lesen sind und was eine Routenprüfung auslöst.
Verwandte Produkte
In die Praxis umsetzen
Nennen Sie uns den Verkehr, das Ziel und die benötigte Messung; wir antworten mit dem nächsten Schritt.