私网拨打公网问题-STUN设置

    知识前提：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。

原文转自：http://www.ltesting.net