Telecommunications operators face a critical need to modernize their architecture to protect voice traffic. According to the CFCA Global Fraud Loss Survey 2025 report, expected global losses from telecom fraud in 2025 will reach approximately $41.82 billion, a significant increase from $38.95 billion in 2023. A large portion of these losses is attributed to International Revenue Share Fraud (IRSF), which cost the industry about $6.23 billion in 2023 alone. These financial risks are forcing CTOs and network architects to rethink their approaches to voice traffic routing.
Traditional approaches to SIP routing, focused solely on switching speed and route cost optimization, are no longer capable of securing the voice core. A modern softswitch must do more than just switch sessions; it must perform deep signaling analysis in real time and cryptographically verify subscriber identities without degrading throughput performance.
Anatomy of the threat: why legacy SIP routing misses IRSF fraud
Classic SIP routing is built on static or semi-dynamic routing tables. Upon receiving a SIP INVITE request, the softswitch analyzes the destination number prefix and selects a trunk based on cost or priority. The fundamental vulnerability of this scheme lies in its complete trust in text-based sender identification headers.
Attackers exploit this weakness to execute mass spoofing and IRSF. The scheme works as follows: a stream of calls is generated to premium-rate numbers. To bypass anti-fraud systems, fraudsters spoof the Caller ID. A legacy softswitch, lacking built-in cryptographic verification tools, allows this traffic to pass through unimpeded.
Attempts to solve the problem through simple synchronous requests to external anti-fraud platforms during SIP session processing lead to a critical increase in Post Dial Delay (PDD) and signaling flow congestion.
RFC 8224 and STIR/SHAKEN: how cryptographic authentication works in SIP INVITE
To combat identifier spoofing, the industry has standardized cryptographic signature mechanisms. According to IETF data, the RFC 8224 standard defines the use of a special Identity header in the SIP protocol to carry cryptographically signed information about the call's origin.
This mechanism is the technical foundation of the STIR/SHAKEN framework, which, in accordance with FCC requirements, is based on verifying SIP INVITEs using a Public Key Infrastructure (PKI):
- Authentication: When a subscriber initiates a call, the originating operator's network confirms the subscriber's right to use that number.
- Cryptographic signature: Based on this confirmation, a signature is generated using the originating operator's private key and added to the Identity header of the signaling packet.
- Verification: The softswitch or the terminating operator's verification service receives the request, extracts the Identity header, and verifies the signature using the originating operator's public key.
Implementing STIR/SHAKEN does not eliminate all existing types of telecom fraud. However, it makes unpunished number spoofing impossible by providing a tool for the precise identification of call sources.
Architectural transition: from monolithic BSS/OSS to Open Digital Architecture (ODA)
Implementing cryptographic checks at the signaling level requires structural changes to the telecom operator's IT infrastructure. Attempting to integrate STIR/SHAKEN validation logic into legacy monolithic Business and Operations Support Systems (BSS/OSS) typically reduces overall network reliability and flexibility.
The optimal path is transitioning to the Open Digital Architecture (ODA) developed by TM Forum. ODA replaces monolithic BSS/OSS with a composable, API-first architecture. This means separating traffic management functions into independent services: a high-performance routing core (softswitch), asynchronous cryptographic verification services, and billing modules. This approach is not a simple plug-and-play deployment, but a long-term trajectory for the operator toward autonomous operations.
Optimizing softswitch performance during deep signaling traffic inspection
Cryptographic computations place a significant load on computing resources. If a softswitch performs signature verification for every SIP INVITE synchronously, routing performance will degrade significantly. To ensure seamless operation, the following solutions are applied:
- Asynchronous validation: The signature verification process is offloaded to separate microservices via API or message queues, allowing the softswitch to process other call setup stages in parallel.
- Certificate caching: Public keys of other operators are stored and updated locally to avoid network request delays during the signaling session.
- Hybrid routing: Combining traditional LCR with intelligent analysis of the number's cryptographic verification status to make real-time call-passing decisions.
Integrating DooxSwitch: building a secure and scalable voice core
To practically solve these tasks, operators need modern Class 4/5 solutions that combine routing capabilities with integrated billing. An example of such a product is the carrier-grade VoIP platform DooxSwitch (developed by DooxSwitch, a product within the portfolio of the Intecracy Group alliance of independent companies).
The platform enables flexible SIP routing and real-time billing without reducing network core performance. The solution's architecture supports integration with modern call authentication standards and allows for dynamic traffic management based on Quality of Service (QoS) metrics, LCR margins, and subscriber verification, meeting the requirements of the modular ODA approach.
| Criterion | Monolithic architecture (Legacy) | Component architecture (TM Forum ODA / DooxSwitch) |
|---|---|---|
| RFC 8224 (Identity) processing | Synchronous verification, causing SIP session delays | Asynchronous validation via API-first services without routing degradation |
| Protection against IRSF and spoofing | Reactive (CDR analysis after the fact) | Proactive (blocking at the SIP INVITE stage) |
| LCR configuration flexibility | Manual routing table updates | Dynamic routing based on real-time data and margins |
FAQ
How does implementing RFC 8224 affect the softswitch PDD (Post Dial Delay)?
With a proper asynchronous architecture and local public key caching, the impact on PDD is minimized. However, using legacy synchronous requests to external servers without caching can cause PDD to increase critically, creating noticeable latency.
Can STIR/SHAKEN be integrated into a softswitch without fully replacing legacy BSS/OSS?
Yes, it is technically possible by implementing Session Border Controllers (SBC) or specialized authentication/verification microservices at the network edge, which partially offloads the core. However, for full automation, transitioning to API-first approaches is recommended.
What requirements does TM Forum ODA impose on modern voice traffic routing systems?
The key requirement is decomposition: moving from monolithic solutions to a modular architecture. Routing, billing, and security systems must function as independent components that interact exclusively through standardized APIs to ensure operational flexibility.