SMPP v5.0 is backward compatible with v3.4 and adds congestion-control signalling, broadcast messaging operations (broadcast_sm and friends), an extra message state (SKIPPED) and additional TLVs. Despite this, v3.4 remains the dominant interconnect because it is universally supported; v5.0 is used only where both peers implement it.
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 v5.0 adds
v5.0 is an incremental, backward-compatible revision of v3.4. Its headline additions are congestion control (the SMSC advertises load so ESMEs can slow down before being throttled), a family of broadcast operations for cell-broadcast-style messaging, a new SKIPPED message state, and extra optional parameters. The core PDU format, the bind model and submit_sm/deliver_sm are unchanged, which is why an v3.4 ESME can talk to a v5.0 SMSC.
| Area | v3.4 | v5.0 addition |
|---|---|---|
| Congestion control | None (react to throttling) | congestion_state TLV — proactive |
| Broadcast | Not supported | broadcast_sm / query_broadcast_sm / cancel_broadcast_sm |
| Message states | 8 states | Adds SKIPPED (9) |
| Optional params | v3.4 TLV set | Additional TLVs |
| interface_version | 0x34 | 0x50 |
What stayed the same
The fundamentals are identical: the 16-byte header, big-endian encoding, the three bind types, session states, enquire_link keepalive, submit_sm/deliver_sm field layouts and the ESME_R* error range all carry over. TLVs — introduced in v3.4 — remain the extension mechanism. This continuity is deliberate: v5.0 was designed so existing v3.4 integrations keep working.
Which version to use
Use v3.4 unless you have a concrete reason to use v5.0 and both peers support it. v3.4 is the safe, universal default for A2P interconnect. Reach for v5.0 when you specifically need its congestion signalling or broadcast operations and the provider confirms support. Always confirm the negotiated version from the bind_resp (the sc_interface_version TLV) rather than assuming a feature is available.
Frequently asked
Is SMPP v5.0 backward compatible with v3.4?
Yes. v5.0 preserves the v3.4 PDU format, bind model and core operations, so a v3.4 ESME and a v5.0 SMSC can interoperate. The version is declared in interface_version (0x34 vs 0x50).
Why is SMPP v3.4 still the most common version?
Because it is universally implemented and covers the needs of A2P messaging completely. v5.0's additions — congestion control, broadcast — are useful in specific scenarios but not required for standard MT/MO traffic, so most interconnects stayed on v3.4.
What is the main practical benefit of v5.0?
Proactive congestion control: the congestion_state TLV lets the SMSC advertise its load so a cooperative ESME slows down before hitting hard ESME_RTHROTTLED errors, giving smoother throughput under pressure.
How do I know which version a session negotiated?
Read the sc_interface_version TLV returned in the bind_resp. Do not assume v5.0 features are available just because you sent interface_version 0x50 — the SMSC reports what it actually supports.
Source specifications
The published standards this page is grounded in. Opens in a new tab.