1. OpenSER(OpenSIPS/Kamailio) 和FreeSWITCH间的区别:
  2. 宁卫通信
  3. 新闻动态
  4. 宁卫新闻
  5. OpenSER(OpenSIPS/Kamailio) 和FreeSWITCH间的区别

OpenSER(OpenSIPS/Kamailio) 和FreeSWITCH间的区别

       经常有人问我,老李,Kamailio/OpenSIPS和FreeSWITCH之间有什么区别?嗯 ,这个一句话两句话还真讲不清楚.现在我们就按发展历史、功能性、平台支持性等来论述!


      前提是我们需要知道SIP服务器的类型,典型是以下几类:


a. 注册服务器 -即只管Register消息,这里相当于location也在这里了


b. 重定向服务器 -给ua回一条302后,转给其它的服务器,这样保证全系统统一接入


c. 代理服务器 -只做proxy,即对SIP消息转发


d. 媒体服务器-只做rtp包相关处理,即media server


e. B2BUA - 这个里包实际一般是可以含以上几种服务器类型


一. 发展历史


1. Kamailio/OpenSIPS的发展


      提到这俩兄弟,就不得不提OpenSER这个SIP代理服务器,这个项目起源于2001年左右的德国的FhG FOKUS研究所,SER就是Sip Express Router.然后基于GPL协议开源了.但是在2005年开始,完全为了开源的理想而奋斗的人们终究抵挡不了个性差异,经济压力差异,产品发展等差异,所以离开的离开,改行的改行.当然能这样坚持的都真的是真爱,如果在中国,在中国高房价的压迫下,也许这两家都成了比较大规模的公司了.


      到了2008年应是标志着OpenSER的完全被分家了,一家叫Kamailio,另一家OpenSIPS,当然应还有其它昙花一现的fork,但现在流传的就是Kamailio和OpenSIPS两位大哥的传说.Kamailio说自己是最正宗的OpenSER的儿子,OpenSIPS就说,你是私生子,连姓都改了,我虽是养子,但我好歹名字和老爹OpenSER有点像.这些都只是开玩笑,只是为了说明Kamailio和OpenSIPS都说自己正宗,也都有自己一个小团队在维护代码和发展着业务及技术.具体差异后续再说.


2. FreeSWITCH的发展


      这个产品的发展,在于安东尼老哥最早参与了Asterisk这个开源B2BUA,但因为Asterisk采用单线程模式处理逻辑,以及其它一些性能及功能的考量,安东尼老哥和Asterisk分道扬镳,然后完全从头开始打造FreeSWITCH,而FreeSWITCH1.0.6发布了以后,开始用户数量上升,一直到尽几年,面向语音层的应用越来越广泛,比如门禁/智能客服/智能外呼/智能质检/座席辅助/回铃检测等面向语音媒体多样化的需求,以及webrtc/视频等需求增加,所以FreeSWITCH面向的应用应该说更宽.


二. 功能性差异


1. Kamailio/OpenSIPS


a. Kamailio/OpenSIPS的共通部分


都是SIP Proxy


都源于SER爸爸


都支持和第三方的rtp proxy或rtp engine做对接


b. Kamailio/OpenSIPS的不同处


B.1 OpenSIPS的模块列表

B.2 Kamailio的模块列表

B.3 OpenSIPS和Kamailio的区别


      一定要区分一个好用的,在这里应是没办法区分,因为它们的定位都在rtp proxy,而且都源于OpenSER,如果一定要做个对比,我们可以把Kamailio定位于类似Debian,OpenSIPS定位于CentOS。


      在基础功能上,两者区别不大,按源代码结构来看,Kamailio实现了大量的IMS相关的,而且有不少app_x等使用其它编程语言来控制流程的部分,假设使用lua,那么只要在kamailio.cfg中配置


     #!ifdef WITH_CFGLUA
     loadmodule "app_lua.so"
     #!endif
 
调用


    #!ifdef WITH_CFGLUA
    modparam("app_lua", "load", "/usr/local/etc/kamailio/kamailio_script.lua")
    cfgengine "lua"
    #!endif

然后就在lua中实现它的逻辑处理,这点上kamailio是考虑到了专业人士对业务复杂性的需求,但由于大量的基础人员也会采用这种方式,又有可能带来一些不可控的问题产生。


      而OpensSIPS则在代码中,做了不少的cachedb_x,用以提高基于数据库查询的性能,同时官方有个freeswitch、freeswitch_scripting模块用来和FreeSWITCH进行深层次的、快速的对接。当然最新版本(2020-3)的版本中也有个beta模块-lua,用于调用lua脚本,调用方式类如:


    modparam("lua", "luafilename", "/etc/opensips/opensips.lua")

但实际上目前来说,opensips.cfg才是路由配置的主体。


      按以上所讲,在各自版本的发展上,两者其实有所不同,但基本的根源在那里,而且作为小众产品,要完全做出新的突破都不容易,大家还是平常心看待它们,在功能选择和自己对名字的爱好、操作的便利性等选自己想用的即可,从实际应用中,区别不是太大,特别是只是使用它作为SIP Proxy的情况下。


2. OpenSER和FreeSWITCH


a. OpenSER和FreeSWITCH共通性


都支持标准SIP


都有register server和location server


都能作为独立的sip server为用户提供基本的session管理。


b. OpenSER和FreeSWITCH的不同处


b.1 FreeSWITCH的模块列表



看上去是不是很少?别慌!仔细看,它不是具体的模块,只是对模块进行了分类。如:application


 
而对于终端的支持,现在FreeSWITCH理论上是支持多种协议,如:endpoints



还有丰富的媒体应用,如:asr_tts


 
b.2 OpenSER和FreeSWITCH的区别


b.2.1 信令的处理


      一般的朋友可能对这块不是太理解,但实际上,这块在具体的使用中影响也挺大的,OpenSER系列是自己开发的sip协议栈,优点是简单些,效率高,可控性更高。而FreeSWITCH的sip协议栈是sofia的,这个协议栈是由nokia公司为主体实现的,当时应对标的是radvision这个协议栈,但后来也就那样了。但是sofia协议栈有个问题,是单一线程处理,所以在当前的主流cpu框架下跑在linux上,sofia在特大并发下处理性能低于OpenSER系列。


      而且由于在FreeSWITCH上绑定的东西实在太多,同时由于FreeSWITCH是B2BUA,所以要维护的状态机太复杂,所以在FreeSWITCH对信令的修改是一个头疼的事,当然一般情况下也没必要去修改它的信令。而在OpenSER系列中,有一堆的内核变量如$du、$hdr等进行信令的修改。


      所以说,在信令的处理上,OpenSER更灵活、也更易处理,而FreeSWITCH相对僵硬、不易处理。


b.2.2 媒体的处理


      这里所讲的媒体是语音或视频流,和其它理解的媒体无关。


      之前陆陆续续讲了不少媒体这个内容,但具体到我们OpenSER和FreeSWITCH中来说,FreeSWITCH的媒体处理是非常强的,特别是它的media_bug能力是笔者看过或用过的系统中最便捷和最易使用的系统,没有之一。具体来说:


      OpenSER是依赖第三方的rtp proxy和rtpengine实际媒体的交换,要么就是两个终端间p2p直接交换,所以在这点上来说,如果是做视频对话,那么OpenSER还是比FreeSWITCH做视频交换要顺畅,因为rtp proxy是直接转发,不用进行转换。所有ip化的东西我们都认为是有损压缩过的,即使是视频yuv,音频pcm都有损,因为模数转换时,已有了差异。


      FreeSWITCH是自己有自己的一堆rtp支撑,所以在音视频通信、转码等远比OpenSER有优势。所以FreeSWITCH对729、723、736、729、711、silk、opus等音频编码,H263、H264、VP8、VP9等视频编码以及其它一些私有媒体的转换,添加一个codec的复杂度远低于去改造rtp proxy。同时由于media bug的存在,可以在在刚通话时做回铃检测、可以在通话过程中把媒体按照mrcp协议送给媒体资源控制协议支持的一些服务(ASR/TTS)等,也可以把语音流获取到后,进行实时质检、以及更多的私有化处理。


      正是由于媒体处理的强大能力,所以FreeSWITCH才成为了做各类企业或个人应用的首选。比如呼叫中心、智能客服、智能外呼、座席助手等。


b.2.3 业务逻辑的处理


      以上两点描述了它在基本面的不同,这点来讲讲使用这些产品做业务的话,它们对于业务逻辑的处理上的不同。


      OpenSER有Management Interafce(MI)来进行管理,但由于它面向的业务单一性,即proxy,所以一般来说,对MI调用的话,都是一些简单管理。反而是大量的呼叫性管理,都是其.cfg文件中或扩展的应用中实现,但万变不离其宗,使用OpenSER时,对一般应用来说,就是配置好cfg等后,做基本维护就可以了。


      FreeSWITCH自带一个fs_cli用于一些日常的监控和维护,但是因为FreeSWITCH的用户属性-业务优先,所以它有个event_socket这个模块,简称为esl(event socket library)让用户以自己的业务需求,通过socket编程实现相应的处理,当然其还支持一堆的lua/python/perl等各语言的原生调用模块,所以FreeSWITCH相比OpenSER在业务管理中我个人认为是有很多优势。


三、平台支持性


1. OpenSER的平台支持性


      OpenSER是基于类Unix平台之上,和其核心代码有关,因为从一开始,设计OpenSER时就是采用unix api进行的开发,不论是文件、内存、传输等都是基于like unix的平台。后期改动的可能性也比较小,也就是说,它只能运行于unix/linux/macos/bsd等系统中。


2. FreeSWITCH的平台支持性


      FreeSWITCH在开始设计时,采用的apache开源组织的跨平台c语言库apr,以使得它在非like unix的系统中,特别是Windows也可以很好的使用FreeSWITCH的基本功能。但是要切记,在某些功能模块编译过程中,因为依赖了一些其它的开源库,而有些开源库并不一定对Windows支持得太好,所以很容易引起FreeSWITCH的内核崩溃,所以总体上来说,笔者建议使用者尽量用在linux上使用它,同时也建议通过编译源码来安装,而不是直接rpm或apt-get安装。


      到了这里,我们文章也结束了,总结一下吧。如果是面向的硬音视频业务,那么建议用户使用FreeSWITCH系列,因为它能良好地协助企业实现复杂的业务应用。而如果是用户量大,但只要简单地端对端音视频通信,那么可以采用OpenSER。如果是用户希望使用一个产品做信令负载分发,也建议使用OpenSER。


      由于笔者在业务场景及相关知识点的因素,不一定讲得全对,有意见请直接mail:lihao@nway.com.cn