SMPP -Sitzungssimulator.

Wie eine SMPP Sitzung tatsächlich abläuft

1. 1 · Binden. Ihre Anwendung öffnet eine TCP-Verbindung zum SMSC und sendet bind_transceiver mit einer system_id und einem Passwort. Solange das SMSC nicht mit command_status 0 antwortet, werden keine weiteren Befehle akzeptiert.
2. 2 · Absenden. Jede Nachricht ist eine submit_sm PDU. Die Antwort liefert eine message_id – das ist eine Bestätigung, keine Zustellungsbestätigung.
3. 3 · Quittung. Wenn Sie eine solche angefordert haben, sendet das SMSC später eine deliver_sm mit esm_class 0x04 und einem Empfangsbestätigungstext, der auf diese message_id verweist.
4. 4 · Am Leben bleiben. Der alle 30–60 Sekunden enquire_link signalisiert, dass die Verbindung noch nutzbar ist. Wird dieser Aufruf verpasst, trennt das SMSC die Verbindung.
5. 5 · Entfesseln. Schließen Sie das Gespräch höflich, damit der Operator dies nicht als anormale Verbindungsunterbrechung wertet.

Fragen, die Ingenieure stellen

Sendet dieser Simulator echte SMS ?

Nein. Nichts auf dieser Seite öffnet eine Verbindung oder sendet eine Nachricht. Jede PDU und jede SMSC Antwort wird in Ihrem Browser anhand Ihrer Eingaben berechnet, sodass dieselben Eingaben immer dasselbe Protokoll erzeugen. Es handelt sich um ein Lernwerkzeug für das Protokoll, nicht um ein Sendewerkzeug.

Was ist ein Bind in SMPP ?

Ein Bind ist der Session-Handshake zwischen einem ESME (Ihrer Anwendung) und dem SMSC (dem Message Center des Betreibers). `bind_transmitter` kann nur senden, `bind_receiver` nur empfangen und `bind_transceiver` beides über eine einzige Verbindung – was die meisten Integrationen nutzen. Über die Session werden keine anderen Daten akzeptiert, bis der Bind erfolgreich war.

Was bewirkt registered_delivery?

Durch Setzen von registered_delivery auf 1 wird das SMSC aufgefordert, das Endergebnis zu bestätigen. Diese Bestätigung trifft später als separate deliver_sm PDU mit der esm_class 0x04 – der Zustellbestätigung – ein, die die in submit_sm_resp angegebene message_id referenziert. Ohne diese Bestätigung erfahren Sie lediglich, dass das SMSC die Nachricht akzeptiert hat, nicht aber, dass ein Endgerät sie empfangen hat.

Warum wird meine Nachricht in mehrere Segmente aufgeteilt?

Eine einzelne SMS PDU enthält 160 Zeichen im GSM-7-Alphabet oder 70 in UCS-2. Längere Texte werden verkettet: Jeder Teil gibt 6 Oktette an einen Benutzerdaten-Header ab, damit das Mobiltelefon die Teile wieder zusammensetzen kann. Dadurch verbleiben 153 bzw. 67 Zeichen pro Segment. Ein arabisches Zeichen oder ein Emoji erzwingt die Übertragung der gesamten Nachricht in UCS-2, weshalb eine 100 Zeichen lange arabische Nachricht zwei Segmente belegt.

Worin besteht der Unterschied zwischen submit_sm_resp und einem Zustellbericht?

submit_sm_resp ist synchron und bedeutet lediglich, dass das SMSC die PDU akzeptiert und ihr eine message_id zugewiesen hat. Die Zustellbestätigung trifft asynchron ein, oft Sekunden oder Minuten später, und meldet das tatsächliche Ergebnis – DELIVRD, UNDELIV, EXPIRED, REJECTD. submit_sm_resp als Zustellnachweis zu behandeln, ist der häufigste Fehler bei der ersten SMPP Integration.

Was ist ein SMPP -Fenster und warum begrenzt es meinen Durchsatz?

Das Zeitfenster gibt an, wie viele PDU Sie zu einem beliebigen Zeitpunkt über eine Bind-Verbindung gesendet, aber noch nicht bestätigt haben dürfen. Da SMPP asynchron arbeitet, wird nicht auf jede submit_sm_resp gewartet, bevor die nächste gesendet wird – das Zeitfenster begrenzt jedoch, wie weit im Voraus Sie vorpreschen können. Bei einem Standardwert von 1 reduziert sich die Bind-Verbindung auf Anfrage/Antwort, und Ihr Durchsatz sinkt auf eine Nachricht pro Roundtrip, unabhängig von der mit dem Betreiber vereinbarten Rate.