How does WebRTC handle many-to-many connections?

Question

If I enter the room with the other 7 users, I wonder if WebRTC is forced to force each user to connect to each of the other participants.

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

Do you know any media link or can you solve this problem? is a TURN server (e.g. https://code.google.com/p/rfc5766-turn-server/ ) suitable for this kind of job (including multicast)?

Answer 1

The TURN server acts as a standby relay server to provide connectivity when direct peer-to-peer connections are not possible due to firewalls or other network problems. (Details here : press P for presenter notes.) TURN servers are not intended for multimedia distribution.

A Multipoint Control Unit can solve the problem you are referring to: there is an example of the topology for this here , As indicated in the notes for this slide:

This is a server specifically designed for media distribution, and can handle a large number of participants; it can also do things like selectively stream, mix audio or video, or record.

Answer 2

See http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06 for more information on WebRTC use cases. The authors mention a multi-user conferencing solution that uses a central server. Therefore, the best solution for creating multi-user audio / video conferencing using WebRTC is to have a central server that performs audio mixing and A / V broadcast "for all peers."

This circumvents the bandwidth issues that you mention in your question. Currently, a whole group of startups and regular service providers are working on WebRTC-based conferencing solutions, just let your favorite search engine choose a few examples.

A single TURN server is not enough because TURN is only used to relay data to hosts that cannot be reached directly (possibly due to firewalls). TURN servers do not terminate WebRTC connections.

Answer 3

The TURN server is only used to bypass the firewall and pass through NAT. For true conferencing, you need a central MCU server in the cloud, otherwise the conference simply does not scale as you add users. There are several conferencing servers for WebRTC, such as https://vline.com/ and http://ngmsvid.com

Answer 4

Yes, you will need to establish separate connections to each of your peers. To solve this problem, you can use a media server like kurento .

When using a media server, each partner will connect to the media server, then the server will combine the video streams from its peers into one, placing them next to each other, and then send a new stream. This eliminates the need for users to download streams from all other partners.

Answer 5

You are right that adapting bandwidth between peers is a problem.

The TURN server does not solve this problem, because all it does is provide a stable endpoint, usually for people with very strict NAT settings.

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

Scalable video codecs are designed so that parts of the stream, usually individual UDP packets, can be removed from the stream, while maintaining the ability to decode video with lower quality. At least three types of scalability are used:

• Temporary, in which the number of frames per second decreases.
• Spatial, where the number of pixels decreases.
• Quality at which color solutions are reduced.

If you implement a video conferencing server, you can go to the VP8 stream at a lower level than the WebRTC level, make the necessary changes to each video stream and solve the problem of adapting to bandwidth.

Answer 6

If the question still remains, here is my suggestion: Based on your SIP server, install an RTP proxy server, for example, if you are using a kamailio couple with rtpengine.