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