转弯请求是否应该包括眩晕的候选人？答案

【问题标题】：Should a turn request include candidates for stun?转弯请求是否应该包括眩晕的候选人？
【发布时间】：2019-02-06 02:57:43
【问题描述】：

这里有两个非常相似的问题，但都没有得到回答：

rfc5766-turn-server as TURN and STUN for webrtc application 问题 1. 说“使用 rfc5766-turn-server 足以充当 TURN 和 STUN 服务器，还是我还需要运行 stun 服务器”。

missing relay candidates from TURN server 谈到缺少接力候选人，我只提出turn 请求时看到的效果。

我们将coturn 配置为turns 和use-auth-secret，并使用https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ 进行测试。

当我在没有密码的情况下发出 stun 请求 stun:hostname:5349 时，我看到了 srflx 候选者（我的外部 IP）。
当我发出转向请求 turns:hostname:5349[username:password] 时，我看到 relay 候选者（TURN 服务器的公共地址）。

这看起来不错，但我需要向同一个服务器发出 2 个请求吗？ turn 不应该包含stun 并给我srflx 和relay 候选人吗？

我可以将coturn 配置为在一个请求中返回两者吗？
还是客户端必须同时提出这两个请求？是这样，所有浏览器在使用 WebRTC 时都会正确执行此操作吗？

【问题讨论】：

标签： webrtc stun turn coturn

【解决方案1】：

如果您在客户端中配置了 TURN/UDP，则无需配置与 STUN 服务器相同的服务器。

TURN over UDP 将自动返回一个 srflx 候选者，您应该能够在涓涓冰测试页面上看到它。如果您查看在 Wireshark 中交换的数据包，您会看到两者 * STUN 绑定请求和绑定响应包含服务器在 xor-mapped-address 字段中看到的公共 ip 以及 * 一个 STUN (TURN) 分配请求，其响应还包含一个异或映射地址

TURN over TLS 或 TURN over TCP 不会这样做，因为这不适用于 udp 打孔。

【讨论】：