Everything worth knowing, nothing that isn't.
Why 3.4 won the install base
SMPP 3.4 shipped at the same moment SMS A2P took off. Every major SMSC vendor built deep, stable 3.4 implementations. The protocol is small (about 30 PDU types, eight commands you ever send), well-understood, and survives every NAT and firewall in the path. Twenty-seven years later, the SMPP 3.4 specification is still the protocol pinned at the top of every A2P interconnect contract.
What 5.0 added
SMPP 5.0 cleaned up several rough edges: native UTF-8 message_payload, a proper service_type registry, broadcast_sm / query_broadcast_sm / cancel_broadcast_sm for cell broadcast, optional billing TLVs, and tighter congestion control with congestion_state. It also introduced the concept of message_state machines that the SMSC can drive on behalf of the ESME.
Why almost nobody runs 5.0
Three reasons. First, SMSC vendors didn't get paid to upgrade — operators already had working 3.4 stacks. Second, the cell-broadcast use case 5.0 targeted went to dedicated cell broadcast centres (CBCs), not SMSCs. Third, the things 5.0 fixed (Unicode handling, billing TLVs) are usually solved at the application layer with TLVs on top of 3.4. The result: at BroadNet we have one 5.0 bind in production. We have over 1,000 active 3.4 binds.
Practical advice
Bind as a transceiver over SMPP 3.4, with TLS on the port provided with your account. Use submit_sm with message_payload TLV for long messages (instead of UDH concatenation) when the receiving SMSC supports it. Negotiate enquire_link every 30 seconds, unbind cleanly. If your aggregator forces 5.0, ask why — there is no deliverability benefit on commercial A2P routes.
SMPP 3.4 vs SMPP 5.0 at a glance
| SMPP 3.4 | SMPP 5.0 | |
|---|---|---|
| Released | 1999 | 2003 |
| Production install base | Nearly every A2P bind | Rare — seldom deployed |
| Native Unicode header | — | |
| Cell / broadcast support | — | |
| Congestion control | Basic | congestion_state signalling |
| Deliverability benefit | Baseline | None on commercial A2P routes |
| Recommended today | Yes — transceiver over TLS | Only if a counterparty requires it |