WebRTC recording: cloud vs local trade-offs

There are three ways to record a WebRTC call.

1. Cloud composite recording

The SDK provider records the call server-side as a single composited video. You get one MP4 per call, ready to play.

Good: zero client-side complexity, consistent output, works even if a participant drops.

Bad: expensive (often 2-3x the per-minute call cost), and the composite layout is fixed at recording time.

2. Cloud per-track recording

Each participant's audio and video are recorded as separate tracks. You composite them later (or never).

Good: flexibility — you can re-render the composite with different layouts, or pull just one participant's audio.

Bad: still expensive, and now you have a composition pipeline to operate.

3. Local browser recording

The recording runs on one client (usually a 'host' bot or one participant's browser). Output is uploaded after the call.

Good: very cheap (no extra SDK cost), full control.

Bad: if the recording client drops, you lose the recording. Quality depends on that client's network and CPU.

The decision

For compliance use cases (telehealth, support transcripts) — cloud composite, every time. The reliability matters more than the cost.

For internal training archives, marketing reels, or anything where 'most calls recorded' is good enough — local recording wins on cost.

Per-track is a power move when you need post-production. Most integrations do not.