WebRTC Insertable Streams: AI Audio Processing in the Browser (2026)

Insertable Streams was the first browser API that let you put your own code between the encoder and the network. For AI voice in 2026 it is the difference between shipping noise suppression as a Chrome flag and shipping it as a feature.

Why Insertable Streams matters for AI voice

Browsers have always had AEC, AGC, and basic noise suppression baked into the WebRTC pipeline. The problem is that those defaults were tuned for video conferencing two-way calls, not for AI voice agents that have to detect a single user speaking on cellular Wi-Fi from a coffee shop. Insertable Streams (and its successor, the Encoded Transform API) lets you stream raw or encoded frames into a Worker, run a model or DSP block, and stream the result back into the peer connection. The encoder, the network, and the receiving SFU all see your transformed frames; the rest of the WebRTC pipeline does not change.

Production reasons teams reach for Insertable Streams in 2026:

• AI noise suppression that beats the default WebRTC denoiser on cellular and reverberant rooms (RNNoise, krisp, Cleanvoice variants compiled to ONNX).
• Synthetic-voice watermarking for FTC and EU AI Act disclosure: an inaudible marker survives codec recompression so an audited recording can later be proven AI-originated.
• On-device VAD that gates the audio before it leaves the browser, saving 80–120 ms of "is the user still talking?" round trips.
• End-to-end encryption via SFrame, which is the reason the API was designed in the first place.
• Telephone-grade dereverberation for users in tile bathrooms, lobby kiosks, and warehouse environments.

The economic argument is simple: the heaviest improvements in voice quality and privacy now live below the codec, and you cannot reach below the codec without this API.

How Insertable Streams fits the WebRTC pipeline

```mermaid flowchart LR Mic[Microphone] --> Track[MediaStreamTrack] Track --> Sender[RTCRtpSender] Sender -.->|encoded frames| Worker[Web Worker - AI model] Worker -.->|transform stream| Sender Sender --> Net[(Network / SFU)] ```

The flow uses two streams: a `ReadableStream` of frames coming out of the encoder, and a `WritableStream` going back into the packetizer. Your transformer reads, modifies, and writes. Critically, all of this runs off the main thread inside a `Worker`, so model inference does not block UI rendering.

CallSphere implementation

CallSphere uses Insertable Streams in the browser-side voice paths for two of its six verticals (real estate, healthcare, behavioral health, legal, salon, insurance):

• Real Estate (OneRoof) — The browser pipes mic audio into a Worker that runs a 1.2 MB ONNX VAD before frames reach our Pion Go gateway 1.23. The gateway forwards over NATS to the 6-container pod (CRM, MLS, calendar, SMS, audit, transcript). We trim 80–120 ms of "are you ready?" latency by gating speech detection client-side. See /industries/real-estate.
• /demo browser path — A second Worker watermarks outgoing audio with an inaudible marker so customers can later prove a clip was synthesised by our agent. Try it at /demo.

Across 37 agents, 90+ tools, and 115+ database tables we keep the heavy DSP off the server hot path, which lets every agent share the same OpenAI Realtime endpoint. SOC 2 + HIPAA controls cover the recorded artifacts, and the worker model files themselves are signed, hashed, and pinned to a SHA-256 in the manifest. Pricing remains $149/$499/$1499 with the 14-day trial; affiliates earn 22% — see /affiliate.

Code snippet (TypeScript, browser side)

```ts // main.ts const stream = await navigator.mediaDevices.getUserMedia({ audio: true }); const [track] = stream.getAudioTracks();

const pc = new RTCPeerConnection(); const sender = pc.addTrack(track, stream);

// @ts-expect-error - createEncodedStreams is non-standard but Chromium-supported const { readable, writable } = sender.createEncodedStreams();

const worker = new Worker("/audio-transform.js", { type: "module" }); worker.postMessage({ readable, writable }, [readable, writable]); ```

```ts // audio-transform.js (runs inside the Worker) self.onmessage = ({ data: { readable, writable } }) => { const transformer = new TransformStream({ async transform(chunk, controller) { // chunk is an RTCEncodedAudioFrame const view = new DataView(chunk.data); // ... run noise suppression / watermarking / VAD on view ... controller.enqueue(chunk); }, }); readable.pipeThrough(transformer).pipeTo(writable); }; ```

Build steps

1. Detect support: `if (RTCRtpSender.prototype.createEncodedStreams) { ... }`. Insertable Streams ships in Chrome/Edge; Safari is still on the older API.
2. Spin up a dedicated Worker; never run model inference on the main thread.
3. Transfer the readable/writable streams to the Worker with the second `postMessage` argument so they hop threads zero-copy.
4. Inside the Worker, pipe `readable.pipeThrough(transformer).pipeTo(writable)` and keep the transform synchronous when you can.
5. Watch CPU with `getStats()`; a 30 ms transform budget per frame is the production ceiling.
6. Cache the model once at Worker boot; reloading per session adds 200–400 ms of cold start.
7. Plan for the migration to RTCRtpScriptTransform — the W3C Working Draft (April 2026) replaces `createEncodedStreams` with a Worker-based transform constructor.

Common pitfalls

• Main-thread inference — a 12 ms RNNoise pass on the main thread blocks layout and produces audible 30 ms hitches. Always use a Worker.
• Stream backpressure — if your transformer cannot keep up with 50 frames/sec the WritableStream backs up and the encoder will eventually stall. Sample your transform's average and p99 latency.
• Frame-size assumptions — Opus frames in Chromium are 20 ms by default; Firefox can produce 10 ms or 60 ms. Treat `frame.data.byteLength` as variable.
• Forgetting the migration — `createEncodedStreams` is going away. New code should branch on `"RTCRtpScriptTransform" in self` and use the standardized API.
• Privacy footprint — any frame manipulation can leak through `getStats()` audio-level fields. Sanitize before sending stats anywhere outside your VPC.

FAQ

Does Safari support Insertable Streams? Not yet. As of May 2026 Safari still ships only the older read-only API; full Encoded Transform support is on track for Safari 27.

Does it slow audio down? Each transform adds 1–3 ms in our measurements. Stay under 30 ms total per frame to avoid jitter buffer growth.

Can I run an AI model in the Worker? Yes — onnxruntime-web with WebGPU runs RNNoise-style models comfortably under 5 ms per 10 ms frame on a M2 MacBook Air.

Is this still the right API? For new code, target RTCRtpScriptTransform. For existing Chromium-only code, `createEncodedStreams` is fine until ~2027.

Can I do video transforms with the same API? Yes — `RTCEncodedVideoFrame` exposes the same shape; SFrame examples in the W3C explainer cover both.

Does it stack with E2EE? Yes — an SFrame worker can sit alongside the noise-suppression worker as long as you order them correctly: encrypt last on the sender, decrypt first on the receiver.

Does it work with simulcast? For audio there is no simulcast; for video the answer is yes, with one transform per layer.

Can I drop frames? Yes — call `controller.enqueue` only when you want to keep the frame. Be careful though, dropping audio frames produces audible glitches.

Production playbook for AI voice teams in 2026

Three production rules survive contact with reality:

1. Run two workers, not one. One for E2EE/SFrame, one for noise/VAD. Putting both in the same worker conflates failure modes and makes profiling impossible.
2. Profile per browser. Chrome on M2 is not Chrome on a Pixel 6a. The 30 ms transform budget is generous on desktop, tight on mid-range Android.
3. Lock model versions in the manifest. A silent ONNX swap that adds 8 ms per frame will not fail any test; it will quietly degrade experience.

We pin every model artifact by SHA-256, refuse to load anything unsigned, and gate model upgrades behind a 2% canary that compares concealment ratio in production before promoting.

Sources

• https://www.w3.org/TR/webrtc-encoded-transform/
• https://webrtc.github.io/samples/src/content/insertable-streams/audio-processing/
• https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/
• https://openai.com/index/delivering-low-latency-voice-ai-at-scale/
• https://trtc.io/blog/details/what-is-webrtc-insertable-streams
• https://www.red5.net/docs/development/webrtc/insertable-streams/

Try the WebRTC + Worker path live on our /demo, see the bundle in /pricing, or start a /trial.