WebRTC bandwidth requirements

The bandwidth requirements are almost the same as the bandwidth requirement for opus and vp8. Real time audio typically has a bitrate of 40-200kbit/s. Video requires at least 200 kbit/s (500kbit/s if you want to see people's faces).

According to webrtc-experiment the minimum bandwidth for opus is 6kbit/s and for vp8 100kbits/s. So in total that makes 106kbit/s but when you account for the overhead of the webrtc protocol stack and constantly varying network conditions I would guess that 200kbit/s is the minimum if one wants stable video and audio.

Chrome and Firefox both use opus and vp8 so the bandwidth requirements should be the same. Although I don't have any hard data to prove it.

You can see the current traffic generated by webrtc by going to chrome://webrtc-internals and inspecting all the charts.


For two-party conferences, 500 kbit/s for good conference-quality should be enough (per stream, so 1 Mbit/s load on a user's line). I'm in line with the other answer about that.

However, multi-party WebRTC bandwidth can be bottlenecked not just because of participants' Internet bandwidth, but also due to potential bandwidth limits of a TURN media relaying server, if you use one – ­which is needed where no P2P connections are possible due to difficult NAT setups. (All the details here.)

I attempted a rough calculation of how many users a TURN server can serve before maxing out its bandwidth:

  • Let's say we have 100 Mbit/s server bandwidth in total (in + out), and we want at most 60 Mbit/s used up by WebRTC traffic.

  • So for example when configuring the coturn TURN server, we'd set input and output stream each to 30 Mbit/s (3,750,000 Byte/s, using bps-capacity=3750000).

  • The output stream will experience the higher load, because given n participants, there will be 1 video input stream and n-1 video output streams per participant for the TURN server to handle. Means the bottleneck will be the 30 Mbit/s combined output stream.

  • In the worst case (where no STUN negotiated P2P connections at all are possible), this bandwidth will suffice for: 30 Mbit/s / 500 kbit/(s*stream) = 60 video streams.

  • Given n participants, there will be n-1 output streams per participant, which means a total of n * (n-1) = n^2 - n streams. Our max. 60 streams are then enough for: n^2 - n = 60 <=> n = 8.26 = ~8 participants (calculation).

Not sure yet how accurate this is, though.