Components

A ClutchCall Voice deployment is one engine process made of a few well-defined roles. You rarely touch them one by one, because a call flows through all of them. But when you know which piece owns which job, routing, tuning, and debugging become much easier. This page describes each component by the job it does. It also points you at the page where you configure it. Everything below runs inside a single shard-per-core C++ engine: one process per host and one reactor per CPU core. The engine pins sessions to a core, so per-call state stays lock-free. The engine loads components as modules into that host. “The SIP gateway” and “the media plane” are roles in one binary. They are not separate services that you deploy and network together.

​

SIP gateway (B2BUA)

The SIP gateway is the front door for telephony. It terminates carrier trunks and registrations from agent phones. It runs as a back-to-back user agent (B2BUA). Every call is two legs (caller and agent) that the gateway bridges. The gateway can then transcode, transfer, and record without either side seeing the other’s signalling. It owns the full SIP lifecycle: INVITE / 200 / ACK / BYE, REFER-based transfers, digest authentication, source-IP ACLs, and a spam filter. An internal registrar is on by default. Software and desk phones can REGISTER directly against your workspace’s SIP domain, and you run no separate registrar. The gateway matches trunks by source IP and resolves them to a tenant. Phone registrations land in a short-lived location store keyed by address-of-record. Configure trunks, numbers, and registration in SIP trunking and Number provisioning.

​

RTP media plane

The gateway handles signalling. The media plane handles the audio itself. It runs RTP/RTCP send and receive in the engine, on the same core that owns the call. There is no hop between where the packet lands and where the engine processes it. Its jobs:

• Codec bridging — the media plane decodes carrier G.711 (PCMU/PCMA) to the runtime’s internal 8 kHz PCM16. It encodes agent audio back out. Opus and G.711 legs meet here.
• Jitter handling and pacing — a per-session jitter buffer smooths arrival. Per-session pacers clock outbound frames on a 20 ms cadence.
• DTMF — the media plane detects and injects RFC 2833 telephone-event digits.
• Recording tap — a recording sink can capture both legs (caller and agent as separate stereo channels) without effect on the live path.
• Quality signals — RTCP feedback yields jitter and packet-loss. The engine attributes per-call byte counts to each tenant for the traffic dashboard.

This path intentionally has no echo cancellation, denoise, or AGC. Audio arrives already encoded from browsers. Telephony-safe defaults keep the agent from triggering on its own speech. See Voice isolation for what this means for your deployment.

​

Dialplan & routing

The dialplan decides what happens to a call after the engine answers it: play an IVR prompt, send it directly to an AI agent, or queue it for a human. It was the first routing role built into the engine. It is where you express “this number, from this trunk, at this time, goes here.” For contact-center flows, a skill-queue routing brain sits on top. It processes an inbound call in this sequence:

1. It classifies the call (IVR / VDN).
2. It matches the call to a skill queue.
3. It offers the call to an eligible agent, AI or human, with ring strategies, glare protection, and re-offer on no-answer.

The same accept signal works whether the agent is a browser softphone or a registered SIP phone. Set this up in PBX & ACD. See Call lifecycle for the events that each routing decision emits.

​

Agent runtime

The agent runtime makes a call conversational. It embeds the AI agent directly in the engine, next to the media plane. Audio does not leave the box to reach the model layer. Each turn runs through a small pipeline (a DAG). The pipeline is either a staged ASR → LLM → TTS chain or a single speech-to-speech provider. You bring your own providers, with credentials scoped per tenant:

• Cloud realtime endpoints (OpenAI Realtime, Gemini Live).
• Separate ASR/LLM/TTS vendors (Deepgram, ElevenLabs, and others).
• Your own realtime endpoint.

The runtime also owns turn detection and barge-in, tool calling, and session lifecycle (idle watchdogs, max-session ceilings, output caps).

​

MoQT transport

Telephony reaches you over SIP/RTP. Browsers and apps reach you over QUIC. The transport component carries their audio as media-over-QUIC (MoQT) over WebTransport on a single :443 plane. You open no separate media port. A browser publishes its microphone as a MoQT track. It subscribes to the agent’s reply as another track. The engine publishes the caller’s audio the same way, so a human agent’s browser can subscribe to a live PSTN caller. The SDK uses the browser’s WebRTC stack only as an encoder tap: it extracts encoded Opus frames and sends them over QUIC. ICE/DTLS/SRTP are never on the wire for these clients. Read the mechanics in WebTransport and The WebRTC diversion.

​

Relay mesh

A published track usually has more than one subscriber: the agent, a supervisor who listens in, a recorder. These subscribers are not always on the same core or even the same host. The relay mesh does the fan-out. It takes one published copy of a track and delivers it to every subscriber, across cores within a host and across hosts within a region. You do not call the relay directly. Publish and subscribe operations route through it automatically. The mesh lets a call scale past one core and one machine, and the publisher pays no per-subscriber cost. The architecture page shows where the mesh sits in the data path. Sessions, calls, tracks & streams covers the track model that the mesh fans out.

​

Inference

For most deployments, the model layer is a cloud provider that you configure in the runtime. In that case, there is no separate inference component to think about. The inference component matters when you run models on your own GPUs, typically on-prem, for data-residency or cost reasons. In that mode, a control plane discovers model pods, scrapes their load, and routes requests to them over QUIC. It presents a single speech-to-speech endpoint. The agent runtime dials that endpoint like any other provider.

​

Next steps