SMPP stands for Short Message Peer-to-Peer. It is a binary protocol, not a piece of software — a defined set of rules for how two systems exchange SMS messages over a single, persistent TCP/IP connection. If you have read about SMS gateway software and seen "SMPP" mentioned as the protocol behind high-volume messaging, this page is the deep dive on what that actually means and how it works under the hood.
SMPP matters because it is the reason aggregators, resellers, and enterprises sending large volumes of OTP or transactional SMS can sustain thousands of messages per second without their infrastructure falling over. Understanding it — even at a conceptual level — makes every other decision about SMS gateway software easier.
Every SMPP conversation happens between two named roles. An ESME connects to an SMSC over a plain TCP/IP socket and keeps that connection open for as long as it needs to send or receive traffic — this is the single biggest architectural difference between SMPP and an HTTP-based SMS API, where every message is its own independent, short-lived request.
Before any message can move, the ESME sends a "bind" request to authenticate and open the session. SMPP defines three bind types, and which one you use depends on what the session needs to do.
A send-only session. The ESME can submit messages but cannot receive inbound messages or delivery receipts on this connection.
A receive-only session. The ESME receives inbound messages and delivery receipts but cannot send.
Both directions on a single session. The most common choice for modern integrations — no need to manage two separate connections.
Once bound, an ESME and SMSC exchange PDUs (Protocol Data Units) — structured, binary-encoded messages that each represent one specific action. The ones you will encounter most often:
| PDU | Direction | What it does |
|---|---|---|
| submit_sm | ESME → SMSC | Submits an outbound SMS message for delivery. The SMSC replies with submit_sm_resp, acknowledging receipt and returning a message ID. |
| deliver_sm | SMSC → ESME | Delivers an inbound SMS to the ESME, or delivers a delivery receipt (DLR) reporting the final status of a previously submitted message. |
| enquire_link | Either direction | A lightweight keepalive/heartbeat PDU that confirms the connection is still alive during periods of low traffic. |
| unbind | Either direction | Gracefully closes the session before the underlying TCP connection is dropped. |
Because all of these PDUs travel over the same already-open connection, there is no per-message handshake or connection setup overhead — which is exactly why a single SMPP session can sustain far higher throughput than making a fresh HTTP request for every message. For the full side-by-side comparison, see SMPP vs HTTP API.
Talk to an SMPP Software Specialist about your integration.
Talk to a SpecialistMost businesses only ever need an SMPP client — connecting outward to a carrier or aggregator's SMSC to send their own traffic. But if you are, or want to become, an SMS reseller or aggregator, you also need an SMPP server: the ability to accept bind requests from your own downstream clients, the same way an SMSC accepts binds from you. Running both sides is what turns SMS gateway software into an aggregator/reseller platform rather than a simple sending tool — see SMPP Provider and Rent SMPP Application for that side of the picture.
The number of PDUs an ESME can have outstanding (sent but not yet acknowledged) on a session at once — tuning this affects throughput.
A response an SMSC can send (ESME_RTHROTTLED) when an ESME is submitting faster than the SMSC currently allows.
A unique identifier on every PDU that matches a request to its response, since multiple PDUs can be in flight at once.
Delivery Receipt, delivered via deliver_sm, confirming a message was delivered, failed, or is pending. See SMPP Center's DLR features.
FAQ