Akzeptiert bedeutet nicht zugestellt: Versandstatus und DLR bei A2P-SMS abgleichen
Ein operatives Framework zur Trennung von API- und SMPP-Bestätigungen, Anbieterakzeptanz, Netzstatus und finalen DLR, ohne Transportnachweise als Behauptung einer Zustellung auf dem Endgerät darzustellen.
Die operative Frage: Welche Nachweise liegen nach dem Versand einer SMS tatsächlich vor?
Bei A2P-SMS kann das Wort „gesendet“ sehr unterschiedliche Sachverhalte beschreiben. Es kann bedeuten, dass eine Anwendung eine HTTP-Anfrage erstellt hat, dass ein ESME erfolgreich ein submit_sm_resp erhalten hat, dass ein Anbieter den Verkehr akzeptiert hat, dass ein Upstream-Carrier die Nachricht angenommen hat oder dass eine Zustellbestätigung eingegangen ist. Diese Signale haben nicht dieselbe Beweiskraft.
Die praktische Regel ist einfach: Jeder Status sollte die verfügbaren Nachweise ausdrücken, nicht die günstigste Schlussfolgerung. Eine erfolgreiche API-Antwort oder ein korrekter command_status in submit_sm_resp bestätigt das Ergebnis dieser technischen Interaktion. Sie bestätigt für sich allein weder, dass die Nachricht das Zielnetz erreicht hat, noch, dass der Teilnehmer sie auf seinem Endgerät erhalten hat.
Diese Unterscheidung ist insbesondere bei OTP- und transaktionalen Abläufen wichtig. Ein System kann Wiederholungsversuche auslösen, dem Nutzer einen Bildschirm anzeigen oder eine operative Untersuchung eröffnen, wenn es „akzeptiert“ fälschlich in „zugestellt“ umwandelt. Im zulässigen Marketing kann derselbe Fehler Kennzahlen und Entscheidungen zur Routenqualität verzerren.
Auch ein DLR sollte nicht automatisch als unabhängiger Nachweis des physischen Empfangs auf dem Endgerät dargestellt werden. Es ist ein über die Messaging-Kette übermittelter Statusnachweis. Seine konkrete Bedeutung hängt vom empfangenen Ereignis, den verfügbaren Feldern und den Garantien der einzelnen Beteiligten auf der Route ab.
- Anfragebestätigung: Nachweis, dass eine Stelle eine technische Anfrage verarbeitet hat.
- Anbieter- oder Carrier-Akzeptanz: Nachweis der Annahme zur weiteren Verarbeitung.
- Zwischenstatus: Nachweis für Warteschlange, Versand oder Transit, jedoch nicht zwingend für ein Endergebnis.
- Finaler DLR: gemeldeter Nachweis einer Zustellung oder Nichtzustellung; sollte zusammen mit Quelle und ursprünglicher Nutzlast gespeichert werden.
- Stille: fehlendes beobachtetes Ereignis, kein Nachweis für Zustellung oder Fehler.
Die vier Ebenen, die nicht vermischt werden sollten
Eine robuste Abgleicharchitektur trennt mindestens vier Ebenen. Die erste ist die lokale Akzeptanz: Die Anwendung hat eine Anfrage validiert und gesendet oder in ihre eigene Warteschlange gestellt. Das ist ein interner Sachverhalt und liefert keine Aussage über das externe Ergebnis.
Die zweite Ebene ist die Remote-Akzeptanz. In SMPP besitzt jede Operation außer alert_notification eine zugehörige Anfrage und Antwort. Erhält der Absender keine Antwort, muss er davon ausgehen, dass die PDU nicht von der entfernten Stelle empfangen wurde. Bei Erhalt von submit_sm_resp zeigt command_status Erfolg oder Fehler der submit_sm-Anfrage an. Diese Transportbestätigung ist kein DLR.
Die dritte Ebene ist die Verarbeitung durch Anbieter oder Netz. In HTTP-APIs stellen einige Anbieter Status wie accepted, queued, sending oder sent bereit. Sie können hilfreich sein, um eine Warteschlange, eine Versandphase oder die Akzeptanz durch einen Upstream-Carrier einzuordnen, unterscheiden sich aber weiterhin von einer Zustellbestätigung.
Die vierte Ebene ist das gemeldete Ergebnis. SMPP definiert Status wie ENROUTE, DELIVERED, EXPIRED, UNDELIVERABLE, UNKNOWN, ACCEPTED und REJECTED. Diese Vielfalt zeigt, warum ein einzelnes boolesches Erfolgsfeld häufig entscheidende Informationen für Betrieb, Kundenservice und Qualitätsanalysen verliert.
- Ebene 1: Anfrage wurde im eigenen System erstellt oder akzeptiert.
- Ebene 2: Anfrage wurde durch API, SMSC oder Anbieter akzeptiert oder abgelehnt.
- Ebene 3: Verarbeitung, Warteschlange, Versand oder Transit werden durch die Zustellkette gemeldet.
- Ebene 4: Endergebnis oder weiterhin ungelöster Status, gemeldet über DLR, Abfrage oder Abgleich.
Warum eine message_id kein Zustellnachweis ist
In SMPP ist message_id eine eindeutige Referenz, die vom SMSC vergeben wird. Die Spezifikation beschreibt sie als undurchsichtigen, implementierungsabhängigen Wert. Sie kann als Handle für spätere Operationen wie query_sm, cancel_sm oder replace_sm verwendet werden. Ihre Existenz ermöglicht die Korrelation von Operationen; sie belegt nicht, dass der Empfänger die SMS erhalten hat.
Eine Integration sollte nicht von einer einzigen Kennung abhängen. Der Anbieter kann eine eigene Kennung erzeugen, ein SMSC eine andere zurückgeben und ein DLR kann receipted_message_id enthalten. Zudem kann eine Geschäftsnachricht eine eigene stabile Kennung benötigen, um den Versandversuch mit einer Transaktion, einer OTP-Sitzung oder einer legitimen transaktionalen Benachrichtigung zu verknüpfen.
Die empfohlene Praxis besteht darin, vor dem Versand eine unveränderliche interne Kennung zu erzeugen. Diese Kennung sollte mit jedem technischen Versuch, seinen externen Referenzen, den eingegangenen Ereignissen und dem abgeleiteten Status verknüpft werden. Bei Wiederholungsversuchen benötigt jeder Versuch eine eigene Identität und eine explizite Beziehung zur ursprünglichen logischen Nachricht.
Verwenden Sie die Zielnummer, den vollständigen Nachrichtentext oder einen ungefähren Zeitstempel nicht als primären Korrelationsschlüssel. Diese Felder können sich wiederholen, durch Segmentierung ändern oder Datenschutzprobleme verursachen. Speichern Sie nur die für den Betrieb notwendigen Daten und wenden Sie die erforderlichen Datenschutzmaßnahmen an.
- message_logical_id: identifiziert die Nachricht oder Geschäftsaktion.
- attempt_id: identifiziert jeden technischen Versandversuch.
- provider_message_id: Kennung, die von API oder Anbieter zurückgegeben wird.
- smpp_message_id: Kennung aus submit_sm_resp, sofern anwendbar.
- receipted_message_id: Referenz in einem SMPP-DLR, sofern anwendbar.
- event_id oder Ereignis-Fingerprint: ermöglicht die Erkennung von Duplikaten, ohne Nachweise zu löschen.
- correlation_version: dokumentiert Korrelationsregeln, wenn sie sich im Zeitverlauf ändern.
Modell einer Zustandsmaschine für eine A2P-SMS
Die Zustandsmaschine sollte beobachtete Ereignisse von abgeleiteten Schlussfolgerungen unterscheiden. Ein Ereignis ist unveränderlich, etwa eine akzeptierte HTTP-Antwort, ein erfolgreiches submit_sm_resp, ein deliver_sm mit message_state oder eine spätere Abfrage. Der aktuelle Status ist eine Projektion, die aus allen korrelierten Ereignissen und expliziten Regeln berechnet wird.
Ein Minimalmodell kann interne Status für Erstellung, lokalen Versand und Warten auf eine Antwort verwalten; Status für Remote-Akzeptanz; vorübergehende Verarbeitungsstatus; gemeldete Endstatus; sowie einen Abgleichstatus, der angibt, ob ein Fall abgeschlossen ist, weiter beobachtet wird oder überprüft werden muss. Es ist nicht nötig, alle Anbieter in eine genauere Taxonomie zu zwingen, als die vorliegenden Nachweise erlauben.
Behandeln Sie bei SMPP ein erfolgreiches submit_sm_resp als „von der SMPP-Stelle akzeptiert“, nicht als „zugestellt“. Wenn Bestätigungen über deliver_sm eintreffen, erfassen Sie die verfügbaren Werte, einschließlich receipted_message_id, message_state und, sofern vorhanden, network_error_code. Zwischenbenachrichtigungen und DLR können denselben Transportmechanismus nutzen.
Eine vorsichtige Projektion kann „Zustellung gemeldet“ anzeigen, wenn die normalisierten Nachweise DELIVERED oder einen vom Anbieter gemeldeten gleichwertigen Status enthalten. Bei negativen Endstatus wie UNDELIVERABLE, EXPIRED oder REJECTED kann sie „Nichtzustellung gemeldet“ anzeigen, ohne den ursprünglichen Code zu löschen. Liegt nur ein Transitstatus vor, muss das Ergebnis weiterhin ausstehend oder in Bearbeitung bleiben.
- CREATED: Versandabsicht wurde erstellt, ohne Remote-Nachweis.
- SUBMITTED_LOCAL: Das System hat versucht, die Anfrage zu übertragen.
- REMOTE_ACCEPTED: API, SMSC oder Anbieter hat die technische Anfrage akzeptiert.
- IN_PROGRESS: Es liegen Nachweise für Warteschlange, Versand, Transit oder ENROUTE vor.
- DELIVERED_REPORTED: Ein über die Messaging-Kette gemeldeter positiver Endstatus wurde empfangen.
- FAILED_REPORTED: Ein über die Messaging-Kette gemeldeter negativer Endstatus wurde empfangen.
- UNKNOWN_OR_UNRESOLVED: Es liegen keine ausreichenden finalen Nachweise vor oder UNKNOWN wurde empfangen.
- RECONCILIATION_PENDING: Ein operatives Zeitfenster ist abgelaufen und der Fall erfordert eine Abfrage oder Abschlussklassifizierung.
HTTP, SMPP und heterogene DLR normalisieren, ohne Originaldaten zu verlieren
Normalisierung dient einem konsistenten Betrieb, nicht dem Ersatz der Quellsemantik. Speichern Sie stets das Originalereignis zusammen mit einer normalisierten Darstellung. Die ursprüngliche Nutzlast wird für technische Audits, die Fehlersuche bei Zuordnungen und Anpassungen benötigt, wenn ein Anbieter Felder in Callbacks ergänzt oder verändert.
Erfassen Sie für jedes Ereignis mindestens Quelle, Schnittstellentyp, Empfangszeitpunkt auf Ihrer Plattform, verfügbare externe Kennung, ursprünglichen Status, normalisierten Status, Fehlercodes und geschützte ursprüngliche Nutzlast. Wenn der Anbieter einen vom Netz stammenden Zeitstempel meldet, speichern Sie ihn getrennt von der Empfangszeit: Sie bezeichnen nicht zwingend denselben Zeitpunkt.
Ein deliver_sm kann in SMPP Zustellbestätigungen transportieren. Für diese Ereignisse sind receipted_message_id und message_state relevante Parameter; network_error_code kann vorhanden sein. Verwerfen Sie eine Bestätigung nicht, nur weil ein von Ihrer Integration nicht garantiertes Feld fehlt: Klassifizieren Sie sie anhand der verfügbaren Nachweise und kennzeichnen Sie sie zur Überprüfung, wenn sie nicht sicher korreliert werden kann.
Gehen Sie bei HTTP nicht davon aus, dass alle Callbacks dieselben Felder enthalten oder dass alle Status für jeden Kanal oder jede Konfiguration existieren. Pflegen Sie eine versionierte Zuordnungstabelle je Anbieter und Schnittstelle. Die Zuordnung sollte externe Status in breite operative Kategorien überführen und dabei den externen Literalwert erhalten.
- Ersetzen Sie den ursprünglichen Status nicht durch den normalisierten; speichern Sie beide.
- Unterscheiden Sie event_received_at und event_reported_at, wenn die Quelle einen eigenen Zeitstempel liefert.
- Erfassen Sie Fehlercodes und Fehlertexte, ohne sie in unbestätigte Diagnosen umzuwandeln.
- Versionieren Sie Zuordnungs- und Vorrangregeln.
- Halten Sie nicht korrelierte Ereignisse in einer Untersuchungswarteschlange, statt sie anhand schwacher Ähnlichkeiten zuzuordnen.
Vorübergehende, finale und unbekannte Status: explizite Regeln
Klassifizieren Sie Status nach ihrer operativen Funktion. Vorübergehende Status zeigen an, dass weitere Informationen eintreffen können; finale Status melden ein Ergebnis und schließen je nach Ihren Regeln den Versuch ab; unbekannte Status drücken fehlende Auflösung aus und dürfen nicht aus analytischer Bequemlichkeit in Erfolg oder Fehler umgewandelt werden.
SMPP führt ENROUTE als Transitstatus auf und DELIVERED, EXPIRED, DELETED, UNDELIVERABLE sowie REJECTED als Status, die je nach Integrationskontext finalen Charakter haben können. UNKNOWN erfordert besondere Vorsicht: Es besagt, dass der Status nicht bestimmt werden kann, nicht dass die Nachricht fehlgeschlagen oder zugestellt wurde.
Definieren Sie im Voraus, welche Status einen Versuch abschließen und welche weitere Ereignisse zulassen. Die Regel sollte nicht nur in implizitem Code liegen. Sie muss dokumentiert, überprüfbar und kontrolliert änderbar sein, wenn sich eine Schnittstelle oder operative Beziehung verändert.
Machen Sie den Zeitablauf nicht zu einem Zustellnachweis. Zeit kann nur eine Abgleichaktion oder einen administrativen Abschluss mit erklärter Unsicherheit auslösen. Liegt kein DLR vor, kann das korrekte Ergebnis „kein finaler Status innerhalb des Zeitfensters beobachtet“ sein, nicht „zugestellt“.
- Vorübergehend: queued, sending, sent, ENROUTE oder von der Quelle gemeldete Äquivalente.
- Gemeldete positive Endstatus: DELIVERED oder ein explizites Äquivalent des Anbieters.
- Gemeldete negative Endstatus: EXPIRED, UNDELIVERABLE, REJECTED oder explizite Äquivalente.
- Unbestimmt: UNKNOWN, Korrelationsfehler, fehlende DLR und unvollständige Ereignisse.
- Administrativ: durch operative Richtlinie abgeschlossen, stets getrennt vom gemeldeten Zustellergebnis.
Doppelte, ungeordnete oder widersprüchliche DLR
Messaging-Systeme müssen für wiederholte Ereignisse und unvollständige Reihenfolgen ausgelegt sein. SMPP gibt an, dass ein SMSC zwar in derselben Reihenfolge antworten sollte, in der es Anfragen empfängt, dazu aber nicht verpflichtet ist, und dass ein ESME Antworten außerhalb der Reihenfolge verarbeiten können muss. Diese Vorsicht sollte auch auf HTTP-Callbacks, interne Warteschlangen und Wiederholungsprozesse ausgeweitet werden.
Die Antwort darauf ist nicht, den zuletzt empfangenen Wert zu überschreiben. Speichern Sie jedes Ereignis als unveränderlichen Sachverhalt und leiten Sie den aktuellen Status anhand einer Vorrangregel ab. Die Regel sollte mindestens Korrelation, Statuskategorie, den von der Quelle gemeldeten Zeitpunkt, sofern verlässlich, Empfangszeit, Quelle und die Version der angewandten Regel berücksichtigen.
Ein Duplikat kann über eine Ereigniskennung erkannt werden, sofern vorhanden, oder über einen aus stabilen Ereignisfeldern berechneten Fingerprint. Die Kennzeichnung als Duplikat bedeutet nicht, dass es gelöscht wird: Es bleibt für die Diagnose wertvoll und zeigt, dass das System mehr als eine Benachrichtigung empfangen hat.
Erfinden Sie bei Widersprüchen keine Auflösung. Wenn beispielsweise ein positives Endsignal und später ein negatives Ereignis auftreten, das nicht durch einen anderen Versuch erklärt werden kann, bewahren Sie beide auf, markieren Sie den Fall als widersprüchlich und wenden Sie eine vorsichtige Darstellungsregel an. Die operative Ansicht kann eine Prüfung erfordern, während das Audit die vollständige Sequenz zeigen muss.
- Verwenden Sie „das letzte Ereignis gewinnt“ nicht als einzige Regel.
- Leiten Sie den Status je Versuch ab, nicht nur je logischer Nachricht.
- Wenden Sie idempotente Deduplizierung an, bevor Projektionen aktualisiert werden.
- Trennen Sie verspätete von ungültigen Ereignissen: Ein verspätetes Ereignis kann legitim sein.
- Leiten Sie unauflösbare Widersprüche zur operativen Prüfung weiter.
- Erfassen Sie den Grund für jede Änderung des abgeleiteten Status.
Was tun, wenn kein DLR eintrifft?
Das Ausbleiben eines DLR beweist weder, dass die Nachricht nicht verarbeitet wurde, noch, dass sie nicht zugestellt wurde. Es kann bedeuten, dass kein Callback eingegangen ist, die Integration ihn für diesen Fall nicht angefordert hat oder nicht unterstützt, das Ereignis nicht korreliert werden konnte oder die Kette noch kein beobachtbares Ergebnis erzeugt hat.
Legen Sie Wartefenster je Anwendungsfall, Anbieter und Schnittstelle nur dann fest, wenn eine begründete operative Richtlinie vorliegt. Vermeiden Sie es, eine Empfehlung eines Anbieters in eine universelle Regel umzuwandeln. Als Beispiel für eine dokumentierte Praxis empfiehlt Twilio, die Ressource abzufragen, wenn innerhalb von 12 Stunden weder delivered noch undelivered eingegangen ist, und Status mindestens täglich abzugleichen; diese Vorgabe muss für jede Integration angepasst und validiert werden und darf nicht als branchenweites Verhalten angenommen werden.
Bei legitimen OTPs erfordert das Produktziel oft eine schnelle Entscheidung, doch der Zustellstatus darf nicht durch eine Annahme ersetzt werden. Entwickeln Sie geeignete alternative Authentifizierungsmöglichkeiten, steuern Sie Wiederholungsversuche zur Vermeidung von Duplikaten und erfassen Sie, dass das Ergebnis ausstehend bleibt, wenn kein finaler Nachweis eintrifft. Für transaktionale Nachrichten kann je nach Kritikalität und Prozesserwartungen ein längeres Zeitfenster angemessen sein. Bei einwilligungsbasiertem Marketing trennen Sie die Messung der gemeldeten Zustellung von Interaktionskennzahlen und leiten Sie aus dem DLR keine Lesebestätigung ab.
Der operative Abschluss sollte zwischen „finales Ergebnis gemeldet“, „Ergebnis abgefragt“, „kein DLR beobachtet“ und „nicht korrelierbar“ unterscheiden. Diese Genauigkeit verringert Konflikte zwischen Systemen und verhindert, dass Qualitätsberichte Unsicherheit in eine künstliche Zustellrate umwandeln.
- Prüfen Sie, ob die Anforderung von DLR oder Callback konfiguriert ist, sofern die Schnittstelle dies ermöglicht.
- Prüfen Sie Verfügbarkeit des empfangenden Endpunkts, Authentifizierung und Protokollierung von Callback-Fehlern.
- Planen Sie Abgleichabfragen ein, wenn der Anbieter eine abfragbare Statusquelle bereitstellt.
- Schließen Sie mit einem Unsicherheitskennzeichen ab, wenn keine finalen Nachweise vorliegen.
- Schreiben Sie Stille nicht ohne stützende Daten einem Netzfehler, Anbieterfehler oder einer Zustellung zu.
- Messen Sie separat angeforderte DLR, empfangene DLR, korrelierte DLR und Fälle ohne finale Auflösung.
Häufige Fragen
Bestätigt ein submit_sm_resp mit korrektem command_status die Zustellung der SMS?
Nein. Es bestätigt das Ergebnis der submit_sm-Anfrage gegenüber der entfernten SMPP-Stelle. Es handelt sich um die technische Akzeptanz der Anfrage, nicht um eine Zustellbestätigung beim Teilnehmer.
Was weist eine SMPP-message_id nach?
Sie weist nach, dass das SMSC eine Referenz für spätere Operationen wie Abfrage, Stornierung oder Ersetzung vergeben hat. Sie ist für die Korrelation nützlich, aber kein Zustellnachweis.
Welcher Status sollte angezeigt werden, wenn kein DLR eintrifft?
Ein Unsicherheitsstatus wie „kein finaler Status beobachtet“ oder „Abgleich ausstehend“, abhängig von Ihrer Richtlinie. Das Fehlen eines DLR darf ohne zusätzliche Nachweise weder als Zustellung noch als Fehler bezeichnet werden.
Wie sollten doppelte DLR behandelt werden?
Speichern Sie jedes Ereignis unveränderlich, erkennen Sie Duplikate anhand einer Kennung oder eines stabilen Fingerprints und gestalten Sie die Aktualisierung des abgeleiteten Status idempotent. Löschen Sie die ursprünglichen Nachweise nicht.
Kann ein DLR außerhalb der Reihenfolge eintreffen?
Ja. SMPP verlangt, dass eine Implementierung Antworten außerhalb der Reihenfolge verarbeiten kann. Daher darf die Ankunftsreihenfolge nicht die einzige Grundlage für die Entscheidung über den Endstatus sein.
Beweist ein DLR mit delivered unabhängig, dass der Nutzer die Nachricht gesehen oder gelesen hat?
Nein. Ein DLR mit delivered ist ein über die Messaging-Kette gemeldeter Zustellnachweis. Er belegt für sich allein weder das Lesen noch die Aufmerksamkeit des Nutzers oder dessen Einwilligung.
Verwendete Quellen
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- Outbound Message Status in Status CallbacksTwilio Documentation
- Messages resourceTwilio Documentation
- Best Practices for Messaging Delivery Status LoggingTwilio Documentation