Sending from a modem pool is a solved problem. Receiving is where projects stall, because the hard part is not the radio but the matching: deciding which conversation an incoming message belongs to when the only identifying information is a phone number and a timestamp.
This guide covers the receiving half of a modem-based deployment. It sets out the four stages of a two-way exchange, how to match an inbound message to a stored conversation, what changes on the module side when receiving is enabled, and how to handle the opt-out replies that any commercial messaging flow is expected to honour.
What are the four stages of a two-way SMS exchange?
Submit, store, receive, and match.
Each stage can succeed or fail independently, which is why a deployment that sends correctly can still lose every reply.
Submit is the outbound send, and it is well understood. Store is the record you keep of what was sent, to whom, and from which number, and it is the stage that most deployments under-build because it costs something now and only matters later. Receive is the module collecting the inbound message. Match is the association of that inbound message with the stored record, and it is where the design either works or does not.
The matching problem exists because SMS carries no application-level conversation identifier. The recipient replies from their number to your number, and those two values plus a timestamp are what you have. Everything else — which campaign, which order, which case — must be inferred from records you kept at submission time.
That is why the store stage matters so much. A deployment that records what it sent, from which number, and when can match replies reliably. One that does not is reduced to guessing from timestamps, and the guess fails precisely on the days when volume is highest.
How do you match a reply to the right conversation?
Keep a submission record keyed by number pair.
Matching is a lookup against records you control, not an inference from the message itself.
The workable approach has three parts. First, at submission, store the originating number, the destination number, the timestamp, and whatever business identifier the message relates to. Second, at receipt, look up records matching that number pair, most recent first, within a window that reflects how quickly replies normally arrive. Third, where more than one record matches, apply a tie-break rule that you have chosen deliberately rather than one that emerges from query order.
The window is the parameter that needs tuning per deployment. A verification flow receives replies within seconds; a marketing flow may receive them over days. Setting one window for both produces wrong matches in one case and misses in the other. Where flows with different reply behaviour share hardware, store the expected reply window with the submission record rather than applying a global value.
The tie-break rule deserves the same care. When two messages were sent to the same number from the same originating number within the window — a common situation when a reminder follows an original message — the reply could belong to either. Choosing the most recent is usually right, but the choice should be recorded in the design rather than left to the database.
What changes on the module when receiving is enabled?
Storage becomes a resource that has to be managed.
A module that only sends never fills its message store; one that receives does, and the behaviour when it fills is the thing to establish.
Three settings matter. The storage location determines whether received messages are held in the module or on the SIM, and the two have different capacities. The notification mode determines how the host learns that a message has arrived, either by polling or by an unsolicited notification, and polling intervals determine the latency your application sees. The retention behaviour determines what happens when the store is full, and the two possible behaviours — overwrite the oldest or reject the new — have very different consequences for a business process that depends on replies.
Rejecting the newest message when the store is full is the safer default for a commercial deployment, because the alternative silently discards evidence. Whichever behaviour a module exhibits, establish it before go-live by filling the store deliberately rather than discovering it during an incident.
The command set for these settings differs between module vendors, and the technical documentation published by Quectel and SimCom is the reference to follow for the specific module in your pool. Restricting your application to commands common across your estate is what makes a mixed pool manageable.
How does a modem pool compare with a gateway for two-way?
The pool is cheaper; a gateway removes work.
Both can carry two-way traffic, and the difference is where the buffering and matching logic lives.
| Stage | Modem pool | Gateway |
|---|---|---|
| Receive | Host software polls modules and reads storage | Device receives and exposes messages through an interface |
| Buffer during application outage | Depends on module storage limits | Device-level buffering with status reporting |
| Delivery reporting | Reconstructed by the host from module responses | Reported per message with retry counts |
| Cost at entry | 8-port pool published at $113.00 | 4-port gateway published at $238.00 |
The choice follows from how much of the receiving logic you want to own. A pool with a well-built host application can deliver the same outcome at a lower capital cost, provided someone maintains the polling, parsing and storage management. A gateway moves that work into the device and presents a message interface instead, which reduces the software surface your team maintains.
Where the deployment already has a mature sending application with a database behind it, the pool is usually the better fit. Where the team would rather consume a message interface than maintain polling logic, the gateway earns its price difference on engineering time alone.
Why do replies get lost or arrive out of order?
Storage limits and polling intervals, in that order.
Both causes are visible in the module state before they become visible as a business problem.
Lost replies usually come from storage. A module that has reached its limit and overwrites the oldest message will discard a reply that arrived while the host was not reading. The remedy is to read more frequently or to increase the effective store, and the diagnostic is to check the module store occupancy during a busy period rather than during a quiet one.
Out-of-order arrival has a different cause. Messages can be received by different modules in the pool at different times, and the host assembles them into a single stream. Where two replies arrive close together on different modules, the order in which the host reads them is the order in which they are processed, not the order in which they were sent. For a conversational flow this matters. The remedy is to sort by the timestamp carried in the message rather than by the order of retrieval, and to record both so the difference is visible.
A third cause is worth noting because it looks like data loss: a module that is deregistered receives nothing, and messages sent during that period may be retried by the network or dropped according to the operator’s configuration. Monitoring registered channel count catches this class of problem before it produces a visible gap.
How do you handle opt-out replies?
Match the keyword, act immediately, and record the action.
An opt-out is a request that must be honoured, and the mechanism for honouring it is a database update rather than a message.
Three requirements apply. Recognise the keywords used in each market, including local-language variants, because a reply that is not recognised is not honoured. Act without human intervention, because a manual process introduces a delay that is difficult to defend. Record the request, including the time and the originating number, because that record is what demonstrates the request was honoured.
Matching opt-outs is the same lookup problem as matching any other reply, and it has the same dependency: you need the submission record to know which messaging flow the number belongs to. A deployment that cannot match replies cannot reliably identify which list a number should be removed from.
The obligations around consent and opt-out handling are set by market rather than by technology, and the practical reference points are the guidance published by industry bodies such as M3AAWG and the market rules described by organisations such as the CTIA. Where a reply is used to confirm possession of a device, the treatment of that channel is described in NIST SP 800-63B, which is worth reading before designing a flow around it.
What should the acceptance test cover?
Confirm the reply path where it fails first.
Testing a working reply proves less than testing the failures around it.
- Reply arrival. Send from a specific module and reply from a handset, then confirm the message reaches the application rather than only the module store.
- Matching accuracy. Send two messages to the same number within the window and reply once, then verify the reply attaches to the intended record.
- Store saturation. Fill a module store deliberately and confirm the behaviour matches what you designed for.
- Opt-out handling. Reply with the opt-out keyword and confirm the record is updated without human involvement, and that subsequent sends are suppressed.
- Host outage. Stop the host during a reply-heavy period and confirm no message is silently discarded.
Item two is the most informative, because it tests the tie-break rule you chose rather than the happy path. Where the reply attaches to the wrong record, the matching design needs revisiting before the deployment carries commercial traffic.
Conclusion
Two-way messaging over modem hardware is a storage and matching problem with a radio attached. The submission record is what makes matching possible, the reply window has to be tuned per flow rather than globally, and the module store has to be sized and monitored so that replies are not overwritten before the host reads them. Out-of-order arrival is a sorting problem rather than a loss of data, and it is solved by ordering on the timestamp carried in the message.
Where the team would rather consume a message interface than maintain polling logic, a gateway moves that work into the device; where a mature sending application already exists, a pool such as the TYH 16-port modem at $148.00 delivers the same outcome at a lower entry cost. In either case, the opt-out path should be designed as a database update with a record, because it is the part of a two-way flow that carries an obligation rather than a preference.
Design the matching record before you buy the hardware. Send your reply volumes, expected reply windows and opt-out requirement to service@telarvo.com, or review the published models on the SMS modem solution pages.
FAQ
Can a modem pool receive SMS as well as send it?
Yes, provided the host software polls the modules and reads their storage, or the modules are configured to notify the host when a message arrives. The capability is standard; the work is in the host application. Confirm the storage location and notification mode of the specific modules in your pool, because those settings determine how quickly replies reach your application.
Why are replies missing from my pool?
The most common cause is module storage reaching its limit and overwriting or rejecting messages before the host reads them. The second is a module that is deregistered and therefore receives nothing. Check store occupancy during a busy period and monitor registered channel count, since both causes are visible before they become a business problem.
How do I match a reply to the message that prompted it?
By keeping a submission record that stores the originating number, the destination number, the timestamp and the related business identifier. At receipt, look up records for that number pair within the expected reply window and apply a tie-break rule you have chosen deliberately. Without the submission record, matching is guesswork based on timestamps alone.
How quickly must an opt-out be honoured?
Immediately in practice, which means the opt-out path must be automated rather than reviewed by a person. Recognise the keywords used in each market including local-language variants, act on the matching record without human intervention, and store the request with its timestamp and originating number so the action can be demonstrated later.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “Can a modem pool receive SMS as well as send it?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Yes, provided the host software polls the modules and reads their storage, or the modules are configured to notify the host when a message arrives. The capability is standard; the work is in the host application. Confirm the storage location and notification mode of the specific modules in your pool, because those settings determine how quickly replies reach your application.”
}
},
{
“@type”: “Question”,
“name”: “Why are replies missing from my pool?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The most common cause is module storage reaching its limit and overwriting or rejecting messages before the host reads them. The second is a module that is deregistered and therefore receives nothing. Check store occupancy during a busy period and monitor registered channel count, since both causes are visible before they become a business problem.”
}
},
{
“@type”: “Question”,
“name”: “How do I match a reply to the message that prompted it?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “By keeping a submission record that stores the originating number, the destination number, the timestamp and the related business identifier. At receipt, look up records for that number pair within the expected reply window and apply a tie-break rule you have chosen deliberately. Without the submission record, matching is guesswork based on timestamps alone.”
}
},
{
“@type”: “Question”,
“name”: “How quickly must an opt-out be honoured?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Immediately in practice, which means the opt-out path must be automated rather than reviewed by a person. Recognise the keywords used in each market including local-language variants, act on the matching record without human intervention, and store the request with its timestamp and originating number so the action can be demonstrated later.”
}
}
]
}