我们正在实施基于 SIP 的解决方案，并已将设置配置为与 RTPProxy 一起使用。现在，我们正在通过 RTPProxy 路由所有内容，因为我们在依赖 ICE 的媒体传输方面遇到了一些问题。如果我们没记错的话，如果两个客户端位于对称 NAT 之后，则需要中央中继服务器来中继两个客户端之间的流数据。在实践中，这是否占所有消费者用户的很大比例？如果我们实施适当的路由以在不需要时跳过中继服务器，我们将节省多少带宽。我们缺少更好的解决方案吗？
问问题
3451 次
4 回答
10
In falling order of usefulness:
- There is a direct connection between the two endpoints in both directions. You just connect and you are essentially done.
- There is a direct connection between the two endpoints in one direction. In that case you just connect via the right direction by trying both.
- Both parties are behind NATs of some kind.
- Luckily, UPnP works in one end, you can then upgrade the connection to the above scheme
- UPnP doesn't work, but STUN does. Use it to punch a hole in the NAT. There are a couple of different protocols but the general trick is to negotiate via a middle man that coordinates the NAT-piercing.
- You fall back to let another node on the network act as a relaying proxy.
If you implement the full list above, then you have to give up very few connections and don't have to spend much time on bandwidth utilization at proxies. The BitTorrent protocol, of which I am somewhat familiar, usually stops at UPnP, but provides a built-in test to test for connectivity through the NAT.
One really wonders why IPv6 did not get implemented earlier - this is a waste of programmers time.
于 2011-01-26T22:13:28.210 回答
6
真实世界的 NAT 类型调查（虽然不是一个庞大的数据集）：
于 2013-04-24T15:01:50.127 回答
5
根据 Google 的说法，大约 8% 的流量需要中继：http ://code.google.com/apis/talk/libjingle/important_concepts.html
于 2011-03-19T13:56:21.887 回答
3
很大一部分（如果不是大多数）家庭用户使用 NAT，因为那些 xDSL/cable 路由器使用 NAT 来提供对本地网络的网络访问。
理论上你可以使用UPnP在路由器上打开端口并设置转发规则，从而透明地通过NAT。不幸的是（或幸运的是，取决于你是谁）许多用户在他们的路由器上理所当然地禁用了 UPnP，并且可能不喜欢手动添加转发规则。
您可以做的（以及 Skype 所做的 AFAIK）是让一些具有清晰网络路径和足够带宽的用户充当中继节点。除了路由和 QoS 问题之外，您至少必须找到某种方法来确保来自任何人（包括中继节点的所有者）的任何中继数据的隐私。此外，除了技术问题外，使用这种方法可能还需要解决法律问题。
于 2011-01-26T22:01:07.107 回答