今天，筆者將對以上這些問(wèn)題做比較詳細地分析解釋。我們本次討論將覆蓋，B2BUA和SIP Proxy的區別，B2BUA的概念，RFC7092規范，使用B2BUA的原因，3PCC場(chǎng)景，SIP代理和B2BUA如何重構SIP消息，SBC和SIP Proxy對比。
1、為什么使用B2BUA
首先，我們介紹一下使用B2BUA的背景和SIP Proxy的基本概念。根據RFC3261規范的定義，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
根據RFC3261的定義，SIP Proxy主要作用是對SIP請求的路由。“路由”這個(gè)詞具有多層含義，它負責執行路由，認證，簽權，地址解析，回環(huán)檢測和均衡負載的功能。根據這些功能，市場(chǎng)上衍生出了很多這些業(yè)務(wù)的SIP服務(wù)器業(yè)務(wù)，包括：注冊服務(wù)器，簽權服務(wù)器，DNS服務(wù)器和均衡負載的服務(wù)器等多種服務(wù)器類(lèi)型。大家熟悉的開(kāi)源SIP服務(wù)器Kamalio，OpenSIPS就是比較常用的SIP Proxy。筆者在以前的討論中有對這些服務(wù)器的介紹，這里不再討論。其具體技術(shù)架構如下：
SIP Proxy有分為兩種模式，一種是狀態(tài)代理模式，另外一種是無(wú)狀態(tài)代理模式。關(guān)于這兩種模式的使用場(chǎng)景和各自的工作方式，我們在以前的文章中有非常完整的介紹，讀者可以查閱歷史完整來(lái)了解它們的功能概念。SIP代理的概念說(shuō)起來(lái)比較抽象，如果沒(méi)有很多SIP使用經(jīng)驗的話(huà)，一些讀者可能會(huì )產(chǎn)生誤解。
簡(jiǎn)單來(lái)說(shuō)，SIP 代理可以看作是我們生活中某些業(yè)務(wù)場(chǎng)景的代理一樣。例如，如果客戶(hù)A正在打高爾夫球，不能出席某個(gè)會(huì )議，他委托公司其他人或者第三方實(shí)體幫助他代理出席某一個(gè)會(huì )議，代理人在現場(chǎng)根據現場(chǎng)的內容，轉發(fā)或者通知客戶(hù)A。這里，中間代理人實(shí)體實(shí)際上就是一個(gè)會(huì )議的中轉人，不承擔也不執行某些主要的業(yè)務(wù)。
通過(guò)以上的介紹讀者應該可以明白，事實(shí)上，代理的功能及其有限，IP語(yǔ)音業(yè)務(wù)的很多功能，它不能實(shí)現。另外，SIP代理自己本身不能發(fā)起INVITE請求，這樣就不能滿(mǎn)足IP語(yǔ)音通信的基本呼叫功能。例如，以下的預付費的功能。
如果在簡(jiǎn)單的場(chǎng)景中，雙方進(jìn)行呼叫，通過(guò)Proxy的計費系統可以滿(mǎn)足計費的要求。如果話(huà)費不足時(shí)，SIP Proxy應該自己生成BYE請求，同時(shí)對雙方終端發(fā)送其生成的請求。事實(shí)上，Proxy自己本身不能生成BYE請求，后續的請求應該由終端生成，而不是Proxy自己。因此，SIP Proxy很難滿(mǎn)足某些復雜的業(yè)務(wù)功能。
另外，在以前的文章中，我們已經(jīng)討論過(guò)，雙方終端通過(guò)多個(gè)Proxy代理以后，根據Route Set返回處理流程。但是，在一些情況下，如果終端忽略了Route Set以后，直接通過(guò)呼叫方和被呼叫方，雙方可能進(jìn)行非法呼叫，它們跳過(guò)了代理服務(wù)器，導致業(yè)務(wù)控制層很難對其進(jìn)行管理。
對此，一些聰明的開(kāi)發(fā)人員提出了一個(gè)非常有創(chuàng )造力的設計思路，他們建議采用一個(gè)新的技術(shù)架構-（背靠背）B2BUA的機制，通過(guò)背靠背的方式來(lái)實(shí)現業(yè)務(wù)能力的管理和會(huì )話(huà)的管理，主要引進(jìn)了我們通常所說(shuō)的B2BUA的概念。
根據RFC3261對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è)部分構成，分別負責接收請求，處理請求和生成請求。B2BUA和SIP代理不同，它必須保持在dialog中所有創(chuàng )建的請求。只有這樣，B2BUA才能完全控制所有需要管理的會(huì )話(huà)。B2BUA具體的構成如下：
通常來(lái)說(shuō)，SIP 服務(wù)器端是不會(huì )信任任何終端的，因此，UAC發(fā)起呼叫后，首先需要面對UAS來(lái)進(jìn)行驗證，然后才能進(jìn)行下一步的處理。一個(gè)B2BUA支持的基本功能包括：
- 呼叫管理，自動(dòng)呼叫掛斷，呼叫轉移等。
- 網(wǎng)絡(luò )連接包括協(xié)議調整
- 隱藏內網(wǎng)地址，終端地址
- 監控整個(gè)呼叫狀態(tài)
B2BUA的基本功能和典型的使用場(chǎng)景： 電話(huà)會(huì )議，網(wǎng)關(guān)，SBC，IPPBX，電話(huà)轉接等場(chǎng)景，這些都是通過(guò)3PCC來(lái)實(shí)現。
2、RFC7092對B2BUA的類(lèi)別
根據RFC7092規范的定義，B2BUA可分為多個(gè)類(lèi)別，主要包括兩個(gè)主類(lèi)別和多個(gè)次類(lèi)別：
- Signaling Plane B2BUA Roles， 其子類(lèi)別分別包括：Proxy-B2BUA， Signaling-only和 SDP-Modifying Signaling-only。這個(gè)類(lèi)別中，B2BUA側重于信令的處理，SDP的管理，它們本身不介于媒體路徑上，所以，它們不能管理RTP頭和payload。
- Signaling/Media Plane B2BUA Roles，其子類(lèi)別分別包括：Media Relay，Media Aware和Media Termination。扮演信令媒體的B2BUA，它們不僅那個(gè)管理SIP頭，而且可以對RTP 頭進(jìn)行管理或者修改。通過(guò)此B2BUA處理后的信令和媒體能夠保證雙方的一致性。大家比較熟悉的SBC可以實(shí)現以上這些功能。
通過(guò)以上的分類(lèi)描述，我們可以通過(guò)以上抽象的概念映射到我們具體的應用環(huán)境中。B2BUA可以實(shí)現以下幾個(gè)方面的應用場(chǎng)景：
- 基于SIP的IPPBX和軟交換，市場(chǎng)上很多企業(yè)融合通信的IPPBX就是一個(gè)非常典型的B2BUA場(chǎng)景。比較熟悉的開(kāi)源的Asterisk或FreeSWITCH，以及基于A(yíng)sterisk引擎的開(kāi)源IPPBX界面管理系統FreePBX
- 基于應用服務(wù)器支持，包括3GPP環(huán)境下的分機隨行，ACD等服務(wù)
- SBC邊界控制器，筆者已經(jīng)多次介紹
- 編碼轉換服務(wù)，支持不同編碼轉換，實(shí)現雙方編碼的一致性支持
- 會(huì )議服務(wù)器，通過(guò)B2BUA實(shí)現會(huì )議，以及會(huì )議控制功能，混音等
- P-CSCF和IBCF Functions，支持IMS網(wǎng)絡(luò )中的網(wǎng)關(guān)訪(fǎng)問(wèn)和切換功能
- S-CSCF Function，支持IMS環(huán)境中的Proxy-B2BUA
在RFC7092規范中定義了具體的角色，但是規范并沒(méi)有詳細說(shuō)明應用場(chǎng)景的具體的使用方式，讀者可以參考具體的場(chǎng)景示例自己去做進(jìn)一步的研究。在接下來(lái)的章節，我們重點(diǎn)介紹B2BUA的具體的工作流程和一些媒體管理的細節。
3、B2BUA具體呼叫工作流程
通過(guò)上面章節的介紹，可能讀者已基本掌握了B2BUA的基本概念。現在我們重點(diǎn)介紹一下B2BUA是如何工作的。首先，這里說(shuō)明，根據以上對B2BUA的定義，為了管理雙方的終端和對會(huì )話(huà)進(jìn)行管理，B2BUA需要分別創(chuàng )建兩個(gè)不同的會(huì )話(huà)，B2BUA根據終端的不同，B2BUA可以扮演UAS/UAC的功能，只有這樣，B2BUA才能完全控制雙方的呼叫流程，保證雙方在同一信令路徑上。
以上示例是一個(gè)簡(jiǎn)單的雙方終端呼叫的流程，B2BUA介于兩個(gè)終端之間。此呼叫流程經(jīng)過(guò)了大概四個(gè)步驟。
- UAC對B2BUA發(fā)起一個(gè)INVITE請求，在B2BUA端，B2BUA是一個(gè)UAS來(lái)接收這個(gè)請求，創(chuàng )建了第一個(gè)會(huì )話(huà)來(lái)管理這個(gè)請求。雙方保存了彼此的Route Set 記錄消息。
- 為了對另外一個(gè)終端發(fā)起INVITE請求，B2BUA同時(shí)也扮演了一個(gè)UAC的角色，它創(chuàng )建了第二個(gè)會(huì )話(huà)，并且再次對下游終端發(fā)起INVITE請求。這里，UAC需要從UAS端拷貝SDP消息和其他必要消息內容。然后，UAC對下游終端發(fā)起INVITE請求。終端接收了INVITE請求，并且保存了Route Set數據記錄。
- 為了響應INVITE請求，這里，下游終端就會(huì )變成一個(gè)UAS回復B2BUA 200 OK。B2BUA再次拷貝200 OK的消息，然后通過(guò)UAS再次返回到UAC終端。
- UAC終端收到200 OK以后，保存為Route Set數據內容。
在最后的握手確認時(shí)，終端必須根據Route Set 返回到B2BUA，因為其中的Contact不是另外終端的Contact地址，而是B2BUA的Contact。接下來(lái)，UAC終端繼續對B2BUA的UAS發(fā)送ACK消息。這里的UAC 終端必須通過(guò)B2BUA返回到另外一端，而不是直接進(jìn)行ACK的交互，這樣，B2BUA就會(huì )保證對終端雙方的會(huì )話(huà)管理，同時(shí)可以支持其他業(yè)務(wù)功能的實(shí)現，例如，計費功能。
這里，讀者一定要注意，B2BUA負責橋接兩個(gè)呼叫的會(huì )話(huà)，拷貝必要的消息內容。關(guān)于拷貝什么消息，不能拷貝什么消息，我們在接下來(lái)的章節介紹。另外，B2BUA保持會(huì )話(huà)內容，兩個(gè)會(huì )話(huà)負責不同的終端。雙方終端不知道對端的Contact地址。終端的Contact地址僅是B2BUA的地址。在這一點(diǎn)上，B2BUA和SIP Proxy有著(zhù)非常明顯的區別。因此，雙方終端只能通過(guò)B2BUA才能進(jìn)行信令路徑的完整性處理。
另外，一個(gè)比較特殊的場(chǎng)景是呼叫的預付費功能，這也是transparent B2BUA的一個(gè)基本功能。比較簡(jiǎn)單計費的原理如下：
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)于預付費的復雜的處理流程，可能需要借助于媒體服務(wù)器的支持，通過(guò)mid-call announcements的方式，對預付費的電話(huà)服務(wù)進(jìn)行語(yǔ)音播放，然后再執行掛機處理。具體的處理方式，讀者查閱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
根據計費原理的工作方式，如果計費模塊檢測到雙方呼叫費用出現超額的時(shí)候，這時(shí)，B2BUA會(huì )切換成UAC/UAC的狀態(tài)，同時(shí)對終端發(fā)送BYE消息。
這里，透明B2BUA的工作方式類(lèi)似于一個(gè)SIP Proxy，而且仍然利用了B2BUA的其他優(yōu)點(diǎn)。和透明（transparent）B2BUA相對的是拓展（extended proxy）B2BUA，它可以支持其他的功能設置。兩者之間沒(méi)有特別明顯的區別，具體的內容，讀者可查閱：
Requirements for a Session Initiation Protocol （SIP） Transparent Back-
To-Back User-Agent （B2BUA）
draft-marjou-sipping-b2bua-00
4、B2BUA功能實(shí)現3PCC討論
B2BUA可以支持很多應用功能，比較常見(jiàn)的是3PCC，第三方呼叫控制。第三方呼叫控制實(shí)現了很多用戶(hù)場(chǎng)景，包括點(diǎn)擊呼叫，電話(huà)轉接等功能。這些具體的實(shí)現流程，筆者在以前的文章中有非常詳細的介紹和消息流程圖，包括18個(gè)呼叫流程，讀者可以查閱。
在3PCC的呼叫中，我們需要明確兩個(gè)主要的定義：3PCC和控制器。根據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
在第三方呼叫的規范中定義了四種第三方呼叫的呼叫模式，其中的控制器就扮演著(zhù)B2BUA的角色。比較典型的場(chǎng)景就是頁(yè)面點(diǎn)擊呼叫或者轉接的處理。
在典型的轉接環(huán)境中，兩個(gè)終端可能已經(jīng)接通了呼叫，因為其他的原因，終端可能需要轉接此呼叫到第三方。這時(shí)，B2BUA或者控制器就會(huì )對另外一端掛機，繼續保持著(zhù)和呼叫方會(huì )話(huà)。呼叫方收到消息后，再次對第三方發(fā)送無(wú)SDP的INVITE（不是Option，是一個(gè)INVITE Request without SDP），雙方接通后實(shí)現RTP創(chuàng )建。然后，B2BUA對另外一端徹底拆線(xiàn)。在整個(gè)流程控制中，B2BUA始終扮演和一個(gè)控制器的作用，會(huì )話(huà)互相不影響。關(guān)于3PCC的四種操作流程，讀者可以查閱RFC3725進(jìn)行進(jìn)一步學(xué)習，規范分別對四種流程中INVITE和SDP處理要求有非常詳細的描述，這里不再討論。
5、SIP Proxy和B2BUA消息重構
在前面的討論中，B2BUA是介于兩個(gè)會(huì )話(huà)直接的一個(gè)邏輯實(shí)體，為了能夠管理修改和保持雙方的會(huì )話(huà)狀態(tài)，B2BUA必須可以修改保存雙方會(huì )話(huà)的消息數據，這樣才能真正實(shí)現信令路徑和媒體路徑的完整性。因此，在B2BUA作為UAS/UAC角色切換時(shí)，UAS需要拷貝一些SIP消息到UAC，或者相反方向的SIP拷貝重構，否則沒(méi)有辦法獲悉從上游過(guò)來(lái)的消息。但是，因為SIP協(xié)議中有很多規范是需要雙方必須遵守的，因此，在拷貝雙方的SIP消息時(shí)，需要考慮哪些SIP消息頭是必須拷貝的，哪些SIP頭是完全可能拷貝的，哪些SIP頭是可以拷貝的。下面，我們通過(guò)一個(gè)示例就以上幾個(gè)問(wèn)題進(jìn)行分析，檢查雙方數據映射處理時(shí)重構結果。
我們的示例是一個(gè)簡(jiǎn)單SIP終端通過(guò)B2BUA呼叫（INVITE）遠端SIP電話(huà)。這里，我們再次強調，雙方呼叫的會(huì )話(huà)沒(méi)有直接的關(guān)系，這些SIP頭的重構完全依賴(lài)于B2BUA本身。現在，我們逐一介紹這些SIP頭的處理。
- 首先，在INVITE中的Request-URL可以拷貝也可以通過(guò)B2BUA自己重新定義。典型的應用方式是B2BUA直接拷貝這個(gè)地址。所以，這個(gè)地址是可以直接拷貝的地址。
- Call-ID，根據RFC3261的定義，它是一個(gè)全局變量，并且具有唯一性，因此，兩個(gè)會(huì )話(huà)都分別有各自不同的Call_ID，因此它是不能拷貝的。服務(wù)器端需要自己生成自己的ID。
- Content-Length和Content-Type的處理，雙方的呼叫中，包含了SDP消息和其他下游媒體說(shuō)需要的參數來(lái)和終端協(xié)商，B2BUA可以利用它們的Content-Length和Content-Type作為另外一個(gè)UA的SDP消息數據。因此，這些數據是可以拷貝的。當然，如果B2BUA進(jìn)行了特別的編碼處理則是另外一個(gè)話(huà)題。
- To和From 地址的處理，理論上說(shuō)，B2BUA可以自由選擇自己本身所需要的地址。但是，如果沒(méi)有其他特別的要求，一般來(lái)說(shuō)，B2BUA直接拷貝了另外一個(gè)UA的To地址。From 地址也是一樣的道理，B2BUA可以直接拷貝上游From地址，然后傳遞給下游終端，這樣SIP終端就會(huì )獲悉是哪個(gè)SIP終端的呼叫。當然，為了更好管理終端之間的呼叫，B2BUA也可以修改為自己B2BUA的地址，下游SIP終端可以獲悉是來(lái)自于B2BUA地址的3PCC呼叫。
- Contact地址的處理，大家知道，如果呼叫到遠端SIP終端時(shí)，SIP終端就會(huì )保存Route Set的地址，這個(gè)地址用來(lái)支持后續的請求處理，這個(gè)Contact地址不應該是SIP終端地址，如果是SIP終端地址的話(huà)，兩個(gè)分機就可以實(shí)現直接呼叫。但是，在B2BUA的模式下，這個(gè)Contact地址不能直接拷貝到下游的Contact地址，只能使用本地B2BUA地址，這樣，下游的SIP終端收到的Contact地址就是B2BUA的地址。在呼叫創(chuàng )建時(shí)，下游終端就會(huì )通過(guò)B2BUA地址呼出。這樣，B2BUA始終在呼叫雙方的媒體路徑和信令路徑，保證B2BUA可以控制和管理呼叫流程。因此，這個(gè)Contact地址是不能直接拷貝的。
- 關(guān)于CSeq的處理，根據RFC3261的定義，CSeq method類(lèi)型必須反映request method的類(lèi)型。為了保證請求類(lèi)型的正確，因此，在B2BUA中CSeq的值可以直接拷貝，也可以重新初始化一個(gè)新的計算器值。
Max-Forward的處理，因為SIP終端設備可以選擇任何計算器的值，B2BUA可以自己決定重新設置為默認的計算器70。另外，因為在SIP路徑經(jīng)過(guò)了一個(gè)Hop，所以B2BUA也可以根據上游設備提供的計算器值，自動(dòng)遞減一次。因此，Max-Forward計算器值也可以直接拷貝或者直接使用上有的值。
Via 頭的處理。我們在以前的文章中專(zhuān)門(mén)討論了Via的用法，這個(gè)地址通知下游設備回復響應的地址。上游的Via可能經(jīng)過(guò)了多個(gè)Hop或者Proxy，對下游SIP終端發(fā)送Via時(shí)，這里的B2BUA不關(guān)心上游Via的結果，B2BUA僅關(guān)心下游SIP終端返回的響應地址，通知下游SIP終端返回到B2BUA的地址，而不是其他的地址。這個(gè)Via地址必須是B2BUA的地址，所以，B2BUA不能直接拷貝上游Via的地址。
根據以上分析，我們可以看到，在B2BUA的模式下，大部分的SIP頭是可以拷貝重構的，Call-ID, Contact 地址和Via是完全不能拷貝的。基本上沒(méi)有B2BUA必須拷貝的SIP頭。因此，B2BUA是非常靈活，而且具有多種權限來(lái)管理SIP話(huà)話(huà)和應用服務(wù)。
特別注意，可能有時(shí)出現一些比較特殊的應用場(chǎng)景，例如mid-call的應用場(chǎng)景（中間播放語(yǔ)音提示或者或其他業(yè)務(wù)流程），如果SIP終端通過(guò)Proxy呼叫一個(gè)功能服務(wù)器，Proxy希望功能服務(wù)器端能夠快速響應，收到系統的請求返回到Proxy。但是，因為是B2BUA，功能服務(wù)器可能重新生成一個(gè)Call-ID, 這樣會(huì )導致遠端的SIP終端產(chǎn)生誤解。如何解決這個(gè)問(wèn)題，B2BUA只能拷貝原來(lái)的Call-ID確保這是一個(gè)同樣的處理流程。具體此細節處理在RFC7329-4.5.2有定義。
根據以上討論，我們可以總結一些它們之間的區別。一般情況下，經(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ò)重構的，因此很多SIP頭可能是不一樣的。SIP消息經(jīng)過(guò)了B2BUA的重構以后，SIP消息具有明顯的不同：Contact地址變成了B2BUA的服務(wù)器的地址，Via消息是一個(gè)單列的地址，這個(gè)地址是B2BUA的需要的返回的地址，這里可能是B2BUA的地址。這里的Call-ID可能有例外（前面已經(jīng)討論），可以是同樣的Call-ID。另外，CSeq具有靈活性，可以處理也可以恢復到默認狀態(tài)。
6、其他相關(guān)問(wèn)題討論
除了我們上面討論的B2BUA的SIP消息重構以外，筆者在這里和大家討論幾個(gè)和本文章相關(guān)的討論。在很多文章中，包括我們今天的討論中，我們一直使用透明B2BUA（transparent B2BUA）的說(shuō)法。事實(shí)上，根據IETF組織的草案，透明B2BUA的工作方式類(lèi)似于一個(gè)特別的Proxy，但是更多利用了UA的功能。透明B2BUA的功能其實(shí)和我們前面介紹的B2BUA功能相似，因此，這里不再累述。因為透明B2BUA的概念比較寬泛，很多人對這個(gè)概念有很多爭論，而且在SIP處理方面具有非常強的靈活性，在一般的討論中，筆者建議根據具體的操作場(chǎng)景來(lái)解釋?zhuān)蛘咄ㄟ^(guò)一定的場(chǎng)景來(lái)理解。
當然，transparency（透明）proxy或者B2BUA是一個(gè)無(wú)休止的討論，到底有多透明，事實(shí)上，完全取決于SIP 處理的流程和業(yè)務(wù)場(chǎng)景。Proxy比較透明，因為它僅實(shí)現了RFC3261的簡(jiǎn)單功能，沒(méi)有涉及太多的SIP消息重構和3PCC的處理。為了滿(mǎn)足3PCC或其他業(yè)務(wù)能力，透明B2BUA是一個(gè)非常明確的需求，但是在B2BUA的使用場(chǎng)景中，很多SIP 頭是需要經(jīng)過(guò)UA處理的，例如，我們現在使用的SBC。SBC作為一個(gè)B2BUA需要對SIP 頭進(jìn)行處理才能實(shí)現拓撲隱藏，協(xié)議正規化，編碼轉換和協(xié)議轉換等功能。因此，一些比較專(zhuān)業(yè)的SBC采取了一定的控制機制來(lái)實(shí)現透明處理（Relay和Transparency）。
我們在前面的章節中已經(jīng)多次提及B2BUA和SIP Proxy之間的區別和SIP頭的變化。下面，我們提供幾個(gè)示例結合以前B2BUA和Proxy的區別，再次對SBC功能和SIP Proxy進(jìn)行一個(gè)對比說(shuō)明以幫助讀者進(jìn)一步了解SBC和Proxy主要區別。讀者一定要注意標注的關(guān)鍵詞部分。
我們可以通過(guò)兩個(gè)示例來(lái)對比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的區別。很多情況下，我們需要檢查系統的日志來(lái)排查問(wèn)題。那么，現在問(wèn)題來(lái)了。如何判斷這些SIP消息是經(jīng)過(guò)Proxy的SIP消息還是B2BUA的SIP消息？這里，我們做一個(gè)簡(jiǎn)單的介紹以幫助讀者能夠非常快速判斷系統的SIP消息日志。經(jīng)過(guò)SIP Proxy的系統日志是這樣的：
經(jīng)過(guò)B2BUA 的SIP重構以后的消息變化是這樣的：
根據我們介紹的SIP消息經(jīng)過(guò)Proxy和B2BUA的不同也可以看出兩者之間的不同，它們兩者都基本上完全遵守SIP的規范和各自的定義。
7、總結
本文章介紹了B2BUA的基本概念，SIP Proxy和B2BUA的區別，然后筆者介紹了B2BUA在3PCC中的應用場(chǎng)景分析。另外，筆者花費時(shí)間對B2BUA消息重構做了非常詳細地說(shuō)明解析，同時(shí)對某些SIP頭的處理針對性地做了強調，幫助讀者能夠有重點(diǎn)地了解某些規范支持。最后，筆者對透明B2BUA處理，B2BUA的透明處理機制和SIP Proxy的區別做了討論。
再次說(shuō)明，如果讀者缺少SIP其他方面基礎的介紹，需要查閱筆者的歷史文檔補充這些知識，這樣可以更好理解本章所學(xué)習的內容。
參考資料：
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)注微信公眾號：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中國合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817
