SMPP (Short Message Peer-to-Peer) is an open, binary, TCP-based protocol for exchanging SMS between an external application (ESME) and a Short Message Service Centre (SMSC). It is the standard interface for high-throughput A2P messaging because it is stateful, low-latency and supports delivery receipts natively.
bind_transceiverOpen and authenticate the sessionbind_transceiver_respSession acceptedsubmit_smSend a messagesubmit_sm_respAccepted, message ID returneddeliver_smDelivery receipt or inbound messagedeliver_sm_respAcknowledgedenquire_linkKeepalive while idle
What SMPP is and why it exists
SMPP is a level-7 application protocol that lets a message application exchange short messages with an SMSC or routing gateway. Where a REST API is convenient for low volumes, SMPP is a persistent binary session that avoids per-message HTTP overhead, sustains thousands of messages per second on a single connection, and carries submit, delivery, query, replace and cancel operations plus asynchronous delivery receipts. It is protocol-agnostic about the underlying network — the SMSC handles SS7/MAP, SIGTRAN or IP delivery to the handset. First published by Aldiscon/Logica in the late 1990s, it is now maintained by the SMPP Developers Forum; v3.4 (1999) remains the most widely deployed version.
The ESME and the SMSC
The two peers are the ESME (External Short Message Entity — your application) and the SMSC (Short Message Service Centre — the operator or aggregator gateway). The ESME opens a TCP connection to the SMSC's listening port (IANA-registered 2775 for plaintext) and authenticates with a bind. Despite the 'peer-to-peer' name, the relationship is typically client (ESME) to server (SMSC); either side can originate PDUs once the session is bound, which is how the SMSC pushes mobile-originated messages and delivery receipts back to the ESME.
| Term | Meaning |
|---|---|
| ESME | External Short Message Entity — the connecting application (your sender) |
| SMSC | Short Message Service Centre — the operator/aggregator gateway |
| MC | Message Centre — the v5.0 term that generalises SMSC |
| MT | Mobile-Terminated — a message delivered to a handset |
| MO | Mobile-Originated — a message sent from a handset to the ESME |
Session model and transport
SMPP runs over a single long-lived TCP connection. After the TCP handshake the ESME sends a bind PDU; on a successful bind_resp the session enters a bound state and stays open indefinitely, kept alive with periodic enquire_link PDUs. Operations are request/response pairs correlated by sequence_number, and multiple requests can be outstanding at once (windowed / asynchronous mode) up to a negotiated window size. The session ends with an unbind exchange or a TCP close. SMPP has no built-in encryption; confidentiality is added by running the session over TLS.
Versions: v3.3, v3.4 and v5.0
Three versions matter in practice. v3.3 is legacy and rarely used. v3.4 introduced the transceiver bind and optional TLV parameters and is the de-facto industry standard today. v5.0 is backward compatible with v3.4 and adds congestion-control signalling, broadcast operations and extra message states, but is less widely deployed. The negotiated version is carried in the bind's interface_version field: 0x34 for v3.4 and 0x50 for v5.0.
| Value | Version |
|---|---|
| 0x33 or lower | SMPP v3.3 or earlier |
| 0x34 | SMPP v3.4 |
| 0x50 | SMPP v5.0 |
Frequently asked
Is SMPP still used in 2026?
Yes. SMPP remains the dominant protocol for high-volume A2P SMS between applications, aggregators and operator SMSCs. REST APIs sit on top of SMPP for convenience, but the carrier-facing interconnect is almost always SMPP over TCP, usually secured with TLS.
What port does SMPP use?
The IANA-registered default is TCP port 2775 for plaintext SMPP. There is no single standardised TLS port, so providers expose a separate TLS-enabled port (for example 3550 or a per-account port) for encrypted binds. Always use the port your provider provisions.
What is the difference between SMPP and SMTP?
They are unrelated. SMTP moves email; SMPP moves SMS between applications and an SMSC. The similar acronyms cause confusion, but the protocols share no design, ports or message format.
Do I need SMPP or is a REST SMS API enough?
A REST API is simpler and fine for low to moderate volumes and quick integration. SMPP earns its keep at high throughput, where a persistent binary session gives lower latency, higher sustained TPS and native, real-time delivery receipts on the same connection.
Source specifications
The published standards this page is grounded in. Opens in a new tab.