Docker-Jitsi-Meet 视频会议服务中音视频无法接收的排查与解决

问题背景

在使用Docker-Jitsi-Meet搭建视频会议服务时，用户遇到了一个典型的多方通信问题：当两个或更多人加入会议时，彼此无法获取对方的音频和视频流。虽然屏幕共享功能能够触发窗口显示，但共享内容区域呈现黑屏状态。

环境配置分析

用户部署环境采用了阿里云ECS实例，配置为2核CPU、2GB内存，运行Ubuntu 20.04系统。服务使用stable-9753版本的Docker-Jitsi-Meet镜像，通过自定义SSL证书配置HTTPS访问。

关键配置参数包括：

• 显式指定了JVB_ADVERTISE_IPS参数，包含内网(172.21.74.32)和公网(47.99.47.78)IP
• 禁用了XMPP WebSocket(ENABLE_XMPP_WEBSOCKET=0)
• 使用8443非标准HTTPS端口
• 防火墙和云安全组已正确放行相关端口(8000,8443,10000/udp等)

问题现象深度分析

从技术角度看，这种音视频传输失败通常涉及以下几个层面的问题：

1. 网络连通性问题：UDP端口10000未正确开放或NAT穿透失败
2. ICE协商失败：STUN/TURN服务器配置不当导致端到端连接建立失败
3. 浏览器策略限制：插件或安全设置阻止了WebRTC连接
4. 服务端配置错误：JVB(视频桥接服务)广告地址不正确

排查过程还原

用户首先检查了基础网络配置：

• 确认ufw防火墙处于inactive状态
• 验证10000/udp端口监听正常
• 云安全组规则已放行必要端口
• 通过ss命令确认Docker端口映射生效

日志分析显示：

• 服务组件(web,prosody,jicofo,jvb)均正常启动无报错
• 浏览器控制台出现关键错误："Unchecked runtime.lastError..."

根本原因定位

经过深入排查，发现问题源于浏览器端的WebRTC Leak Shield插件。该插件出于隐私保护目的，默认会阻止WebRTC相关功能，导致：

1. 媒体流传输被拦截
2. ICE候选地址收集不完整
3. 端到端连接无法建立
4. 虽然信令交互正常(能显示共享窗口)，但实际媒体数据被阻断

解决方案

禁用或移除WebRTC Leak Shield插件后，系统功能立即恢复正常。这提示我们在排查WebRTC相关问题时，需要特别注意：

1. 浏览器插件可能无声地干扰WebRTC功能
2. 隐私保护类插件与实时通信功能存在天然冲突
3. 问题可能仅表现在媒体流层面，而信令交互看似正常

最佳实践建议

基于此案例，建议在部署Docker-Jitsi-Meet时：

1. 浏览器环境检查清单：

   • 禁用所有可能影响WebRTC的插件
   • 确保浏览器支持并启用了WebRTC
   • 在无痕模式下测试以排除插件干扰

2. 服务端配置要点：

   • 正确配置JVB_ADVERTISE_IPS包含所有可能访问IP
   • 对于复杂网络环境，考虑配置TURN服务器
   • 监控jvb组件的ICE协商日志

3. 网络架构建议：

   • 确保UDP端口开放且未被QoS限制
   • 在NAT环境下配置适当的端口转发
   • 考虑启用STUN服务辅助NAT穿透

总结

这个案例展示了WebRTC应用中一个典型问题现象及其解决方法。它提醒我们，在音视频通信系统出现异常时，排查范围应该涵盖从服务端配置到客户端环境的完整链路。特别是浏览器插件这种容易被忽视的因素，往往成为问题的关键所在。通过系统化的排查方法，可以高效定位和解决这类音视频传输问题。