要连接stun server 端口该如何映射啊

[hui zhang]

nat 下好些问题。

如果换做云平台是不是就没这些端口问题了。

[Bojie Li]

什么问题？

根据 RFC 5389，STUN server 只要知道客户端的 IP 地址和端口号就行，它会把客户端发来的请求的 IP 和端口号作为包的内容返回给用户，NAT 后的客户端就能知道它的公网 IP 和端口号了。如果你是在 freeshell 上部署，请注意 STUN client 需要连接 ssh.freeshell.ustc.edu.cn 的 public endpoint（在控制面板上配置的 40000-59999 端口），同时注意 TCP/UDP 的不同。昨晚我调整了端口映射方案，使得 freeshell 能够看到用户的真实 IP 和端口号，之前都变成了 202.141.160.99。

云平台这个概念太泛了，你想说的是独立 IP 地址吧。我曾见过某国内云服务提供商声称“有独立IP的是真云，没有独立IP的是假云”，这样说来 Azure 就是假云了，因为 Azure 的虚拟机都是虚拟网络的 IP（如 192.168.x），需要在 Web 控制面板里显式添加 TCP/UDP 端口映射才能从 Internet 访问，而且没有一段连续端口映射（相当于 iptables dports）的功能。Azure 上有数以千计的企业用户和数以百万计的虚拟机，应该不会运行不了 ICE 吧。

On May 10, 2014, at 13:23, hui zhang <fastf...@gmail.com> wrote:

nat 下好些问题。

如果换做云平台是不是就没这些端口问题了。

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hui zhang]

之前说的这些问题我都解决了， 还有个问题 一直不知道 怎么解决

  webrtc media server  在freeshell   NAT内， web client 在另外一个内网，

两个都配了google stun server                stun:stun.l.google.com  

offer  &  answer candidates 

貌似也是正常的

candidate 都返回了  各自公网的ip 和端口

但是媒体通道就是打不通。  

  由于不清楚 webrtc 内部实现，  今天折腾了这个好久。

我对 ice 全套方案 只懂点皮毛，  记得stun不是所有通道都能打通的

这种是不是就是要turn server了。

 

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/qilQkdQyeEU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

[Bojie Li]

哦，你用的是 Google STUN server 啊，我以为你是在 STUN server 部署中遇到问题了。

ICE 我也没有部署过，只知道原理。两个 web media client 之间的网络拓扑结构是什么样的？可以首先尝试局域网内的两个客户端通信，如果这都不工作，说明是配置问题。然后再在双方在不同 NAT 后面的环境中测试，能不能穿透 NAT 就听天由命了。

所谓的穿透 NAT，或称 UDP 打洞，是基于这样一个观察：大多数 NAT 实现在选取公共 IP 上的源端口时并非随机，对相同的内部 IP 和内部端口组合，不论目的 IP 和端口是什么，所选取的公共 IP 上的源端口很有可能是相同的。

在 RFC 5245 中，欲发起通信的两个客户端会从自己的网络配置获取自己的私有 IP 和端口，从 STUN server 尝试获取自己的公共 IP 和端口，并把这些信息通过中转服务器（如 web application）告诉对方。两个客户端分别首先尝试直接连接对方的私有 IP 和端口，如果不成功再尝试连接对方的公共 IP 和端口。每个客户端连接的时候要始终使用相同的源 IP 和源端口组合。

如果双方可以直连，则直连成功。如果双方只有一方在 NAT 后，在 NAT 后的直连成功，在公网的使用对方公共 IP 连接也成功。如果双方都是在符合上述观察的 NAT 后，则直连都不成功，使用对方公共 IP 连接至少有一个会成功，这就建立了 UDP 连接。为什么至少有一个会成功呢？假设 A 首先发起连接，会在 A 的 NAT 表中记录下 A、B 的公共 IP 和端口（所谓五元组），但这个包到达 B 的 NAT 会被丢掉。B 接下来发起连接时，根据假设，会在 B 的 NAT 表内记录下 B、A 的公共 IP 和端口（五元组），这个包到达 A 的 NAT 时匹配上五元组，发送给 A。A 此后的回复到达 B 的 NAT 时也匹配上五元组，发送给 B。也就是只有第一个包被牺牲了。当然，如果 A 和 B 几乎同时发起公共 IP 连接尝试，则包到达对方前对方的 NAT 中已经有相应五元组，则双方的连接尝试都会成功。

[Bojie Li]

为避免误解，补充一下，两个客户端的私有 IP 直连、公共 IP NAT 穿透的 4 个尝试，只要有一个连接成功就行，因此对每个客户端来说，直连和公共 IP NAT 穿透是同时开始尝试的，哪个先收到对方的响应就用哪个。

[hui zhang]

多谢你的帮助

昨天调试了一下   都到 建立srtp了   应该是 信令 通了，   但是 rtp 没有建立成功。

我今天再看看怎么回事。