现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

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

2020-03-14 14:56 工业·编程 ⁄ 共 4569字 ⁄ 字号 暂无评论

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或rpt engine做对接

b. Kamailio/OpenSIPS的不同处

  b.1 OpenSIPS的模块列表 wps1   b.2 Kamailio的模块列表 wps2  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的模块列表

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

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

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

wps6 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

给我留言

留言无头像?