If you’re building or scaling a VoIP business, the softswitch isn’t just another component in your stack — it’s the decision engine that determines whether your infrastructure can support growth, deliver quality, and remain profitable over time. This guide is written for the technical and business leaders who make those architecture decisions: CTOs at ITSPs, telecom startup founders evaluating their first platform, and wholesale VoIP architects looking at a re-architecture.
We’ll cover the full lifecycle: softswitch definition and architecture, class selection, protocol requirements, scalability design, build-vs-buy trade-offs, OSS/BSS integration, security and compliance, vendor evaluation, and realistic cost modeling. No filler, no vendor cheerleading — just the information you need to make defensible decisions.
What Is a VoIP Softswitch? Definition, Architecture & Role in Modern Telecom
A VoIP softswitch is a software-based platform that performs call routing, signaling control, and session management over IP networks — replacing the role once filled by dedicated TDM hardware switches. It sits at the heart of every carrier-grade VoIP deployment, making real-time decisions about where each call goes, which codec to use, and how to bill for it.
According to AWS’s Real-Time Communication reference architecture, a softswitch provides the intelligence for establishing, maintaining, and routing voice calls within or outside the enterprise. Every subscriber must register with the softswitch to send or receive calls, and it continuously tracks subscriber state and reachability using supporting network components.
Architecturally, a modern softswitch separates two planes of operation:
The Signaling Plane handles call setup, modification, and teardown. It processes SIP (Session Initiation Protocol) messages, manages registration, enforces dial plans, applies routing logic, and interfaces with the billing system to track Call Detail Records (CDRs). This is where your business logic lives: Least Cost Routing (LCR), number translation (ENUM lookups), fraud rules, and quality-based routing all operate here.
The Media Plane handles the actual voice packets. RTP (Real-time Transport Protocol) streams carry audio between endpoints, while the softswitch or an associated media gateway manages transcoding between codecs, handles NAT traversal, and enforces encryption via SRTP. In high-performance deployments, the media plane is deliberately separated from the signaling plane — running on dedicated media servers or RTP proxies — to prevent signaling bottlenecks from degrading audio quality.
Between these two planes, a well-architected softswitch also incorporates a Session Border Controller (SBC) at the network edge. The SBC sits at the edge of the voice network, tracking all incoming and outgoing traffic across both control and data planes, absorbing malicious traffic before it can reach core softswitch infrastructure. Most modern SIP trunks are established through SBCs rather than direct connections to the core softswitch.
Understanding this two-plane architecture matters before you make any procurement or build decision. A platform that conflates signaling and media processing on a single node will hit scalability limits much earlier than one that separates them — and retrofitting that separation later is painful.
Class 4 vs Class 5 Softswitch: Which Does Your Business Need?
The single most important architectural decision for any ITSP or carrier is whether you need a Class 4 softswitch, a Class 5 softswitch, or both. These aren’t just marketing labels — they represent fundamentally different traffic models, feature sets, and infrastructure requirements.
Class 4 softswitches handle long-distance calls and wholesale traffic, focusing on routing calls across large networks, while Class 5 softswitches manage local call delivery and advanced features for end users. A call originating in one country is typically routed by a Class 4 softswitch to another country, where a Class 5 softswitch takes over to deliver the call to the recipient.
| Dimension | Class 4 Softswitch | Class 5 Softswitch |
|---|---|---|
| Primary Function | Wholesale transit routing between carriers and across long distances | Retail voice delivery to end users (residential and business) |
| Traffic Model | High-volume, carrier-to-carrier, international long distance | Local and national calls, PBX-style service delivery |
| Key Features | LCR, protocol transcoding, CDR generation, inter-carrier billing, fraud detection | IVR, voicemail, call forwarding, calling cards, conferencing, auto-attendant, DID management |
| Protocol Support | SIP, H.323, MGCP — inter-network protocol conversion is essential | SIP primarily, with SIP-to-PSTN gateway capability |
| Scalability Focus | Concurrent calls (thousands to tens of thousands), CPS (calls per second) | Subscriber count, feature richness per user, multi-tenancy |
| Typical User | Wholesale VoIP carrier, international transit provider, Tier 1/2 operator | ITSP, hosted PBX provider, UCaaS platform, residential VoIP provider |
| Billing Model | Per-minute wholesale billing, inter-carrier settlements | Per-user monthly subscriptions, prepaid calling cards, usage-based |
| Infrastructure Cost | Higher — carrier-grade hardware or bare metal for peak concurrency | Moderate — cloud-deployable, scales with subscriber base |
| When to Use | You route minutes for other carriers, run international traffic, or operate a wholesale termination business | You sell phone numbers and features directly to businesses or consumers |
The practical implication: Class 4 softswitches are built to handle thousands of concurrent calls with minimal latency — this scalability makes them ideal for wholesale VoIP providers and international carriers. Class 5 systems trade raw call volume capacity for feature depth, managing per-user state like voicemail boxes, call queues, and IVR menus.
A third option worth considering is a hybrid softswitch, which combines Class 4 transit capabilities with Class 5 subscriber management. This is the architecture most ITSPs eventually converge on as they grow: you need the retail features to win enterprise customers, but you also need efficient wholesale routing to control termination costs. The trade-off is complexity — hybrid platforms require more careful capacity planning and have more integration surface area to maintain.
If you’re a startup with limited capital, start with Class 5 and purchase wholesale transit from an upstream carrier. Trying to operate Class 4 infrastructure at low traffic volumes is economically inefficient. If you’re a wholesale carrier or transit provider, Class 4 is your core platform and Class 5 features are unnecessary overhead.
Core Components of a VoIP Softswitch System
A production-grade VoIP softswitch is never a single process or binary — it’s a system of coordinated components. Understanding what each component does helps you evaluate vendor platforms honestly and design custom architectures that don’t have hidden single points of failure.
SIP Proxy / Registrar
The SIP proxy is the entry point for all signaling traffic. It receives INVITE requests, handles user registration (associating SIP URIs with IP addresses), applies routing logic, and forwards requests to the appropriate destination. In high-traffic deployments, this is typically implemented with OpenSIPS or Kamailio — both capable of managing tens of thousands of simultaneous calls with minimal resource consumption, making them well-suited for carrier-grade environments.
Media Server / Back-to-Back User Agent (B2BUA)
Where the SIP proxy routes signaling, the media server terminates and re-originates call legs — acting as a B2BUA. FreeSWITCH is a widely-deployed open-source platform that lets you directly manage SIP, RTP, codecs, media flows, dialplans, and routing logic. It handles conferencing, IVR execution, call recording, codec transcoding, and DTMF detection. FreeSWITCH and Asterisk are the dominant open-source options; commercial deployments often use purpose-built media servers for reduced CPU overhead at high concurrency.
Session Border Controller (SBC)
The SBC sits at the network perimeter and handles several critical functions simultaneously: topology hiding (concealing internal infrastructure from external peers), NAT traversal for endpoints behind firewalls, protocol normalization (fixing non-compliant SIP), and security enforcement (rate limiting, IP blacklisting, DDoS mitigation). Every production softswitch deployment should have an SBC between its core and any external interconnect. Without one, your signaling plane is exposed directly to the public internet.
Media Gateway
Required when your network interfaces with the PSTN. The PSTN gateway converts signaling between SIP and SS7, and media between RTP and TDM using CODEC transcoding. PSTN gateways always sit at the edge, close to the PSTN network. For SIP trunking (which bypasses TDM entirely), a gateway may not be needed — but you still need the SBC for border control.
Billing and Rating Engine
CDRs generated by the softswitch feed a rating engine that calculates per-minute costs, applies customer pricing plans, and posts charges to subscriber accounts. This can be a tightly integrated module (common in commercial platforms) or a separate system connected via API or database replication. Real-time billing — where credit limits are enforced mid-call — requires a low-latency connection between the softswitch and the billing engine, typically via DIAMETER or a proprietary credit control interface.
Routing Database
LCR (Least Cost Routing) logic requires a routing database that maps destination prefixes to carrier routes with associated cost, quality, and priority data. This database is queried in real time during call setup. At Class 4 scale, this lookup must complete in milliseconds — typically achieved through in-memory caching of routing tables or purpose-built databases optimized for prefix lookups.
Monitoring and Alerting Infrastructure
A softswitch without observability is a black box you can’t operate at SLA level. Production deployments require real-time visibility into calls per second (CPS), concurrent session count, Answer-Seizure Ratio (ASR), Average Call Duration (ACD), post-dial delay (PDD), and codec distribution. At minimum, integrate Prometheus for metrics collection, Grafana for dashboards, and an alerting layer that fires on degraded ASR or approaching concurrency limits before they become outages.
Protocol Requirements: SIP, RTP, WebRTC, ENUM & Signaling Standards
Protocol selection isn’t academic — the protocols your softswitch supports determine which devices, carriers, and use cases you can serve. SIP is non-negotiable in 2025, but the full protocol stack runs deeper than most architects initially plan for.
SIP (Session Initiation Protocol)
SIP (defined in RFC 3261) is the dominant signaling protocol for VoIP and handles session setup, modification, and teardown. Your softswitch must handle the full range of SIP method types (INVITE, REGISTER, OPTIONS, BYE, CANCEL, REFER, NOTIFY, SUBSCRIBE) and deal gracefully with the wide variance in SIP implementations across devices and carriers. Non-compliant SIP from poorly implemented endpoints is one of the leading operational headaches in production — the SBC’s protocol normalization layer absorbs most of this.
Transport matters: SIP over UDP is still common but should be considered legacy. Production systems should support SIP over TCP and TLS. Using TLS for SIP is a well-established best practice supported by most modern SIP software, but it requires every proxy and server on the path to support and be configured for TLS — any unencrypted hop in the chain breaks the security model.
RTP and SRTP (Media Transport)
While SIP handles signaling, RTP manages the transmission of media — voice and video. SRTP adds encryption to ensure privacy, making it vital for HIPAA or GDPR compliance. Every deployment handling sensitive communications should enforce SRTP. The computational overhead of SRTP encryption is negligible on modern hardware, and there’s no legitimate reason to run unencrypted media in a production system today.
Codec support is a practical constraint. Common codecs include G.711 µ-law for North America, G.711 A-law for outside North America, G.729, and G.722. When two devices using different codecs communicate, a media server must transcode between them. Plan for transcoding capacity in your media tier — it’s CPU-intensive and often the first resource to saturate under load.
WebRTC
WebRTC enables peer-to-peer VoIP calls directly from the browser without requiring plugins or softphones — perfect for SaaS apps, customer support portals, and remote agent dashboards. Integrating WebRTC into your softswitch platform requires a WebRTC gateway (often Janus or a native FreeSWITCH module) that bridges browser-based DTLS-SRTP media to standard SIP/RTP. Kamailio serves as a bridge between conventional SIP systems and WebRTC applications, enabling users to start voice, video, and messaging sessions directly from web browsers.
H.323 and Legacy Protocol Support
H.323 remains in active use across enterprise telephony, video conferencing infrastructure, and some carrier interconnects. Protocol transcoding enables the Class 4 softswitch to convert calls between different signaling protocols such as SIP, H.323, or MGCP, ensuring compatibility between different VoIP networks, carriers, or legacy systems. If your network will interconnect with enterprises or older carrier platforms, H.323 support in your SBC or media gateway isn’t optional — it’s a practical requirement.
ENUM (E.164 Number Mapping)
ENUM translates E.164 phone numbers into SIP URIs or other IP-based addresses using DNS. For Class 4 deployments, ENUM lookups can route calls directly over IP between carriers without touching the PSTN, eliminating termination costs for on-net calls. Building ENUM lookup into your routing logic — and maintaining an internal ENUM database for your own number ranges — is standard practice in wholesale carrier deployments.
Scalability & Redundancy: Designing for High-Availability Telecom Infrastructure
Telecom infrastructure has a higher availability expectation than almost any other software system. When your platform goes down, every call in progress drops and every new call fails — immediately and visibly. Designing for carrier-grade availability means building redundancy in at every layer, not bolting it on afterward.
Horizontal Scaling: The Right Model for VoIP
Vertical scaling (adding CPU and RAM to a single server) has a hard ceiling for SIP-heavy workloads. The right model is horizontal scaling: multiple signaling nodes behind a SIP-aware load balancer, with shared state for active sessions stored in a distributed data store like Redis. OpenSIPS acts as the traffic director for voice calls, sitting between clients and media servers, deciding where each call should go based on server load and location — handling user registration, routing calls to available servers, and redirecting traffic if a server fails.
Media servers require separate scaling considerations. Each FreeSWITCH or media server node has a practical concurrent session limit based on available CPU (especially when transcoding is involved). For scalable systems, OpenSIPS for SIP routing and FreeSWITCH for media handling are often combined to achieve both performance and modularity.
Infrastructure as Code for Telecom
Manual server provisioning doesn’t scale when you need to spin up nodes in response to traffic spikes. Using Infrastructure as Code tools like Terraform to provision cloud resources and Ansible to configure servers consistently means defining SIP servers, media gateways, and databases as code templates that can be deployed anywhere — preventing configuration drift and ensuring predictable scaling to new regions or environments.
Active-Passive vs. Active-Active HA
For stateful components like the softswitch core, two HA patterns are common. Active-passive pairs a primary node with a hot standby; on failure, a floating IP is reassigned to the secondary. This is simpler to implement but wastes half your capacity. Active-active runs both nodes simultaneously, distributing load between them — requiring session state replication so in-progress calls can survive a node failure. For any deployment targeting five-nines uptime, active-active is the right choice despite its complexity.
Geographic Distribution
Latency is a first-class concern in voice networks. Deploying softswitch nodes geographically close to your traffic concentration points — not just close to your development team — can reduce post-dial delay and improve Mean Opinion Score (MOS) for end users. For global carriers, multi-region deployments with DNS-based geo-routing or anycast load balancing distribute traffic to the nearest healthy node automatically.
RTP Load Balancing and NAT Traversal
RTPProxy and MediaProxy handle RTP stream balancing with NAT traversal support — pair load balancers with health-checking tools to ensure traffic is only routed to healthy nodes. NAT traversal remains one of the more operationally frustrating aspects of SIP deployments; ICE, STUN, and TURN protocols handle it at the endpoint level, while the SBC and RTP proxy handle it at the network level. Budget time during implementation to test NAT scenarios thoroughly — they’re rarely covered adequately in vendor documentation.
Build vs. Buy: Custom Softswitch Development or Commercial Platform?
This is the decision that shapes your operational model for years. The right answer depends on your traffic model, technical team depth, time-to-market requirements, and how differentiated your platform needs to be. There’s no universal winner — but there are clear signals pointing toward each path.
The Case for Open-Source Custom Development
Building on open-source components (FreeSWITCH, OpenSIPS, Kamailio, Asterisk) gives you complete control over every layer of the stack. You can implement proprietary routing algorithms, integrate with any billing or CRM system on your own terms, and eliminate per-port or per-minute licensing fees entirely. For high-volume operators where licensing costs become significant at scale, the economics strongly favor custom development.
The cost is team depth and time. A production-grade custom softswitch requires engineers who understand SIP call flows, RTP media handling, Linux systems tuning, database optimization for real-time queries, and distributed systems design. That’s a rare combination of skills, and building the team before you have revenue is a significant capital commitment. Realistically, a capable custom Class 4 softswitch takes 6–12 months to build and stabilize from scratch. Class 5 with a full feature set takes longer.
The Case for Commercial Platforms
Commercial softswitches compress time-to-market dramatically. A vendor with a mature platform can have you operational in weeks rather than months, with proven high-availability architecture, integrated billing, and tested interconnects with major carriers already in place. For startups that need to generate revenue quickly, this compresses the capital at risk significantly.
The risks are vendor dependency and customization limits. If the platform can’t support a routing logic your key enterprise customer requires, or if the billing module doesn’t map to your pricing model, you’re negotiating with a vendor rather than editing code. Licensing costs also scale with usage — favorable early but potentially margin-compressing at scale.
The Hybrid Approach: Custom Development on Open-Source Foundations
The approach most production ITSPs converge on is custom development using battle-tested open-source engines as the foundation. FreeSWITCH is suitable for a wide range of environments, from small office PBX systems to large-scale carrier-grade telecom infrastructures, and its modular architecture facilitates straightforward customization and integration with third-party applications.
This approach lets you build differentiated business logic (routing algorithms, billing integration, customer portal) without re-inventing RTP processing or SIP state machines. It’s also well-supported — there are large communities and specialist developers around each of these open-source platforms, reducing the key-person risk of purely proprietary builds.
At Gama Infotech, we specialize in exactly this model: building production VoIP softswitch platforms on proven open-source foundations, customized to fit specific carrier architectures, billing models, and integration requirements — without the vendor lock-in of commercial platforms or the risk of building from scratch.
VoIP Softswitch Implementation Roadmap: Phases, Timelines & Milestones
A realistic implementation roadmap helps you sequence work, manage stakeholder expectations, and avoid the common trap of launching prematurely under commercial pressure. The phases below reflect how production-grade softswitch deployments actually unfold — not how vendor sales decks present them.
Phase 1: Architecture Definition and Requirements (Weeks 1–4)
Define your traffic model: projected peak concurrent calls, expected CPS, geographic distribution of traffic, and interconnect requirements. Decide on Class 4, Class 5, or hybrid. Document your billing model in detail — this drives more downstream integration decisions than any other requirement. Select your core technology stack (signaling engine, media server, SBC, billing platform). Identify regulatory requirements for your target markets (STIR/SHAKEN for the US, GDPR for EU, etc.).
Phase 2: Core Infrastructure Build (Weeks 5–10)
Stand up the signaling plane (SIP proxy/registrar), media server cluster, SBC, and database infrastructure. Implement basic call routing — at minimum, get a call from a softphone through the system and out to a PSTN gateway or SIP trunk. Establish monitoring and logging infrastructure early; you’ll depend on it during every subsequent phase. Configure your HA architecture even in the development environment — retrofitting HA later is more painful than building it in from the start.
Phase 3: Feature Development and Integration (Weeks 11–20)
For Class 5: implement subscriber provisioning, dial plans, voicemail, IVR, call queuing, and call recording. For Class 4: implement LCR routing, inter-carrier billing, and number portability lookups. Integrate the billing engine — this phase typically takes longer than expected because billing requirements have more edge cases than any other part of the system. Build the customer portal and provisioning APIs. Integrate with OSS/BSS systems if applicable.
Phase 4: Load Testing and Performance Tuning (Weeks 21–24)
Run synthetic load at 150% of projected peak to identify bottlenecks before they appear in production. Common findings at this phase: database query performance degrading under load, RTP proxy memory leaks at high session counts, SIP proxy configuration not optimized for your call mix, and monitoring systems introducing latency. This phase cannot be skipped — it routinely surfaces issues that would otherwise cause production incidents.
Phase 5: Security Hardening and Compliance Audit (Weeks 23–26)
Enforce TLS for all SIP signaling, SRTP for media, and network segmentation between components. Implement STIR/SHAKEN if serving US numbers. Run a penetration test against the SBC and signaling infrastructure. Validate CDR accuracy and billing integrity. Document your security controls for any compliance requirements in your target markets.
Phase 6: Soft Launch and Ramp (Weeks 27–32)
Launch with a limited set of customers or traffic volume. Monitor call quality metrics (ASR, ACD, MOS) in real time. Establish an operational runbook for common failure scenarios. Gradually increase traffic while monitoring all resource utilization metrics. Plan for 24/7 on-call coverage during the ramp period — issues at this stage surface at unpredictable hours.
Integration Essentials: Billing, CRM, OSS/BSS & Third-Party APIs
A softswitch that doesn’t connect to your business systems is an island. Integration quality — not feature count — is what separates a platform that scales operationally from one that requires constant manual intervention as the business grows.
Billing Integration: The Operational Core
By integrating billing directly into the softswitch infrastructure, telecom service providers can simplify charging customers for usage, managing accounts, and maintaining revenue streams. There are two integration patterns to understand:
Post-call billing works by accumulating CDRs and processing them in batch runs. It’s simpler to implement but unsuitable for prepaid services where you need to prevent subscribers from exceeding their credit limit mid-call.
Real-time billing queries the billing engine during call setup to verify available credit and authorize the call, then decrements the balance as the call progresses. Many hosted billing solutions offer real-time billing capabilities — as soon as a call is terminated or a service is used, it is immediately accounted for in the billing system. This requires low-latency connectivity between the softswitch and the billing engine; DIAMETER (RFC 3588) is the standard protocol for real-time credit control in telecom.
OSS/BSS Integration
The difference between OSS and BSS can be distinguished as the systems that maintain network operations and the systems that maintain the business operations that rely on that network to generate revenue. Specifically: OSS maintains network inventory, management, and operations, while a BSS handles orders, customer relationships, and billing management.
For a softswitch operator, OSS integration means provisioning workflows (adding a new SIP trunk to the softswitch when a customer signs up), number inventory management (tracking which DIDs are assigned to which subscribers), and fault management (automatically opening a ticket when a carrier route degrades). BSS integration means your CRM knows what services each customer has provisioned, your billing system receives accurate CDR feeds, and your order management system can automatically provision new services without manual intervention.
CRM and Third-Party API Integration
Enterprise customers increasingly expect their VoIP platform to integrate with Salesforce, HubSpot, or their specific CRM. Exposing your softswitch capabilities through clean REST APIs — for call initiation, subscriber provisioning, CDR retrieval, and number management — makes these integrations possible and opens the door to enterprise accounts that would otherwise require custom development on their end.
Plan your API surface deliberately. Versioned APIs with clear authentication (OAuth 2.0 or API keys with scoped permissions) are easier to support over time than ad-hoc integrations. Document them with an OpenAPI spec from day one — it costs little and enables self-service integrations by enterprise IT teams.
Testing, Security & Compliance Considerations
Security in VoIP isn’t optional, and the consequences of getting it wrong are concrete and financial. Telecommunications fraud increased 12% in 2023, with an estimated $38.95 billion lost to fraud representing 2.5% of global telecommunications revenues. That exposure is distributed across carriers, ITSPs, and their customers — and your softswitch platform is a direct target.
Encryption: Non-Negotiable Baselines
SIP security focuses specifically on protecting the SIP signaling protocol: encrypting SIP messages with TLS, validating SIP headers, and preventing SIP flooding and registration attacks. VoIP security is broader, encompassing SIP security plus media encryption (SRTP) and fraud prevention. Deploy TLS for all SIP signaling between components. Enforce SRTP for all media streams. Configure your SBC to reject unencrypted SIP from external peers where your peering agreements allow it.
STIR/SHAKEN Compliance
STIR/SHAKEN is the FCC-mandated framework for caller ID authentication. If you originate or terminate voice calls in the United States, your infrastructure must support STIR/SHAKEN signing and verification. The framework works at the SBC, which signs outbound calls using your certificate and verifies inbound calls from other carriers.
A significant regulatory update to note: the FCC’s Eighth Report and Order, adopted in November 2024, changed STIR/SHAKEN implementation requirements. Every secure trunk provider with STIR/SHAKEN obligations must now obtain and use their own certificates directly from approved certificate authorities. The September 2025 compliance deadline has passed — if your platform handles US numbers and you haven’t implemented provider-owned STIR/SHAKEN, this needs immediate attention.
DDoS and SIP Flood Protection
SIP registration floods, OPTIONS ping storms, and INVITE amplification attacks can saturate your signaling plane even if each individual request is individually valid. The SBC is your first line of defense: configure rate limiting per source IP, implement dynamic blacklisting for sources generating anomalous request rates, and set maximum registration rate thresholds. For volumetric UDP flood attacks, upstream scrubbing at the network layer (from your data center provider or a CDN/DDoS mitigation service) is needed — the SBC alone can’t absorb multi-gigabit floods.
Fraud Detection and Prevention
International Revenue Share Fraud (IRSF) — where fraudsters gain unauthorized access to your platform and route calls to premium-rate numbers they control — is one of the most financially damaging attack types for VoIP operators. Build automated detection into your routing and billing layer: alert on sudden spikes in traffic to specific destination prefixes, enforce per-account concurrent call limits, and block calls to known high-risk number ranges by default.
Load Testing Methodology
Test your signaling plane with SIPp or similar tools at 2x projected peak CPS. Test your media plane at projected peak concurrent sessions with active transcoding. Test your HA failover by literally killing the primary node while calls are in progress — verify that in-flight calls survive failover and that new calls route correctly within your acceptable recovery time. Test billing accuracy by comparing CDR output against call records from an independent measurement point.
Vendor Selection Criteria: Evaluating Softswitch Partners & Platforms
Choosing the right softswitch vendor or development partner is a decision with a long operational tail. The platform you choose shapes your costs, capabilities, and constraints for years. Evaluate on substance, not on sales presentation.
Architecture Transparency
Ask for a detailed architecture diagram that identifies every component, its dependencies, and how it scales. A vendor who can’t clearly articulate where their single points of failure are hasn’t thought carefully about HA. Ask specifically: “What happens to active calls if the database goes down?” and “How does session state survive a signaling node failure?” The quality of the answers will tell you a lot about the maturity of the platform.
Protocol Compliance and Interoperability
Verify SIP compliance against RFC 3261 and the SIP connect technical requirements. Ask for a list of carrier interconnects the platform has already been tested with. Request a demo where you route test calls through your target termination carriers — interoperability issues with specific carriers are often only discovered in testing, not in vendor documentation.