SBC的七大核心功能，包括基本要求，技術(shù)架構(gòu)帶來的問題，流程示例

　　1、這里，筆者簡(jiǎn)單通俗地介紹一下SBC的誕生。因?yàn)樽罱鼛啄甑腎P化過程越來越快，運(yùn)營(yíng)商對(duì)語(yǔ)音服務(wù)的能力支撐也發(fā)生了很多變化。IMS網(wǎng)絡(luò)是其中的一個(gè)重要里程碑。如果不同運(yùn)營(yíng)商之間對(duì)接時(shí)，首先需要安全方面的保證，同時(shí)需要兩個(gè)網(wǎng)絡(luò)之間可以實(shí)現(xiàn)良好地兼容性支持。因此兩個(gè)運(yùn)營(yíng)商都需要在網(wǎng)絡(luò)邊界的地方做一些管理控制來支持運(yùn)營(yíng)商自己的業(yè)務(wù)流程，而且能夠支持第三方運(yùn)營(yíng)商對(duì)接的業(yè)務(wù)協(xié)議規(guī)范。為了保證幾個(gè)運(yùn)營(yíng)商之間的對(duì)接連接，也為了保證運(yùn)營(yíng)商本身的業(yè)務(wù)安全，因此，需要一個(gè)邊界會(huì)話控制的設(shè)備或者解決方案來扮演一個(gè)邊界控制的角色。SBC就因此逐漸出現(xiàn)在了通信產(chǎn)品的市場(chǎng)上。

　　盡管現(xiàn)在市場(chǎng)上很多的SBC廠家，每個(gè)廠家都有各自不同的特點(diǎn)，而且很多時(shí)候，廠家之間的兼容性也存在很多的問題，但是因?yàn)槭袌?chǎng)需求的原因，所以很多運(yùn)營(yíng)商客戶和企業(yè)客戶仍然需要SBC這個(gè)產(chǎn)品。今天，RFC5835協(xié)議中重點(diǎn)討論的是如何使用SBC來保證運(yùn)營(yíng)商的需求，同時(shí)說明這些架構(gòu)中存在的一些問題，讓客戶明白目前存在的這些問題，以便能夠讓客戶在部署SBC方案時(shí)有充分的論證。

　　客觀地說，目前沒有一個(gè)關(guān)于SBC的標(biāo)準(zhǔn)功能的明確說明。很多廠家基本上都支持大部分客戶需要的功能。一般的SBC會(huì)部署在兩個(gè)運(yùn)營(yíng)商網(wǎng)絡(luò)之間，來支持peering的網(wǎng)絡(luò)環(huán)境，也可能部署在主干網(wǎng)絡(luò)和企業(yè)客戶之間實(shí)現(xiàn)access 網(wǎng)絡(luò)環(huán)境。他們都會(huì)提供基于會(huì)話的媒體服務(wù)，包括權(quán)限訪問控制，防攻擊，NAT服務(wù)，流量管理，終端集成等相關(guān)功能。當(dāng)然，終端也可能提供一些類似功能，實(shí)現(xiàn)一些或者部分的SBC功能，例如編碼轉(zhuǎn)換，簡(jiǎn)單訪問控制等功能。

　　2、基于SIP的SBC一般來說可以提供對(duì)信令和會(huì)話的處理，工作方式可以看作是一個(gè)私有服務(wù)處理，執(zhí)行對(duì)header的私有服務(wù)處理。在進(jìn)行私有參數(shù)進(jìn)行處理時(shí)就可能涉及一些SIP header，session的修改。關(guān)于SIP privacy的處理機(jī)制，用戶可以參考RFC3323進(jìn)行進(jìn)一步的學(xué)習(xí)。SBC需要修改一些SIP header和消息體來保證服務(wù)的成功，但是proxy則不會(huì)支持這樣的操作。我們以前介紹過，SBC一般來說就是一個(gè)B2BUA，SBC可以修改一些必要的SIP數(shù)值。SBC是一個(gè)透明代理，它可以根據(jù)功能的需求來執(zhí)行一些必要的修改。以下是一個(gè)SBC的簡(jiǎn)單技術(shù)架構(gòu)，通過配置SBC可以實(shí)現(xiàn)對(duì)inner network的管理。

　　一些SBC的操作支持用戶準(zhǔn)許的，對(duì)用戶本身沒有什么影響。但是一些SBC的應(yīng)用場(chǎng)景中，SBC的操作是沒有支持用戶準(zhǔn)許的，SBC可以修改一些必要的SIP消息來完成某些運(yùn)營(yíng)商或第三方的要求。因此，這樣的結(jié)果就會(huì)導(dǎo)致一些潛在的問題。在某些應(yīng)用場(chǎng)景中，運(yùn)營(yíng)商可以強(qiáng)制要求企業(yè)用戶的SIP服務(wù)必須通過SBC來實(shí)現(xiàn)互聯(lián)互通，而在另外的場(chǎng)景中，運(yùn)營(yíng)商為了滿足編碼轉(zhuǎn)換的要求，可能需要把SBC部署在企業(yè)語(yǔ)音網(wǎng)關(guān)的前端來實(shí)現(xiàn)編碼轉(zhuǎn)換。下面，我們介紹一下SBC的兩種部署方式：Peering 模式和Access 模式。

　　在Peering 模式環(huán)境下，兩個(gè)運(yùn)營(yíng)商的服務(wù)通過SBC來進(jìn)行對(duì)接，運(yùn)營(yíng)商之間互相進(jìn)行數(shù)據(jù)通信。當(dāng)運(yùn)營(yíng)商A 對(duì)SBC發(fā)起一個(gè)INVITE時(shí)，SBC會(huì)轉(zhuǎn)發(fā)此INVITE到運(yùn)營(yíng)商B的軟交換（SS-B），軟交換SS-B經(jīng)過路由處理以后，SS-B 會(huì)redirct 3xx 消息到SBC，SBC 然后路由到運(yùn)營(yíng)商B中的GW-B1終端。 如果運(yùn)營(yíng)商B沒有部署SBC，這軟交換會(huì)直接回復(fù)給運(yùn)營(yíng)商A發(fā)起INVITE 的網(wǎng)關(guān)。

　　如果從SBC的網(wǎng)絡(luò)角度，結(jié)合前面的圖例，我們可以看出，這里的運(yùn)營(yíng)商A就是outer network，運(yùn)營(yíng)商B則是inner network。運(yùn)營(yíng)商B使用SBC來保護(hù)自己的內(nèi)網(wǎng)網(wǎng)關(guān)，軟交換，進(jìn)行數(shù)據(jù)管理。運(yùn)營(yíng)商B可以簡(jiǎn)化自己的網(wǎng)絡(luò)，實(shí)現(xiàn)最少的ACL用戶的管理，運(yùn)營(yíng)商B內(nèi)網(wǎng)的網(wǎng)關(guān)，軟交換和其他媒體服務(wù)器沒有暴露在peer的網(wǎng)絡(luò)中，運(yùn)營(yíng)商完全通過SBC避免了網(wǎng)絡(luò)的暴露，實(shí)現(xiàn)了嚴(yán)格的安全控制。

　　在Access的部署場(chǎng)景中，SBC需要部署在outer 網(wǎng)絡(luò)或者access 的網(wǎng)絡(luò)和運(yùn)營(yíng)商的邊界。這里的運(yùn)營(yíng)商網(wǎng)絡(luò)就是一個(gè)inner network網(wǎng)絡(luò)。因?yàn)镾BC是呼叫 stateful的，它可以實(shí)現(xiàn)訪問的控制，例如訂閱功能的設(shè)定，防止服務(wù)器過載。SBC可以作為終端的outbound proxy地址。SBC則可以運(yùn)營(yíng)商的proxy部署支持。

　　這里的SBC可以根據(jù)終端用戶的實(shí)際情況，可以部署在一般的企業(yè)用戶側(cè)，也可以部署在運(yùn)營(yíng)商側(cè)。無論如何部署，實(shí)際上，運(yùn)營(yíng)商都可以控制SBC的訪問和對(duì)外部網(wǎng)絡(luò)的保護(hù)。

　　大部分情況下，終端會(huì)部署在在企業(yè)客戶場(chǎng)景中（如以上圖例所示），本身可能面對(duì)NAT的問題。這里的Access 網(wǎng)絡(luò)可能就是一個(gè)私網(wǎng)環(huán)境。SBC可以通過修改Path header或者Contact Header來實(shí)現(xiàn)NAT的轉(zhuǎn)換。關(guān)于如何通過Path添加一個(gè)SIP 節(jié)點(diǎn)記錄的技術(shù)細(xì)節(jié)，以及Path和Record-Router的不同，用戶可以參考RFC3327來進(jìn)一步學(xué)習(xí)。

　　這里，我們會(huì)介紹SBC的七大核心功能，這里的七大功能僅是RFC5853中所涵蓋的功能要求，不會(huì)涉及具體廠家的第三方功能。我們主要介紹SBC的七大核心功能，架構(gòu)所帶來的問題和流程示例。根據(jù)RFC5835的說明，SBC所具備的七大SBC核心功能包括：

　　1.1 背景介紹

　　拓?fù)潆[藏的主要目的是運(yùn)營(yíng)商不想把運(yùn)營(yíng)商網(wǎng)絡(luò)中的網(wǎng)關(guān)，軟交換，應(yīng)用服務(wù)器等相關(guān)的信息暴露給外部網(wǎng)絡(luò)。這樣可以防止來自外部的網(wǎng)絡(luò)攻擊。同時(shí)，運(yùn)營(yíng)商也不能把運(yùn)營(yíng)商網(wǎng)絡(luò)的所有內(nèi)部網(wǎng)關(guān)，媒體服務(wù)器，其他軟交換暴露給終端客戶。一般的拓?fù)潆[藏的實(shí)現(xiàn)方式是通過截取Via和Record-Route header，替換Contact header甚至于通過修改call-IDs的方式來實(shí)現(xiàn)。但是，在實(shí)際部署環(huán)境中，SBC替換一些header時(shí)會(huì)面對(duì)很多的問題，一些IP地址和header值也不能移除。使用SBC的IP地址可替換這些IP地址來實(shí)現(xiàn)網(wǎng)絡(luò)拓?fù)潆[藏方式。有很多種拓?fù)潆[藏的方式，其中一種，在信令路徑中插入一個(gè)中間節(jié)點(diǎn)就是其中一種方式，SBC就是這種方式的典型代表。另外的方式也可以使用User-Agent-Driven Privacy Mechanism 來實(shí)現(xiàn)，具體的規(guī)定用戶可以參考rfc5767。

　　拓?fù)潆[藏架構(gòu)帶來的問題也是非常明顯的。因?yàn)�，SBC沒有獲得用戶準(zhǔn)許，修改了用戶的信息來實(shí)現(xiàn)網(wǎng)絡(luò)拓?fù)潆[藏。這里的用戶是基于Hop-By-Hop的信任模式來進(jìn)行通信的，而不是End-to-End 信任模式實(shí)現(xiàn)，因此是沒有獲得用戶準(zhǔn)許的。SBC是修改了很多的用戶私有消息，安全信息才能實(shí)現(xiàn)用戶的要求，用戶沒有辦法區(qū)別是來自于SBC的呼叫還是中間人（MITM）的攻擊。另外，SBC可能導(dǎo)致身份認(rèn)證機(jī)制失敗。因?yàn)樯矸菡J(rèn)證機(jī)制（RFC4474）是通過From, To, Call-ID， CSeq， Date，Contact和消息體構(gòu)成，認(rèn)證機(jī)制是通過四個(gè)步驟，基于哈希值獲得的。如果SBC沒有提供認(rèn)證服務(wù)的話，修改過的SIP消息通過認(rèn)證機(jī)制計(jì)算后可能出現(xiàn)安全認(rèn)證失敗。

　　現(xiàn)在，我們通過一個(gè)示例來看一下如何修改Record-Route和Via實(shí)現(xiàn)拓?fù)潆[藏。SBC（p4.domain.example.com）收到的INVITE消息，修改前的信息是：

　　經(jīng)過SBC修改以后，移除了Via和Record-Route，保存了修改記錄后，實(shí)現(xiàn)了拓?fù)潆[藏，地址修改INVITE的SIP消息修改為 SBC的地址：

　　SBC會(huì)保存所有相關(guān)的修改記錄，如果SBC重新啟動(dòng)或者出現(xiàn)故障的話，這里的會(huì)話記錄可能會(huì)丟失。這里，除了SBC可以實(shí)現(xiàn)拓?fù)潆[藏以外，SBC也可以實(shí)現(xiàn)身份隱藏，例如訂閱身份的隱藏。SBC可以修改Contact header值或其他和身份修改的值域來實(shí)現(xiàn)身份隱藏，其修改的身份信息包括：P-Asserted-Identity，Referred-By，Identity和Identity-Info。這些參數(shù)的修改完全取決于用戶的實(shí)際要求。這里不再繼續(xù)展開。

　　2.1 背景介紹

　　SBC的媒體流量管理功能的目的是控制媒體理論，并且對(duì)其進(jìn)行管理。運(yùn)營(yíng)商需要對(duì)訂閱的用戶進(jìn)行媒體流量管理。一個(gè)重要任務(wù)就是對(duì)訂閱用戶根據(jù)不同的業(yè)務(wù)進(jìn)行不同的計(jì)費(fèi)，例如視頻呼叫或者語(yǔ)音呼叫。另外，根據(jù)用戶訂閱的要求，實(shí)現(xiàn)對(duì)用戶實(shí)現(xiàn)強(qiáng)制編碼使用。

　　很多情況下，根據(jù)一些運(yùn)營(yíng)商或者國(guó)家相關(guān)的法律規(guī)定，需要對(duì)某些呼叫進(jìn)行監(jiān)聽。運(yùn)營(yíng)商可以通過監(jiān)聽設(shè)備來實(shí)現(xiàn)對(duì)呼叫話務(wù)的監(jiān)聽，而無需SBC。大家知道，一般情況下，信令路徑和媒體路徑是完全不同的，信令路徑必須通過運(yùn)營(yíng)商，但是媒體路徑是不一定的。除非SBC修改了媒體的路徑，這樣，媒體才能經(jīng)過SBC。SBC通過修改媒體描述可以強(qiáng)制媒體轉(zhuǎn)發(fā)。這樣的話，可以支持QoS服務(wù)和強(qiáng)制使用運(yùn)營(yíng)商指定的編碼（例如，強(qiáng)制使用G.729等）。還有一些運(yùn)營(yíng)商可能不會(huì)對(duì)媒體進(jìn)行管理，因?yàn)槟承�業(yè)務(wù)的規(guī)定，可以對(duì)某些已訂閱的用戶進(jìn)行檢測(cè)流量。使用SBC來管理媒體還可以對(duì)呼叫的“Bye 消息丟失”進(jìn)行處理。很多情況下，終端因?yàn)槟承┰�因，例如網(wǎng)絡(luò)問題或者終端突然不能正常工作，可能出現(xiàn)丟失Bye消息的問題。丟失Bye消息可能導(dǎo)致很多的問題，首先用戶體驗(yàn)不好，其次，對(duì)終端用戶計(jì)費(fèi)失去控制，出現(xiàn)計(jì)費(fèi)錯(cuò)誤等。SBC會(huì)使用VAD或者其他手段檢測(cè)到用戶用戶的媒體處于無流量狀態(tài)，SBC發(fā)送一個(gè)Bye消息到終端用戶。最后，如果終端用戶在呼叫過程中出現(xiàn)欠費(fèi)問題，運(yùn)營(yíng)商可以及時(shí)檢測(cè)到此問題，同時(shí)發(fā)送一個(gè)計(jì)費(fèi)提示或者結(jié)束呼叫。

　　2.2 技術(shù)架構(gòu)問題

　　SBC對(duì)媒體流量進(jìn)行管理會(huì)帶來很多的技術(shù)問題。通常情況下，因?yàn)镾BC需要修改SIP的會(huì)話描述來實(shí)現(xiàn)對(duì)媒體的管理。但是，如果終端對(duì)媒體或者信令進(jìn)行了加密處理的話，那么SBC就可能不能正常工作。如果SBC進(jìn)行了會(huì)話描述的修改，則會(huì)破壞用戶的準(zhǔn)許，而且終端用戶沒有辦法正確判斷是SBC執(zhí)行的流程還是中間人攻擊的流程。另外，如果SBC在媒體路徑中插入了媒體轉(zhuǎn)發(fā)的服務(wù)，此服務(wù)如果不能正常工作或者缺乏良好地兼容性的話，SBC的媒體轉(zhuǎn)發(fā)服務(wù)可能破壞IP和傳輸層某些功能需求，例如反饋協(xié)議失�。‥CN）或最大傳輸單元的問題（PMTUD）。這里讀者還要注意，如果SBC來集中處理媒體的話，可能導(dǎo)致SBC服務(wù)器的負(fù)載增加，同時(shí)可能導(dǎo)致媒體路徑轉(zhuǎn)發(fā)路徑的阻塞，出現(xiàn)語(yǔ)音質(zhì)量問題和遲延。

　　2.3 示例

　　SBC對(duì)媒體管理的應(yīng)用示例中就會(huì)說明在B2BUA的環(huán)境中，SBC如何實(shí)現(xiàn)修 改編碼的管理。SBC收到一個(gè)從outer 網(wǎng)絡(luò)來的INVITE，這里的outer網(wǎng)絡(luò)是Access 模式的SBC網(wǎng)絡(luò)環(huán)境。SIP的修改前的SDP 消息如下：

　　經(jīng)過媒體協(xié)商，SBC的媒體管理功能修改后的消息如下，其中重寫了m=行，移除了a=rtpmap:98 L16/16000/2：

　　在實(shí)際部署環(huán)境中，很多不同的終端支持了不同的編碼支撐能力，而且可能出現(xiàn)很多新的編碼支持能力，所以需要SBC能夠同時(shí)支持不同編碼之間的協(xié)商，保證各種終端能夠完全正常工作，這對(duì)于SBC的性能和處理會(huì)話描述的能力是一個(gè)非常大的挑戰(zhàn)。

　　3.1 背景介紹

　　SBC的修復(fù)支持能力錯(cuò)誤匹配功能可以支持不同終端用戶和不同拓展的通信。SBC可以支持普通SIP用戶連接3GPP網(wǎng)絡(luò)，終端雙方具有不同的IP地址版本，不同的編碼格式，或者不同的地址realms。SBC可以對(duì)這些支撐能力進(jìn)行匹配，最后實(shí)現(xiàn)正常的業(yè)務(wù)需求。另外，在實(shí)際部署環(huán)境中，SIP終端可能支持很多不同的拓展和methods，SBC修復(fù)這些支撐能力。

　　3.2 技術(shù)架構(gòu)問題

　　和前面討論的媒體流量管理一樣，如果要求SBC支撐不同的能力，并且對(duì)其加以修復(fù)的話，SBC需要在媒體路徑插入一些必要的SIP SDP描述。這樣的話，SBC也沒有經(jīng)過用戶準(zhǔn)許，它破壞了端對(duì)端的安全機(jī)制，也破壞了應(yīng)用場(chǎng)景的協(xié)商機(jī)制。如果大量終端用戶需要支撐能力修復(fù)的話，SBC就會(huì)產(chǎn)生很高的負(fù)載，最終導(dǎo)致SBC需要同時(shí)并行處理大量的錯(cuò)誤匹配修復(fù)任務(wù)。

　　3.1 示例

　　SBC錯(cuò)誤匹配功能的修復(fù)有很多示例�，F(xiàn)在來看一個(gè)簡(jiǎn)單的示例，終端用戶IP地址的修復(fù)，從IPv4 修改到IPv6。這里的inner network是一個(gè)Access 網(wǎng)絡(luò)，帶了IPv4的地址，outer 網(wǎng)絡(luò)帶了IPv6的地址。SBC從Access 網(wǎng)絡(luò)收到了一個(gè)INVITE消息，帶有以下會(huì)話描述：

　　經(jīng)過SBC的錯(cuò)誤匹配修復(fù)以后，SBC添加了Record-Route, 另外一個(gè)Via，增加了一行帶IPv6的c=。以下消息會(huì)發(fā)送到IPv6的網(wǎng)絡(luò)中。

　　4.1 背景介紹

　　SBC必須支持NAT相關(guān)的綁定來保證NAT功能的實(shí)現(xiàn)。這里的NAT指的是通過特別的消息修改來幫助終端用戶保持一個(gè)SIP的媒體有效的媒體連接。通常情況下，位于NAT后的終端用戶和代理或注冊(cè)服務(wù)器，或者其他的終端需要一個(gè)持續(xù)連接的狀態(tài)來保證終端用戶的有效性。SBC的NAT相關(guān)綁定功能就是為了控制NAT后的終端用戶的連接性。SBC通過周期性地生成網(wǎng)絡(luò)流量來支持綁定的生命周期。SBC的相關(guān)NAT綁定功能要求SBC是在NAT之外。

　　SBC的NAT綁定功能支持NAT后的終端用戶和注冊(cè)服務(wù)器之間的通信。NAT問題普遍存在于各種網(wǎng)絡(luò)環(huán)境中，運(yùn)營(yíng)商要求支持注冊(cè)服務(wù)的功能。但注冊(cè)服務(wù)器收到了來自于終端用戶的REGISTER請(qǐng)求時(shí)，它會(huì)回復(fù)一個(gè)200 OK的響應(yīng)消息給終端用戶，這里的SBC需要修改一個(gè)響應(yīng)消息，降低注冊(cè)的認(rèn)證時(shí)間響應(yīng)。這樣的話，SBC就需要強(qiáng)制用戶很快重新發(fā)送一個(gè)新的REGISTER請(qǐng)求來保持一個(gè)生命周期的存活，終端用戶在NAT環(huán)境中能夠始終保持綁定狀態(tài)，不會(huì)出現(xiàn)綁定超時(shí)的問題。 這里，讀者要注意，SBC無需轉(zhuǎn)發(fā)所有從終端用戶來的注冊(cè)請(qǐng)求消息到注冊(cè)服務(wù)器。在注冊(cè)超時(shí)之前，SBC會(huì)自己對(duì)來自終端的注冊(cè)請(qǐng)求重新生成對(duì)注冊(cè)服務(wù)器的響應(yīng)消息，保證注冊(cè)不會(huì)超時(shí)。另外，SBC同樣需要控制終端用戶注冊(cè)失敗的流程，如果終端用戶沒有注冊(cè)成功的話，即使這個(gè)注冊(cè)請(qǐng)求在注冊(cè)服務(wù)器仍然處于有效狀態(tài)，SBC需要執(zhí)行一個(gè)業(yè)務(wù)處理，它不再為此終端用戶發(fā)起注冊(cè)請(qǐng)求。這也是很多實(shí)際工作場(chǎng)景中，一些終端用戶為什么有時(shí)會(huì)出現(xiàn)注冊(cè)失敗的原因。以上所介紹的是關(guān)于信令方面的綁定設(shè)置，SBC同樣也可以為了NAT強(qiáng)制媒體轉(zhuǎn)發(fā)。這里不再做過多討論。

　　4.2 技術(shù)架構(gòu)問題

　　SBC支持了NAT綁定的功能以后，技術(shù)架構(gòu)同樣也面臨很多問題。如果一些安全機(jī)制處理方式使用了S/MIME的話，SBC實(shí)現(xiàn)的NAT相關(guān)綁定不能支持端-對(duì)-端的安全機(jī)制或安全保護(hù)機(jī)制。因?yàn)�，這里，SBC被認(rèn)為是MITM中間人攻擊的角色，SBC需要修改終端用戶和注冊(cè)服務(wù)器之間的消息體。另外一個(gè)問題是和SBC設(shè)置的注冊(cè)生命周期相關(guān)。SBC可能需要這個(gè)時(shí)間設(shè)置越高越好。為了保持生命周期的存活，這個(gè)生命周期可能需要調(diào)整在一個(gè)非常合適的值來保持NAT綁定的狀態(tài)。一些SBC產(chǎn)品可能沒有這么非常靈活的設(shè)置，同時(shí)，終端用戶的網(wǎng)絡(luò)環(huán)境差異也非常大，所以可能導(dǎo)致用戶的NAT綁定出現(xiàn)問題。SBC的NAT相關(guān)綁定功能也可能引起媒體處理的問題。SBC通常情況下會(huì)猜測(cè)媒體流中接收方公網(wǎng)IP地址，這個(gè)媒體流可能是這個(gè)SBC轉(zhuǎn)發(fā)的，偵測(cè)到的媒體流源地址，也完全可能是同一SBC轉(zhuǎn)發(fā)的媒體流地址。這樣可能出現(xiàn)安全問題和兼容性的問題，或者轉(zhuǎn)發(fā)到錯(cuò)誤目地地。網(wǎng)絡(luò)攻擊者可以偵測(cè)到SBC中的媒體轉(zhuǎn)發(fā)的IP地址和端口，對(duì)這些地址進(jìn)行發(fā)送數(shù)據(jù)。另外一個(gè)問題是如果在NAT后的終端用戶通過re-INVITE切換了媒體流的IP地址。如果媒體流數(shù)據(jù)出現(xiàn)發(fā)送順序問題或者網(wǎng)絡(luò)時(shí)延，即使re-INVITE可以成功通過，SBC仍然可能會(huì)過濾這個(gè)地址切換后發(fā)送的媒體流數(shù)據(jù)。

　　4.3 示例

　　現(xiàn)在，我們看一個(gè)相關(guān)NAT綁定的示例，此示例說明了通過SBC修改了超時(shí)設(shè)置的參數(shù)。SBC部署在終端用戶和注冊(cè)服務(wù)器之間。SBC收到了以下注冊(cè)響應(yīng)消息：

　　通過SBC相關(guān)綁定的功能修改后的消息如下：

　　當(dāng)然還有其他的方式對(duì)NAT的生命周期進(jìn)行綁定處理，我們這里僅討論在SBC中的功能設(shè)置。

　　5.1 背景介紹

　　SBC需要支持訪問控制功能。訪問控制是運(yùn)營(yíng)商網(wǎng)絡(luò)環(huán)境中一個(gè)必不可少的功能要求，運(yùn)營(yíng)商需要對(duì)人員進(jìn)入到運(yùn)營(yíng)商網(wǎng)絡(luò)內(nèi)部的用戶，業(yè)務(wù)進(jìn)行控制管理。SBC可以設(shè)置成為一個(gè)SIP的防火墻，對(duì)SIP數(shù)據(jù)進(jìn)行流量管理或者路由，同時(shí)SBC的控制管理可以根據(jù)管理員的業(yè)務(wù)要求設(shè)置一定的權(quán)限。

　　SBC的訪問控制功能可以應(yīng)用在信令或信令媒體兩種環(huán)境中。如果SBC的訪問控制功能僅支持了信令的話，SBC可以看作為一個(gè)代理服務(wù)器的角色。如果SBC的訪問控制功能支持了信令和媒體的話，則SBC的訪問控制就被看作是一個(gè)B2BUA的方式，SBC的訪問控制可以對(duì)已認(rèn)證的會(huì)話進(jìn)行媒體轉(zhuǎn)發(fā)處理。

　　SBC的訪問控制功能同樣也可以實(shí)現(xiàn)比較具體的業(yè)務(wù)功能，他們包括：防止DoS攻擊，數(shù)據(jù)的優(yōu)先級(jí)管理/重新路由等相關(guān)功能，執(zhí)行均衡負(fù)載管理/降低設(shè)備的負(fù)載處理。另外，SBC還可以應(yīng)用在一些網(wǎng)絡(luò)帶寬非常限的環(huán)境中。SBC可以計(jì)算用戶根據(jù)編碼支持能力所需的網(wǎng)絡(luò)帶寬。結(jié)合網(wǎng)絡(luò)帶寬的要求，SBC可以在網(wǎng)絡(luò)帶寬耗盡之前拒絕拒絕新的會(huì)話進(jìn)入，同時(shí)能夠保證當(dāng)前會(huì)話的語(yǔ)音質(zhì)量和服務(wù)。否則，網(wǎng)絡(luò)連接就會(huì)出現(xiàn)用戶過載的問題，用戶服務(wù)不能得到充分的保證。當(dāng)然，SBC可以通過一定的拓展，對(duì)接運(yùn)營(yíng)商的業(yè)務(wù)保障服務(wù)器，可以對(duì)基于每個(gè)會(huì)話服務(wù)進(jìn)行策略支持來決定是否網(wǎng)絡(luò)有足夠的帶寬來支持用戶。

　　5.2 技術(shù)架構(gòu)問題

　　SBC的訪問控制功能同樣也需要面對(duì)很多的技術(shù)架構(gòu)的問題，這些問題可能需要拓展其他的應(yīng)用來實(shí)現(xiàn)。很多時(shí)候，SBC設(shè)備是一臺(tái)單點(diǎn)設(shè)備或者基于云部署的解決方案，為了保證大批量用戶的正常工作狀態(tài)，SBC同樣需要雙備份冗余的配置來防止單點(diǎn)設(shè)備故障出現(xiàn)的呼叫丟失或會(huì)話丟失的問題。另外，如果SBC的訪問控制僅實(shí)現(xiàn)的是信令控制的話，其基本架構(gòu)和SIP的其他技術(shù)架構(gòu)是一樣的，讀者僅需要按照一般SIP技術(shù)架構(gòu)來面對(duì)這些問題。如果SBC的訪問控制功能支持了信令和媒體的話，那么訪問控制的技術(shù)架構(gòu)帶來的問題或者挑戰(zhàn)和媒體管理功能是一樣的。

　　5.3 示例

　　SBC的訪問控制實(shí)現(xiàn)示例如以上圖例所示（為了簡(jiǎn)單說明問題，忽略了ACK消息），SBC首先確認(rèn)呼叫方的身份，然后修改會(huì)話描述中的一些SDP參數(shù)。這里，呼叫方需要通過注冊(cè)認(rèn)證服務(wù)器的認(rèn)證。然后，SBC把修改后的消息發(fā)送到被呼叫方，被呼叫方返回200 OK和SDP消息，SBC返回修改的SDP消息和200 OK 到呼叫發(fā)起方。雙方進(jìn)行媒體通信，SBC檢測(cè)協(xié)商的編碼類型是否一致，最后創(chuàng)建媒體流。

　　6.1 背景介紹

　　SBC的協(xié)議修復(fù)功能可以支持一些非標(biāo)準(zhǔn)的，由非標(biāo)準(zhǔn)設(shè)備或終端生成的協(xié)議消息。運(yùn)營(yíng)商可能需要SBC來支持某些協(xié)議修復(fù)的功能來支持更多的終端用戶。這里讀者要注意，協(xié)議修復(fù)功能僅可能影響SBC的信令模塊，協(xié)議修復(fù)功能和協(xié)議轉(zhuǎn)換和完全不同的。

　　6.2 技術(shù)架構(gòu)問題

　　SBC的協(xié)議修復(fù)功能的目的是支持修復(fù)SIP header來兼容SIP的協(xié)議架構(gòu)，它不會(huì)破壞SIP端-對(duì)-端的模式。SBC的協(xié)議修復(fù)消息可以被看作是一個(gè)代理服務(wù)器的處理流程，它們相對(duì)比較寬泛，它可以接受或限制它們發(fā)生的信息。但是，SBC的協(xié)議修復(fù)仍然存在技術(shù)兼容性的問題。協(xié)議修復(fù)可能破壞某些安全機(jī)制，這些安全機(jī)制結(jié)合SIP header使用了不同的算法。需要修復(fù)同樣也會(huì)修改SDP消息體的內(nèi)容，這樣會(huì)導(dǎo)致身份認(rèn)證管理和端對(duì)端安全機(jī)制的兼容性問題。最后，如果進(jìn)行協(xié)議修復(fù)的話，同樣會(huì)導(dǎo)致和修復(fù)支撐能力匹配一樣的問題，SBC的修復(fù)協(xié)議的功能會(huì)更加復(fù)雜。

　　6.3 示例

　　SBC的協(xié)議修復(fù)示例如下圖例所示，這是一個(gè)相對(duì)比較新的用戶的INVITE消息，它經(jīng)過SBC的協(xié)議修復(fù)功能處理以后，在Via header中添加了重寫的參數(shù)lr設(shè)置為true或ON（kamalio rr模塊配置為on）來支持一些非標(biāo)準(zhǔn)的SIP協(xié)議場(chǎng)景需求。

　　7.1 背景介紹

　　SBC同樣也可以支持媒體加密的功能，這也是運(yùn)營(yíng)商或企業(yè)用戶在某些特定場(chǎng)景下所必須支持的功能要求。它可以支持在網(wǎng)絡(luò)邊界處進(jìn)行媒體加密或解密。有一種情況，但媒體加密（例如，SRTP）運(yùn)行在Access網(wǎng)絡(luò)（outer網(wǎng)絡(luò)側(cè)），在inner網(wǎng)絡(luò)中傳輸未加密的媒體流。一些運(yùn)營(yíng)商可以提供合法偵聽，這些運(yùn)營(yíng)商同時(shí)也提供access網(wǎng)絡(luò)的加密處理能力。這樣的話，運(yùn)營(yíng)商就需要SBC具有媒體加密的功能服務(wù)。

　　7.2 技術(shù)架構(gòu)問題

　　SBC的媒體加密技術(shù)架構(gòu)需要在媒體路徑中注入SBC自己的控制參數(shù)，也可能需要其他第三方的實(shí)體注入到媒體路徑。這樣就會(huì)導(dǎo)致前面我們討論的問題，可能出現(xiàn)中間人攻擊的問題。

　　7.3 示例

　　這里我們簡(jiǎn)單介紹一個(gè)SBC媒體加密的處理流程：

　　首先，UAC發(fā)送一個(gè)INVITE請(qǐng)求，第一個(gè)SBC通過自己的方式修改SDP消息，注入自己的媒體路徑。第二個(gè)也執(zhí)行同樣的流程，然后發(fā)送到UAS。UAS 返回 200 OK， SBC 同樣在返回的媒體路徑注入自己參數(shù)。信令交互完成以后，開始媒體互通，兩個(gè)SBC執(zhí)行媒體加密和解密處理。

　　3、以上部分是完整RFC5853的關(guān)于SBC部署的標(biāo)準(zhǔn)協(xié)議。今天的IMS網(wǎng)絡(luò)環(huán)境中，SBC扮演著更加重要的角色。為了讓讀者能夠?qū)�SBC的功能有一個(gè)更加清晰地認(rèn)識(shí)，筆者結(jié)合IMS網(wǎng)絡(luò)，對(duì)SBC在IMS網(wǎng)絡(luò)中的功能做一個(gè)簡(jiǎn)單介紹，讓讀者能夠全面了解SBC的功能和作用。在3GPP的IMS架構(gòu)中，SBC包括了A-SBC（Access Session Border Controller ）和I-SBC（Interconnect Session Border Controller 兩種，它們分別執(zhí)行不同的功能。在下面的介紹中，筆者分別列出了不同的管理模塊，方便讀者做進(jìn)一步的了解。如果讀者需要對(duì)IMS中的SBC做更多了解，讀者可以查閱3GPP技術(shù)細(xì)節(jié)。以下圖例是一個(gè)非常簡(jiǎn)單的兩個(gè)運(yùn)營(yíng)商之間的SBC對(duì)接方式，另外，在IMS核心網(wǎng)中A-SBC所控制的模塊。

　　4、這里，筆者主要列出IMS網(wǎng)絡(luò)中A-SBC和I-SBC各自執(zhí)行的功能，因?yàn)镮MS網(wǎng)絡(luò)中的SBC功能不是我們今天討論的重點(diǎn)，另外篇幅有限，筆者不可能完全展開討論。今天，我們通過簡(jiǎn)單的功能列表配合圖例可以非常清楚地了解IMS中A-SBC和I-SBC的功能，筆者讀者清晰判斷各自的功能。

　　IMS中的A-SBC主要負(fù)責(zé)處理用戶訂閱和IMS核心網(wǎng)的邊界管理。

　　企業(yè)SBC對(duì)接方式，IPPBX下掛SIP終端，網(wǎng)關(guān)等設(shè)備。

　　6、今天，我們?nèi)�面討論了SBC-邊界會(huì)話控制器部署協(xié)議-RFC5853，它是一個(gè)關(guān)于SBC部署的規(guī)范建議，重點(diǎn)說明了SBC的七大核心功能，每個(gè)功能帶來的技術(shù)問題和挑戰(zhàn)，然后通過對(duì)應(yīng)的示例，說明了這些功能的工作流程。這是目前為止，SBC部署最權(quán)威的規(guī)范，讀者可以通過這些規(guī)范了解SBC的功能和部署時(shí)需要注意的問題。結(jié)合IMS網(wǎng)絡(luò)中的SBC子功能，筆者通過完整圖例介紹了IMS網(wǎng)絡(luò)中SBC中的A-SBC和I-SBC的功能，希望能夠幫助讀者完整了解SBC技術(shù)架構(gòu)和相關(guān)規(guī)范。有興趣的讀者可以繼續(xù)根據(jù)IMS網(wǎng)絡(luò)的模塊做進(jìn)一步的學(xué)習(xí)。

　　https://tools.ietf.org/rfc/rfc5853

　　https://www.rfc-editor.org/info/rfc3323

　　https://datatracker.ietf.org/doc/rfc3327/?include_text=1

　　https://datatracker.ietf.org/doc/rfc5767/?include_text=1

　　https://www.rfc-editor.org/rfc/rfc4474.txt

　　https://telcoloewe.wordpress.com/2010/02/10/session-border-controller-sbc-border-gateway-in-3gpp/

　　https://wiki.freepbx.org/display/SBC/SIP+Trunking

　　http://freepbx.org.cn/wiki/index.php?title=SBC%E5%BA%94%E7%94%A8%E5%9C%BA%E6%99%AF

　　關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享

　　Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php

　　Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn

　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com

　　Asterisk/FreePBX中國(guó)合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817