<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.
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
Option A — bring the Twilio SIP trunk (recommended)
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.
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.
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.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’smedia events
carry.
What it does not do is speak Twilio’s JSON envelope. So today you run a small
shim that:
- Accepts Twilio’s
<Stream>WebSocket connection. - Unwraps each
mediaevent — base64-decodesmedia.payloadback to raw 8 kHz µ-law. - Forwards the raw µ-law frames onto the TeleQuick WebSocket audio on-ramp,
keyed by
call_sid.
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:
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>.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.µ-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.Status
| Path | Status |
|---|---|
| Twilio SIP trunk → workspace SIP endpoint | Available — recommended for AI-on-call |
| µ-law → PCMU codec passthrough (zero transcode) | Available |
| Custom WebSocket audio on-ramp + your envelope shim | Available — you write the shim |
Native Twilio <Stream> adapter (no shim) | Roadmap — not shipped |
| Twilio as an external vendor bridge target | Available (external sidecar) |
Related
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.