sid. The PSTN leg, the
SIP leg, the browser softphone leg, and the AI-agent leg all hang off it.
The two primitives (plus agents)
Calls — the control plane
Originate, fetch, transfer, hang up. HTTP-shaped and idempotent; every call
returns a
Call handle keyed by a single sid. This is where you manage
a call.AudioBridge — the data plane
Bidirectional encoded audio over MoQT tracks at
voice/<sid>/{uplink,downlink}. This is where the media flows — tap
caller audio, push audio back, frame by frame.sid and the engine wires the
bridge end-to-end and drives the conversation for you. You write the agent, not
the plumbing.
The split is deliberate: the control plane is a request/response API you can call
from any backend, while the data plane is a low-latency media path you only touch
when you want the raw frames. For an AI voice agent you often touch neither — you
attach an agent and let the engine own both.
When to use it
Outbound + inbound calling
Originate to E.164 over a SIP trunk; accept inbound calls terminated by the
SIP gateway. One control surface for both directions.
AI voice agents
Attach a speech-to-speech agent to a live call. The engine bridges audio
both ways and handles turn-taking and barge-in.
Programmable audio
Subscribe caller audio (uplink) into your own ASR and publish synthesized
audio (downlink) back, with full codec control.
Browser softphone
Place and answer calls from the browser with encoded Opus over MoQT — no SFU
and no gateway round-trips for the media.
The wire model
A call’s media is two MoQT audio tracks under a per-call namespace:voice/opus), and the relay
routes on that capability — a recording sidecar, an ASR consumer, or an AI-agent
attach can subscribe to a call’s audio without the publisher knowing they exist.
You route on intent, not on a hardcoded peer.
When you attach as the server you subscribe uplink and publish downlink;
when you attach as the browser caller you do the mirror image — publish
uplink (mic) and subscribe downlink (playback). Distinct tracks per direction
avoid self-subscribe feedback.
Call lifecycle
The control plane reports a status that moves monotonically toward a terminal state:originate() returns as soon as the call is dialing; re-fetch to read the
latest status. transfer() re-points the live audio at a new number (a SIP
REFER under the hood) or re-attaches a different agent, keeping the same sid.
hangup() ends the call and drops both tracks.
Inbound PSTN calls are terminated by a SIP gateway acting as a back-to-back
user agent (B2BUA): it negotiates signalling with the carrier, answers, and
publishes the audio onto the same voice/<sid>/{uplink,downlink} tracks — so at
the SDK surface an inbound call is indistinguishable from an outbound one.
Codecs
The bridge transcodes between what the call leg negotiated and what your code asks for — PSTN µ-law in, Opus to your code, Opus from your code, µ-law back out, with no media tooling in your process.| Codec | When to use it |
|---|---|
opus | Default. Best quality-per-bit; native in the browser path. |
pcm16 | When a realtime model wants raw 16-bit PCM (many do). |
g711_ulaw | PSTN-direct, no transcoding. µ-law (North America / Japan). |
g711_alaw | PSTN-direct, no transcoding. A-law (most of the rest of the world). |
The browser softphone path
The browser places audio on the same MoQT tracks as everything else — there is no SFU on this path:Capture + encode
The SDK’s capture helper runs the browser’s own capture graph (echo
cancellation, gain control, noise suppression), then diverts the encoded
Opus frames — via encoded / insertable streams — onto the uplink track. Raw
PCM never crosses the wire, and the browser’s WebRTC transport is never used,
only its Opus encoder.
Publish over QUIC/MoQT
Each encoded frame is written to
voice/<sid>/uplink as a MoQT object over
WebTransport. The relay fans it to whatever the engine bridged the call to —
the SIP leg, an agent, or a recorder.QUIC/MoQT over WebTransport is first-class and is the default browser path
(Chrome-family). On Safari, UDP-blocked corporate networks, or TCP-only proxies
the client falls back to a WebSocket (control/data) or WebRTC (media) leg. See
Browser compatibility.
How it works
You get telephony-grade latency at fleet scale without running any media infrastructure. Underneath:- One connection carries everything. Your audio multiplexes over the same MoQT substrate as every other modality, all over a single QUIC/HTTP-3 connection on port 443 — one auth token authorizes the whole connection, with no per-track setup.
- The media path skips the kernel. The SIP/RTP leg rides an AF_XDP zero-copy fast path — packets move between the NIC and userspace without traversing the kernel networking stack for steady-state media.
- No lock contention on the hot path. A shard-per-core reactor pins each call to the core that owns it; an eBPF classifier steers packets to that shard, and cross-shard hand-off uses lock-free rings. A call never takes a lock while media is flowing.
- io_uring drives async I/O so the media shards stay off the scheduler’s critical path.
- Secure by default. Every QUIC connection is TLS 1.3; call handshakes use ECDSA for low per-core signing cost.
Next steps
Quickstart
Ship a voice agent in minutes on the managed cloud — no infrastructure to
run.
Core concepts
The end-to-end architecture: signalling, media, transport, and the agent
runtime.
Sessions, calls, tracks & streams
The object model behind the
sid — how legs, tracks, and namespaces fit
together.Agent runtime
Bring your own ASR/LLM/TTS or a speech-to-speech provider, tools, and
session lifecycle.