基于Channel Bank和网关的IPCB网关的设计与实现

提出了一种基于Channel Bank和VoIP语音网关的将大客户语音接入IP网络的IPCB方案。详细阐述了IPCB的基本功能、体系结构及其设计原理。实际运行的结果表明，该设计方案是切实可行的。?
    关键词：通道组, 网关, H.323协议, 有限状态机?

1 引言
    在传统的电信业务中，语音的交换是基于时隙的电路交换，其主要问题在于：(1) 通信过程中用户对线路的独占所造成的通信资源的浪费；(2) 电路交换的体系结构不便实现业务的综合。随着通信技术的迅速发展，语音、数据和视频融合于基于包交换的IP（Internet Phone）网络是目前通信技术的发展方向，其重要的技术特征是统计时分复用〔1〕。因此，研究将传统电信的语音业务融合于IP网络的技术是目前的开发热点。由于在现有的电信语音业务中，企业和集团的用户占有很大比例，故，开发针对企业和集团这样一类大客户的语音业务接入IP网络的方案具有特别重要的现实意义。
    目前，企业和集团大客户的语音通信采用两种方案。一，通过PBX（Private Branch Exchange，用户交换机）接入到传统的PSTN（Public Switching Telephone Network，公用交换电话网）网实现语音通信；二，在PBX上加一个VoIP（Voice Over IP）网关将话音业务接入到IP网，即，所谓的IP-PBX方案〔2〕，如图1所示。

    尽管上述IP-PBX解决方案解决了语音到IP网的接入，但是，这种实现方案需要用户配备PBX。PBX价格昂贵，对企业而言并不经济。为此，本文提出了使用Channel Bank来代替PBX，与数字VoIP网关相结合，组成IPCB的解决方案。该方案的主要特点在于，很方便地实现大客户语音到IP网络的接入，同时，将大客户内部的语音交换移植到IP语音网关上，通过软交换来完成。
2 IPCB的基本功能
    IPCB是要实现大客户的语音业务到IP网的接入，通过IP网络与远端的用户进行语音通信。因此，IPCB应具有下列基本功能：
    （1） 完成用户侧和网络侧的呼叫建立和释放。?
    （2） 同时完成96路语音编码（ITU?T的G系列协议，G.711，G.723，G.729）、RTP（Routing Table Protocol）打包解包、回声消除、静音检测，并提供收端缓存等语音功能。
    （3） 用户侧通过通道组（Channel Bank）转换而来的数字中继信令，完成与网络侧Q.931或H.245信令之间的转换。?
    （4） 在通话开始时采集计费信息，并在通话结束时经过网守向计费/认证中心发送计费信息。?
    （5） 自动识别语音和传真业务，传真符合T.38协议。?
    （6） 为用户提供交互式语音提示IVR（Interactive Voice Register）。?
    （7） 支持产生与检测DTMF（Double Tone Multiple Frequency，双音多频），用于远端电话用户的第2次拨号。?
    （8） IP网关支持卡号用户和主叫号用户的使用。?
    由于Channel Bank没有交换模块，因此，IPCB除了要完成上述用户侧与IP网络侧之间的信令和协议的转换、用户与远端通信媒体流的传输外，还应具有实现Channel Bank上各个通道之间的语音交换的功能。 
3 IPCB的结构
    IPCB由Channel Bank和VoIP语音网关两部分组成，它的结构如图2所示。IPCB的一端通过VoIP语音网关的以太接口连接到外部的IP网，另一端通过Channel Bank的用户电路模块接24部普通电话(S口)或接交换机的24条模拟用户线(O口)。在IPCB内部，Channel Bank和VoIP网关之间通过T1中继线相连。

    VoIP网关的底层为语音板卡和以太网卡，中层为操作系统和H.323协议栈，上层为应用程序。语音板卡采用的是Audiocodes公司的TP240，最多可提供四个T1/E1中继接口,可以同时处理96/128路语音的编/解码，语音的RTP打、解包及Channel Bank上各个通道的状态检测和信号提取。语音的RTP/RTCP（Routing Table Protocol /Realtime Transport Control Protocol，路由表协议/实时传输控制协议）流可以通过板卡上的以太网接口传输。IP网络侧的信令则通过VoIP网关上的以太网卡传输。
    Channel Bank是一个通道组，由用户电路模块和数字中继模块组成，可以提供24路语音的接入和一个T1中继接口。用户电路模块可完成馈电、过压保护、振铃、监测、混合电路、测试和编/解码等项功能。数字中继模块则将收到的数字信号送到T1中继相应的时隙上，T1中继的24个时隙与Channel Bank的24个语音通道一一对应。
4 系统设计的基本原理?
    在IPCB系统中，语音的编/解码、媒体流的打/解包是通过VoIP网关上的硬件语音板卡来完成的，而用户模拟语音与数字语音之间的转换，以及模拟信令与数字中继信令之间的转换是由Channel Bank来完成的。因此，系统设计主要集中在软件的开发上，下面介绍系统软件模块划分、呼叫及交换实现的基本原理。
4.1 IPCB网关的模块划分?
    IPCB的语音网关模块可划分为五个部分，即：PSTN呼叫处理，H.323呼叫处理，网关用户界面管理，公共定时服务器和网管代理。其结构如图3所示。

    PSTN呼叫处理模块：利用板卡TP240提供的API（Application Program Interface，应用程序接口）函数来完成信令的提取，DTMF收号，交互式语音（IVR）提示，语音通道的管理，呼叫流程的控制以及信令之间的转换等功能。?
    H.323呼叫处理模块： 利用H.323协议栈提供的API函数来完成H.323的RAS（Remote AccessService，远程接入服务）消息、Q.931消息和H.245消息的传送，进行呼叫流程的控制以及H.323消息到适配信令的转换。
    定时器模块：为整个网关应用程序提供定时。当上述模块之一需要开始一个新的定时时，就可以通过发送消息的形式来向模块请求。当定时时间到达时，定时器会向请求定时的模块发送定时响应消息。
    网关用户界面管理：完成网关系统初始化，向其它模块发送人机管理界面命令，接收显示网关状态、告警消息和故障检测结果，实现与PSTN的呼叫处理以及H.323呼叫处理模块的交互通信。
4.2 信令的转换?
    IPCB的VoIP语音网关与Channel Bank之间采用的是PSTN数字中继信令，与IP网络之间采用的是H.323信令。网关必须对这两种信令进行转换。考虑到系统的可扩展性，在PSTN网的信令和IP网的信令之间构造一组中间适配信令，如图4所示。

    这样，网关两侧网络的协议信令都向中间适配信令转换，通过中间适配信令实现两个网络协议信令的转换。这种将两个网络的协议信令都向一个中间适配信令转换的好处是隔离了一侧网络新增信令协议所引起的变化直接对另一侧网络协议的影响，以便网络引入新的信令协议，使系统具有良好的可扩展性。为了保证这种设计的有效性，在设计初期应仔细地构建中间适配信令集，以确保多协议引入时，中间适配信令的完备性。在上述的网关模块划分中，PSTN呼叫处理模块和H.323呼叫处理模块的主要功能之一，就是分别完成PSTN的协议信令和H.323协议信令到中间适配信令之间的转换。
4.3 呼叫处理?
4.3.1 呼叫的处理方式?
    IP电话呼叫处理的过程是一个典型的在有限状态之间进行状态变迁的过程。呼叫处理可根据输入的呼叫信令消息和当前状态，完成相应的呼叫信令处理，确定变迁到达的新状态。因此，对于一个具体的呼叫，可以采用有限状态机（Finite State Machine,FSM）的方法来进行过程的描述和处理。
    另一方面，在VoIP网关中会同时存在多个呼叫。呼叫处理必须考虑对并发呼叫的实时处理。鉴于传统的多进程处理并发事件的方式所存在的问题(呼叫越多，进程切换的开销越大，内存资源占用越多)，在IPCB的网关中采用单呼叫进程实现多呼叫的并发处理。
    单进程处理多呼叫并发事件的设计方法是：当一个呼叫产生时，进程生成一个记录该呼叫的呼叫控制块，称为CCB（Call Control Block）。呼叫控制块记录了该呼叫的主叫号码、被叫号码和当前的状态等信息。因此，多个呼叫就产生了与之对应的多个呼叫控制块，进而组成一个呼叫控制表。当一个呼叫的信令到达时，呼叫处理进程基于主叫号码和被叫号码查寻呼叫控制表，从表中读取该呼叫对应的呼叫控制块，然后，根据输入的呼叫信令和当前状态，完成相应的呼叫信令处理，确定将要转移的新状态，并迁移到该状态。最后，用迁移的新状态更新该呼叫控制块的内容。
    VoIP网关对CCB的管理是动态完成的。当呼叫开始时，CCB被创建，呼叫终止时，CCB被撤消。
    若当前状态下接收到一个不希望到达的呼叫信令，则可视作该呼叫过程发生故障，此时，可退出呼叫处理过程。
4.3.2 IPCB的语音交换控制?
    Channel Bank上的用户与远端的用户进行语音通信可分为三种情况：一是，Channel Bank上的用户作为主叫，呼叫远端的用户；其二是，主/被叫都是Channel Bank上的用户；三是，IP网络侧远端的用户作为主叫，呼叫Channel Bank上的用户。
    为了实现对上述语音交换的控制，在VoIP电话网关上，对Channel Bank上每一个通道时隙指配一个特定逻辑电话号码，建立一张中继时隙通道号与对应的逻辑电话号码的映射表。当VoIP网关收到来自Channel Bank上的用户呼叫时，网关首先通过该呼叫所处的时隙通道号码，查询映射表，获取主叫用户的逻辑电话号码，然后，经过网守向认证计费中心认证该逻辑电话号码的合法性和呼叫权限，在认证鉴权通过后，从呼叫的消息中读取被叫的电话号码，搜索时隙通道与逻辑电话映射表。结果有下面两种情况：
    （1）如果被叫电话号码与映射表中的某个逻辑电话号码相匹配，则表明是一个Channel Bank内部的两个电话的通信，就从表中读取该逻辑电话号码对应的中继号和中继时隙通道号。在获得了主叫和被叫在数字中继上对应的中继和物理时隙通道后，通过包交换技术将语音包交换到对应的物理通道上，从而实现内部各用户的语音交换。
    （2）如果被叫电话号码未能与映射表中所有的逻辑电话号码相匹配，则表明是一个到IP网络侧的远端呼叫。网关向网守请求地址解析，获取远端网关或H.323终端的信令IP地址。然后，发起快速呼叫连接，同时告诉对端本地的媒体流的IP地址和将要用于本呼叫的接收媒体流的逻辑通道号。在收到远端返回的呼叫进行(Call Proceeding)或提醒消息(Alerting)后，从中读取对端的用于媒体流传送的IP地址和将用于本次呼叫接收媒体流的逻辑通道号。在远端的被叫用户摘机后，在相应媒体流IP地址和对应的逻辑通道上实现语音交换。
    如果IPCB收到一个来自IP网络侧的呼叫连接请求，则表明是远端用户呼叫Channel Bank上的用户，于是，VoIP网关将分别读取被叫电话号码、对端用于媒体流通信的IP地址和接收本次通话媒体流的逻辑通道号。然后，查寻中继时隙通道号与逻辑电话号码的映射表，获取该逻辑电话号码对应的中继号和物理时隙通道号，检测该被叫用户的忙闲状态。如果该用户空闲，则向网络侧的远端用户发回响应消息，告诉远端，本网关用于媒体流通信的IP地址和用于接收对端媒体流的逻辑通道号，在用户摘机后实现媒体流的交换。
4.3.3 呼叫的接入和接出控制?
    一个具有商业实用价值的IP电话系统必须能对呼叫的接入和接出进行控制，并且在通话结束之后，能将通话的时长通过网守告诉计费系统，从而实现对通话的控制和费用的结算。
    当Channel Bank上的用户发起呼叫时，网关通过呼叫所处的通道号来获取它的逻辑电话号码，然后经网守到数据库对主叫用户的身份及其拨打权限进行认证。如果主叫为合法用户时，查询被叫地是否在用户允许拨打的权限范围内，确定是否为其接续。
    当远端的呼叫到来时，网关要到网守对主叫网关的合法性进行认证。如果认证通过，网关通过查询地址映射表来[FL(2K2]判断被叫是否为本Channel Bank 上的用户。如果不是，则释放呼叫，否则，返回该号码所对应的时隙通道号。网关查询该通道的状态，若被叫空闲，接续此次呼叫，否则，拒绝该呼叫。上述控制流程如图5所示。

5 IPCB的实现结果
    IPCB的硬件设备如图6所示。在Channel Bank的24个端口中任选两个和电话相连。选用其中一部电话作为主叫，如果被叫也是Channel Bank上的用户，则会听到Channel Bank上的另一部电话振铃，摘机后，就可以进行正常的语音通信，语音编码方式选用G.711。同样，Channel Bank上的电话也可以和远端的电话进行通信，语音编码方式选用G.723。IPCB可以为用户提供语音交互，对于卡号用户，IPCB还支持密码修改、话费查询等业务。?
    目前已经将IPCB 网关放到一个已投入正常使用的IP电话系统中进行了实现并通过了测试。在测试中，呼叫接通率在90%以上，采用MFR2信令时，平均呼叫建立时间小于5s，端到端的时延在200ms-300ms之间。可以看出，IPCB工作正常、性能稳定。

6 结束语
    本文提出了一种基于Channel Bank和VoIP语音网关的大客户语音接入IP网络的IPCB方案，对IPCB的体系结构、基本功能和设计原理进行了系统的论述，并在此基础上进行了实际的开发。该方案的主要特点在于：(1) 能很好地实现大客户语音业务到IP网的接入；(2) 大客户内部的语音通信通过软交换来实现，从而去掉了对具有交换模块的PBX的需求；（3）系统的扩容可以通过多个Channel Bank的简单堆叠来实现；(4) 采用硬件进行数据的压缩和解压，处理更加高速有效。实际运行结果表明，该方案切实可行。因此，基于Channel Bank和IP语音网关构成IPCB的体系结构，为大客户的话音业务接入到IP网提供了一种新的解决方案。

参考文献?

1 叶华，谢玮，梁勇，崔进水. IP电话/传真技术. 北京：人民邮电出版社, 2000
2 李鲁湘，宋健. VoIP的新热点—IPPBX. 通讯世界, 2000(10)
3 ITU-T Recommendation H.323. Audiovisual and Mul-timedia Systems.1996