SIP和NAT穿越
我试图了解 NAT 和 SIP 的确切问题，并且看到了许多不同的解释。以下是我到目前为止收集到的内容：
1) SIP 用户代理既发起又接受呼叫，因此除非 NAT/防火墙配置为接受此端口上的传入流量，否则它无法工作 - 这是有道理的，但听起来更多的是防火墙和端口映射
2) SIP 消息在正文中包含 IP 地址（可以是私有的），需要 NAT 穿越 - 如果是这种情况
3) 这不是 SIP 的问题，而是 RTP 的问题，RTP 的参数包含在 SDP 中作为包含私有 IP 地址的 SIP 消息正文的一部分
4) 与 UDP 与 TCP 有关吗？
I'm trying to understand the exact problem with NAT and SIP and have seen many different explanations. Here's what I've gathered so far:
1) SIP User agent is both initiating and accepting calls, therefore unless the NAT/firewall is configured to accept incoming traffic on this port it cannot work - this makes sense but sounds more firewall and port mapping
2) SIP messages contain IP addresses (that can be private) in the body which requires NAT traversal - if this is the case
3) it's not a problem with SIP but with RTP, whose parameters that are included in the SDP as part of the SIP message body that include private IP addresses
4) something to do with UDP vs. TCP?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当使用 SIP 完成呼叫时，呼叫端点不知道呼叫必须到达的端点，即端点的 IP。
它只知道SIP服务器的IP地址。
因此，INVITE 会发送到 SIP 服务器，并且 SIP 服务器“知道”在何处/如何到达被叫端点。
这个想法是，SIP 消息包含 SDP 数据，其中包含所需的信息，以便最终电话能够建立会话并且用户能够开始通话。
这些数据包括IP、端口、编解码器和其他参数。
因此，如果其中一部电话位于 NAT 之后，该电话将报告为其 IP，例如 IP_X，这是其私有 IP，而另一个端点无法访问该 IP；此时公共 IP 未知。
When a call is done with SIP the calling endpoing does not know the endpoint the call must reach i.e. the endpoint's IP.
It only knows the IP address of the SIP server.
So the INVITE goes to the SIP server and SIP servers "knows" where/how to reach the called endpoints.
The idea is that the SIP messages contain SDP data that contain the information needed so that eventually the phones will be able to set up a session and users will be able to start talking.
These data include IP, port, codecs and other parameters.
So if one of the phones is behind NAT the phone will report as its IP e.g. IP_X which is its private IP and the other endpoint can not reach that IP; the public IP is unknown at that point.
你所有的假设都是正确的。
在 SIP 中，您可以将其分为 2 个主要问题：信令和媒体。
信令在 TCP 或 UDP 上的 SIP 中运行，并且可以从两个方向打开连接，因为用户代理可以拨打或接受呼叫。
媒体通过 RTP（和 RTCP）运行，通常通过 UDP 完成（除非您试图实现 NAT 穿越），然后它可能通过 TCP）。这里的端口和地址是动态分配的，需要双向运行并在多个会话（=多个套接字和连接）上运行。
为了实现 NAT 穿越，您通常会使用多种技术：STUN、TURN、ICE、HTTP 隧道甚至 SBC。
SIP 的 NAT 穿越需要专用于该作业的服务器（通常不是 SIP 服务器）的外部支持。
All of your assumptions are correct.
In SIP, you can split it into 2 main problems: signaling and media.
The signaling runs in SIP over either TCP or UDP, and the connection can open from both directions, as calls can be dialed or accepted by user agents.
The media runs over RTP (and RTCP), which is usually done over UDP (unless you're trying to achieve NAT traversal), and then it might go over TCP). The ports and addresses here are allocated dynamically, need to go both ways and run on multiple sessions (=multiple sockets and connections).
To achieve NAT traversal, you will usually use multiple techniques: STUN, TURN, ICE, HTTP tunneling and even an SBC.
NAT traversal for SIP requires external support from servers - usually not the SIP server - that are dedicated for the job.
我稍微不同意 Tsahi Levent-Levi 的回答。
问题是您放入 Via、Contact、From/To 标头、SDP 等中的 IP 地址必须是全局可路由的。如果您位于 NAT 后面，则显然需要输入您的外部 IP 地址。
实现 ICE、使用 STUN 等可以让您自动执行此操作，但您始终可以手动解决该程序。
特别是，通过检查计算机的路由表，您可以判断您正在呼叫的计算机是否位于 NAT 后面（通过了解工作计算机位于此 VPN NAT 后面，并且本地计算机位于该子网上，其他一切都通过路由器的 NAT 运行）。有了这些信息，您可能会以某种方式找到 NAT 的远端/外部地址（STUN 自动给出此信息，但您的互联网路由器可能有一个静态地址，或者您可以联系能够返回您的地址的 HTTP 服务器）外部地址，或...）。获得远端/外部地址后，您可以将地址放在必要的位置 - 您的 Contact 标头、SDP c= 标头等。
I'll disagree mildly with Tsahi Levent-Levi's answer.
The problem is that the IP address you put in your Via, Contact, From/To headers, SDP, etc., must be globally routable. If you're behind a NAT you'll obviously need to put in your external IP address.
Implementing ICE, using STUN, etc., allows you to do this automatically, but you can always solve the program manually.
In particular, by inspecting your machine's routing table you can tell whether or not the machine you're calling is behind a NAT or not (by virtue of knowing that work machines are behind this VPN NAT here, and local machines are on this subnet, and everything else runs through your router's NAT). With that information you may find out a NAT's far-side/external address somehow (STUN gives this automatically, but your internet router may have a static address, or you could contact an HTTP server capable of returning your external address, or ...). Once you have that far-side/external address, you can put the address where necessary - your Contact header, SDP c= headers, and the like.
Eyeball Networks 有一份白皮书清楚地解释了 NAT 和 NAT。 voip 的防火墙穿越问题和STUN、TURN、ICE 解决方案。 http://www.eyeball.com/voip-solutions/stun-turn-ice.htm
There is a whitepaper by Eyeball Networks that clearly explains the NAT & firewall traversal problem for voip and the STUN, TURN, ICE solution. There are also a couple of great diagrams on how SIP P2P and SIP TURN calls are achieved at http://www.eyeball.com/voip-solutions/stun-turn-ice.htm