今天，筆者將對(duì)以上這些問(wèn)題做比較詳細(xì)地分析解釋。我們本次討論將覆蓋，B2BUA和SIP Proxy的區(qū)別，B2BUA的概念，RFC7092規(guī)范，使用B2BUA的原因，3PCC場(chǎng)景，SIP代理和B2BUA如何重構(gòu)SIP消息，SBC和SIP Proxy對(duì)比。
1、為什么使用B2BUA
首先，我們介紹一下使用B2BUA的背景和SIP Proxy的基本概念。根據(jù)RFC3261規(guī)范的定義，SIP Proxy是：
SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients.
https://tools.ietf.org/html/rfc3261#section-16
根據(jù)RFC3261的定義，SIP Proxy主要作用是對(duì)SIP請(qǐng)求的路由。“路由”這個(gè)詞具有多層含義，它負(fù)責(zé)執(zhí)行路由，認(rèn)證，簽權(quán)，地址解析，回環(huán)檢測(cè)和均衡負(fù)載的功能。根據(jù)這些功能，市場(chǎng)上衍生出了很多這些業(yè)務(wù)的SIP服務(wù)器業(yè)務(wù)，包括：注冊(cè)服務(wù)器，簽權(quán)服務(wù)器，DNS服務(wù)器和均衡負(fù)載的服務(wù)器等多種服務(wù)器類型。大家熟悉的開源SIP服務(wù)器Kamalio，OpenSIPS就是比較常用的SIP Proxy。筆者在以前的討論中有對(duì)這些服務(wù)器的介紹，這里不再討論。其具體技術(shù)架構(gòu)如下：
SIP Proxy有分為兩種模式，一種是狀態(tài)代理模式，另外一種是無(wú)狀態(tài)代理模式。關(guān)于這兩種模式的使用場(chǎng)景和各自的工作方式，我們?cè)谝郧暗奈恼轮杏蟹浅Ｍ暾慕榻B，讀者可以查閱歷史完整來(lái)了解它們的功能概念。SIP代理的概念說(shuō)起來(lái)比較抽象，如果沒(méi)有很多SIP使用經(jīng)驗(yàn)的話，一些讀者可能會(huì)產(chǎn)生誤解。
簡(jiǎn)單來(lái)說(shuō)，SIP 代理可以看作是我們生活中某些業(yè)務(wù)場(chǎng)景的代理一樣。例如，如果客戶A正在打高爾夫球，不能出席某個(gè)會(huì)議，他委托公司其他人或者第三方實(shí)體幫助他代理出席某一個(gè)會(huì)議，代理人在現(xiàn)場(chǎng)根據(jù)現(xiàn)場(chǎng)的內(nèi)容，轉(zhuǎn)發(fā)或者通知客戶A。這里，中間代理人實(shí)體實(shí)際上就是一個(gè)會(huì)議的中轉(zhuǎn)人，不承擔(dān)也不執(zhí)行某些主要的業(yè)務(wù)。
通過(guò)以上的介紹讀者應(yīng)該可以明白，事實(shí)上，代理的功能及其有限，IP語(yǔ)音業(yè)務(wù)的很多功能，它不能實(shí)現(xiàn)。另外，SIP代理自己本身不能發(fā)起INVITE請(qǐng)求，這樣就不能滿足IP語(yǔ)音通信的基本呼叫功能。例如，以下的預(yù)付費(fèi)的功能。
如果在簡(jiǎn)單的場(chǎng)景中，雙方進(jìn)行呼叫，通過(guò)Proxy的計(jì)費(fèi)系統(tǒng)可以滿足計(jì)費(fèi)的要求。如果話費(fèi)不足時(shí)，SIP Proxy應(yīng)該自己生成BYE請(qǐng)求，同時(shí)對(duì)雙方終端發(fā)送其生成的請(qǐng)求。事實(shí)上，Proxy自己本身不能生成BYE請(qǐng)求，后續(xù)的請(qǐng)求應(yīng)該由終端生成，而不是Proxy自己。因此，SIP Proxy很難滿足某些復(fù)雜的業(yè)務(wù)功能。
另外，在以前的文章中，我們已經(jīng)討論過(guò)，雙方終端通過(guò)多個(gè)Proxy代理以后，根據(jù)Route Set返回處理流程。但是，在一些情況下，如果終端忽略了Route Set以后，直接通過(guò)呼叫方和被呼叫方，雙方可能進(jìn)行非法呼叫，它們跳過(guò)了代理服務(wù)器，導(dǎo)致業(yè)務(wù)控制層很難對(duì)其進(jìn)行管理。
對(duì)此，一些聰明的開發(fā)人員提出了一個(gè)非常有創(chuàng)造力的設(shè)計(jì)思路，他們建議采用一個(gè)新的技術(shù)架構(gòu)-（背靠背）B2BUA的機(jī)制，通過(guò)背靠背的方式來(lái)實(shí)現(xiàn)業(yè)務(wù)能力的管理和會(huì)話的管理，主要引進(jìn)了我們通常所說(shuō)的B2BUA的概念。
根據(jù)RFC3261對(duì)B2BUA定義，B2BUA-6定義是：
A back-to-back user agent （B2BUA） is a logical entity that receives a request and processes it as a user agent server （UAS）. In order to determine how the request should be answered, it acts as a user agent client （UAC） and generates requests. it maintains dialog state and must participate.
https://tools.ietf.org/html/rfc3261
通過(guò)以上定義，我們可以看出，B2BUA是一個(gè)邏輯實(shí)體，它由一個(gè)UAS和一個(gè)UAC兩個(gè)部分構(gòu)成，分別負(fù)責(zé)接收請(qǐng)求，處理請(qǐng)求和生成請(qǐng)求。B2BUA和SIP代理不同，它必須保持在dialog中所有創(chuàng)建的請(qǐng)求。只有這樣，B2BUA才能完全控制所有需要管理的會(huì)話。B2BUA具體的構(gòu)成如下：
通常來(lái)說(shuō)，SIP 服務(wù)器端是不會(huì)信任任何終端的，因此，UAC發(fā)起呼叫后，首先需要面對(duì)UAS來(lái)進(jìn)行驗(yàn)證，然后才能進(jìn)行下一步的處理。一個(gè)B2BUA支持的基本功能包括：
- 呼叫管理，自動(dòng)呼叫掛斷，呼叫轉(zhuǎn)移等。
- 網(wǎng)絡(luò)連接包括協(xié)議調(diào)整
- 隱藏內(nèi)網(wǎng)地址，終端地址
- 監(jiān)控整個(gè)呼叫狀態(tài)
B2BUA的基本功能和典型的使用場(chǎng)景： 電話會(huì)議，網(wǎng)關(guān)，SBC，IPPBX，電話轉(zhuǎn)接等場(chǎng)景，這些都是通過(guò)3PCC來(lái)實(shí)現(xiàn)。
2、RFC7092對(duì)B2BUA的類別
根據(jù)RFC7092規(guī)范的定義，B2BUA可分為多個(gè)類別，主要包括兩個(gè)主類別和多個(gè)次類別：
- Signaling Plane B2BUA Roles， 其子類別分別包括：Proxy-B2BUA， Signaling-only和 SDP-Modifying Signaling-only。這個(gè)類別中，B2BUA側(cè)重于信令的處理，SDP的管理，它們本身不介于媒體路徑上，所以，它們不能管理RTP頭和payload。
- Signaling/Media Plane B2BUA Roles，其子類別分別包括：Media Relay，Media Aware和Media Termination。扮演信令媒體的B2BUA，它們不僅那個(gè)管理SIP頭，而且可以對(duì)RTP 頭進(jìn)行管理或者修改。通過(guò)此B2BUA處理后的信令和媒體能夠保證雙方的一致性。大家比較熟悉的SBC可以實(shí)現(xiàn)以上這些功能。
通過(guò)以上的分類描述，我們可以通過(guò)以上抽象的概念映射到我們具體的應(yīng)用環(huán)境中。B2BUA可以實(shí)現(xiàn)以下幾個(gè)方面的應(yīng)用場(chǎng)景：
- 基于SIP的IPPBX和軟交換，市場(chǎng)上很多企業(yè)融合通信的IPPBX就是一個(gè)非常典型的B2BUA場(chǎng)景。比較熟悉的開源的Asterisk或FreeSWITCH，以及基于Asterisk引擎的開源IPPBX界面管理系統(tǒng)FreePBX
- 基于應(yīng)用服務(wù)器支持，包括3GPP環(huán)境下的分機(jī)隨行，ACD等服務(wù)
- SBC邊界控制器，筆者已經(jīng)多次介紹
- 編碼轉(zhuǎn)換服務(wù)，支持不同編碼轉(zhuǎn)換，實(shí)現(xiàn)雙方編碼的一致性支持
- 會(huì)議服務(wù)器，通過(guò)B2BUA實(shí)現(xiàn)會(huì)議，以及會(huì)議控制功能，混音等
- P-CSCF和IBCF Functions，支持IMS網(wǎng)絡(luò)中的網(wǎng)關(guān)訪問(wèn)和切換功能
- S-CSCF Function，支持IMS環(huán)境中的Proxy-B2BUA
在RFC7092規(guī)范中定義了具體的角色，但是規(guī)范并沒(méi)有詳細(xì)說(shuō)明應(yīng)用場(chǎng)景的具體的使用方式，讀者可以參考具體的場(chǎng)景示例自己去做進(jìn)一步的研究。在接下來(lái)的章節(jié)，我們重點(diǎn)介紹B2BUA的具體的工作流程和一些媒體管理的細(xì)節(jié)。
3、B2BUA具體呼叫工作流程
通過(guò)上面章節(jié)的介紹，可能讀者已基本掌握了B2BUA的基本概念�，F(xiàn)在我們重點(diǎn)介紹一下B2BUA是如何工作的。首先，這里說(shuō)明，根據(jù)以上對(duì)B2BUA的定義，為了管理雙方的終端和對(duì)會(huì)話進(jìn)行管理，B2BUA需要分別創(chuàng)建兩個(gè)不同的會(huì)話，B2BUA根據(jù)終端的不同，B2BUA可以扮演UAS/UAC的功能，只有這樣，B2BUA才能完全控制雙方的呼叫流程，保證雙方在同一信令路徑上。
以上示例是一個(gè)簡(jiǎn)單的雙方終端呼叫的流程，B2BUA介于兩個(gè)終端之間。此呼叫流程經(jīng)過(guò)了大概四個(gè)步驟。
- UAC對(duì)B2BUA發(fā)起一個(gè)INVITE請(qǐng)求，在B2BUA端，B2BUA是一個(gè)UAS來(lái)接收這個(gè)請(qǐng)求，創(chuàng)建了第一個(gè)會(huì)話來(lái)管理這個(gè)請(qǐng)求。雙方保存了彼此的Route Set 記錄消息。
- 為了對(duì)另外一個(gè)終端發(fā)起INVITE請(qǐng)求，B2BUA同時(shí)也扮演了一個(gè)UAC的角色，它創(chuàng)建了第二個(gè)會(huì)話，并且再次對(duì)下游終端發(fā)起INVITE請(qǐng)求。這里，UAC需要從UAS端拷貝SDP消息和其他必要消息內(nèi)容。然后，UAC對(duì)下游終端發(fā)起INVITE請(qǐng)求。終端接收了INVITE請(qǐng)求，并且保存了Route Set數(shù)據(jù)記錄。
- 為了響應(yīng)INVITE請(qǐng)求，這里，下游終端就會(huì)變成一個(gè)UAS回復(fù)B2BUA 200 OK。B2BUA再次拷貝200 OK的消息，然后通過(guò)UAS再次返回到UAC終端。
- UAC終端收到200 OK以后，保存為Route Set數(shù)據(jù)內(nèi)容。
在最后的握手確認(rèn)時(shí)，終端必須根據(jù)Route Set 返回到B2BUA，因?yàn)槠渲械腃ontact不是另外終端的Contact地址，而是B2BUA的Contact。接下來(lái)，UAC終端繼續(xù)對(duì)B2BUA的UAS發(fā)送ACK消息。這里的UAC 終端必須通過(guò)B2BUA返回到另外一端，而不是直接進(jìn)行ACK的交互，這樣，B2BUA就會(huì)保證對(duì)終端雙方的會(huì)話管理，同時(shí)可以支持其他業(yè)務(wù)功能的實(shí)現(xiàn)，例如，計(jì)費(fèi)功能。
這里，讀者一定要注意，B2BUA負(fù)責(zé)橋接兩個(gè)呼叫的會(huì)話，拷貝必要的消息內(nèi)容。關(guān)于拷貝什么消息，不能拷貝什么消息，我們?cè)诮酉聛?lái)的章節(jié)介紹。另外，B2BUA保持會(huì)話內(nèi)容，兩個(gè)會(huì)話負(fù)責(zé)不同的終端。雙方終端不知道對(duì)端的Contact地址。終端的Contact地址僅是B2BUA的地址。在這一點(diǎn)上，B2BUA和SIP Proxy有著非常明顯的區(qū)別。因此，雙方終端只能通過(guò)B2BUA才能進(jìn)行信令路徑的完整性處理。
另外，一個(gè)比較特殊的場(chǎng)景是呼叫的預(yù)付費(fèi)功能，這也是transparent B2BUA的一個(gè)基本功能。比較簡(jiǎn)單計(jì)費(fèi)的原理如下：
If there is more time left, the B2BUA starts the timer again with the same operations as described above. If there is no more time left, the call legs willbe disconnected by sending BYE messages to all call legs . If either side disconnects the call, the B2BUA stops accounting.
http://mirror.unpad.ac.id/orari/library/library-sw-hw/linux-1/sip/vocal/application/b2bua/b2bua.pdf
事實(shí)上，關(guān)于預(yù)付費(fèi)的復(fù)雜的處理流程，可能需要借助于媒體服務(wù)器的支持，通過(guò)mid-call announcements的方式，對(duì)預(yù)付費(fèi)的電話服務(wù)進(jìn)行語(yǔ)音播放，然后再執(zhí)行掛機(jī)處理。具體的處理方式，讀者查閱RFC3725-3。另外，關(guān)于透明B2BUA的介紹，讀者可以查閱：
Send a BYE request towards one, or even both parties, for example in prepaid applications.
https://tools.ietf.org/html/draft-marjou-sipping-b2bua-01#section-3
根據(jù)計(jì)費(fèi)原理的工作方式，如果計(jì)費(fèi)模塊檢測(cè)到雙方呼叫費(fèi)用出現(xiàn)超額的時(shí)候，這時(shí)，B2BUA會(huì)切換成UAC/UAC的狀態(tài)，同時(shí)對(duì)終端發(fā)送BYE消息。
這里，透明B2BUA的工作方式類似于一個(gè)SIP Proxy，而且仍然利用了B2BUA的其他優(yōu)點(diǎn)。和透明（transparent）B2BUA相對(duì)的是拓展（extended proxy）B2BUA，它可以支持其他的功能設(shè)置。兩者之間沒(méi)有特別明顯的區(qū)別，具體的內(nèi)容，讀者可查閱：
Requirements for a Session Initiation Protocol （SIP） Transparent Back-
To-Back User-Agent （B2BUA）
draft-marjou-sipping-b2bua-00
4、B2BUA功能實(shí)現(xiàn)3PCC討論
B2BUA可以支持很多應(yīng)用功能，比較常見(jiàn)的是3PCC，第三方呼叫控制。第三方呼叫控制實(shí)現(xiàn)了很多用戶場(chǎng)景，包括點(diǎn)擊呼叫，電話轉(zhuǎn)接等功能。這些具體的實(shí)現(xiàn)流程，筆者在以前的文章中有非常詳細(xì)的介紹和消息流程圖，包括18個(gè)呼叫流程，讀者可以查閱。
在3PCC的呼叫中，我們需要明確兩個(gè)主要的定義：3PCC和控制器。根據(jù)RFC3725的定義，這兩個(gè)定義是：
3pcc: Third Party Call Control, which refers to the general ability to manipulate calls between other parties.
Controller: A controller is a SIP User Agent that wishes to create a session between two other user agents.
https://tools.ietf.org/html/rfc3725
在第三方呼叫的規(guī)范中定義了四種第三方呼叫的呼叫模式，其中的控制器就扮演著B2BUA的角色。比較典型的場(chǎng)景就是頁(yè)面點(diǎn)擊呼叫或者轉(zhuǎn)接的處理。
在典型的轉(zhuǎn)接環(huán)境中，兩個(gè)終端可能已經(jīng)接通了呼叫，因?yàn)槠渌脑颍K端可能需要轉(zhuǎn)接此呼叫到第三方。這時(shí)，B2BUA或者控制器就會(huì)對(duì)另外一端掛機(jī)，繼續(xù)保持著和呼叫方會(huì)話。呼叫方收到消息后，再次對(duì)第三方發(fā)送無(wú)SDP的INVITE（不是Option，是一個(gè)INVITE Request without SDP），雙方接通后實(shí)現(xiàn)RTP創(chuàng)建。然后，B2BUA對(duì)另外一端徹底拆線。在整個(gè)流程控制中，B2BUA始終扮演和一個(gè)控制器的作用，會(huì)話互相不影響。關(guān)于3PCC的四種操作流程，讀者可以查閱RFC3725進(jìn)行進(jìn)一步學(xué)習(xí)，規(guī)范分別對(duì)四種流程中INVITE和SDP處理要求有非常詳細(xì)的描述，這里不再討論。
5、SIP Proxy和B2BUA消息重構(gòu)
在前面的討論中，B2BUA是介于兩個(gè)會(huì)話直接的一個(gè)邏輯實(shí)體，為了能夠管理修改和保持雙方的會(huì)話狀態(tài)，B2BUA必須可以修改保存雙方會(huì)話的消息數(shù)據(jù)，這樣才能真正實(shí)現(xiàn)信令路徑和媒體路徑的完整性。因此，在B2BUA作為UAS/UAC角色切換時(shí)，UAS需要拷貝一些SIP消息到UAC，或者相反方向的SIP拷貝重構(gòu)，否則沒(méi)有辦法獲悉從上游過(guò)來(lái)的消息。但是，因?yàn)镾IP協(xié)議中有很多規(guī)范是需要雙方必須遵守的，因此，在拷貝雙方的SIP消息時(shí)，需要考慮哪些SIP消息頭是必須拷貝的，哪些SIP頭是完全可能拷貝的，哪些SIP頭是可以拷貝的。下面，我們通過(guò)一個(gè)示例就以上幾個(gè)問(wèn)題進(jìn)行分析，檢查雙方數(shù)據(jù)映射處理時(shí)重構(gòu)結(jié)果。
我們的示例是一個(gè)簡(jiǎn)單SIP終端通過(guò)B2BUA呼叫（INVITE）遠(yuǎn)端SIP電話。這里，我們?cè)俅螐?qiáng)調(diào)，雙方呼叫的會(huì)話沒(méi)有直接的關(guān)系，這些SIP頭的重構(gòu)完全依賴于B2BUA本身�，F(xiàn)在，我們逐一介紹這些SIP頭的處理。
- 首先，在INVITE中的Request-URL可以拷貝也可以通過(guò)B2BUA自己重新定義。典型的應(yīng)用方式是B2BUA直接拷貝這個(gè)地址。所以，這個(gè)地址是可以直接拷貝的地址。
- Call-ID，根據(jù)RFC3261的定義，它是一個(gè)全局變量，并且具有唯一性，因此，兩個(gè)會(huì)話都分別有各自不同的Call_ID，因此它是不能拷貝的。服務(wù)器端需要自己生成自己的ID。
- Content-Length和Content-Type的處理，雙方的呼叫中，包含了SDP消息和其他下游媒體說(shuō)需要的參數(shù)來(lái)和終端協(xié)商，B2BUA可以利用它們的Content-Length和Content-Type作為另外一個(gè)UA的SDP消息數(shù)據(jù)。因此，這些數(shù)據(jù)是可以拷貝的。當(dāng)然，如果B2BUA進(jìn)行了特別的編碼處理則是另外一個(gè)話題。
- To和From 地址的處理，理論上說(shuō)，B2BUA可以自由選擇自己本身所需要的地址。但是，如果沒(méi)有其他特別的要求，一般來(lái)說(shuō)，B2BUA直接拷貝了另外一個(gè)UA的To地址。From 地址也是一樣的道理，B2BUA可以直接拷貝上游From地址，然后傳遞給下游終端，這樣SIP終端就會(huì)獲悉是哪個(gè)SIP終端的呼叫。當(dāng)然，為了更好管理終端之間的呼叫，B2BUA也可以修改為自己B2BUA的地址，下游SIP終端可以獲悉是來(lái)自于B2BUA地址的3PCC呼叫。
- Contact地址的處理，大家知道，如果呼叫到遠(yuǎn)端SIP終端時(shí)，SIP終端就會(huì)保存Route Set的地址，這個(gè)地址用來(lái)支持后續(xù)的請(qǐng)求處理，這個(gè)Contact地址不應(yīng)該是SIP終端地址，如果是SIP終端地址的話，兩個(gè)分機(jī)就可以實(shí)現(xiàn)直接呼叫。但是，在B2BUA的模式下，這個(gè)Contact地址不能直接拷貝到下游的Contact地址，只能使用本地B2BUA地址，這樣，下游的SIP終端收到的Contact地址就是B2BUA的地址。在呼叫創(chuàng)建時(shí)，下游終端就會(huì)通過(guò)B2BUA地址呼出。這樣，B2BUA始終在呼叫雙方的媒體路徑和信令路徑，保證B2BUA可以控制和管理呼叫流程。因此，這個(gè)Contact地址是不能直接拷貝的。
- 關(guān)于CSeq的處理，根據(jù)RFC3261的定義，CSeq method類型必須反映request method的類型。為了保證請(qǐng)求類型的正確，因此，在B2BUA中CSeq的值可以直接拷貝，也可以重新初始化一個(gè)新的計(jì)算器值。
Max-Forward的處理，因?yàn)镾IP終端設(shè)備可以選擇任何計(jì)算器的值，B2BUA可以自己決定重新設(shè)置為默認(rèn)的計(jì)算器70。另外，因?yàn)樵赟IP路徑經(jīng)過(guò)了一個(gè)Hop，所以B2BUA也可以根據(jù)上游設(shè)備提供的計(jì)算器值，自動(dòng)遞減一次。因此，Max-Forward計(jì)算器值也可以直接拷貝或者直接使用上有的值。
Via 頭的處理。我們?cè)谝郧暗奈恼轮袑ｉT討論了Via的用法，這個(gè)地址通知下游設(shè)備回復(fù)響應(yīng)的地址。上游的Via可能經(jīng)過(guò)了多個(gè)Hop或者Proxy，對(duì)下游SIP終端發(fā)送Via時(shí)，這里的B2BUA不關(guān)心上游Via的結(jié)果，B2BUA僅關(guān)心下游SIP終端返回的響應(yīng)地址，通知下游SIP終端返回到B2BUA的地址，而不是其他的地址。這個(gè)Via地址必須是B2BUA的地址，所以，B2BUA不能直接拷貝上游Via的地址。
根據(jù)以上分析，我們可以看到，在B2BUA的模式下，大部分的SIP頭是可以拷貝重構(gòu)的，Call-ID, Contact 地址和Via是完全不能拷貝的�；旧蠜](méi)有B2BUA必須拷貝的SIP頭。因此，B2BUA是非常靈活，而且具有多種權(quán)限來(lái)管理SIP話話和應(yīng)用服務(wù)。
特別注意，可能有時(shí)出現(xiàn)一些比較特殊的應(yīng)用場(chǎng)景，例如mid-call的應(yīng)用場(chǎng)景（中間播放語(yǔ)音提示或者或其他業(yè)務(wù)流程），如果SIP終端通過(guò)Proxy呼叫一個(gè)功能服務(wù)器，Proxy希望功能服務(wù)器端能夠快速響應(yīng)，收到系統(tǒng)的請(qǐng)求返回到Proxy。但是，因?yàn)槭荁2BUA，功能服務(wù)器可能重新生成一個(gè)Call-ID, 這樣會(huì)導(dǎo)致遠(yuǎn)端的SIP終端產(chǎn)生誤解。如何解決這個(gè)問(wèn)題，B2BUA只能拷貝原來(lái)的Call-ID確保這是一個(gè)同樣的處理流程。具體此細(xì)節(jié)處理在RFC7329-4.5.2有定義。
根據(jù)以上討論，我們可以總結(jié)一些它們之間的區(qū)別。一般情況下，經(jīng)過(guò)Proxy處理的SIP消息具有幾個(gè)方面的特點(diǎn)：大部分的頭是相同的，Proxy沒(méi)有處理這些SIP頭，Max-Forwards是遞減的，而且Via頭增加了一個(gè)Proxy自己的地址。但是，經(jīng)過(guò)了B2BUA的SIP消息是經(jīng)過(guò)重構(gòu)的，因此很多SIP頭可能是不一樣的。SIP消息經(jīng)過(guò)了B2BUA的重構(gòu)以后，SIP消息具有明顯的不同：Contact地址變成了B2BUA的服務(wù)器的地址，Via消息是一個(gè)單列的地址，這個(gè)地址是B2BUA的需要的返回的地址，這里可能是B2BUA的地址。這里的Call-ID可能有例外（前面已經(jīng)討論），可以是同樣的Call-ID。另外，CSeq具有靈活性，可以處理也可以恢復(fù)到默認(rèn)狀態(tài)。
6、其他相關(guān)問(wèn)題討論
除了我們上面討論的B2BUA的SIP消息重構(gòu)以外，筆者在這里和大家討論幾個(gè)和本文章相關(guān)的討論。在很多文章中，包括我們今天的討論中，我們一直使用透明B2BUA（transparent B2BUA）的說(shuō)法。事實(shí)上，根據(jù)IETF組織的草案，透明B2BUA的工作方式類似于一個(gè)特別的Proxy，但是更多利用了UA的功能。透明B2BUA的功能其實(shí)和我們前面介紹的B2BUA功能相似，因此，這里不再累述。因?yàn)橥该鰾2BUA的概念比較寬泛，很多人對(duì)這個(gè)概念有很多爭(zhēng)論，而且在SIP處理方面具有非常強(qiáng)的靈活性，在一般的討論中，筆者建議根據(jù)具體的操作場(chǎng)景來(lái)解釋，或者通過(guò)一定的場(chǎng)景來(lái)理解。
當(dāng)然，transparency（透明）proxy或者B2BUA是一個(gè)無(wú)休止的討論，到底有多透明，事實(shí)上，完全取決于SIP 處理的流程和業(yè)務(wù)場(chǎng)景。Proxy比較透明，因?yàn)樗鼉H實(shí)現(xiàn)了RFC3261的簡(jiǎn)單功能，沒(méi)有涉及太多的SIP消息重構(gòu)和3PCC的處理。為了滿足3PCC或其他業(yè)務(wù)能力，透明B2BUA是一個(gè)非常明確的需求，但是在B2BUA的使用場(chǎng)景中，很多SIP 頭是需要經(jīng)過(guò)UA處理的，例如，我們現(xiàn)在使用的SBC。SBC作為一個(gè)B2BUA需要對(duì)SIP 頭進(jìn)行處理才能實(shí)現(xiàn)拓?fù)潆[藏，協(xié)議正規(guī)化，編碼轉(zhuǎn)換和協(xié)議轉(zhuǎn)換等功能。因此，一些比較專業(yè)的SBC采取了一定的控制機(jī)制來(lái)實(shí)現(xiàn)透明處理（Relay和Transparency）。
我們?cè)谇懊娴恼鹿?jié)中已經(jīng)多次提及B2BUA和SIP Proxy之間的區(qū)別和SIP頭的變化。下面，我們提供幾個(gè)示例結(jié)合以前B2BUA和Proxy的區(qū)別，再次對(duì)SBC功能和SIP Proxy進(jìn)行一個(gè)對(duì)比說(shuō)明以幫助讀者進(jìn)一步了解SBC和Proxy主要區(qū)別。讀者一定要注意標(biāo)注的關(guān)鍵詞部分。
我們可以通過(guò)兩個(gè)示例來(lái)對(duì)比SBC和SIPProxy的消息經(jīng)過(guò)變化。
經(jīng)過(guò)了SBC后，Via 頭變成了SBC的地址，Call-ID發(fā)生了變化，Max-Forwards遞減，Contact頭修改為SBC地址，最后c=和m=發(fā)送了變化，支持RTP和RTCP的創(chuàng)建。如果經(jīng)過(guò)了Proxy以后，SIP Via 頭中插入了新的Via地址，就是Proxy地址，另外，Max-Forwards發(fā)生遞減。其他頭沒(méi)有任何修改和變化。
通過(guò)以上示例，我們基本上可以理解B2BUA或者SBC和SIPProxy的區(qū)別。很多情況下，我們需要檢查系統(tǒng)的日志來(lái)排查問(wèn)題。那么，現(xiàn)在問(wèn)題來(lái)了。如何判斷這些SIP消息是經(jīng)過(guò)Proxy的SIP消息還是B2BUA的SIP消息？這里，我們做一個(gè)簡(jiǎn)單的介紹以幫助讀者能夠非�？焖倥袛嘞到y(tǒng)的SIP消息日志。經(jīng)過(guò)SIP Proxy的系統(tǒng)日志是這樣的：
經(jīng)過(guò)B2BUA 的SIP重構(gòu)以后的消息變化是這樣的：
根據(jù)我們介紹的SIP消息經(jīng)過(guò)Proxy和B2BUA的不同也可以看出兩者之間的不同，它們兩者都基本上完全遵守SIP的規(guī)范和各自的定義。
7、總結(jié)
本文章介紹了B2BUA的基本概念，SIP Proxy和B2BUA的區(qū)別，然后筆者介紹了B2BUA在3PCC中的應(yīng)用場(chǎng)景分析。另外，筆者花費(fèi)時(shí)間對(duì)B2BUA消息重構(gòu)做了非常詳細(xì)地說(shuō)明解析，同時(shí)對(duì)某些SIP頭的處理針對(duì)性地做了強(qiáng)調(diào)，幫助讀者能夠有重點(diǎn)地了解某些規(guī)范支持。最后，筆者對(duì)透明B2BUA處理，B2BUA的透明處理機(jī)制和SIP Proxy的區(qū)別做了討論。
再次說(shuō)明，如果讀者缺少SIP其他方面基礎(chǔ)的介紹，需要查閱筆者的歷史文檔補(bǔ)充這些知識(shí)，這樣可以更好理解本章所學(xué)習(xí)的內(nèi)容。
參考資料：
http://pamelazave.com/b2bua.pdf
https://searchunifiedcommunications.techtarget.com/feature/SIP-protocol-primer-Learn-the-SIP-basics
https://www.eetimes.com/document.asp?doc_id=1203045#
https://support.sonus.net/display/SBXDOC42/SBC+SIP+Transparency+Implementation+Guide#SBCSIPTransparencyImplementationGuide-2.1SIPProxyvs.SIPB2BUA
https://www.opensips.org/Documentation/Tutorials-B2BUA
https://www.nextiva.com/blog/sip-proxy-server.html
https://mailarchive.ietf.org/arch/msg/sip/5qPeWiY5n_c1h0pKX1udIFQJADk
https://www.youtube.com/watch?v=Zd172eYr5nw
https://github.com/sippy/b2bua
https://tools.ietf.org/html/rfc7092
https://thanhloi2603.wordpress.com/2017/04/23/what-is-the-main-difference-between-sip-proxy-and-b2bua/
關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的IP通信行業(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
