javascript WebRTC 如何处理多对多连接？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17134778/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How does WebRTC handle many-to-many connections?
提问by rodi
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.
如果我和其他 7 个用户在一个房间里，我想知道 WebRTC 是否会强制每个用户与其他每个参与者建立连接。
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.
显然它会消耗 7kb/s*7 下载甚至上传，如果它们的连接已经很忙，许多连接无法处理这个。相反，使用某种媒体中继，带宽使用率仅为 7kb/s，但您将失去对等点之间的带宽自适应。
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 )?
您知道任何媒体中继，或解决此问题的方法吗？TURN 服务器（如https://code.google.com/p/rfc5766-turn-server/）是否适合这种工作（包括多播）？
回答by Sam Dutton
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.
TURN 服务器用作回退中继服务器，以便在由于防火墙或其他网络问题而无法进行直接对等连接时启用连接。（此处的更多信息：按 P 获取演讲者备注。）TURN 服务器不是为媒体分发而设计的。
A Multipoint Control Unitcould 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.
这是一个专门做媒体分发的服务器，可以处理大量的参与者；它还可以执行智能操作，例如选择性流转发、音频或视频混合或录制。
回答by Makkes
Have a look at http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06for 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.
有关 WebRTC 用例的详细信息，请查看http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06。作者提到了一个使用中央服务器的多用户会议解决方案。因此，使用 WebRTC 建立多用户 A/V 会议的最佳解决方案是拥有这样一个中央服务器，可以向所有对等方进行音频混合和 A/V“广播”。
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.
这绕过了您在问题中提到的带宽问题。目前，一大批初创公司和成熟的服务提供商正在开发基于 WebRTC 的会议解决方案，让您最喜欢的网络搜索引擎挑选一些示例。
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.
单独的 TURN 服务器是不够的，因为 TURN 仅用于为无法直接访问的主机（可能是因为防火墙）中继数据。TURN 服务器不会终止 WebRTC 连接。
回答by Amir Vakili
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.
是的，您必须与每个对等点建立单独的连接。为了解决这个问题，您可以使用像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.
使用媒体服务器，每个对等方都将连接到媒体服务器，然后服务器会将来自对等方的视频流合并为一个，将它们并排放置，然后向您发送新流。这为对等点节省了必须从其他对等点下载流的麻烦。
回答by user239558
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.
TURN 服务器并不能解决这个问题，因为它所做的只是提供一个稳定的端点，通常是为那些使用非常严格的 NAT 设置的人提供的。
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.
这个问题的解决方案在于可扩展的视频编解码器。这些视频编解码器专为解决多路视频会议问题而设计。H.264/SVC 就是这样一种可扩展的编解码器，目前被 Google+ Hangouts 使用。VP8 还具有时间和空间可扩展性，用于 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:
可伸缩视频编解码器的设计使得流的一部分，通常是单独的 UDP 数据包，可以从流中删除，同时保留以较低质量解码视频的能力。至少使用了三种类型的可扩展性：
- 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.
如果你实现了视频会议服务器，你可以进入比WebRTC级别更低的VP8流，对每个视频流做必要的改变，解决带宽适配问题。
回答by Altanai
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.
如果问题仍然存在，我的建议是：根据您的 SIP 服务器安装 RTP 代理软件，例如，如果您使用 kamailio，请将其与 rtpengine 结合。
