經常有人問我,老李,Kamailio/OpenSIPS和FreeSWITCH之間有什麼區別?嗯 ,這個一句話兩句話還真講不清楚.現在我們就按發展歷史、功能性、平臺支援性等來論述!
前提是我們需要知道SIP伺服器的型別,典型是以下幾類:
a. 註冊伺服器 -即只管Register訊息,這裡相當於location也在這裡了
b. 重定向伺服器 -給ua回一條302後,轉給其它的伺服器,這樣保證全系統統一接入
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的模組列表
B.2 Kamailio的模組列表
B.3 OpenSIPS和Kamailio的區別
一定要區分一個好用的，在這裡應是沒辦法區分，因為它們的定位都在rtp proxy,而且都源於OpenSER，如果一定要做個對比，我們可以把Kamailio定位於類似Debian，OpenSIPS定位於CentOS。
在基礎功能上，兩者區別不大，按原始碼結構來看，Kamailio實現了大量的IMS相關的，而且有不少app_x等使用其它程式語言來控制流程的部分，假設使用lua，那麼只要在kamailio.cfg中配置
#!ifdef WITH_CFGLUAloadmodule "app_lua.so"#!endif呼叫
#!ifdef WITH_CFGLUAmodparam("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:[email protected]