Introducing OTS SMPP Proxy

Open Text Shield (OTS) just got a major upgrade. With the latest commit to the v2.7 branch, OTS now includes a native SMPP interface, an inline SMPP-to-SMPP classification proxy that lets telecom operators filter spam and phishing at the protocol level, without changing a single line of code in their existing SMSC infrastructure.

Why This Matters

Until now, integrating OTS into your SMS pipeline required HTTP API calls. That works well for platforms that can make REST calls mid-routing, but some carriers and aggregators run pure SMPP stacks with no HTTP capability in the message path. They had to build custom middleware just to call the OTS classification API.

The new SMPP interface removes that barrier entirely. Your SMSC connects to the OTS proxy via standard SMPP bind_transceiver. Every submit_sm is intercepted, classified by the OTS mBERT model in real time, and either forwarded to the upstream SMSC or rejected, all transparently.

How It Works

The architecture is straightforward:

Client SMSC connects to the OTS SMPP proxy on port 2775. For every incoming message, the proxy extracts the short_message content, sends it to the OTS mBERT classification API via HTTP, and makes a decision based on the result. Ham messages are forwarded to the upstream SMSC. Spam and phishing messages are rejected with SMPP error code 0x45, or optionally dropped with a fake success response to silently absorb the traffic.

The proxy handles connection pooling to the upstream SMSC with configurable parallel binds, DLR relay back to the originating client, UDH and multipart SMS passthrough, and round-robin load balancing across multiple OTS API instances.

Production Ready

This is not a proof of concept. The implementation is built on the same patterns used in the proven SMPP stack that processes millions of messages daily. Key production features include exponential backoff reconnect on upstream session drops, message_store size caps to prevent memory leaks on long-running sessions, client keepalive via enquire_link with configurable intervals, graceful shutdown handling, and structured logging for every classification decision.

The commit includes 79 tests covering basic SMPP operations, UDH handling, emoji content, async behavior, and performance benchmarks.

Configuration

Everything is driven by a single config.json file. You define your client credentials, upstream SMSC connection details, and classification rules per label:

{ "classification": { "api_url": "http://localhost:8002/predict/", "model": "ots-mbert", "confidence_threshold": 0.7, "rules": { "ham": { "action": "forward" }, "spam": { "action": "reject", "error_status": 69 }, "phishing": { "action": "reject", "error_status": 69 } } } }

You can also point the proxy at multiple OTS API instances for horizontal scaling. The proxy round-robins across them automatically.

Scaling With v2.7

The SMPP interface ships alongside v2.7 platform scaling infrastructure, which adds nginx-based load balancing across up to 10 OTS API instances and Docker Compose configs for 2x and 10x horizontal deployments. Combined with the SMPP proxy’s multi-API support, this means you can scale classification throughput linearly by adding more API containers behind the load balancer.

Get Started

cd src/smpp_interface npm install vi config.json # set your upstream SMSC and credentials ./start.sh

The OTS API needs to be running on the configured endpoint (default localhost:8002). Point your SMSC at the proxy, and classification happens inline with zero changes to your existing routing logic.

The full source, documentation, and architecture diagrams are available on GitHub: github.com/TelecomsXChangeAPi/OpenTextShield

OTS is open source under the MIT license. If you are running an SMPP-based SMS operation and want AI-driven content classification without the integration overhead, this is the simplest path to get there.