文档介绍：使用网络分析系统解决一例VOIP通信受干扰的故障
环境概述
我处拥有一套内部VOIP系统,P混合构架,共覆盖六个分支节点。同时,使用第三方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包,其中的