WebRTC Xirsys TURN服务器401未授权：全网络无ICE候选生成问题

问题描述 #

基于WebRTC开发实时流媒体应用，使用Xirsys TURN服务器时，在企业Wi-Fi、家庭Wi-Fi、移动热点等全网络环境下均出现流媒体建立失败的问题，具体表现为：

• 无法建立视频/流连接
• 未生成任何ICE候选
• 控制台持续报错：ICE candidate error: 401 Unauthorized

补充背景：该配置此前在移动网络可正常工作，切换为动态获取ICE服务器并禁用缓存后出现问题。

已执行的测试 #

• 网络连通性：https://global.xirsys.net及TURN服务器（含turns:443）均可正常访问，排除防火墙拦截问题
• 后端ICE服务器获取：通过/api/ice-servers接口从后端获取Xirsys API返回的ICE服务器配置，所有条目均包含username和credential字段，且接口响应头已禁用缓存
• 对等连接代码：异步获取ICE服务器配置后再创建RTCPeerConnection，测试过将iceTransportPolicy设为all和relay两种模式
• 诊断输出：所有TURN服务器（UDP/TCP/443端口）均返回Error on turns:bn-turn2.xirsys.com:443?transport=tcp - code 401: Unauthorized错误，无中继候选生成

核心疑问 #

1. 为何刚获取的Xirsys TURN凭证仍返回401未授权？
2. 获取ICE服务器与创建RTCPeerConnection之间是否存在时序问题？
3. 异步处理或复用ICE配置是否会导致凭证失效？
4. 如何确保建立连接时TURN凭证始终有效？

问题解答 #

1. 刚获取的凭证仍返回401的可能原因 #

• 凭证字段被篡改：Xirsys返回的username通常包含时间戳（格式类似<用户名>:<过期时间戳>），如果后端转发时截断、修改了该字段，会直接触发认证失败。检查后端返回的username是否与Xirsys API返回的完全一致，包括时间戳部分。
• credential传递错误：Xirsys的credential可能是临时密码或HMAC签名，若前端对其做了转义、编码等额外处理，会导致服务器拒绝认证。确认前端传递给RTCPeerConnection的credential值与后端获取的完全一致，无格式变更。
• 后端API调用权限问题：后端调用Xirsys API时使用的密钥、域名等参数错误，导致返回的凭证本身无效。直接在后端测试调用Xirsys API，对比返回的凭证与前端拿到的是否一致，同时检查Xirsys控制台的配额、权限设置。

2. 获取ICE服务器与创建PeerConnection的时序问题 #

如果是严格遵循「获取配置完成后再创建RTCPeerConnection」的逻辑，通常不会有时序问题。但需注意：

• 避免在获取ICE配置的Promise未resolve时就初始化PeerConnection，确保配置完全加载后再传入构造函数。
• 若存在多次请求配置的逻辑，需确保最终传入PeerConnection的是最新的、有效的配置，而非旧的失效配置。

3. 异步处理或复用ICE配置是否会导致失效 #

• 异步处理本身不会导致失效：只要保证配置获取完成后再使用，异步逻辑是安全的。但如果异步流程中出现竞态（比如多次请求返回不同配置，最终用了旧的），会导致凭证失效。
• 复用ICE配置大概率会失效：Xirsys的凭证有有效期（通常几分钟到几十分钟），如果复用超过有效期的配置，必然触发401。即使禁用了接口缓存，若前端缓存了旧配置对象，也会导致问题。

4. 确保TURN凭证始终有效的方案 #

• 按需实时获取：每次创建新的RTCPeerConnection前，都调用后端接口获取最新的ICE配置，不复用旧配置。
• 校验有效期：解析username中的时间戳字段，在创建PeerConnection前检查是否已过期，若过期则重新获取。
• 后端透传完整配置：后端调用Xirsys API后，直接返回完整的ICE配置数组，不做任何字段修改或截断，避免人为引入错误。
• 添加重试机制：若遇到401错误，自动重新获取ICE配置并重建PeerConnection，排除临时网络波动导致的配置传递不全问题。

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