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