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