sip - 什么时候需要TURN？对称 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 数据包，而您将开始与他交谈...

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

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