世界進入混沌狀態(tài)。這本身就已經(jīng)是一件非常痛苦的事情，更痛苦的是從事VoIP行業(yè)的一些讀者對SIP技術中B2BUA的功能角色也一直是“混沌”的，也經(jīng)常對SIP B2BUA概念產(chǎn)生疑惑。特別是隨著互聯(lián)網(wǎng)，云計算的技術不斷變化，基于SIP技術網(wǎng)絡的各種應用也在不停地發(fā)生變化，SIP服務器端的應用場景也呈現(xiàn)了更多的形態(tài)，從本地部署到混合云，公有云，智能終端部署，邊緣智能終端和計算等等環(huán)境也介入到了企業(yè)網(wǎng)絡環(huán)境中，這些眼花繚亂的變化讓更多技術人員對一些方向性的技術架構產(chǎn)生了更多的疑問，天天面對這個十萬個為什么問題。實際上，具體來說，SIP B2BUA（背靠背代理）其功能根據(jù)實際場景的不同也調整支持了不同的業(yè)務場景。目前很多讀者對SIP B2BUA的理解可能僅僅停留在了媒體服務器或者IPPBX，呼叫中心這這些經(jīng)�？吹降牡湫偷膽�用場景中。在現(xiàn)實環(huán)境中，隨著IMS網(wǎng)絡和SIP技術架構的不斷擴展，其支持的功能出現(xiàn)了更多的場景，包括目前客戶需求激增的IMS必要進入產(chǎn)品-會話邊界控制器（SBC）。所以，在本文章中，筆者希望對讀者提供一個完整的概覽，幫助或者喚醒對SIP B2BUA概念功能仍然混沌的讀者。當然，如果讀者還對SIP技術知識仍然處于“酣睡”的基礎階段，筆者提供的這種“喚醒服務”內容可能對這些讀者也有一定難度，筆者建議讀者可以參考筆者其他關于SIP系列講座基礎歷史文檔學習。

叫醒服務-英國1930時代的服務

　　筆者在以前的文檔中大量介紹過關于B2BUA的分類。但是，那些文章因為主題內容討論的不同，仍然沒有太多細節(jié)的說明。筆者今天針對關于B2BUA實體分類做應該完整的說明，可以進一步幫助讀者完全消化這些林林總總的概念以及其應用場景。事實上，關于B2BUA實體分類是根據(jù)RFC規(guī)范7092來規(guī)范定義的，為了方便更多讀者了解其抽象概念，可能結合一些具體應用場景來加以說明。如果讀者對筆者歷史文檔中關于有興趣的話，可以查閱此歷史文檔鏈接學習。

　　在以上文檔中主要針對B2BUA的主要類型SBC進行說明。本文章中將針對更多的關于B2BUA的實體分類進行說明。在以下圖例中，我們可以看到，SIP信令和RTP媒體流完全實現(xiàn)了解藕（decouple）。

關于SIP協(xié)議B2BUA實體分類架構推薦

　　以上推薦架構可以滿足最新互聯(lián)網(wǎng)云平臺分布式部署和RTP處理的分離，并且可以實現(xiàn)完全兼容IMS網(wǎng)絡環(huán)境或者網(wǎng)絡虛擬化虛擬IMS支持擴展。這種新的部署方式是有其理論依據(jù)的。在RFC7092中，針對SIP實體中B2BUA做了比較詳細的詳解，包括了其B2BUA的實體分類和相關定義。現(xiàn)在，我們針對B2BUA的實體分類進行細節(jié)討論。具體的B2BUA定義分類包括以下幾個大類和子類別。筆者針對這些實體分類角色進行逐一說明。

　　SIP信令面的B2BUA角色是B2BUA經(jīng)常使用的一個角色分類。我們可以根據(jù)其定義大概知道其具體的功能。它主要的功能就是負責信令處理功能， 它僅對SIP 消息和SIP頭進行操作，不涉及對媒體路徑的處理。雖然它可以保存SDP或者對SDP中的MIME進行操作，但是，整體來說，這樣的處理方式不會涉及SDP消息體修改。它進一步細分為以下三個子分類：

　　Proxy-B2BUA，它是基于RFC3261規(guī)范細分的一個SIP代理，也包括其擴展協(xié)議功能，只是它會維持一個足夠的dialog狀態(tài)在在某些場景中生成in-dialog SIP消息。最典型的Proxy-B2BUA常見場景是它會生成一個BYE請求來實現(xiàn)對不再存活的會話的拆線功能支持。根據(jù)RFC3261規(guī)范詳解說明，Proxy-B2BUA不能修改收到的SIP頭消息，例如To，F(xiàn)rom，Contact，Proxy-B2BUA僅能修改Via和Record-Route頭和其擴展。如果Proxy-B2BUA能生成in-dialogSIP消息，它生成自己的信息以后，它也需要修改CSeg頭。另外，Proxy-B2BUA既不能修改MIME消息體（包括SDP），也不能檢查MIME消息體（包括SDP），它對媒體是無感知的，將轉發(fā)任何的method類型。

　　Signaling-only，它運行在SIP層，雖然可以正常轉發(fā)請求，但是超出了RFC3261的SIP代理范圍。例如，這樣的B2BUA可能替換Contact URL，修改或者移除所有的Via和Record-Route頭，修改To和From頭，修改和檢查特定的MIME消息體等。 它可以拷貝任何在UAS端收到的SIP頭到UAC端生成的請求中。這樣的典型的應用場景包括了一些應用服務器，例如IPPBX。這樣的B2BUA代理可以在REFER目標路徑中從邏輯上處理REFER請求，然后生成新的INVITE請求。另外一個例子就是Privacy 服務代理，它對privacy頭進行處理。

　　SDP-Modifying Signaling-only， 此類型的B2BUA僅能夠運行在信令面，不會運行在媒體路徑。但是，它可以修改SDP消息體，對SDP語法和語義有感知。在一些應用場景中，應用服務器或者PBX可以移除某些編碼選項或者合并兩個媒體流為一個SDP offer。這個類型的B2BUA不會修改媒體執(zhí)行的媒體路徑。具體來說，此代理不會把自己插入到媒體路徑中，但是他們可以對SDP做出修改來影響媒體面中需要發(fā)送到媒體內容。

　　SIP信令面/媒體面的B2BUA角色，它可以在SIP面和媒體面進行操作執(zhí)行，包括SDP，RTP和RTCP層面或者其他媒體的執(zhí)行操作。這樣的B2BUA有可能替換Contact URL，修改或移除所有的Via和Record-Route頭，修改To和From頭等。它可以拷貝任何在UAS端收到的SIP頭到UAC端生成的請求中，其SDP也可以被修改。這樣的B2BUA在具體應用場景中包括了目前經(jīng)常使用的SBC，編碼轉換服務器，振鈴音服務器，以及錄音服務器。另外，還有一個例子就是Privacy 服務代理，它對privacy頭進行處理。這樣的B2BUA不需要部署在一臺物理服務器，它可以解耦，獨立部署為信令服務器和媒體服務器。此類型的B2BUA可以進一步劃分為以下幾種B2BUA子類型：

　　Media Relay， 它支持媒體轉發(fā)類型的B2BUA，顧名思義是執(zhí)行一個媒體轉發(fā)的角色，它主要負責終止在UAS和UAC端的IP或者TCP/UDP層的媒體面，但是它不會修改或者限制數(shù)據(jù)包中payload的格式。相反，它可以透明地從一端拷貝到另外一端。因此，它可能僅支持TCP，或者UDP，也可能同時支持TCP和UDP或者其他的傳輸方式。它可能涉及到IP包的管理策略來限定網(wǎng)絡帶寬以及IPv4和IPv6之間的轉換。它所涉及的NAT處理非常類似于NAT雙向操作，但是NAT雙向操作可以執(zhí)行數(shù)據(jù)源和目的地之間的雙向轉換，一些讀者可能在SBC的默認配置場景中看到類似的轉換。

　　Media Aware， 此B2BUA執(zhí)行媒體感知的角色，除了它檢查和可能修改在UDP或者TCP傳輸?shù)膒ayload以外，工作方式類似于媒體轉發(fā)服務器，但是它不會對編碼本身或者更高層級進行處理。比較常見的示例是SRTP終端服務器，這一類型的終端不關注RTP payload，但是它關注RTP header。另外一種終端，它檢測RTCP來獲取QoS值等，還有在5元組中的多路復用和多路復用分離RTP和RTCP的設備等。

　　Media Termination， 此B2BUA承擔媒體終端或者”終止“的角色，它僅在媒體payload層執(zhí)行，例如RTP/RTCP編碼，消息會話轉發(fā)層（MSRP）或者更高層處理。這樣的B2BUA僅可以終止或者生成特有的RTP媒體，例如DTMF撥號音，也可以執(zhí)行媒體編碼轉換。它也可以像背靠背MSRP代理一樣工作，這種工作方式由編碼轉換服務器或者會議服務器來實現(xiàn)。

　　在以上章節(jié)中，我們主要介紹了關于B2BUA的分類和一些子分類。對于讀者來說，大部分的概念理解還是比較抽象的。在RFC7092中，這些分類和子分類都會映射到具體的實際的應用環(huán)境中。讀者通過在實際應用環(huán)境中了解這些概念會比較容易。映射到具體業(yè)務形態(tài)的B2BUA應用場景包括以下幾種：

　　SIP PBXs and Softswitches， 這個類型是讀者經(jīng)�？梢越佑|到的用戶場景。基于SIP的IPPBX或者軟交換可以對SIP層和媒體進行管理修改。這些名稱都是一些市場產(chǎn)品通俗的稱謂，根據(jù)其業(yè)務功能要求，SIP PBX 或者軟交換可以實現(xiàn)以上B2BUA的各種特定功能需求，無標準化的官方說明。因此，建議讀者根據(jù)具體的應用場景來理解B2BUA的映射關系。我們也可能看到，某些提供商產(chǎn)品可能為了市場宣傳，重點突出了某些熱點功能，事實上，軟交換或者基于SIP 的PBX可以實現(xiàn)很多媒體服務層面的需求，這些功能實現(xiàn)完全取決于廠家的定義或者支持水平。

　　Application Servers， 應用服務器包括的類型很多，它可以對SIP頭或者其他字段進行管理也可以修改一些必要的字段。和前面的軟交換或者SIP PBX 類似，在市場上，它本身也沒有特定的官方標準來定義應用服務器的屬性，目前比較官方的定義是在3GPP中對Application Servers（SIP AS， OSA AS， CAMEL IM-SSF等）的具體功能說明和規(guī)范，比如應用服務器中的消息等待指示（MWIs），分機隨行服務等。這些服務有的在SIP信令面執(zhí)行，有的在媒體面執(zhí)行，也有的的提供媒體應用提供終端服務，包括IVR，語音郵箱服務器集成等業(yè)務。

　　Session Border Controllers， 這個類型的B2BUA可以對SIP層消息和媒體進行比較深度的干預管理以及修改。SBC是目前企業(yè)語音通信中部署的主流產(chǎn)品，讀者可以參考RFC5853獲得更多關于SBC功能的介紹，它更多依賴于邏輯功能設置來管理SIP信令和媒體的轉發(fā)處理。默認環(huán)境中，SBC是一個媒體轉發(fā)服務器或者對媒體感知的B2BUA代理服務器，它可以替換Contact URL，修改Via和Record-Route頭，修改Call-ID， To， From等頭域值，并且可以按照路由要求修改SDP。根據(jù)配置策略，SBC可以拒絕某些SIP methods， 也可以透傳某些SIP頭消息字段。讀者也可以觀看以下視頻獲得更多關于SBC的概覽介紹。

　　Transcoders， 這個類型主要針對媒體類型進行必要的修改或者管理，具體來說就是編碼轉換服務器對語音編碼或者視頻編碼進行不同格式的轉換，例如，比較典型的用例就是G.711轉為G.729。盡管它們媒體之間的轉換僅發(fā)生在某些特定需求中的編碼互相不匹配的轉換，像媒體轉換這樣的應用場景，它實際上執(zhí)行了一個典型的媒體-終端或者“終止”服務器角色。關于對SIP編碼轉換有兩種類型的定義規(guī)范，它們分別是RFC5369和RFC5370。在實戰(zhàn)環(huán)境中，比較受歡迎的規(guī)范是后者的處理方式，通過內聯(lián)會議橋接方式來實現(xiàn)B2BUA的角色，而沒有使用請求列表中包含請求源URL的機制實現(xiàn)，通過B2BUA內置SIP編碼轉換器極大簡化了正常請求的路由。SIP編碼轉換架構都基于所有從來自于SIP媒體服務器和SBC到TDM環(huán)路中的必要資源。因此，這樣的處理機制就可以處理整個邏輯流程，從僅替換特定消息頭/消息體和SDP需要執(zhí)行的某些功能到替換幾乎所有的SIP頭和SDP content。一些編碼轉換器可以從UAC中的INVITE保存或移除SDP offer，等待一個從UAS響應的offer，這種處理方式來自于第三方呼叫控制（SPCC）模式。還有一些其他的編碼轉換器可以在SDP offer中插入其他的編碼，如果被插入的編碼類型是answer列表中選擇的編碼類型，則對其進行轉換。

　　Conference Servers， 一般來說，會議服務器的功能定位不能完全符合B2BUA的定義，因為在會議服務器的應用中都涉及了多個各自獨立的UAC發(fā)起的SIP會話，然后這些獨立的會話最后匯聚到單個UAS端。但是，會議服務器支持RFC5366，在此RFC中，會議通過SIP包含請求URL的方式來創(chuàng)建，收到的INVITE請求會觸發(fā)會議對UAS進行中心化處理，然后作為UAC對多個INVITE請求執(zhí)行初始化流程。當執(zhí)行這些功能時，它將以媒體-終端或者“終止”服務器的形式出現(xiàn)。

　　P-CSCF 和 IBCF Functions，3GPP定義了Proxy-Call Session Control Function (P-CSCF)和Interconnection Border Control Function (IBCF)功能，當需要配合IMS媒體面網(wǎng)關（AGW）和轉換面網(wǎng)關TrGW等網(wǎng)關工作時，這些網(wǎng)關也承擔著媒體轉發(fā)和媒體感知的B2BUA的角色。

　　S-CSCF Function，同樣，3GPP IMS也定義了Serving-Call Session Control Function (S-CSCF)，它承擔了Proxy-B2BUA的角色。

　　關于B2BUA在3GPP IMS中會話控制層的接口，讀者可以參閱基于開源SER擴展開發(fā)的FOKUS OpenIMS core的示例來加以說明。更多關于3GPP IMS core，筆者在后期的文檔針對3GPP IMS core中會話控制部分加以詳解說明。

　　在以上章節(jié)中，筆者根據(jù)RFC7092對SIP技術架構中背靠背代理做了深入解讀�？赡茏x者也注意到了這些概念之間存在著互相“沖突和重疊”的內容說明。從理論來說，這些分類是必要的，為我們了解這些模塊提供了指導和技術結構脈絡。但是，在具體應用環(huán)境中，這些分類角色實際上是混合在一起使用部署的。偉大領袖一直告警我們反對教條主義。所以，為了避免我們成為新生代的“杠精” 或者非黑即白者，我們一定不能以絕對化或者簡單化乃至于非常教條的思維去理解這些功能概念。筆者建議，讀者可以從三個比較大的抽象層面理解它們之間的不同。第一個理解層面是根據(jù)SIP信令面和媒體面兩個基本的層級進行分解。另外，讀者必須根據(jù)這些B2BUA對信令控制程度和媒體控制程度加以區(qū)分。并且，在某些具體功能管理實現(xiàn)方面，它們的功能側重點也做出了相應的調整。通過以上幾個角度的分析，我們就基本明確了這些角色分類的必要性。同時，我們也知道，在商業(yè)產(chǎn)品中和環(huán)境中，客戶需求是一個真實的存在，產(chǎn)品定位是根據(jù)具體客戶需求來開發(fā)的，它可能同時支持了多種具體的B2BUA的業(yè)務角色。因此，一個完整的產(chǎn)品是支持多種B2BUA角色功能的，這些產(chǎn)品可以根據(jù)功能需求做靈活設置。比如，一個B2BUA的SIP IPPBX場景中，它可能可以支持SIP 信令中某些消息頭字段的修改，SDP修改，也可以實現(xiàn)編碼轉換功能。當然，它可以根據(jù)具體的業(yè)務場景需求，可能僅對某些功能執(zhí)行轉發(fā)功能。另外一個當前比較常見的B2BUA角色場景是會話邊界控制器-SBC，筆者在很多歷史文檔和本文檔中做了很多的深度解讀和技術討論，它就是一個非常典型的對SIP信令面，媒體面以及業(yè)務功能管理幾個方面深度介入和進行管理的B2BUA角色場景。SBC必須對這些數(shù)據(jù)進行深度介入管理才能作為IMS網(wǎng)絡中核心的網(wǎng)元產(chǎn)品，否則就不能完全接管SIP/IMS接入的需求。當然筆者要提醒讀者，在實際應用環(huán)境中，絕大部分廠家的會話邊界控制器產(chǎn)品根據(jù)自己的開發(fā)定位對功能側重點支持有所不同，但是其核心呼叫控制的邏輯是完全一致的。

　　在本分享文章中，筆者根據(jù)RFC7092對B2BUA做了比較初淺的分享。這些內容涵蓋了RFC7092的基本全部內容。在此文章中針對SIP技術架構中我們經(jīng)�？吹降腂2BUA進行了詳細說明解讀，同時筆者根據(jù)具體B2BUA的分類針對不同的用戶場景和應用做了說明，最后，因為讀者對B2BUA的分類概念比較迷惑，筆者針對這些概念和具體應用，以商業(yè)的角度對根據(jù)三個不同層面來幫助讀者理解這些設計的合理性。

　　筆者再次提醒，對于SIP B2BUA分類僅是一個理論層面的規(guī)范，在實際應用中無此嚴格的規(guī)定和定義。所以，大家仍然需要從理論指導實踐的角度理解B2BUA，同時能夠把這些概念靈活運用到實際用戶環(huán)境中。如果實現(xiàn)了以上的目標，筆者的“喚醒者”的小目標也達到了。
 

　　www.dinstar.com

　　www.asterisk.org.cn

　　https://www.rfc-editor.org/rfc/rfc3261

　　https://datatracker.ietf.org/doc/html/rfc7092

　　https://www.rfc-editor.org/rfc/rfc5366

　　https://www.rfc-editor.org/rfc/rfc5370

　　https://www.rfc-editor.org/rfc/rfc5369

　　https://www.rfc-editor.org/rfc/rfc4975