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.

PRE-1984 · BELL SYSTEM REFERENCE

The Historical PSTN Switching Hierarchy

Five switching classes routed every call from a subscriber's handset up to the national trunk network

CLASS 1
Regional Center
Top-level switch — nationwide & international routing
CLASS 2
Sectional Center
Aggregates traffic from several primary centers
CLASS 3
Primary Center
Links toll centers to sectional centers — state / province coverage
CLASS 4
Toll Center
Routes long-distance traffic between local exchanges — city / intercity
CLASS 5
End Office
Provides dial tone & switching directly to subscribers — the local exchange
ORIGIN
Subscriber
Residential or business telephone connected to the local exchange
Call path:Subscriber → Class 5 → Class 4 → Class 3 → Class 2 → Class 1 (and back down the far side to the destination subscriber)

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.

Component Function
SIP Proxy or B2BUA Handles call signalling, INVITE routing, and session management.
Routing Engine Evaluates routing rules, rate decks, and quality thresholds for every call.
Billing Engine Applies real time rating against customer and supplier rate plans.
CDR Generator Creates a Call Detail Record for every session from call setup through call completion.
Fraud Monitor Monitors traffic patterns against configurable fraud detection thresholds.
Media Gateway Bridges IP and TDM networks where protocol or media conversion is required.
Management API Enables integration with external billing platforms, provisioning systems, and operational tools.

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.

ROUTE RANKING
Cost vs. Quality
ROUTE
COST
ASR
ACD
PDD
Route A
$0.0091
38%
1:42
2.8s
Route B
$0.0097
48%
2:15
1.1s
Route C
$0.0119
44%
1:58
1.4s
Route B wins the ranking despite costing more than Route A. Ten points of ASR is worth more than $0.0006 a minute.
FAILOVER CASCADE
One Call, Three Attempts
Route 1
No answer, 502 timeout
+900ms PDD
Route 2
Congestion, 503
+700ms PDD
Route 3
Answered, call connects
Total PDD before answer: ~2.3s. Invisible to the caller, but every millisecond here is a ranking input for the next call.

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 StrategyLogicBest Used For
Least Cost Routing (LCR)Ranks routes strictly by price per minute.High volume commodity traffic.
Quality Based RoutingScores routes using ASR, ACD, and PDD alongside cost.Traffic where answer rates directly affect customer SLAs.
Priority RoutingUses a fixed carrier preference where cost is secondary.Enterprise customers with bespoke agreements.
Load BalancingDistributes traffic across multiple suppliers using predefined percentages.Traffic diversification and upstream redundancy.
Time Based RoutingSelects 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.

CALL DETAIL RECORD
Anatomy of a CDR

Every completed call writes one record like this. Each field below feeds a different downstream process, from invoicing to fraud review.

CALL IDENTIFICATION
Originating number
+14155551234
Destination number
+442071838750
ROUTING
Route used
carrier-tier1-uk-A
TIMING
Start time
2026-08-03 14:22:07 UTC
Duration
184s
OUTCOME
Answer signal
ANSWERED
Disposition code
200 — Normal clearing
A missing or delayed value in any one of these fields is what turns a routine billing dispute into an unresolvable one.

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.

FRAUD SIGNATURE MATRIX
What the Switch Is Watching For

Each fraud pattern trips a different trigger, at a different layer, with a different response speed.

FRAUD TYPE
SIGNATURE PATTERN
DETECTION LAYER
LIMIT TYPE
IRSF
Sudden volume spike to premium-rate destinations
Destination + customer
HARD
Wangiri
High volume of one-ring, unanswered inbound calls
Network
SOFT
CLI Spoofing
Caller ID doesn't match originating trunk or carrier range
Customer + network
HARD
Hard limits block before cost accrues. Soft limits flag for review without touching live traffic. Running all three layers together is what catches patterns a single layer misses.

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.

FactorOn PremiseCloud Native
Capital ExpenditureHigh upfront investment in hardware and infrastructure.No capital expenditure. Operational costs only.
ScalingRequires manual capacity planning and hardware procurement.Supports horizontal scaling on demand.
RedundancyRequires duplicate hardware and infrastructure investment.Built into the cloud architecture by design.
Update CyclesScheduled maintenance windows are typically required.Rolling updates with little or no service disruption.
Global ReachLimited by the location of physical points of presence (PoPs).Can be deployed rapidly to regions worldwide.
Fraud ResponseRule changes are typically implemented manually by engineers.Automated detection thresholds with real time enforcement.
Time to LaunchTypically 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.

2:47 A.M. — TRAFFIC SPIKE
Same Event, Two Architectures
ON PREMISE
2:47 AM
Capacity alert fires, on-call engineer paged
3:05 AM
Engineer VPNs in, assesses hardware headroom
3:30 AM
Existing racks maxed. No spare capacity on site
DAYS LATER
New hardware procured, racked, and provisioned
Calls dropped or rejected in the meantime
CLOUD NATIVE
2:47 AM
Threshold crossed, autoscale trigger fires
2:48 AM
Additional switching capacity provisions automatically
2:50 AM
Traffic distributed across new capacity, live
SAME NIGHT
Engineer sees the alert in the morning digest
Zero calls lost. No one woke up

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.