摘  要: 提出了一种集成式IP电话网关的实现方法，分析了语音信号在该网关中的处理过程，详细介绍了语音采样、播放、压缩与解压缩、RTP包的封装与解包以及IP包的接受和发送的实现方法。

　　关键词: IP电话网关  语音压缩  RTP协议

　　随着IP电话技术的飞速发展,IP电话的实现方式正在由PC To PC过渡到Phone to Phone,在Phone to Phone的实现方式中,需要所谓的IP电话网关来连接PSTN和因特网。因此IP电话网关成为目前计算机和通信领域研究的热点之一。虽然国内外许多厂商都在以不同的方式开发IP电话网关,但他们有一个共同的的特点,即:几乎所有IP电话网关都采用了自己的专用硬件设备。本文提出了一种采用市场上通用的板卡来构造一种硬件集成式的IP电话网关的方法,并研究了语音数据在该网关的处理过程和实现方法。

　　集成式IP电话网关的硬件构成如图1所示,它是在Pentium II PC机的基础上,插入Dialogic公司的D/41E型语音卡、LSI公司的C6200资源卡和D_Link网卡所组成。其中D/41E语音卡用来完成语音的采样和播放。C6200资源卡有一块TI公司的TMS320C6201 DSP芯片,用来完成语音的压缩和解压缩以及回声抵消。Pentium II PC用来实现H.323协议栈的主要功能,网卡用来发送和接受IP包。下面具体分析语音数据在IP电话网关的处理过程和实现方法。

1 语音采样和播放

　　在该IP电话网关中,语音的采样和播放是由Dialogic公司的D/41E型语音卡来完成,其中,语音采样是利用语音卡所提供的录音函数来完成的。在实时语音通信时,语音数据存入语音采样缓冲区中,等待语音压缩线程取出并处理。录音函数形式如下:

　　dx_reciottdata(activeChdev，&chinfo[activeChdev].iott，&tptrec[0]，&xpbVox，mode);                  

　　该函数的输入参数的含义如下:

　　int chdev                    语音通道的设备句柄

　　DX_IOTT *iott         　　   指向语音数据目的地的指针

　　DV_TPT *tptp                 指向终止参数块的指针

　　DX_XPB *xpbp                 指向I/O传输块的指针

　　unsigned short mode          录音所采取的方式

　　iott是一种DX_IOTT类型的数据结构，该数据结构中的io_type可取值IO_DEV和IO_MEM，分别用于指定语音数据是存入文件还是存入缓冲区中。io_type的另一类取值可为IO_CONT,IO_LINK或 DX_IOTT,用于指定语音数据目的地的结构。如果io_type取值IO_DEV,则io_fhandle的值应为一个文件的句柄;如果io_type取值IO_MEM,则io_fhandle的值应为0,此时,io_bufp指向存放语音数据的缓冲区的起始地址。io_offset为地址偏移量。io_length用于指定文件或缓冲区的大小。如果io_type取值IO_LINK,则io_nextp指向下一个存放语音数据的DX_IOTT数据结构,而io_prevp指向上一个存放语音数据的DX_IOTT数据结构。DX_IOTT的数据结构定义如下:

　　typedef struct dx_iott {

　　unsigned short io_type；               /*Transfer type*/

　　unsigned short rfu； 　　　　　        /*Reserved*/

　　int     io_fhandle；   　　　　　　    /*File descriptor*/

　　char*  io_bufp；   　　　　　　　　    /*Pointer to base memory*/

　　unsigned long io_offset；  　　        /*File/Buffer offset*/

　　long int io_length； 　　　　　        /*Length of data*/

　　DX_IOTT *io_nextp；   　　　　         /*Ptr to next DX_IOTT if IO_LINK set*/

　　DX_IOTT *io_prevp； 　　　　　　　     /*(Optional) Ptr to previous DX_IOTT*/

　　}　DX_IOTT；

　　DV_TPT数据结构用于指定终止某语音通道上函数的条件。具体如下:

　　typedef struct DV_TPT {

　　unsigned short  tp_type；              /*Flags describing this structure*/

　　unsigned short tp_termno； 　　　　　　/*Termination parameter number */

　　unsigned short tp_length；   　　　　　/*Length of terminator*/

　　unsigned short tp_flags；              /*Term.parameter attributes flag*/

　　unsigned short tp_data；   　　　　    /*Optional additional data*/

　　unsigned short rfu； 　                /*Reserved for future use*/

　　struct DV_TPT *tp_nextp； 　　　　　　 /*Pointer to next term.parameter if*/

                                           /*IO_LINK is set*/

　　} DV_TPT；

　　DX_XPB数据结构用于指定用何种算法进行录音等。WFileFormat可取值FILE_FORMAT_VOX和FILE_FORMAT_WAVE,分别代表用VOX文件格式和WAV文件格式存放语音数据。wDataFormat可取值DATA_FORMAT_DIALOGIC_ADPCM、DATA_FORMAT_MULAW、DATA_FORMAT_ALAW、DATA_FORMAT_PCM,分别代表用ADPCM、μ率、A率或线性PCM的算法对声音进行采样。nSamplesPerSec可取值DRT_6kHz、DRT_8kHz、DRT_11kHz,用于指定采样频率分别为6kHz、8kHz或11kHz。nBitsPerSample可取值4和8,为每个样本点的位数。如果wDataFormat采用ADPCM算法,则nBitsPerSample只能取4。DX_XPB的数据结构定义如下:

　　typedef struct {

  　USHORT   wFileFormat；          //file format

  　USHORT   wDataFormat；         //audio data format

  　ULONG   nSamplesPerSec；       //sampling rate

  　ULONG   nBitsPerSample；        //bits per sample

　　} DX_XPB；

　　mode用于指定录音的方式,可取值PM_TONE、EV_SYNCH或EV_ASYNCH。取值PM_TONE代表在录制前先播放一个200ms的提示音。取值为EV_SYNCH时,代表用同步的方式执行语音采样,在同一线程中的其它功能将被暂时挂起,直到该同步函数执行完后才被释放。取值为EV_ASYNCH代表是用异步的方式执行语音采样,在同一线程中的其它功能仍可照常进行。

　　语音播放是利用语音卡播放函数来完成的。该函数所用的参数与录音函数的参数类似。播放函数的形式如下:

    dx_playiottdata(activeChdev，&chinfo[activeChdev].iott，&tptplay[0]，&xpbVox，mode)

2 电话状况侦测

　　电话状况侦测功能主要是判断电话线状况,如判断现在电话机话筒是拿起或放下,有没有拨号音,是否电话正忙或没有人接电话。在异步方式下，采用语音卡的ATDX_CPTERM()来检测某语音通道上电话呼叫的返回值。在同步方式下无需该步骤。当返回值为CR_CEPT时,表示特殊通知音,即拨了无效的电话号码或遇到了其它特殊问题。当返回值为CR_NORB时,表示无回铃音,即检测不到可识别的信号模式。当返回值为CR_NOANS时,表示无应答,即线已拨通，但无应答。当返回值为CR_CNCT时,表示连接音。当返回值为CR_BUSY时,表示忙音。当返回值为CR_CNCT时,还可利用ATDX_CONNTYPE(chdev)函数检测连接音的类型。返回值可能是CON_CAD,CON_LPC,CON_PVD或CON_PAMD,分别代表韵律连接音,循环流连接音,阳极音连接音或阳极应答机连接音。

　　进行呼叫时,先用ATDX_HOOKST(activeChdev)函数获取电话机的状态。如果是挂机状态,则用dx_sethook(activeChdev，DX_OFFHOOK，EV_SYNC)将电话机置为摘机状态。然后给呼叫函数传递所需的参数。参数是通过DX_CAP这个数据结构来传递的,其定义为:

　　typedef struct DX_CAP {

　　unsigned short ca_nbrdna；  　　　  //# of rings before no answer.

　　unsigned short ca_stdely；          //Delay after dial before　analysis

　　unsigned short ca_cnosig；   　　　 //Duration of no signal time out delay

　　unsigned short ca_lcdly；   　　　  //Delay after dial before lc drop connect

　　unsigned short ca_lcdly1；    　　　//Delay after lc drop con. before msg.

　　unsigned short ca_hedge；    　　　 //Edge of answer to send connect message

　　unsigned short ca_cnosil； 　　　　 //Initial continuous noise timeout delay

　　unsigned short ca_lo1tola；   　　　//% acceptable pos.dev of short low sig.

　　unsigned short ca_lo1tolb； 　　　　//% acceptable neg.dev of short low sig.

　　unsigned short ca_lo2tola；   　　　//% acceptable pos.dev of long low sig.

　　unsigned short ca_lo2tolb；   　　　//% acceptable neg.dev of long low sig.

　　unsigned short ca_hi1tola； 　　　  //% acceptable pos.dev of high signal.

　　unsigned short ca_hi1tolb；     　　//% acceptable neg.dev of high signal

　　unsigned short ca_lo1bmax；   　　　//Maximum interval for shrt low for busy.

　　unsigned short ca_lo2bmax；  　　　 //Maximum interval for long low for busy.

　　unsigned short ca_hi1bmax；   　　　//Maximum interval for 1st high for busy

    unsigned short ca_nsbusy；          //Num. of highs after nbrdna busy check.

    unsigned short ca_logltch；         //Silence deglitch duration.

    unsigned short ca_higltch；         //Non-silence deglitch duration.

    unsigned short ca_lo1rmax；         //Max. short low dur. of double ring

    } DX_CAP；

　　该数据结构中有大量的参数项,一般使用缺省值即可。需要修改时,可通过程序提供的呼叫对话框来修改。呼叫的电话号码也在该对话框中指定。

3 语音数据压缩与解压缩

　　G.723.1、G.729均为ITU H.323所推荐的语音编码标准。其中G.723.1采用ACELP和MP_MLQ算法,比特率为6.3kbps和5.3kbps。G.729采用CS_ACELP算法,比特率为8kbps。由于G.723.1无论是在带宽还是语音质量都优于G.729，因此，一般在IP电话中普遍使用G.723.1语音压缩标准。

　　在集成式IP电话网关中，语音的压缩是由C6200资源卡上的TMS320C6201 DSP来完成。G.723.1编码器的输入信号是8kHz的16位线性PCM码,由语音卡采样的语音信号包括8kHz的8位线性PCM码在内的多种形式,在输入到G.723.1编码器之前,需要进行转换。相应地,解码器的输出语音信号也应转化为语音卡能识别的格式数据流。Dialog D/4E语音卡只识别ADPCM码,其它高级一些的语音卡如D/41ESC语音卡既可识别ADPCM码,也能识别线性PCM码。编码器每30ms处理一帧数据,每帧包含240个样本点,每个样本点占16位。G.723.1编码/解码器的处理流程大致过程如下:

　　每一帧首先通过高通滤波器,去除直流成分,然后被分为4个子帧,每个子帧包括60个采样点。每个子帧被送入一个10阶线性预测编码器,计算LPC系数。最后一个子帧的LPC系数采用预测分裂矢量量化器(PSVQ)量化。量化前的LPC系数用来建立短时感觉加权滤波器,整帧信号通过它得到感觉加权语音信号。对于每两个子帧,用感觉加权后的语音信号来计算开环基音周期,基音周期的搜索范围在18和145之间。对于每一个子帧,运用估计的基音周期建立谐波噪声成形滤波器(Harmonic Noise Shaping filter)。LPC合成滤波器、共振峰感觉加权滤波器和谐波噪声成形滤波器组成一个联合滤波器,然后可以得到该滤波器的冲激响应。运用基音周期估计和冲激响应计算闭环基音周期。采用五阶基音预测器,以开环基音周期为中心,作小范围内闭环搜索,得到精确的基音周期,然后将基音预测器的贡献从初始的目标矢量中扣除。最后,进行非周期性的激励信号的估计。对于高码率6.3kbps,采用多脉冲最大似然量化激励(MP_MLQ);对于低码率5.3 kbps,采用代数码本激励(ACELP)。

4 RTP包的形成与解包

　　RTP包的形成与解包是由网关中的主CPU(Pentium Ⅱ)来完成。RTP是IEFT的提议标准RFC1890。它是一个独立于应用程序的协议规范,在具体应用中可有不同的独立框架。每个RTP数据包都由一个头部和一个有效数据部组成。有效数据部中放置压缩后的语音数据。RTP包头的前12个字节是固定的,其格式如图2所示。

　　在RTP包头中,标记M占有1比特位,用来指明语音数据的边界。PT占7比特位,指明语音数据的压缩类型。Sequence number占16比特位,是一个正整数的序列号。每发送一个RTP数据包,序列号就加1。接收端可通过序列号监测数据包传输过程中的丢包情况以及失序情况。序列号的初始值是随机分配的。Timestamp是时间戳,占32比特位,描述RTP包中语音数据的采样时刻,主要用于同步和计算时延。Synchronization source identifier是同步资源标识符SSRC,占32比特位,用于标识同步资源。RTP打包过程如图3所示。

　　如果是第一次生成RTP包，则序列号的初值为一随机数而不是0。这样做的目的是为了通信过程中的安全性。SSRC标识符是一个32位的随机数。在一个RTP会话中，不允许两个SSRC有相同的值。RTP解包过程是RTP打包过程的逆过程,在此不再赘述。

5 IP包的发送与接收

　　利用H.323协议栈软件包可以生成符合H.323协议的API函数。在程序中,先执行 mcInitialize()和mcSetEventHandler()建立H.245控制信道,然后执行mcOpenCall() 函数以建立H.225.0呼叫信令信道。在mcOpenCall()函数的参数中可以设置所选的音频编解码协议。所选的音频编解码协议包括G.711协议(必选) 、G.722、G.723.1、G.728或G.729协议。当H.245控制信道和H.225.0呼叫信令信道成功建立后,使用mcSendAudio()函数发送包含压缩语音数据的IP包。当通话结束后,使用mcCloseCall()函数关闭H.225.0呼叫信令信道和H.245控制信道。

　　本文提出的集成式IP电话网关具有硬件结构简单、维护方便、升级容易等优点,并具有很高的性能价格比,更有价值的是拓宽了设计IP电话网关的设计思想。另外,本文还详细地给出了语音在网关中的各个阶段的处理过程和实现方法,其中有关语音压缩和回声抵消的处理,是网关中语音的关键技术,涉及到网关的DSP的运行效率、压缩算法的优化、语音质量的提高和噪声的消除等技术问题。

参考文献

1 Dialogic， Standard Runtime Library Programmer＇s Guide for Windows NT. Dialogic Corporation,1997

2 Heffes H，Lucanoni D.A. Markov modulation characterization of packetized voice and data traffic and related statistical multiplexer analysis[J].IEEE JSAC， 1986；4(6):856～868

3 H.Schulzrinne， S.Casner， R.Frederick， V.Jacobson. RTP-A Transport Protocol for Real-Time Applications. Internet Draft， draft-ietf-avt-rtp-new-ps， Internet Engineering Task Force， Dec.，1997

4 H.Schulzrinne. RTP Profile for Audio and Video Conferences with Minimal Control. Internet Draft， draft-

ietf-avt-profile-new-01.ps， Internet Engineering Task Force， Jan.，1998