# Transport to Telephony Overview > Connect the phone network to your voice stack: SIP trunks, numbers, inbound and outbound calls, and warm handoff to humans. The phone network carries most business conversations, so FirstByte 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. > **NOTE:** > 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](/modalities/voice/migration/overview). ## How a phone call reaches your agent A call crosses four boundaries between the carrier and your agent. You configure something at each boundary. 1. **Signalling — SIP gateway / B2BUA** The carrier sends an `INVITE` to your per-tenant SIP host, `.sip.firstbyte.fast`. 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. 2. **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](/modalities/voice/transport-telephony/pbx-acd) layer holds the number-to-destination mapping and the skill-queue routing. 3. **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//uplink`. The agent's reply returns on `voice//downlink`. The engine paces the reply out as G.711 every 20 ms. The [Codec Guide](/modalities/voice/transport-telephony/codecs) has the codec details. 4. **Handling — agent or human** The AI runtime attaches to those tracks. It runs your ASR/LLM/TTS or speech-to-speech pipeline (see [Runtime](/modalities/voice/runtime/overview)). 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](/modalities/voice/transport-telephony/ai-human-handoff). ## The pieces you configure - **[SIP Trunking](/modalities/voice/transport-telephony/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](/modalities/voice/transport-telephony/number-provisioning)** — Import a DID. Assign it to a trunk and an agent. Route inbound calls from it. Each workspace also gets its own `.sip.firstbyte.fast` host. - **[Inbound Calls](/modalities/voice/transport-telephony/inbound)** — 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](/modalities/voice/transport-telephony/outbound)** — 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](/modalities/voice/transport-telephony/pbx-acd)** — Route calls through VDNs, skills, and queues. Ring human agents on browser softphones or real SIP deskphones. - **[AI-to-Human Handoff](/modalities/voice/transport-telephony/ai-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](/modalities/voice/transport-telephony/call-lifecycle)** — Follow the full signalling and media sequence, from `INVITE` and early media through teardown, CDR, and Q.850 cause. - **[Codec Guide](/modalities/voice/transport-telephony/codecs)** — 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 `INVITE`s 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. - **`direction`** (`inbound | outbound | both`) — The direction that calls flow over this trunk. - **`media_mode`** (`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`. - **`realm`** (`internal | external | ai_vendor`) — Classifies the far side as an internal device domain, an external carrier, or a vendor bridge. - **`inbound_rule / inbound_skill_id / vdn_id`** (`string`) — The action for an inbound call on this trunk: stream to an AI agent, enter a skill queue, or enter a VDN program. > **NOTE:** > You create and edit trunks in the control-plane console at `agent.firstbyte.fast`, 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](/modalities/voice/transport-telephony/sip-trunking) page has the full field reference and the setup steps. ## Numbers and per-tenant SIP hosts When FirstByte provisions your workspace, it creates DNS records for `.sip.firstbyte.fast` 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. > **WARNING:** > 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](/modalities/voice/transport-telephony/number-provisioning). ## Placing calls out Outbound origination mirrors the inbound flow. A control-plane call mints a session and asks the engine to dial: **TypeScript:** ```typescript import { Voice } from "@clutchcall/agents"; 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); ``` **Python:** ```python from clutchcall.voice 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](/modalities/voice/transport-telephony/outbound). ## 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](/modalities/voice/observability/overview). ## Next steps - **[Connect a carrier](/modalities/voice/transport-telephony/sip-trunking)** — Set up your first SIP trunk, inbound or outbound. - **[Take your first inbound call](/modalities/voice/transport-telephony/inbound)** — Route a DID to an AI agent end to end. - **[Understand the lifecycle](/modalities/voice/transport-telephony/call-lifecycle)** — Follow the full INVITE-to-CDR sequence. - **[Hand off to a human](/modalities/voice/transport-telephony/ai-human-handoff)** — Bridge a live AI call to a person.