我们正在建立纯音频 WebRTC 通话。
通过仅更改一个变量，即我们一次建立的并发 WebRTC 调用的数量，我可以看到在批次中“最后”的调用上获取 RTP 音频的可靠失败。 因此，调用 1-3 都获得音频正常，但第四个调用无法协商音频。我们在服务器上有 DTX 检测，并且能够终止这些不产生任何 RTP 音频的呼叫，但我们无法解释原因。
由于一致性的性质，感觉我们已经达到了 Chromium 的定义极限。因此，每个连接的呼叫都必须执行多个 STUN 请求（找到每个网络适配器一个？）。通过连接 >3 个调用，我们可以最大限度地提高并发 STUN 请求。
我们可以在 webrtc-internals 中看到这些未正确协商的调用，它们没有显示粗体的本地/远程候选对。并且没有统计图，因为没有 RTP。
除了挂断重试，我们还能做什么呢？有没有办法通过 RTCPeerConnection 接口或 Chrome://flags 中的限制我们可以调整？
我们的愿望是同时至少有 8 个并发 webrtc 调用，总共最多 50-60 个调用。
尝试过的事情：
Chromium 中并发 WebRTC 调用的问题可能与 ICE/STUN/TURN 处理的内部限制有关。根据您的发现，超过三个并发呼叫似乎会因缺少 RTP 流而导致音频协商失败。这可能是由于资源限制或 Chromium 对多个 ICE 候选者的处理造成的。
解决这个问题： 1. 使用TURN服务器而不是仅仅依赖STUN。 TURN 服务器中继媒体流量，可以更可靠地处理 NAT 穿越。测试托管解决方案（例如 Google 的 TURN 服务）和自定义设置以确定最适合的方案。 2. 调整您的WebRTC配置： • 增加iceCandidatePoolSize 以优化候选分配。 • 设置iceTransportPolicy 以优先考虑中继候选并减少对本地候选的依赖。 3. 通过 chrome://flags 探索 Chromium 设置。启用实验性 QUIC 协议支持等标志可能会改善高并发下的连接处理。虽然没有记录的 ICE/STUN 限制，但调整这些设置会有所帮助。 4. 减少活动网络适配器以最大限度地减少 STUN 请求。 Chromium 可能会为每个适配器生成多个请求，因此禁用未使用的适配器（例如，如果在以太网上，则禁用 Wi-Fi）可能会有所帮助。 5. 增加iceCheckingTimeout 以留出更多时间进行连接协商。使用 chrome://webrtc-internals 调试失败的调用并验证 ICE 候选对的形成。
如果调用 8 次以上问题仍然存在，则可能是 Chromium 特定的限制或错误。要扩展到 50-60 个呼叫，请考虑使用 SFU（选择性转发单元）或 MCU（多点控制单元）来集中管理连接，因为这可以减轻单个客户端的协商和媒体处理负担。
如果这些步骤都不起作用，请考虑向 Chromium 开发人员提交一份详细的错误报告，其中包含来自 webrtc-internals 的可重现步骤和日志。