The SC.Soft SMSC platform offers a message routing emulation mode that allows operator engineers to verify the correctness of delivery rules before publishing changes — without sending test messages into the real network. This capability is a characteristic example of an approach in which platform development is measured by how much work and risk it removes from the operator’s team.
In legacy SMSC platforms, where configuration is stored across multiple text files, any change to routing rules effectively becomes a release to a production system. An engineer edits the configuration, waits for the changes to take effect, and then observes how the new logic plays out on live traffic. If the routing script contains an error, it’s not the developers who find out first — it’s subscribers and enterprise clients, through dropped delivery rates and support tickets.
In the SC.Soft SMSC platform, change verification is performed before publication. In the routing graph editor, an engineer adds nodes, edges, and Lua scripts; these changes are visible only to that engineer and do not affect the active configuration. Before publication, an emulation can be run: the engineer specifies parameters of a test message — sender, recipient, text, encoding, scheduled delivery time — and sees the path the message will take through the graph, which nodes and scripts will be involved, and a detailed processing log. Test message templates are saved and can be reused, including templates built from any real message in the SMSC history.
[Screenshot: routing graph with the highlighted path of an emulated message and a log panel showing an error in the script of the EventTest node]
Consider a typical scenario. An operator is onboarding a new A2P aggregator for which a separate route needs to be configured — with message text pre-processing, CDR generation, and sender address substitution. On a classical SMSC, this task takes several iterations: edit configuration — publish — verify via logs — roll back if needed. Each iteration is a window during which some portion of traffic may be misrouted. In the SC.Soft platform, the new route is built in the graph editor, run through emulation against several message templates (including edge cases — long messages, alphanumeric addresses, various encodings), and only after verifying the logic does the engineer publish the changes. If, for example, the script references a non-existent field, the emulation surfaces it in the log with the exact line number, as shown in the screenshot above, and the engineer fixes the issue before it affects live traffic.
For a telecom operator, this delivers three practical outcomes: reduced operational risk when changing routing, shorter time to launch new integrations with enterprise customers, and reduced dependence on a small group of engineers able to «read» platform behavior from logs. Behind these outcomes is the general principle by which SC.Soft develops the platform: every investment an operator makes in the SMSC and its day-to-day operation should deliver maximum return. Functional decisions that add work for the operator’s team instead of saving it do not make it into the product.
The SC.Soft SMSC platform has been delivered to telecom operators for 17 years and is currently deployed in more than 30 installations across 15 countries. The company is ready to conduct a 4-week pilot project in an operator’s network — with agreement on goals, KPIs, and conditions for transition to commercial operation. The pilot KPIs are defined by the customer.
