Table of Contents
A modern open-source SMS gateway has to do much more than simply accept a message, route it to an SMSC and return a delivery receipt.
There was a time when the job of an SMS gateway was relatively easy to describe.
Accept a message. Route it to an SMSC. Respect throughput limits. Receive a delivery receipt. Try not to lose anything along the way.
That is still the foundation. But it is no longer enough.
Accept a message. Route it to an SMSC. Respect throughput limits. Receive a delivery receipt. Try not to lose anything along the way.
That is still the foundation. But it is no longer enough.
Modern messaging infrastructure sits between applications, carriers, aggregators, internal platforms and increasingly complex routing policies. It runs in containers, moves between environments, integrates with existing observability stacks and often has to coexist with infrastructure that was designed many years ago.
So perhaps the more interesting question today is not:
What features should an SMS gateway have?
It is:
What should an open-source SMS gateway build next?
And the answer may have less to do with adding another protocol or another configuration parameter than with making the infrastructure easier to understand, test, extend and operate.
We Do Not Need Another Black Box
One of the biggest advantages of open-source infrastructure is inspectability.
You can see the code. You can understand what the system is doing. You are not entirely dependent on a vendor telling you that something failed somewhere inside a platform you cannot access.
But access to source code alone does not automatically make a system transparent.
Imagine a message enters the gateway and eventually reaches Provider B instead of Provider A.
Why?
Did a routing rule match?
Was Provider A unavailable?
Was its TPS limit reached?
Did an earlier submission fail?
Was a fallback rule triggered?
Was the message deliberately routed differently because of its destination, sender, account or another attribute?
A modern gateway should be able to answer those questions without requiring an operator to reconstruct the entire decision from several log files.
The next generation of SMS infrastructure needs routing explainability.
Not simply:
Message routed to Provider B
but something closer to:
Message matched rule X → Provider A unavailable → fallback rule Y → Provider B selected
That difference becomes enormous when you are troubleshooting production traffic.
Configuration Should Be Testable Before It Becomes Production Traffic
Telecom infrastructure has traditionally relied heavily on configuration files, and there is nothing inherently wrong with that.
In fact, file-based configuration has several important advantages. It is portable, versionable, automatable and works extremely well with modern infrastructure practices.
The problem begins when changing configuration effectively means:
Edit it, reload it and see what happens.
For a modern open-source SMS gateway, configuration should not only be editable. It should also be testable.
Routing rules should be testable.
If an operator changes a routing table, the gateway should ideally be able to answer questions such as:
Where would this destination be routed?
Which rule would match this message?
What changed between the previous configuration and this one?
Are any routes now unreachable?
Does this rule shadow another rule?
A dry-run or route simulation capability could make configuration changes dramatically safer.
Even better would be the ability to run a collection of predefined routing tests automatically.
For example:
+30xxxxxxxxxx → Greek Provider A
+44xxxxxxxxxx → UK Provider B
Sender: BRAND → Route C
Then a routing change could be validated before a single real message uses it.
For telecom infrastructure, that is not simply developer convenience.
It is operational risk reduction.
Observability Should Follow the Message
CPU usage matters.
Memory usage matters.
Connection status, queue depth, throughput and error rates matter.
But the object we ultimately care about is still the message.
A modern SMS gateway should make it possible to follow the lifecycle of a message from the moment it enters the system until the final outcome is known. This kind of SMS gateway observability is critical when troubleshooting real production traffic.
Submission.
Routing decision.
Queue.
SMPP connection.
submit_sm.
Provider response.
Provider message ID.
Delivery receipt.
Final status.
And, where relevant, the corresponding callback to the originating application.
The infrastructure world is increasingly moving toward correlated telemetry rather than isolated logs and metrics. For SMS gateways, the same idea makes sense.
An operator investigating an incident should not have to manually connect five unrelated events using timestamps and message IDs.
The gateway already knows how those events are related.
It should expose that relationship.
This is where standards such as OpenTelemetry could eventually become particularly interesting for messaging infrastructure: not because every SMS gateway needs another monitoring product bundled into it, but because gateways should integrate cleanly with the observability systems operators already use.
Failure Handling Should Become Easier to Understand
Retries are essential.
Fallback routing is essential.
Queues are essential.
But complex failure handling introduces another problem: infrastructure can successfully recover from an incident while making it surprisingly difficult for the operator to understand what actually happened.
Imagine a provider temporarily stops accepting traffic.
Messages begin retrying. Some are re-enqueued. Some move through fallback routing. The provider recovers. Traffic returns to normal.
From the outside, the incident may appear relatively small.
From an operational perspective, however, several questions remain:
How many messages were affected?
How long did they remain queued?
Which fallback paths were used?
Did the gateway recover automatically?
Did any messages exhaust their retry policy?
Was traffic restored gradually or immediately?
The next step should therefore not simply be more automatic recovery.
It should be explainable recovery.
Automation is much more useful when humans can understand what the automation did.
Testing an SMS Gateway Should Not Require a Carrier
This is another area where open-source telecom infrastructure could improve significantly.
Testing messaging systems often becomes unnecessarily dependent on external infrastructure.
To properly test routing, retries, throttling or failure scenarios, operators may need working SMPP connections, test accounts or custom simulators.
A modern open-source SMS gateway could make this much easier.
Imagine being able to create a simulated upstream provider that intentionally:
accepts messages at 50 TPS,
rejects every tenth submission,
delays responses,
returns specific SMPP error codes,
disconnects after a defined number of messages,
or generates predefined delivery receipts.
Suddenly, failure scenarios become reproducible.
Developers could test an integration locally.
Operators could validate retry behaviour before deployment.
Contributors could reproduce bugs without needing access to somebody’s SMSC.
And CI pipelines could test telecom behaviour that today often requires manual integration environments.
For an open-source project, this would be particularly powerful because reproducibility makes community debugging much easier.
Extending the Gateway Should Not Mean Forking It
Every telecom environment eventually develops requirements that are specific to that environment.
A custom routing rule.
A proprietary provider behaviour.
A particular DLR format.
An internal authentication mechanism.
A transformation applied before submission.
An unusual business rule.
The traditional open-source answer is often:
Modify the source code.
That works — until you need to upgrade.
Then your private modifications become a maintenance burden.
A stronger long-term architecture would make more of these behaviours extensible without forcing users to maintain their own fork.
Hooks, plugins, custom routing operators, provider adapters or clearly defined extension interfaces could allow organizations to customize behaviour while keeping the core gateway upgradeable.
That is especially important for infrastructure projects.
The easier a project is to extend cleanly, the less fragmentation develops around it.
Smarter Routing Does Not Have to Mean “AI Routing”
There is also an obvious direction for routing itself.
A gateway knows considerably more about its environment than traditional static routing rules normally use.
It may know that one connection is unavailable.
It may know that another provider is rejecting messages.
It may know that a queue is growing.
It may know that a route is consistently producing failures for a particular destination.
That information could eventually influence routing decisions.
But there is an important distinction here.
“Smarter” does not automatically mean unpredictable.
Telecom operators need deterministic behaviour. If a message takes a different route, somebody should be able to explain why.
A useful evolution could therefore be policy-based, health-aware routing where operators explicitly define what should happen under specific operational conditions.
If Provider A becomes unavailable, use Provider B.
If a defined failure threshold is reached, temporarily remove a route.
When the provider recovers, restore traffic according to a defined policy.
Nothing magical.
Nothing opaque.
Just better use of information the gateway already possesses.
Open Source Should Also Mean Portable Operations
A modern open-source SMS gateway should remain portable not only at the source-code level, but at the operational level as well.
One of the strongest arguments for open-source infrastructure is independence.
That independence should apply not only to licensing, but also to operations.
A modern gateway should not force an organization into a particular cloud, monitoring stack, database architecture or management platform.
It should expose clean interfaces and allow operators to decide how they want to run it.
Docker today. Kubernetes tomorrow. A private data centre somewhere else.
Prometheus for one organization. Another telemetry platform for another.
Configuration managed manually in a small deployment or through automated infrastructure pipelines at scale.
The gateway should provide the primitives.
The operator should retain the choices.
That is a much more meaningful definition of infrastructure flexibility than simply saying that software can run “in the cloud.”
Maybe the Next Feature Is Not a Feature
There is another possibility.
Perhaps the most important work for an open-source SMS gateway is not always adding functionality.
It may be improving documentation.
Making configuration errors clearer.
Creating better examples.
Making installation easier.
Improving upgrade paths.
Providing realistic test environments.
Making troubleshooting less dependent on deep SMPP knowledge.
Reducing the number of things an operator needs to understand before sending the first message.
Infrastructure software often becomes powerful long before it becomes easy to operate.
Open source gives us an unusual opportunity to work on both.
What Should a Modern Open-Source SMS Gateway Build Next?
At Sendium, we already have many of the fundamentals in place: SMPP server and client capabilities, HTTP and SMPP bridging, configurable routing, throughput control, queues and retries, delivery receipt handling, MO forwarding, container deployment and operational metrics.
But an open-source project should never assume that its maintainers know every problem its users are trying to solve.
The people operating messaging platforms every day know where the friction really is.
Maybe it is routing simulation.
Maybe it is deeper message-level observability.
Maybe it is configuration validation.
Maybe it is better testing.
Maybe it is extensibility.
Or maybe it is something we have not considered at all.
That is exactly why the next stage of an open-source SMS gateway should not be designed behind closed doors.
If you could add one capability to a modern SMS gateway, what would it be?
Tell us in the Sendium GitHub Discussions.
The next useful feature may already be sitting in somebody’s production problem today.
