在前面的關(guān)于SIP和NAT問題的講座中，我們花費(fèi)了大量篇幅把整個(gè)關(guān)于SIP和NAT的各種問題做了比較全面和深入的探討，同時(shí)，我們也介紹了各種針對(duì)NAT的解決方案，但是那些方案僅解決了SIP在互聯(lián)網(wǎng)環(huán)境下的局部問題，也沒有考慮到整個(gè)企業(yè)IPPBX環(huán)境所要求的其他業(yè)務(wù)能力的支持。盡管那些解決方案在某些特定的環(huán)境中實(shí)現(xiàn)了某些用戶的要求，但是它們本身還是具有一定的局限性和針對(duì)性。SBC則比較好地解決了我們討論的問題，但是目前在市場(chǎng)上很少看到對(duì)SBC技術(shù)的全面介紹和剖析，很多公司的SBC介紹也僅局限于市場(chǎng)需求，使用了太多市場(chǎng)語言把SBC，很多描述可能有一些含糊不清，另外，一些相關(guān)的技術(shù)問題也缺乏更多詳細(xì)說明，用戶在了解和學(xué)習(xí)這些相關(guān)知識(shí)時(shí)會(huì)產(chǎn)生很多困擾。

　　筆者雖然在差不多6年前開始接觸SBC，這期間也多多少少接觸了一些客戶，基本上了解一些客戶對(duì)SBC的需求和目前存在的潛在問題。為了結(jié)合我們的SIP系列講座，筆者今天對(duì)SBC做一個(gè)比較全面的剖析，盡可能覆蓋大部分用戶所關(guān)心的問題，這樣可以幫助SBC用戶能夠比較全面地對(duì)SBC有一個(gè)概括。我們討論的范圍從SBC使用背景和由來，市場(chǎng)需求，使用場(chǎng)景和存在的問題進(jìn)行一個(gè)基本梳理。筆者不會(huì)在這里討論過多某個(gè)SBC廠家的產(chǎn)品技術(shù)細(xì)節(jié)，如果特別需要可能會(huì)適當(dāng)加入一點(diǎn)廠家的SBC內(nèi)容，幫助用戶理解SBC，否則讀者可能產(chǎn)生歧義。

　　筆者主要從幾個(gè)方面來剖析SBC的全貌，這些內(nèi)容包括：SBC的基本概念，SBC產(chǎn)生的背景原因，SBC的市場(chǎng)情況，SBC的核心功能，SBC運(yùn)營(yíng)商和企業(yè)客戶的使用場(chǎng)景，SBC的功能介紹，SBC錄音時(shí)的性能問題，SBC部署時(shí)的問題，SBC對(duì)SIP的流程的影響，SBC在IMS網(wǎng)絡(luò)中的角色，SBC虛擬化的可能性和基于開源解決方案等方面的內(nèi)容做一個(gè)全面的剖析（盡可能全面），幫助用戶全面了解SBC技術(shù)。

　　首先讓我們介紹一下SBC產(chǎn)生的背景。任何技術(shù)的產(chǎn)生都是基于一定的背景，只有客戶端需求越來越急迫的時(shí)候，一些對(duì)行業(yè)敏感的廠家就可能抓住機(jī)會(huì)來開發(fā)這樣的產(chǎn)品滿足消費(fèi)者。舉個(gè)例子，故事的大概過程是這樣的。當(dāng)年美國(guó)早期的淘金熱時(shí)，Lee牛仔褲的暢銷就是因?yàn)長(zhǎng)ee的老板抓住了商機(jī)。當(dāng)時(shí)西部淘金時(shí)礦工抱怨說為什么沒有一條結(jié)實(shí)一點(diǎn)的褲子，同時(shí)褲兜的地方老是開裂，Lee當(dāng)年正好從事布匹的批發(fā)業(yè)務(wù)，他琢磨了半天，把當(dāng)時(shí)做帆船的帆布經(jīng)過改造，結(jié)合褲子上打鉚釘?shù)膭?chuàng)意生產(chǎn)出了非常結(jié)實(shí)的牛仔褲。然后，Lee就開始在全世界大賣。這樣的例子數(shù)不勝數(shù)。VoIP的發(fā)展也是這樣，隨著VoIP的不斷發(fā)展，服務(wù)提供商不只提供一個(gè)簡(jiǎn)單的語音通話的功能，在實(shí)際的VoIP運(yùn)營(yíng)環(huán)境中，SBC設(shè)備沒有真正部署或應(yīng)用之前，市場(chǎng)上沒有專門的設(shè)備為服務(wù)提供商和服務(wù)提供商自己實(shí)現(xiàn)完整的對(duì)接解決方案，同時(shí)也沒有一套完整的解決方案來實(shí)現(xiàn)運(yùn)營(yíng)商和終端客戶之間的對(duì)接支持。為了滿足運(yùn)營(yíng)商服務(wù)的要求，很多廠家開始研發(fā)SBC做為一個(gè)運(yùn)營(yíng)商邊界網(wǎng)絡(luò)的設(shè)備來支持運(yùn)營(yíng)商的需求。在典型的應(yīng)用環(huán)境中，SBC作為運(yùn)營(yíng)商VoIP網(wǎng)絡(luò)邊界的互聯(lián)設(shè)備，這樣運(yùn)營(yíng)商之間可以實(shí)現(xiàn)通信和策略控制。在介紹SBC的細(xì)節(jié)之前，讓我們首先明確幾個(gè)基本的概念：

　　SBC的全稱是Session Border Controller。簡(jiǎn)單來說，SBC是部署在網(wǎng)絡(luò)邊界，用來控制SIP會(huì)話的設(shè)備或軟件。Session 表示會(huì)話，Border 表示網(wǎng)絡(luò)邊界，Controller 表示控制器。注意，這里的控制器很多用戶理解為是物理設(shè)備，事實(shí)上，也有很多廠家推出了基于軟件的E-SBC。

　　除了我們討論的SIP相關(guān)的技術(shù)范疇之內(nèi)，目前沒有關(guān)于SBC非常明確的定義規(guī)定。

　　根據(jù)RFC5853的定義，SBC被定義為一個(gè)B2BUAs，它可以實(shí)現(xiàn)對(duì)某些SIP 頭消息和SDP媒體描述進(jìn)行修改。

　　在下面的圖例中，橙色部分就是經(jīng)過SBC處理以后的相關(guān)參數(shù)。注意，不同廠家的SBC或不同的業(yè)務(wù)需求對(duì)參數(shù)修改可能有所不同。這里的案例僅做示例來幫助用戶了解SBC的流程。

　　很多時(shí)候，一些客戶使用常用的概念來表示SBC的部署邊界。SBC在不同場(chǎng)景使用時(shí)的幾個(gè)主要概念：Peering SBC支持服務(wù)提供商對(duì)服務(wù)提供商的對(duì)接，Access SBC提供運(yùn)營(yíng)商和企業(yè)用戶SBC的對(duì)接，Enterprise SBC提供企業(yè)之間的對(duì)接。

　　綜合前面討論的幾個(gè)NAT解決方案的介紹，無論從技術(shù)層面還是未來網(wǎng)絡(luò)的拓展性方面，那些解決方案很難說是一個(gè)最終的解決辦法。這些解決方案可能存在以下幾個(gè)方面的問題和挑戰(zhàn)：

　　不同客戶的不同需求，幾種NAT類型的解決方案面對(duì)的是不同的客戶問題，不同的網(wǎng)絡(luò)環(huán)境，不同的客戶要求，所以，這些解決方案很難構(gòu)成一個(gè)完整的解決方案去支持大部分的客戶要求。

　　對(duì)服務(wù)提供商技術(shù)的挑戰(zhàn)，幾種解決方案對(duì)不同的公司有不同的要求，他們要求部署集成商提供專業(yè)的的技術(shù)水平，足夠的網(wǎng)絡(luò)帶寬，良好的網(wǎng)絡(luò)穩(wěn)定性和兼容性。

　　終端用戶的多樣性，終端用戶很難控制對(duì)端網(wǎng)絡(luò)，對(duì)網(wǎng)絡(luò)服務(wù)，語音質(zhì)量，安全機(jī)制失了可控性，例如使用第三方的STUN/TURN服務(wù)。

　　缺乏統(tǒng)一管理的平臺(tái)機(jī)制，對(duì)網(wǎng)絡(luò)設(shè)置和安全機(jī)制的設(shè)置缺乏一個(gè)統(tǒng)一的管理機(jī)制。

　　終端對(duì)STUN，TURN和防火墻問題，對(duì)不同終端所要求的支持能力也可能完全不同。

　　未來的可拓展性，以上幾種NAT解決方案缺乏對(duì)目前最新的SIP業(yè)務(wù)需求完整支持，例如IMS，電話轉(zhuǎn)接業(yè)務(wù)，錄音等要求。

　　對(duì)服務(wù)提供商的標(biāo)準(zhǔn)不同，缺乏對(duì)各種SIP服務(wù)提供商的兼容性測(cè)試標(biāo)準(zhǔn)，這樣失去了對(duì)業(yè)務(wù)能力的保證。

　　對(duì)融合通信的支持問題，它們也缺乏融合通信的業(yè)務(wù)能力的支持包括未來業(yè)務(wù)的升級(jí)和拓展。

　　通過以上各種問題的總結(jié)，我們可以看到，SBC可能是目前SIP業(yè)務(wù)最佳的一種解決方案，這也是為什么最近幾年SBC逐漸受到重視的原因。

　　根據(jù)美國(guó)專注融合通信市場(chǎng)研究的Infonetrics所做的調(diào)查，到2018年， 預(yù)計(jì)SBC的市場(chǎng)需求是365 million 美金，大家可以看到這是一個(gè)非常龐大的市場(chǎng)。2013年是250 million 美金，到2018年則增長(zhǎng)到了365 million 美金。增長(zhǎng)速度非常驚人。

　　在此報(bào)告中同時(shí)列出了幾個(gè)主要的SBC廠家：

　　在未來的5G/IMS網(wǎng)絡(luò)中，SBC也扮演著非常重要的角色。我們?cè)诒菊鹿?jié)的后續(xù)部分會(huì)介紹SBC在IMS網(wǎng)絡(luò)中所扮演的角色。

　　大部分情況下，在介紹SBC的功能時(shí)，很多廠家的功能介紹解釋的比較含糊，這樣會(huì)導(dǎo)致用戶對(duì)產(chǎn)品的認(rèn)識(shí)缺乏明確的概念，客戶可能喪失了購(gòu)買信心。事實(shí)上，根據(jù)SBC使用的場(chǎng)景不同，SBC的功能有一定差別的。一般情況下，SBC 針對(duì)服務(wù)提供商和終端客戶兩種不同的場(chǎng)景需求�，F(xiàn)在我們分別介紹一些功能要求。

　　以下圖例標(biāo)識(shí)了運(yùn)營(yíng)商和運(yùn)營(yíng)商對(duì)接的方式：
 

　　目前，綜合各種SBC的功能需求，筆者把SBC的功能歸納為十大主要功能。根據(jù)服務(wù)提供商和企業(yè)終端客戶的需求不同，我們分別予以介紹。這里，筆者僅對(duì)不同服務(wù)根據(jù)業(yè)務(wù)的側(cè)重點(diǎn)不同進(jìn)行的簡(jiǎn)單分類，以方便用戶掌握，不等于說運(yùn)營(yíng)商SBC和企業(yè)SBC功能上有什么特別的不同。SBC可以對(duì)服務(wù)提供商提供的支持包括：

　　權(quán)限訪問控制，控制用戶訪問權(quán)限，控制呼叫數(shù)量。

　　安全策略設(shè)置

　　QoS 保障

　　計(jì)費(fèi)功能

　　服務(wù)提供商之間應(yīng)該可以提供更大的拓展能力

　　托管IPPBX通過SBC對(duì)接的案例。

　　當(dāng)然，以上每一種功能都不一定是SBC用戶必須使用的功能，根據(jù)融合通信行業(yè)著名市場(chǎng)分析公司IHS Markit的報(bào)告，它把SBC的幾個(gè)主要核心功能概括為：編碼轉(zhuǎn)換，協(xié)議轉(zhuǎn)換，NAT，拓?fù)潆[藏，權(quán)限控制和安全控制。

　　另外，隨著IMS網(wǎng)絡(luò)的進(jìn)一步普及，SBC需要支持IMS網(wǎng)絡(luò)環(huán)境中，SBC需要支持sigaling plane（P-CSCF，I-BCF）和media plane（IMS-AGW，TrGW）。很多運(yùn)營(yíng)商已經(jīng)對(duì)SBC在IMS網(wǎng)絡(luò)的應(yīng)用提出了非常緊迫的要求。因此，為了滿足未來IMS的網(wǎng)絡(luò)要求，SBC的功能不得不進(jìn)行升級(jí)。在3GPP環(huán)境中，SBC必須實(shí)現(xiàn)可拓展性，虛擬化和分布式部署。

　　在IMS架構(gòu)中需要合并UNI邊界部分和NNI的部分功能來實(shí)現(xiàn)SBC控制器功能。在UNI邊界中的SBC控制部分：

　　在NNI邊界部分的SBC控制部分，這里僅涉及了R7的訪問。

　　目前，市場(chǎng)上比較領(lǐng)先的SBC設(shè)備一般集成IMS支持能力，也支持了以上幾個(gè)主要的核心模塊成為一個(gè)設(shè)備解決方案。

　　IMS網(wǎng)絡(luò)非常復(fù)雜，筆者水平有限，加之篇幅問題，不能完整介紹整個(gè)IMS的架構(gòu)。具體關(guān)于IMS網(wǎng)絡(luò)的介紹，請(qǐng)讀者查閱網(wǎng)絡(luò)文檔獲得更加詳細(xì)的介紹。

　　通過以上的篇幅，我們介紹了SBC的一些基本的功能和概念，筆者對(duì)SBC所支持功能歸納為十個(gè)具體的功能，它們分別是：

　　盡管筆者花了很多時(shí)間介紹SBC的“好”， 但是在用戶部署環(huán)境中仍然有一些問題需要用戶考慮：

　　SIP REFER消息支持問題或呼叫業(yè)務(wù)轉(zhuǎn)接支持也是一個(gè)值得重視的問題，有時(shí)，如果本地用戶需要執(zhí)行轉(zhuǎn)接功能的話，運(yùn)營(yíng)商有兩種處理方式，第一種運(yùn)營(yíng)商可能支持REFER，一般可能執(zhí)行重新計(jì)費(fèi)。當(dāng)然，這里不排除利用轉(zhuǎn)電話接功能實(shí)現(xiàn)長(zhǎng)途呼叫功能，繞過運(yùn)營(yíng)商本地計(jì)費(fèi)，事實(shí)上，這也是一種詐騙的方式。所以，運(yùn)營(yíng)商執(zhí)行重新計(jì)費(fèi)。第二種方式就是返回一個(gè)405 Method not Allowed消息，不支持本地用戶的呼轉(zhuǎn)服務(wù)。

　　以下圖例說明了在內(nèi)網(wǎng)沒有SBC的狀況下，運(yùn)營(yíng)商會(huì)直接返回一個(gè)405消息，轉(zhuǎn)接服務(wù)被拒絕。

　　如果終端客戶部署了SBC后，前面我們已經(jīng)介紹過，SBC是一個(gè)B2BUA，可以修改SIP消息，重新發(fā)送一個(gè)帶本地ID的Re-INVITE消息，運(yùn)營(yíng)商仍然看作是同一個(gè)呼叫，這樣運(yùn)營(yíng)商會(huì)接受這個(gè)轉(zhuǎn)接呼叫服務(wù)。

　　再次說明，因?yàn)镽EFER存在著一個(gè)潛在的不安全因素，所以運(yùn)營(yíng)商一般會(huì)拒絕這個(gè)請(qǐng)求。關(guān)于REFER安全的討論，大家可以查閱RFC3515的Authorization Consideration for REFER。

　　具體的測(cè)試項(xiàng)目包括：通過SBC IPPBX用戶的呼出呼入測(cè)試，直接點(diǎn)對(duì)點(diǎn)的IP呼叫測(cè)試，DTMF測(cè)試-使用RFC2833進(jìn)行IVR測(cè)試，語音等待測(cè)試流程測(cè)試，呼叫專接，電話會(huì)議，長(zhǎng)時(shí)間呼叫摘機(jī)測(cè)試，錄音測(cè)試和T38傳真收發(fā)測(cè)試。如果讀者真正想進(jìn)行完整權(quán)威地對(duì)接測(cè)試，筆者建議參考SIPconnect 社區(qū)的測(cè)試標(biāo)準(zhǔn)來進(jìn)行對(duì)接測(cè)試。

　　用戶根據(jù)架構(gòu)圖實(shí)現(xiàn)兼容性測(cè)試，具體測(cè)試要求查閱參考資料的鏈接。以下是SIPConnect-2.0 的測(cè)試流程圖：

　　實(shí)際上，隨著IMS 用戶的不斷增加，運(yùn)營(yíng)商對(duì)SBC的維護(hù)部署也有了新的要求，例如使用基于云的計(jì)算平臺(tái)，使用虛擬化的解決方案都是可行的。首先了解一下傳統(tǒng)的SBC架構(gòu)，它是一種一體機(jī)設(shè)備的解決方案，包括DSP，Cryto 處理加密，TCAM處理媒體，CPU的核心要件。

　　國(guó)外一些公司已經(jīng)開始著手進(jìn)行SBC虛擬化解決方案的可行性研究，一些公司的虛擬化SBC解決方案已開始測(cè)試。他們的研究是基于目前比較成熟的云平臺(tái)來實(shí)現(xiàn)。研究人員認(rèn)為基本的云計(jì)算技術(shù)架構(gòu)已經(jīng)可以滿足SBC的虛擬化部署，其主要根據(jù)是：

　　以上關(guān)于SBC虛擬化可行性的研究討論都是基于云平臺(tái)技術(shù)本身，當(dāng)然也有賴于開發(fā)人員的技術(shù)實(shí)力。

　　我們?cè)谇懊娴暮芏嗾鹿?jié)中討論了很多使用SBC的好處，但是SBC在實(shí)際網(wǎng)絡(luò)環(huán)境的使用中，用戶仍然需要面對(duì)很多不可知的挑戰(zhàn)：

　　Kamalio，OpenSIPs結(jié)合Asterisk或者FreeSWITCH是一種相對(duì)比較“經(jīng)濟(jì)”的SBC解決方案。關(guān)于使用以上開源解決方案實(shí)現(xiàn)SBC的功能，筆者在幾年前也做過類似的探討，這里不會(huì)再次做過多詳細(xì)的介紹，網(wǎng)絡(luò)上有很多類似的文檔可以參考。但是，客觀地說，如果通過以上類似的非常龐大的軟交換平臺(tái)開發(fā)成為一個(gè)SBC的話，它距離真正的生產(chǎn)環(huán)境和商業(yè)使用還有很長(zhǎng)的距離，需要開發(fā)人員投入很大的精力去完善。這里，筆者有幾個(gè)方面的建議用戶可以考慮：

　　使用以上開源平臺(tái)，是否有足夠的人力去開發(fā)維護(hù)。

　　目前網(wǎng)絡(luò)上看到的SBC解決方案僅實(shí)現(xiàn)了SBC的部分功能，大部分僅實(shí)現(xiàn)了拓?fù)潆[藏，防攻擊，NAT基本功能，如果嚴(yán)格地說，還不能算一個(gè)完整的SBC解決方案。另外，很多公開的開源的SBC設(shè)置文檔也缺乏對(duì)底層的優(yōu)化，如果需要真正部署在用戶環(huán)境，仍然需要優(yōu)化。

　　Kamalio/OpenSIPs 可以實(shí)現(xiàn)媒體的處理，但是需要第三方媒體服務(wù)器參與才能支持一個(gè)比較完整的SBC功能。

　　編碼轉(zhuǎn)換需要開發(fā)人員進(jìn)一步投入才能完成，目前，還沒有真正的開源的媒體轉(zhuǎn)換的功能能夠支持大量的媒體轉(zhuǎn)換，過多可能還是有賴于Asterisk或者FreeSWITCH實(shí)現(xiàn)媒體轉(zhuǎn)換的功能。

　　Asterisk或者FreeSWITCH平臺(tái)的SIP和媒體耦合度太緊密，媒體和信令獨(dú)立或分離的可能性不大，這樣的話就可能導(dǎo)致SBC缺乏真正的可拓展性。當(dāng)然，用戶確實(shí)有非常強(qiáng)大的技術(shù)研發(fā)隊(duì)伍也可以進(jìn)一步優(yōu)化。

　　Kamailio/OpenSIPs對(duì)SIP RFC的兼容性支持相當(dāng)強(qiáng)大靈活，但是需要非常高的技術(shù)要求。

　　個(gè)人覺得，目前比較可行的企業(yè)級(jí)SBC開源解決方案是Kamailio做信令服務(wù)器，F(xiàn)reeSWITCH作為一個(gè)媒體服務(wù)器，負(fù)責(zé)錄音和編碼轉(zhuǎn)換。編碼轉(zhuǎn)換可以使用基于硬件的編碼轉(zhuǎn)換卡來獲得編碼能力的支持，并且編碼處理能力也可以做分布式部署拓展發(fā)布。關(guān)于此開源解決方案具體的部署方式，用戶可以訪問Kamailio或FreeSWITCH官方網(wǎng)站獲得詳細(xì)配置文件。

　　使用OpenSIPS作為SBC來使用，OpenSIPS本身支持B2BUA模塊，也可以實(shí)現(xiàn)SBC的功能，而且結(jié)合編碼轉(zhuǎn)換卡可以實(shí)現(xiàn)編碼轉(zhuǎn)換的功能，但是仍然缺乏媒體服務(wù)器的支持，還是需要依賴第三方的媒體服務(wù)器實(shí)現(xiàn)媒體的控制。

　　在本章節(jié)中，我們簡(jiǎn)單回顧了以前章節(jié)的一些NAT解決方案的內(nèi)容和存在的問題，然后介紹了SBC的產(chǎn)生背景，SBC的用戶場(chǎng)景和SBC的主要功能，同時(shí)，我們也探討了SBC在部署時(shí)需要用戶注意到問題，還有目前SBC對(duì)SIP的影響，最后我們分別介紹了SBC的虛擬化可行性研究探討和基于開源解決方案的簡(jiǎn)單論述。通過以上大篇幅的介紹，我們希望給用戶一個(gè)比較完整的SBC解決方案的剖析，然后用戶要根據(jù)自己的使用場(chǎng)景，部署成本，可維護(hù)性，拓展性做一個(gè)正確的評(píng)價(jià)。最后，因?yàn)閭�(gè)人能力有限和篇幅的局限，很多技術(shù)細(xì)節(jié)沒有深入太多討論，也可能出現(xiàn)很多錯(cuò)誤，希望諒解指正。

　　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呼叫實(shí)現(xiàn)網(wǎng)絡(luò)偵聽對(duì)SBC性能影響：Implementation and Performance for Lawful Intercept of VoIP calls based on SIP Session Border Controller