You already have a working voice stack — a LiveKit app, a WebRTC pipeline, a Twilio Media Streams bridge, an Asterisk or FreeSWITCH deployment, a bespoke WebSocket audio sender. Migrating to TeleQuick Voice does not mean rewriting it. The fastest, lowest-risk path is transport-first: keep your runtime, your agent loop, your ASR/LLM/TTS chain, and your call control — and swap only the layer that moves audio, onto real-time media over QUIC/MoQT on the single :443 plane.

The transport-first thesis

Most voice migrations stall because teams treat them as a full-platform port. You do not need to. Your runtime already produces and consumes audio frames across a media boundary — WebRTC’s SRTP, a WebSocket carrying PCM or µ-law, or RTP on a SIP trunk. Migration means re-pointing that one boundary at TeleQuick and leaving everything above it untouched.

What you keep

Your conversation loop, VAD and turn-taking, prompts and tools, models and vendor credentials, call-control logic, and dashboards.

What you swap

Only the media transport — the wire that carries encoded audio between your runtime and the endpoint (browser, app, or phone).
Whether TeleQuick also runs your agent is a separate, later choice. You can adopt the transport alone and keep your runtime indefinitely — see Keep Your Existing Agent Runtime. The menu below is only about the media boundary.

Pick your path

Choose by where your audio lives today. Each path re-points one boundary; the detailed page walks the cutover.

From WebRTC

Keep the browser’s capture, echo cancellation, and Opus encoder — divert the encoded frames onto QUIC/MoQT instead of ICE/DTLS/SRTP. Shipped in the TypeScript SDK.

From Self-Hosted LiveKit

Swap one import and run your Room / track code over our transport instead of a LiveKit SFU. Browser-first drop-in shim — Preview.

From Custom WebSocket Audio

Point a bespoke WebSocket audio sender at the engine’s WebSocket media fallback, or wire your runtime to the raw publish/subscribe primitives.

From Twilio Media Streams

Move a µ-law Media Streams WebSocket onto a SIP PCMU trunk with zero transcode, or bridge it as an external media vendor.

From Asterisk / FreeSWITCH

Re-point your SIP trunks and agent endpoints at TeleQuick’s built-in B2BUA, registrar, and dialplan. Shipped, no separate SIP proxy.

Migration Checklist

The step-by-step cutover checklist to run once you have picked a path.

What each path swaps

Status reflects what ships today. “Shipped” paths are proven end-to-end; “Preview” paths work for the core voice case but are not yet drop-in for every API of the source product. Read the callouts on each path page before you plan a cutover.
Coming fromYou swapYou keepStatus
WebRTC (browser)ICE/DTLS/SRTP → encoded Opus over QUIC/MoQTCapture, AEC/AGC/NS, Opus encoder, your runtimeShipped (TS SDK)
Self-hosted LiveKitThe SFU + livekit-client transport → MoQT sessionYour Room/track code, participants, dataPreview (browser shim)
Custom WebSocket audioYour WS media wire → engine WS media fallback / MoQT primitivesYour audio format handling and runtimeAvailable on-ramp
Twilio Media Streamsµ-law WS → SIP PCMU trunk (passthrough) or vendor bridgeYour app logic and promptsShipped (SIP)
Asterisk / FreeSWITCHYour PBX/proxy → our B2BUA + registrar + dialplanTrunks, DIDs, agents, routing intentShipped (SIP)
The LiveKit drop-in shim is Preview and browser-first. It covers the core voice path (publish/subscribe audio, data messages) and has been exercised browser-to-browser over the transport, but it is not yet a drop-in for every livekit-client API, video and screenshare are deferred, and a server-side Python (livekit.rtc) equivalent is not yet available. Pin a version and test your flows. If you only need transport, the raw MoQT primitives are the stable path. See Keep Your Existing Agent Runtime.

How a transport-first migration runs

Every path shares the same shape. The detail is on the per-source page; this is the arc.
1

Provision your workspace

Onboarding creates your per-tenant endpoints — <workspace-id>.sip.telequick.dev for phone traffic and <workspace-id>.webrtc.telequick.dev for browser and app media — plus your relay at relay.telequick.dev. Nothing in your runtime changes yet.
2

Re-point one media boundary

Swap only the transport for the path you picked: divert encoded WebRTC frames onto QUIC/MoQT, swap the LiveKit import, aim your WebSocket sender at the engine’s media fallback, or re-point a SIP trunk. Your agent code is untouched.
3

Verify audio both ways

Confirm uplink (caller/browser → runtime) and downlink (runtime → caller) audio flow, and check quality. On telephony legs, the media plane scores MOS, jitter, and loss per call so you can compare against your old stack — see MOS, Jitter & Loss.
4

Cut over gradually

Route a slice of traffic to the new transport (a test DID, a canary trunk, a subset of browser sessions), watch the dashboards, then widen. Follow the Migration Checklist for the full cutover sequence.

Where the runtime line falls

Transport-first is one end of a spectrum. Keeping your runtime and using only the wire is the minimal-change migration. If you would rather hand us the conversation loop too and bring only the models, that is a runtime adoption, not a transport swap — TeleQuick can run a cascaded ASR→LLM→TTS pipeline or a speech-to-speech provider for you.
“Keep your runtime” via an external vendor is a config-level bridge, not a packaged adapter. TeleQuick can front an external media vendor (LiveKit, Vapi, Twilio) with our transport by routing the leg to a bridge node, but there is no drop-in LiveKit-Agents or Pipecat adapter embedded in the runtime. Point those runtimes at a realtime endpoint or use the bridge — see Keep Your Existing Agent Runtime.

Next steps

Keep Your Existing Agent Runtime

Adopt the transport alone and leave your runtime in place — the shim and raw primitives, in depth.

WebRTC Diversion

How the encoded-frame tap moves a browser WebRTC pipeline onto QUIC without touching capture or codec.

SIP Trunking

Re-point carrier trunks at the built-in B2BUA and registrar for telephony migrations.

Migration Checklist

Run the ordered cutover checklist once you have chosen a path.