SMPP Bind Types Explained: Transmitter, Receiver and Transceiver
A practical guide to the three SMPP bind types, the PDUs each one allows, and how to choose between TX, RX and TRX connections.
Every SMPP response PDU carries a command_status field in its header. 0x00000000 (ESME_ROK) means success; anything else is an error that your client has to understand. Treating all errors the same way, for example retrying forever, is a common source of duplicate SMS and stuck queues.
Where the error appears
- In
bind_*_resp: the session was not established. - In
submit_sm_resp: this one message was refused, the session stays open. - In
generic_nack: the SMSC could not even parse the request. - In the
errfield of a delivery receipt: a network-specific code, not acommand_status(see delivery receipts).
Common command_status values
| Code | Name | Typical meaning | Retry? |
|---|---|---|---|
| 0x01 | ESME_RINVMSGLEN | Message length is invalid | No, fix the message |
| 0x03 | ESME_RINVCMDID | Command ID not recognised | No |
| 0x04 | ESME_RINVBNDSTS | Command not allowed in this bind state, for example submit_sm on an RX session | No, fix the bind type |
| 0x05 | ESME_RALYBND | Already bound | No |
| 0x08 | ESME_RSYSERR | System error on the SMSC | Yes, with backoff |
| 0x0A | ESME_RINVSRCADR | Invalid source address | No |
| 0x0B | ESME_RINVDSTADR | Invalid destination address | No |
| 0x0D | ESME_RBINDFAIL | Bind failed | Check credentials first |
| 0x0E | ESME_RINVPASWD | Invalid password | No |
| 0x0F | ESME_RINVSYSID | Invalid system_id | No |
| 0x14 | ESME_RMSGQFUL | Message queue full | Yes, slow down |
| 0x45 | ESME_RSUBMITFAIL | submit_sm failed | Maybe, with limits |
| 0x58 | ESME_RTHROTTLED | You are sending faster than allowed | Yes, reduce the rate |
| 0xFE | ESME_RDELIVERYFAILURE | Delivery failure | Depends on your policy |
| 0xFF | ESME_RUNKNOWNERR | Unknown error | Maybe, with limits |
The full list is in the SMPP v3.4 specification. Real providers also add their own vendor-specific values, so always log the numeric code and not only the name.
Permanent versus temporary errors
Split errors into two groups and handle them differently:
- Permanent (invalid address, invalid length, wrong bind state): retrying cannot succeed. Mark the message failed and surface the error.
- Temporary (throttled, queue full, system error): retry with exponential backoff and a maximum number of attempts.
For ESME_RTHROTTLED in particular, lower your send rate or shrink the window of outstanding requests instead of just retrying faster.
Test the handling, not just the happy path
Unit tests that mock a response cover your parser but not the real session behaviour: windowing, timeouts and reconnect logic all interact with errors. A bind with a wrong password is easy to reproduce against the sandbox, and so is a message that ends as Not Delivered or Rejected through a delivery scheme. For load behaviour, higher plans let you push volume through the sandbox and watch how your client reacts when it is throttled or its queue fills.
Want to try this against a real SMPP endpoint? Register for the sandbox and use it free for 3 days, or tell us about your scenario.