AVAY

How Many People Can Join a Video Call: The Real Ceiling

16 August 2026

There's no single number, because the limit isn't set by the app — it's set by whether the call routes media directly between participants (mesh) or through a server (SFU), and by whose CPU and upload speed pays for it. A mesh call is usually fine at four and struggling by nine. An SFU-based call can hold fifty or more, but the bottleneck moves from your upload to your download and your machine's ability to decode and render that many streams at once.

A chain showing a camera feed being encoded once, sent to a server, duplicated for each recipient, and decoded separately on each participant's device. single upload one connection server-side c… per-person do… 1 Camera feed captured locally 2 Encoder compressed once 3 SFU server receives one stream 4 Fan-out duplicated per recipient 5 Client decode rendered as a tile
How a server-relayed (SFU) call moves one person's video to everyone else

The question is architecture, not headcount

Every video call has to move a camera and microphone feed from each person to every other person. The two dominant ways to do that produce very different ceilings, and most people never see the difference because they only ever join calls, they don't build them.

In a mesh call, every participant's device connects directly to every other participant's device — no server sits in the middle relaying video. In a server-relayed call (an SFU, or Selective Forwarding Unit), each device sends one upload stream to a server, and the server copies and forwards it to everyone else. Same call, same faces on screen, completely different math underneath.

Why mesh calls fall apart around eight or nine

In a mesh call with N people, each device has to maintain N-1 direct connections. That means encoding and sending N-1 upload streams and decoding N-1 incoming ones — simultaneously, with no server to absorb the fan-out.

At four people, that's 3 up and 3 down. A modest laptop on home wifi handles that without much strain: maybe 1-1.5 Mbps per 480p stream, so 4-5 Mbps total upload, well inside most home connections. At nine people, it's 8 up and 8 down. Now you're pushing 8-12 Mbps of upload from a single machine while decoding eight incoming video feeds on the CPU, and most residential upload speeds — often capped at 5-20 Mbps even where download is fast — simply can't sustain it. The first symptom is usually one or two participants freezing or dropping to audio-only, not everyone degrading evenly, because the weakest uplink in the mesh determines what everyone else sees of that person.

This is also why a mesh call that was fine yesterday breaks today with the same headcount: it's sensitive to whichever single participant has the worst connection, since their upload has to reach everyone directly.

What an SFU changes and what it doesn't

An SFU fixes the upload problem by having each participant send exactly one stream — to the server, not to everyone. The server then duplicates and forwards it to whoever needs it, often at different resolutions per recipient (simulcast), so a phone on a slow connection doesn't get the same bitrate as a laptop on fiber.

This is why platforms built on an SFU can hold thirty, fifty, or more participants without every device needing a 20 Mbps uplink. But the ceiling doesn't disappear — it moves. Your upload is now flat regardless of group size, but your download and decode load still scale with N. A device rendering forty live video tiles is decoding forty streams and compositing forty frames into a layout, and that's a CPU and GPU cost that has nothing to do with network speed. This is why large SFU calls switch to speaker-view or paginated grids well before the participant count gets absurd — usually somewhere between 25 and 49 visible tiles, depending on the client — and why turning video off for most participants is the actual fix once a call gets large, not a bandwidth upgrade.

Where the practical ceiling actually sits

For a mesh architecture, plan on real trouble starting somewhere between 6 and 10 participants, with 4-5 as the comfortable zone on typical home connections. For an SFU architecture, the network ceiling is much higher — into the hundreds for audio and dozens for full-grid video — but the rendering ceiling on the client kicks in well before that, which is why most tools quietly cap visible video tiles rather than the meeting itself.

Beyond that, the tools that claim to hold hundreds or thousands of people are usually doing something structurally different: most attendees are receive-only, sending no upload stream at all, which is a webinar, not a meeting. That distinction matters more than the headline number. A 500-person 'meeting' where 495 people never unmute and never send video is a broadcast wearing a meeting's name.

Where AVAY sits in this

AVAY runs on a server-relayed model in the browser, so the upload-side math that breaks mesh calls at eight or nine people doesn't apply — a participant sends one stream regardless of group size. It's built and tuned for meeting-sized groups where everyone is expected to be present and speaking, not for webinar-scale broadcast to a mostly silent audience, so if the goal is a one-to-many stream to hundreds of receive-only viewers, that's a different tool than the problem AVAY is solving.

One thing worth knowing regardless of platform: the AI participant that transcribes and answers questions in an AVAY call doesn't add a video stream to the call itself, so it doesn't count against the same rendering ceiling that live video tiles do.

Upload cost per participantWhere the ceiling actually sitsTypical practical limit
Mesh (peer-to-peer)Scales with N-1: full stream sent to every other peerWeakest participant's uplink, plus local encode/decode load 4-6 comfortable, 8-9 typically breaks
SFU (server relay)Flat: one upload stream regardless of group sizeDownload bandwidth and client-side decode/render CPU20-50+ before UI switches to speaker view or paginates
MCU (server mixes into one stream)Flat, and download is also flat — server sends one composited feedServer-side compute; client work stays low even at scaleVery large, but layout and speaker prominence are fixed server-side
Mesh, SFU and MCU: what each costs the participant's device
  1. 1 First few joins Each new person adds one more direct connection everyone else's device has to encode and decode, but total load stays under most uplinks' ceiling.
  2. 2 Around six to seven Devices are now juggling five or six simultaneous encode/decode pairs, and the call becomes sensitive to whichever single participant has the weakest connection.
  3. 3 Eight or nine Upload demand per device (7-8 simultaneous streams) exceeds what typical home uplinks sustain, and video for one or more participants starts dropping to audio-only or freezing.
  4. 4 Past that point The call doesn't fail uniformly — it degrades unevenly, and adding participants makes it worse for everyone already on the call, not just the newcomer.
What happens on a mesh call as people join, in order

Common questions

What's the actual max on Zoom, Meet, or Teams?

All three use server-relayed architectures, and their published limits (often 100-1,000 depending on plan and whether it's a meeting or webinar mode) reflect licensing and product tiers more than a hard technical wall. The real-world limit most people hit first is the client rendering dozens of live video tiles at once, which is why these platforms switch to speaker view, grid pagination, or 'view more' well before the account limit is reached.

Why does audio hold up fine when video breaks on a big call?

Audio streams run at a tiny fraction of video's bitrate — a compressed voice stream is typically under 50 kbps versus 500 kbps to 2.5 Mbps for a video stream at reasonable quality. A connection that can't sustain nine simultaneous video streams can usually sustain nine audio streams without noticing, which is why calls often degrade to voice-only rather than dropping entirely.

Will upgrading my internet fix a call that breaks at nine people?

On a mesh call, yes, up to a point — more upload bandwidth directly raises the number of simultaneous streams your device can push. On an SFU call, faster internet mostly helps your download side; your CPU's ability to decode and render many tiles at once becomes the limiting factor before bandwidth does, so a faster connection on an old or thermally-throttled laptop won't fix a call that's stuttering because of rendering load.

Does having an AI notetaker in the call use up one of the slots or add load?

It depends on the platform, but a well-built AI participant typically joins as a listener rather than a full video peer, so it doesn't add an encode/decode video stream that counts against the rendering ceiling. It still consumes a participant slot on platforms that count by connection, but the video-quality math that breaks mesh calls at high counts isn't affected by its presence.

The short version

There's no fixed number of people a video call can hold — there's a mesh ceiling around 6-9 set by upload bandwidth, and a server-relayed ceiling set by how many video tiles a device can decode and render, and the fix for each is different.

Try it on your next call

Meetings that take their own notes, in the browser: avay.ai.