Everything in ClutchCall Voice hangs off a single identifier. A call is one sid, and that sid is the only thing you ever address. The phone leg, the SIP leg, the browser softphone leg, and an attached AI agent are all facets of it. Learn the four nouns on this page: call, track, stream, and frame. The rest of the voice API then reads as vocabulary that you already know.

​
One call, one sid

A call is a two-legged conversation (caller ↔ agent). A SIP gateway runs it as a back-to-back user agent (B2BUA). You can originate the call, receive it inbound, or place it from a browser. In each case, the control plane hands you a Call keyed by one sid. You never hold separate handles for signalling, media, and the agent:
  • Originate returns a Call as soon as it is dialing.
  • Fetch, transfer, hang up all take the same sid.
  • Attach an audio bridge or an AI agent by sid. The engine wires the media end to end.
transfer() re-points the live audio at a new number or a different agent. The call keeps the same sid. A call’s identity therefore survives an AI→human handoff or a carrier re-route. See Call lifecycle for the full state machine.

​
The two audio tracks

A call’s media is exactly two MoQT audio tracks under a per-call namespace:
These are ordinary realtime tracks, scoped to a call. They use the same publish/subscribe primitive described in Realtime tracks. Because they ride MoQT, they fan out for free. A recorder, an ASR consumer, and a live dashboard can all subscribe to voice/<sid>/uplink, and the publisher does not know that they exist.
Uplink and downlink are named from the caller’s point of view. When you attach as the server, you subscribe uplink (hear the caller) and publish downlink (talk to the caller). When you attach as the browser caller, you do the mirror image: you publish uplink (your mic) and subscribe downlink (playback). The two track names are the same. The ends are opposite.

​
The capability tag: voice/<codec>

Each track carries a capability string of the form voice/<codec>, for example voice/opus or voice/pcm16. The relay routes on that capability, not on a hardcoded peer address. You subscribe by intent: “give me this call’s audio as Opus.” Through a capability, an AI-agent attach, a recording sidecar, or your own ASR tap can each find a call’s audio without advance wiring. This is the voice-specific instance of a general rule: a track’s capability is its routing key. "asr" and "tts" tracks use the same mechanism elsewhere.

​
Streams and frames

A track is a continuous stream of small binary frames. For voice, one frame is one encoded audio packet. A 20 ms Opus frame is the default unit. The bridge writes each frame as a MoQT object with a microsecond timestamp:
The engine delivers frames reliable and ordered by default. A 20 ms frame is small, and the relay bounds its per-group queue. The relay therefore drops a late frame at playout and does not retransmit it forever. A transient loss costs one packet of jitter, not a growing backlog. When you release the bridge handle, the engine stops both tracks and ends the media session.

​
Codecs

The bridge transcodes between two formats: the codec that the call leg negotiated with the carrier, and the codec that your code asked for. For example, PSTN µ-law comes in, Opus goes to your code, and the reverse on the way back. You never run media tooling in your own process. Pick a codec per attach: Carrier legs arrive as G.711 (PCMU/PCMA) at 8 kHz. The browser path is Opus. sampleRate (default 48000), channels (default 1), and frameMs (default 20) complete the audio shape. Voice is audio-only. There are no video codecs on this path. See Codecs for the transcode matrix and passthrough fast paths.

​
Where sessions fit

A “session” is the transport-level connection that your SDK client holds. It is one authenticated QUIC link that can carry the tracks of many calls at once. You open a session once. The client auto-reconnects and re-attaches your tracks for you. Each call multiplexes its uplink/downlink pair over the session. A single auth token authorizes the whole session, so an attach to another sid needs no new setup.
The browser softphone places audio on these same voice/<sid> tracks. There is no separate WebRTC transport and no SFU on that path. The SDK borrows only the browser’s Opus encoder (via encoded/insertable streams). The encoded frames ride QUIC/MoQT like every other frame. See Browser audio capture.

Calls API

Originate, fetch, transfer, and hang up — the control surface for a sid.

Realtime tracks

Learn the MoQT publish/subscribe primitive under the audio bridge.

Codecs

See the transcode matrix and passthrough paths for Opus, PCM16, and G.711.

Voice architecture

See how signalling, media, transport, and the agent runtime fit together.