# Sessions, Calls, Tracks & Streams

> The voice object model: one call is one sid that addresses two MoQT audio tracks tagged by codec. Learn how calls, tracks, and audio frames fit together.

Everything in FirstByte 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](/modalities/voice/transport-telephony/call-lifecycle)
for the full state machine.

## The two audio tracks

A call's media is exactly two [MoQT](https://datatracker.ietf.org/wg/moq/about/)
audio tracks under a per-call namespace:

```
voice/<sid>/uplink     caller / device → cloud   (what the caller is saying)
voice/<sid>/downlink   cloud → caller / device   (what is played back)
```

These are ordinary realtime tracks, scoped to a call. They use the same
publish/subscribe primitive described in
[Realtime tracks](/concepts/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.

> **NOTE:**
> **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:

```ts
// server side: publish a downlink frame
bridge.write(tsUs, opusFrame);        // one 20 ms object → voice/<sid>/downlink

// server side: receive uplink frames
bridge.onFrame((tsUs, bytes) => { /* one decoded object at a time */ });
```

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:

| Codec        | When to use it                                                       |
| ------------ | -------------------------------------------------------------------- |
| `opus`       | Default. Best quality-per-bit; the native browser-softphone format.  |
| `pcm16`      | Raw 16-bit PCM — what many realtime AI models want on their input.   |
| `g711_ulaw`  | PSTN-direct, no transcode. µ-law (North America / Japan).            |
| `g711_alaw`  | PSTN-direct, no transcode. A-law (most of the rest of the world).    |

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](/modalities/voice/transport-telephony/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.

> **NOTE:**
> 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](/modalities/voice/transport-web/browser-audio-capture).

## Related

  - **[Calls API](/modalities/voice/api/calls)** — Originate, fetch, transfer, and hang up — the control surface for a `sid`.
  - **[Realtime tracks](/concepts/realtime-tracks)** — Learn the MoQT publish/subscribe primitive under the audio bridge.
  - **[Codecs](/modalities/voice/transport-telephony/codecs)** — See the transcode matrix and passthrough paths for Opus, PCM16, and G.711.
  - **[Voice architecture](/modalities/voice/concepts/architecture)** — See how signalling, media, transport, and the agent runtime fit together.