网络分析系统解决VOIP通信受干扰的故障案例解决方案.docxVIP

使用网络分析系统解决一例VOIP通信受干扰的故障 环境概述 我处拥有一套内部VOIP系统，采用SIP与SCCP混合构架，共覆盖六个分支节点。同时，使用第三方VOIP运营商的服务进行落地呼叫。（硬件PSTN落地目前没有部署完成。） 我们原来使用To****提供的落地服务，因为它提供隧道接入，不会被封。（本地ISP封VOIP）但是其服务实在不稳定，有时连续几个小时（甚至一天）都无法使用。 因此，我们申请了ET***的服务。经测试，该运营商的服务较为稳定，延迟低，可以满足稳定的通话需求。虽然其提供了加密接入方式，但只能由其客户端软件使用，并不兼容第三方PBX。所以，我们仍然要通过标准的SIP协议进行注册。 在接下来的测试中，我们发现，落地呼的拆除建立都狠正常。但是，在IP电话上听对方的语音有很明显的爆音和背噪。此种情况在本地区一直存在，实为ISP对VOIP进行干扰。 故障分析 我们的PBX采用商业版3CX软件交换系统，此系统运行在Windows环境下，因此我们可以在PBX上同时运行科来网络分析系统。 首先，落地呼叫的建立和拆除没有异常。因此我们可以推测，ISP并没有屏蔽SIP协议，也没有干扰SIP信令。不过，稳妥起见，还是需要抓包确认一下。 （图1） 如图1所示，呼叫的建立和拆除信令完整，且没有受到干扰。这也证明了我们之前的推论。 其次，VOIP通信的语音数据由RTP包承载（RTP封装在UDP中）。如果ISP丢弃了RTP包，那么在IP电话中应该听不到任何声音，而不是听到爆音和背噪。这也就说明，ISP并没有丢弃正常的RTP流。 当然，话音失真还可能是由于另外一个原因——抖动（Jitter）。所谓抖动，是指两个数据包之间的时间间隔差异。通过科来Ping工具我们可以很好地观察这一点。通过两次Ping延迟的差异，我们可以粗略地观察抖动的情况。实际测试结果表明，平均抖动基本处于10ms左右，最大的也不过25ms，不足以影响VOIP的通话质量。 那么，只有一种可能——ISP向RTP流中增加了额外的RTP包，以干扰VOIP通信。 VOIP属于实时应用，要求数据能尽力快速传递，因此没有采取重传和防伪造机制。 （图2） 从图2中可以看到ISP发送的干扰RTP数据包。从广义上讲，这也是一种会话劫持。 我们之???经常提到，判定会话劫持攻击，有两个参考点：TTL；2、IPID。 对于一个路由稳定的网络，“进程间通信”的一方连续发送的IP报文中，这两个参数的值是有规律可循的。我们只要对比这两个参数的值，就能轻易地发现“不速之客”。 从图2中可以看到，VOIP运营商服务器发回的RTP包，其中的IPID是有序递增的。但是，其中夹杂着一些异常，而且相同的IPID。再检查一下这些异常数据包的TTL，也与服务器返回的TTL不符。很明显，这就是运营商发送的干扰RTP数据包。 再次，我们知道，RTP包不一定会按照发送的顺序抵达目的地。因此，它带有一个序列号，用于在目的进行重新排列。前文中我们也提到了，RTP属于实时应用，不会重传数据包。那么，在一个RTP流中，如果短时间（几秒钟）内出现了序列号相同的RTP包，那么一定存在网络故障或恶意攻击。 （图3） 从图3中可以很明显地看出，一些RTP包发生了“重传”的情况。（解码区为RTP序列号）红圈中的两个包，为ISP伪造。 这样我们就可以得出最终结论：ISP没有封锁或干扰SIP信令，也没有封禁RTP包，只是在RTP流中插入了用于干扰的RTP包，产生爆音和背噪，导致通话质量的下降。 解决方案 由于这些干扰RTP包具有明显的特征，因此我们可以很方便地???网络边界设备上进行识别和过滤，阻止其进入PBX。但是我处没有合适的防火墙设备，过滤是通过NDIS驱动在PBX上实现的，可以获得相同的效果。