WebRTC仅音频流中断问题：防火墙能否单独阻断WebRTC音频？

• 检查媒体轨道与发送端状态
  不要仅依赖iceConnectionState，监听音频轨道的onended、onmute事件，确认MediaStreamTrack.enabled未被意外置为false。调用peerConnection.getStats()获取发送端统计数据，重点关注音频的bytesSent、packetsLost、sendBitrate：如果音频的bytesSent长期停滞，说明数据输出中断，结合视频正常的情况，问题大概率出在音频轨道或RTP发送链路，而非整体ICE连接。

• 对比音视频传输路径差异
  WebRTC可能为音频和视频分配不同的ICE候选对，即使整体ICE状态为connected，音频的候选对可能已失效但未触发状态变更。通过getStats()查看音视频各自的候选对信息，确认两者是否一致（比如是否都使用TURN中继，还是音频用直连、视频用TURN）。若音频用主机候选（直连），部分企业NAT或流量清洗规则可能因音频流带宽低（如Opus默认码率）触发超时切断，而高带宽视频流不受影响。

• 分析TURN服务器日志与配置
  查看TURN服务器对应会话的日志，确认是否存在音频流中继停止的情况。部分TURN服务器配置了空闲超时，若音频流发送间隔超过阈值（如默认60秒），可能被判定为空闲而关闭端口，视频流因帧率高不会触发。可检查TURN超时配置，或强制音频发送端发送静音帧（避免静音时停止发包）。

• 排查终端安全软件拦截
  即使防火墙已开例外，企业终端安全软件（如EDR、DLP）可能误判音频RTP包特征（端口范围、负载类型）并阻断，而视频流因包大小或频率躲过拦截。可让客户临时关闭终端安全软件测试，或抓包确认客户端是否真的发出了音频数据包。

• 主动触发ICE重协商
  调用peerConnection.restartIce()主动触发ICE重协商，验证是否能恢复音频流。部分场景下，ICE候选对已失效（如NAT端口映射超时但未发送STUN绑定请求），但WebRTC未检测到，主动重启ICE可获取新候选对。同时检查ICE定期检查（Keepalive）的间隔，若间隔超过NAT超时时间，可能导致端口被回收。

• 验证音频编码与设备状态
  确认客户端音频编码格式（如Opus、G.711）与对等端兼容，部分设备或网络环境可能对特定编码包有特殊处理。另外检查音频输入设备是否在异常发生时出现状态变化（如设备断开、系统权限变更），系统层面的设备驱动问题可能导致音频轨道停止发数据。

• 双向抓包定位流量断点
  异常发生时，在客户端和TURN服务器同时抓包，对比音视频流量：

  • 客户端是否发出音频RTP包？
  • TURN服务器是否收到并转发音频包？
  • 对等端是否收到音频包？
    以此定位问题出在本地、TURN服务器还是中间网络。

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