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
ag真人视讯腾讯微博 双色球50人合买 浙江体彩6+1中奖查询 11选5大玩家 比分直播188直 波场币官网波场币交易平台app 手机棋牌麻将辅助器 双色球复式139开奖结果 ag视讯是骗局吗 体彩顶呱刮兑奖 广西快乐10分彩票控 吉林11选5彩票网 浙江11选5专家推荐 百度理财官方网址 扑克麻将千术揭秘 双色球号码预测图表 重庆时时彩官网开奖结果记录