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

叫醒服務(wù)-英國1930時(shí)代的服務(wù)

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

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

關(guān)于SIP協(xié)議B2BUA實(shí)體分類架構(gòu)推薦

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　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