SMPP (Short Message Peer-to-Peer) ist ein offenes, binäres, TCP-basiertes Protokoll für den SMS-Austausch zwischen einer externen Anwendung (ESME) und einem Short Message Service Centre (SMSC). Es ist die Standardschnittstelle für A2P-Messaging mit hohem Durchsatz, weil es zustandsbehaftet und latenzarm ist und Zustellberichte nativ unterstützt.
bind_transceiverSitzung öffnen und authentifizierenbind_transceiver_respSitzung akzeptiertsubmit_smNachricht sendensubmit_sm_respAkzeptiert, Nachrichten-ID zurückgegebendeliver_smZustellungsbericht oder eingehende Nachrichtdeliver_sm_respBestätigtenquire_linkKeepalive im Leerlauf
Was SMPP ist und warum es existiert
SMPP ist ein Anwendungsprotokoll auf Schicht 7, mit dem eine Messaging-Anwendung Kurznachrichten mit einem SMSC oder Routing-Gateway austauscht. Während sich eine REST-API für geringe Volumina anbietet, ist SMPP eine dauerhafte binäre Sitzung, die den HTTP-Overhead je Nachricht vermeidet, Tausende Nachrichten pro Sekunde über eine einzige Verbindung trägt und Submit-, Zustell-, Query-, Replace- und Cancel-Operationen sowie asynchrone Zustellberichte transportiert. Gegenüber dem darunterliegenden Netz ist es protokollunabhängig — das SMSC übernimmt die Zustellung an das Endgerät über SS7/MAP, SIGTRAN oder IP. Ursprünglich Ende der 1990er-Jahre von Aldiscon/Logica veröffentlicht, wird es heute vom SMPP Developers Forum gepflegt; v3.4 (1999) bleibt die am weitesten verbreitete Version.
Die ESME und das SMSC
Die beiden Gegenstellen sind die ESME (External Short Message Entity — Ihre Anwendung) und das SMSC (Short Message Service Centre — das Gateway des Betreibers oder Aggregators). Die ESME öffnet eine TCP-Verbindung zum Listening-Port des SMSC (IANA-registriert 2775 für Klartext) und authentifiziert sich mit einem Bind. Trotz des Namens „Peer-to-Peer" ist die Beziehung typischerweise die zwischen Client (ESME) und Server (SMSC); sobald die Sitzung gebunden ist, kann jede Seite PDUs initiieren — so schiebt das SMSC mobil-originierte Nachrichten und Zustellberichte zurück an die ESME.
| Begriff | Bedeutung |
|---|---|
| ESME | External Short Message Entity – die sich verbindende Anwendung (Ihr Absender) |
| SMSC | Short Message Service Centre – das Gateway des Betreibers/Aggregators |
| MC | Message Centre – der Begriff aus v5.0, der SMSC verallgemeinert |
| MT | Mobile-Terminated – eine an ein Endgerät zugestellte Nachricht |
| MO | Mobile-Originated – eine vom Endgerät an das ESME gesendete Nachricht |
Sitzungsmodell und Transport
SMPP läuft über eine einzige, langlebige TCP-Verbindung. Nach dem TCP-Handshake sendet die ESME eine Bind-PDU; bei erfolgreichem bind_resp geht die Sitzung in einen gebundenen Zustand über und bleibt unbegrenzt offen, gehalten durch periodische enquire_link-PDUs. Operationen sind Request/Response-Paare, die über die sequence_number korreliert werden, und mehrere Requests können gleichzeitig ausstehen (Windowed-/Async-Modus) bis zur ausgehandelten Fenstergröße. Die Sitzung endet mit einem Unbind-Austausch oder einem TCP-Close. SMPP bietet keine eingebaute Verschlüsselung; Vertraulichkeit wird durch den Betrieb der Sitzung über TLS ergänzt.
Versionen: v3.3, v3.4 und v5.0
In der Praxis sind drei Versionen relevant. v3.3 ist veraltet und wird kaum noch genutzt. v3.4 führte den Transceiver-Bind und optionale TLV-Parameter ein und ist heute der De-facto-Industriestandard. v5.0 ist abwärtskompatibel zu v3.4 und ergänzt Congestion-Control-Signalisierung, Broadcast-Operationen und zusätzliche Nachrichtenzustände, ist aber weniger verbreitet. Die ausgehandelte Version wird im Feld interface_version des Bind übertragen: 0x34 für v3.4 und 0x50 für v5.0.
| Wert | Version |
|---|---|
| 0x33 oder niedriger | SMPP v3.3 oder früher |
| 0x34 | SMPP v3.4 |
| 0x50 | SMPP v5.0 |
Häufig gestellte Fragen
Wird SMPP im Jahr 2026 noch verwendet?
Ja. SMPP bleibt das dominierende Protokoll für A2P-SMS mit hohem Volumen zwischen Anwendungen, Aggregatoren und SMSCs der Betreiber. REST-APIs setzen aus Bequemlichkeit auf SMPP auf, doch die netzbetreiberseitige Kopplung erfolgt fast immer über SMPP über TCP, meist mit TLS abgesichert.
Welchen Port verwendet SMPP?
Der IANA-registrierte Standard ist TCP-Port 2775 für Klartext-SMPP. Es gibt keinen einheitlich standardisierten TLS-Port, daher stellen Anbieter einen separaten TLS-fähigen Port (zum Beispiel 3550 oder einen kontospezifischen Port) für verschlüsselte Binds bereit. Verwenden Sie stets den von Ihrem Anbieter bereitgestellten Port.
Was ist der Unterschied zwischen SMPP und SMTP?
Sie sind nicht verwandt. SMTP transportiert E-Mail; SMPP transportiert SMS zwischen Anwendungen und einem SMSC. Die ähnlichen Akronyme sorgen für Verwirrung, doch die Protokolle teilen weder Design, Ports noch Nachrichtenformat.
Brauche ich SMPP oder genügt eine REST-SMS-API?
Eine REST-API ist einfacher und für geringe bis mittlere Volumina sowie eine schnelle Integration ausreichend. SMPP zahlt sich bei hohem Durchsatz aus, wo eine dauerhafte binäre Sitzung geringere Latenz, höhere anhaltende TPS und native Zustellberichte in Echtzeit über dieselbe Verbindung bietet.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)