SMPP-Fehlercodes in A2P-SMS: Praxisleitfaden für Wiederholungen, Korrekturen und Abschlüsse

Was eine submit_sm-Antwort bestätigt – und was nicht

Eine submit_sm_resp-Antwort bestätigt das Ergebnis einer Anfrage im SMPP-Protokoll. Das Feld command_status in der Antwort-PDU zeigt an, ob das SMSC diese SMPP-Anfrage angenommen oder abgelehnt hat, und gibt gegebenenfalls einen Fehlercode zurück.

Eine technische Annahme ist nicht gleichbedeutend mit einer Zustellung am Endgerät. Wenn command_status Erfolg anzeigt und das SMSC eine message_id zurückgibt, wurde die Nachricht von diesem System zur weiteren Verarbeitung angenommen. Dies belegt für sich allein weder, dass die Nachricht das Mobilfunknetz erreicht hat, noch dass sie auf dem Gerät zugestellt oder vom Nutzer gesehen wurde.

Die erste Betriebsregel besteht darin, die Annahme von der späteren Status-Evidenz zu trennen. Speichern Sie die vom SMSC zurückgegebene message_id zusammen mit der internen Nachrichtenkennung, dem Ziel, der verwendeten Route oder Verbindung, dem Zeitstempel und den relevanten PDU-Parametern. Diese Korrelation wird benötigt, um DLRs, query_sm, cancel_sm oder replace_sm zu interpretieren.

• submit_sm_resp mit Erfolg: Die SMPP-Anfrage wurde vom SMSC angenommen.
• submit_sm_resp mit Fehler: Die Anfrage ist in dieser Phase fehlgeschlagen und muss vor einem erneuten Versand klassifiziert werden.
• DLR oder Statusabfrage: liefern spätere Informationen, dürfen aber nicht mit einem unabhängigen Nachweis des Empfangs am Endgerät verwechselt werden.
• message_id: technische Referenz für spätere SMPP-Vorgänge und zur Ereigniskorrelation.

Die Statusschichten in SMPP: Sitzung, submit-Annahme, DLR und Empfangsnachweis

Für einen zuverlässigen Betrieb muss der Lebenszyklus schichtweise überwacht werden. Zuerst kommt die Sitzung: Transportkonnektivität und Bind-Status. Danach folgt die Annahme oder Ablehnung von submit_sm. Später kann, wenn dies über registered_delivery angefordert wurde und die Route es unterstützt, eine Zustellbestätigung über deliver_sm oder data_sm eintreffen. Schließlich muss jeder unabhängige Empfangsnachweis als separates Signal gegenüber der SMSC-Telemetrie behandelt werden.

SMPP arbeitet über einer zugrunde liegenden Verbindung, üblicherweise TCP/IP, von der das Protokoll zuverlässige Übertragung, Flusskontrolle und Behandlung von Transportfehlern erwartet. Eine Trennung, ein Timeout oder eine ausbleibende Antwort bedeuten nicht automatisch, dass das SMSC die Anfrage nicht erhalten hat. In diesem Fall besteht das Risiko einer doppelten Einreichung, wenn ohne Korrelations- und Idempotenzstrategie in der Anwendung erneut gesendet wird.

Der über query_sm abfragbare Status kann ENROUTE, DELIVERED, EXPIRED, DELETED, UNDELIVERABLE, ACCEPTED, UNKNOWN und REJECTED umfassen. Diese Status sollten unverändert gespeichert werden, zusammen mit dem Beobachtungszeitpunkt und dem Routenkontext. Ein späterer Status kann die ursprüngliche Entscheidung nach submit_sm_resp verändern.

• Sitzung: aktive Verbindung und gültiger Bind für den jeweiligen Vorgang.
• Annahme: Ergebnis von command_status in submit_sm_resp.
• Späterer Status: DLR oder query_sm, sofern verfügbar.
• Empfangsnachweis: darf nicht allein aus einer submit_sm-Annahme oder einem textlichen DLR-Format abgeleitet werden.

Warum derselbe Fehler nicht immer dieselbe Maßnahme erfordert

Die Maßnahme sollte nicht allein vom Code abhängen. Derselbe Fehler kann je nach Ziel, betroffenem Volumen, Kritikalität der Nachricht, Sitzungsstatus, Wiederholungshäufigkeit und jüngsten Konfigurationsänderungen unterschiedliche Folgen haben. Ein isoliertes ESME_RTHROTTLED erfordert eine Verringerung der Last; eine anhaltende Folge über die gesamte Verbindung hinweg verlangt eine Überprüfung der Ratensteuerung und möglicherweise eine Unterbrechung des Datenflusses.

Definieren Sie eine Entscheidungsmatrix, die vier Faktoren kombiniert: Fehlerklasse, Umfang, Kritikalität und verfügbare Evidenz. Klassifizieren Sie den Umfang als einzelne Nachricht, konkretes Ziel, Sitzung, Verbindung oder Datenverkehrsgruppe. Unterscheiden Sie Nachrichten, deren Nutzen funktional ablaufen kann, etwa ein OTP, von Nachrichten, die Verzögerungen zulassen. Verstärken Sie ein vorübergehendes Problem nicht durch parallele Wiederholungen und verwandeln Sie Datenfehler nicht in wiederholte Sendeversuche.

Die Richtlinie muss klare Grenzen enthalten. Jeder Wiederholungsversuch benötigt einen Zähler, ein Warteintervall, eine Abbruchbedingung und einen Mechanismus zur Vermeidung von Duplikaten, wenn Unsicherheit über die Netzwerkantwort besteht. Wenn keine eindeutige Antwort vorliegt, erfassen Sie den Fall als unsicher, statt ihn voreilig als abgelehnt oder zugestellt zu kennzeichnen.

• Kontrolliert erneut versuchen: nur bei vorübergehenden oder mehrdeutigen Signalen, die eine Untersuchung rechtfertigen.
• Korrigieren und erneut senden: wenn der Code auf falsche Parameter, Adressierung, Zugangsdaten oder einen falschen Bind-Status hinweist.
• Pausieren und eskalieren: wenn der Fehler eine Sitzung, Warteschlange, Kapazität oder ein relevantes Volumen betrifft.
• Abschließen: wenn das Problem dauerhaft ist, die Nachricht ihren Nutzen verliert oder die in der Richtlinie definierten Grenzen erreicht sind.

Operative Taxonomie von SMPP-Codes und -Fehlern

Die praktische Klassifizierung sollte zwei Ebenen beibehalten: die genaue Semantik von command_status und eine interne operative Kategorie. Die erste Ebene verhindert Informationsverlust. Die zweite erleichtert Automatisierung, Warnmeldungen und konsistente Entscheidungen.

Eine nützliche Taxonomie trennt Fehler bei der PDU-Erstellung, Sitzungs- und Authentifizierungsfehler, Kapazitäts- oder Begrenzungsfehler, Adressierungsfehler, Inhalts- oder Parameterfehler sowie System- oder Anbieterfehler. Nicht alle Standardcodes klären die Ursache allein; ESME_RSYSERR ist beispielsweise lediglich als Systemfehler definiert und spezifiziert weder Dauer, Ursache noch Wiederholbarkeit.

Ersetzen Sie den ursprünglichen Wert nicht durch eine vereinfachte Bezeichnung. Protokollieren Sie den hexadezimalen Code, den SMPP-Namen, falls vorhanden, die betroffene PDU, die sequence_number, command_status, message_id sofern verfügbar, das entfernte System, nicht sensible Adressierungsparameter und Sitzungsereignisse in unmittelbarer Nähe des Fehlers.

• PDU-Erstellung: Serialisierung, Längen, Felder und Befehl korrigieren.
• Sitzung und Authentifizierung: Bind und Berechtigungen wiederherstellen, bevor Datenverkehr gesendet wird.
• Kapazität: verlangsamen, Wartezeit anwenden und Wiederherstellung überwachen.
• Adressierung: Daten normalisieren und die Kombination aus Adresse, TON und NPI validieren.
• System oder Anbieter: Evidenz bewahren, Wiederholungen begrenzen und eine dokumentierte Definition anfordern, wenn die Semantik nicht standardisiert ist.

Sitzungs- und Bind-Fehler: Zugangsdaten, Berechtigungen, Bind-Modus und Verbindungszustand

submit_sm darf nur aus einer Sitzung im Status BOUND_TX oder BOUND_TRX gesendet werden. Das Senden aus einem anderen Status kann ESME_RINVBNDSTS erzeugen, definiert als falscher Bind-Status für den Befehl. Die richtige Maßnahme besteht nicht darin, denselben submit sofort erneut zu senden: Bestätigen Sie den Sitzungsstatus, führen Sie den passenden Bind aus und prüfen Sie, ob der autorisierte Modus die Übertragung erlaubt.

Die Fehler ESME_RBINDFAIL, ESME_RINVPASWD und ESME_RINVSYSID stehen für Bind-Fehler, ungültiges Passwort und ungültige Systemkennung. Sie müssen als Fehler behandelt werden, die eine Korrektur erfordern. Wiederholungen mit denselben Zugangsdaten verstärken die Fehler und können die Diagnose erschweren.

Beobachten Sie zusätzlich zum Code den Zustand der Verbindung: Socket-Schließungen, Timeouts, ausbleibende Antworten, häufige Wiederverbindungen und unbind-Ereignisse. Wenn eine Anfrage aufgrund eines Transportproblems ohne Antwort bleibt, gehen Sie nicht davon aus, dass sie nicht verarbeitet wurde. Wenden Sie vor einer Wiederholung Duplikatschutzmaßnahmen an und nutzen Sie, falls verfügbar und geeignet, Abfrage- oder Abgleichmechanismen anhand bekannter Kennungen.

• Prüfen Sie, dass die Sitzung vor dem Senden von submit_sm als Transmitter oder Transceiver gebunden ist.
• Überprüfen Sie system_id, Passwort, Berechtigungen und Bind-Modus anhand der autorisierten Konfiguration.
• Unterscheiden Sie eine explizite SMPP-Ablehnung von einem Timeout oder einer Verbindungstrennung ohne Antwort.
• Planen Sie unsichere Nachrichten nach einem Transportfehler nicht parallel erneut ein, wenn keine Strategie gegen Duplikate besteht.

Vorübergehende Fehler: Überlastung, Limits, Kapazität und kontrollierte Wartezeit

ESME_RTHROTTLED, Code 0x00000058, bedeutet, dass das ESME die erlaubten Nachrichtenlimits überschritten hat. Dies muss als Signal zur Verringerung der Versandrate interpretiert werden. Eine sofortige Wiederholung, insbesondere aus mehreren parallelen Prozessen, erhält oder verschärft die Überschreitung, die zur Ablehnung geführt hat.

ESME_RMSGQFUL, Code 0x00000014, bedeutet, dass eine Nachrichtenwarteschlange voll ist. Klassifizieren Sie diesen Code als Kapazitätssignal des SMSC oder der Route, getrennt von Format-, Zugangsdaten- oder Adressierungsfehlern. Er kann vorübergehend sein, doch der Standard legt weder ein Wiederherstellungsfenster fest noch garantiert er, dass ein Wiederholungsversuch erfolgreich ist.

Wenden Sie eine schrittweise Wartezeit und ein zur Nützlichkeit der Nachricht passendes Wiederholungslimit an. Verringern Sie Parallelität oder Durchsatz vor dem nächsten Versuch. Messen Sie Ablehnungen aufgrund von Limits, die Zeit bis zur Wiederherstellung und den Umfang pro Verbindung oder Ziel getrennt. Wenn die Fehler anhalten, pausieren Sie den betroffenen Verkehr und eröffnen Sie eine Untersuchung mit vollständigen Protokollen.

• ESME_RTHROTTLED: Rate senken, Parallelität steuern und nach einer Wartezeit erneut versuchen.
• ESME_RMSGQFUL: als Kapazitätsbegrenzung behandeln und beobachten, ob eine Wiederherstellung erfolgt.
• Vermeiden Sie parallele und unbegrenzte Wiederholungsversuche.
• Beenden Sie Wiederholungen, wenn die Nachricht keinen Nutzen mehr hat, das definierte Maximum erreicht wurde oder der Vorfall eskaliert werden muss.
• ESME_RSYSERR: zunächst untersuchen; der Standard erlaubt nicht, allein daraus auf einen vorübergehenden oder wiederholbaren Fehler zu schließen.

Dauerhafte oder korrekturbedürftige Fehler: ungültige Parameter, Adressierung, Absender und Format

PDU-Fehler erfordern eine Überprüfung der Nachrichtenerstellung vor einer erneuten Einreichung. ESME_RINVMSGLEN steht für ungültige Nachrichtenlänge, ESME_RINVCMDLEN für ungültige Befehlslänge und ESME_RINVCMDID für ungültige Befehlskennung. Sie sind keine Kandidaten für eine identische Wiederholung: Die Serialisierung oder Integrationslogik muss korrigiert werden.

In submit_sm kann short_message bis zu 254 Oktette enthalten. Die Spezifikation weist darauf hin, dass die genaue physische Grenze je nach zugrunde liegendem Netz variieren kann. Für Nachrichten über 254 Oktette muss message_payload verwendet werden; short_message darf nicht gleichzeitig verwendet werden. Diese Anforderung ersetzt nicht die Validierung der vom SMSC akzeptierten Regeln für Kodierung, Segmentierung und weitere Parameter.

ESME_RINVSRCADR und ESME_RINVDSTADR weisen auf eine ungültige Quell- beziehungsweise Zieladresse hin. Außerdem gibt es ESME_RINVDSTTON und ESME_RINVDSTNPI für TON und NPI des Ziels. Prüfen Sie die Adresse als Gesamtheit: Wert, TON, NPI und Annahmeregel der Verbindung. E.164 ist eine internationale Referenz für Nummerierung, doch ein mit dieser Referenz kompatibel wirkendes Format garantiert nicht, dass die Kombination aus Adresse, TON, NPI und SMSC-Richtlinie akzeptiert wird.

Wenden Sie bei Absendern dieselbe Sorgfalt an: Ein Fehler bei der Quelladresse erfordert die Prüfung des gesendeten Werts und der zugehörigen Parameter sowie der Regeln der Verbindung. Versuchen Sie nicht, Absenderbeschränkungen oder Messaging-Richtlinien zu umgehen; korrigieren Sie die Konfiguration und bestätigen Sie die für die Route geltenden Anforderungen.

• ESME_RINVMSGLEN, ESME_RINVCMDLEN und ESME_RINVCMDID: PDU korrigieren; nicht unverändert wiederholen.
• ESME_RINVSRCADR und ESME_RINVDSTADR: Quell- oder Zielwert prüfen.
• ESME_RINVDSTTON und ESME_RINVDSTNPI: Kombination aus Adresse, TON und NPI prüfen.
• Bei langen Nachrichten short_message nicht mit message_payload kombinieren.
• Behalten Sie eine Validierung vor dem Versand bei, um vermeidbare Ablehnungen zu reduzieren.

Mehrdeutige oder anbieterspezifische Fehler: Evidenz bewahren und dokumentierte Definition anfordern

Nicht jeder empfangene Code hat eine universelle Semantik. SMPP reserviert Bereiche für Erweiterungen und SMSC-Anbieter. Wenn Sie einen Code außerhalb der Standardtabelle erhalten, ordnen Sie ihn keiner allgemeinen Ursache zu und übersetzen Sie ihn ohne Dokumentation nicht als fehlgeschlagene Zustellung. Protokollieren Sie den exakten Wert und fordern Sie vom entfernten System eine dokumentierte technische Definition an.

Auch Zustellbestätigungen erfordern Vorsicht. SMPP erlaubt dem SMSC, bei Anforderung über registered_delivery eine Delivery Receipt mittels deliver_sm oder data_sm zurückzugeben, doch der informative Textinhalt einer SMSC Delivery Receipt ist anbieterspezifisch. Bauen Sie keine kritischen Automatisierungen ausschließlich auf einer Textzeichenfolge auf, die fälschlicherweise als universell angenommen wird.

Wenn vorhanden, stellt network_error_code einen tatsächlichen, technologieabhängigen Netzwerkfehlercode dar. Bewahren Sie sowohl den Netztyp als auch den Codewert auf, zusätzlich zum SMPP-Status und zum ursprünglichen DLR-Text. Diese Evidenz ermöglicht Untersuchungen, ohne die Unterscheidung zwischen einer standardmäßigen SMPP-Semantik, einem vom SMSC gemeldeten Status und einem zugrunde liegenden Netzwerkcode zu verwischen.

Eine gute Eskalationsakte enthält Chronologie, relevante PDU und Antwort, Originalcodes, korrelierte Kennungen, Sitzungsstatus, Fehlerquote und -umfang, bei Bedarf minimierte betroffene Ziele sowie jüngste Konfigurationsänderungen. Vermeiden Sie Zugangsdaten oder unnötige Daten.

• Bewahren Sie command_status in hexadezimaler Form und, falls vorhanden, mit seiner Standardinterpretation auf.
• Protokollieren Sie DLR-Texte, ohne anzunehmen, dass ihr Format zwischen Systemen portabel ist.
• Speichern Sie network_error_code mit Netztyp und Originalwert.
• Fordern Sie für Erweiterungs- oder Anbietercodes Dokumentation an.
• Eskalieren Sie mit ausreichender technischer Evidenz, ohne Verbindungsgeheimnisse offenzulegen.