什么时候需要 TURN？对称 NAT 和端口限制 NAT
when is TURN necessary? symmetric NAT and port-restricted NAT
我遇到了这个："The only time when TURN is necessary is when one of the peers is behind a symmetric NAT and the other peer is behind either a symmetric NAT or port-restricted NAT."那么对称 NAT 后面的对等点如何连接后面的另一个对等点，例如全锥 NAT？
比如对称NAT后面的peer是A，full cone NAT后面的peer是B，调用过程应该是这样的：
- A 从 STUN（无 TURN）服务器发现其本地地址和端口（Al:Alp）被映射到服务器自反值（As:Asp），这应该只在 A 和 STUN 服务器之间有意义，因为它是对称 NAT。 （对吗？）
- 同理，B发现它的Bl:Blp被映射到Bs:Bsp。
- A 发出 SIP INVITE，INVITE 中的 SDP 部分告诉使用 As:Asp 接收媒体。
- B回复200 OK表示使用Bs:Bsp接收媒体
- 媒体启动，A 发送给 B。请注意，由于它是对称 NAT，NAT 将创建一个新端口，因此数据包将是 As:Asp' -> Bs:Bsp（其中 Asp' 是新创建的端口）。 B 端的 NAT 将传递数据包（因为它是完整的锥形）并且 B 将获得 A 的媒体。
- 从 SIP/SDP，B 知道使用 As:Asp 向 A 发送媒体，这将在 A 的对称 NAT 中被丢弃，对吗？
请检查我是否理解正确的步骤。那么 A（在对称 NAT 后面）如何与 B（在完整锥形或地址限制锥形后面）通信？
谢谢。
如您所知，在您的用例中仅在双方使用 STUN 将以单向音频通话结束：A 能够向 B 发送音频。
你知道，如果 A 可以发送给 B，那么反向路径也是可用的。
B站情况如下：
* RTP packets are sent to As:Asp
* RTP packets are received from As:Asp'
* B can read the origin of RTP packets with "recvfrom"
B 的一个非常简单的方法是比较来自 SDP 的 IP:PORT 和来自 RTP 数据包的 IP:PORT'。除了它引入的安全问题之外，如果 B 切换到 IP:PORT'，A 将从 B 接收 RTP，并且您最终会进入双向音频通话：许多软件都使用这种技术，通常称为“对称 RTP” ".
同样，这不是一种合规的方式。它可能会引入 ALG 问题，并且仅当发送方使用相同的套接字进行发送和接收时才有效。 （99% 的用例）。这也被认为是一个安全问题，因为“中间人”可能会向您发送 RTP 数据包，而您将开始与他交谈...
rfc6336 定义的 ICE 正在提供解决方案。 STUN 连通性检查将通过 RTP 路径进行交换。 B 将收到本应来自 As:Asp 但来自 As:Asp' 的 STUN 连接检查：STUN 连接检查被验证为来自 A。这个新的“候选人”（参见 ICE 的定义）应该是添加到可能的候选者列表（新的 RTP 路径）并将再次被 A 和 B validated/authenticated。理论上，它是通过信令协议再次交换的。 （实际上，即使不再次交换新候选人，它也能工作...）
因此，使用ICE，RTP路径As:Asp' <-> Bs:Bsp将被学习、认证、确认和使用！
我遇到了这个："The only time when TURN is necessary is when one of the peers is behind a symmetric NAT and the other peer is behind either a symmetric NAT or port-restricted NAT."那么对称 NAT 后面的对等点如何连接后面的另一个对等点，例如全锥 NAT？
比如对称NAT后面的peer是A，full cone NAT后面的peer是B，调用过程应该是这样的：
- A 从 STUN（无 TURN）服务器发现其本地地址和端口（Al:Alp）被映射到服务器自反值（As:Asp），这应该只在 A 和 STUN 服务器之间有意义，因为它是对称 NAT。 （对吗？）
- 同理，B发现它的Bl:Blp被映射到Bs:Bsp。
- A 发出 SIP INVITE，INVITE 中的 SDP 部分告诉使用 As:Asp 接收媒体。
- B回复200 OK表示使用Bs:Bsp接收媒体
- 媒体启动，A 发送给 B。请注意，由于它是对称 NAT，NAT 将创建一个新端口，因此数据包将是 As:Asp' -> Bs:Bsp（其中 Asp' 是新创建的端口）。 B 端的 NAT 将传递数据包（因为它是完整的锥形）并且 B 将获得 A 的媒体。
- 从 SIP/SDP，B 知道使用 As:Asp 向 A 发送媒体，这将在 A 的对称 NAT 中被丢弃，对吗？
请检查我是否理解正确的步骤。那么 A（在对称 NAT 后面）如何与 B（在完整锥形或地址限制锥形后面）通信？
谢谢。
如您所知，在您的用例中仅在双方使用 STUN 将以单向音频通话结束：A 能够向 B 发送音频。
你知道，如果 A 可以发送给 B，那么反向路径也是可用的。
B站情况如下：
* RTP packets are sent to As:Asp
* RTP packets are received from As:Asp'
* B can read the origin of RTP packets with "recvfrom"
B 的一个非常简单的方法是比较来自 SDP 的 IP:PORT 和来自 RTP 数据包的 IP:PORT'。除了它引入的安全问题之外，如果 B 切换到 IP:PORT'，A 将从 B 接收 RTP，并且您最终会进入双向音频通话：许多软件都使用这种技术，通常称为“对称 RTP” ".
同样，这不是一种合规的方式。它可能会引入 ALG 问题，并且仅当发送方使用相同的套接字进行发送和接收时才有效。 （99% 的用例）。这也被认为是一个安全问题，因为“中间人”可能会向您发送 RTP 数据包，而您将开始与他交谈...
rfc6336 定义的 ICE 正在提供解决方案。 STUN 连通性检查将通过 RTP 路径进行交换。 B 将收到本应来自 As:Asp 但来自 As:Asp' 的 STUN 连接检查：STUN 连接检查被验证为来自 A。这个新的“候选人”（参见 ICE 的定义）应该是添加到可能的候选者列表（新的 RTP 路径）并将再次被 A 和 B validated/authenticated。理论上，它是通过信令协议再次交换的。 （实际上，即使不再次交换新候选人，它也能工作...）
因此，使用ICE，RTP路径As:Asp' <-> Bs:Bsp将被学习、认证、确认和使用！