未调用getUserMedia时HTTP下WebRTC单向流能否在Chrome/Firefox播放

结论：在不调用getUserMedia、getDisplayMedia这类访问用户本地采集设备高权限接口的纯单向WebRTC拉流场景下，HTTP环境本身不会阻止Chrome、Firefox正常播放传入的视频流，你遇到的仅Safari可用的异常和HTTP协议无直接关系。

• 关于WebRTC的HTTPS限制误区
  网上常说的「WebRTC必须运行在HTTPS环境」的规则，约束范围仅限需要申请用户本地权限的接口：包括调用摄像头/麦克风的getUserMedia、采集屏幕内容的getDisplayMedia，以及部分需要安全上下文的WebRTC扩展能力（比如端到端加密流、插入自定义处理帧等）。纯接收远端推送的音视频流、不访问本地任何敏感资源的场景，从来不在HTTP拦截范围内。如果是协议层面的全局限制，你测试时Mac端Safari也会直接拦截功能，不会出现单浏览器正常运行的情况。
• 跨浏览器播放异常的常见排查方向
  • 优先排查ICE连通性问题：Chrome、Firefox和Safari的ICE候选收集规则、UDP/TCP中继优先级、IPv6地址支持策略存在默认差异，很多测试环境没有正确配置STUN/TURN服务，或者信令交互阶段漏传了对应浏览器生成的ICE候选，就会出现部分浏览器能成功建联、部分浏览器连不通的问题，和当前页面是HTTP还是HTTPS没有关联。
  • 检查SDP协商的编码兼容性：如果推流端使用的音视频编码（比如特殊Profile的H.264、未开启对应浏览器支持的AV1/VP9编码）没有在SDP协商阶段正确声明，或者你在拉流端意外调用了需要安全上下文的WebRTC API，就会导致Chrome、Firefox无法正常解码播放流。
  • 注意官方测试页的特殊白名单：你提到的官方WebRTC测试站点能在全浏览器HTTP环境运行，是因为这类域名被加入了各大浏览器的内置安全上下文白名单，属于特殊豁免，不代表普通自建HTTP服务能直接复用这个规则。
• 实践建议
  哪怕HTTP环境可以满足当前纯拉流的需求，生产环境还是建议直接部署HTTPS。目前免费SSL证书的申请、部署成本极低，后续如果要新增互动、连麦类功能也不需要重构架构，还能规避后续浏览器安全策略收紧导致的功能失效风险。

内容的提问来源于stack exchange，提问作者Robert Driller