SMS Simulator Online: Simulate SMS Delivery Without Real Handsets
What SMS simulation is, when an online SMS simulator saves time and money, and what a good simulator should let you control.
Any application that sends SMS through an operator or an aggregator talks to an SMSC (Short Message Service Center) using a protocol, most often SMPP. Before that application goes live you need to know how it behaves when the SMSC accepts a message, rejects it, delays it or never confirms delivery. An SMPP test tool gives you a safe SMSC to test against.
What is an SMPP test tool?
An SMPP test tool is a piece of software that speaks the SMPP protocol, either as a server (an SMSC simulator) or as a client (an SMPP tester that sends messages to a real SMSC). In this article we focus on the server side: a simulator that your SMPP client connects to as if it were a real operator connection, but where nothing is delivered to a phone.
This is what makes SMPP testing cheap and repeatable. Messages stay inside the simulator, so there is no delivery cost, no risk of texting real people, and you can trigger any outcome on demand.
Why not test against a live SMSC?
- Cost. Every load test or regression run would generate billable traffic.
- Uncontrollable results. You cannot ask a real operator to return EXPIRED for the next 10% of your messages.
- Risk. A bug in a retry loop can send thousands of real messages to real subscribers.
- Access. Operators often limit test accounts, sender IDs and destinations.
What to check when testing an SMPP client
| Area | What to verify |
|---|---|
| Bind and authentication | Correct system_id and password succeed; wrong ones return a bind error such as ESME_RINVPASWD (0x0E); a second bind is handled when the session is already bound. |
| Keep-alive | Your client sends enquire_link and reconnects if it gets no enquire_link_resp. |
| Submitting messages | submit_sm is accepted, and the message_id from submit_sm_resp is stored. |
| Error handling | Non-zero command_status values such as ESME_RTHROTTLED (0x58) trigger the right retry or fail path. |
| Delivery reports | A deliver_sm receipt is matched to the original message by id, for every final status. |
| Encoding | GSM 7-bit text and UCS2 (Unicode) text are encoded with the right data_coding. |
| Long messages | Messages above 160 GSM 7-bit characters (or 70 UCS2 characters) are split into parts of 153 (or 67) characters, or sent as one message with a message_payload TLV. |
| Throughput | Your client respects the speed limit and copes with throttling. |
A basic SMPP client test flow
A minimal end-to-end test covers the full life cycle of a message:
client -> bind_transceiver (system_id, password, interface_version=0x34)
server -> bind_transceiver_resp (command_status=0)
client -> submit_sm (destination, short_message, registered_delivery=1)
server -> submit_sm_resp (message_id)
server -> deliver_sm (esm_class=0x04, receipt text with stat:DELIVRD)
client -> deliver_sm_resp
client -> unbindThen repeat the same flow with each outcome your business logic cares about: delivered, undeliverable, expired, and no report at all. A good simulator lets you choose those outcomes with percentages, so one test batch exercises every path.
Choosing an SMPP test tool
When you compare tools, check these points:
- Which SMPP version is supported (v3.4 is the common baseline) and which bind types: transmitter, receiver and transceiver.
- Whether you can control delivery report statuses and the delay before the report is sent.
- Support for multipart messages and both GSM 7-bit and UCS2 encodings.
- Visibility: can you see the message queue, the report queue and statistics while the test runs?
- Whether it works for teams: several client accounts, each with its own credentials.
- Setup effort. A hosted simulator with a web panel saves you from installing and maintaining your own SMSC just for testing.
SMSC testing with Maxi
Maxi is a web-based SMPP SMSC simulator. It supports SMPP v3.4, REST API and API connections, and TX, RX and TRX connections on a single SMPP port (4444). In the web panel you create an account for each client, add SMPP credentials (login and password) and the IP address the client connects from, and then define a delivery report scheme: the percentage of messages that should end up Delivered, Not Delivered, Expired or Pending, and how many seconds pass before the report is sent.
The simulator returns a positive response with a message_id in UUID format, supports multipart SMS and both GSM 7-bit and UCS2 character sets, and shows live queues and statistics in the panel. New users get 3 free days to try it. See how to configure it, how to register, or contact us with questions about your test scenario.