SMPP-Integrations-Checkliste

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.

• 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.

• 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.

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.

• 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.

• 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.

• 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.