VOIP部署时，最严重的问题就是遇到无法呼叫（SIP信令不通）、媒体单通或完全不通，而这其中最常见的原因也就是：

n 局域网（私网环境）

n 防火墙策略

n 地区网络政策（VOIP封杀）

——SIP，RTP，软电话、IP电话机，IPPBX，加密，防封杀，私网穿越

V1.0 By meineson 2011/12

VOIP部署时，最严重的问题就是遇到无法呼叫（SIP信令不通）、媒体单通或完全不通，而这其中最常见的原因也就是：

n 局域网（私网环境）

n 防火墙策略

n 地区网络政策（VOIP封杀）

其中关于私网穿越，目前主流的SIP服务器大多已经能支持来自私网地址的SIP终端的注册和呼叫请求：这些REGISTER、INVITE消息经过路由器NAT动态端口转换后，到达SIP服务器时，SIP服务器能根据原始的SIP URI携带的IP、端口与实际收到SIP消息的IP报文的来源IP和端口进行比对，并能正确地将应答SIP报文返回到路由器的NAT外部动态端口，由路由器返回给这些SIP终端；

但某些极端情况下，SIP服务器无法做这些工作（例如只提供公网或同级局域网内终端服务的服务器），只能根据SIP 报文URI携带的地址进行消息返回，这就导致了SIP信令都无法畅通的一种异常，解决该问题的方法是，让SIP终端发出消息时，就已经修改SIP报文中的URI的IP和端口为路由器NAT外部地址、端口，原理就是，让SIP终端知道自己所在局域网的网关对外地址，这项工作可以自行设计实现（有多种方式可以让局域网内的设备知道网关的对外地址），当然，也可以交给标准的协议实现，普遍采用的是STUN；

SIP信令互通，是进一步解决媒体通话的前提，所以在继续分析RTP媒体能遇到的问题之前，还得继续查看下其它导致SIP信令不顺畅通讯的异常；

排除掉上述SIP服务器不支持私网内终端服务的情况，另一项可能导致SIP信令不通的原因应该就是ISP的封杀，而这又分为完全封杀和干扰封杀；

n 完全封杀

完全封杀就是针对SIP消息特征进行屏蔽，例如封闭SIP消息的常见知名端口5060，或直接对报文内容检查是否SIP消息；

n 干扰封杀

干扰封杀顾名思义，就是干扰正常的SIP呼叫流程，这一般是由于完全封杀成本过高，例如ISP在随机时间段内监测到某个地址、端口出现SIP INVITE消息，提取出消息中的关键字段，故意组装一个4xx或5xx错误甚至BYE消息返回给SIP终端，阻断SIP会话的正常发起；

要解决这些问题，目前大多数厂家采用的最简单的方法就是加密SIP报文，一般各家均有自己定义的加密方式，标准不一，唯一较广泛使用的比较标准的，也就是将UDP的SIP报文进行RC4加密，而RFC定义的TLS加密方式，由于依赖TCP方式的SIP报文传输，也存在着SIP服务器需要维护大量TCP连接的开销问题，实际使用的并不太多；

另外一个不得不提的极端情况下，某些企业局域网或某些国家地区的网络，只开放了极少的知名端口例如HTTP 80端口，甚至直接封锁UDP协议，这属于最后要谈论的终极解决方案，下文再述；

SIP信令畅通后，只能保证主、被叫双方能建立联系，而媒体的通讯则还需要依赖RTP的畅通，RTP的连接信息携带在SIP消息的SDP中，包括媒体监听地址、端口及编码等附加信息；

RTP同样会遇到私网问题、封杀问题，首先是私网问题，NAT分为Full Cone、Restricted Cone、Port Restricted Cone和Symmetric四种类型，根据NAT的工作特性（可参见其它关于NAT的资料库），前三种NAT类型，可以同样借助于上述的帮助SIP穿越私网的STUN标准技术来解决，即SIP终端发出INVITE或对INVITE进行200应答时，修改SDP携带的媒体地址为NAT外部地址，端口为借助STUN在NAT外部动态分配端口；

但即使只有一种NAT类型不能穿透，这种工作模式也是不能接受的，在商用环境下是不允许的，所以即使SIP终端支持了STUN，作为VOIP运营的SIP服务器端，一般还是需要针对这种特殊NAT环境进行额外的代理工作，即RTP Proxy，当然，SIP服务器可以自动判断何种情况下需要启用RTP Proxy，以节省服务器资源；

RTP封杀则比SIP封杀难以解决的多，虽然RTP也可以采用SRTP或产品厂家自定义的加密算法进行躲避，但由于RTP包的特征是短时间内有规律的频繁的小UDP包的传输，很容易被ISP侦测而直接封闭UDP端口，一旦遇到这种极端网络环境，大多数SIP终端均不能正常工作，也找不到简单可行的解决办法；

这里就涉及到了VOIP通讯的最极端网络情况下的解决方案，这种方案可以解决象上述封锁了全部UDP传输，对RTP进行包特征过滤等场景，其核心原理就是，让SIP和RTP通讯不再以它们原本的面目出现在网络上，而是进行二次封装，例如目前市面上开始出现的支持VPN的SIP终端；

由于VPN是一种隧道技术，且广泛应用于跨国跨地区的企业安全专网通讯，ISP一般不会直接进行信令级别的封锁，而只是做IP或端口的禁止；

可以直接在SIP终端和SIP服务器的前端放置VPN网关设备，或设备内建虚拟网卡驱动级别的VPN支持，屏蔽了对SIP或RTP协议级别的开发工作，目前较常用的有支持PPTP，L2TP或OpenVPN等标准VPN协议，或者也有厂家自定义私有的简化的VPN协议，这也就涉及我们接下来要提到的，如果连标准的VPN也封锁的终极网络环境，如何处理？

一般提供Internet服务的网络环境，即使限制再严厉，HTTP还是放行的，否则就不能称之为提供Internet接入服务的了，基于这个前提，我们这里提出基于HTTP的隧道技术；

标准的HTTP隧道技术我们已经接触过了，许多软件提供有HTTP代理，它使用了HTTP协议的标准的CONNECT方法，建立与HTTP代理服务器的二进制原始socket通讯连接，可以通过代理服务器间接与目标IP建立通讯，但它有个限制就是只支持TCP协议，标准的SIP可以通过它通讯，但RTP则无法通行，这里有两种解决方法：

n HTTP VPN Tunnel

即让标准的VPN通过HTTP代理通讯，使用的就是前面说的HTTP的Connect方法，基本不需要标准VPN作大的修改就可以支持；

n 私有协议HTTP Tunnel

由于标准的VPN毕竟不是为了VOIP通讯而设计的，可能对于RTP包的传输来说负担过重，容易造成性能问题，再从HTTP代理绕行，可能加剧了这个问题；

HTTP Tunnel是一个很轻量级的隧道，标准的CONNECT方式由于限制了TCP连接，所以可以采用私有协议把RTP二次封包后，同样通过TCP传输，但是需要在服务端有相应的解包处理，还原为原始的UDP RTP；

或者，不采用CONNECT，而是采用标准的HTTP的GET，POST这些标准方法，把SIP，RTP都打包为HTTP的载荷数据，使用标准HTTP协议进行传输，同样需要服务端有相应的解包处理，从HTTP载荷数据中还原出SIP，RTP数据；