Question

我遇到了这个问题：＆＃34;唯一需要TURN的时候是其中一个对等体在对称NAT后面而另一个对等体在对称NAT或端口限制NAT之后。＆＃34;那么对称NAT后面的对等体怎么能连接另一个后面的对象，例如全锥形NAT？

例如，让对称NAT后面的对等体为A，而完全锥形NAT后面的对等体为B.调用过程应该是这样的：

从STUN（无TURN）服务器发现其本地地址和端口（Al：Alp）被映射到服务器自反值（As：Asp），这应该只在A和STUN服务器之间有意义，因为它＆＃39;对称NAT。（右？）
同样，B发现它的Bl：Blp被映射到Bs：Bsp。
A发送INVITE中的SIP INVITE和SDP部分告诉使用As：Asp接收媒体。
B回答200 OK，使用Bs：Bsp接收媒体。
媒体启动，A发送给B.注意，由于它是对称NAT，因此NAT会创建一个新端口，因此数据包将为As：Asp＆＃39; - ＆GT; Bs：Bsp（其中Asp＆＃39;是新创建的端口）。 B方面的NAT将通过数据包（因为它是完整的锥形）而B将获得A的媒体。
从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和IP：PORT＆＃39;来自RTP数据包。除了它引入的安全问题之外，如果B切换到IP：PORT＆＃39;，A将从B接收RTP并且您最终进行双向音频呼叫：此技术被许多软件使用并且经常被称为＆＃34 ;对称RTP＆＃34;。

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

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

因此，使用ICE，RTP路径 As：Asp＆＃39; ＆LT; - ＆GT; Bs：Bsp 将被学习，认证，确认和使用！

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

1 个答案: