A2P-SMS-Konnektivitätsausfall oder Verschlechterung einer Route: Ursachen anhand von Belegen eingrenzen

Konnektivität, Annahme und Zustellung sind unterschiedliche Signale

Ein A2P-SMS-Vorfall kann an unterschiedlichen Stellen des Übertragungswegs auftreten. Die Verbindung kann bereits vor dem Senden der Nachricht fehlschlagen; die Plattform oder das SMSC kann die Nachricht ablehnen; der Versand kann angenommen werden, ohne dass schon ein Endergebnis vorliegt; oder der Fehler tritt erst nach der Annahme auf. Für jede Situation sind andere Belege erforderlich.

Bei SMPP zeigt eine erfolgreiche Antwort auf submit_sm an, dass das SMSC die Nachricht zur späteren Weiterleitung angenommen hat. Sie bestätigt für sich genommen nicht, dass die Nachricht das Telefon erreicht hat. ENQUIRE_LINK und ENQUIRE_LINK_RESP prüfen ebenfalls nur die Verbindung zwischen ESME und SMSC, nicht die Zustellung über das Mobilfunknetz.

• Verbindung oder Sitzung: Prüfe, ob der Client die Verbindung zur Schnittstelle herstellen und aufrechterhalten kann.
• Antwort auf den Versand: Ermittle, ob die Anfrage angenommen oder abgelehnt wurde, und protokolliere den verfügbaren Grund.
• Späteres Ergebnis: Verknüpfe Statusberichte mit der ursprünglichen Nachricht und prüfe, welche Instanz sie ausgegeben hat.
• Menschliche Wahrnehmung: Leite aus einer Protokollantwort oder einem DLR nicht ab, dass eine Person die SMS gelesen hat.

Übertragungsweg eingrenzen und Kennungen aufbewahren

Zeichne vor Änderungen an Routen oder Konfiguration den tatsächlichen Übertragungsweg des Datenverkehrs auf: Client-Anwendung, HTTP-Integration oder SMPP-Sitzung, Plattform, Anbieter und mobiles Ziel. Notiere, an welcher Stelle jeder Protokolleintrag entsteht und wer die jeweilige Antwort erzeugt. Die interne Funktionsweise eines Service Centre kann außerhalb dessen liegen, was eine Schnittstelle oder Spezifikation sichtbar macht. Berücksichtige diese Grenze in deiner Analyse.

Bewahre Zeitstempel und Referenzen auf, mit denen sich die einzelnen Schritte verknüpfen lassen. Protokolliere bei SMPP die Sequenznummer von Anfrage und Antwort, die zurückgegebene Nachrichtenkennung und – falls ein Empfangsbericht eingeht – dessen Referenz auf die ursprüngliche Nachricht. Bei HTTP bewahre die verfügbare Anfragekennung, den Zeitpunkt, den Endpoint und die Antwort auf. Gehe nicht davon aus, dass Kennungen aus verschiedenen Systemen austauschbar sind.

• Protokolliere Versandzeit und Zeitzone, das Ziel im normalisierten Format, Absender, Nachrichtenart und ausgewählte Route.
• Speichere den HTTP-Code oder SMPP-Status, den relevanten Antworttext oder die Fehlerfelder sowie die verfügbare Korrelationskennung.
• Erfasse bei jedem Callback oder DLR den Zeitpunkt und die Quelle sowie die Referenz auf die Nachricht.
• Schütze personenbezogene Daten und beschränke den Zugriff auf Protokolle gemäß den geltenden Richtlinien.

Zuerst die Integration prüfen

Beginne auf der Seite, die du kontrollierst. Unterscheide bei HTTP Transportfehler von HTTP-Antworten und prüfe den Statuscode, den Antworttext und mögliche Hinweise zu Wiederholungsversuchen. Ein 503 bedeutet, dass der Server die Anfrage vorübergehend nicht bearbeiten kann; mögliche Gründe sind etwa Überlastung oder Wartungsarbeiten. Retry-After kann einen Hinweis auf die Wartezeit geben. Ein 429 bedeutet, dass der Server eine zu hohe Anzahl von Anfragen innerhalb eines Zeitraums feststellt; auch diese Antwort kann Retry-After enthalten. Ein 502 kennzeichnet ein Problem mit einem Gateway oder Proxy, der eine ungültige Antwort vom Upstream-Server erhalten hat. Für sich genommen zeigt der Code jedoch nicht, welche Komponente das Problem verursacht hat.

Prüfe bei SMPP den Bind-Status, Verbindungsabbrüche, Timeouts, Antworten auf Anfragen und den Zustand der Sitzung. ESME_RTHROTTLED (0x58) bedeutet, dass das ESME die für diese Schnittstelle zulässigen Limits überschritten hat. Das ist ein Beleg für eine Ratenbegrenzung an dieser Schnittstelle, aber kein Nachweis für eine Verschlechterung einer Zielroute.

Überprüfe außerdem die lokale Warteschlange, die Empfangsbestätigung von Callbacks und die Wiederholungslogik. SMPP garantiert für sich genommen keine Idempotenz. Tritt ein Timeout auf, lässt sich anhand dieses Signals allein möglicherweise nicht feststellen, ob das SMSC die Anfrage verarbeitet hat. Nutze vor einem erneuten Versuch die dokumentierten Korrelations- und Statusabfragemöglichkeiten, sofern vorhanden. Gehe nicht davon aus, dass sich immer feststellen lässt, ob der Vorgang bereits angenommen wurde.

• Schlagen Verbindung oder Bind fehl, prüfe zuerst Zugangsdaten, Sitzungskonfiguration, Konnektivität und Schnittstellenlimits.
• Erhältst du Ablehnungen, gruppiere sie nach Code und bewahre die ursprünglichen Antworten auf, bevor du Parameter änderst.
• Treten 429 oder ESME_RTHROTTLED auf, vergleiche Anfragevolumen und -rate mit den vereinbarten Limits. Bezeichne dies nicht automatisch als Abdeckungsproblem.
• Wende dich bei 503 oder 502 an die für die antwortende Komponente verantwortliche Stelle und nenne Zeitpunkt, Kennung und beobachtete Antwort.

Muster nach Ziel und Verkehrseigenschaften suchen

Eine Routenverschlechterung lässt sich am besten anhand wiederkehrender Unterschiede zwischen Segmenten untersuchen, nicht anhand einer einzelnen Nachricht ohne Kontext. Vergleiche Ziele, Mobilfunkanbieter – sofern diese Information verlässlich ist –, Absender, Nachrichtenart, Route und Zeitfenster. Halte andere relevante Eigenschaften möglichst konstant: Beim Vergleich unterschiedlicher Sendungen können Änderungen bei Empfänger, Absender, Inhalt oder Konfiguration mit dem Routeneffekt verwechselt werden.

Notiere, welches Segment Fehler aufweist und welches als Vergleich dient. Fällt ein Vorfall mit einem Zielnetzbetreiber zusammen, ist das ein Hinweis zur Eingrenzung, aber kein Beweis, dass das Netz dieses Betreibers die Ursache ist. Stelle sicher, dass Stichprobe und Parameter vergleichbar sind, und fordere von den Parteien, die nicht sichtbare Abschnitte kontrollieren, weitere Belege an.

• Gruppiere Fälle nach Land oder Ziel, bekanntem Mobilfunkanbieter, Absender, Verkehrstyp (OTP, Transaktion oder Marketing), Route und Zeitraum.
• Vergleiche Annahmequoten, Ablehnungen und Endstatus getrennt. Vermische keine Kennzahlen mit unterschiedlichen Definitionen.
• Prüfe, ob die verglichenen Nachrichten eine gleichwertige Konfiguration haben und die Zeitfenster zusammenpassen.
• Notiere Konfigurations- oder Volumenänderungen sowie Änderungen im Verhalten des Clients, die zeitgleich mit dem Problem auftraten.

Kontrollierte Stichproben vergleichen, ohne Korrelation mit Ursache zu verwechseln

Wähle vergleichbare Stichproben aus und lege vorab fest, welches Signal du vergleichen willst: die Versandantwort, die Zeit bis zu einer Antwort, den Eingang eines Callbacks oder einen gemeldeten Status. Fasse Ereignisse aus verschiedenen Übertragungsphasen nicht zu einer einzigen Kennzahl zusammen. Ein beobachteter Unterschied zwischen zwei Segmenten hilft, Hypothesen aufzustellen, belegt aber für sich genommen keine Kausalität.

Führe, sofern dies sicher und autorisiert ist, begrenzte Vergleiche mit legitimem, einwilligungsbasiertem Datenverkehr durch. Ändere nicht mehrere Variablen gleichzeitig: Änderst du Route, Absender und Konfiguration zugleich, lässt sich schwerer erkennen, was das Ergebnis beeinflusst hat. Stimme Tests mit den zuständigen Stellen ab und vermeide unnötigen zusätzlichen Datenverkehr.

• Definiere vor der Auswertung die betroffene Gruppe, eine Vergleichsgruppe und den Zeitraum.
• Kontrolliere relevante Faktoren wie Ziel, Absender, Nachrichtentyp, Konfiguration und Versandbedingungen.
• Trenne Messwerte zur Annahme von Messwerten zur Zustellung und weise auf fehlende Daten hin.
• Wiederhole den Vergleich in einem weiteren Zeitfenster, wenn Umfang oder Zusammensetzung der Stichprobe den Unterschied erklären könnten.

DLRs nach Quelle und Aussageumfang interpretieren

Ein DLR ist ein Signal, dessen Bedeutung davon abhängt, wer es ausgibt und wie es in der Integration definiert ist. Gemäß der 3GPP-Spezifikation bestätigt ein Bericht des Service Centre den Empfang durch das Centre, nicht unbedingt durch das Endgerät. Ein von der Mobilstation ausgegebener Bericht bestätigt den Empfang durch das Endgerät, aber nicht, dass der Nutzer die Nachricht gelesen hat. Prüfe vor der Verwendung als Beleg die Quelle des Berichts und den Status, den er abbildet.

Ein SMS-STATUS-REPORT informiert über den Status des Versands, ist aber nicht automatisch eine Bestätigung des menschlichen Empfangs. Außerdem kann sich das, was eine Schnittstelle als „zugestellt“ bezeichnet, von dem technischen Ereignis unterscheiden, auf dem dieser Status beruht. Sind Quelle oder Semantik des DLR unklar, dokumentiere diese Unsicherheit und bitte den Anbieter um Klärung.

• Verknüpfe den Bericht mit der Kennung der ursprünglichen Nachricht und bewahre seinen Zeitstempel auf.
• Frage, welche Instanz den Status erzeugt, welches Ereignis er bestätigt und welche Fehlerzustände er abbilden kann.
• Unterscheide zwischen fehlendem DLR, verzögertem Bericht und Fehlerstatus. Behandle diese Fälle nicht als gleichwertig.
• Nutze ein einzelnes DLR nicht, um das Problem dem Mobilfunknetz, dem Anbieter oder dem Endgerät zuzuschreiben.

Entscheidungsbaum zum Eingrenzen und Eskalieren

Gehe bei der Diagnose der Reihe nach vor – von der ersten beobachtbaren Phase bis zum späteren Ergebnis. Brich die Untersuchung bei der ersten Phase ab, zu der keine Belege vorliegen, und fordere die benötigten Protokolle an. Ziehe nicht von einem Integrationssymptom direkt einen Schluss über das Zielnetz.

Bei einer Betriebsstörung solltest du sichere und reversible Maßnahmen priorisieren: Reduziere oder pausiere den betroffenen Datenverkehr, wenn die Gefahr von Duplikaten, Missbrauch oder betrieblichen Auswirkungen besteht, und halte dich an das vereinbarte Verfahren für einen Routenwechsel. Gehe nicht davon aus, dass eine alternative Route verfügbar, gleichwertig oder für diesen Datenverkehr freigegeben ist.

• Keine HTTP-Verbindung oder kein SMPP-Bind: Erfasse Zeitpunkte, Transportfehler, Sitzungsstatus und kürzliche Änderungen. Eskaliere an das für Konnektivität oder Integration verantwortliche Team.
• Sitzung besteht, Versand wird aber abgelehnt: Gruppiere Codes und Antworten. Prüfe Format und Schnittstellenlimits und eskaliere mit Beispielen, die sich korrelieren lassen.
• Versand angenommen, Ergebnis fehlt: Prüfe Callbacks, Timeouts und die Bedeutung des DLR. Bitte den Anbieter um den Status der nachgelagerten Phase. Die Annahme beweist keine Zustellung.
• Berichte zeigen auf ein Segment konzentrierte Fehler: Prüfe, ob die Stichproben vergleichbar sind, und teile das Muster mit Anbieter und zuständigen Stellen auf der Zielseite, ohne eine Ursache zu behaupten, bevor Belege aus dieser Phase vorliegen.
• Ergebnisse widersprechen sich oder Kennungen lassen sich nicht zuordnen: Ziehe keine Schlüsse, prüfe Uhren, Referenzen und Duplikate und rekonstruiere den Übertragungsweg anhand der ursprünglichen Protokolle.

Belege, Unsicherheiten und Maßnahmen dokumentieren

Ein guter Bericht ermöglicht es einem anderen Team, die Schlussfolgerungen nachzuvollziehen, ohne die Ursache vorauszusetzen. Trenne beobachtete Fakten, Hypothesen und Schlussfolgerungen voneinander. Gib an, welche Systeme die jeweiligen Protokolle geliefert haben und welche Abschnitte des Übertragungswegs nicht einsehbar sind. Füge eine kleine, repräsentative und datenschutzgerecht geschützte Stichprobe bei – nicht nur zusammengefasste Screenshots ohne Kennungen.

Standards beschreiben für die einzelnen Phasen unterschiedliche Grenzen und Signale: Verbindung, Annahme und Statusberichte. Die Diagnose sollte diese Grenzen berücksichtigen und überprüfbare Beobachtungen von Hypothesen unterscheiden, für die noch Belege fehlen.

• Fasse Auswirkungen, bekannte Anfangs- und Endzeitpunkte, betroffene und nicht betroffene Segmente sowie kürzliche Änderungen zusammen.
• Füge Zeitstempel, Kennungen, ursprüngliche Antworten und die Definition jedes analysierten Status bei.
• Kennzeichne jeden Punkt als Fakt, Hypothese, ausstehenden Datenpunkt oder ergriffene Maßnahme.
• Halte fest, wer die nächsten Belege liefern soll und wann die Diagnose überprüft wird.