SMPP (Short Message Peer-to-Peer) is the telecom industry protocol used to exchange SMS between applications, SMS gateways, aggregators and operator SMSCs. It runs over a persistent TCP connection, called a bind, and carries messages, delivery reports and inbound replies in compact binary packets called PDUs. Version 3.4 is the one most routes use.
What is SMPP?
The SMPP protocol is an open standard, first developed in the 1990s, for submitting and delivering short messages outside the mobile network's own signalling. It defines two roles: the ESME (External Short Messaging Entity), which is the client, such as your platform or gateway; and the SMSC (Short Message Service Center), which is the server, such as an operator's or aggregator's messaging centre. Almost every wholesale A2P SMS route is delivered over SMPP. Version 3.4 is the de facto standard; version 5.0 exists but is far less common.
How does SMPP work?
The client opens a TCP connection to the server (port 2775 is the common default), authenticates with a system ID and password, and keeps the session open. Messages, delivery receipts and keep-alive packets then flow in both directions over that bind until one side closes it.
- Bind. The client sends a bind request with its credentials and the bind type.
- Submit. Each message goes out as a
submit_smPDU with source address (sender ID), destination number, data coding and text. The server answers withsubmit_sm_respcontaining a message ID or an error code. - Deliver. Delivery receipts and mobile-originated replies come back as
deliver_smPDUs, which the client acknowledges. - Keep-alive.
enquire_linkPDUs every 30 to 60 seconds keep the session healthy and detect dead links. - Unbind. Either side closes the session cleanly with
unbind.
Error codes in responses (for example invalid destination or throttling) are listed in SMPP error codes, and delivery receipt states in SMS DLR status codes.
What are SMPP bind types?
| Bind type | Direction | Typical use |
|---|---|---|
| Transmitter (TX) | Client sends messages only | Separate sending connections |
| Receiver (RX) | Client receives DLRs and replies only | Separate receiving connections |
| Transceiver (TRX) | Both directions on one connection | The most common setup on modern routes |
Providers limit the number of binds per account and the messages per second (TPS) per bind. See SMPP binds and TPS.
What is an SMPP server?
An SMPP server is the side that accepts binds: an operator SMSC, an aggregator's platform, or a gateway that resells routes to its own customers. A reseller often runs both roles: an SMPP server for its clients and SMPP client connections to its upstream routes. Gateway software such as Kannel and Jasmin can play these roles. Tools to test either side are covered in SMPP client and server tools.
SMPP in telecom: what is it used for?
- Connecting A2P platforms and CPaaS providers to aggregators and operators.
- Carrier-to-carrier SMS interconnects in wholesale.
- High-volume senders (banks, OTP providers) that need throughput and fast receipts.
- Receiving inbound SMS on short codes and long numbers.
See what is an A2P SMS aggregator for where SMPP sits in the chain.
SMPP vs HTTP API
SMPP keeps one connection open and pipelines messages, so it handles high volume with low overhead and returns receipts in real time. An HTTP API is easier to integrate (one request per message, webhooks for reports) and fits apps with moderate volume. Resellers and platforms usually choose SMPP; product teams usually start with HTTP. Full comparison: SMPP vs HTTP SMS and what is an SMS API.
Key SMPP parameters to get right
- Source address TON/NPI: tells the server whether the sender is alphanumeric, international or national.
- data_coding: 0 for the default GSM alphabet on most routes, 8 for UCS-2 (Unicode). See GSM-7 vs Unicode.
- registered_delivery: must be set to request delivery receipts.
- Long messages: sent with a UDH or SAR parameters. See concatenated long SMS.
- Security: SMPP 3.4 has no built-in encryption, so connections usually run over a VPN, IP whitelisting or a TLS tunnel.
Getting SMPP routes
VoIPMatcher sources A2P SMS routes over SMPP from its carriers and manages them, with binds and TPS sized to your traffic. Request an SMPP route.
Frequently asked questions
What port does SMPP use?
SMPP runs over TCP, and port 2775 is the commonly used default. In practice, each provider gives you its own host, port, system ID and password, and the port may differ. Connections are usually restricted by IP whitelisting, and because SMPP 3.4 has no built-in encryption, many links run over a VPN or TLS tunnel.
What is the difference between SMPP 3.4 and SMPP 5.0?
SMPP 3.4 is the version almost every SMS route uses. SMPP 5.0 added features such as broadcast messaging, congestion control information and more optional parameters, but adoption stayed limited. When a provider says SMPP without a version, assume 3.4, and confirm details such as TLV support and receipt format before integrating.
Is SMPP secure?
Not by itself. SMPP 3.4 sends credentials and message content without encryption, so it should run over a VPN, a TLS tunnel or at least a private connection with strict IP whitelisting. Use strong, unique passwords per bind and restrict each account to the source addresses and destinations it needs.
What is an ESME in SMPP?
ESME stands for External Short Messaging Entity: the client side of an SMPP connection. It is the application, platform or gateway that binds to an SMSC or SMPP server to submit messages and receive delivery receipts. A reseller platform acts as an SMSC to its customers and as an ESME toward its upstream routes.
Do I need SMPP to send SMS?
No. Most applications send SMS through an HTTP API, which is simpler to integrate. SMPP is preferred when you send high volume, need low latency receipts, resell routes to other customers or connect directly with carriers and aggregators. Many providers offer both, so you can start with HTTP and move to SMPP later.
Need a route?
Send the destination, route type and target rate. We reply with what we can deliver.