WebRTC聊天应用创建第二个PeerConnection时getUserMedia报错及多对等通信咨询

一、navigator.mediaDevices.getUserMedia 非SSL环境报错的解决方案 #

这个问题是现代浏览器的安全限制导致的——除了localhost（本地开发环境），浏览器要求必须通过HTTPS协议才能访问摄像头、麦克风这类敏感媒体设备，因为getUserMedia属于高权限API，非安全环境下调用会被直接拦截。

给你几个实用的解决办法：

• 本地开发用localhost：直接在http://localhost:xxx下测试，浏览器默认信任localhost的非HTTPS请求，不会拦截媒体设备调用。
• 开发环境配置自签SSL证书：用mkcert这类工具生成本地信任的自签证书，配置到你的服务器（比如Nginx、Node.js服务）上，这样开发环境就能用HTTPS访问了，步骤也很简单，生成证书后在服务里指定证书文件即可。
• 临时放宽Chrome的安全限制（仅开发用）：在Chrome地址栏输入chrome://flags/#unsafely-treat-insecure-origin-as-secure，启用这个选项，然后添加你的开发域名（比如http://your-dev-domain.com），重启浏览器后就能在非SSL环境下调用媒体设备了。注意：这个方法只能用于开发调试，生产环境绝对不能用，必须部署正规的SSL证书。

二、peer1与任意其他节点实现双向通信的可行性 #

完全可以实现！WebRTC本身支持单个Peer和多个其他Peer建立独立的连接，而且不会影响已存在的连接（比如peer1和peer2的视频通话不会因为新增peer1-peer3的连接而中断）。

常见的实现方案有两种：

• Mesh架构（点对点直连）：让peer1和每个需要通信的节点（peer3、peer4等）分别创建独立的RTCPeerConnection实例，每个连接单独处理信令交换、媒体流协商。这种方式适合节点数量不多的场景（比如10个以内），优点是不需要额外的中转服务器，缺点是每个节点需要维护多个连接，带宽和性能消耗会随节点数增加而上升。
• SFU架构（选择性转发单元）：如果未来节点数量较多，推荐用SFU服务器做中转。peer1只需要把媒体流发送到SFU，SFU再把流转发给其他需要和peer1通信的节点（peer3、peer4等）。这种方式下每个节点只需要和SFU建立一个连接，扩展性更好，而且能更好地处理网络差异（比如不同节点的带宽不同，SFU可以调整流的质量）。

无论用哪种方案，核心都是：每个新的通信连接都是独立的RTCPeerConnection实例，不会和已有的连接互相干扰，所以你可以在保持peer1-peer2连接的同时，让peer1和其他任意节点建立新的双向通信。

内容的提问来源于stack exchange，提问作者shivang patel