Jitsi Meet在AWS ECS部署中的媒体流问题分析与解决方案

问题背景

在使用AWS ECS部署Jitsi Meet视频会议系统时，用户报告了一个典型的WebRTC媒体流问题：当两个参与者加入会议时音视频通话正常，但当第三个参与者加入后媒体流就中断了。这种症状表明系统在点对点(P2P)模式下工作正常，但在需要转发服务器(JVB)介入时出现了故障。

技术原理分析

WebRTC的媒体传输机制

1. 点对点模式：当只有两个参与者时，WebRTC会优先建立直接的点对点连接，媒体流直接在浏览器间传输，不经过服务器中转。

2. 转发服务器模式：当第三个参与者加入后，系统必须切换到使用Jitsi Videobridge(JVB)进行媒体流转发，这时需要UDP端口10000正常工作。

AWS架构差异

1. EC2直接部署：传统EC2实例通常配有弹性IP，UDP端口可以直接暴露，JVB服务能够正常接收媒体流。

2. ECS部署特点：ECS服务默认使用动态端口映射，容器网络经过NAT转换，且ALB(应用负载均衡器)不支持UDP协议，导致媒体流转发失败。

根本原因

问题的核心在于ECS部署环境中：

• ALB仅支持HTTP/HTTPS(TCP协议)
• 缺少对UDP端口10000的正确配置
• JVB服务无法被外部客户端直接访问
• 容器网络地址转换(NAT)导致媒体流路径中断

解决方案

方案一：使用网络负载均衡器(NLB)

1. NLB配置要点：

   • 创建TCP/UDP类型的监听器
   • 映射外部10000端口到容器10000端口
   • 设置正确的健康检查路径

2. 环境变量配置：

   • 设置JVB_ADVERTISE_IPS为NLB的IP地址
   • 确保PUBLIC_URL指向正确的访问端点

方案二：EC2部署模式调整

1. 赋予ECS节点公网IP：

   • 为ECS集群的EC2实例分配弹性IP
   • 在安全组中开放UDP 10000端口
   • 禁用动态端口映射，使用固定主机端口

2. 混合负载均衡：

   • 保留ALB处理Web流量(HTTP/HTTPS)
   • 单独为JVB配置直接EC2实例访问

最佳实践建议

1. 网络架构设计：

   • 对Web流量和媒体流采用分离的负载均衡策略
   • 考虑使用服务发现机制动态配置JVB地址

2. 安全考量：

   • 为媒体服务配置单独的安全组规则
   • 实施适当的网络访问控制策略

3. 监控与调试：

   • 部署网络流量监控工具
   • 检查ICE协商过程和STUN/TURN使用情况

总结

在AWS ECS上部署Jitsi Meet时，媒体流转发问题通常源于UDP通信的限制。通过理解WebRTC的媒体传输机制和AWS网络服务的特性，可以采用NLB或混合架构方案解决此问题。关键是要确保JVB服务能够被客户端直接访问，同时保持Web应用部分的高可用性。