在前面的關(guān)于SIP和NAT問題的講座中，我們花費了大量篇幅把整個關(guān)于SIP和NAT的各種問題做了比較全面和深入的探討，同時，我們也介紹了各種針對NAT的解決方案，但是那些方案僅解決了SIP在互聯(lián)網(wǎng)環(huán)境下的局部問題，也沒有考慮到整個企業(yè)IPPBX環(huán)境所要求的其他業(yè)務(wù)能力的支持。盡管那些解決方案在某些特定的環(huán)境中實現(xiàn)了某些用戶的要求，但是它們本身還是具有一定的局限性和針對性。SBC則比較好地解決了我們討論的問題，但是目前在市場上很少看到對SBC技術(shù)的全面介紹和剖析，很多公司的SBC介紹也僅局限于市場需求，使用了太多市場語言把SBC，很多描述可能有一些含糊不清，另外，一些相關(guān)的技術(shù)問題也缺乏更多詳細說明，用戶在了解和學習這些相關(guān)知識時會產(chǎn)生很多困擾。
筆者雖然在差不多6年前開始接觸SBC，這期間也多多少少接觸了一些客戶，基本上了解一些客戶對SBC的需求和目前存在的潛在問題。為了結(jié)合我們的SIP系列講座，筆者今天對SBC做一個比較全面的剖析，盡可能覆蓋大部分用戶所關(guān)心的問題，這樣可以幫助SBC用戶能夠比較全面地對SBC有一個概括。我們討論的范圍從SBC使用背景和由來，市場需求，使用場景和存在的問題進行一個基本梳理。筆者不會在這里討論過多某個SBC廠家的產(chǎn)品技術(shù)細節(jié)，如果特別需要可能會適當加入一點廠家的SBC內(nèi)容，幫助用戶理解SBC，否則讀者可能產(chǎn)生歧義。
筆者主要從幾個方面來剖析SBC的全貌，這些內(nèi)容包括：SBC的基本概念，SBC產(chǎn)生的背景原因，SBC的市場情況，SBC的核心功能，SBC運營商和企業(yè)客戶的使用場景，SBC的功能介紹，SBC錄音時的性能問題，SBC部署時的問題，SBC對SIP的流程的影響，SBC在IMS網(wǎng)絡(luò)中的角色，SBC虛擬化的可能性和基于開源解決方案等方面的內(nèi)容做一個全面的剖析（盡可能全面），幫助用戶全面了解SBC技術(shù)。
首先讓我們介紹一下SBC產(chǎn)生的背景。任何技術(shù)的產(chǎn)生都是基于一定的背景，只有客戶端需求越來越急迫的時候，一些對行業(yè)敏感的廠家就可能抓住機會來開發(fā)這樣的產(chǎn)品滿足消費者。舉個例子，故事的大概過程是這樣的。當年美國早期的淘金熱時，Lee牛仔褲的暢銷就是因為Lee的老板抓住了商機。當時西部淘金時礦工抱怨說為什么沒有一條結(jié)實一點的褲子，同時褲兜的地方老是開裂，Lee當年正好從事布匹的批發(fā)業(yè)務(wù)，他琢磨了半天，把當時做帆船的帆布經(jīng)過改造，結(jié)合褲子上打鉚釘?shù)膭?chuàng)意生產(chǎn)出了非常結(jié)實的牛仔褲。然后，Lee就開始在全世界大賣。這樣的例子數(shù)不勝數(shù)。VoIP的發(fā)展也是這樣，隨著VoIP的不斷發(fā)展，服務(wù)提供商不只提供一個簡單的語音通話的功能，在實際的VoIP運營環(huán)境中，SBC設(shè)備沒有真正部署或應(yīng)用之前，市場上沒有專門的設(shè)備為服務(wù)提供商和服務(wù)提供商自己實現(xiàn)完整的對接解決方案，同時也沒有一套完整的解決方案來實現(xiàn)運營商和終端客戶之間的對接支持。為了滿足運營商服務(wù)的要求，很多廠家開始研發(fā)SBC做為一個運營商邊界網(wǎng)絡(luò)的設(shè)備來支持運營商的需求。在典型的應(yīng)用環(huán)境中，SBC作為運營商VoIP網(wǎng)絡(luò)邊界的互聯(lián)設(shè)備，這樣運營商之間可以實現(xiàn)通信和策略控制。在介紹SBC的細節(jié)之前，讓我們首先明確幾個基本的概念：
SBC的全稱是Session Border Controller。簡單來說，SBC是部署在網(wǎng)絡(luò)邊界，用來控制SIP會話的設(shè)備或軟件。Session 表示會話，Border 表示網(wǎng)絡(luò)邊界，Controller 表示控制器。注意，這里的控制器很多用戶理解為是物理設(shè)備，事實上，也有很多廠家推出了基于軟件的E-SBC。
除了我們討論的SIP相關(guān)的技術(shù)范疇之內(nèi)，目前沒有關(guān)于SBC非常明確的定義規(guī)定。
根據(jù)RFC5853的定義，SBC被定義為一個B2BUAs，它可以實現(xiàn)對某些SIP 頭消息和SDP媒體描述進行修改。
在下面的圖例中，橙色部分就是經(jīng)過SBC處理以后的相關(guān)參數(shù)。注意，不同廠家的SBC或不同的業(yè)務(wù)需求對參數(shù)修改可能有所不同。這里的案例僅做示例來幫助用戶了解SBC的流程。
很多時候，一些客戶使用常用的概念來表示SBC的部署邊界。SBC在不同場景使用時的幾個主要概念：Peering SBC支持服務(wù)提供商對服務(wù)提供商的對接，Access SBC提供運營商和企業(yè)用戶SBC的對接，Enterprise SBC提供企業(yè)之間的對接。
市場發(fā)展的要求
綜合前面討論的幾個NAT解決方案的介紹，無論從技術(shù)層面還是未來網(wǎng)絡(luò)的拓展性方面，那些解決方案很難說是一個最終的解決辦法。這些解決方案可能存在以下幾個方面的問題和挑戰(zhàn)：
不同客戶的不同需求，幾種NAT類型的解決方案面對的是不同的客戶問題，不同的網(wǎng)絡(luò)環(huán)境，不同的客戶要求，所以，這些解決方案很難構(gòu)成一個完整的解決方案去支持大部分的客戶要求。
對服務(wù)提供商技術(shù)的挑戰(zhàn)，幾種解決方案對不同的公司有不同的要求，他們要求部署集成商提供專業(yè)的的技術(shù)水平，足夠的網(wǎng)絡(luò)帶寬，良好的網(wǎng)絡(luò)穩(wěn)定性和兼容性。
終端用戶的多樣性，終端用戶很難控制對端網(wǎng)絡(luò)，對網(wǎng)絡(luò)服務(wù)，語音質(zhì)量，安全機制失了可控性，例如使用第三方的STUN/TURN服務(wù)。
缺乏統(tǒng)一管理的平臺機制，對網(wǎng)絡(luò)設(shè)置和安全機制的設(shè)置缺乏一個統(tǒng)一的管理機制。
終端對STUN，TURN和防火墻問題，對不同終端所要求的支持能力也可能完全不同。
未來的可拓展性，以上幾種NAT解決方案缺乏對目前最新的SIP業(yè)務(wù)需求完整支持，例如IMS，電話轉(zhuǎn)接業(yè)務(wù)，錄音等要求。
對服務(wù)提供商的標準不同，缺乏對各種SIP服務(wù)提供商的兼容性測試標準，這樣失去了對業(yè)務(wù)能力的保證。
對融合通信的支持問題，它們也缺乏融合通信的業(yè)務(wù)能力的支持包括未來業(yè)務(wù)的升級和拓展。
通過以上各種問題的總結(jié)，我們可以看到，SBC可能是目前SIP業(yè)務(wù)最佳的一種解決方案，這也是為什么最近幾年SBC逐漸受到重視的原因。
市場調(diào)查
根據(jù)美國專注融合通信市場研究的Infonetrics所做的調(diào)查，到2018年， 預(yù)計SBC的市場需求是365 million 美金，大家可以看到這是一個非常龐大的市場。2013年是250 million 美金，到2018年則增長到了365 million 美金。增長速度非常驚人。
在此報告中同時列出了幾個主要的SBC廠家：
在未來的5G/IMS網(wǎng)絡(luò)中，SBC也扮演著非常重要的角色。我們在本章節(jié)的后續(xù)部分會介紹SBC在IMS網(wǎng)絡(luò)中所扮演的角色。
SBC在運營商和企業(yè)用戶的部署場景
大部分情況下，在介紹SBC的功能時，很多廠家的功能介紹解釋的比較含糊，這樣會導(dǎo)致用戶對產(chǎn)品的認識缺乏明確的概念，客戶可能喪失了購買信心。事實上，根據(jù)SBC使用的場景不同，SBC的功能有一定差別的。一般情況下，SBC 針對服務(wù)提供商和終端客戶兩種不同的場景需求�，F(xiàn)在我們分別介紹一些功能要求。
以下圖例標識了運營商和運營商對接的方式：
目前，綜合各種SBC的功能需求，筆者把SBC的功能歸納為十大主要功能。根據(jù)服務(wù)提供商和企業(yè)終端客戶的需求不同，我們分別予以介紹。這里，筆者僅對不同服務(wù)根據(jù)業(yè)務(wù)的側(cè)重點不同進行的簡單分類，以方便用戶掌握，不等于說運營商SBC和企業(yè)SBC功能上有什么特別的不同。SBC可以對服務(wù)提供商提供的支持包括：
- IP地址隱藏
權(quán)限訪問控制，控制用戶訪問權(quán)限，控制呼叫數(shù)量。
安全策略設(shè)置
QoS 保障
計費功能
服務(wù)提供商之間應(yīng)該可以提供更大的拓展能力
SBC可以對本地企業(yè)IPPBX的功能包括：
- 自動切換服務(wù)線路，如果服務(wù)提供商的工作中繼出現(xiàn)問題，SBC可以自動切換到服務(wù)提供商的備份服務(wù)器。
- 提供對本地IPPBX進行標準化處理，例如修改SIP SDP信息，編碼轉(zhuǎn)換，SIP-SS7的映射功能。
- 提供QoS保障。
- 可以提供協(xié)議的轉(zhuǎn)換功能，例如內(nèi)網(wǎng)使用TCP連接，連接服務(wù)提供商時則使用UDP連接。
- 防止非法侵入和網(wǎng)絡(luò)詐騙電話。來自Acme Packet的Kaplan總結(jié)了以下幾種關(guān)于VOIP的攻擊方式：
NAT支持，遠端終端通過外網(wǎng)實現(xiàn)對內(nèi)網(wǎng)IPPBX注冊。
筆者根據(jù)不同的場景提供幾個不同的解決方案圖例：遠端用戶注冊到企業(yè)內(nèi)網(wǎng)SBC解決方案。托管IPPBX通過SBC對接的解決方案和企業(yè)SIP trunk的解決方案。
托管IPPBX通過SBC對接的案例。
企業(yè)用戶接入SBC的案例：
當然，以上每一種功能都不一定是SBC用戶必須使用的功能，根據(jù)融合通信行業(yè)著名市場分析公司IHS Markit的報告，它把SBC的幾個主要核心功能概括為：編碼轉(zhuǎn)換，協(xié)議轉(zhuǎn)換，NAT，拓撲隱藏，權(quán)限控制和安全控制。
另外，隨著IMS網(wǎng)絡(luò)的進一步普及，SBC需要支持IMS網(wǎng)絡(luò)環(huán)境中，SBC需要支持sigaling plane（P-CSCF，I-BCF）和media plane（IMS-AGW，TrGW）。很多運營商已經(jīng)對SBC在IMS網(wǎng)絡(luò)的應(yīng)用提出了非常緊迫的要求。因此，為了滿足未來IMS的網(wǎng)絡(luò)要求，SBC的功能不得不進行升級。在3GPP環(huán)境中，SBC必須實現(xiàn)可拓展性，虛擬化和分布式部署。
SBC在IMS網(wǎng)絡(luò)中的功能模塊：
在IMS架構(gòu)中需要合并UNI邊界部分和NNI的部分功能來實現(xiàn)SBC控制器功能。在UNI邊界中的SBC控制部分：
在NNI邊界部分的SBC控制部分，這里僅涉及了R7的訪問。
目前，市場上比較領(lǐng)先的SBC設(shè)備一般集成IMS支持能力，也支持了以上幾個主要的核心模塊成為一個設(shè)備解決方案。
IMS網(wǎng)絡(luò)非常復(fù)雜，筆者水平有限，加之篇幅問題，不能完整介紹整個IMS的架構(gòu)。具體關(guān)于IMS網(wǎng)絡(luò)的介紹，請讀者查閱網(wǎng)絡(luò)文檔獲得更加詳細的介紹。
SBC功能詳解
通過以上的篇幅，我們介紹了SBC的一些基本的功能和概念，筆者對SBC所支持功能歸納為十個具體的功能，它們分別是：
- DoS預(yù)防：防止外網(wǎng)用戶對內(nèi)外IPPBX進行網(wǎng)絡(luò)攻擊，SBC可以提前設(shè)置一些策略來預(yù)防攻擊。
- DoS保護，如果有DoS攻擊的話，SBC的處理能力可以支持DoS攻擊，設(shè)置黑名單，設(shè)置嘗試注冊次數(shù)都是比較好的手段。
- 權(quán)限控制：SBC可以控制用戶認證身份，可以控制計費能力，可以控制呼叫能力權(quán)限。
- QoS保障，通過SBC設(shè)置可以提供對QoS的語音保障。
- 標準化重構(gòu)，這里的標準化重構(gòu)的含義是對用戶提供的媒體能力，業(yè)務(wù)能力提供相應(yīng)的轉(zhuǎn)化，并且能夠靈活地對對端進行支持，例如支持編碼轉(zhuǎn)換，SDP 消息體修改，SIP-SS7消息映射。
- 檢測功能，SBC可以檢測網(wǎng)絡(luò)狀態(tài)，SIP信令狀態(tài)，語音質(zhì)量等相關(guān)信息。
- VPN分離，SBC可以針對不同用戶設(shè)置不同的VPN隧道功能。
- 拓撲隱藏，SBC提供了內(nèi)網(wǎng)IPPBX對外網(wǎng)不可見的能力，SBC提供修改后的IP地址相關(guān)信息，這樣，外網(wǎng)用戶不會看到內(nèi)網(wǎng)PBX信息。但是，讀者要注意，根據(jù) RFC 5853中3.1.2的說明，SBC不能很好的配合Authenticated Identity Management 工作。
- 系統(tǒng)資源優(yōu)化，SBC可以提供SIP注冊能力的均衡負載，SIP trunk的均衡負載，監(jiān)控系統(tǒng)閥值，提供SIP/PSTN的逃生處理，保障系統(tǒng)達到最佳資源狀態(tài)。
- 防止非法入侵，SBC提供了對用戶的認證和簽權(quán)功能，同時提供了對信令語音的加密功能，SBC可以保障非法用戶的入侵。
部署SBC需要關(guān)注的問題
盡管筆者花了很多時間介紹SBC的“好”， 但是在用戶部署環(huán)境中仍然有一些問題需要用戶考慮：
- 性能處理的問題，因為本身架構(gòu)的問題，SBC是一個B2BUA，簡單來說，就是SIP路徑上的一個中間人。這樣會導(dǎo)致很多問題出現(xiàn)，例如標準重構(gòu)時需要處理大量的SDP消息，同時可能需要進行編碼轉(zhuǎn)換（關(guān)于編碼轉(zhuǎn)換的問題筆者以前專門做過介紹），可能還要接收和發(fā)送大量的注冊消息，這些功能需要消耗大量的CPU資源和網(wǎng)絡(luò)接口資源，可能導(dǎo)致SBC穩(wěn)定性降低。
- 需要擴展逃生功能支持傳統(tǒng)的PSTN，單純的SBC設(shè)備為了支持SIP的服務(wù)，為了保證企業(yè)電話系統(tǒng)100%正常工作，需要增加多個trunk智能支持，也同時需要傳統(tǒng)PSTN的接入。
- 國家法律的要求錄音功能，大家知道，中國已經(jīng)在最近幾年開始要求一些敏感部門對電話進行錄音。其實，美國在1994年就已經(jīng)制定了關(guān)于通信設(shè)備支持電話偵聽到法案（ CALEA）。在RFC 3924中也相應(yīng)地規(guī)定了錄音的要求。如果SBC不能支持錄音的話，SBC的功能需求就大打折扣，很多項目中，客戶也不敢使用不支持錄音的SBC。但是，如果支持錄音的話，SBC性能會受到很大影響，Menghui YANG 幾年前發(fā)表了VoIP網(wǎng)絡(luò)電話呼叫偵聽對SBC性能的影響，以下是研究報告關(guān)于錄音和不錄音狀態(tài)下，SBC的并發(fā)處理數(shù)據(jù)。通過此報告數(shù)據(jù)可以看出，錄音或不錄音狀態(tài)下，對SBC的并發(fā)處理能力有很大差別。
SIP REFER消息支持問題或呼叫業(yè)務(wù)轉(zhuǎn)接支持也是一個值得重視的問題，有時，如果本地用戶需要執(zhí)行轉(zhuǎn)接功能的話，運營商有兩種處理方式，第一種運營商可能支持REFER，一般可能執(zhí)行重新計費。當然，這里不排除利用轉(zhuǎn)電話接功能實現(xiàn)長途呼叫功能，繞過運營商本地計費，事實上，這也是一種詐騙的方式。所以，運營商執(zhí)行重新計費。第二種方式就是返回一個405 Method not Allowed消息，不支持本地用戶的呼轉(zhuǎn)服務(wù)。
以下圖例說明了在內(nèi)網(wǎng)沒有SBC的狀況下，運營商會直接返回一個405消息，轉(zhuǎn)接服務(wù)被拒絕。
如果終端客戶部署了SBC后，前面我們已經(jīng)介紹過，SBC是一個B2BUA，可以修改SIP消息，重新發(fā)送一個帶本地ID的Re-INVITE消息，運營商仍然看作是同一個呼叫，這樣運營商會接受這個轉(zhuǎn)接呼叫服務(wù)。
再次說明，因為REFER存在著一個潛在的不安全因素，所以運營商一般會拒絕這個請求。關(guān)于REFER安全的討論，大家可以查閱RFC3515的Authorization Consideration for REFER。
- 關(guān)于號碼歸屬地的問題。號碼歸屬地可能導(dǎo)致計費錯誤，大部分情況這種可能性不會發(fā)生，但是有的運營商會根據(jù)SIP頭帶的號碼來做一個簡單的判斷，判斷號碼屬性。在用戶多個分公司部署的環(huán)境下，如果沒有嚴格設(shè)置號碼路由，很可能出現(xiàn)分公司內(nèi)網(wǎng)用戶呼叫外地用戶就變成長途呼叫的可能。例如，如果在深圳的分公司通過北京總部的PBX出局呼叫北京或者河北的用戶，運營商很可能根據(jù)SIP帶的號碼歸屬地，認為這是來自深圳的呼叫，從而以長途計費。如果通過SBC重新修改成一個標識為本地PBX出局的號碼身份，則運營商就會認為這是本地客戶電話系統(tǒng)的呼叫，而不是一個來自外地的呼叫。SBC同時也可以根據(jù)路由的要求，添加一個號碼歸屬地前綴，表示國家或者地區(qū)的屬性。SBC也可以實現(xiàn)對tgrp的支持，通過添加tgrp標簽，運營商也可以正確識別客戶的SIP身份。
- SBC結(jié)合IPPBX的兼容性測試問題，網(wǎng)絡(luò)有很多的討論，筆者推薦根據(jù)Avaya的兼容性測試流程來進行測試。
具體的測試項目包括：通過SBC IPPBX用戶的呼出呼入測試，直接點對點的IP呼叫測試，DTMF測試-使用RFC2833進行IVR測試，語音等待測試流程測試，呼叫專接，電話會議，長時間呼叫摘機測試，錄音測試和T38傳真收發(fā)測試。如果讀者真正想進行完整權(quán)威地對接測試，筆者建議參考SIPconnect 社區(qū)的測試標準來進行對接測試。
用戶根據(jù)架構(gòu)圖實現(xiàn)兼容性測試，具體測試要求查閱參考資料的鏈接。以下是SIPConnect-2.0 的測試流程圖：
- SBC對WebRTC的支持問題。WebRTC技術(shù)是最近幾年發(fā)展非�；鸬募夹g(shù)，在和SIP結(jié)合時，很多公司也建議使用SBC來解決編碼轉(zhuǎn)換的問題和語音加密的問題。這里需要注意，一些SBC編碼轉(zhuǎn)換功能可能還不能完全支持VP8 或最新的VP9。
SBC虛擬化的可行性研究
實際上，隨著IMS 用戶的不斷增加，運營商對SBC的維護部署也有了新的要求，例如使用基于云的計算平臺，使用虛擬化的解決方案都是可行的。首先了解一下傳統(tǒng)的SBC架構(gòu)，它是一種一體機設(shè)備的解決方案，包括DSP，Cryto 處理加密，TCAM處理媒體，CPU的核心要件。
國外一些公司已經(jīng)開始著手進行SBC虛擬化解決方案的可行性研究，一些公司的虛擬化SBC解決方案已開始測試。他們的研究是基于目前比較成熟的云平臺來實現(xiàn)。研究人員認為基本的云計算技術(shù)架構(gòu)已經(jīng)可以滿足SBC的虛擬化部署，其主要根據(jù)是：
- Intel CPU的發(fā)展可以支持多核處理，支持虛擬化。
- Linux X86 結(jié)合強大的CPU 實現(xiàn)并行處理的能力不斷強化，為SBC容量擴展提供了硬件支持。
- 開發(fā)自有的軟件DSP負責編碼轉(zhuǎn)換，這里，研究人員也考慮了DSP的成本問題，不過，無論軟硬件的DSP，成本一般都比較高。
- CPU可以被充分利用，DSP只做編碼處理。
- 亞馬遜的AWS對信令處理的性能比較滿意，媒體處理能力也相對比較好。
- 分布式部署，信令和媒體獨立處理，提高了擴容的可能性。
以上關(guān)于SBC虛擬化可行性的研究討論都是基于云平臺技術(shù)本身，當然也有賴于開發(fā)人員的技術(shù)實力。
SBC對SIP網(wǎng)絡(luò)流程帶來的挑戰(zhàn)
我們在前面的很多章節(jié)中討論了很多使用SBC的好處，但是SBC在實際網(wǎng)絡(luò)環(huán)境的使用中，用戶仍然需要面對很多不可知的挑戰(zhàn)：
- SBC會破壞整個端對端SIP的邏輯流程的自然屬性。如果部署相對封閉的VoIP解決方案，SBC可能是一個需要考慮的問題。
- SBC會破壞整個端對端SIP的呼叫流程，這樣會導(dǎo)致UAS對SIP呼叫流程的監(jiān)控和狀態(tài)失去作用，并且增加了技術(shù)排查難度，可能增加其他設(shè)備或軟件來彌補SBC帶來的問題。
- SBC不僅對信令進行二次處理，也對媒體進行二次處理，例如編碼轉(zhuǎn)換的流程。這樣的話，會給雙方的語音呼叫帶來進一步的延遲，增加了運營商的帶寬成本。但是，我們經(jīng)常遇到的是，運營商提供的是相對占用帶寬比較低的G.729, 這樣就需要終端客戶自己進行編碼處理，這樣就會導(dǎo)致本地IPPBX，網(wǎng)關(guān)或SBC必須做編碼轉(zhuǎn)換，同樣增加本地用戶的部署成本。
- 加密以后的SIP和SBC結(jié)合會帶來更加復(fù)雜的問題。記得一位麻省理工多媒體實驗室的學者說過這樣一句話- “Your advantages are your disadvantages”。 任何事情都帶有兩面性。具有諷刺意味的是，大家知道我們使用SBC是為了更加安全，如果IPPBX和終端之間已經(jīng)使用了加密機制的話，SBC是最有可能出現(xiàn)問題的一個中間環(huán)節(jié)。根據(jù)RFC 5853 3.1.2 部分的說明，假設(shè)SIP終端都已經(jīng)設(shè)置了加密的方式和IPPBX進行通信驗證，SBC則需要獲得SIP頭內(nèi)容和SDP的體，這里就要求SBC需要首先讀取對發(fā)送到呼叫方的加密消息，并且SBC還要需要獲得被呼叫方的確認和信任。訪問被呼叫方的私鑰可能還要涉及其他的服務(wù)認證設(shè)置。這樣的流程就完全可能導(dǎo)致終端的協(xié)商失敗。如果SBC移除加密機制，重新設(shè)置加密機制的話，那么SBC就會打破SIP終端之間的加密認證機制。這里再次提醒用戶，根據(jù) RFC 5853中3.1.2的說明，SBC不能很好地配合Authenticated Identity Management工作，具體說明讀者可查閱RFC5853。
- SBC支持媒體流量管理帶來的問題。大家知道，SBC不僅僅對信令做出處理，同時也負責媒體的管理也包括媒體流量的管理。有時，SBC可以檢測丟失Bye消息的媒體會話，丟失Bye消息可能就意味著這個呼叫在中間某個環(huán)節(jié)已經(jīng)出現(xiàn)異�；蛘咚赖�，SBC必須通過檢測媒體狀態(tài)，然后返回信令掛機消息。有時，運營商會根據(jù)數(shù)據(jù)流量來計費，如果在媒體路徑上部署了SBC的話，媒體經(jīng)過SBC的轉(zhuǎn)發(fā)處理，可能導(dǎo)致媒體數(shù)據(jù)丟失的問題，同時增加了SBC的負載。另外，和我們上面介紹的一樣，如果終端客戶雙方進行了加密處理，SBC沒有獲得雙方的許可，那么RTP加密認證又是一個問題。
- SBC對標準化重構(gòu)的支持問題。雖然SBC支持標準化重構(gòu)。很多情況下，終端之間完全可能出現(xiàn)支持能力不同的問題，雙方所各自支持的功能可能不完全匹配，這時運營商需要SBC重新進行標準化重構(gòu)的機制，這樣就可以滿足雙方的通話要求。如果在大并發(fā)處理的環(huán)境中出現(xiàn)大量類似的不同功能的標準化重構(gòu)的話，SBC就需要支持大量的配置機制，并且能夠保證并行處理大量的流程處理。例如，同時處理IPv4 和IPv6 轉(zhuǎn)換，也可能同時處理G.711到G.729的轉(zhuǎn)換，還有可能同時處理VP8 到G.711的轉(zhuǎn)換或者TCP到UDP的轉(zhuǎn)換。這個問題需要SBC用戶盡可能做一些進一步的研究，選擇真正有處理能力，能夠完全支持復(fù)雜環(huán)境的SBC產(chǎn)品。
- SBC備份的問題。如果一個單點SBC出現(xiàn)故障需要備份的話，主從服務(wù)器之間需要非常緊密的配合才能實現(xiàn)媒體和信令的成功切換，否則極有可能出現(xiàn)大批用戶突然失去連接的問題。
- SBC未來的功能支持，這個內(nèi)容對于筆者來說太大，筆者僅根據(jù)RFC5853的一些建議對此做一個簡單總結(jié)。SBC在未來的設(shè)計中應(yīng)該支持一個對SIP更加友好的拓撲隱藏方式，應(yīng)該支持一個對SIP更加友好的媒體流量管理方式，應(yīng)該支持一個對SIP更加友好的標準化重構(gòu)方式。
SBC開源解決方案
Kamalio，OpenSIPs結(jié)合Asterisk或者FreeSWITCH是一種相對比較“經(jīng)濟”的SBC解決方案。關(guān)于使用以上開源解決方案實現(xiàn)SBC的功能，筆者在幾年前也做過類似的探討，這里不會再次做過多詳細的介紹，網(wǎng)絡(luò)上有很多類似的文檔可以參考。但是，客觀地說，如果通過以上類似的非常龐大的軟交換平臺開發(fā)成為一個SBC的話，它距離真正的生產(chǎn)環(huán)境和商業(yè)使用還有很長的距離，需要開發(fā)人員投入很大的精力去完善。這里，筆者有幾個方面的建議用戶可以考慮：
使用以上開源平臺，是否有足夠的人力去開發(fā)維護。
目前網(wǎng)絡(luò)上看到的SBC解決方案僅實現(xiàn)了SBC的部分功能，大部分僅實現(xiàn)了拓撲隱藏，防攻擊，NAT基本功能，如果嚴格地說，還不能算一個完整的SBC解決方案。另外，很多公開的開源的SBC設(shè)置文檔也缺乏對底層的優(yōu)化，如果需要真正部署在用戶環(huán)境，仍然需要優(yōu)化。
Kamalio/OpenSIPs 可以實現(xiàn)媒體的處理，但是需要第三方媒體服務(wù)器參與才能支持一個比較完整的SBC功能。
編碼轉(zhuǎn)換需要開發(fā)人員進一步投入才能完成，目前，還沒有真正的開源的媒體轉(zhuǎn)換的功能能夠支持大量的媒體轉(zhuǎn)換，過多可能還是有賴于Asterisk或者FreeSWITCH實現(xiàn)媒體轉(zhuǎn)換的功能。
Asterisk或者FreeSWITCH平臺的SIP和媒體耦合度太緊密，媒體和信令獨立或分離的可能性不大，這樣的話就可能導(dǎo)致SBC缺乏真正的可拓展性。當然，用戶確實有非常強大的技術(shù)研發(fā)隊伍也可以進一步優(yōu)化。
Kamailio/OpenSIPs對SIP RFC的兼容性支持相當強大靈活，但是需要非常高的技術(shù)要求。
個人覺得，目前比較可行的企業(yè)級SBC開源解決方案是Kamailio做信令服務(wù)器，F(xiàn)reeSWITCH作為一個媒體服務(wù)器，負責錄音和編碼轉(zhuǎn)換。編碼轉(zhuǎn)換可以使用基于硬件的編碼轉(zhuǎn)換卡來獲得編碼能力的支持，并且編碼處理能力也可以做分布式部署拓展發(fā)布。關(guān)于此開源解決方案具體的部署方式，用戶可以訪問Kamailio或FreeSWITCH官方網(wǎng)站獲得詳細配置文件。
使用OpenSIPS作為SBC來使用，OpenSIPS本身支持B2BUA模塊，也可以實現(xiàn)SBC的功能，而且結(jié)合編碼轉(zhuǎn)換卡可以實現(xiàn)編碼轉(zhuǎn)換的功能，但是仍然缺乏媒體服務(wù)器的支持，還是需要依賴第三方的媒體服務(wù)器實現(xiàn)媒體的控制。
在本章節(jié)中，我們簡單回顧了以前章節(jié)的一些NAT解決方案的內(nèi)容和存在的問題，然后介紹了SBC的產(chǎn)生背景，SBC的用戶場景和SBC的主要功能，同時，我們也探討了SBC在部署時需要用戶注意到問題，還有目前SBC對SIP的影響，最后我們分別介紹了SBC的虛擬化可行性研究探討和基于開源解決方案的簡單論述。通過以上大篇幅的介紹，我們希望給用戶一個比較完整的SBC解決方案的剖析，然后用戶要根據(jù)自己的使用場景，部署成本，可維護性，拓展性做一個正確的評價。最后，因為個人能力有限和篇幅的局限，很多技術(shù)細節(jié)沒有深入太多討論，也可能出現(xiàn)很多錯誤，希望諒解指正。
參考資料：
https://tools.ietf.org/html/rfc5853
http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc
https://www.opensips.org/Documentation/Tutorials-SangomaVoiceTranscoding
https://www.nanog.org/meetings/nanog34/presentations/kaplan.pdf
https://datatracker.ietf.org/doc/rfc3924/
https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818
部署VoIP呼叫實現(xiàn)網(wǎng)絡(luò)偵聽對SBC性能影響：Implementation and Performance for Lawful Intercept of VoIP calls based on SIP Session Border Controller
