What is SMPP: A Complete Guide to the SMS Protocol

Understanding SMPP: Core Concepts and Versions

SMPP is a specialized, stateful protocol that enables high-speed, two-way SMS message exchange between an application and a mobile network's SMSC.

At its core, SMPP facilitates communication between an External Short Message Entity (ESME) and a Short Message Service Center (SMSC). Think of the ESME as your application or platform that needs to send or receive SMS. The SMSC is the network component, operated by a mobile carrier or an SMS aggregator, that handles the routing and delivery of these messages to a mobile phone.

• High Throughput: Capable of handling thousands of messages per second.
• Low Latency: Persistent connection minimizes per-message delay.
• Reliable Delivery: Includes mechanisms for confirming message delivery status.
• Two-Way Communication: Natively supports both sending (Mobile Terminated) and receiving (Mobile Originated) messages.
• Stateful Connection: The connection between the ESME and SMSC remains active, eliminating repetitive setup and authentication.

Binds and PDUs: The Language of SMPP

An SMPP session is established using a 'bind' command, after which 'Protocol Data Units' (PDUs) are exchanged to send messages, receive messages, and manage the connection.

Before any messages can be exchanged, your application (the ESME) must establish a session with the SMSC. This process is called 'binding'. The bind request includes your credentials (system_id and password) and specifies the type of connection you want. There are three primary bind modes:

• bind_transmitter (TX): A send-only connection. Your application can submit messages but cannot receive them.
• bind_receiver (RX): A receive-only connection. Your application can receive incoming SMS and delivery receipts but cannot submit messages.
• bind_transceiver (TRX): A two-way connection that combines TX and RX modes. Your application can send and receive messages over a single, efficient session.

Confirming Success: Delivery Receipts (DLRs) in SMPP

A Delivery Receipt (DLR) is a special type of message sent back over the SMPP connection to confirm the final delivery status of a message you sent.

Sending a message is only half the battle; knowing it was delivered is crucial for many applications, especially for transactional alerts like one-time passwords or shipping notifications. SMPP has a built-in, highly reliable mechanism for this called Delivery Receipts (DLRs).

• registered_delivery: The flag in the `submit_sm` PDU that requests a DLR.
• message_id: The unique identifier that links an outbound message to its eventual DLR.
• deliver_sm: The PDU used by the SMSC to send both incoming messages and DLRs to your application.
• message_state: A field within the DLR that provides the final status of the message.

High-Throughput and Secure Messaging: Windowing and TLS

SMPP uses 'windowing' to achieve high throughput by sending multiple messages without waiting for individual responses, and it can be secured using Transport Layer Security (TLS).

To achieve its industry-leading throughput, SMPP relies on a concept called 'windowing,' or asynchronous communication. In a simple synchronous mode, you would send one `submit_sm`, wait for the `submit_sm_resp`, and only then send the next message. This creates a bottleneck. With windowing, your application can send a batch of messages (e.g., 10, 50, or more) simultaneously without waiting for individual responses for each one. The SMSC processes them and sends back responses as it's ready. This parallel processing dramatically increases the number of messages you can send per second.

• Windowing: Sending multiple PDUs before receiving their corresponding responses to maximize throughput.
• Asynchronous Communication: The core principle behind windowing that decouples sending from receiving acknowledgements.
• Throughput: The number of messages per second an SMPP connection can handle, greatly increased by windowing.
• TLS (Transport Layer Security): The standard encryption protocol used to secure the SMPP connection and protect all data in transit.

SMPP vs. HTTP REST API: A Technical Comparison

The primary difference is that SMPP is a stateful, persistent binary protocol for high-volume messaging, while HTTP is a stateless, transactional text-based protocol better suited for simpler integrations and lower volumes.

While SMPP is the backbone of the SMS industry, many providers also offer an HTTP REST API for sending texts. The two are designed for very different use cases and have distinct technical characteristics. SMPP's stateful nature means the connection is established once and held open, making subsequent message sends extremely fast as there's no connection setup or authentication overhead. Its binary format is also highly compact and efficient, further contributing to low latency.

• Protocol: SMPP is binary over TCP; HTTP is text-based (usually JSON) over TCP.
• Connection: SMPP is persistent and stateful; HTTP is transactional and stateless.
• Throughput: SMPP is significantly higher due to its persistent connection, low overhead, and support for windowing.
• Complexity: SMPP requires specialized client libraries and connection management; HTTP is simple to use with standard web development tools.
• Use Case: SMPP is built for carriers and large-scale A2P services; HTTP is for web apps and general-purpose integrations.

Choosing Your Protocol: The TextVolley Approach

Choose SMPP for high-volume, low-latency applications requiring real-time delivery status, and use an HTTP API for easier integration, web applications, and moderate traffic volumes.

Deciding between SMPP and an HTTP API depends entirely on your specific needs for volume, speed, and development resources. If you are a service provider, an aggregator, or a large enterprise sending millions of messages per month for time-sensitive applications like two-factor authentication (2FA), critical alerts, or large-scale notifications, SMPP is the superior choice. Its low latency and high throughput are unmatched.

• Use SMPP if... You send over 50 messages per second, require the lowest possible latency, need scalable two-way messaging, and have development resources to manage a persistent connection.
• Use an HTTP API if... Your volume is lower, speed of development is a priority, you're integrating into a standard web stack, and millisecond latency differences are not critical to your application.

FAQ