Follow a single call from the carrier’s edge to your AI agent and back, and you have the whole architecture. TeleQuick Voice is one path made of five roles, each owning one job and handing off cleanly to the next:

SIP gateway / B2BUA

Terminates carrier trunks and browser-originated calls, authenticates and routes them, and stitches the two legs of every call together.

RTP media plane

Receives and sends the audio packets, transcodes codecs, handles jitter and DTMF, and taps recordings — all in-engine, per session.

Agent runtime

Drives the conversation: streams caller audio to your ASR/LLM/TTS or speech-to-speech provider and paces the reply back into the call.

MoQT transport

Carries audio to and from browsers and apps as media-over-QUIC objects, tunneled through WebTransport on the same port as your control API.
A relay mesh sits underneath the transport, fanning each audio track out to every subscriber across engine cores and hosts. You never wire these roles together yourself — you point a trunk or a browser client at the stack and the path assembles itself.

​
The end-to-end path

Here is an inbound PSTN call reaching an AI agent. Read it top to bottom; each arrow is a handoff between the roles above. 
  Carrier SIP trunk
        │  INVITE (matched by source IP → tenant + trunk)
        ▼
  ┌─────────────────────────┐
  │  SIP gateway / B2BUA     │  digest auth · ACL · spam filter · dialplan
  └───────────┬─────────────┘
              │  route to agent, open media on the caller's core
              ▼
  ┌─────────────────────────┐
  │  RTP media plane         │  G.711 (PCMU/PCMA) 8 kHz  →  decode to PCM16
  └───────────┬─────────────┘
              │  8 kHz PCM16 frames (20 ms / 160 samples)
              ▼
  ┌─────────────────────────┐
  │  Agent runtime           │  ASR → LLM → TTS, or speech-to-speech
  └───────────┬─────────────┘
              │  agent audio, 8 kHz PCM16
              ▼
  ┌─────────────────────────┐
  │  RTP media plane egress  │  pacer → G.711 encode → RTP back to carrier
  └─────────────────────────┘
1

The call arrives

The carrier sends an INVITE to the tenant’s SIP edge (<workspace-id>.sip.telequick.dev). The gateway matches the trunk by source IP, resolves the tenant, and runs digest auth, ACL, and spam filtering before it accepts anything.
2

The gateway routes and opens media

Acting as a back-to-back user agent (B2BUA), the gateway picks the destination from the dialplan and skill-based routing, then opens an RTP media session pinned to the CPU core that owns the call.
3

The media plane decodes

Carrier audio is G.711 µ-law or A-law at 8 kHz. The media plane decodes it to the runtime’s internal format — 8 kHz PCM16, little-endian — in 20 ms frames, and handles jitter, DTMF, and the recording tap along the way.
4

The runtime holds the conversation

Decoded audio streams into the agent runtime. It runs your cascaded ASR → LLM → TTS graph or a single speech-to-speech provider, decides turn boundaries, and produces reply audio.
5

The reply flows back

Reply audio goes through the media plane’s egress pacer, is re-encoded to the carrier’s codec, and is sent back over RTP. The gateway holds the SIP dialog open until either side hangs up.
Everything inside the runtime runs at 8 kHz PCM16 end to end, so a call crosses at most one transcode on the way in and one on the way out. See Sessions, calls, tracks & streams for how these map to the object model.

​
Direct media vs. proxied media

Whether the media plane and the SIP gateway sit on the same host is a per-trunk choice. Set media_mode on the trunk:
RTP terminates wherever the agent runs, and after call setup the gateway is signalling-only — it manages the SIP dialog while audio flows straight from the carrier to the runtime’s media plane. Fewer hops, lower latency, and no media relay to scale. Use this for well-behaved carriers.
Carrier ──RTP audio──▶ RTP media plane ─▶ Agent runtime
   ▲                        │
   └── SIP signalling ──▶ SIP gateway (dialog only, no media)
Direct media is the fast path and the default. Reach for proxy only when a carrier’s NAT or SBC policy refuses to send audio to an address other than the one it signalled to.

​
Browser and app clients

A browser or mobile client does not speak SIP — it rides the media-over-QUIC transport. Audio never touches WebRTC’s transport; only the browser’s Opus encoder and capture graph are borrowed (see WebRTC diversion): 
Browser mic ─▶ Opus encode ─▶ MoQT object ─▶ WebTransport :443
                                                   │
                                                   ▼
                                          media-over-QUIC bridge
                                          Opus decode · 48k→8k resample
                                                   │
                                                   ▼
                                          bridge into the call / agent
   Browser player ◀─ Opus ◀─ MoQT track ◀─ 8k→48k ◀─ caller / agent audio
Uplink and downlink use distinct MoQT tracks (a mic track up, a spk track down) so a client never subscribes to its own audio and creates a feedback loop. The relay mesh handles the fan-out. Full detail lives in Transport to web & apps.

​
Two planes on the QUIC edge

The engine terminates a single QUIC listener that multiplexes two logical planes:
PlaneProtocolCarriesReached at
ControlQUIC + HTTP/3Session setup, agent config, call control, telemetryportal.telequick.dev / agent.telequick.dev
MediaMoQT over WebTransportLive audio tracks (publish / subscribe)The same :443, tunneled through WebTransport
For browsers, both planes converge on one :443 — MoQT rides inside WebTransport alongside the HTTP/3 control traffic, so there is a single port and a single certificate to open. Native SDKs can additionally dial a dedicated media endpoint for the MoQT plane.
Converging the media plane onto the shared :443 WebTransport port is the current direction. A standalone media-over-QUIC port still exists for native SDKs that dial the transport directly; it is the legacy rung, not the default. WebSocket (control and data) and WebRTC (browser media) remain the required fallbacks when QUIC or WebTransport is unavailable.

​
The relay mesh

The engine runs one reactor per CPU core (shard-per-core), and calls are pinned to a core. When a track needs to reach subscribers on other cores — or on other hosts — the relay mesh does the fan-out:
  • Cross-core — a published track is broadcast to sibling cores on the same host through a lock-free ring, so a subscriber pinned elsewhere still receives every audio object.
  • Cross-host — edges peer with each other and push tracks between hosts, so a browser connected to one edge can subscribe to a call terminating on another. The mesh is reachable at relay.telequick.dev.
This is what lets a single call — a PSTN caller on one core, an AI agent, and a browser-based human supervisor on a different host — share one audio track set without any of them knowing where the others live.

Components

A closer look at each piece of the stack and what it owns.

Sessions, calls, tracks & streams

The object model behind the data path.

Transport to telephony

SIP trunking, numbers, ACD, and the call lifecycle.

Agent runtime

Bring your own ASR/LLM/TTS or speech-to-speech provider.

Deployment models

Managed cloud and on-prem self-hosting.

Transport to web & apps

How browser and mobile clients reach the stack over QUIC.