Powered by Probe

SIP Load Testing
find the breaking point.

The breaking point you find on your busiest day costs customers and overtime. Find it in a test instead. From 100 to 100,000 concurrent calls: realistic ramp profiles, SBC and media-server bottlenecks exposed, and a forensic capture that lets you size capacity precisely instead of over-buying hardware for headroom you never needed. Powered by Probe.

What you can do

Realistic load, not just a flood of calls.

A load test is only useful if it mirrors how traffic actually arrives. Probe lets you shape the ramp, sustain it, and capture the same forensic detail at 100,000 calls that you get at one.

Ramp profile design

Linear, stepped, sustained and burst profiles. Model the morning login storm, the marketing-blast spike, or a steady 24-hour soak.

Find the bottleneck

Common SBC and media-server failure patterns: CPS limits, registration storms, transcoding exhaustion, RTP port starvation, SIP retransmission cascades.

MOS, jitter, loss, RTT under load

Real media metrics at scale, not a synthetic latency proxy. Watch quality degrade call by call as you approach the limit.

Capacity planning

Read the forensic capture to size headroom. Know the exact concurrency at which the first KPI drifts, and which component gave way first.

CI/CD and REST API

GitHub Actions, REST API, MCP server, webhooks. Run a capacity check on every infrastructure change, not just before launch.

AI Assistant as test author

“Ramp to 5,000 concurrent calls into sbc-eu-1 over 10 minutes, hold for an hour.” The Agent writes the profile and runs it.

How it works

From target to breaking point in four steps.

1
Point Probe at the target
An SBC, a media server, an IVR cluster or a full SIP trunk. Credentials live in encrypted vaults.
2
Shape the ramp
Pick linear, stepped, sustained or burst. Set the peak concurrency and the duration of the soak.
3
Run from anywhere
UI, REST API, MCP server, GitHub Actions or a webhook trigger. Globally distributed agents generate the load.
4
Read the capture
See the exact concurrency where KPIs drift, correlate it to the component that gave way, and size headroom for launch.
When to load test

Two jobs, one engine.

Load testing is not a one-time event. Run it hard before a launch, then run it regularly to confirm capacity has not quietly eroded.

Pre-launch validation

Prove the platform survives the projected peak before the marketing date. Find the bottleneck while you still have time to fix it.

Periodic capacity verification

Infrastructure drifts: a config change, a new codec, a busier neighbour on shared hardware. Re-run the profile to confirm headroom is still there.

Pre-launch SBC and IVR sizing

Validate that a new SBC pair or IVR cluster meets the concurrency it was specified for, with evidence procurement will accept.

Migrating off a legacy load tester

Replacing Hammer or another legacy lab? Probe reproduces the load profiles without the appliance footprint.

Find the breaking point. 14 days, no credit card.

All four products unlocked. Run a 100-concurrent-call load test on day one, the AI Assistant walks you through it. If you don’t convert, your work pauses for 6 months, resume any time.