5）利用開源軟交換來開發(fā)SBC

利用開源平臺開發(fā)SBC圖例

　　目前市場上主流的SBC 設備廠家相對來說技術(shù)實力比較強，同時對底層設備架構(gòu)性能有充分的了解。硬件設備相對穩(wěn)定一些。但是目前很多開源的軟交換也具備SBC的某些功能，例如openSIPS， kamailio 或者FreeSWICTH。這些平臺本身具有注冊，路由，NAT處理的能力，但是首先這些軟交換平臺基本都不具有編碼轉(zhuǎn)換處理的能力，本身沒有對編碼的處理，只能對SIP消息做規(guī)范化處理，其次，幾個平臺對接的技術(shù)難度很高，維護成本高，所以只能部分實現(xiàn)SBC功能。如果需要對編碼轉(zhuǎn)換進行處理的話，必須借助第三方DSP處理或者軟轉(zhuǎn)碼，目前類似的算法基本上都需要通過購買商業(yè)許可證來實現(xiàn)。所以嚴格意義上這樣的架構(gòu)并不是SBC的標準設備。

　　6）SBC 部署類型 目前SBC部署支持兩種形式：

　　6.1）設備類型。設備類型支持企業(yè)級和運營商級的部署，從400路到2000路以上，或者更高級別的處理。

SBC 在企業(yè)語音業(yè)務中的應用拓撲圖

　　6.2）VMware 平臺安裝部署eSBC。這樣的方式適合于中小型企業(yè)的IPPBX對接，SIP中繼對接或者企業(yè)融合通信的管理。SBC 是以軟件形式安裝在企業(yè)內(nèi)部的虛擬機上，可以根據(jù)不同配置來支持編碼轉(zhuǎn)換，另外一個軟編碼的局限性在于支持的編碼類型非常有限，而且市場上編碼類型又不斷豐富。編碼轉(zhuǎn)換的處理包括軟件形式的，很多廠家都有自己的算法，但是并發(fā)數(shù)量和虛擬機的性能有嚴格的要求，同時支持的編碼類型非常有限。Sangoma 的eSBC 則通過外置的編碼DSP設備處理，通過IP對接，來對RTP流進行處理。這樣保證了處理能力，可以根據(jù)企業(yè)用戶的增加適當拓展并發(fā)數(shù)量，調(diào)整編碼轉(zhuǎn)換設備的容量。用戶通過ESBC 對接基于云的IPPBX，例如可以部署IPPBX在阿里云，亞馬遜云，百度云，然后在本地進行編碼處理。

SBC 在AWS云平臺部署圖例

　　7）SBC 在VoIP環(huán)境中主要面對的挑戰(zhàn)

　　VoIP的技術(shù)日新月異，筆者不敢輕易斷定網(wǎng)絡會有什么不可預知的問題。當然，以目前的技術(shù)水平和網(wǎng)絡環(huán)境來看，無論是什么樣的設備，什么樣的功能，面對的一個主要問題就是網(wǎng)絡的穩(wěn)定性問題，用戶網(wǎng)絡環(huán)境復雜等等問題。這些問題通常是廠家不可預知的問題。這些也都是VoIP環(huán)境一直面對的難題。比較好的解決辦法就是設備端必須支持完善的排查工具，包括QOS，SIP消息，語音抓包等等工具，用戶可以輕松檢查出問題所在，能夠快速解決問題，或者反饋問題。

　　總結(jié)，從我們介紹的以上內(nèi)容中我們不難看出，SBC設備是目前VoIP網(wǎng)絡環(huán)境中最為可靠的解決方案，具有對SIP完整的支持，同時解決了安全問題。一句話，SBC 就是為SIP所生！

　　參考資料：

　　1）http://wiki.sangoma.com/NetBorder-Session-Controller
　　2）http://www.dummies.com/
　　3）http://en.wikipedia.org/wiki/Session_border_controller
　　4）http://en.wikipedia.org/wiki/Back-to-back_user_agent
　　5）http://blogs.trilogy-lte.com/post/77427158750/how-webrtc-is-revolutionizing-telephony
　　6）http://www.frafos.com/wp-content/uploads/2012/10/FRAFOS_Underdstanding_SBC.pdf