Bring calls you run on Twilio into TeleQuick Voice. This page is honest about status: a drop-in Twilio Media Streams adapter — one that terminates Twilio’s <Stream> TwiML protocol and its JSON media envelope natively — is not shipped yet. But two on-ramps carry Twilio traffic today, and the Media Streams adapter, when it lands, reuses the exact same 8 kHz µ-law WebSocket shape those on-ramps already use.
No native <Stream> adapter yet (preview). TeleQuick does not yet terminate Twilio’s Media Streams protocol — the <Connect><Stream> handshake and its connected / start / media / mark / stop JSON events — as a turnkey endpoint. If you point a Twilio <Stream> straight at the platform, it will not be understood. Use one of the two paths that work today. Everything under the intended adapter is roadmap and may change.

Pick the right on-ramp

Twilio users reach for Media Streams for one of two reasons. The better TeleQuick path depends on which is yours:

You want an AI agent on the call

You stream audio to your own model today only because Twilio can’t run the agent for you. On TeleQuick the agent runs in the engine — so you don’t need Media Streams at all. Bring the SIP trunk and let the runtime handle the media. This is the recommended, fully-shipped route.

You keep your own media processing

You genuinely need raw audio frames delivered to your own service over a WebSocket (custom DSP, a bespoke pipeline, an external orchestrator). Use the custom WebSocket audio on-ramp and translate Twilio’s envelope with a thin shim.

What works today

Twilio Elastic SIP Trunking terminates on your workspace’s own SIP endpoint with zero Media Streams involved. Point Twilio at <workspace-id>.sip.telequick.dev and calls flow straight into the runtime — AI agents, IVR flows, and human queues — with the phone leg staying G.711 µ-law on the wire.
1

Create a trunk in TeleQuick

Add a bring-your-own trunk pointed back at Twilio, matched by Twilio’s signalling source IPs. See SIP trunking for every field.
2

Point Twilio's Origination URI at your endpoint

In the Twilio console, set the trunk’s Origination URI to sip:<workspace-id>.sip.telequick.dev. Inbound calls from a configured trunk peer bypass the workspace registrar ACL, so Twilio does not need to register.
3

Route the inbound calls

Set the trunk’s inbound rule to Handle with AI (or bind it to a skill / VDN for an IVR/ACD flow). See Inbound calls.
Because the wire codec stays G.711 µ-law on both sides, there is no transcode on a straight carrier hand-off — see the passthrough fast paths. The runtime only transcodes to its internal audio bus when a model actually needs PCM.

Option B — custom WebSocket audio + a Twilio envelope shim

If you must keep the WebSocket-audio shape, TeleQuick exposes a custom WebSocket audio on-ramp for bespoke senders that stream raw framed audio. It is codec-agnostic at the µ-law layer: 8 kHz µ-law frames map straight onto a PCMU SIP trunk with zero transcode — the same shape Twilio’s media events carry. What it does not do is speak Twilio’s JSON envelope. So today you run a small shim that:
  1. Accepts Twilio’s <Stream> WebSocket connection.
  2. Unwraps each media event — base64-decodes media.payload back to raw 8 kHz µ-law.
  3. Forwards the raw µ-law frames onto the TeleQuick WebSocket audio on-ramp, keyed by call_sid.
The Twilio side of that shim is Twilio’s own documented protocol — you receive events like this from Twilio:
{ "event": "start",  "start": { "streamSid": "MZ…", "mediaFormat": { "encoding": "audio/x-mulaw", "sampleRate": 8000, "channels": 1 } } }
{ "event": "media",  "media": { "track": "inbound", "chunk": "1", "timestamp": "5", "payload": "<base64 µ-law>" } }
{ "event": "stop",   "stop":  { "callSid": "CA…", "streamSid": "MZ…" } }
Your shim decodes media.payload and writes the bytes to the TeleQuick WS audio bridge. See Migrate from custom WebSocket audio for the on-ramp’s frame contract — the same µ-law bytes flow, you just strip Twilio’s wrapper first.
This is the same WebSocket-audio ingress that vendor bridges (for example to LiveKit or Vapi) ride. If you’d rather route the media to an external agent-orchestration vendor instead of the in-engine runtime, that path is described under custom runtime & vendor bridge.

The intended Media Streams adapter (roadmap)

The planned adapter removes the shim: you point Twilio’s <Stream> at a TeleQuick endpoint and it Just Works. Conceptually — this is the intended shape, not shipped behavior:
1

Native `<Stream>` terminator

A WebSocket endpoint that speaks Twilio’s protocol directly — accepts the connected / start / media / mark / stop events and answers with mark / clear — so your TwiML is just <Connect><Stream url="wss://…" /></Connect>.
2

streamSid → call_sid mapping

The adapter maps Twilio’s streamSid / callSid onto the TeleQuick call_sid so the session, agent, recording, and telemetry all key off one identifier — see Sessions, calls, tracks & streams.
3

µ-law passthrough, zero transcode

Because Twilio streams 8 kHz µ-law and the phone plane is PCMU, inbound media payloads land on a PCMU leg without re-encoding — the codec fast path that already exists.
4

mark / clear for barge-in

Outbound audio carries Twilio mark events so your app tracks playback boundaries, and honors clear to flush buffered audio on barge-in — mapping onto the runtime’s turn-taking and interruption model.
Do not build against the adapter yet — there is no <Stream> endpoint URL to target. The shape above may change before it ships. If a native Media Streams adapter is on your critical path, tell your TeleQuick team so it can be prioritized and scoped against your exact TwiML.

Status

PathStatus
Twilio SIP trunk → workspace SIP endpointAvailable — recommended for AI-on-call
µ-law → PCMU codec passthrough (zero transcode)Available
Custom WebSocket audio on-ramp + your envelope shimAvailable — you write the shim
Native Twilio <Stream> adapter (no shim)Roadmap — not shipped
Twilio as an external vendor bridge targetAvailable (external sidecar)

Migrate from custom WebSocket audio

The WS audio on-ramp your Twilio envelope shim forwards to.

SIP trunking

Bring the Twilio Elastic SIP trunk — the fully-shipped route.

Codecs & passthrough

Why 8 kHz µ-law lands on a PCMU trunk with zero transcode.

Migration overview

Every source we move users off, and the migration checklist.