WebRTC实战：Janus服务器公网部署中Coturn流转发的那些坑（附完整配置流程）

最近在帮一个客户部署一套线上视频会议系统，核心架构是Janus网关配合Coturn服务器做媒体流转发。本以为照着官方文档和几篇热门博客就能搞定，结果在实际配置和联调阶段，踩的坑一个接一个，从SDP Candidate的优先级打架，到端口绑定顺序的玄学问题，折腾了快一周才彻底跑通。我发现网上关于Janus和Coturn结合做纯流转发（而非简单的地址发现）的深度实践内容很少，大多停留在基础配置。今天我就把这些实战中遇到的典型问题、排查思路以及最终的完整配置流程梳理出来，希望能帮遇到类似困境的朋友少走弯路。

1. 理解核心问题：为什么需要Coturn做纯流转发？

很多朋友部署Janus到公网后，发现即使不配Coturn，位于不同NAT后的两个客户端也能通过Janus交换媒体流。这是因为Janus内置的libnice库具备STUN功能，当你在janus.jcfg中设置了nat_1_1_mapping为你服务器的公网IP后，Janus自身就扮演了一个“中继点”。发布者将流推送到公网Janus，订阅者再从Janus拉流，数据流路径是“客户端A -> Janus -> 客户端B”。

那么，什么情况下必须引入Coturn进行流转发呢？主要是在一些对称型NAT（Symmetric NAT） 或防火墙策略极为严格的网络环境中。在这种环境下，两个客户端可能无法直接通过Janus的公网地址建立P2P连接，即使Janus提供了双方的地址信息。此时，就需要一个TURN服务器作为强制中继，所有媒体数据都通过这个中继服务器转发。Coturn正是这样一个集STUN/TURN于一身的服务器。

这里有一个关键概念区分：

• STUN (Session Traversal Utilities for NAT)：主要用于地址发现。它帮助客户端发现自己位于NAT后的公网IP和端口（即Server Reflexive Candidate），但不转发数据。
• TURN (Traversal Using Relays around NAT)：在STUN基础上，提供了数据中继功能。当P2P连接失败时，客户端将所有音视频数据发送到TURN服务器，再由TURN服务器转发给对端。

在我们的场景中，目标很明确：强制让某一端（例如发布者客户端）的媒体流，不直接发送给Janus，而是先发送给Coturn，再由Coturn转发给Janus。这听起来简单，配置起来却暗藏玄机。

2. 基础环境搭建与Coturn配置详解

工欲善其事，必先利其器。我们先确保Janus和Coturn的基础安装与配置正确。

2.1 Janus服务器配置要点

假设你的Janus已经部署在公网服务器上（IP: YOUR_JANUS_PUBLIC_IP）。关键的配置在于janus.jcfg中关于NAT和ICE的部分。为了使用外部TURN服务器，你需要调整以下设置：

# 示例 janus.jcfg 相关片段
nat: {
    # 如果打算完全依赖Coturn转发，可以注释掉1:1映射，避免Janus生成自己的srflx candidate干扰优先级
    # nat_1_1_mapping = "YOUR_JANUS_PUBLIC_IP"
    stun_server = "stun.l.google.com"
    stun_port = 19302
    # 以下是启用TURN中继的关键配置
    turn_server = "YOUR_COTURN_PUBLIC_IP"
    turn_port = 19302
    turn_type = "udp"
    turn_user = "your_turn_username"
    turn_pwd = "your_turn_password"
    ice_enforce_list = "relay" # 这是一个重要选项，后面会详细讲
}

注意：ice_enforce_list这个参数非常关键。它用于指示Janus在ICE候选者列表中偏好或强制使用某种类型的候选者。设置为"relay"意味着Janus将优先（或在某些模式下强制）使用中继候选者。但请注意，这并不总是能完全阻止其他类型候选者的生成，需要结合代码层面调整，我们会在第3节深入。

2.2 Coturn服务器安装与深度配置

Coturn的安装可以通过包管理器完成，例如在Ubuntu上：

sudo apt update
sudo apt install coturn

安装后，核心是配置文件/etc/turnserver.conf或turnserver.conf。下面是一个针对媒体流转发场景优化过的配置示例，并附上了关键参数的注释：

# Coturn 主配置示例
listening-port=19302
listening-ip=0.0.0.0
# 外部公网IP，必须设置正确，否则中继地址会错
external-ip=YOUR_COTURN_PUBLIC_IP
# 中继端口范围，为动态分配的转发端口划定区间
min-port=20000
max-port=40000

# 身份验证相关，必须配置，否则任何客户端都能申请中继资源
user=your_turn_username:your_turn_password
realm=your.domain.com # 领域，可自定义

# 长期凭证机制，更安全，但WebRTC客户端通常使用短期凭证，这里我们先用静态密码演示
lt-cred-mech=false

# 重要：允许TURN中继功能（默认开启）
no-tcp-relay=false # 允许TCP中继
no-udp-relay=false # 允许UDP中继，我们主要用这个

# 日志相关，调试时建议开启详细日志
verbose
syslog

# TLS/DTLS证书配置（如果启用TURN over TLS/DTLS）
# cert=/path/to/cert.pem
# pkey=/path/to/key.pem

启动Coturn服务：

sudo systemctl start coturn
# 或直接使用命令行
turnserver -c /etc/turnserver.conf

使用netstat或ss命令检查19302端口是否正常监听TCP和UDP：

sudo ss -tulnp | grep 19302

你应该能看到类似下面的输出，表明服务在TCP和UDP上都已就绪：

udp   UNCONN 0      0              0.0.0.0:19302      0.0.0.0:*
tcp   LISTEN 0      10             0.0.0.0:19302      0.0.0.0:*

3. 第一个大坑：SDP Candidate优先级与ICE策略

环境搭好了，配置也写了，满心欢喜启动测试。结果用Wireshark一抓包，发现媒体流还是直接从客户端发到了Janus，Coturn像个旁观者一样。这就是我们遇到的第一个，也是最典型的一个坑：Candidate优先级问题。

3.1 问题根源分析

在WebRTC的ICE协商过程中，双方会交换SDP，其中包含一系列a=candidate行。每个candidate有类型（host, srflx, relay）和优先级值。ICE Agent会根据优先级尝试连接，优先级高的优先。

当Janus配置了nat_1_1_mapping或即使没配但能通过STUN发现自己公网IP时，它生成的SDP Answer中会包含三种candidate:

1. host candidate (类型 typ host): Janus服务器的内网IP。
2. server reflexive candidate (类型 typ srflx): Janus服务器的公网IP（通过STUN发现或直接映射）。
3. relay candidate (类型 typ relay): 从Coturn申请到的中继地址。

根据RFC 5245，srflx candidate的优先级通常高于relay candidate。因为直接连接（即使是经过NAT反射）的路径通常比通过中继服务器更短、延迟更低。因此，客户端会优先尝试连接Janus的公网IP（srflx），如果成功，就不会去用Coturn的中继地址。

3.2 解决方案：修改Janus源码

要让流量强制走Coturn，我们需要让Janus在SDP Answer中只提供relay candidate，或者至少确保relay candidate是唯一可用的选择。有几种思路：

1. 配置法：如前所述，在janus.jcfg中设置ice_enforce_list = "relay"。但根据我的测试和Janus社区的一些讨论，这个参数有时并不能完全阻止libnice生成srflx candidate，尤其是在Janus有公网IP的情况下。
2. 源码修改法（一劳永逸）：直接修改Janus的ICE处理代码，过滤掉非relay的candidate。这是最彻底的方法。

修改位置通常在 janus/ice.c 文件中的 janus_ice_candidates_to_sdp 函数附近。你需要找到组装candidate列表的代码段，添加过滤逻辑。以下是一个示例性的修改思路（请根据你的Janus版本具体定位）：

// 伪代码，展示修改逻辑
// 在遍历candidates并添加到SDP的循环中
for (GList *c = candidates; c; c = c->next) {
    NiceCandidate *candidate = (NiceCandidate *)c->data;
    // 只保留relay类型的candidate
    if (candidate->type != NICE_CANDIDATE_TYPE_RELAY) {
        // 跳过，不将此candidate加入SDP
        continue;
    }
    // ... 原有的将candidate信息格式化为SDP行的代码 ...
}

修改后，需要重新编译并安装Janus。这样，Janus发出的SDP Answer中将只包含从Coturn获取的中继地址。客户端别无选择，只能通过Coturn来连接Janus。

警告：修改源码有风险，请务必在测试环境先行验证，并备份原始文件。同时要意识到，这会使所有连接都强制经过TURN服务器，可能会增加带宽成本和延迟，请根据实际网络环境评估。

4. 第二个大坑：客户端与Coturn的端口绑定顺序

解决了Janus端的问题，你以为就结束了？太天真了。在客户端，你可能按照常规方式在PeerConnection的ICE配置中添加了Coturn服务器信息：

const pcConfig = {
  iceServers: [
    {
      urls: 'turn:YOUR_COTURN_PUBLIC_IP:19302?transport=udp',
      username: 'your_turn_username',
      credential: 'your_turn_password'
    }
  ]
};
const peerConnection = new RTCPeerConnection(pcConfig);

但抓包发现，客户端在向Coturn申请的中继端口（例如:24104）发送Binding Request时，收不到任何回复，导致打洞失败，连接无法建立。

4.1 抓包分析与问题定位

通过对比成功和失败的抓包日志，我发现了关键差异。在成功的案例中，客户端的ICE交互流程是这样的：

步骤	源地址:端口 -> 目标地址:端口	协议	操作	目的
1	客户端内网IP:随机端口 -> Coturn公网IP:19302	STUN	Binding Request	发现自身公网地址（MAPPED-ADDRESS）
2	客户端内网IP:随机端口 <- Coturn公网IP:19302	STUN	Binding Success Response	返回客户端公网地址
3	客户端内网IP:随机端口 -> Coturn公网IP:24104	STUN	Binding Request (带凭证)	向中继端口发起认证和打洞
4	客户端内网IP:随机端口 <- Coturn公网IP:24104	STUN	Binding Success Response	中继端口打洞成功

而在失败的案例中，缺少了步骤1和2，客户端直接向:24104端口发送了带凭证的Binding Request，但这个请求似乎被Coturn忽略或拒绝了。

4.2 原因与解决方案

这个问题的根源在于某些网络环境或Coturn/客户端ICE实现中，需要先对TURN服务器的“主端口”（默认19302）完成一次基本的STUN Binding交换，之后才能与动态分配的中继端口进行TURN协议交互。这可以看作是一种“握手”或“端口发现”的预备阶段。

解决方案就是确保客户端的ICE配置能触发这一过程。实际上，标准的WebRTC API在添加turn:服务器时，浏览器或WebRTC库（如libwebrtc）通常会正确处理这个流程。但如果你遇到问题，可以尝试：

1. 显式添加STUN服务器：在iceServers数组中，除了TURN服务器，也添加一个指向同一Coturn服务器的STUN配置。

   const pcConfig = {
     iceServers: [
       {
         urls: 'stun:YOUR_COTURN_PUBLIC_IP:19302'
       },
       {
         urls: 'turn:YOUR_COTURN_PUBLIC_IP:19302?transport=udp',
         username: 'your_turn_username',
         credential: 'your_turn_password'
       }
     ]
   };
   

   这明确告诉ICE Agent先对:19302端口做STUN发现。

2. 检查Coturn配置：确保Coturn配置中没有禁用STUN功能（no-stun参数默认为false，即开启）。同时检查防火墙是否同时放行了TCP和UDP的19302端口，以及min-port到max-port定义的UDP端口范围。

经过这样调整后，客户端的ICE协商流程就会恢复正常，顺利通过Coturn中继连接到Janus。

5. 完整配置流程与验证 checklist

结合以上所有坑和解决方案，我总结出一套完整的、可操作的配置与验证流程。

5.1 分步配置清单

1. Coturn服务器

   • [ ] 安装Coturn (apt install coturn 或编译安装)。
   • [ ] 编辑配置文件，重点设置listening-port, external-ip, min-port, max-port, user, realm。
   • [ ] 启动服务并验证19302端口监听状态。
   • [ ] 在服务器本地使用turnutils_uclient等工具测试TURN服务是否正常。

2. Janus服务器

   • [ ] 注释或删除janus.jcfg中的nat_1_1_mapping配置。
   • [ ] 正确配置turn_server, turn_port, turn_user, turn_pwd。
   • [ ] （可选但推荐）设置ice_enforce_list = "relay"。
   • [ ] （如果上述配置无效）修改ice.c源码，过滤非relay candidate，重新编译Janus。
   • [ ] 重启Janus服务。

3. WebRTC客户端

   • [ ] 在创建PeerConnection时，确保iceServers配置中包含正确的TURN服务器URL、用户名和密码。
   • [ ] 考虑显式添加STUN服务器配置（指向Coturn）。
   • [ ] 在代码中监听iceconnectionstatechange事件，检查连接状态是否最终变为connected。

5.2 抓包验证流程

理论配置千遍，不如抓包看一眼。使用Wireshark或tcpdump在客户端、Coturn服务器、Janus服务器三处同时抓包，是定位问题的终极武器。

1. 过滤条件：使用过滤表达式 stun || turn || rtp || rtcp 或 port 19302 or portrange 20000-40000。
2. 关键交互验证点：
   • 客户端 -> Coturn (19302): 应有STUN Binding请求/响应。
   • Janus -> Coturn (19302): 应有TURN Allocate请求（带认证）/响应，响应中应包含XOR-RELAYED-ADDRESS（如:24104）。
   • 客户端 -> Coturn (24104): 应有带凭证的STUN Binding请求/响应（打洞）。
   • 客户端 -> Coturn (24104): 随后应有RTP/RTCP媒体流数据包。
   • Coturn (19302) -> Janus: Coturn应将接收到的媒体流，从它的19302端口转发至Janus在Allocate请求中指定的端口。

如果抓包结果显示媒体流直接从客户端发往了Janus的公网IP，说明Candidate优先级问题没解决。如果客户端与Coturn的中继端口交互失败，则检查端口绑定顺序和认证问题。

整个调试过程虽然繁琐，但一旦打通，你对WebRTC的ICE、STUN、TURN协议的理解会上一个大台阶。这套基于Coturn的强制中继方案，在应对复杂企业网络、移动运营商网络下的WebRTC连通性问题时，提供了可靠的兜底保障。