What Is a Class 4 Softswitch? Architecture, Routing, and Fraud Controls Explained
It is 2:47 a.m. on a Tuesday. Your wholesale traffic is spiking, as it always does when your biggest customer runs a campaign in Asia Pacific. Your hardware switch starts throwing 503 errors, and call attempts begin cascading into failure.
Your customer is watching answer rates collapse in real time. You spend the next three hours troubleshooting a capacity ceiling that a cloud platform would have scaled past automatically.
The root cause is not your routes, your suppliers, or your NOC team. It is the switch itself.
Most carriers outgrow their switching infrastructure long before they recognise it. A Class 4 softswitch is the engine at the centre of every wholesale VoIP network.
This article covers the architecture, the routing logic, the billing layer, and the fraud controls that define a production-grade Class 4 platform. Whether you are evaluating a new switch or trying to understand your existing one better, this is the complete guide.
What Is a Class 4 Softswitch?
The term comes from the ITU-T classification system for telephone exchanges. Class 4 refers to the transit level of the public switched telephone network, handling calls between networks rather than to end users. That single distinction defines everything about how these platforms are built and operated.
A Class 4 softswitch is a carrier-grade routing engine that manages high volumes of voice traffic between originating and terminating networks. It receives calls from one carrier, evaluates routing rules and cost tables, and forwards each call to the appropriate downstream provider.
It does not ring a desk phone, and it does not manage voicemail.
The software replaces what used to be done by physical TDM tandem switches. Those hardware cabinets cost millions of dollars, required specialist engineers, and broke in ways that were catastrophically difficult to diagnose.
A modern Class 4 softswitch runs on commodity servers, scales horizontally, and handles millions of simultaneous call attempts with millisecond routing decisions.
A useful shorthand: a Class 5 switch delivers a call to your phone. A Class 4 switch decides which path that call takes to get there. The Class 4 switch never speaks to you. It speaks to other switches.
The PSTN classification system originally had five levels, with Class 1 at the top of the hierarchy and Class 5 at the subscriber edge. Class 4 occupied the long-distance transit layer. When VoIP emerged, the terminology carried over. Most of the hardware did not.
The Historical PSTN Switching Hierarchy
Five switching classes routed every call from a subscriber's handset up to the national trunk network
The Core Architecture: Signalling, Media, and Why They Are Kept Apart
The most important concept in softswitch architecture is the separation of signalling and media. These are two distinct planes with two distinct jobs. Understanding the difference unlocks everything else about how a Class 4 platform works at scale.
The signalling plane controls the call. It handles SIP messaging, INVITE transactions, call setup, and teardown. This is where routing decisions happen, where billing counters start, and where fraud detection runs.
The media plane carries the actual voice, with RTP packets flowing between endpoints, completely independently of the signalling layer.
This separation is why a Class 4 softswitch can route millions of calls without ever touching a single audio stream. The switch manages the conversation about the conversation. This architecture is what makes carrier platforms both highly scalable and remarkably efficient under heavy load.
Each component handles its function independently. The result is a platform that absorbs traffic spikes without cascading failures, and that can be extended without redesigning the entire stack. The architecture is the platform, not just the packaging.
The Routing Engine: Where Your Margin Is Won or Lost
Routing decisions happen in milliseconds, but they carry enormous financial weight. A Class 4 softswitch evaluates every call against a set of routing criteria before dispatching it to a downstream provider.
The most basic form of this is least cost routing, or LCR. The engine holds rate decks from every upstream supplier. It matches the dialled number against each deck and selects the cheapest route that meets a minimum quality threshold.
ConnexCS has covered LCR mechanics in depth, including the practical pitfalls of implementing it without destroying answer rates in the process.
But experienced carriers move beyond pure LCR quickly. The problem with always taking the cheapest route is that cheap routes are cheap for a reason. Quality-based routing layers ASR, ACD, and PDD measurements on top of cost. A route half a cent cheaper but ten percentage points worse on answer rates does not win the ranking.
When a route fails, the switch does not drop the call. It runs a failover cascade, offering the call to the next route in the ranked list, then the next, until one connects. This cascade is invisible to the caller but visible in your CDRs as extra post-dial delay. Optimising your failover sequence is as important as optimising your primary route.
| Routing Strategy | Logic | Best Used For |
|---|---|---|
| Least Cost Routing (LCR) | Ranks routes strictly by price per minute. | High volume commodity traffic. |
| Quality Based Routing | Scores routes using ASR, ACD, and PDD alongside cost. | Traffic where answer rates directly affect customer SLAs. |
| Priority Routing | Uses a fixed carrier preference where cost is secondary. | Enterprise customers with bespoke agreements. |
| Load Balancing | Distributes traffic across multiple suppliers using predefined percentages. | Traffic diversification and upstream redundancy. |
| Time Based Routing | Selects routes based on the time of day or day of week. | International destinations with off peak rate differentials. |
A production-grade Class 4 softswitch supports all five strategies simultaneously, with per-customer and per-destination configuration. The routing engine is not a set-and-forget component. It is an active margin management tool that needs the same ongoing attention as your rate decks do.
Once routing decides where the call goes, billing decides what it costs.
Real-Time Billing and CDR Generation
A Class 4 softswitch that cannot rate calls accurately in real time is a liability dressed as infrastructure. The billing engine runs concurrently with every active session, applying per-customer rate plans against actual call data as it happens.
When a call connects, the billing engine starts a counter against the originating customer's rate plan. When the call ends, it reconciles that counter against the terminating supplier's cost. The difference, across millions of calls per day, is your margin.
The CDR analysis workflow covers how to extract meaning from this data at scale. But the quality of that analysis depends entirely on what the switch records in the first place.
Every call generates a Call Detail Record. The CDR captures the originating number, the destination, the route used, the start time, and the duration. It also records the answer signal and the final disposition code.
Every completed call writes one record like this. Each field below feeds a different downstream process, from invoicing to fraud review.
These records are the source of truth for billing disputes, fraud investigations, and route quality audits. A switch that writes incomplete or delayed CDRs creates downstream problems that compound with every passing day.
Credit limits are part of this layer too. A Class 4 softswitch enforces per-customer credit thresholds in real time, cutting off traffic before a customer's balance goes negative. For wholesale operators extending credit to other carriers, this control is not optional. It is the difference between a manageable dispute and a debt that never gets paid.
Fraud Detection at the Switch Level
VoIP fraud does not happen slowly. IRSF attacks, Wangiri schemes, and CLI spoofing campaigns can drain significant revenue within hours of initiation. A Class 4 softswitch is the best place to stop them, because it sees every call before it generates cost.
The switch applies hard and soft limits at multiple points in the call flow. Hard limits block calls that breach thresholds instantly, before they connect and before cost accrues. Soft limits flag anomalies for review without interrupting live traffic.
Effective fraud controls run at the customer level, the destination level, and the network level simultaneously. The blog covers IRSF detection in detail and Wangiri attack patterns for carriers who want the full picture on each fraud type.
Each fraud pattern trips a different trigger, at a different layer, with a different response speed.
The Communications Fraud Control Association estimated global telecom fraud losses at $38.95 billion in its 2021 survey. Voice fraud represents a substantial share of that figure. The switch is not just a routing engine. It is the first and most effective line of defence for your entire network.
On-Premise vs. Cloud-Native: The Architecture Decision That Follows You
For most of the history of VoIP, Class 4 softswitches were physical infrastructure. Racks of servers, deployed in carrier-grade facilities, managed by teams of engineers who knew every quirk of the hardware. That model still exists. It is also increasingly the wrong default choice for most operators.
A cloud-native Class 4 softswitch decouples the platform from the physical infrastructure. Capacity scales on demand. Redundancy is architectural rather than bolted on after the fact.
Updates deploy without scheduled maintenance windows. For carriers that are growing, or those who experienced that 2:47 a.m. moment from the opening of this article, the operational difference is significant.
The economic argument is equally clear. An on-premise switch requires upfront hardware investment, a data centre footprint, and dedicated engineering capacity to manage and maintain it. A cloud-native platform converts that capital expenditure into operational cost and removes the hardware lifecycle problem entirely.
| Factor | On Premise | Cloud Native |
|---|---|---|
| Capital Expenditure | High upfront investment in hardware and infrastructure. | No capital expenditure. Operational costs only. |
| Scaling | Requires manual capacity planning and hardware procurement. | Supports horizontal scaling on demand. |
| Redundancy | Requires duplicate hardware and infrastructure investment. | Built into the cloud architecture by design. |
| Update Cycles | Scheduled maintenance windows are typically required. | Rolling updates with little or no service disruption. |
| Global Reach | Limited by the location of physical points of presence (PoPs). | Can be deployed rapidly to regions worldwide. |
| Fraud Response | Rule changes are typically implemented manually by engineers. | Automated detection thresholds with real time enforcement. |
| Time to Launch | Typically takes weeks to months. | Typically takes days. |
This is not a blanket argument against on-premise infrastructure. Carriers with specific regulatory requirements or data sovereignty constraints have legitimate reasons to maintain physical infrastructure.
For the majority of wholesale VoIP operators today, a cloud-native platform reduces both capital risk and operational overhead without sacrificing control or performance.
Conclusion
A Class 4 softswitch is not a commodity. The routing engine, the billing accuracy, the fraud controls, and the underlying architecture all compound over time. A platform that performs well on day one may quietly become the ceiling that limits your growth on day three hundred.
The more useful question is not what a Class 4 softswitch does. It is what yours does not do yet. That gap is worth identifying before a traffic spike at 2:47 a.m. identifies it for you.












