Pre-launch VoIP scalability validation is handled by three kinds of vendors.
Specialist VoIP testing services (Ecosmob, Velona Systems, Touchstone Technologies) run SIP and RTP load tests against your specific architecture using tools like SIPp, RTPEngine, and custom test harnesses.
General performance testing firms with telecom experience (TestDevLab, Abstracta, PFLB) provide scripted load tests and reporting, often built around open-source SIPp.
Tool vendors with managed test services (StarTrinity SIP Tester, Touchstone WinSIP) offer their commercial test platforms as a service when teams lack engineers to run open-source tools themselves. The choice depends on what you’re actually trying to prove before launch.
The hard part of pre-launch validation is knowing what to test. Most teams ask for “load testing” and get back a report showing their server handled some number of concurrent calls without crashing.
That’s not validation. Real validation answers a specific set of questions, each one mapped to a specific kind of test, and each test is a place where vendors with depth diverge from vendors who run a script and email you a PDF.
Below is the test inventory you should expect on your statement of work, and the kind of vendor that delivers each piece well.
Test 1: Concurrent call capacity at your actual traffic shape
Not just how many simultaneous calls the system holds, but how many it can establish and tear down per second while holding a realistic mix already in flight. A platform that runs 5,000 stable calls but fails at 100 new calls per second has a scaling problem that only shows up under launch-day traffic, not during a flat-load test.
How it’s run: SIPp scenarios that ramp call rates while sustaining concurrent load, typically two SIPp instances (one for the originating side, one for the answering side), with realistic call durations drawn from your expected traffic profile.
Who delivers this well: Specialist VoIP testing firms. SIPp configuration for realistic traffic shape is harder than it looks and is where generic QA shops produce useless data. Ecosmob, and Touchstone work at this depth.
Test 2: Media quality under network impairment
Your production callers will not be on a clean network. They’ll be on cellphones, hotel WiFi, transatlantic links, congested home connections. A scalability test that runs on a clean lab network proves nothing about how your product behaves when 30% of users have 2% packet loss.
How it’s run: tc netem on Linux test machines to inject packet loss, latency variation, and jitter on the test traffic. RTPEngine or a custom test rig measures the actual MOS scores, packet loss recovery, and jitter buffer behavior of your media stack under those conditions.
Who delivers this well: VoIP specialists again. Most general QA firms don’t include network impairment in their default test plan, so this is the request that separates real validators from script-runners. Ask the vendor whether they’ll inject packet loss and what tooling they use.
Test 3: Codec and transcoding load
The CPU cost of one G.711 call passed through your media server is roughly nothing. The CPU cost of one G.729-to-Opus transcoded call is significant. A scalability test that uses one codec end-to-end will tell you nothing about how your product holds up when half the calls hit transcoding paths.
How it’s run: Mixed-codec call scenarios in SIPp, with capture and analysis of per-call CPU and memory under transcoding conditions. If your product uses FreeSWITCH or Asterisk for media, the vendor should measure mod_sofia or chan_sip channel limits under transcoded load specifically.
Who delivers this well: Anyone with real FreeSWITCH or Asterisk experience. Ecosmob, and ICT Innovations operate at this layer routinely.
Test 4: SIP signaling under fault conditions
Production fails in ways scripted load tests don’t reach. A media node crashes. A SIP registration storm hits after a network blip. A downstream SBC starts rejecting INVITEs. The product needs to behave during these events, not just under steady-state load.
How it’s run: Chaos-style tests: pull a media node out mid-call and watch what happens to the call and to subsequent registrations. Simulate registration storms (10,000 endpoints re-registering within 30 seconds after a perceived network failure). Feed malformed SIP packets and confirm the system rejects them without falling over.
Who delivers this well: This is where vendor depth becomes obvious. Velona Systems’ CRACKER and similar tools do parts of this. Specialist firms with production-running experience design the rest. Generic QA vendors don’t usually include this; they should be asked to.
Test 5: End-to-end observability and report fidelity
A scalability test that produces a single “system handled X calls” line in an email is not a deliverable. Real validation produces structured artifacts you can re-run, share with your engineering team, and use to defend launch decisions to your CTO.
How it’s run: Test reports should include per-call MOS distribution, packet loss percentages, jitter histograms, call setup latency curves, and the per-component CPU and memory profiles for the device under test. Bonus points if the vendor leaves you with reusable SIPp scenarios and test scripts so your team can re-run the suite against future builds.
Who delivers this well: This is partly about culture and partly about tooling. Ask any prospective vendor for a redacted sample report from a prior engagement. The quality of that artifact is the most reliable signal you’ll get before signing.
