How does WebRTC handle many-to-many connections?

Question

if I am in a room with other 7 users, I am wondering if WebRTC force every user to establish a connection to each one of other participants.

Obviously it would consume something like 7kb/s*7 download and even upload, and many connection cannot handle this if their connection is already busy. Instead with some kind of media relay the bandwidth usage would be only 7kb/s but you would lose bandwidth adaptation between peers.

Do you know any media relay, or way to solve this problem? is TURN server ( like https://code.google.com/p/rfc5766-turn-server/ ) suitable for this kind of job ( multicast included )?

Answer 1

A TURN server works as a fallback relay server in order to enable connectivity when direct peer-to-peer connectivity is impossible because of firewalls or other network issues. (More information here: press P for speaker notes.) TURN servers are not designed for media distribution.

A Multipoint Control Unit could solve the problem you refer to: there's an example topology for this here. As stated in the notes for that slide:

This is a server that's made specifically to do distribution of media, and can handle large numbers of participants; it can also do smart things like selective stream forwarding, mixing of the audio or video, or recording.

Answer 2

If the question still stands , here is my suggestion : Based on your SIP server install a RTP proxy software such as if you are using kamailio couple it with rtpengine.

Answer 3

Have a look at http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06 for details about WebRTC use cases. The authors mention a multi-user conferencing solution that uses a central server. So the best solution of establishing multi-user A/V conferences using WebRTC is to have such a central server that does the audio mixing and A/V "broadcasting" to all peers.

This circumvents the bandwidth problems you mention in your question. Currently a whole bunch of start-ups and established service providers are working on WebRTC-based conferencing solutions, just let your favourite web search engine pick some examples.

A TURN server alone doesn't suffice since TURN is only used to relay data for hosts that can't be reached directly (possibly because of firewalls). TURN servers don't terminate WebRTC connections.

Answer 4

A TURN server only aids in firewall traversal and getting through NATs. For true conferencing you need a central MCU type of server in the cloud, otherwise the conference just doesn't scale as you keep adding users. There are some conferencing servers for WebRTC such as from https://vline.com/ and http://ngmsvid.com

Answer 5

You are right that bandwidth adaption between peers is an issue.

A TURN server does not solve this issue since all it does is provide a stable endpoint, typically for people behind very restrictive NAT setups.

The solution to this issue lies in scalable video codecs. These video codecs are specifically designed to solve the multi-way video conferencing problem. H.264/SVC is one such scalable codec and it is currently used by Google+ Hangouts. VP8 also has temporal and spatial scalability and is used in WebRTC.

The scalable video codecs are designed so that parts of the stream, typically individual UDP packets, can be removed from the stream while preserving the ability to decode the video at a lower quality. At least three types of scalabilities are used:

• Temporal, in which the frames-per-second is reduced.
• Spatial, where the number of pixels is reduced.
• Quality, where the color resolutios is reduced.

If you implement a video conferencing server, you can go into the VP8 stream at a lower level than the WebRTC-level, do the necessary changes to each video stream, and solve the bandwidth adaption issue.

Answer 6

Yes, you would have to establish separate connections to each of your peers. In order to solve this you could use a media server like kurento.

With a media server every peer would connect to the media server, the server would then combine the video streams from your peers into one by placing them side by side and then send you the new stream. This saves peers the trouble of having to download streams from every other peer.