什么时候需要转？对称 NAT 和端口限制 NAT

Question

我遇到了这样的情况：“唯一需要 TURN 的情况是其中一个对等方位于对称 NAT 之后，而另一个对等方位于对称 NAT 或端口限制 NAT 之后。”那么对称 NAT 后面的对等方如何连接后面的另一个，例如全锥 NAT？

例如，假设对称 NAT 后面的对等方是 A，而全锥 NAT 后面的另一个是 B。调用过程应该是这样的：

1. A 从 STUN（无 TURN）服务器发现其本地地址和端口 (Al:Alp) 映射到服务器反身值 (As:Asp)，这应该只在 A 和 STUN 服务器之间有意义，因为它是对称 NAT。 （对吗？）
2. 同样，B 发现其 Bl:Blp 映射到 Bs:Bsp。
3. A 发出 SIP INVITE，INVITE 中的 SDP 部分告诉使用 As:Asp 接收媒体。
4. B 回复 200 OK 表示使用 Bs:Bsp 接收媒体。
5. 媒体启动，A 发送给 B。注意，由于是对称 NAT，NAT 会创建一个新端口，因此数据包将是 As:Asp' -> Bs:Bsp（其中 Asp' 是新创建的端口）。 B 侧的 NAT 将通过数据包（因为它是完整的锥形），B 将获得 A 的媒体。
6. 通过 SIP/SDP，B 知道使用 As:Asp 向 A 发送媒体，这将在 A 的对称 NAT 中被丢弃，对吗？

请检查我是否正确理解了这些步骤。那么 A（在对称 NAT 之后）如何与 B（在完整锥体或地址限制锥体之后）通信？

谢谢。

Answer 1

正如您所了解的，在您的用例中仅在双方都使用 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，并且您最终会进行 2 路音频通话：这种技术被许多软件使用，通常被称为“对称 RTP”。

同样，这不是一种合规方式。它可能会引入 ALG 问题，并且仅在发送方使用相同的套接字进行发送和接收时才有效。 （99% 的用例）。这也被认为是一个安全问题，因为“中间人”可能会向您发送 RTP 数据包，而您将开始与他交谈...

rfc6336 定义的 ICE 提供了一个解决方案。 STUN 连接检查将通过 RTP 路径进行交换。 B 将收到一个应该来自 As:Asp 但来自 As:Asp' 的 STUN 连接检查：STUN 连接检查被验证为来自 A。这个新的“候选人”（参见 ICE 的定义）应该添加到列表中可能的候选者（新的 RTP 路径），并将再次由 A 和 B 验证/验证。理论上，它是通过信令协议再次交换的。 （实际上，即使不再次交换新的候选人，它也可以工作......）

因此，使用 ICE，RTP 路径 As:Asp' Bs:Bsp 将被学习、验证、确认和使用！