2024年5月15日发(作者：r7 5800h相当于i7几代)

基于FreeSwitch和DSP的多媒体会议系统的设计与实现

胡建洲;田裕鹏

【摘 要】多媒体会议系统的出现有效地提高了人们的沟通效率.传统采用纯硬件的多

媒体会议系统,由于价格昂贵,维护困难,让很多企业都望而却步;而单纯以软件构建的多媒体

会议系统又由于对通用处理器能力要求过高、音视频效果不佳等原因,无法满足企业对高

质量多媒体会议的需求.针对这一现实需求,设计一种以FreeSwitch为软交换平台,以SIP

协议为信令协议,并外扩DSP来分离处理媒体,软硬件相结合的多媒体会议系统.实践表明

该系统能够满足当前对多媒体会议系统的需求.%The emergence of multimedia

conference system effectively improved the communication efficiency between

to high cost and difficult in maintenance,quite a few companies flinch

from traditional multimedia conference system purely using the

hardware;however the multimedia conference system built with pure software

also can hardly meet the demands of enterprises in high quality multimedia

conferencing because of too high requirement in capacity of the general-purpose

processor and poor audio and video view of this practical

need,we design a multimedia conference system integrating both the software

and hardware,it uses FreeSwitch as the soft switching platform,SIP protocol as the

signaling protocol,and extends DSP to separate and process the ce

proves that the system can meet the current demands on multimedia conference

system.

【期刊名称】《计算机应用与软件》

【年(卷),期】2013(030)008

【总页数】4页(P263-266)

【关键词】VoIP;FreeSwitch;SIP协议;DSP;多媒体会议系统

【作 者】胡建洲;田裕鹏

【作者单位】南京航空航天大学自动化学院 江苏南京210016;南京航空航天大学自

动化学院 江苏南京210016

【正文语种】中 文

【中图分类】TP311

多媒体会议系统是一种让身处异地的人们通过某种传输介质实现“实时、可视、交互”

的多媒体通信技术。它可以通过现有的各种电气通讯传输媒体，将人物的静态／动态图像、

语音、文字、图片等多种信息分送到各个用户的终端设备上，使得在地理上分散的用户可

以通过图形、声音等多种方式交流信息。多媒体会议系统是传统电信网络提供的一类重要

的电信业务。随着因特网的迅猛发展，如何在IP网络上开展多媒体会议成为一个重要的

研究课题［1，2］。而开源项目在通信领域不断涌现，打破了传统电信设备制造商对电

信技术的垄断，推动了下一代网络技术（NGN）的迅速发展。其中，FreeSwitch就是构

建多媒体会议系统的一个典型代表。这里以FreeSwitch为主要开发平台是因为相比

Asterisk等同类VoIP软交换平台，它在相同的硬件配置下支持更多的会话连接，并且

Asterisk用动态链表来管理每个打开的通道，这样使它在多线程中非常不便于管理（需要

频繁的锁定和解锁）。而FreeSwitch每个呼叫通道都会用一个线程来管理呼叫状态，大

大降低了死锁发生的几率。最后FreeSwitch支持多种操作系统，而Asterisk只支持

Linux／Unix。SIP是由IETF MMUSIC工作组定义的一种多媒体通信控制协议［3－5］。

SIP协议由于推出得比较晚，而且是根据IP电话网上已经存在的问题来开发的新的协议，

因此它有更多的灵活性，它是基于文本的应用层协议，可以综合语音、数据和视频业务，

支持终端能力检测、唯一号码、在线检测、呼叫处理和多用户会议等功能［6］。因此这

里采用SIP协议作为信令协议。

多媒体会议系统除了需要处理上述控制信令之外，另一个重要功能就是处理媒体信息；

在纷繁复杂的终端时代，一个成功的网络会议系统势必需要处理各个终端之间的视音频转

码、回声消除、网络抖动、丢包补偿等特色功能；为了降低通用处理器的媒体处理负荷，

设计采用低功耗、高性能的DSP来完成媒体面工作，以此提高整个系统的鲁棒性、并发

性和服务质量。本文基于以上分析，选择FreeSwitch＋DSP来构建多媒体会议系统。

本多媒体会议系统结构系统主要由FreeSwitch构成VoIP服务器，FreeSwitch选用

SIP协议作为信令协议，完成注册、代理、重定向等功能。由专门的多核DSP构成多媒

体网关，进行媒体的处理。终端设备形式多样，可以是支持语音视频功能的IPphone，

也可以是运行在个人PC机上的SoftPhone，甚至是移动电话等。它们的共同特征是都支

持SIP协议，整个系统用IP网络连接而成。系统的整体结构如图1所示。

1．1 FreeSwitch性能介绍与可扩展结构分析

FreeSwitch是一个开源的VoIP交换平台，具有很强的伸缩性，从简单的软电话客户

端到运营商级的软交换设备几乎无所不能。能够原生地运行于Windows、Max OS X、

Linux、BSD及Solaris等32／64位平台。并支持SIP、H323、Skype、Google Talk

等协议，并能很容易地与各种开源的PBX系统如SipXecs、Call Weaver、Bayonne、

YATE及Asterisk等通信［7］。

本文多媒体会议系统需要自己编写Codec Module，用于Code在FreeSwitch中的

处理。该模块通过动态加载的方式实现。因此需要对FreeSwitch结构以及模块动态加载

过程进行了解。现对它进行简单的说明。

FreeSwitch在结构设计上可分为FS CORE和外围动态可加载模块两部分，其中FS

CORE和外围模块通过Public API进行通信，FS CORE最终被编译为静态库，和由

freeswitch.c编译生成的启动模块链接为可执行程序。FS CORE的主要功能是利用APR

库来完成内存管理／线程管理功能，实现动态模块库（mod）的加载／卸载管理，呼叫

控制及Session的管理，对Event事件／日志／NAT／Config／数据库存储等基本管理

能力。

外围模块是FreeSwitch可伸缩性的具体体现，模块具体形式为mod_xxx。每个

mod被加载后可以提供相应的API或APP，使得FreeSwitch的功能得到扩展。

FreeSwitch动态实现加载模块的方式如图2所示。

1．2 SIP协议在FreeSwitch中的实现

SIP协议是多媒体会议系统的信令协议，是多媒体会议进行会话的基础。SIP模块在

FreeSwitch中是通过加载mod_（Linux环境下）来实现的。而Sofia-SIP是诺

基亚公司开发的开源的SIP协议栈。Sofia-SIP遵循RFC3261标准，它在FreeSwitch中

的会话流程如图3所示。

如图3所示，首先UA2（User Agent 2）向FreeSwitch内的SIP （Sofia-SIP）模

块发出Invite请求，该请求带有SDP（Session Description Protocol）［8］媒体信息，

SIP收到该请求后首先会根据SDP信息准备媒体，然后利用nua_i_invite函数向已经在

SIP注册过UA1（User Agent 1）发出请求，接着SIP会回100 Trying信息给UA2，表

示已经处于请求状态。如果此时UA1已经准备就绪，就会开始振铃，同时UA2也会收到

UA1已经振铃的回铃音，当UA1摘机后，就会通过nua_respond函数回复200 OK，

该回复中带有UA1的SDP信息，接下来就是媒体激活，包括媒体选择等过程。之后通过

确认消息，表明UA2已收到UA1对Invite请求的最终响应。接下来就是传输媒体的过程，

此时UA1与UA2可以进行通话了。最后当任何一方挂机时，该方就会发送一个Bye的

请求给服务器，SIP服务器响应请求后就会通知另一方，通过回复200 OK结束本次通话。

2.1 会议桥的实现

FreeSwitch会议桥是利用其自带的mod_conference模块来实现的，该会议桥采用

的是松散的多播会议框架进行数据的发送。在理论上对参与者的数量不设上限。进入会议

者的拨号规则通过／conf／dialplan中的配置文件进行配置，而与会议相关的参数通过

conf／autoload_configs／进行配置。除此之外，为了满足对视频

的需求，还需要在中对codec_prefs参数进行配置，其余可以参照默认的配置

方法。如果需要设置会议的具体操作流程可以对mod_conference进行个性化配置。

2．2 Codec Module的实现

模块是通过FreeSwitch动态加载功能实现的。该模块主要由以下几个函数构成：

模块的工作流程是首先利用switch_codec_init函数接收FreeSwitch媒体请求并对

相关参数进行初始化，其中媒体请求中包括flags消息、encode、decode等媒体信息。

然后根据flags信息选择是encode还是decode。如果是encode，则将利用

switch_codec_encode函数进行处理，如果是decode，则用switch_ codec_decode

函数来进行处理。在处理过程中Codec Module会把FreeSwitch服务器的IP、PORT、

转码的Codec类型等信息打包后通过UDP通信功能模块发送给DSP，如果此时DSP处

于就绪状态，Codec Module就会收到DSP的IP、PORT等信息。根据这些信息模块就

能通过FreeSwitch自带的API函数建立RTP Session，通过该Session FreeSwitch与

DSP就可以直接进行媒体交互了。在媒体交互过程中encode或decode函数会对收到

的媒体进行校验，以提高信息的可靠性。当任务已经完成，而Codec Module又没有收

到新请求的情况下，模块就会启动switch_ codec_destroy函数，以便释放资源，初始化

相关设置，为下一次的请求做好准备。

2．3 UDP通信模块的实现

UDP通信模块具有很强的扩展性，可以实现多个FreeSwitch服务器和DSP的级联。

该模块分UDP Client和UDP Server两个部分，由UDP建立连接，UDP Client存在于

FreeSwitch服务器上，用来接收Codec Module的请求，并将该请求信息封装发送给

UDP Server。UDP Server主要用于接收处理UDP Client发送的信息。并通过DSP API

建立和DSP的连接。把从UDP Client收到的信息发送给DSP。在得到DSP的响应之后，

调配DSP的资源，最终实现DSP与FreeSwitch服务器的RTP互通。具体过程如图4所

示。

为保证信息传输的高效性，选用了UDP的连接方式。但是众所周知，UDP是一种不

可靠的网络协议。因此为了兼顾传输的可靠性和高效性，实现UDP在无连接情况下的可

靠传输，保证不丢包、不收错包。我们在应用层对程序进行了必要设计，以实现对差错报

文的证实机制、重发机制。相关机制是在UDP Client发送报文上加上一段特殊的标记字

符串，UDP Server收到该字符串后进行比对，如果正确，UDP Server就回复一个相应

的UDP包，表示确认正确。如果收到了错误信息或者没有收到信息，则UDP Client会

因为在规定时间内没有收到确认的UDP包而对信息进行重发。并且在UDP Client中规

定了最多重发次数，超过该次数。不再进行发送，显示发送失败。该机制有效提高了接收

报文的准确性，提高了系统的容错性。

应用中发现如果FreeSwitch服务器长时间不发送数据，一段时间，大概几分钟以后，

UDP Server就接收不到UDP Client发来的数据了，分析后发现这是由于UDP存在一个

保活时间，而这个时间长度是由设备本身属性、设备的连接方式等多种因素共同作用而成

的。所以为了提高系统的可靠性稳定，该通信模块采用了相应的定时保活机制，采取的措

施是在UDP Server中加入相应的心跳程序，设定每隔一定时间发送一个小的报文通知

UDP Client自己的存在。保证了UDP Client与UDP Server的互通。

2．4 DSP多媒体处理模块的实现

DSP多媒体处理模块通过DSP API与UDP Server进行对接。DSP支持多种常用的

IP协议栈和传输协议。同时针对语音视频在传输过程中的干扰，特别添加了最小二乘自适

应滤波、比特速率适配、帧速率自适应等多种针对性的算法，提高了媒体的质量。为了克

服传统总线无法连接太多设备，导致总线扩展性差，并且容易在线间干扰等缺陷，采用了

PCIE总线接口形式。DSP具体功能特点如图5所示。

DSP处理来自FreeSwitch的媒体，主要是语音和视频媒体。处理视频的主要流程这

里以H263＜＝＞H26为例进行说明。首先是FreeSwitch建立RTP（Real-time

Transport Protocol）［9］Session。此时FreeSwitch开始接收H263编码，并将该编

码通过透传的方式发送给DSP。DSP建立H263＜＝＞H26的转码通道。经过相关处理，

把H264编码发送给FreeSwitch。这样一次视频编码处理流程结束。处理语音编码相对

处理视频编码要复杂一些。现在以Gsm＜＝＞G723为例来说明，当FreeSwitch建立

RTP Session以后，DSP首先会建立Gsm＜＝＞Linear转码通道，当FreeSwitch收到

Linear后，经过相应处理，再转发给DSP，这时DSP就会建立Linear＜＝＞G723的转

码通道，向FreeSwitch发送G723编码。FreeSwitch把G723编码发送给终端。这样一

次语音转码结束，特别要说明的是，与视频编码不同处理的是这里首先要把语音编码转变

成Linear编码，这是因为FreeSwitch本身支持Linear编码，所以为了保持FreeSwitch

对语音编码的控制处理能力，有必要向FreeSwitch转发Linear编码。处理语音编码

Gsm＜＝＞G723具体流程如图6所示。

3.1 环境的搭建

FreeSwitch安装于Linux CentOS release 6.2系统中。编译UDP Client生成以供

Codec Module调用的动态库，将其放在usr／lib路径下面。动态加载模块Codec

Module于FreeSwitch中。将UDP Server运行于同一网络环境下的任意机器上。把

DSP同样置于该网络下。同时准备几台有摄像头的PC机，用于运行带视频功能的

SoftPhone。也可以用支持视频通话的IP-phone代替SoftPhone，把这些终端同样运行

于该网络下。网络可以用一个小型交换机组建局域网。最好能使不同类型的终端成员达到

三方以上。这样有利于提高会议系统测试的准确性。

3.2 测 试

首先把准备好的SoftPhone IPphone注册到FreeSwitch上，同时检查选择的语音

视频编码是不是Codec Moudle所支持的编码。然后配置UDP Client的Server IP地址，

以保持与UDP Server的互通。保证DSP的开启，然后拨打默认的会议号3000，就能进

入会议了。进入会议后的具体操作可以参看conference. 中的相关配置。

客户端进入3000会议时的SIP信令用wireshark抓包分析如图7所示。

从图7中可以看到终端的IP地址分别为192.168.1.106，192.168.1.109。

FreeSwitch服务器IP地址为192.168.1.105。SIP信令占用的是5060端口。终端注册

进入会议主要包括请求INVITE，服务器响应100 Trying，服务器许可200 Ok。最后服

务器把带有XML配置的信息发给终端。来执行会议配置。至此，该终端顺利进入会议。

现选用多个支持视频的终端设备进行视频会议测试，测试中直观感受语音通话清楚流

畅，视频图像清晰连贯，在当前测试网络条件下用wireshark抓包统计，丢包率0%，延

时小于37ms，抖动在－5ms到7ms之间。相关指标达到了普通纯硬件会议系统并且要

优于普通纯软件会议系统。达到了设计目的。图8是其中一个会议终端在进行视频会议时

的截图。

本文基于FreeSwitch软交换软件和专业多媒体DSP设计了一套结构简单、可扩展能

力强的多媒体会议系统。该系统通过SIP协议进行信令交互，mod_conference作为会

议桥，在FreeSwitch中实现codec模块和UDP Client，在客户端中实现UDP Server，

实现了FreeSwitch和DSP的交互。为像视频会议这种占用大量资源，而影响服务器正常

工作的情况，提出了一种解决方案。该套系统与单纯硬件构成的多媒体会议系统相比在价

格上具有明显的优势，而在性能上该系统在可重构性、易维护升级上也具有比较大的优势。

同样相比较于用纯软件搭建的多媒体会议系统，在媒体质量上也有不可比拟的优势。当然

该多媒体会议系统只是基本达到了实现多方多媒体通信的要求，在会议控制、会议记录等

方面还需对系统做进一步的完善。使其更加符合会议的特点和功能。

【相关文献】

［1］Rosenberg J.A Framework for Conferencing with the Session Initiation

Protocol［S］.IETF Internet Draft，2003.

［2］Karapantazis S，Pavlidou ：A Comprehensive Survey on

Promising Technology［J］.Computer Networks，2009，53（12）：2050-2090.

［3］魏强，苏森，陈俊亮.基于SIP的集中式多媒体会议系统的研究［J］.计算机工

程与应用，2004（14）.

［4］Rosenberg J，Schulzrinne H，et ：Session Initiation Protocol［S］.

IETF RFC 3261，2002.

［5］Asterisk：电话未来之路CHN 2.0［EB／OL］.［2006］.http：／／

.

［6］罗斯青.H.323和SIP的比较［J］.通讯世界，2002（5）：60-62.

［7］Anthony Minessale，Michael S Collins，Darren ITCH-

106-eBook［M］.2010：23-25.

［8］Handley M，Jacboson V，et ：Session Description Protocol［S］.

IETF RFC 2327，1998.

［9］Schulzrinne H，et ：A Transport Protocol for Real-Time

Applications［S］.IETF RFC 1889，1996.