`
javahigh1
  • 浏览: 1223444 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

SIP通过NAT的实例解析

 
阅读更多

下面对SIP协议产生NAT穿透问题,作一些解释;及提出解决的办法。
1、大致有4种类型的NAT。
a) Full Cone 完全圆锥体
b) restricted cone 受限制的圆锥体
c) port restricted 端口受限制的圆锥体
d) symmetric 对称的
其中a,b,c 也称作非对称的NAT。

2、SIP终端在NAT后面,其工作有可能出现问题。原因是SIP信令走的路径,和媒体流走的路径不一样。

3、Full Cone 完全圆锥体NAT
因特网上的任何PC,可以发送数据包到IP:port对;而NAT将这个IP:port对(公网上的)映射到内网的IP:port对(私有网络的)。

4、restricted cone 受限制的圆锥体NAT
NAT外面的PC,只有那些内网中已有PC与之联系过的PC,才能通过这个映射进来。例如,我通过内网的一台机器,IP 地址是10.1.1.1:123,与PC(a)联系,则PC(a)也可以通过这个NAT的映射,联系到我。而PC(b)则不行。
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a)
如果pc(b)也发送数据到202.70.65.78:10000,则不会有数据送到10.1.1.1:123。

补充说明:
如果我也联系过pc(b),则pc(b)也可以进来了。
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(b)
如果pc(b)也发送数据到202.70.65.78:10000,则数据送到10.1.1.1:123。

5、port restricted 端口受限制的圆锥体NAT
除了4的条件外,即不但要检测pc(a)的源IP地址,还要检测其端口是否与前面也一样。
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a)[213.123.324.34:8000]

这个NAT只会接收从IP地址 213.123.324.34 且端口为 8000来的数据,让进入到10.1.1.1:123。

6、对称的NAT 这是关系描述最简单的一个
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
这种NAT的IP:port对,对每个外部的程序,都是不同的。因而每一个外部的程序,都有自己的映射(NAT分配的IP:port对)。而前面的三种,多个外部程序,可能共用一个NAT的IP:port对。

7、RTP的问题
在RTP的消息正文内,有UA能够成功通信所需要的一些信息。这种消息正文,就叫做SDP消息。

问题在于,SIP终端(UA)可能对NAT一无所知。因而在SDP中包含的IP地址,通常使用内部的IP地址,也就是SIP终端知道的IP。这样,当通信的对方想与SIP终端通信时,就查看SDP消息中的IP地址,但是什么也没有得到,因为这里使用的是内部IP地址。

下面举个例子说明:

INVITE sip:040600@192.168.20.2:5060 SIP/2.0.
Record-Route: <sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on>.
Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0.
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
From: "Iqbal" <sip:040618@sip.dom.com>;tag=3a7ceb24a6ac50c4.
To: <sip:040600@sip.dom.com>.
Contact: <sip:040618@223.178.140.109:1024>.
Supported: replaces.
Call-ID: 7f2c327896a5b0e1@192.168.20.3.
CSeq: 8717 INVITE.
User-Agent: Grandstream HT487 1.0.5.18.
Max-Forwards: 16.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Content-Length: 343.
.
v=0.
o=040618 8000 1 IN IP4 192.168.20.3.
s=SIP Call.
c=IN IP4 192.168.20.3.
t=0 0.
m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

SIP消息的标题头,类似于邮件的标题头。从后往前看,从From行开始,看到第一个Via行,这是SIP终端自己认为的IP地址,例如192.168.20.3。但是SIP代理服务器是聪明的,它知道这个消息是从哪里发过来的,它添加了rport和接收到的标志:
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.

也就是说,SIP代理服务器,知道发消息的SIP终端的公网地址是223.178.140.109:1024。
这样,SIP代理服务器是可以与SIP终端通信的,因为它知道SIP终端的公网地址。

但是,可怜的老式的RTP被阻塞了,因为它的标题头如下:
v=0.
o=040618 8000 1 IN IP4 192.168.20.3.
s=SIP Call.
c=IN IP4 192.168.20.3.
t=0 0.
m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

SIP终端期望从端口 port m=38660 且IP地址IP c= 192.168.20.3来接收RTP数据,而这个192.168.20.3:38660,就是通信的对方试图发RTP数据的目的地址。

这就是SIP电话振铃总是能够听到,而接起来却没有声音的原因。

8 解决办法 告诉SIP终端,不要如此傻地工作,而要想办法知道NAT分配给自己的端口映射。

并将公网的IP地址:端口放到SDP消息中。这样,SIP终端就问NAT....。或者是问公网的某个服务器,NAT分配给自己的映射是什么。

9 问NAT。 这种办法就是使用UPnP协议,另外去参见UPnP的资料。

10 问公网上的某个服务器。 如STUN服务器。
SIP终端发送一个探测数据包,到公网上的服务器。公网上的服务器会发回数据包,会包含有关NAT的详细信息。有了这些信息,SIP终端就会知道它是否在NAT后面。这种探测方法,可以用于上面4种NAT,都有效。例如SIP终端从10.1.1.1:1000发送一个数据包,则SDP消息中包含的是m=1000 and c=10.1.1.1。但是,如果SIP终端先进行NAT探测,则会知道NAT会分配公网的IP:端口是212.134.123.23:12345。则 SIP终端直接在SDP消息写m=12345,c=212.134.123.23。

产生的问题 因为NAT的端口分配是动态的,因而有可能会改变。这样,在发送了NAT探测消息后,要很快地发送出SIP消息。而且,SIP终端发送数据的端口和接收数据的端口要是一样的。

注意受限制的圆锥体(包括端口受限制的圆锥体)NAT,它不让回来的消息进来,除非SIP终端先发了一个数据包给它。因而,SIP终端需要先发一个数据包给对方。这样以后对方来的数据,就可以进入NAT内部了(不过,不需要为这个操作担心,有办法的)。

上面的办法在对称的NAT后面,不能够工作。因为,对称的NAT,它在分配给SIP终端外部的IP:port时,每次都变化(不同的对方不一样)。也就是SIP终端在探测NAT时,得到的IP:port,与它后来发SIP消息时,分配的IP:port不一样。这样,对方来的语音数据就进不来,因为对方得不到正确的IP:port。

11、上面描述的过程,其实就是采用STUN协议时,解决问题的过程。就是SIP终端向STUN服务器发探测NAT的数据包。

12、对称的NAT 解决办法 就是在公网上放一个中转语音流的服务器。这个中转语音流的服务器有时就是一个Out Bound proxy。注意,这个中转语音流的服务器,可能会成为瓶颈。由于语音要经过中转语音流的服务器,所以路径增长了,音质会变差。所以,对称的NAT,要SIP能够工作,总之是个麻烦。

不过,目前大多数的NAT,都可以做“虚拟服务器的端口转发”,即将SIP工作需要的端口转发到SIP终端上去。如果在NAT设备上,做了“虚拟服务器的端口转发”,则NAT会保留SIP工作需要的端口,专用于SIP终端,这样SIP终端就相当于是在一个Full Cone完全圆锥体的NAT后面,SIP用STUN工作没有问题。SIP终端需要的端口数是这样确定的,一个端口用于SIP信令,比如5060。RTP端口的数量,取决于通话的路数。一路通话需要2个RTP端口。每增加一路通话,则需要多2个端口。
只支持一路通话的SIP话机,需要NAT映射3个端口。
前面三种的NAT,可统称为非对称的NAT。非对称的NAT,都可以用STUN协议穿过NAT。

将对称的NAT,通过端口转发的方式,变为完全圆锥体的NAT,是解决NAT问题的最好办法。首先应当用这种办法来解决。没有办法映射端口,再想其它的办法。当然,建议大家不要买那种不能够映射端口的宽带路由器,那样的路由器太差了。

分享到:
评论

相关推荐

    JAVA上百实例源码以及开源项目源代码

     Java生成密钥、保存密钥的实例源码,通过本源码可以了解到Java如何产生单钥加密的密钥(myKey)、产生双钥的密钥对(keyPair)、如何保存公钥的字节数组、保存私钥到文件privateKey.dat、如何用Java对象序列化保存私钥...

    JAVA上百实例源码以及开源项目

     Java生成密钥、保存密钥的实例源码,通过本源码可以了解到Java如何产生单钥加密的密钥(myKey)、产生双钥的密钥对(keyPair)、如何保存公钥的字节数组、保存私钥到文件privateKey.dat、如何用Java对象序列化保存私钥...

    java开源包3

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    P2P网络技术原理与C++开发案例 源代码和第五章电子书 Peercast(王浩聪注释版)

    5.4.1 P2P和SIP结合方案分析 120 5.4.2 基于Pastry设计P2P-SIP系统 122 5.5 本章总结 125 5.6 练习题 126 C++开发案例篇 第6章 P2P应用开发平台 129 6.1 Windows Peer-to-Peer Networking平台 129 ...

    rtpproxy:RTPproxy是RTP流的高性能软件代理,可以与Sippy B2BUA,Kamailio,OpenSIPS和SER一起使用

    OpenSIPS或Kamailio SIP代理软件中包含的rtpproxy模块允许使用在远程计算机上运行的多个RTPproxy实例,以实现容错和负载平衡目的。 通过使用中间件,可以使用高级大容量群集和负载平衡。 该软件还支持MOH /预记录...

    java开源包8

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包1

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包2

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包6

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包5

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包10

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包7

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包9

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包11

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包4

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    java开源包101

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

    Java资源包01

    JCarder 是一个用来查找多线程应用程序中一些潜在的死锁,通过对 Java 字节码的动态分析来完成死锁分析。 Java的Flash解析、生成器 jActionScript jActionScript 是一个使用了 JavaSWF2 的 Flash 解析器和生成器。...

Global site tag (gtag.js) - Google Analytics