SMPP and VoIP messaging infrastructure

Context

SMS is still how many businesses reach their customers: one-time codes, delivery alerts, reminders. Behind each message there is a gateway that passes it from the sending application to a mobile operator.

From July to August 2024 I was an intern at MISTA LLC, where I first worked closely with SMS gateways, the SMPP protocol and the other channels businesses use to communicate. In September 2024 I became Infrastructure Manager at Trust SMS Uganda, responsible for their SMS gateway infrastructure, which connects through different international telecom operators.

I cannot describe the client's internal setup, partners or volumes, so this case study covers the engineering problem in general terms.

What I built

SMPP (Short Message Peer-to-Peer) is the protocol most of the SMS industry uses to exchange messages between applications, aggregators and operators. Unlike a simple web interface, it keeps long-lived connections open, sends messages as binary packets, and expects both sides to acknowledge everything. Delivery reports come back on their own schedule.

For Trust SMS Uganda I built a custom SMPP server. It started in Python. Later I added Node.js, for better performance and for raw, low-level access to the protocol, instead of working through layers of abstraction.

In January 2026 I built and put into production custom VoIP software and two-way SMPP software, so that messages and calls can flow in both directions. VoIP, voice over internet protocol, carries phone calls over an internet connection.

The hard part

Connections fail, so recovery has to be designed in. A long-lived SMPP connection will drop sooner or later. If the system is not built to reconnect and resend, messages are delayed or lost. Reconnection and resending had to be part of the server from the start, not added after the first incident.

Every message needs a known state. Each message must be in a clear state: submitted, accepted, delivered or failed. Without that, nobody can answer the first question every customer asks, which is whether the message arrived. Delivery reports come back on their own schedule, so the state of a message can change after it has been sent.

Several operators mean several behaviours. Connecting through different international telecom operators means each one can behave a little differently. The system has to cope with those differences without each one becoming a special case that only one person understands.

Moving to raw SMPP access in Node.js gave me control that higher-level tools had hidden, and better performance with it. Python was the right place to start, and Node.js was the right next step once performance and protocol control mattered more.

Results

• A custom SMPP server in use for the Trust SMS Uganda gateway, first in Python and then also in Node.js.
• Two-way SMPP and VoIP software in production since January 2026, so the gateway handles messages and calls in both directions.
• Management of the gateway infrastructure across several international telecom operators since September 2024.

What I would do differently

Reliability is a design decision, not a feature that can be added later. I would write down the reconnection rules and the message states before writing the first line of server code, and test the failure cases before the happy path.

Stack and role

• Role: Infrastructure Manager at Trust SMS Uganda since September 2024; preceded by an internship at MISTA LLC from July to August 2024.
• Work: SMPP server, two-way SMPP software, VoIP software, gateway infrastructure.
• Stack: SMPP, VoIP, Python and Node.js.
• Timeframe: 2024 to the present.