Transport to Telephony Overview

The phone network carries most business conversations, so ClutchCall Voice speaks it natively. A carrier delivers a call over SIP. The engine answers the call as a back-to-back user agent (B2BUA). The engine decodes the G.711 media and republishes it as an audio track. Your AI agent, or a human, can talk on that track. Every leg keys off a single call_sid. As a result, signalling, media, recording, and reporting all line up on one call. This page gives an overview of that bridge. Use the links to the task pages when you are ready to connect a trunk, provision a number, or hand a call to a person.

You do not run a separate PBX. The engine contains its own SIP gateway, registrar, and dialplan in a FreeSWITCH-style modular core. To migrate from Asterisk or FreeSWITCH, re-point your trunks and agents. You do not build new signalling infrastructure. See Migration.

How a phone call reaches your agent

A call crosses four boundaries between the carrier and your agent. You configure something at each boundary.

Signalling — SIP gateway / B2BUA

The carrier sends an INVITE to your per-tenant SIP host, <workspace-id>.sip.clutchcall.dev. The SIP gateway authenticates the INVITE: a source-IP ACL for trunks, and digest auth for registered devices. The gateway matches the INVITE to a trunk and answers it. The engine is a B2BUA, so it owns both legs of the dialog: the caller on one side, and the agent or callee on the other. This ownership makes transfer, bridging, and handoff possible.

Routing — dialplan and ACD

After the engine answers the call, a decision engine uses the matched trunk and the dialed number to select the next step. The call can stream to an AI agent, run an IVR/queue program, or ring a human. The PBX / ACD layer holds the number-to-destination mapping and the skill-queue routing.

Media — RTP plane

Audio flows as G.711 RTP (µ-law PT 0 / A-law PT 8). The in-engine media plane decodes the audio to the runtime’s 8 kHz PCM16 bus. The media plane applies noise suppression and scores call quality (MOS). It publishes the caller’s voice as the MoQT track voice/<sid>/uplink. The agent’s reply returns on voice/<sid>/downlink. The engine paces the reply out as G.711 every 20 ms. The Codec Guide has the codec details.

Handling — agent or human

The AI runtime attaches to those tracks. It runs your ASR/LLM/TTS or speech-to-speech pipeline (see Runtime). You can hand the live call to a person at any time. The AI leg pauses, and a human subscribes to the same caller track. See AI-to-Human Handoff.

The pieces you configure

SIP Trunking

Connect a carrier. Bring your own SIP trunk (matched by source IP), or register outbound. Trunks work in either direction. The engine seals credentials at rest.

Number Provisioning

Import a DID. Assign it to a trunk and an agent. Route inbound calls from it. Each workspace also gets its own <workspace-id>.sip.clutchcall.dev host.

Inbound Calls

Receive calls from the phone network. Resolve the trunk and number. Route the call to an AI agent, an IVR, or a queue.

Outbound Calls

Originate a single call, or run a paced bulk campaign over a trunk. An AI agent or a playback app handles the far end.

PBX / ACD

Route calls through VDNs, skills, and queues. Ring human agents on browser softphones or real SIP deskphones.

AI-to-Human Handoff

Warm-transfer a live call from the AI agent to a person. The caller audio stays bridged for the full transfer.

Call Lifecycle

Follow the full signalling and media sequence, from INVITE and early media through teardown, CDR, and Q.850 cause.

Codec Guide

Learn about Opus, PCM16, and G.711. See what runs on the wire, what the runtime works in, and where transcoding happens.

Trunks: the unit of connectivity

A trunk connects a carrier, another PBX, or a vendor bridge to your workspace. The engine matches inbound INVITEs to a trunk by source IP or by the dialed DID. Outbound calls select a trunk to leave over. Each trunk carries the SIP and RTP addressing for both sides, credentials (sealed), a media mode, and a realm.

inbound | outbound | both

The direction that calls flow over this trunk.

proxy | direct

default:"proxy"

proxy routes RTP through the engine’s media plane. proxy is the default, and AI handling and recording require it. direct is defined for pass-through media, but the live runtime currently degrades it to proxy.

internal | external | ai_vendor

Classifies the far side as an internal device domain, an external carrier, or a vendor bridge.

string

The action for an inbound call on this trunk: stream to an AI agent, enter a skill queue, or enter a VDN program.

You create and edit trunks in the control-plane console at agent.clutchcall.dev, or through the admin API. When you save a trunk, the system seals it and pushes it to the engine’s live configuration store. The system does not keep trunks in your reporting database. The SIP Trunking page has the full field reference and the setup steps.

Numbers and per-tenant SIP hosts

When ClutchCall provisions your workspace, it creates DNS records for <workspace-id>.sip.clutchcall.dev and a matching WebRTC host. The records point at the engine. The engine reads the leftmost label of an inbound INVITE to identify your tenant. Multiple workspaces share one edge with no cross-tenant collisions. You then attach phone numbers (E.164 DIDs) to a workspace. You bind each number to a trunk and an agent. Imported and manually configured numbers route calls today.

The in-console “buy a number” search catalog is a demo stub (India-only, placeholder vendor). It does not purchase real numbers yet. To go live, import a DID that you already own from Twilio, Telnyx, Bandwidth, or another provider. Point its trunk at your workspace. See Number Provisioning.

Placing calls out

Outbound origination mirrors the inbound flow. A control-plane call mints a session and asks the engine to dial:

import { Voice } from "@clutchcall/sdk";

const voice = new Voice({ apiKey: process.env.CLUTCHCALL_API_KEY });

// Dial a number and drop it straight onto an AI agent.
const call = await voice.calls.originate({
  to: "+15551234567",
  from: "+18005550100",   // a DID on one of your outbound trunks
  app: "AI_BIDIRECTIONAL_STREAM",
  agentId: "agent_42",
});

console.log(call.callSid);

from clutchcall import Voice
import os

voice = Voice(api_key=os.environ["CLUTCHCALL_API_KEY"])

call = voice.calls.originate(
    to="+15551234567",
    from_="+18005550100",
    app="AI_BIDIRECTIONAL_STREAM",
    agent_id="agent_42",
)

print(call.call_sid)

For volume, a paced bulk dialer runs campaigns of up to tens of thousands of numbers. You can set calls-per-second and max-concurrency limits. The engine owns the pacing. See Outbound Calls.

Every call is observable

The SIP gateway emits a lifecycle event on each transition: initiated, established, ring, hold, transferred, and cleared. When the call ends, the gateway writes a CDR with the Q.850 cause and the duration. The media plane writes per-call quality (loss, jitter, MOS) alongside the CDR. A segment tagged with a handler shows whether the AI or a human handled that part of the call. All of this data lands in your reports. See Observability.

Next steps

Connect a carrier

Set up your first SIP trunk, inbound or outbound.

Take your first inbound call

Route a DID to an AI agent end to end.

Understand the lifecycle

Follow the full INVITE-to-CDR sequence.

Hand off to a human

Bridge a live AI call to a person.

Overview

Quickstart

Core Concepts

Build Guides

Agent Runtime

Transport to Web & Apps