SBC的七大核心功能，包括基本要求，技術架構帶來的問題，流程示例

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

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

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

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

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

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

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

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

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

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

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

　　1.1 背景介紹

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

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

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

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

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

　　2.1 背景介紹

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

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

　　2.2 技術架構問題

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

　　2.3 示例

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

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

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

　　3.1 背景介紹

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

　　3.2 技術架構問題

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

　　3.1 示例

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

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

　　4.1 背景介紹

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

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

　　4.2 技術架構問題

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

　　4.3 示例

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

　　通過SBC相關綁定的功能修改后的消息如下：

　　當然還有其他的方式對NAT的生命周期進行綁定處理，我們這里僅討論在SBC中的功能設置。

　　5.1 背景介紹

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

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

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

　　5.2 技術架構問題

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

　　5.3 示例

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

　　6.1 背景介紹

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

　　6.2 技術架構問題

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

　　6.3 示例

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

　　7.1 背景介紹

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

　　7.2 技術架構問題

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

　　7.3 示例

　　這里我們簡單介紹一個SBC媒體加密的處理流程：

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

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

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

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

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

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

　　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

　　關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享

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

　　Asterisk freepbx技術文檔： www.freepbx.org.cn

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

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