Chrome使用a=group:BUNDLE 0 1仍生成多组ICE候选是否为Bug？
2026-7-19
这不是Chrome的Bug，是符合WebRTC规范的正常行为
原因解释：
- BUNDLE的核心作用是在ICE连通性检查完成后，将多个媒体流复用在同一个传输通道，但它不会改变ICE候选的收集逻辑。
- Chrome（以及其他遵循WebRTC标准的浏览器）默认会为每个
m-line（即每个媒体/应用流）独立收集ICE候选，即使启用了BUNDLE。这是因为在候选收集阶段，浏览器无法提前确定最终会复用哪个端口，所以先为每个流分配独立的端口并收集对应候选，后续再通过BUNDLE机制将它们合并到同一个传输端口上，多余的候选会被自动忽略。
对你提供的候选数据的说明：
你看到的mid-0和mid-1对应不同端口的候选（比如本地端口54078 vs 54079，中继端口60609 vs 43434）是完全正常的——这是Chrome为每个m-line初始分配独立端口的结果。当BUNDLE生效后，浏览器会选择其中一个端口作为复用端口，所有媒体流都会通过这个端口传输，另一个端口的候选不会被实际使用。
额外说明：
如果你希望让多个m-line共享同一组候选，可以在创建RTCPeerConnection时，将RtcConfiguration的bundlePolicy设置为"max-bundle"，不过Chrome的默认行为已经能自动完成BUNDLE复用，这个配置通常不需要手动修改，也不会影响实际的连通性。
内容的提问来源于stack exchange，提问作者progquester
相关产品推荐
相关产品推荐
