知识前提:STUN 代表UDP数据包简单地穿过NAT(Simple Traversal of UDP over NAT)。这是一个协议,当一个IP电话机在NAT后面时,IP电话机可以使用这个协议检测到NAT的存在,并判断NAT的类型。一个IP电话机如果支持 STUN协议,它就可以发送一系列的STUN查询,到公共的因特网上的STUN服务器,这样就可以得到NAT上映射到话机的公网IP地址和端口。IP电话机就可以智能地修改SIP/SDP消息中的私有IP地址。这样SIP信令和RTP多媒体数据就可以成功地穿过NAT,而不需要修改NAT的任何配置。
STUN代表了对大多数NAT的解决方法,但是不适合于对称的NAT。也就是说,绝大多数的SOHO路由器都是非对称的NAT,在这种情况下,使用STUN是成功的。但是STUN协议不能穿过对称的NAT。如果你的路由器是对称的NAT,则不要使用STUN。
问题:公网终端正常,NAT后的终端无法看到和听到公网终端图像与声音。
解决方法之一是使用STUN技术:
http://bgp.potaroo.net/ietf/rfc-pdf/rfc3489.pdf
简单来说,STUN解决的过程如下:
1、将STUN Client放在NAT后的终端中。
2、该终端在发送OLC之前调用STUN Client,去连接位于公网的任一台STUN Server.
3、STUN Server与STUN Client进行STUN Messgae交互(STUN Server将对应的RTP/RTCP经NAT转换后的地址告之STUN Client)。
4、该终端在打开本地逻辑通道时,使用STUN Client已经发送过的地址作为RTP/RTCP地址。并且在填写OLC时将STUN Client得到的NAT转换后的地址填写到OLC报文中。比如:STUN Client使用192.168.1.4:40000与192.168.1.4:40001 与STUN Server通讯;得到的经NAT转换后的地址为:221.12.27.14:2000与221.12.27.14:2039;那么终端在打开本地的RTP/RTCP就指定为40000与40001,同时OLC中地址替换为221.12.27.14:2000与221.12.27.14:2039。
5、这样公网的终端将会把数据发到221.12.27.14:2000与221.12.27.14:2039上,NAT会送到192.168.1.4:40000与192.168.1.4:40001上。
在这里,提及了4种NAT类型,上面使用STUN的结果会有不同:
● 如果STUN Server和被叫不是同一主机,那么只有Full Cone类型的NAT才能成功。
● 如果STUN Server和被叫是同一主机(也就是被叫终端安装STUN Server),但STUN Server使用的端口与本地OLC的端口不同,那么Restricted Cone NAT类型的也能成功。
● 如果STUN Server和被叫是同一主机,而且STUN Server使用的端口与本地OLC的端口相同,那么都能成功。
OpenH323 在其class H323EndPoint/class H323_RTP_UDP/class RTP_UDP中已经加入了STUN Client支持,你只需要调用H323EndPoint ::SetSTUNServer(…),就可以完成Client的功能。其STUN Client的代码在PWLIB中:http://cvs.sourceforge.net/viewcvs.py/openh323/pwlib/src/ptclib/pstun.cxx
虽然OpenH323没有提供STUN Server的支持,但是找到一个成熟的STUN Server/Client并添加到OpenH323中并不是一件难事:http://sourceforge.net/projects/stun/ 是不错的选择。
将http://sourceforge.net/projects/stun/的代码放入PWLIB中编译,并相应的修改OpenH323,以支持STUN Server。
文章来源于领测软件测试网 https://www.ltesting.net/