H.323语音捕获器的设计与实现

摘要:随着IP电话技术应用的普及, IP电话带来的普遍服务、紧急呼叫、公众安全等系列问题越来越受关注。为了利于对IP电话业务的安全性管理及其健康的发展,本文介绍一种在IP 网络对IP 电话进行呼叫监控,协议分析以及监听录音的方法。主要讨论H.323语音捕获器的设计和技术实现。

关键词:H.323 ; IP电话;语音监听

前言

随着国内互联网技术迅猛发展,数据网络带宽的不断扩展。能够将语音信号转化为数据信号从而在数字网络中进行信号传输的IP电话技术已经从原来的实验性质真正的转向为成熟的商业应用。IP电话(VoIP)以其低廉的价格、增值业务的多样性、质量的不断提高正越来越多地替代传统电话,日益受到用户的欢迎。随着IP电话对公众利益影响增大、业务的可靠性增强,对PSTN的替代程度扩大,积极应对IP电话带来的普遍服务、紧急呼叫、公众安全等系列问题,实施IP电话轻度管制政策将是正确的举措。到目前为止有关对IP电话进的监听的标准还没有建立。为了有利于对IP电话业务进行合理的管制,有利于IP电话业务健康的发展,本文描述一种实现监听H.323协议的IP电话软件的方法。
1 　原理分析

当前IP电话技术主要采用两种H.323和SIP协议体系,虽然它们在呼叫过程和信令定义上存在着不同,但原理是相似的。我们这里只讨论H.323的IP电话,SIP可以类推。

H.323是ITU-T研究开发的IP网络实时多媒体通信标准协议体系,它有呼叫控制,媒体编码,管理控制, 网络安全和会议通信等一系列组成。H.323协议栈结构如图1所示:

图1 　H.323协议栈结构

其下三层为PBN的底层协议,在IP网络中,其网络层就是IP,其下面是相应的主机—网络接入协议层,可靠协议为TCP用于传送数据信号及呼叫信令;不可靠协议为UDP用于传送实时声像信号和终端至网闸的登记协议。我们可以通过对H. 323特定1719和1720端口监听,进行IP包数据分析获得IP 电话连接过程中的RAS和Q.931信令。下面我们分析在同一网闸登记的两个IP电话的连接过程,信令过程如图2所示。
图2 　公共网闸(网闸选路) 信令过程

图2与直接选路的差别在于: 网闸向端点1回送的ACF消息中包含的不是端点2的呼叫信令信道运输层地址,而是网闸建立网闸自身的呼叫信令信道运输层地址。同时,网闸建立至端点2的呼叫信令信道。其后,端点1的呼叫信令消息只能发往网闸。再由网闸转发给端点2。由于端点2只和网闸建有信令信道,因此其信令消息也只能发往网闸,再由网闸转发给端点1。呼叫建立成功时,端点2仍经Connect消息告知其H.245控制信道运输层地址,但网闸向端点1发送的Connect消息所含信息取决于H.245控制消息的传送方式。如果网闸决定采用直接方式传送媒体控制消息,则消息中包含的是端点2的H.245控制信道地址;如果采用转接方式,则消息中包含的是网闸H.245控制信道地址,此时,网闸中一般包含MC功能。

通过分析以上的呼叫过程,知道了对Q.931呼叫过程监测,Q.931信令的分析可以得到H.245控制信道地址,通信根据得到的地址,解析该连接的H.245控制信令,我们在其逻辑信令过程中得到音频信道地址,从而可以得到相应的音频数据具体实现方法和算法见本文的协议分析部分。

2 　H.323语音捕获器的结构组成

在这里,我们重点讨论语音捕获器的主要功能模块以及这些功能模块的软件设计与实现,功能模块之间的关系及其工作流程如图3所示。

图3 　语音捕获器的功能关系图(即工作流程图)

数据捕获模块是通过以太网卡捕获经过其的网络数据。以太网的数据传输是基于“共享”原理的:所有的同一本地网范围内的计算机共同接受到相同的数据包。这意味着计算机直接的通信都是可见的。正是因为这样的原因,以太网卡都构造了硬件的“过滤器”,这个过滤器将忽略一切和自己无关的网络信息。如果将网卡设置为“混杂模式”,关闭这个过滤器就能够接受整个以太网内的网络数据了。另外也可以将该模块放置与防火墙位置类似的网络接点处来完成。

协议分析模块主要是对捕获模块中获得网络数据进行IP协议分析和H.323协议分析。首先通过对网络数据帧结构分析,过滤掉非IP数据,然后从IP数据选择TCP数据(或UDP数据) 。再从TCP数据(或UDP) 数据中监测得到H.323呼叫连接,对呼叫信令进行解析得到设备使用的媒体通道,最后利用得到多媒通道从UDP数据中分析出H.323音频数据。

录音监听模块是将协议分析模块中得到呼叫信息和音频数据存储到中央数据库,拥有多种录音和监听功能,以应付不同情况的需要,如自动录音、选择录音等。

前端控制模块与其他三个模块结合紧密,所有管理员的控制命令和参数设置都是通过它对其他模块完成的。它提供中文系统管理和监控界面,系统管理提供包括呼叫监控,呼叫记录和录音管理,录音回放,最小录音段设定,噪音电平检测设定,多服务器网络设定等系统级管理和应用级管理。监控功能提供自动线路监控告警,服务器工作状态,硬盘容量,备份告警等多种监控功能。

2. 1 　H.323语音捕获器的主要功能

捕获器的应用结构如图4 所示:

图4 　软件应用结构图

主要功能如下:
(1) 多种方式录音
软件有自动条件触发或手动录音控制两种录音方式。因此,可以根据实际的需要,既可以自动录音也可以手动录音。迅速实施按需录音、全程录音和质量监控功能。提供设定规则进行录音例如:根据设定IP 范围有选择进行录音。

(2) 多点录音、中央存储
考虑到多点的捕获器和组网环境。通过数据网络传送语音。捕获器在世界的任何地方,只要能够访问数据网连接到服务器,就可以把语音数据存储到中央服务器。

(3) 支持大规模录音
纯软件的解决方案,没有通话数量的限制。只依靠服务器进行数据存储和索引。因此没有每小时呼叫处理能力的限制,是“分布处理,集中存储”。

(4) 实时电话和录音回放
可以根据需要在对监测的电话连接进行直接实时监听。录音回放根据两种不同模式支持多种检索查询方式,从数据库服务器中获得录音进行回放。

(5) 数据实时备份
数据库服务器对数据进行实时的备份,数据几乎是同时被写到存储介质(硬盘,DVD-RAM ,MO等)上的。如果发生系统崩溃,那么数据已经被存档了。支持系统级镜像备份,允许同时将录音资料备份到异地另一台服务器上,保障即使系统遭到毁灭性打击,仍保障数据安全。

3 　数据捕获和过滤

目前在过滤器和VPN的实现中常用采用两种截获网络数据的方式, 一种是应用层采用Winsock2SPI , 另外一种是在核心层采用NDIS-HOOK。我们这里采用NDIS-HOOK。

NDIS(NetWork Driver Interface Specification网络驱动程序接口规范)提供了网卡和协议以及操作系统的通信驱动,它提供了网络驱动开发的全部函数。Windows使用NDIS函数库实现NDIS接口。所有的网络通信最终必须通过NDIS完成。NDIS横跨传输层、网络层和数据链路层,NDIS的结构如图5所示:

图5 　NDIS的结构图

NDIS - HOOK的工作原理是直接替换NDIS的函数库中的函数地址,这样只要向NDIS的请求就会先经过我们自己函数的处理,处理完转发给系统函数就完成了。图6为NDIS - HOOK安装前后的结构图。


图6 　NDIS - HOOK安装前后的结构图
(左为安装前,右为安装后)

4 　协议分析

数据在网络中帧(Frame)的单位来传输的。以太网卡收到的报文的结构,其前14字节是EthernetHeader,这14字节的具体定义如图7所示:

图7 　以太网数据帧的格式
头6个字节是目的地址,接着6字节是源地址,第13 ,14字节是帧类型或帧长度,这两个字节决定帧的类型,下面是判断帧类型的算法:
IF 帧类型/ 帧长度<= 1500 (十进制)
IF 帧类型/ 帧长度字段后续第一个WORD 是FFFFh
　此PACKET 是raw Ehternet 802. 3
ELSE
　IF 帧类型/ 帧长度字段后续第一个WORD
是AAAAh AND Cont rol IS03h
　　此PACKET 是Ethernet SNAP
　　ELSE
　　此PACKET 是Ethernet 802. 2
　ENDIF
ENDIF
ELSE
此PACKET 是Ethernet Ⅱ
ENDIF

根据此算法就可以判断出帧类型。帧类型,帧长度的值还可以确定帧所携带的协议。如果Packet是有效的IP包的话,帧类型/ 帧长度的值应该是0800。

接下来我们要分析IP 协议,先看一下IP的报头的格式如图8所示:

图8 　IP 的报头格式

根据协议号这个字段我们很容易从IP包中拆分出TCP(06)包或者UDP(11)包。

接下来是需要从TCP数据中得到H.323设备使用的媒体通道,先让我们看看H.323通信当中使用TCP和UDP协议的报头格式图9和图10。

图9 　TCP报头格式


图10 　UDP报头格式

UDP中并没有标识该数据包是何种数据的字段,RTP头部也没有提供足够的信息区别以RTP打包的媒体流数据与其他的UDP数据。我们从网卡数据中拆分出UDP包,而哪些包是需要的H.323的音频数据,无从获知。不妨借鉴一下TCP分离HTTP数据的方法:如果目的端口为00 50 (80),那么TCP数据部分传送的是HTTP 协议的请求,如果源端口为00 50 (80),那么TCP数据部分传送的是HTTP协议的请求,如果源端口为00 50 (80),那么TCP数据部分传送的是HTTP协议的回应,即通过端口来确定其传输数据的类型。

RTP没有固定的端口,但可以通过打开逻辑通道的确认消息OpenLogicalChannelAck得到,首先需要在1719,1720侦听RAS消息和Q. 931消息,解析Q.931的消息得到的H.245能力协商过程的TCP连接IP地址及端口号,再通过解析H.245消息,得到音频传输的地址及端口号,下面给出一个获得音频传输RTP信道端口的实现伪代码:
If (源端口> 1024 & & 目的端口> 1024) {
H245 MultimediaSystemCont rolMessage
H245Mesg ;
/ / 为真则是打开逻辑信道过程的消息
If (245Mesg. Decode (收到的TCP 数据) )
　switch (245Mesg. Get Tag () ) {
　　/ / 为请求消息
　　case H245 MultimediaSystemCont rolMessage : :
e request :break ;
　　/ / 为确认消息
　　case H245 MultimediaSystemCont rolMessage : :
e response :{

H245 ResponseMessage &Response = 245Mesg ;
　　　switch (Response. Get Tag () ) {
　　　　case
H245 ResponseMessage : :e_openLogicalChannel
Ack :
　　　RTP 信道发送者的IP 地址和端口= mediaChannel : :
H245 TransportAddress ;
　　　　RTCP信道发送者的IP地址和端口= mediaControlChannel : :H245 TransportAddress ;
　　　　检测RTP 端口是否为2n,RTCP端口是否
为2n+1 ,是则数据正确,否则为无效数据。
　　　　break ;
　　　　　..}
　　}
　　　break ;
　　　..
　}
}

通过以上算法得到RTP的端口,我们就可以通过端口区分出通过RTP打包的音频数据与其他UDP数据了,接下来的工作是进行RTP头的分离和音频数据的重组。固定报头的RTP报文结构如图11所示:

图11 　固定报头的RTP报文

通过RTP中净荷类型字段可以确定媒体流的类型。

5 　结论

本软件开发完成之后,我们对其进行了实际检验。主要通过西安邮电学院通信技术研究所所提供的局域网环境以及标准IP电话4台,个人计算机若干,对语音捕获器进行了长时间的功能测试和性能测试,测试结果表明,本软件功能基本实现,操作方便,基本符合事先的设计期望。