我正在实现一个TURN服务器，我将在我的问题中使用TURN rfc5766术语。
有一部分我没有得到。 假设我们有一个连接到TURN服务器的客户端（A）和一个尚未连接到任何东西的对等端（B）。我们从另一个机制获得对等（B）的自反地址，并使用SIP或电子邮件将其传递给客户端（A）。无论情况如何。
接下来假设我们为客户端（A）创建了分配，权限和中继地址
它表示当客户端（A）向TURN服务器发送对等（B）的数据指示以进行中继时，它将对等（B）的服务器自反地址附加到该指示。然后，服务器从指示和对等体（B）的反射地址中提取udp并将其发送给对等体（B） 。 我没有得到的是服务器如何到达NAT后面的对等体（B）。只知道对等体（B）的服务器反身地址并没有正确地解决问题。 如果peer（B）从未与服务器通信，则peer（B）的NAT将永远不会在TURN服务器上创建从Peer（B）到客户端（A）的中继地址的映射。
如果服务器可以通过out ip：port映射到达对等体（B）的服务器自反地址，那么客户端（A）（因为客户端也知道对等体（B）的服务器自反地址）。它不需要转弯服务器。它只会使用STUN。
TURN服务器有什么意义呢？ 我错过了什么
有人可能会争辩说，Maybe peer（B）事先向同一服务器发出STUN绑定请求，这就是我们如何得到对等（B）服务器自反地址，并且该请求在对等体（B）上创建了NAT映射'的一面。那么它仅适用于使用端点独立映射和地址相关映射但不使用地址和端口相关映射的NAT。因为客户端（A）的中继地址不同于发送STUN绑定请求的Turn服务器的地址。 例如： 转服务器地址：121.121.121.121：8080 客户端中继地址：121.121.121.121：8081（在同一个服务器不同的端口。）。 由于晕眩绑定消息转到121.121.121.121:8080，因此对等（B）的NAT没有映射到121.121.121.121:8081。 基本上是桥梁坏了。
感谢。
答案 0 :(得分：0)
您的解释中的问题是对等方（B）在消息开始之前不会连接到TURN服务器。事实并非如此。
对于WebRTC客户端，需要配置STUN和TURN服务器地址。当客户端创建PeerConnections时，它们将在实际消息传递开始之前连接到TURN服务器。为了实现这一点，两个对等方都必须连接到TURN服务器，然后进行“打孔”操作。然后允许通过NAT的流量。
当通过TURN服务器中继流量时，客户端将不会彼此知道IP地址，只知道要与之通信的TURN端点。