Free developer tool · Protocol
SMPP session simulator.
Step through a real SMPP 3.4 conversation — the PDUs an ESME and an SMSC actually exchange, byte by byte. Select any PDU to see its fields mapped onto the octets on the wire.
This never sends a message
Everything on this page is computed in your browser. There is no socket, no request to BroadNet or anyone else, and no message of any kind is submitted to any network. Message IDs and timestamps are derived from your inputs, so the same inputs always produce the same output — they are illustrative, not real.
not bound
wire — ESME ⇄ SMSC0 PDU
ESMESMSC
Nothing on the wire yet. Run the session to watch the PDUs an ESME and an SMSC exchange, then select any one of them to see its bytes.
How an SMPP session actually runs
- 1 · Bind. Your application opens a TCP connection to the SMSC and sends bind_transceiver with a system_id and password. Until the SMSC answers with command_status 0, nothing else is accepted.
- 2 · Submit. Each message is a submit_sm PDU. The reply gives you a message_id — that is an acceptance, not a delivery.
- 3 · Receipt. If you asked for one, the SMSC later pushes a deliver_sm carrying esm_class 0x04 and a receipt body referencing that message_id.
- 4 · Keep alive. enquire_link every 30–60 seconds proves the socket is still usable. Miss it and the SMSC drops you.
- 5 · Unbind. Close politely so the operator does not count it as an abnormal disconnect.
Questions engineers ask
- Does this simulator send a real SMS?
- No. Nothing on the page opens a connection or submits a message anywhere. Every PDU and every SMSC reply is computed in your browser from the values you type, so the same inputs always produce the same transcript. It is a teaching tool for the protocol, not a sending tool.
- What is a bind in SMPP?
- A bind is the session handshake between an ESME (your application) and the SMSC (the operator's message centre). bind_transmitter can only send, bind_receiver can only receive, and bind_transceiver does both over one connection — which is what most integrations use. Nothing else is accepted on the session until the bind succeeds.
- What does registered_delivery do?
- Setting registered_delivery to 1 asks the SMSC to confirm the final outcome. That confirmation arrives later as a separate deliver_sm PDU carrying esm_class 0x04 — the delivery receipt — which references the message_id you were given in submit_sm_resp. Without it you learn only that the SMSC accepted the message, not that a handset received it.
- Why does my message split into several segments?
- A single SMS PDU carries 160 characters in the GSM-7 alphabet or 70 in UCS-2. Longer text is concatenated: each part gives up 6 octets to a user-data header so the handset can reassemble them, leaving 153 or 67 characters per segment. One Arabic character or one emoji forces the whole message to UCS-2, which is why a 100-character Arabic message costs two segments.
- What is the difference between submit_sm_resp and a delivery receipt?
- submit_sm_resp is synchronous and only means the SMSC accepted the PDU and assigned it a message_id. The delivery receipt arrives asynchronously, often seconds or minutes later, and reports the real outcome — DELIVRD, UNDELIV, EXPIRED, REJECTD. Treating submit_sm_resp as proof of delivery is the most common mistake in a first SMPP integration.
- What is an SMPP window and why does it cap my throughput?
- The window is how many PDUs you may have submitted but unacknowledged on one bind at any moment. Because SMPP is asynchronous you do not wait for each submit_sm_resp before sending the next — but the window bounds how far ahead you may run. Left at a default of 1 the bind degrades to request/response and your throughput collapses to one message per round trip, regardless of the rate the operator agreed.