Feature: Group calls?
Opened this issue · 5 comments
Hi, great work with WebCall!
Just wondering if you have any intent to implement RTC group calls to WebCall:
https://superuser.com/questions/1609118/webrtc-for-group-calling
Thanks!
Sorry, probably this issue should go into the other repo: https://github.com/mehrvarz/webcall
Hi. Here my thoughts on the matter.
Connecting two WebRTC clients with each other is cheap. From the pov of the server it "costs" less than 100 KB traffic per call. And once connected the clients can stay connected for as long as they like. No server is needed for that.
Three or more clients and all traffic needs to be relayed. One 10 minute 3-party audio-only call will generate about 20 MB of traffic. This is a 200 fold increase. More participants? Longer calls? Video? Waaaaay more traffic.
If you run a server with a certain traffic budget, then more traffic per call means less calls per month. I am able to offer a free and completely unrestricted service based on P2P communications. There is little cost and good benefit. I would NOT know how to do the same with a group talk feature. Someone would need to pay for the 200x increase in traffic.
One more thing to consider: Relaying (via remote server) does at least double your latency. But for a live, two-way conversations you want as little latency as possible. Please compare the actual media quality of your favorite group talk solution vs. WebCall if you have a chance.
Why would clients connecting to each other and transmitting to each other (all without server) result in such traffic? Each client can send traffic to each client, straight forward and offloaded to clients. Think “bidirectional” mesh network as a group call. Or perhaps consider that Alice calls Bob, Bob adds Dave to the call by initiating a bidirectional to Dave and Dave's traffic goes through Bob to get to Alice. That way there is link redundancy and fail-over if Dave can't communicate to Alice but can to Bob.
Mobile devices relaying realtime audio/video data (from other peers to other peers) is not realistic due to severe latency.
For P2P group calls (without client-side relaying), each peer needs to handle data from and to (n-1) peers in realtime fashion. This will quickly stop working (cpu load, network load) with a low number of peers, even under ideal conditions.
The only practical solution for group calls is server-side multiplexing. Only 3 disadvantages:
- server needs to handle shi*load$ of data
- you get noticeably more latency/delay than over a direct P2P WebRTC link
- you lose E2EE (server can record your conversations)
Mobile devices relaying realtime audio/video data (from other peers to other peers) is not realistic due to severe latency.
And yet Voice over LTE is a thing, carries all audio over data now-days. (4G-LTE+)
For P2P group calls (without client-side relaying), each peer needs to handle data from and to (n-1) peers in realtime fashion. This will quickly stop working (cpu load, network load) with a low number of peers, even under ideal conditions.
Are you trying to say any audio-chatting apps with P2P is impossible without even trying to provide an actual technical reason? There are plenty of functional apps on Android that do this. Just use client-side relaying and/or muxing of audio, keeps bandwidth down, provides network failover. If other softwares are doing the same thing and can handle thousands of users simultaneously, I'm going to trust that it can be done. Server-side muxing, a simple Raspberry Pi running Mumble can handle a decent number of audio sessions before getting fussy, though that assumes each user is able to use the same codecs for considering bandwidth. Assuming max Opus bit-rate, a common US home has enough upstream to handle a minimum of 10 users. Note, most US internet is crappier than ISPs publicly state. I'm imagining Mumble or TeamSpeak, but for Android and with client-side relaying for the entire concept of P2P... *shrug*
As far as server-side handling of data, you don't need to give up E2EE. You can give up who is talking to who privacy, but you do not have to give up what the contents are. Think XMPP, which is pretty much exactly what WebCall is attempting to achieve as far as Jingle and such goes. Optional server-relaying, but E2EE. Video enabled, too. I use it with Android.