语音软交换系统的设计与实现

来源：作者：出处：巧巧读书 2006-06-02 进入讨论组

访问地址 http://www.qqread.com/network-special/d572115181.html

江汉石油学院向亚林
西南财经大学向亚萍

【摘要】本文在分析VoIP应用的基础上，提出了一种在IP网上构建一个语音软交换中心的方案。首先简单介绍了系统的功能，其次给出了系统的总体结构，而后详细阐述了系统的软件实现，最后是使该系统实用化的后续开发要求。

关键词软交换，终端，呼叫ID，媒体流

【abstract】Theimplementationthatbuilding a voice softswitch center over IP network is given in this paper on basis of analyzing VoIP application. First, the basic function of the system is simply introduced. Secondly, the overall framework of the system is put forward. Thirdly, the software realization of the system is illustrated in detail. Finally, continuous developing requirement that making system practical is mentioned.

Keywords:softswitch,terminal,callingID, medium stream

1．引言：

在过去的5年，VoIP语音通信技术迅速发展，其业务量日益增长。但目前VoIP的通信模式主要是两种：第一，直接路由模式，源终端在获得目的终端的IP地址的情况下，直接向目的终端发起呼叫的通信方式；第二，经过网守转发的间接路由模式，通信双方所有的通信信令通过网守转发，而目的IP由网守通过地址解析来完成的通信方式。从本质上来讲，这两种方式都只是一种点对点的机制。这种点对点的机制仅适用于语音业务量较小的场合。

随着VoIP语音业务量的剧增，以上述两种方式进行通信将会变得越来越复杂，越来越需要在IP网络上构建一个语音软交换中心，来实现VoIP语音通信的路由选择和不同运营商IP网间语音交换的任务，从而实现网络语音软交换、呼叫控制和路由管理以及满足不同用户对通信质量的要求。同时为了满足与其它厂商设备之间的互通以及后续开发的需要，此系统的开发将遵照H.323协议。

2．系统功能简介

语音软交换系统主要用于解决IP网上两个IP终端之间媒体流（这里指语音流）的交换。这里的IP终端可能是网关、PC机或其它能够进行语音通信的终端。本系统应具有如下基本功能：

①系统具有基本的呼叫控制功能。

系统可与IP终端之间实现基本的呼叫的建立、维持和释放，实现的标准将完全按照H.323进行；

②系统可对终端提供多种认证功能。

③系统具有灵活的路由管理功能。

④系统对通话进行计时计费的功能。

3．系统总体结构

语音软交换系统按其功能可分为两个子系统：交换子系统和认证计费子系统，总体结构如图1所示。

交换子系统由4个模块组成：（1）呼叫处理和控制模块：当有呼叫产生时，对被叫电话号码进行地址解析获取被叫终端的信令IP地址；对呼叫进行接入认证和鉴权；进行接收媒体流的IP地址以及逻辑通道号的映射，完成媒体流的交换；（2）认证计费代理模块：接收呼叫处理和控制模块的认证、计费请求；将相关信息送到认证计费子系统进行认证和计费；将认证、计费结果返回给呼叫处理和控制模块；（3）地址解析模块：对呼叫的被叫号进行地址解析，确定路由；（4）H.323协议栈：完成网络层的协议通信，为应用层提供接口。

认证计费子系统由3个模块组成：(1)实时认证和计费模块；(2)数据库；(3)系统维护管理模块。

图1语音软交换系统的总体结构

4．系统的软件实现

系统的软件可分为软交换软件和认证计费软件，本文重点介绍软交换软件的实现。软交换软件的层次结构可分为三个层次，分别为操作系统、H.323协议栈和Radius协议、软交换应用软件。由于H.323协议栈向上层提供协议信令的收发、媒体流的打包\解包等应用函数接口，因此软交换软件的开发主要归结为软交换应用软件的开发。

4．1模块的划分及各模块的功能

软交换应用软件模块被分为五个部分，分别是呼叫处理与控制、地址解析、数据库代理、公共定时服务器、软交换系统人机界面。其结构如图2所示，各模块的主要功能如下：

呼叫处理与控制模块：与认证计费子系统一起完成呼叫接入认证；与路由数据模块一起，完成呼叫的地址解析；根据呼叫源端和目的端接收媒体流的IP地址和逻辑通道号，建立媒体流交换的逻辑通道的映射关系；根据呼叫媒体流逻辑通道的映射关系，进行媒体流的交换。

地址解析模块：根据呼叫处理与控制模块送来的被叫电话号码完成地址解析工作，返回该呼叫下车的目的终端IP地址；

共定时服务器模块：公共定时器的任务是为需要定时的多个任务统一提供定时。公共定时服务器采用客户/服务器方式，需要定时的任务向公共定时服务器发出定时请求，公共定时服务器在定时结束时向所请求的定时任务发送定时结束消息。

数据库代理：传送和接收接入认证请求与应答消息，以便数据库能根据在用户数据库存放的信息对接入的用户进行认证；传送和接收计费请求和应答消息，以便数据库能将通话的呼叫的详细记录写入计费数据库。

交换系统的人机界面：完成系统工作状态和话音通道信息的显示；路由数据的编辑、修改及加载；告警和故障信息的接收与显示。

图2软交换应用软件的模块划分

4．2实现方案

4．2．1呼叫控制的实现

系统的呼叫处理的过程是一个典型的在有限状态之间进行状态变迁的过程。呼叫处理可根据输入的呼叫信令消息和当前状态,完成相应的呼叫信令处理,确定变迁到达的新状态。因此,对于一个具体的呼叫,可以采用有限状态机(FiniteStateMachine,FSM)的方法来进行过程的描述和处理。

另一方面,在系统中会同时存在多个呼叫。呼叫处理必须考虑对并发呼叫的实时处理。鉴于传统的多进程处理并发事件的方式所存在的问题(呼叫越多,进程切换的开销越大,内存资源占用越多),在本系统中采用单呼叫进程实现多呼叫的并发处理。

在呼叫控制的实现中采用单呼叫进程设计方法：当一个呼叫产生时，进程生成一个记录该呼叫的呼叫FSM控制块，称为CCB（CallControlBlock）。呼叫FSM控制块记录了该呼叫的主叫号码、被叫号码和当前的状态等信息。因此，对于多个呼叫就产生与之对应的多个呼叫FSM控制块，进而组成一个呼叫FSM控制表。

当一个呼叫的信令到达时，呼叫处理进程基于主叫号码和被叫号码查找该呼叫对应的呼叫FSM控制块，然后可根据输入的呼叫信令和当前状态，完成相应的呼叫信令处理，确定变迁到达的新状态，并用迁移的新状态更新呼叫FSM控制块。

4．2．2解析和路由的实现

为了对不同的运营商的路由实施管理和控制，不同的运营商按不同的地址解析表解析。为此将呼叫的CallingID作为寻找对应解析表的索引，基本方法如下：首先设置三张数据表：①呼叫ID到解析表号映射表:用于查询用于该呼叫地址解析的解析表号；② 地址解析表: 用于将被叫号码转换为特定路由的映射表；③ 路由编号到IP地址的映射表: 用于根据路由编号查询该路由IP终端的IP地址，如表1-1 －表1-3所示。

表1-1ID到解析表号

映射表表1-2地址

解析表表1-3路由到IP

映射表

CallingIDNo.A_R Tabl E.164 No of rout No of rout IP address

Tokyo01381 5 1 X.X.X.X

Tokyo02386 2 2 210.74.139.59

Taiwan015886 4 3 X.X.X.X

Taiwan0251 4 4 203.160.248.66

……… … 5 211.4.249.121

… …

当系统收到源端发起的呼叫时，根据CallingID查询呼叫ID到解析表号映射表，获取对该呼叫进行地址解析的解析表的表号；然后，在对应的解析表中对被叫号码进行地址解析，获取该被叫号码对应的路由号；最后，根据该路由号码，查询路由编号到IP地址的映射表，获取呼叫下车IP终端的IP地址，从而完成了由被叫号码到IP地址的地址解析。

路由控制的基本思想是：对于来自不同运营商的呼叫，通过按呼叫的标识CallingID索引到相应的解析表，从而实现对不同运营商路由的管理和控制。对每一个有呼叫接入的运营商需配置一个解析表，因此系统会有若干张解析表，但只有一张路由表，这样便于对路由表进行统一的管理、维护。

4．2．3认证的实现

系统收到的呼叫可能来自不同运营商的源端，对不同源端呼叫的认证可能会是不同的内容。因此本系统应该能进行灵活的配置，根据不同的运营商的要求，认证不同的内容。为此本系统中应配置一张认证索引表，以CallingID为索引，配置认证的内容，如下表2所示：

表2认证内容索引表

CALLINGIDTYPEMATCH CONTENT ILLUSTRATION

Tokyo100-50-13-671: 认证MAC地址

Jingzhou2211.4.249.1232: 认证IP地址

Taiwan38883: 匹配被叫号码前缀

Yokohama4888+(00-60-22-28)4: 被叫号码前缀+MAC地址

Qingdao5888+(210.132.7.23)5: 被叫号码前缀+IP地址

当系统收到源端发来的Setup消息时，从Setup消息中提取CallingID，然后查找该索引表，获取相应的认证类型，然后从Setup消息中提取相应的对象和进行相应的运算，结果与表中的内容进行匹配，从而实现对主叫用户进行认证。在认证通过后，确认被叫号码是否在主叫用户的呼叫权限内，根据鉴权的结果确定是否为主叫用户进行交换和接续。

4．2．4媒体流交换转发的实现

软交换系统对被叫号码进行地址解析，获取目的终端的信令IP地址，在对收到的呼叫认证通，确认被叫号码在主叫终端的呼叫权限内之后，转入交换过程。具体步骤如下：

①系统从Setup消息中提取源端接收媒体流的IP地址和逻辑通道号，然后向源端发回Call-Proceeding消息，并在消息中告诉源端本系统用于接收源端媒体流的IP地址和逻辑通道号，同时向目的终端发起呼叫建立请求，并告诉目的终端本系统用于接收目的终端媒体流的IP地址和逻辑通道号，然后等待目的终端的应答消息。

②当收到目的终端的Call-Proceeding消息后，如果消息中携带了目的终端接收本软交换系统发送本呼叫媒体流的IP地址和逻辑通道号，则提取之，然后转入等待接收Alerting消息。

③当收到了目的终端的Alerting消息，如果消息中携带了目的终端接收系统发送本呼叫媒体流的IP地址和逻辑通道号，则提取之。然后向源端终端发送Alerting消息，并在此消息中再次携带本软交换系统用于接收源端媒体流的IP地址和逻辑通道号。

④根据呼叫源端、呼叫目的端和本软交换系统三方四个接收媒体流的IP地址和逻辑通道，建立煤体流交换的逻辑映射关系，进行媒体流包头路由信息的置换，从而实现媒体流的软交换，交换示意图如图3所示。

图3媒体流交换示意图

5．后续工作

本系统虽然实现了IP网上两个IP终端之间语音流的交换，并具有多种接入认证功能、灵活的路由管理功能、计时计费功能，但本系统还不是很成熟。要想使此系统成为一个完善、功能强大、具有商业价值的产品还有很多的工作需要改进：解决由于网络环境造成话音通信的时延过长的问题；实现异构网上终端之间媒体流的交换；网络管理功能的加强。

参考文献

1ITU-T Recommendation H.323.Packet based multimedia Communication Systems.[S],1998。

2糜正琨。IP网络电话技术[M]。北京：人民邮电出版社，2000。

3叶华，谢玮，梁勇，崔进水。IP电话/传真技术。北京:人民邮电出版社，2000。