The telecommunications industry is under constant pressure from organized cybercriminal groups exploiting vulnerabilities in voice network architecture. According to the CFCA Global Fraud Loss Survey 2025, global losses from telecom fraud are estimated at approximately $41.82 billion (compared to $38.95 billion in 2023). The most destructive vector remains International Revenue Share Fraud (IRSF), which caused about $6.23 billion in losses in 2023 alone. As noted in the ENISA Threat Landscape 2025 report, the exploitation of legacy signaling protocols remains a key attack vector. The core problem is that traditional billing systems, focused on batch processing of Call Detail Records (CDR), detect anomalous activity too late—after the traffic has already passed through transit networks and the operator has incurred financial obligations to partners.
The cost of delay: why reactive CDR processing is powerless against IRSF
The classic IRSF scheme is based on compromising subscriber equipment (IP-PBX, SIP phones) or user accounts. Attackers generate hundreds of simultaneous calls to expensive international Premium Rate Numbers (PRN). This often occurs on weekends or at night when operator monitoring is in standby mode.
When using traditional batch analysis (CDR-processing), the latency between the start of a call and its appearance in the fraud detection system can range from several hours to a full day. CDR files are typically uploaded from media gateways or Softswitch platforms in batches every 15–60 minutes, after which they undergo ETL (Extract, Transform, Load) and rating processes. For fraudsters, this time window is more than enough: an IRSF scheme is fully executed in minutes, generating thousands of dollars in losses every minute. Reactive analysis merely confirms the fact of a financial loss. The only effective protection method is transitioning to a real-time billing architecture, where call verification and authorization occur directly in the signaling path before the session is connected.
Real-time billing architecture: moving limit verification to the session establishment phase
According to the Open Digital Architecture (ODA) concept from TM Forum, the industry is moving away from monolithic BSS/OSS toward componentized, API-first architectures. In this paradigm, modern billing functions as an Online Charging System (OCS). Instead of passively collecting CDRs after a call ends, the billing system integrates directly into the SIP signaling process via high-performance REST API or the Diameter protocol.
When a Softswitch receives a SIP INVITE request, it pauses connection establishment and sends an authorization request to the OCS. The billing system performs the following operations within a millisecond limit:
- Verification of the client's current balance and credit limit.
- Matching the call destination with authorized geographic zones.
- Analysis of the concurrent calls/ports limit for a specific account.
- Calculation of the cost of the first billing unit at the current rate.
If limits are exhausted or an anomaly is detected, the OCS returns a call rejection command to the switch with the appropriate SIP code (e.g., 403 Forbidden or 402 Payment Required). This allows the transaction to be stopped before it is completed.
Dynamic LCR routing as a tool for active fraud protection
Least Cost Routing (LCR) is a critical element for wholesale and retail operators. However, classic LCR often becomes a tool in the hands of fraudsters who use the cheapest, unverified transits to terminate fraud traffic. Modern billing must combine rating functions with dynamic LCR management.
When abnormal traffic spikes to expensive destinations are detected, the dynamic LCR system should automatically change route priorities. For example, if a sudden 53.7% increase in traffic volume to a premium destination is recorded within 5 minutes, or if the Answer Seizure Ratio (ASR) drops by 27.7% due to mass number probing, the system must instantly exclude this route from the active LCR table.
| Parameter | CDR-processing (Batch) | Real-time Billing (OCS) |
|---|---|---|
| Response latency | From several hours to days | Milliseconds (before connection establishment) |
| IRSF protection | Low (records losses post-factum) | High (blocks call upon limit breach or anomaly) |
| Impact on LCR | None | Dynamic exclusion of compromised routes in real-time |
| Signaling load | None | Minor (additional API requests to OCS during SIP session) |
Cryptographic call authentication: implementing RFC 8224 and SIP Identity
An important tool for executing IRSF is CLI spoofing. To combat this, the IETF has developed the RFC 8224 standard (Authenticated Identity Management in SIP), which defines the use of the SIP Identity header to carry cryptographically signed information about the call's origin.
Within this architecture, the originating operator signs the call information using a private cryptographic key and adds an Identity header (JWT token) to the SIP INVITE request. The receiving operator verifies this signature. If verification fails, the billing system, together with the Softswitch, decides to block or flag the call.
It is worth noting that implementing RFC 8224 (or related technologies like STIR/SHAKEN) is not an absolute "silver bullet" against fraud. It is merely an authentication mechanism that cannot independently prevent situations where a call is made from a real but compromised account. Therefore, cryptographic verification must work in synergy with real-time billing.
BSS/OSS integration: building a resilient security perimeter based on DooxSwitch
To create robust protection, operators need platforms that combine switching and OCS without unnecessary intermediate links. An example of such an integrated approach is the DooxSwitch telecom platform, which includes a high-performance class 4/5 Softswitch, a built-in real-time rating system, and LCR management tools.
DooxSwitch allows for the implementation of limit-checking logic directly during SIP signaling processing. The platform uses the switch API to instantly update credit limits and block sessions based on billing data or Identity header analysis. This approach eliminates the Post Dial Delay (PDD) inherent in using external, non-integrated BSS systems and guarantees that fraudulent calls are blocked at the connection initiation stage.
FAQ
How to integrate real-time billing with an existing Softswitch without critically increasing PDD (Post Dial Delay)?
To minimize PDD, integration should be based on an API-first architecture (in accordance with TM Forum ODA principles) using asynchronous protocols and in-memory databases for balance caching. OCS requests should be executed in parallel with routing logic, limiting response wait times to a millisecond threshold.
What is the role of the RFC 8224 (SIP Identity) standard in combating number spoofing (CLI spoofing)?
According to the IETF RFC 8224 standard, the SIP Identity header is used to transmit cryptographically signed information about the call's origin. This allows the switch and billing system to verify that the caller's number actually belongs to the network that initiated the SIP session, preventing basic spoofing scenarios.
How to configure automatic route blocking in LCR tables when an abnormal traffic spike is detected?
It is necessary to implement triggers at the switch and OCS levels that monitor metrics in real-time: the number of call attempts per minute and the Answer Seizure Ratio (ASR). Upon reaching abnormal thresholds (e.g., a sudden 53.7% spike on a high-cost route), the integrated LCR system must instantly lower the route priority or block it.