Comparison & Benchmarks

This page collects the numbers other pages point at, states the scenario and hardware behind each, and is honest about which are measurements and which are models. The one rule that governs all of it: measure your own workload before you quote a figure. Every number below came off a specific rig under a specific load; yours will differ, and the tooling to measure yours is linked at the end.

​

How to read these numbers

​

Media plane: calls per unit of CPU

The gateway is a modular, shard-per-core engine with an in-process RTP media plane — audio is mixed and paced inside the same process that terminates SIP, with no per-call transcode hop and, on a fully NIC-owned deployment, a zero-copy AF_XDP fast path. The practical consequence is that it carries far more concurrent audio per CPU than a channel-driver PBX. On identical hardware (GCE c4-highcpu-8), an inbound-answer + G.711-playback media-plane test measured: That is roughly 3.7× more calls per unit of CPU. Two caveats keep this honest:

• Both systems capped on SIP call setup, not media. TeleQuick’s signalling runs on a single shard (shard-0), which is what pinned it at 3,500 in this test; the media plane itself sat near-idle with large headroom (media load spread dead-even across all 8 shards, ~300 Mbps NIC egress). These are floor numbers for the media plane — the ratio is a media-per-CPU advantage, not a max-concurrent-calls promise.
• It is a synthetic G.711-playback scenario. Your codec mix, recording, AI attachment, and trunk topology all move the number.

Migrating off Asterisk or FreeSWITCH re-points trunks rather than importing a dialplan — see From Asterisk / FreeSWITCH.

​

Transport: QUIC turn latency vs TCP

This is the hop where the transport choice shows up as a number. In a controlled prototype rig over a WAN link (50 ms RTT, ~1% loss), measuring the same turn — end-of-user-speech to start-of-agent-speech — over QUIC versus a TCP+TLS baseline: QUIC roughly halves the turn and keeps the tail flat — p99 sits right on p50 because head-of-line blocking is gone. Under concurrency (c = 20) the gap widens where it hurts most: time-to-first-token p50 93.9 ms vs 143.6 ms (−35%), and p99 149.2 ms vs 1,197.9 ms — an ~8× better tail — with ~60% more throughput. The signalling-gateway proxy added ~2 ms flat out to 100 concurrent.

​

The browser diversion tax

Reusing the browser’s encoder and shipping the tapped Opus frames over QUIC instead of native SRTP/UDP is not free, but it is close to it. In the localhost diversion prototype, the JS-layer round trip measured 1.20 ms over QUIC versus 0.84 ms for raw WebRTC SRTP/UDP — a +0.36 ms tax for the tap and the QUIC hop. That is noise next to a single 20 ms Opus frame, and it buys you a single :443 plane, no SFU, and encoded-frame E2EE readiness. See WebRTC diversion for how the tap works.

​

Control plane: HTTP/3 stream throughput

The same QUIC transport carries the control plane (call setup, signalling RPC). On a single connection multiplexing 100 concurrent streams, targeted work on the stream scheduler took request throughput from 1.3K → ~47K req/s — a ~36× improvement — landing on par with a leading reference HTTP/3 implementation. Head-of-line-free multiplexing is what lets one connection carry many concurrent call-control operations without the tail blowup a TCP path shows under concurrency (see the c = 20 tail above).

​

Media fan-out: CPU vs a WebRTC SFU

For one-to-many audio/video fan-out (supervisor monitoring, broadcast), the engine shares one encoded buffer across subscribers rather than re-encrypting per peer. Against pion (an open-source WebRTC SFU) on a 1-publisher → N-viewer fan-out, the localhost result looked lopsided: Per-viewer CPU decreased as subscribers grew (0.40% → 0.21%, a sublinear shared-buffer fan-out) while pion stayed flat at ~0.57% (linear per-peer SRTP).

​

Cost: a model, not a headline number

There is no measured $/1k-call-minute figure to publish. The cost harness that would produce one still stubs parts of the media-spawn path, so its dollar tables are explicitly placeholders — a cost model you parameterize, not a measurement of the running stack. What the model captures is genuinely useful as a method: for a given call profile, cost per thousand call-minutes is a function of

• compute — CPU-seconds per call-minute (the media-plane efficiency above is the lever here) times your instance’s $/CPU-hour,
• egress — bytes per call-minute (codec choice: G.711 ~64 kbps/leg vs Opus narrowband far less) times your provider’s $/GB, and
• AI runtime — per-minute ASR/LLM/TTS or speech-to-speech provider spend, which usually dominates and is entirely your vendor’s pricing.

The engine’s efficiency moves the first two terms; it does nothing to the third. On most AI-voice workloads the runtime term swamps compute and egress combined, which is why we lead with “measure your own” rather than a dollar chart. The per-tenant, per-modality byte and bandwidth accounting needed to feed real numbers into this model is shipped as a capability — see Dashboards.

​

Measure your own

Every number here is reproducible on your traffic, and doing so is the only way to get a figure you can quote to your own stakeholders.

​

Related