我的公司正在使用Wowza Media Server实现音频聊天服务器，但我们需要一些指导来帮助我们解决以下带宽问题：
状况：
我们有一个音频聊天系统，用户可以与他人协作。 N个用户发布到他们自己的音频频道，同时订阅N-1个音频频道（其他用户减去他们自己的频道）。
问题：
当您开始添加更多用户时，带宽变得相当快。例如，假设4个用户在线 - 用户A，用户B，用户C和＆amp;用户D.如果每个用户发布一个8kbps音频通道，所有其他用户都在订阅，那么使用的总带宽将是96kbps：
用户A = 24kbps（来自3个流：订阅用户B为8kbps，订阅用户C为8kbps，订阅用户D为8kbps）+
用户B = 24kbps（来自3个流：订阅用户A，用户C和用户D的8kbps）+
用户C = 24kbps（来自3个流：订阅用户A，用户B和用户D的8kbps）+
用户D = 24kbps（来自3个流：订阅用户A，用户B和用户C的8kbps）=总共96kbps
我认为我们需要做什么：
在线合并所有用户频道的音频频道（实时）（除了自己的频道），并让每个用户订阅这个独特的新合并频道，如下所示：
用户A = 8kbps（来自用户B，C和D的1个合并流）+
用户B = 8kbps（来自用户A，C和D的1个合并流）+
用户C = 8kbps（来自用户A，B和D的1个合并流）+
用户D = 8kbps（来自用户A，B和C的1个合并流）= 32kbps总计
您可以快速查看此问题可能失控的位置，因为此示例一次只有4个人在线。假设您总共添加5个，那么在我们当前的设置下，带宽将使用20个不同的订阅流，总计160kbps。然而，最佳合并解决方案每个额外用户仅增加8kbps，因此5个用户总共为40kbps，6个用户为48kbps等。
SO，有没有人对如何实现这一目标有任何建议？
答案 0 :(得分：0)
你可能过度分析了它。只有一个用户可能在任何时间点进行通话（您可以假设有一些重叠，如在正常对话中）。如果您有语音活动检测（简单的阈值处理可能有效），那么您不必在用户的流中发送数据（如果他们没有说话）。这应该意味着您的总带宽将是单个用户的110％。