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.