If you’re building or operating a cloud telephony business — whether as an ITSP, a hosted VoIP provider, or an MSP adding voice to your portfolio — the Class 5 softswitch is the platform your entire subscriber experience rides on. It’s not a background component. It governs whether your customers can reach voicemail, trigger IVR menus, forward calls to their mobile, or join a conference bridge. The architecture you choose, and the features it supports, determine both your service quality and your revenue ceiling.
This guide covers the full picture: what a Class 5 softswitch actually does under the hood, the subscriber features that drive retention, the multi-tenancy and billing integrations that make a service provider business operationally viable, and the build roadmap if you’re considering a custom platform. It’s written for operators who need to make real decisions, not for people who just want a definition.
Understanding Class 5 Softswitch: The Subscriber-Facing Core of Cloud Telephony
A Class 5 softswitch is the layer of your VoIP network that deals directly with end users — authenticating subscribers, managing their registrations, routing their calls, and delivering the feature set they pay for. If Class 4 is your carrier highway (handling bulk, long-distance transit between networks), Class 5 is the on-ramp and off-ramp that connects individual subscribers to that highway.
Class 5 softswitches manage local call delivery and advanced features for end users. In practice, this means the platform handles SIP registration from a subscriber’s IP phone, softphone, or mobile client; authenticates credentials; determines routing; applies features like call forwarding or voicemail; and generates Call Detail Records (CDRs) for billing. None of that happens at the Class 4 layer, which is purely concerned with carrier-to-carrier transit.
Historically, these functions lived in hardware central office switches. A Class 5 switch served as a telephone routing exchange connecting the calling client to the called client through an IP network and the Public Switched Telephone Network (PSTN). The modern software-based equivalent does all of this on commodity Linux servers in a cloud environment — without proprietary hardware, without per-port licensing tied to physical capacity, and without the capital expenditure of legacy infrastructure.
The practical result for cloud telephony providers: a Class 5 switch can handle registration, call setup, routing, and teardown while ensuring compatibility with softphones, mobile phones, SIP trunks, and IP phones. That compatibility across endpoint types is fundamental — your subscribers might be on a desk phone, a mobile SIP client, or a browser-based WebRTC softphone, and the switch needs to handle all of them transparently.
Who Deploys a Class 5 Softswitch?
The use cases span a wide range of operators. ISPs offering bundled VoIP services to residential and small business customers require Class 5 softswitches for local call management and value-added features. UCaaS providers building integrated voice, video, and messaging platforms use them as the call control core. ITSPs launching calling card, callback, or hosted PBX products all depend on Class 5 infrastructure. The common thread: any service that involves subscriber accounts, per-user features, and retail billing needs a Class 5 platform.
Key Features of a Cloud-Ready Class 5 Softswitch
A cloud-ready Class 5 softswitch must do more than route calls. The feature set determines your competitive positioning — whether you can serve residential, SMB, and enterprise segments from a single platform, and whether subscribers stay or churn when a competitor offers more functionality.
Core features should include call forwarding, call waiting, voicemail, DND, IVR, conferencing, and number portability support. Beyond these baseline capabilities, the platform should support DID management, call recording, time-based routing, hunt groups, and auto-attendants. Advanced features such as call analytics, real-time monitoring, customizable dial plans, and white-label portals can help differentiate your offerings.
Here’s how to think about each feature category from an operator’s perspective:
Subscriber Authentication and Security
Class 5 softswitches offer strong call authentication mechanisms to verify user identities before call initiation, preventing fraudulent usage and protecting VoIP accounts from unauthorized access. This matters operationally because toll fraud on a poorly secured VoIP platform can generate thousands of dollars in unexpected carrier charges overnight. Essential security capabilities include SIP authentication, IP whitelisting, rate limiting, and anomaly detection.
Hosted PBX and IP Centrex
For business users, Class 5 switching offers hosted PBX and IP Centrex services without the need for on-site hardware. It supports hunt groups, auto attendants, and role-based call control. This is the feature tier that lets you compete in the SMB market without asking customers to buy and manage on-premise equipment. The switch provisions these features per tenant, allowing an MSP to offer fully managed hosted PBX to hundreds of business accounts from a single platform.
Call Center Features
Call center support includes ACD (automatic call distribution), IVR integration, live call monitoring, and agent performance reporting. For ITSPs targeting contact center customers or adding contact-center-as-a-service to their portfolio, this feature set is a meaningful revenue differentiator. It elevates the platform from a simple voice pipe to a business productivity tool.
Calling Card and Prepaid Services
Class 5 softswitches support calling card platforms with PIN validation, intelligent routing, call holding during transfers, and call forwarding to alternate numbers. For ITSPs targeting diaspora communities or international calling markets, calling card services remain a viable and high-margin business model — and they require the Class 5 layer to handle authentication, balance deduction, and call routing in real time.
Architecture Overview: Signaling, Media Handling, and Database Layers
A Class 5 softswitch is not a monolithic application. Understanding the component architecture matters when you’re evaluating scalability, redundancy options, and integration points — because the design of these layers determines where bottlenecks form and how you address them.
A softswitch comprises two core components: a media gateway or access gateway for processing media streams, and a call agent or call feature server for handling call control, routing, and signalling. In modern cloud deployments, these functions are further decomposed:
Signaling Layer
The signaling layer handles SIP message processing — REGISTER, INVITE, BYE, and the full session lifecycle. Tools like Kamailio or OpenSIPS typically serve as the SIP proxy and registrar here. A SIP proxy like Kamailio is added to load-balance calls across multiple application servers and assists with NAT traversal. This layer is stateless and can be horizontally scaled independently — critical for high-registration environments where thousands of subscribers are constantly re-registering.
Media and Application Layer
The media/application layer handles the actual voice processing: codec negotiation, transcoding, conference bridge mixing, voicemail recording, and IVR prompt playback. FreeSWITCH and Asterisk are the most widely deployed open-source engines at this layer. Softswitches handle codec negotiation between endpoints to establish a VoIP session using a commonly supported voice codec. This is also where call admission control (CAC) lives — CAC restricts calls during network congestion and allocates bandwidth dynamically based on traffic patterns, ensuring good QoS by minimizing latency, jitter, and packet loss.
Database Layer
The database layer stores subscriber profiles, routing tables, dial plans, CDRs, and billing data. The architecture consists of a database server, telephony server, and a web server for administration, agent, customer, and online sign-up. Usually these servers are hosted on the same physical hardware but can be distributed across multiple servers to increase capacity. For production deployments serving thousands of subscribers, database replication and read/write splitting become important — a single PostgreSQL or MySQL primary node is a single point of failure and a read-bottleneck under load.
Session Border Controller (SBC)
In cloud deployments, a Session Border Controller sits at the edge of the network to handle NAT traversal, topology hiding, SIP normalization, and DDoS protection. The SBC is the public face of your signaling infrastructure — it’s where SIP trunks connect, where remote subscribers register, and where security policies are enforced before traffic reaches your core switch. Some Class 5 platforms include SBC functionality natively; others require it as a separate component in the architecture.
Multi-Tenancy and White-Label Capabilities for Service Providers
Multi-tenancy is not a convenience feature — it’s a business model enabler. Without it, you cannot serve multiple businesses from a single platform, cannot offer reseller tiers, and cannot build a recurring-revenue ITSP operation at any scale. The architecture choice between shared-tenant and logically-isolated tenancy shapes your cost structure, security posture, and customization ceiling from day one.
The modular architecture, inbuilt multi-tenant support, integrated VoIP billing, advanced call center features, and several other components make a Class 5 softswitch solution more competitive. In a properly implemented multi-tenant Class 5 platform, each tenant gets an isolated namespace: their own SIP domains, extensions, dial plans, voicemail boxes, IVR trees, and billing configuration — all managed from a single administrative database, but logically separated so tenant A cannot see or affect tenant B.
Role-Based Access and Reseller Hierarchy
Centralized control with a single dashboard allows you to build a powerful system with role-based access for administrators, resellers, and end-users, along with real-time monitoring to keep track of system performance and usage. The reseller model is particularly important for MSPs: you provision a reseller account with a capped number of extensions and a rate deck, the reseller creates and manages their own sub-accounts, and you simply collect the margin. The platform handles the rest.
White-Label Portals and Branding
Proper API integration and white-labeling allow you to offer branded, personalized solutions to every customer. In practice, this means your resellers and enterprise customers interact with a portal that carries their logo, their color scheme, and their domain — not yours. Subscriber-facing elements like voicemail notification emails, invoices, and self-service portals should all be fully brandable. This is the difference between being a white-label ITSP and being a vendor that shows up visibly in your customer’s experience.
The appearance of user interfaces can be customized, supporting the look and feel of the corporate identity, with multiple languages supported through language packs including resource files, localized images, and voice prompts. Language pack support also matters if you’re targeting non-English-speaking markets — your IVR prompts and portal UI need to match your customers’ operating language.
Essential Subscriber Features: Voicemail, Call Forwarding, IVR, and Find-Me-Follow-Me
These features are what subscribers actually care about. They’re also the features that differentiate a professional ITSP offering from a bare SIP trunk. Getting them right — reliable, easy to configure, and genuinely useful — is how you reduce churn in the SMB and residential segments.
Voicemail and Unified Messaging
Class 5 switches can integrate voicemail and unified messaging services. The minimum viable implementation stores voicemail audio and delivers notification emails. The competitive implementation adds voicemail-to-email with audio attachment, voicemail-to-text transcription, unified inbox across email and voicemail, and visual voicemail via the subscriber portal or mobile app. Voicemail-to-text, in particular, is a strong SMB differentiator — subscribers can read messages during meetings without playing audio.
Call Forwarding and Time-Based Routing
Call forwarding sounds basic, but the implementation complexity ranges significantly. A proper Class 5 platform supports unconditional forwarding, forward-on-busy, forward-on-no-answer, and simultaneous ring. Time-based routing adds business hours logic — route to the main extension during business hours, to an after-hours IVR or voicemail outside them. Originator authentication based on IP address, user/password, caller ID, PIN code, and DID number, along with dialed number and CLI manipulation, enables flexible dial plan control for these scenarios.
IVR (Interactive Voice Response)
IVR is both a subscriber feature and a platform capability that enables an entire class of business VoIP use cases. Softswitches also support advanced call control capabilities like call forking, which makes find-me/follow-me services possible. A well-implemented IVR system in a Class 5 softswitch allows tenants to build multi-level menus, record custom prompts, route based on DTMF input, and integrate with external systems via HTTP callbacks (for things like CRM lookup before routing). For call centers, IVR is the entry point to ACD queues — and the quality of the IVR directly affects first-call resolution rates.
Find-Me-Follow-Me
Find-me-follow-me is the feature that makes a subscriber reachable regardless of where they are. When an incoming call arrives, the system sequentially or simultaneously rings a configured list of destinations — office phone, mobile, home phone — until the subscriber answers or the call falls to voicemail. Integrated class 4 and class 5 features in softswitches eliminate the need for additional SSPs or SCPs to deploy these revenue-generating services. For SMB customers, this is a genuine productivity feature. For ITSPs, it’s a retention mechanism — subscribers who rely on find-me-follow-me don’t port away easily.
Conferencing
Conferencing at the Class 5 layer means managed conference bridges hosted by your platform — not third-party conferencing services. A VoIP softswitch offers distinct yet cost-effective features like call recording, monitoring, queuing, online faxing, instant messaging, audio, video, and conference calls. 3-way calling is typically built into the media layer; dedicated conference rooms with dial-in numbers, moderator controls, and recording are a higher-tier capability requiring dedicated media server resources. Both are genuine upsell opportunities for business accounts.
Integration with VoIP Billing and OSS/BSS Platforms
Billing integration is where many Class 5 softswitch deployments succeed or fail operationally. A technically excellent call routing engine that produces unreliable CDRs, doesn’t support your billing model, or requires manual reconciliation will create subscriber disputes and administrative overhead that erodes your margins. The billing layer needs to be a first-class design consideration, not an afterthought.
| Integration Point | What It Does | Protocol / Method | Operational Impact |
|---|---|---|---|
| Real-Time CDR Generation | Captures call start/end time, duration, source, destination, codec per call leg | Syslog, RADIUS, database write | Required for accurate per-minute billing and dispute resolution |
| Prepaid Balance Engine | Deducts credit in real time during live calls; terminates call when balance reaches zero | RADIUS / DIAMETER / internal API | Prevents credit loss on prepaid accounts; essential for calling card services |
| Postpaid Rating Engine | Applies rate tables to completed CDRs; generates invoices on billing cycle | Internal rating or external billing platform API | Enables subscription and postpaid business models |
| DID Management | Assigns, routes, and bills phone numbers to subscriber accounts | REST API to DID provider; internal provisioning DB | Automates number assignment; enables self-service DID selection |
| Payment Gateway | Processes credit card, ACH, or voucher payments against subscriber accounts | HTTPS API to Stripe, PayPal, etc. | Enables self-service top-up and automated recurring billing |
| OSS/BSS Integration | Syncs subscriber provisioning, service activation, and billing with external business systems | RADIUS, DIAMETER, CDR mediation, REST/SOAP APIs | Reduces manual provisioning effort; enables flow-through activation |
| CRM Integration | Links call records and subscriber activity to customer accounts in CRM | REST API / webhooks | Improves support quality; enables call analytics per customer |
Integrated VoIP billing systems allow service providers to manage subscriptions, generate invoices, and track payments. Class 5 softswitches often support flexible billing models such as prepaid, postpaid, or hybrid, with multiple currencies and tax configurations. The currency and tax configuration is non-trivial for ITSPs serving multiple countries — VAT rates, GST, regulatory fees, and local tax rules need to be applied correctly at invoice generation time.
Protocol Stack: SIP Trunking, WebRTC, and Mobile SIP Clients
The protocol stack your Class 5 softswitch supports directly determines which endpoint types your subscribers can use — and therefore which market segments you can serve. A platform limited to desk-phone SIP clients cannot compete in the mobile-first UCaaS market. A platform without WebRTC cannot offer browser-based calling without additional middleware.
SIP Trunking
SIP is the foundation. Voice peerings can be established either by SIP trunks straight from the Class 5 platform or via third-party SS7/TDM gateways towards the PSTN network. Your SIP trunking connections — both upstream to carriers for PSTN access and downstream to business customers with their own PBX systems — all ride the SIP layer. The softswitch needs to handle SIP normalization gracefully: different carriers and endpoints implement SIP slightly differently, and a robust platform handles header manipulation, codec re-negotiation, and interop edge cases without dropping calls.
WebRTC
WebRTC enables browser-based voice and video calling without plugins or client installs. The open architecture of a carrier-grade Class 5 platform based on standardized protocols and open APIs allows fast and cost-effective deployment of various IP Telephony and Rich Communication services, like Video Telephony, Presence/IM, and WebRTC-based applications. For service providers, WebRTC unlocks use cases like browser-based softphones, click-to-call widgets embedded in CRM or e-commerce platforms, and web portals where subscribers can make calls without installing anything. The technical requirement is a TURN/STUN server for NAT traversal and a WebRTC-to-SIP gateway or native WebRTC support in the media server.
Mobile SIP Clients
Mobile SIP clients — both iOS and Android — extend your subscribers’ phone service to their smartphones, turning a mobile device into a business extension. The Class 5 platform needs to support push notification wakeup (via APNS for iOS and FCM for Android) so that SIP clients can receive inbound calls even when the app is backgrounded. Without push support, mobile SIP registration becomes unreliable and inbound calls are missed. The platform also needs to handle the network transition gracefully when a subscriber moves between Wi-Fi and cellular — call continuity across network changes requires proper SIP re-INVITE handling.
Codec Support
The platform supports codecs like G.729, ulaw (G.711u), alaw (G.711a), iLBC, and GSM. Codec selection matters for both call quality and bandwidth consumption. G.711 delivers the best quality but uses roughly 80 kbps per call; G.729 compresses to about 8 kbps at the cost of some audio fidelity. For environments with constrained uplinks (mobile users, remote sites with limited bandwidth), G.729 support and transcoding capability are necessary. Transcoding adds CPU load to the media layer, so capacity planning needs to account for the transcoding mix in your subscriber population.
Scaling Your Class 5 Softswitch for Thousands of Concurrent Subscribers
Scaling a Class 5 softswitch is not primarily a hardware problem — it’s an architecture problem. A monolithic single-server deployment will hit a ceiling; a properly decomposed architecture can scale horizontally to serve tens of thousands of subscribers with consistent call quality.
Virtualization provides inherent high availability, geographic redundancy, and multi-tenancy capabilities. Service providers can quickly deploy softswitch network functions on demand. The key architectural principles for cloud-scale deployments are:
Horizontal Scaling of the Signaling Layer
The SIP proxy layer (Kamailio/OpenSIPS) is the first layer to scale under load — it handles every SIP REGISTER, INVITE, and OPTIONS from every subscriber. Because these proxies are stateless (or can be made stateless with appropriate distributed state management), you can add nodes behind a load balancer as registration volume grows. A Kamailio cluster with shared database state can handle registrations in the hundreds of thousands per node.
Media Server Farm
Media servers (FreeSWITCH or Asterisk nodes) are CPU-bound — each concurrent call leg consumes CPU for RTP handling, codec processing, and feature execution. Rather than one large media server, cloud deployments use a farm of smaller nodes with a dispatcher or load balancer directing calls to nodes with available capacity. A SIP proxy like Kamailio load-balances calls across multiple application servers. This architecture lets you add media server capacity to handle traffic spikes without re-architecting the platform.
Geographic Redundancy
Multi-national operators can manage centralized softswitch intelligence in the cloud while distributing media gateways at local PoPs. For ITSPs with subscribers in multiple regions, placing media nodes close to subscriber clusters reduces RTP path length and therefore reduces latency and jitter. Signaling can traverse longer paths (TCP/TLS over the internet is acceptable for SIP signaling latency), but media should stay as local as possible. In case of node failure, call continuation and CDR consistency are guaranteed via data synchronization over dedicated network links.
High Availability and Failover
High availability architecture is essential. Look for solutions that support redundancy, geo-redundancy, and automatic failover to minimize downtime. Real-time monitoring tools help detect issues early and maintain service continuity. For carrier-grade deployments, the target is five-nines (99.999%) availability — roughly five minutes of downtime per year. Achieving that requires active-active or active-standby configurations at every layer, automated health checks with instant failover, and database replication with sub-second lag.
If you’re designing your Class 5 deployment architecture and want a technical second opinion, our team at Gama Infotech has deep experience in telecom infrastructure design. Reach out to discuss your subscriber volume targets and redundancy requirements.
Build Roadmap: Phases, Tech Stack, and Development Timeline
The build-vs-buy decision for a Class 5 softswitch is not a simple one. Off-the-shelf platforms reduce time-to-market but constrain customization. Custom builds give you full control over architecture and features but require telecom development expertise and realistic time commitments. A hybrid approach — customizing or extending an open-source foundation — is often the practical middle ground.
Phase 1: Core Infrastructure (Months 1–3)
The foundation consists of the SIP signaling layer, media processing engine, subscriber database, and basic web administration portal. Technology choices at this phase define your long-term architecture:
SIP Proxy / Registrar: Kamailio or OpenSIPS for high-performance stateless signaling, NAT traversal, and load balancing. Both are production-proven in carrier environments and actively maintained. Media / Application Server: FreeSWITCH for complex feature execution (IVR, conferencing, voicemail, call recording) or Asterisk for environments where the ecosystem of extensions (AGI, AMI) is valuable. Database: PostgreSQL or MySQL for subscriber data, CDRs, and routing tables. Redis for session state and real-time balance tracking. Admin Portal: A web interface for subscriber management, DID assignment, dial plan configuration, and reporting.
Realistic timeline for a working call-in / call-out platform with basic subscriber features: 8–12 weeks with an experienced VoIP development team.
Phase 2: Billing and Provisioning Integration (Months 3–5)
This phase adds the commercial layer: CDR generation and export, real-time balance deduction for prepaid accounts, rate table management, invoice generation, and payment gateway integration. An up-to-date balance can be provided to subscribers at the precision of milliseconds by using the real-time rating engine, working for both prepaid and postpaid billing models. This is also when DID management integration is built — connecting to DID providers via API so numbers can be provisioned and assigned automatically.
Phase 3: Subscriber Features and Portal (Months 5–8)
Phase 3 delivers the feature set subscribers actually use: voicemail with email delivery, call forwarding rules, IVR builder, find-me-follow-me configuration, call recording, and the self-service subscriber portal. This phase is often the longest because feature completeness and UX quality directly affect subscriber satisfaction and churn. Cutting corners here to meet a launch deadline creates support burden that compounds over time.
Phase 4: Multi-Tenancy, White-Label, and Reseller (Months 8–12)
The final phase adds the multi-tenant infrastructure required to operate as a commercial ITSP: isolated tenant namespaces, reseller account tiers, branded portal theming, reseller rate management, and the administrative tooling for onboarding and managing large numbers of accounts. This phase is technically complex because it requires enforcing tenant isolation at every layer — signaling, media, billing, and storage — without degrading performance for any single tenant.
A realistic custom Class 5 softswitch, built from open-source foundations with an experienced team, takes 9–12 months to reach a stable, production-grade state. Extending or customizing an existing platform can reduce that to 3–6 months depending on how closely the base platform matches your requirements. At Gama Infotech, we work with ITSPs and cloud telephony operators at every stage of this roadmap — from architecture design through deployment and ongoing support.
Class 5 vs. Class 4: When You Need Both in Your Network
The relationship between Class 4 and Class 5 is complementary, not competitive. A call originating in one country may be routed by a Class 4 softswitch to another country, where a Class 5 softswitch takes over to deliver the call to the recipient. Understanding when you need one, the other, or both is a fundamental network design decision.
| Dimension | Class 4 Softswitch | Class 5 Softswitch |
|---|---|---|
| Primary role | Carrier-to-carrier transit; wholesale call routing | Subscriber-facing services; retail call management |
| Who it serves | Other carriers, CLECs, ITSPs buying termination | End users — residential, SMB, enterprise |
| Key metrics | CPS (calls per second), concurrent calls, latency | Subscriber count, features, QoS per session |
| Billing model | Wholesale per-minute rates; inter-carrier settlement | Retail per-minute, subscription, prepaid, postpaid |
| Feature set | LCR, protocol conversion, fraud detection, CDRs | Voicemail, IVR, call forwarding, conferencing, PBX features |
| Authentication | IP-based, trunk-level | Per-subscriber SIP credentials, PIN, caller ID |
| Scalability ceiling | Millions of calls/day with proper hardware | Scales per subscriber + concurrent call ratio |
| When you need it | Selling wholesale minutes, buying carrier termination | Selling retail VoIP, hosted PBX, UCaaS |
| Can operate standalone? | Yes, for pure wholesale operations | Yes for on-net calls; needs Class 4 or SIP trunk for PSTN |
Most ITSPs eventually need both layers. Class 4 switches handle carrier-to-carrier transit along with wholesale routing. Class 5 softswitches manage end-user services, subscriber control, feature addition, and retail VoIP call processing. The typical deployment pattern: your Class 5 softswitch handles subscriber authentication, features, and on-net routing; when a subscriber calls an off-net PSTN number, the Class 5 passes the call to a Class 4 or directly to a SIP trunk for carrier termination.
For startups, buying wholesale termination from a carrier via SIP trunk is simpler than operating your own Class 4 infrastructure. As call volume grows and margin pressure increases, internalizing Class 4 functionality becomes economically attractive — but it requires additional technical operations capability. The honest framing: start with Class 5 plus SIP trunks, evaluate Class 4 when your monthly termination spend justifies the infrastructure investment.
Ready to Build Your Class 5 Softswitch?
A Class 5 softswitch is not a commodity product you can evaluate purely on feature checklists. The architecture decisions made at the design stage — how tenancy is isolated, how billing is integrated, how the media layer scales, how the SBC is positioned — determine your operational costs, your scalability ceiling, and your ability to serve the market segments you’re targeting. Getting those decisions right requires experience with real deployments, not just familiarity with the technology on paper.
At Gama Infotech, we work with VoIP service providers, ITSPs, and cloud telephony operators to design, build, and deploy Class 5 softswitch platforms tailored to their specific subscriber base, traffic model, and revenue goals. Whether you’re evaluating open-source foundations, extending an existing platform, or designing a custom build from scratch, we bring the architecture expertise and development depth to get it done correctly the first time.
Contact our team at sales@gamainfotech.com or reach us at +1-800-581-3963 to start the conversation. We’re happy to review your current architecture, evaluate your requirements, and give you an honest assessment of the best path forward for your deployment.
Frequently Asked Questions
What is the difference between a Class 4 and Class 5 softswitch?
A Class 4 softswitch handles carrier-to-carrier call routing for wholesale and long-distance traffic — it connects network operators but doesn’t serve end users directly. A Class 5 softswitch serves end users: it manages SIP registrations, subscriber authentication, call features (voicemail, IVR, call forwarding), and retail billing. Most ITSPs need both — Class 5 for subscriber services, and Class 4 or SIP trunks for PSTN termination.
How many concurrent calls can a Class 5 softswitch handle?
It depends on the architecture and hardware. A single FreeSWITCH or Asterisk media server on modern hardware can handle several hundred to a few thousand concurrent calls depending on codec mix and feature load (transcoding and conferencing are CPU-intensive). Production deployments use a farm of media servers behind a load balancer, allowing horizontal scaling to tens of thousands of concurrent calls. Signaling layers based on Kamailio or OpenSIPS can handle far higher registration and call setup volumes.
What is multi-tenancy in a Class 5 softswitch, and why does it matter for service providers?
Multi-tenancy allows a single Class 5 softswitch platform to serve multiple independent customers (tenants) with isolated SIP domains, extensions, dial plans, billing, and feature configurations. It matters because it’s the foundation of a scalable ITSP business model — you can serve hundreds of business customers and resellers from one platform rather than operating separate infrastructure per customer. It also enables white-label reseller programs where partners manage their own sub-accounts under your platform.
Can a Class 5 softswitch support both prepaid and postpaid billing?
Yes. A properly designed Class 5 softswitch integrates with a billing engine that supports both models. Prepaid billing requires real-time balance deduction during the call — the billing engine decrements the subscriber’s credit as the call progresses and terminates the call when the balance runs out. Postpaid billing rates completed CDRs against a rate table and generates invoices on a billing cycle. Hybrid models (subscription plus per-minute overage) are also common for SMB VoIP services.
How long does it take to build a custom Class 5 softswitch?
A realistic custom Class 5 softswitch built on open-source foundations (FreeSWITCH, Kamailio, PostgreSQL) takes 9–12 months to reach a stable, production-grade state with a full feature set including multi-tenancy, billing integration, and subscriber portal. Extending or customizing an existing platform can reduce that to 3–6 months. The timeline depends heavily on the scope of subscriber features required, the complexity of billing integration, and whether the team has prior telecom development experience.