The client would still need to send the full size stream to every other client "when talking" so you have the same problem if the client's upstream is < 5 mbps.
You aren't! This is just a hard design problem -- mesh topologies degrade rapidly beyond two-party communications, mixer topologies introduce lag and quality issues during the compositing phase, and router topologies are still being proved out (but are probably the best option for not-huge multiparty communications). There's no silver bullet, but several options that force reasonable tradeoffs in design.
Exactly, it's just a tough problem to solve. As you so eloquently stated, the server-based solutions all introduce a terrible amount of latency (500ms-1 sec+ round trip) so they're not a silver bullet either.
The impressive things about WebRTC like appear.in are:
- Video/audio quality is extremely good - better than almost any other server-based video chat.
- Latency is extremely low because of it's direct peer-to-peer communication method. It's awesome having video chat that is <20ms round trip latency (assuming you're all in the same geographic/metropolitan area).
- HTTPS/TLS/SSL gives you end-to-end encryption, which is very nice to have.
At the cost of very high bandwidth due to the mesh topology.
I just meant that I felt a little silly for overlooking something like that.
One of my biggest pet-peeves is when people swoop into a field they know very little about and proclaim they figured it all out, and i kind of feel like i did that here a little bit and it bothers me.