# SMPP-Integrations-Checkliste

- Kanonische URL: https://www.broadnet.me/de/guides/smpp-integration-checklist
- Sprache: de
- Herausgeber: BroadNet (https://www.broadnet.me)
- Markdown-Fassung der Seite, aus der ausgelieferten Seite erzeugt.

Protokolle & APIs Kostenlose Checkliste

Eine Feld-Checkliste für die Integration von SMPP v3.4/v5.0: Bind-Typen, optionale TLVs, Verarbeitung von Zustellbestätigungen, enquire_link-Keepalives, Drosselung, TLS und ein Testplan vor dem Produktivbetrieb.

33 Prüfpunkte 5 Min. Lesezeit Aktualisiert am 14. Juli 2026

PDF per E-Mail erhalten

Für Entwickler und Messaging-Ingenieure, die einen neuen SMPP-Bind einrichten.

Inhalt

1. 01Sitzungs- & Bind-Einrichtung
2. 02Nachrichten übermitteln (submit_sm)
3. 03Optionale Parameter (TLVs), die sich zu setzen lohnen
4. 04Verarbeitung von Zustellbestätigungen (DLR)
5. 05Keepalive & Flusskontrolle
6. 06Transportsicherheit (TLS)
7. 07Testplan vor dem Produktivbetrieb

[Alle Leitfäden ansehen](https://www.broadnet.me/de/guides)

Kurz gesagt

SMPP (Short Message Peer-to-Peer) ist das binäre Protokoll, das die meisten Aggregatoren und Betreiber für hochvolumiges A2P-Messaging bereitstellen. Bei einer sauberen Integration geht es weniger um das Schreiben von PDUs als darum, die betrieblichen Details richtig zu machen: den korrekten Bind-Modus wählen, Fenster- und Drosselgrenzen einhalten, Zustellbestätigungen zuverlässig auswerten, die Sitzung aktiv halten und den Transport absichern. Arbeiten Sie von oben nach unten — jede Gruppe ist ein Prüfpunkt, den Sie abzeichnen können, bevor Sie einen Bind in den Produktivbetrieb überführen.

Die Checkliste

## Arbeiten Sie sie Punkt für Punkt durch und haken Sie ab.

Diagramm Eine SMPP-Sitzung zwischen Ihrer Plattform und BroadNet

Ihre Plattform (ESME)

BroadNet SMSC

Eine dauerhafte TCP/TLS-Verbindung

1. `bind_transceiver` Sitzung öffnen und authentifizieren
2. `bind_transceiver_resp` Sitzung akzeptiert
3. `submit_sm` Nachricht senden
4. `submit_sm_resp` Akzeptiert, Nachrichten-ID zurückgegeben
5. `deliver_sm` Zustellungsbericht oder eingehende Nachricht
6. `deliver_sm_resp` Bestätigt
7. `enquire_link` Keepalive im Leerlauf

01

### Sitzungs- & Bind-Einrichtung

Wählen Sie den richtigen Bind-Modus für Ihre Verkehrsrichtung und bestätigen Sie die ausgehandelte Protokollversion, bevor Sie auch nur eine Nachricht senden.

- Bestätigen Sie die SMPP-Version — v3.4 für die meisten Routen, v5.0 dort, wo der Anbieter Überlastzustands-Signalisierung und erweiterte TLVs unterstützt. v5.0 ist abwärtskompatibel; gehen Sie nicht davon aus, dass Funktionen verfügbar sind, bis die bind_resp dies bestätigt.
- Wählen Sie den richtigen Bind-Typ je Sitzung. Transmitter (nur MT), Receiver (nur DLR/MO) oder Transceiver (beides in einer Sitzung). Bevorzugen Sie Transceiver, um die Verbindungsanzahl zu halbieren, wo der Anbieter dies zulässt.
- Setzen Sie system_id, password, system_type und address_range genau wie bereitgestellt. Ein falscher address_range blockiert bei Receiver-Binds stillschweigend das MO-/DLR-Routing.
- Vereinbaren Sie die Anzahl gleichzeitiger Binds und die TPS je Bind schriftlich mit dem Anbieter. Mehr Binds zu öffnen als bereitgestellt, ist die häufigste Ursache für ein gedrosseltes oder gesperrtes Konto.
- Behandeln Sie bind_resp-Statuscodes explizit — wiederholen Sie bei ESME_RALYBND und fahren Sie bei ESME_RBINDFAIL zurück. Nie einen fehlgeschlagenen Bind in einer Schleife sofort wiederholen; nutzen Sie exponentiellen Backoff mit Jitter.

02

### Nachrichten übermitteln (submit_sm)

- Setzen Sie source_addr_ton / source_addr_npi und dest_addr_ton / dest_addr_npi korrekt für alphanumerische vs. numerische Sender-IDs. Alphanumerischer Absender → TON 5 (alphanumerisch); internationale MSISDN → TON 1, NPI 1.
- Wählen Sie die richtige data_coding: GSM 7-Bit (0), 8-Bit (4) oder UCS-2 (8) für Unicode. Das Mischen von Kodierungen ohne Setzen von data_coding verursacht Zeichensalat und fehlerhafte Segmentierung.
- Implementieren Sie die Verkettung langer Nachrichten über UDH oder die optionalen SAR-TLVs (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum). Wählen Sie eine Methode und bleiben Sie konsistent; manche Routen lehnen UDH ab, andere SAR-TLVs.
- Fordern Sie Zustellbestätigungen mit registered_delivery = 1 nur dort an, wo Sie sie auswerten. DLRs anzufordern, die Sie nicht auswerten, verschwendet Durchsatz und kann anbieterseitige Warnungen auslösen.
- Beachten Sie die Semantik von validity_period und schedule_delivery_time für Ihren Anwendungsfall (OTP = kurze Gültigkeit). Kurzlebige OTPs sollten eine enge validity_period tragen, damit veraltete Nachrichten nicht verspätet zugestellt werden.

03

### Optionale Parameter (TLVs), die sich zu setzen lohnen

- message_payload — für Nutzlasten, die die Grenze des short_message-Felds überschreiten. Befüllen Sie nicht sowohl short_message als auch message_payload; Anbieter lehnen das ab.
- sar_*-TLVs — standardbasierte Verkettung ohne UDH-Bytes im Body.
- dest_addr_subunit / source_addr_subunit — wo die Route dies für das Handset-Routing erfordert.
- Tragen Sie vom Client gelieferte Metadaten nur in anbieterseitig genehmigten TLVs. Benutzerdefinierte TLVs außerhalb des vereinbarten Bereichs werden häufig entfernt oder verursachen nachgelagert Parsing-Fehler.

04

### Verarbeitung von Zustellbestätigungen (DLR)

Zustellbestätigungen treffen als deliver_sm-PDUs ein und sind das Rückgrat Ihres Abgleichs und Ihrer Qualitätsberichterstattung.

- Werten Sie die Bestätigung aus dem short_message-Feld der deliver_sm aus: id, sub, dlvrd, submit date, done date, stat, err. Das Feld `stat` (DELIVRD, UNDELIV, EXPIRED, REJECTD usw.) ist Ihr Endstatus.
- Ordnen Sie DLRs Ihrer Übermittlung anhand des message_id-Formats des Anbieters zu, nicht allein anhand des Bestätigungstexts. message_id kann bei submit_resp hexadezimal, im DLR aber dezimal zurückgegeben werden — beide normalisieren.
- Behandeln Sie Zwischenbestätigungen (nicht final) getrennt von Endzuständen. Bit 0x04 von esm_class markiert eine Zustellbestätigung; nur finale `stat`-Werte sollten eine Nachricht abschließen.
- Antworten Sie stets mit einem deliver_sm_resp — ein unbestätigter DLR wird erneut gesendet und kann das Fenster blockieren. Antworten Sie umgehend, auch wenn die nachgelagerte Verarbeitung asynchron erfolgt.
- Bilden Sie Betreiberfehlercodes auf eine normalisierte Taxonomie ab (Teilnehmer nicht erreichbar, Handset belegt, als Spam blockiert, ungültige Nummer). Rohe Fehlercodes variieren je Route; eine normalisierte Taxonomie macht die Qualität routenübergreifend vergleichbar.

05

### Keepalive & Flusskontrolle

- Senden Sie enquire_link auf einem Leerlauf-Timer (üblicherweise 30–60 s) und behandeln Sie ein ausbleibendes enquire_link_resp als tote Sitzung. Dies ist der einzige zuverlässige Weg, eine halb offene TCP-Verbindung zu erkennen.
- Implementieren Sie das SMPP-Fenster: Begrenzen Sie ausstehende, unbestätigte PDUs und pausieren Sie Übermittlungen, wenn das Fenster voll ist. Blindes Absenden von submit_sm über das Fenster hinaus löst ESME_RTHROTTLED aus.
- Fahren Sie bei ESME_RTHROTTLED (0x58) zurück, statt sofort erneut zu versuchen. Fügen Sie Jitter hinzu, damit sich Reconnect-Wellen nicht über mehrere Worker synchronisieren.
- Beachten Sie unbind / unbind_resp für ein geordnetes Herunterfahren; verbinden Sie sich bei unerwarteten Verbindungsabbrüchen mit Backoff neu.

06

### Transportsicherheit (TLS)

- Verwenden Sie SMPP über TLS, wo der Anbieter dies anbietet; deaktivieren Sie Klartext-Binds im Produktivbetrieb. SMPP hat keine native Verschlüsselung — TLS ist die Kontrolle auf Transportebene.
- Pinnen oder validieren Sie die Zertifikatskette des Servers und erzwingen Sie TLS 1.2+. Lehnen Sie abgelaufene oder selbstsignierte Zertifikate ab; deaktivieren Sie die Verifizierung nicht, „damit es funktioniert“.
- Beschränken Sie Binds auf zugelassene (Allow-List-)Quell-IPs auf beiden Seiten. IP-Allow-Listing ist eine gängige Betreiberkontrolle und ein schneller Weg, um Credential-Lecks einzudämmen.
- Rotieren Sie SMPP-Zugangsdaten nach Zeitplan und speichern Sie sie in einem Secret-Manager, niemals im Code.

07

### Testplan vor dem Produktivbetrieb

- Senden Sie an eine echte Test-MSISDN auf jeder Zielroute und bestätigen Sie den Empfang auf dem Mobiltelefon durchgehend.
- Überprüfen Sie den DLR-Rundlauf für die Ergebnisse zugestellt, nicht zugestellt, abgelaufen und abgelehnt.
- Testen Sie lange (mehrsegmentige) Nachrichten und Unicode-Inhalte (UCS-2) auf jeder Route.
- Führen Sie einen Lasttest bei Ihrer bereitgestellten TPS durch und bestätigen Sie ein geordnetes Verhalten an der Fenster-/Drosselgrenze.
- Simulieren Sie einen Verbindungsabbruch mitten im Fenster und bestätigen Sie einen sauberen Reconnect ohne doppelte Übermittlungen. Idempotenz bei Wiederholungen verhindert doppelte Abrechnung und doppelte Zustellung auf dem Handset.
- Bestätigen Sie die Überwachung: Bind-Status, Fensterauslastung, Submit-/DLR-Latenz und Fehlercode-Raten lösen alle Alarme aus.

Quellen

- [SMPP v3.4-Spezifikation](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [SMPP v5.0-Spezifikation](https://smpp.org/SMPP_v5.pdf)
- [3GPP TS 23.040 — Technische Realisierung von SMS](https://www.3gpp.org/dynareport/23040.htm)

In diesem Leitfaden zitierte Standards und Regulierungsquellen. BroadNet ist assoziiertes Mitglied der GSMA und Mitglied des MEF und betreibt seit 2003 Messaging in Carrier-Qualität.

Related

- [SMPP-Fehlercode-Nachschlagewerk (kostenloses Tool)](https://www.broadnet.me/de/tools/smpp-error-codes)
- [DLR-Decoder (kostenloses Tool)](https://www.broadnet.me/de/tools/dlr-decoder)
- [Was ist SMPP?](https://www.broadnet.me/de/answers/what-is-smpp)
- [SMPP-Protokoll — Tiefenanalyse](https://www.broadnet.me/de/answers/smpp-protocol)
- [Entwicklerdokumentation](https://www.broadnet.me/de/developers)

Kopie behalten

## Lieber als PDF zum Teilen?

Schicken Sie sie an Ihr Postfach, um sie im Team zu teilen – kein Spam, eine einzige E-Mail.

PDF per E-Mail erhalten

PDF anfordern

## „SMPP-Integrations-Checkliste“ per E-Mail erhalten.

Wir senden Ihnen ein sauberes, druckfertiges PDF dieser Checkliste, das Sie im Team teilen oder für Ihre Ausschreibung (RFP) aufbewahren können. Ein Messaging-Ingenieur meldet sich nur, wenn Sie es wünschen — kein Vertriebs-Spam.

- Druckfertiges PDF, eine Seite pro Abschnitt
- Alle Inhalte dieser Seite, zum Teilen aufbereitet
- Optional: ein Gespräch mit einem BroadNet-Ingenieur

Sie möchten Ihre E-Mail-Adresse nicht angeben? Nutzen Sie Drucken / als PDF speichern oben — die vollständige Checkliste steht auf dieser Seite.

Direkter Draht · Antwort innerhalb eines Werktags

## „SMPP-Integrations-Checkliste“ zusenden

Sagen Sie uns, wohin wir es senden sollen. Wir schicken Ihnen das PDF per E-Mail und melden uns nur, wenn Sie es wünschen.

1. 1 Wer
2. 2 Bedarf
3. 3 Kontext