Class 4 vs. Class 5 Softswitch: What You Need to Know Before Replacing Yours

The terms "Class 4" and "Class 5" describe two fundamentally different switching architectures—yet many carriers and service providers treat them as interchangeable. Understanding the distinction is critical when evaluating replacements for legacy BroadSoft, Metaswitch, or proprietary platforms.

‍

The good news: modern orchestration platforms have made the Class 4/Class 5 separation obsolete. The bad news: if you're migrating off a legacy platform, you still need to understand which functions you're actually running and ensure your new solution handles both.

‍

What Is Class 4? (Tandem or Transit Switching)

A Class 4 softswitch handles high-volume, long-distance call routing for carriers and service providers. Its job is simple but foundational: receive calls from multiple sources (local carriers, other service providers, long-distance providers) and intelligently route them to their destination.

‍

Key characteristics:

‍

• High throughput: Processes thousands of simultaneous calls per second
• Simple intelligence: Routes based on dial plan rules (e.g., "calls to 1-800 numbers go to Provider A; international calls go to Provider B")
• Minimal features: No voicemail, call waiting, or three-way calling logic
• Carrier-to-carrier focus: Optimizes for volume and cost-effectiveness
• Billing-centric: Tracks call detail records (CDRs) for every call, typically with high granularity (source, destination, duration, cost)
• Geographic flexibility: Can route to any endpoint (PSTN, VoIP, foreign carriers)

‍

Class 4 switches were historically installed at the center of carrier networks—hence the term "tandem" switch, meaning "in between" multiple network segments.

‍

Common use case: A regional carrier receives calls from 50+ provider partners and needs to route them intelligently to minimize costs and ensure reliability. A Class 4 switch makes this decision in milliseconds for billions of calls annually.

‍

What Is Class 5? (End-User Feature Switching)

A Class 5 softswitch, by contrast, is installed closer to end users. Its function is to deliver rich telephony features directly to the user.

‍

Key characteristics:

‍

• Feature-rich: Voicemail, call waiting, call transfer, three-way calling, call forwarding, DND, visual voicemail, etc.
• User-centric: Stores user preferences, feature codes, and profiles
• Lower throughput per switch: Typically 100–1000 simultaneous calls (not 10,000+)
• State management: Maintains session state for each active call
• Integration-heavy: Often integrates with billing systems, provisioning platforms, and CRM systems
• Subscriber management: Manages user accounts, SIM associations, line provisioning
• Regulatory compliance: Often includes E911, CALEA (lawful intercept), and HIPAA compliance features

‍

Class 5 switches were historically installed at the edge of carrier networks, closest to end users.

‍

Common use case: A service provider offers hosted PBX or residential VoIP service to customers. A Class 5 switch delivers those customers' voicemail, call waiting, and call forwarding features while managing their subscriptions and billing relationships.

Quick Comparison

‍

The Historical Separation (And Why It Mattered)

Carriers built separate platforms because the engineering requirements are fundamentally different.

‍

A Class 4 switch optimizes for throughput and cost. It needs to process as many calls as possible with minimal latency, which means keeping logic simple and data lookups fast. Adding feature-rich state management to a Class 4 platform would slow it down and drive costs up.

‍

A Class 5 switch optimizes for flexibility and user experience. It needs to maintain complex feature states, handle custom configurations per subscriber, and integrate tightly with billing and provisioning systems. Doing this at the volume and speed required for Class 4 transit would be overengineered and wasteful.

‍

So carriers built two separate platforms:

‍

• Class 4 switch in the network core for transit routing
• Class 5 switch at the edge for subscriber features

‍

Each platform was optimized for its job. Each had its own vendor ecosystem, licensing model, and operational team.

‍

Where The Line Blurs: Modern Platforms

Today's telecom landscape has introduced new architectural possibilities:

‍

Software-defined networking (SDN) allowed carriers to decouple switching logic from proprietary hardware. Instead of buying a "BroadSoft Class 5 switch," you could buy a software license and run it on commodity hardware. This reduced hardware costs but didn't change the fundamental Class 4/Class 5 distinction.

‍

Orchestration platforms went further: they eliminated the need to choose between Class 4 and Class 5 at all. Instead of running separate platforms, modern orchestration layers sit above your existing infrastructure and intelligently route calls, enforce policies, manage failover, and deliver features through APIs.

‍

For example, a carrier might maintain:

‍

• Contracts with five Class 4 providers (regional carriers, backup carriers, international gateways)
• One or more Class 5 providers for specific use cases (hosted PBX, residential VoIP)
• An orchestration layer that decides which provider handles which call, enforces billing rules, manages failover, and ensures compliance

‍

The orchestration layer doesn't need to be Class 4 or Class 5—it's a meta-layer that manages complexity across heterogeneous infrastructure.

‍

What This Means For Your Migration

If you're replacing a BroadSoft or Metaswitch platform, here's what you need to figure out:

‍

Are you running Class 4, Class 5, or both?

‍

• If you're a regional carrier routing calls from multiple providers, you're almost certainly running Class 4 functions
• If you're a service provider offering voicemail and call forwarding to end users, you're running Class 5
• If you're a large carrier or service provider, you're probably running both (possibly on separate platforms)

‍

Which functions are critical to your business?

‍

• Class 4 carriers care about routing intelligence, CDR accuracy, and failover speed
• Class 5 providers care about feature richness, user provisioning, and billing integration
• Both care about compliance and reliability

‍

Can your replacement handle both?

‍

• Cisco's path: typically requires separate platforms for Class 4 and Class 5
• Microsoft Teams: designed for Class 5 enterprise features, doesn't handle Class 4 transit
• Orchestration platforms: handle both by sitting above carrier/provider infrastructure and intelligently routing calls

‍

Real-World Migration Scenarios

Scenario 1: Regional Carrier on BroadSoft You're running BroadSoft for Class 4 transit routing. You have 20+ provider relationships and route thousands of calls per second. You need a Class 4 replacement that handles complex dial plans and scales to your volume.

‍

Migration option: Migrate to an orchestration platform that sits above your existing providers and intelligently routes calls based on your dial plans. Decommission BroadSoft. Faster cutover because you're not moving actual call handling—you're replacing the logic layer.

‍

Scenario 2: Hosted PBX Provider on Metaswitch You're running Metaswitch for Class 5 subscriber features (voicemail, call transfer, CID, etc.) serving 50,000 SMB customers. Your end users don't care what platform powers their features; they just care that voicemail works.

‍

Migration option: Move to a modern Class 5 platform (cloud-based or on-premises) that supports API-driven provisioning and integrates with your existing billing system. Or migrate to a unified platform that handles both Class 4 and Class 5, reducing operational overhead.

‍

Scenario 3: Large Service Provider with Both You're running BroadSoft for Class 4 (transit routing from partner carriers) and Metaswitch for Class 5 (subscriber features for your MVNO and VoIP service). You have deep integrations in both.

‍

Migration option: Evaluate orchestration platforms that can abstract away the Class 4/Class 5 distinction, potentially replacing both platforms with a single unified management layer. This reduces operational complexity and licensing costs over time.

‍

The Bottom Line

Class 4 and Class 5 describe two different jobs in telecom infrastructure. Historically, carriers built separate platforms because the engineering requirements were so different. Today, that separation is increasingly optional—modern orchestration platforms can handle both functions without forcing you into vendor lock-in or expensive rearchitecting.

‍

When evaluating your replacement, ask yourself:

‍

1. What am I actually using each platform for?
2. Can I consolidate, or do I truly need two separate systems?
3. Does my new platform need to be Class 4, Class 5, or both?
4. Will it scale to my current volume without requiring another migration in three years?

‍

The vendors trying to sell you their next platform may not ask these questions. You should.