SMPP-Konten für Kunden: Binds, TPS, DLRs und Abrechnung

In dem Moment, in dem ein technischer Kunde fragt: „Kann ich mich per SMPP binden?“, ist Ihre Plattform in seinen Augen kein Web-Panel mehr, sondern ein Carrier. SMPP-Konten für Kunden sind die Funktion, mit der Sie Banken, OTP-Anbieter, andere Aggregatoren und jeden Entwickler gewinnen, der bereits eine SMPP-Client-Bibliothek hat, und sie sind zugleich die Stelle, an der eine nachlässige Einrichtung am meisten schadet: ein Kunde ohne Durchsatzobergrenze, ein Receiver-Bind, den niemand konfiguriert hat, Zustellberichte, die nirgendwo ankommen, ein Kontobuch, an dem der Bind vorbeiläuft. Dieser Leitfaden ist die Checkliste, um es richtig zu machen, vom Bind, den Sie ausgeben, bis zum Test, den Sie durchführen, bevor Sie dem Kunden sagen, dass er live gehen kann.

Was SMPP-Konten für Kunden eigentlich sind

Über die HTTP-API sendet ein Kunde eine Anfrage pro Nachricht und erhält eine Antwort. Über SMPP öffnet der Kunde eine langlebige TCP-Sitzung zu Ihrem SMPP-Server, authentifiziert sich einmal mit system_id und Passwort und streamt die Nachrichten als Binärpakete, sogenannte PDUs, über diese Sitzung. Ihre Plattform muss einen SMPP-Server betreiben (der von Smppcube lauscht auf Port 2775 und ist auf der Plattform-Seite eingezeichnet), den Bind annehmen, jedes submit_sm gegen das Konto des Kunden prüfen, es in dieselbe Pipeline einreihen, die auch die HTTP-API speist, und später den Zustellbericht als deliver_sm über die Sitzung zurückschicken.

Ein SMPP-Konto ist also kein separates Produkt mit eigener Abrechnung. Es sind Zugangsdaten zu einem bestehenden Kundenkonto plus eine Reihe von Limits: welche Bind-Modi, von welchen IPs, wie viele Sitzungen, wie schnell. Die Zugangsdaten sind der kleine Teil. Die Limits sind das Konto.

Bind-Typen und was Sie erlauben sollten

SMPP definiert drei Bind-Modi, und Ihre Kontoeinrichtung sollte festlegen, welche der Kunde nutzen darf:

• Transmitter: nur Senden. Der Kunde reicht Nachrichten ein und erhält die Antworten auf seine submits (die Nachrichten-ID), sonst nichts. Einfach, und der Grund, warum Zustellberichte verloren gehen, denn ein Transmitter hat keinen Kanal für ein deliver_sm.
• Receiver: nur Empfangen. Der Kunde erhält Zustellberichte und eingehende Nachrichten (Antworten von Mobiltelefonen, falls Sie welche an ihn routen) und kann nicht senden.
• Transceiver: beides in einer Sitzung. Das öffnen die meisten modernen Client-Bibliotheken standardmäßig, und das sollten Sie empfehlen, weil eine Sitzung Sendungen und Zustellberichte zusammen trägt und nichts auseinanderlaufen kann.

Das traditionelle Muster aus einem Transmitter- und einem Receiver-Bind gibt es noch, meist weil ein älterer Client-Stack so geschrieben wurde. Erlauben Sie es, aber zählen Sie es als zwei Sitzungen gegen das Limit des Kontos, und stellen Sie sicher, dass der Receiver-Bind wirklich offen ist, bevor Sie annehmen, dass Zustellberichte zugestellt werden.

Sitzungslimits zählen mehr, als man erwartet. Ein Kunde, der „zur Redundanz“ zehn Transceiver-Binds öffnet, belegt zehn Plätze in der Verbindungstabelle Ihres Servers und kann den zehnfachen Durchsatz schieben, den Sie vorgesehen hatten. Zwei bis vier Sitzungen pro Konto sind ein sinnvoller Standard; ein Kunde, der mehr braucht, gehört in ein höheres Paket.

Durchsatz, Fenster und Drosselung

Der Durchsatz über SMPP hängt von zwei Dingen ab: wie viele PDUs der Kunde gleichzeitig unterwegs haben darf, bevor er auf Bestätigungen wartet (das Fenster), und der Rate, die Sie erlauben. Der Leitfaden SMPP gegen HTTP erklärt, warum ein einzelner gut verwalteter Bind Hunderte Nachrichten pro Sekunde schieben kann; der Punkt hier ist, dass auf Ihrer Plattform Sie derjenige sind, zu dem geschoben wird.

Geben Sie jedem SMPP-Konto eine Obergrenze in Nachrichten pro Sekunde, die aus dem Vertrag kommt, nicht aus dem, was Ihr Server leisten könnte. Ein Kunde, der für 10 msg/s bezahlt, bekommt 10 msg/s; überschreitet er sie, antworten Sie mit dem Drosselungsfehler, den das Protokoll definiert (ESME_RTHROTTLED), statt den Überschuss still in die Warteschlange zu stellen. Eine gut geschriebene Client-Bibliothek versteht diesen Fehler als „langsamer werden“ und fährt zurück. Eine schlecht geschriebene hämmert weiter, und Ihr Server sollte den Bind nach wiederholten Verstößen trennen und den Grund protokollieren, denn die Alternative ist, dass die falsch konfigurierte Wiederholungsschleife eines einzelnen Kunden zur Latenz aller wird.

Zwei weitere Zahlen gehören zum Konto. Eine Fenstergröße (10 bis 20 unbestätigte PDUs sind für einen kundenseitigen Bind üblich; vorgelagerte Netzbetreiber erlauben unter Umständen mehr) und ein enquire_link-Intervall, der Heartbeat, der eine ruhende Sitzung am Leben hält. Nennen Sie dem Kunden alle drei, wenn Sie die Zugangsdaten ausgeben. Das häufigste Ticket vom Typ „SMPP funktioniert nicht“ ist eine Client-Bibliothek, die auf ein Fenster eingestellt ist, das Ihr Server nicht gewährt, bei jeder zehnten Nachricht in einen Timeout läuft und das als Plattformfehler meldet.

Wohin Zustellberichte gehen

Ein Zustellbericht (DLR) über SMPP ist keine Antwort auf das submit des Kunden. Er trifft später ein, unaufgefordert, als deliver_sm auf dem Receiver- oder Transceiver-Bind des Kunden, und der Kunde ordnet ihn der ursprünglichen Nachricht über die Nachrichten-ID zu, die Ihr Server beim Einreichen zurückgegeben hat. Daraus folgen drei Dinge.

Erstens muss der Zustellbericht irgendwohin gehen können. Ist der Kunde nur als Transmitter gebunden und hat keinen Receiver-Bind offen, hat der Zustellbericht keinen Weg. Legen Sie die Richtlinie im Voraus fest: Transceiver-Binds verlangen, Zustellberichte kurz zurückhalten, bis ein Receiver-Bind erscheint, oder Kunden, die keinen Receiver betreiben können, einen Webhook als Kanal für Zustellberichte anbieten. Zustellberichte still zu verwerfen, ist die eine Option, die als Streitfall zurückkommt.

Zweitens gehört der Zustellbericht Ihnen, bevor er dem Kunden gehört. Ihre Plattform braucht den Zustellbericht des Netzbetreibers, um die Nachricht im Kontobuch abzurechnen, den Status in der Konsole des Kunden anzuzeigen und Ihr eigenes Reporting zur Zustellqualität pro Route zu speisen. Speichern Sie ihn, aktualisieren Sie die Nachricht und leiten Sie ihn dann weiter. Ein Design, das Zustellberichte nur an den Bind durchreicht und nichts behält, hat keine Antwort, wenn der Kunde sagt: „Sie haben mir 4.000 Nachrichten berechnet, die nie angekommen sind.“

Drittens treffen Zustellberichte ungefähr in der Rate ein, in der gesendet wurde, und die Zustellberichte einer Kampagne treffen nach der Kampagne ein. Ein Kunde, der 50.000 Nachrichten in fünf Minuten versendet, erhält in den folgenden zehn Minuten 50.000 deliver_sm-Pakete. Bestätigt sein Receiver-Bind nur langsam, wächst Ihre ausgehende Warteschlange für Zustellberichte; machen Sie daraus eine Warteschlange mit sichtbarer Tiefe statt eines unbegrenzten Puffers und alarmieren Sie nach Alter, damit ein hängender Kunden-Bind auf Ihrem Dashboard auftaucht, bevor der Kunde ein Ticket eröffnet.

Absenderkennungen, Kodierung und was Kunden falsch machen

Ein SMPP-Konto braucht außerdem ein Regelwerk. Welche Quelladressen (Absenderkennungen) darf der Kunde verwenden, alphanumerisch oder numerisch, und schreibt Ihr Server eine unbekannte um oder weist er sie ab? Welche Datenkodierungen (GSM 7-bit gegenüber UCS-2 für nichtlateinische Schriften), und wie werden lange Nachrichten geteilt (UDH-Verkettung, die die Bibliothek des Kunden meist übernimmt, aber nicht immer)? Welche Gültigkeitsdauer und welches Flag für registered delivery verlangen Sie, damit Zustellberichte überhaupt angefordert werden?

Diese Regeln sollten am Konto hinterlegt sein und beim Einreichen durchgesetzt werden, mit einem klaren Fehlercode, statt angenommen zu werden und dann beim Netzbetreiber still zu scheitern. So wie eine gute HTTP-API einen 400 mit Begründung zurückgibt, weist ein guter SMPP-Server das submit_sm mit dem richtigen Status ab und lässt den Kunden seine Seite korrigieren. Jede Regel, die Sie am Eingang Ihrer Plattform durchsetzen, ist ein Streitfall, den Sie später nicht haben.

Abrechnung pro Bind: das Konto führt das Kontobuch

Das ist der Teil, der schiefgeht, wenn der SMPP-Server neben die Plattform geschraubt wird, statt in sie eingebaut zu sein. Eine Nachricht, die über SMPP hereinkommt, muss genau so bepreist und abgebucht werden wie eine Nachricht aus der Konsole oder der HTTP-API: derselbe Preisplan, dasselbe Guthaben, dieselbe Marge, verbucht auf dieselbe Route. Die drei Abrechnungsmodi aus dem Leitfaden zur Abrechnung (CreditRoute, WalletRoute und AutoRoute) gelten für das Konto, und der Bind erbt sie. Erreicht das Guthaben null, muss der SMPP-Server das submit mit einem passenden Fehler abweisen, statt Traffic in eine Warteschlange aufzunehmen, die nie bezahlt wird.

Ein SMPP-Bind ist eine Tür in das Konto des Kunden, kein separates Konto. Wenn das Kontobuch die Tür nicht sieht, ist die Tür ein Leck.

Wo SMPP sich tatsächlich eine eigene kommerzielle Zeile verdient, ist das Paket rund um den Bind: eine monatliche Mindestabnahme im Tausch gegen eine höhere Durchsatzobergrenze, eine Gebühr pro zusätzlicher Sitzung, ein Aufpreis für eine dedizierte Route oder eine Kurzwahlnummer. Bepreisen Sie diese als Kontobedingungen, damit das Kontobuch Gebühr und Traffic auf demselben Kontoauszug verbucht und damit ein Kunde, der von HTTP zu SMPP wechselt, eine Rechnung mit einer zusätzlichen Zeile sieht und keine neue Geschäftsbeziehung.

Kunden-Onboarding: das Paket mit den Zugangsdaten

Wenn ein Kunde für SMPP freigegeben ist, senden Sie ein einziges Dokument, und zwar jedes Mal dasselbe:

1. Host, Port und die TLS-Erwartung, falls Sie TLS vor dem SMPP-Server terminieren.
2. system_id und Passwort (über einen anderen Kanal zugestellt als die E-Mail mit dem Rest).
3. Erlaubte Bind-Modi und die Höchstzahl an Sitzungen.
4. Die IP-Adressen, von denen Sie Binds annehmen, und wie man sie ändert.
5. Durchsatzobergrenze in msg/s, Fenstergröße, enquire_link-Intervall.
6. Erlaubte Absenderkennungen, Kodierungsregeln, Behandlung langer Nachrichten, erforderliches Flag für registered delivery.
7. Wohin Zustellberichte gehen und welche Fehlercodes der Kunde erwarten und behandeln sollte.
8. Die Testroute und die Testnummern, die vor dem Go-live zu verwenden sind.

Die Hälfte davon sind Zahlen, die der Techniker des Kunden in der nächsten Stunde in eine Konfigurationsdatei tippt. Sie alle auf einmal zu liefern, ist der Unterschied zwischen einer Integration an einem Tag und einem E-Mail-Wechsel über zwei Wochen.

Tests vor dem Go-live

Schalten Sie das SMPP-Konto eines Kunden nie gegen Live-Routen frei. Stellen Sie eine Testroute bereit, die Nachrichten annimmt, nach kurzer Verzögerung einen plausiblen Zustellbericht erzeugt und nichts berechnet, und gehen Sie mit dem Kunden darauf sechs Prüfungen durch: ein Bind in jedem erlaubten Modus, eine einzelne Nachricht und ihr per ID zugeordneter Zustellbericht, eine lange Nachricht in einer nichtlateinischen Schrift, die auf einem echten Endgerät als eine Nachricht ankommt, ein Schub oberhalb der Durchsatzobergrenze, der Drosselungsfehler und ein korrektes Zurückfahren auslöst, eine absichtlich falsche Absenderkennung, die die erwartete Abweisung auslöst, und eine getrennte Verbindung, gefolgt von einem sauberen Neuaufbau. Erst dann stellen Sie das Konto auf seine Live-Routen um, und zwar mit weiterhin aktiver Obergrenze.

Dieselbe Testroute nutzen Sie später, um ein Problem eines Kunden nachzustellen. Ein Kunde, der sagt „die Zustellberichte kommen nicht mehr“, kann sich an die Testroute binden, eine Nachricht senden und in der Konsole zusehen, wie der Zustellbericht zurückkommt, und aus einem vagen Ticket wird eine zehnminütige Prüfung seines Receiver-Binds.

Wann ein Kunde kein SMPP bekommen sollte

Nicht jeder Kunde, der nach SMPP fragt, sollte es bekommen. Ein Marketingteam, das aus dem Browser sendet, hat keine Verwendung für einen Bind; ein Entwickler, der 300 OTPs am Tag sendet, ist mit der HTTP-API besser bedient, die keine persistente Sitzung braucht und Fehler zurückgibt, die er lesen kann. SMPP ist für Kunden mit Volumen, mit einem vorhandenen SMPP-Stack oder mit einem Compliance-Grund, eine direkte Protokollbeziehung zu unterhalten. Alle anderen bekommen die API, und Ihre Support-Warteschlange wird dadurch leichter.

Glaubwürdig wird das Angebot dadurch, dass darunter dieselbe Plattform liegt, und bei einer selbst gehosteten Lizenz ist der SMPP-Server enthalten, statt als separate Stufe verkauft zu werden. Ein Kunde, der mit der HTTP-API beginnt und in einen SMPP-Bind hineinwächst, behält sein Konto, sein Guthaben, seinen Preisplan und sein Reporting; der Bind ist ein weiterer Kanal in ein Omnichannel-Konto, das auf demselben Kontobuch auch seinen WhatsApp- und RCS-Traffic tragen kann. Diese Kontinuität kann ein Reseller, der ein Panel mietet, meist nicht bieten, und sie ist der leise Grund, warum technische Kunden bleiben.