ZLMediaKit中WebRTC推流超时问题的排查与解决

问题背景

在使用ZLMediaKit进行WebRTC推流时，用户遇到了"接受rtp/rtcp/datachannel超时"的错误提示。这个问题表现为OBS Studio通过WebRTC协议向ZLMediaKit服务器推流时连接失败，而同样的配置在使用SRS流媒体服务器时却能正常工作。

问题现象

用户在使用OBS Studio的obs-webrtc插件进行推流时，出现以下具体现象：

1. 推流地址配置为：http://192.168.0.101/index/api/whip?app=live&stream=test
2. OBS Studio显示错误提示："Failed to connect to server"
3. ZLMediaKit日志显示："Receiving rtp/rtcp/datachannel timed out"
4. 虽然HTTP API请求能正常响应SDP交换，但后续的媒体数据传输失败

技术分析

WebRTC协议建立连接的过程分为几个关键阶段：

1. 信令交换：通过HTTP协议完成SDP(会话描述协议)交换
2. ICE协商：交换网络候选地址(NAT穿透)
3. DTLS握手：建立安全传输通道
4. 媒体传输：通过UDP传输RTP/RTCP媒体数据

从日志分析可以看出，问题发生在第四阶段。虽然SDP交换成功完成，但后续的媒体数据传输未能建立连接。

根本原因

经过深入排查，发现问题出在Docker容器的端口映射配置上：

1. 用户只映射了TCP端口(8000/tcp)，而没有映射UDP端口
2. WebRTC在完成SDP交换后，实际媒体数据传输使用的是UDP协议
3. 由于UDP端口未映射，导致媒体数据包无法到达容器内的ZLMediaKit服务
4. 超时后，ZLMediaKit主动关闭了连接

解决方案

解决此问题需要确保所有必要的端口都正确映射：

1. 完整的端口映射：不仅需要映射TCP端口，还必须映射UDP端口
2. Docker命令修正：使用-p 8000:8000/udp参数显式映射UDP端口
3. 防火墙检查：确保主机防火墙允许UDP流量通过
4. 网络配置验证：确认NAT设备或云服务商的安全组规则没有阻止UDP流量

配置示例

正确的Docker运行命令应包含TCP和UDP端口映射：

docker run --rm -it \
  -p 1935:1935 \
  -p 1985:1985 \
  -p 8080:8080 \
  -p 1990:1990 \
  -p 8088:8088 \
  -p 8000:8000/tcp \
  -p 8000:8000/udp \
  --env CANDIDATE=192.168.0.101 \
  registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5

经验总结

1. 协议理解：WebRTC同时使用TCP(信令)和UDP(媒体)协议，部署时需考虑两者
2. 容器网络：Docker默认只映射TCP端口，使用UDP协议的服务需要显式声明
3. 排错方法：通过分析日志确定失败阶段，逐步缩小问题范围
4. 测试验证：可以使用工具如Wireshark抓包验证UDP数据包是否到达服务器

扩展知识

WebRTC的NAT穿透通常依赖以下机制：

1. STUN服务器：获取公网IP和端口映射
2. TURN服务器：在直接连接失败时中继流量
3. ICE框架：协调上述机制，选择最佳连接路径

在ZLMediaKit中，通过配置externIP参数可以指定服务器的外部IP地址，帮助客户端建立正确的连接路径。对于复杂的网络环境，可能还需要配置STUN/TURN服务器以确保可靠的连接建立。

通过本次问题的解决，我们不仅修复了具体的配置错误，更重要的是加深了对WebRTC协议栈和容器网络的理解，为今后处理类似问题积累了宝贵经验。