CN1937544A - Ip电话监听系统 - Google Patents

Abstract

本发明涉及一种IP电话监听系统，用于对IP通话进行监听，所述IP电话监听系统包括：数据采集装置，用于根据过滤规则采集数据包；数据分析装置，用于对由数据采集装置采集的数据进行TCP流重组；语音存储装置，用于根据数据分析装置的分析结果，解析出需要记录的RPT流地址信息，并且根据所述RPT流地址信息将需要记录的流中的RTP数据包存储为文件；以及音频转换装置，用于将语音存储装置存储的文件中的经过语音编码的数据进行解码，生成可使用播放器播放的文件。

Description

IP电话监听系统

技术领域

本发明涉及IP电话的监听过程，结合了监听过程、VoIP协议解析技术、语音还原技术和语音合路技术，属于网络信息安全技术领域。监听过程是对网络数据进行分析管理的基本技术，属于网络安全技术，通过该技术可以获得网络中监听者感兴趣的敏感数据。

背景技术

IP语音通信(IP Telephony)是新一代技术，通过语音和数据网络的融合，IP语音通信使所有类型的通信业务(包括音频、视频和数据以及无线和有线语音业务)都可以在一套IP(互联网协议)网络上传输。将监听过程与VoIP相关技术进行特殊结合，可以实现对VoIP语音信息的监听。

IP电话(VoIP)正得到日益广泛的应用。随着IP电话对公众利益影响的增大、业务可靠性的增强，对PSTN的替代程度的扩大，积极应对IP电话带来的普遍服务、紧急呼叫、公众安全等系列问题，实施对IP电话轻度管制政策将是正确之举。同时，因特网上的内容管制也逐渐成为相关管理部门关注的焦点，对IP网上传输的多媒体信息，如IP电话语音流信息也将被纳入管理之列。

对VoIP的监听，对管理部门来说是相关的管理，同时对VoIP的监听是否合法，也属于安全问题。目前，我国正处于VoIP的应用部署的高潮阶段，但对VoIP市场的管理和对VoIP的安全关注较少。目前国内出现了部分VoIP的监听解决方案如Waygong监听录音广播系统，主要是针对公路收费系统的，对专有的软电话终端进行监听。美国联邦政府将赞助George Mason大学研究员开发一款原型监听工具，据说可追踪因特网电话的交谈双方，主要是针对Skype VoIP电话的监听，该工具未试图破解加密谈话的内容，只是设法辨认通话双方的身份，而不是他们交谈的内容。

发明内容

本发明的目的在于提供对通过IP网进行的通话进行监控的技术。本系统采用了监听过程、VoIP协议解析技术、语音还原技术和语音和语音合路技术，在可接入条件下，对VoIP语音进行通话双方的身份识别和未加密通话内容的还原。为VoIP语音监听提供了一套有效的实现方案。本系统为软件产品，可配置在需进行VoIP语音监听的任何有接入权限的设备上。

本发明提供了一种IP电话监听系统，用于对IP通话进行监听，所述IP电话监听系统包括：数据采集装置，用于根据过滤规则采集数据包；数据分析装置，用于对由数据采集装置采集的数据进行TCP流重组；语音存储装置，用于根据数据分析装置的分析结果，解析出需要记录的RPT流地址信息，并且根据所述RPT流地址信息将需要记录的流中的RTP数据包存储为文件；以及音频转换装置，用于将语音存储装置存储的文件中的经过语音编码的数据进行解码，生成可使用播放器播放的文件。

本父母优选的数据处理装置，进行的是H.323协议的解析。如果需要进行信令协议为SIP协议的IP电话的监听，可以添加数据处理装置，进行SIP解析。因此，本发明的IP电话监听系统也可以适用于SIP解析。因此，根据本发明的IP电话监听系统可以扩展协议处理架构

对骨干网进行监听将面临高速率的问题。数据从光纤数据接口经过模块转化为实际的数据包，由于大多数光纤的速度为OC48(2.5G)或者OC192(10G)的接口，对于这样高速度的数据进行缓存然后分析按照目前SDRAM的速度来说是不可能实现的，同时网络VoIP数据的特点就是VoIP只占整个网络流量的很少一部分，而且在分析的过程中只需要分析协议的开始于结尾信息。本发明在数据处理服务器前可以包括一个硬件过滤系统，将整个网络流量的绝大多数过滤，达到硬件过滤的优点。

即使经过硬件过滤系统，软件系统要处理的数据量还是很大。本发明在处理经过硬件过滤系统之后的数据时，采用动态过滤技术。在设定较严格的初始过滤条件，大大减少了要处理的数据，但会导致需要处理的数据包被过滤掉。因此必须从符合初始过滤条件的数据包中获取需要处理信息的连接信息(如H.245的地址信息)，通过添加对这些连接的监听，来获取进一步关于通话的信息。这种动态过滤技术适合于任何嵌套连接建立的协议体系。在H.323中，Q931连接中会建立H.245的连接，Q931协议数据包中会包含H.245控制消息的地址，H.245协议数据包中又会包含媒体流的地址。

目前的VoIP监听系统都只获得通话双方的两个单向的语音流，监听者要分别听这两个单独的语音流来获取通话内容，这种做法无法及时关联通话双方的说话内容，这会导致监听者遗漏通话的关键信息。本发明的系统中可以采用合路技术，对通话语音流进行静音期补包处理，丢包补包处理，计算说话起始时间，使通话双方的内容同步，这样播放合路后的语音流，就好像在现场听两个人对话一样。

附图说明

图1示出了系统硬件结构组成图；

图2示出了根据本发明的系统结构图；

图3示出了TCP流重组的流程图；

图4示出了TPKT协议头；

图5示出了H.323协议的解析流程；

图6示出了VoIP系统的音频数据传输过程；

图7示出了语音还原过程的示意图；

图8示出了RTP序列号溢出的例子；

图9示出了VoIP监听系统的应用结构图。

具体实施方式

从硬件组成上来说，本发明的结构如图1所示：

由数据处理设备，语音记录设备，音频转换设备，数据库设备，Apache设备，大型存储设备和若干用户查询设备组成。数据处理设备和语音记录设备是双网卡主机，一个网卡接入被监听的网络，另一个网卡与系统其他主机通信。数据处理设备根据过滤规则(初始过滤规则为Q.931协议数据即TCP：1720端口)从被监听网络采集TCP数据，对TCP流进行重组，提取信令数据，解析信令数据(包括Q.931和H.245)，从中获取H.245逻辑控制信道地址，将它插入到过滤规则队列中，并提取有用信息如通话双方的电话号码和IP等，将其插入到数据库设备中，并通知语音记录设备进行相应的记录。语音记录设备接收并解析数据处理设备的通知，将每个通话的语音流以原始的RTP包文件的形式存储在大型存储设备中，在每个通话结束的时候通知音频转换设备进行相关通话的音频转换，将原始的RTP包文件转换后的统一的wav格式的语音文件存储在大型存储设备中。用户查询终端通过网页浏览器访问Apache服务器浏览网页的方式获取信息。

根据本发明的系统结构如图2所示。

本系统主要由数据采集、数据分析、音频转换、进程守护、用户查询以及相关支持数据库六部分组成。其中，进程守护、数据采集及数据分析子系统安装在数据处理设备上，进程守护、数据采集及语音记录子系统安装在语音记录设备上，进程守护和音频转换子系统安装在音频转换设备上。

各个部分完成的功能如下：

1)进程守护

进程守护提高整个VoIP监听系统工作的可靠性。当数据采集、数据分析或音频转换发生异常崩溃时，进程守护子系统负责把发生异常的系统重启。同时它还有另外一个辅助功能，监视报警策略数据库，及时发现报警策略是否有更新，通过共享内存进程通信的方式通知数据分析去更新报警策略。

2)数据采集

数据采集主要作用是根据过滤规则采集数据包，实现对TCP流的重组和对IP分片数据包的重组。数据包的过滤技术有硬件过滤技术和动态软件过滤技术。

硬件过滤技术主要是基于网络处理器的数据过滤技术，通过硬件处理，达到高速率的数据过滤。对骨干网进行监听面临着高速率的问题。数据从光纤数据接口经过转化成为实际的数据包，由于大多数光纤的速度为OC48(2.5G)或者OC192(10G)的接口，对于这样高速度的数据进行缓存然后分析，按照目前SDRAM的速度来说是不可能实现的；同时网络VoIP数据的特点就是VoIP只占整个网络流量的很少一部分，而且在分析的过程中只需要分析协议的开始和结尾信息。本发明在数据处理装置前加入了一个硬件过滤系统，将整个网络流量的绝大多数数举包过滤。

动态软件过滤技术的处理过程如下描述：存在一个初始的过滤规则，过滤规则根据用户需要与系统需要动态变化。在数据处理装置中，初始过滤规则为Q.931协议数据即TCP：1720端口，对Q.931协议数据进行解析，得到H.245逻辑控制信道地址，将它插入到过滤规则队列中，从而实现动态过滤。语音记录装置的初始过滤规则队列为空，在数据处理装置通知其进行语音记录时，则解析通知，提取其中的RTP地址信息，并添加该RTP地址到过滤规则队列中，语音记录装置只记录过滤规则队列中的RTP流。

3)数据分析

数据分析对由数据采集系统提交的数据进行TCP流重组，信令提取和协议分析，确认数据是否为VoIP数据，且从其中提取H.245逻辑通道地址，RTP媒体流地址，通话双方IP地址，通话双方的电话号码等有用信息，并利用提取到的地址信息修改过滤规则，一旦确认有通话在进行时，通知语音存储记录通话语音流。当被通知更新报警策略发生变化时，读取数据库内容，更新报警策略；当检测到符合报警策略的事件时，更新报警策略数据库，通知用户查询子系统。

4)语音存储

语音存储接收数据分析的消息，从中解析出需要记录的RTP流地址信息，插入到过滤规则队列中。每采集到一个UDP数据包，比较当前UDP包的端口和对应的IP地址与过滤规则队列中的RTP端口和对应的IP地址，若相同，则进行存储，将需要进行记录的流中的原始RTP数据包存为文件，用于音频转换的输入。

5)音频转换

音频转换接收解析语音存储的消息，获取已结束的通话的原始RTP包语音存储文件，对原始RTP包语音存储文件进行分析，对经过语音编码(如G.729和G.7231)的数据进行解码，将编码格式多样的语音流信息解码存储为统一的wav格式文件，以便于用户查询时可以使用统一的播放器播放。一个通话有两个RTP流，从主叫到被叫的流和从被叫到主叫的流。对这两个流的wav文件进行合路处理，播放合路后的语音流，可以达到现场听两个人对话的效果。

6)用户查询

用户查询是VoIP监听系统的用户接口，负责VoIP监听系统与用户的交互。用户从用户查询系统中输入报警策略(即当某个IP地址或电话号码被监听到时由数据分析发出警报)，更新报警策略数据库，通知进程守护。

本发明的工作原理和流程

首先描述本发明的工作原理

1)监听过程

监听过程是本发明采用的基本技术。数据包监听与网络接口设备操作有紧密联系，因此监听过程也因操作系统不同而不同。目前主流的监听过程分为Windows监听过程和Linux监听过程。根据本发明的数据处理装置在优选方式下运行在Linux操作系统下。

Linux下的TCP/IP协议栈实质为基于网络接口设备之上的协议软件。用户应用程序可以通过BSD套接字与Linux协议内核建立联系。BSD套接字基于套接字管理软件INET套接字层的支持。INET套接字管理着基于IP的TCP或UDP协议栈。IP层包含的协议软件需要处理数据报的报头信息，并且必须将传入的数据报发送到TCP或UDP两者中正确的一层处理。在IP层之下是Linux的网络接口层，主要包括网络接口设备的驱动程序及链路层协议软件。ARP协议提供地址解析功能，因此它处于IP层和网络设备层之间负责将IP地址翻译成网络接口设备的物理地址，在以太网中指的是48位的MAC地址。Linux利用套接字缓冲区(Sk-buff)在协议层和网络接口设备之间传送数据，从网络设备接收到的数据帧传递给Linux协议软件。Sk-buff包含了一些指针和长度信息，从而可让协议层以标准的函数或方法对应用程序的数据进行处理。每个Sk-buff均包含一个数据块、四个数据指针以及两个长度字段。利用四个数据指针，各协议层可操纵和管理套接字缓冲区的数据。

在本发明中，需要做的是网络接口层的数据处理。通过向网卡发送I/O控制命令将其设置为混杂模式用于监听，将网卡数据映射到内存中，先通过对网络数据帧结构分析，经过简单的过滤(如过滤非IP包，过滤广播包)之后，将数据缓存起来。

2)TCP流重组过程

TCP数据是字节流式的。因此，利用监听过程获得的TCP数据，只有通过TCP会话重组，才能成为应用程序可以识别的信息。TCP流重组的目的在于将每个TCP连接的两端所发送的数据进行恢复。

依照TCP/IP协议，网络嗅探捕获MAC真据MAC真结构得到IP包，再据IP包协义字段指示，判断是否具有TCP载荷。针对TCP首部的FLAG字段，判断TCP连接的建立，拆除，从而进行TCP连接记录的建立和删除。根据TCP协议字段的指示，判断是否具有TCP净荷，实现对流数据的存储。进行TCP连接记录的建立时，关键的元素是源IP地址、目的IP地址，源端口号，目的端口号。在TCP连接释放时，删除TCP连接记录，并回收TCP数据的存储空间。对长时间收不到结束指示的连接，由超时处理删除连接。

TCP流重组的工作流程图如图3所示。

TCP流重组主要由四个难题：如何确定每个连接，如何确定初始序列号，如何解决数据包乱序的问题，如何解决数据重传的问题。

每个TCP连接可以用一对IP：Port来表示，但IPv4中IP地址为32bit，端口为16bit，这样每个连接需要48*2＝96比特来表示，也就意味有可能有2^96个连接同时存在，也就需要更多的内存空间来存储每个连接的数据信息，而为每个连接存储信息时也需要更多时间来搜索定位连接所在的位置。事实上，网络中并没有这么多连接存在，可以通过哈希函数将IP：Port对映射到16bit的上，并通过单向链表的方式解决冲突问题，这种做法既节省了内存空间，同时也节省了搜索时间。哈希表中每个节点对应以下信息：源IP，源端口，目的IP，目的端口。哈希表的查找也基于这个四元组。

TCP协议执行的是面向连接的可靠传输，TCP协议头中有个SN(sequence number)字段可以用于解决丢包，重传，乱序的问题。每传送一个包含有效数据的TCP包，后续紧接着传送的一个TCP数据包Sequence Number会作相应的修改，如果前一个TCP包的长度为N字节，则这个包的Sequence Number为前一个包的Sequence Number加N字节。

重组TCP流需要为属于这个双向流的两个方向的单向流确定流的开始。对于为每个单向流记录初始序列号，从每个单向流上的具有SYN标记的数据包中获取其SN字段的值，设定单向流初始序列号为该值。对于重传乱序的处理，一个通用的方法就是计算嗅探到的数据包在流中的位置，将它放在流中原本的位置上。对于乱序的数据，只需要填充它本该属于的位置即可。而对重传的数据，填充它本该属于的位置可能会造成效率的下降，但这对整个TCP流的恢复并没有太大影响。而且当网络中数据包传输出错时，重传的数据的正确性更高。

3)VoIP协议解析

本发明中主要涉及H.323体系架构中协议解析。IP电话监听系统中主要对Q.931和H.245的数据进行解析。这两个协议承载在TCP协议之上。

H.323协议包括H.245和H.225.0两部分。H.245是用于两个或多个端点之间的控制协议。H.245的主要作用是管理H.323与会者之间的媒体流。H.225.0协议包括两个部分，一部分是ITU-TQ.931建议的变体(以后简称Q.931)，这部分主要用于在H.323端点之间建立以及拆除连接；另一部分被称为登录、许可和状态(RAS)信令，用于端点和关守之间，使关守可以管理其所在域中的端点。

Q.931和H.245这两个协议都建立在TPKP协议之上。TPKP协议在TCP上添加了TPKT头，可以用于区分TCP上的应用层数据。

图4示出了TPKT协议头。一个TPKT协议数据包就是一个H.323信令包。协议解析就是解析这些信令包，从中提取出有用信息，并进行相关的关联。

VoIP协议解析主要是对数据采集中获得的网络数据进行H.323协议分析。从IP数据选择TCP数据，从TCP数据中(即Q.931和H.245的协议数据)监测得到H.323呼叫连接，对呼叫信令进行解析得到设备使用的媒体通道，最后利用得到多媒体通道从UDP数据中分析出H.323音频数据。而在实际的VoIP系统中，为了节省带宽，一般都不会采用独立的H.245控制信道的方式，而是采用快速连接方式或H.245消息封装方式完成逻辑信道的建立。所以往往只需要重组TCP1720端口的数据进行Q.931的解析就可以获得RTP动态端口。

VoIP协议解析主要是调用Openh323开源代码库。Openh323项目是澳大利亚的Equivalence Pty Ltd公司组织开发的，这个协议库完全符合H.323协议，主要是免费面向所有想从事VoIP和网络视频传输的软件开发商使用。

信令提取是针对每个TCP连接进行的，协议解析也是针对每个TCP连接进行的。H.323呼叫建立过程中存在两种连接过程，快连接和慢连接。在慢连接呼叫过程中，H.323端点一般要经过三个控制过程：呼叫接纳控制，呼叫控制，连接控制。而快连接过程利用快启动元素和隧道机制传输连接控制的信息，没有建立H.245连接。

针对慢连接过程，可以得出以下对一次H.323呼叫进行监听的过程：(1)重组Q.931连接的流数据，解析Q.931信令，可以得到通话双方电话号码和IP地址等信息和H.245控制信道地址；(2)重组H.245连接的数据，解析该连接的H.245控制信令，可以得到通话媒体流使用的音频信道地址；(3)根据音频信道地址从而可以截取通话的音频数据即通话内容；(4)关联这三个过程中获取的信息，可以获得一个H.323呼叫的完整信息。Q931协议负责H.323呼叫的建立和拆除，因此应将所有的通话信息与Q.931连接进行关联。

而对快连接过程的H.323呼叫进行监听，只需要重组Q.931连接的流数据，解析Q.931信令，从与快连接相关的信息元素中提取信息，获取媒体信道地址，将截取的音频数据和信令信息与Q.931连接进行关联。

H.245连接地址都是由Q.931连接过程协商确定的，因此系统最初不需要重组任何H.245连接。只有在Q.931信令中获取到H.245地址后，才需要对这些目标H.245地址的连接进行重组。

针对快连接和慢连接两种不同的连接，综合分析，可得出以下协议解析过程。协议解析过程如图5所示。

H.245连接地址都是由Q.931连接过程协商确定的，因此系统最初不需要重组任何H.245连接。只有在Q.931信令中获取到H.245地址后，才需要对这些目标H.245地址的连接进行重组。只重组H245目标队列中的H.245连接会话，且在H.245连接结束时，要删除H245目标队列中本连接对应的目标。

Q.931的约定端口是1720，但这个端口不是知名端口，这就意味着目的端口或源端口为1720的TCP数据包不一定是Q.931数据。Q.931连接中信令的解析过程如下：首先判断该信令是否为Q.931信令，若为Q.931数据，则进行进一步解析；若为SETUP信令，则提取双方身份信息，主叫被叫电话号码，所在服务器信息；若为CONNECT信令，则提取H.245信道的地址信息，若有，则修改过滤规则，添加对这个H.245地址的监听；对所有的信令都尝试获取媒体通道即RTP地址信息，当通话双方的RTP的端口都获得之后，就通知语音记录存储RTP数据包。

H.245连接的端口都是通过Q.931协议通信过程动态确定的。解析H.245信令在于判断逻辑通道是否建立，获取通话双方的RTP地址信息。H.245连接中信令的解析过程如下：先判断该信令是否为H.245信令，若为H.245数据，则进行进一步解析；对所有的信令都尝试获取媒体通道即RTP地址信息，当通话双方的RTP的端口都获得之后，就通知语音记录存储RTP数据包。

4)语音还原

语音还原处理的数据为VoIP协议解析中提取的RTP数据，RTP数据承载在UDP协议之上。

VoIP系统音频数据传输过程如图6所示。在通过呼叫控制信令(如H.323、SIP)建立起两个终端之间的媒体流通道后，便开始了两个终端之间的语音传递过程。整个过程始于对模拟音频的模数转换，经过抽样、量化、编码生成的原始PCM数据再经过音频编码器的压缩编码生成待传送的音频数据，通过RTP、UDP、IP协议的层层封装生成包含有音频抽样信息的IP报文发送到接收终端。接收端接收到含有音频数据的IP报文取出RTP净荷中的音频数据，送入相应的解码器解码，然后通过音频设备进行数模转换，回放出原始的声音来。

语音还原技术就是通过处理和解析RTP协议数据包，按照正确的顺序取出RTP净荷，对RTP净荷进行解码生成wav文件，以及把两路wav文件合成为一个包含两路会话内容的wav文件的处理过程。

整个语音还原过程如图7所示。

排序处理

由于网络传输存在一定的不可靠性，在数据传输的过程中有可能会导致数据包到达顺序的局部混乱，通过排序将很好的解决这个问题。

从RTP协议来看，可以用于进行排序的域有两个，即序列号和时间戳。在没有出现乱序的情况下，序列号和时间戳都应该是递增的，而序列号的递增量应该为1。但是序列号是一个16bit的域，在长时间的通话过程中有可能存在溢出的情况，这将导致排序结果的不正确。通过实验观察，在实际的通话过程中这种情况确实存在。

图8所示为采用Ethereal网络数据分析软件抓到的RTP数据包，其中就存在序列号溢出。因此，我们采用时间戳域作为索引对数据包进行排序。待排序的数据特征是数据基本有序，通过综合考虑各种排序算法的时间复杂度和程序实现的复杂度，我们采用直接插入排序法，比较顺序为从后向前。

补包处理

网络传输的不可靠性还会导致数据包的丢失，可以用填补丢失数据包的方法解决。然而，前一种情况属于非正常缺失，出现的概率是很小的。VoIP系统实现中，常常在检测出通话静音期后，采用停发语音包的方法以减少语音数据传输所占用的带宽。补包处理主要是为了解决这种更为普遍的正常缺失情况。如果不进行补包处理，通话过程中静音期的停顿在恢复出语音后将无法体现，势必严重影响语音还原的效果，还会导致两路音频进行合路后声音的严重不同步。

音频解码

音频解码过程采用于RTP头中负载类型相一致的解码器对RTP净荷数据进行解码，生成16位的原始PCM数据，然后写入.wav文件中，最终生成能够采用音频播放器进行播放的.wav音频文件。

支持的音频解码方式为VoIP系统应用最为广泛的G.711A-law/u-law，G.729，G.723.1。

双向音频的合路处理

通过前面的处理过程，一次通话的两路会话都记录在各自的.wav文件中，而且保证其内容是同步对齐的。合路处理采用把两路.wav文件中的数据部分按抽样量化值按比例叠加的方法。根据数字信号处理的相关理论，通过公式推倒证明这种方法引入和量化误差最大为一个量化级，而两路模拟音频数据合成在一起后，再经过量化引入的量化误差最大为半个量化级。最大量化误差无论是半个量化级还是一个量化级，都不会对音频的还原效果产生大的影响。因此，这种方法算法简单、容易实现，且能够保证较好的音质。

根据本发明的IP电话监听系统和方法的工作流程

首先，相关工作人员需要与目标网络(被监听网络)管理人员交流，了解网络信息，并且对监听系统的需求进行分析。本发明运行后，首先数据处理记录装置将负责过滤采集数据，过滤工作一部分由硬件网络设备完成，一部分由数据采集采用动态修改过滤规则的方式完成。采集完的数据包交付给数据分析进行处理，获取用户身份信息，获取通话双方的多媒体通道地址信息，完成协议解析。语音记录将语音流的信息以文件的方式记录在大型存储设备上。在每个通话结束的时候通知音频转换装置及时进行音频转换。用户查询终端通过网页浏览器输入请求，访问Apache服务器浏览网页的方式获取信息。

具体流程如下所述：

第一步，相关工作人员要与目标网络管理人员交流，对监听系统的需求进行分析。该步骤分析系统的总体需求，是本发明转化为产品的基础。并且相关工作人员应该根据需求向目标网络管理人员提出获取相关信息的要求，如IP地址与对对应的地理位置信息等，同时协商硬件配置。

第三步，配置系统所属的网络环境，确定各装置、数据库和大型存储设备的连通。

第二步，根据网络配置信息，安装各装置，数据库。

第四步，完成前三步之后，启动各装置，监听系统开始工作。

第五步，用户输入查询条件，查看查询结果。用户可以获得的通话信息有：

会话信令源IP
	会话信令目的IP
会话语音流源IP
	会话语音流目的IP
主叫号码
	被叫号码
主叫其他表示
	被叫其他表示
会话发起时刻
	会话终止时刻
会话时长
	前向RTP流文件名(主叫到被叫)
反向RTP流文件名(被叫到主叫)
	合路WAV文件名

用户查询普通通话信息如通话时间，通话时长等，由Apache服务器解析用户请求，查询数据库，向用户返回查询结果。用户要求查询某次通话的内容时，由Apache服务器解析用户请求，查询数据库获得通话内容文件所在路径。

第六步，用户输入报警条件，获取报警结果。

实例

下面通过一个应用实例来说明本发明的实施方案。在该应用实例中，监听系统的网络拓扑图如图所示。

图9中的骨干网数据是2.5G POTS光纤数据经过网络处理器过滤后的数据。交换机交换速率为百兆。

网络配置信息如下

设备名称	操作系统	IP	通信端口
				数据处理装置	Linux	10.0.0.20	6000(与语音记录装置通信)，6500(与音频转换装置通信)
语音记录装置	Linux	10.0.0.30	3000
				音频转换装置	Windows	10.0.0.40	4000
大型存储设备	Windows	10.0.0.50	无
				数据库(兼Apache服务器)	Windows	10.0.0.60	无
用户终端	Windows	10.0.0.70---10.0.0.254	无

系统装置安装

1)安装数据处理装置

第一步编译pwlib，openh323库。

第二步编写XML配置文件，配置文件的信息包括语音记录装置地址及其通信端口，音频转换装置地址及其通信端口，数据库地址。

第三步利用配置文件，执行数据处理装置安装文件。

2)安装语音记录装置

第一步编写XML配置文件，配置文件的信息包括语音记录装置地址及其通信端口，大型存储设备IP地址及其开放的用于语音记录的路径。

第二步利用配置文件，执行语音记录装置安装文件。

3)安装音频转换装置

第一步编译pwlib，openh323库。

第二步编写XML配置文件，配置文件的信息包括语音记录装置地址及其通信端口。

第三步利用配置文件，执行音频转换装置安装文件。

监听结果

系统启动后，通过用户终端设备能查询到正在进行的和已经完成的通话的信息，能够播放已经完成的通话的内容；若用户输入需要被监测的号码，当发现该号码时能及时报警。

Claims (9)

1.一种IP电话监听系统，用于对IP通话进行监听，所述IP电话监听系统包括：

数据采集装置，用于根据过滤规则采集数据包；

数据分析装置，用于对由数据采集装置采集的数据进行TCP流重组；

语音存储装置，用于根据数据分析装置的分析结果，解析出需要记录的RPT流地址信息，并且根据所述RPT流地址信息将需要记录的流中的RTP数据包存储为文件；以及

音频转换装置，用于将语音存储装置存储的文件中的经过语音编码的数据进行解码，生成可使用播放器播放的文件。

2.根据权利要求1的IP电话监听系统，还包括：

进程守护装置，用于监视IP电话监听系统的可靠性。

3.根据权利要求1的IP电话监听系统，还包括：

用户查询装置，用于IP电话监听系统与用户之间的交互。

4.根据权利要求1的IP电话监听系统，其中，过滤规则包括硬件过滤规则和软件过滤规则。

5.根据权利要求4的IP电话监听系统，其中，软件过滤规则是能够根据数据分析装置的分析结果进行动态修改的动态软件过滤规则。

6.根据权利要求1的IP电话监听系统，其中，IP通话包括两个RTP流，并且音频转换装置对基于这两个RTP流的文件进行合路处理。

7.根据权利要求1的IP电话监听系统，其中，语音存储装置在解析RPT流地址信息时，对RTP数据包进行排序。

8.根据权利要求7的IP电话监听系统，其中，根据序列号和时间戳进行排序。

9.根据权利要求1的IP电话监听系统，其中，语音存储装置在解析RPT流地址信息时，对RTP数据包进行补包处理。

Images