代理（Proxy）和背靠背用戶代理（B2BUA）

document.body.oncopy = function() { if (window.clipboardData) { setTimeout(function() { var text = clipboardData.getData("text"); if (text && text.length > 300) { text = text + "\r\n\n本文來自CSDN博客，轉載請標明出處：" + location.href; clipboardData.setData("text", text); } }, 100); } } function StorePage() { d = document; t = d.selection ? (d.selection.type != 'None' ? d.selection.createRange().text : '') : (d.getSelection ? d.getSelection() : ''); void (keyit = window.open('http://www.365key.com/storeit.aspx?t=' + escape(d.title) + '&u=' + escape(d.location.href) + '&c=' + escape(t), 'keyit', 'scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes')); keyit.focus(); }

1. 什麼是Proxy模式？

按照RFC3261中的定義，Proxy服務器是一箇中間的實體，它自己即做爲客戶端也做爲服務端，爲其餘客戶端提供請求的轉發服務。一個 Proxy服務器首先提供的是路由服務，也就是說保證請求被髮到更加」靠近」目標用戶的地方。Proxy服務器在施行某些強制政策時也有用（好比，確認一 個用戶是否容許創建一個呼叫等）。而一個Proxy服務器翻譯，若是有須要的話在轉發消息前會重寫該請求消息。

2. 什麼是B2BUA？

按照RFC3261中的定義，背對背的用戶代理（B2BUA）是一個邏輯實體，它就像用戶代理服務器（UAS）同樣接收和處理請求。爲了決定該如何應答一個請求，B2BUA就像UAC同樣工做，而且發出請求。可是它不像代理服務器（proxy），它維持對話狀態，而且參與已經創建的對話中的每個請求。因爲它是直接的UAC和UAS的串連，因此，不須要對他有額外的定義。

   

3.Proxy模式和B2BUA模式有什麼不一樣？各有什麼優缺點？

最多見的Proxy服務器僅僅完成兩個UA的鏈接。而B2BUA服務器則是一個智能的實體，更爲強大，它有一些Proxy沒法作到的功能，它更靈活，並漸漸取代通常的Proxy服務器而成爲SIP服務器的主流。

根據sip-router.org 的描述，Proxy模式和B2BUA的最大區別是前者是事物有狀態（transaction-stateful），然後者是呼叫有狀態（call stateful）。 也就是說，代理服務器只在SIP事務交互時（會話的開始和終結）保持狀態，而並非在整個呼叫中維護狀態。而B2BUA則在兩個或多個UA經過某種手段互 聯時起做用，B2BUA在整個呼叫中會維護一些狀態（一般是內存中的一些結構）。B2BUA與SIP代理服務器不一樣，B2BUA能夠接收呼叫，並能對其進 行修改，以其它形式表明發起呼叫的UA向終端目標發起呼叫，並能充當呼叫雙方的媒體協商表明或對其進行監控管理。B2BUA能夠對通過它的來自於私網的呼 叫進行處理完成NAT的穿越。爲適應全部類型NAT的環境，B2BUA也須要作媒體流的中介。這就讓B2BUA有了一些Proxy沒有的特性，例 如，B2BUA能夠終結一個已經存在的呼叫，而Proxy不行。在B2BUA中，咱們能夠提供點對點呼叫的增值業務能力或者多點呼叫控制能力，而其餘的 SIP服務器，好比Proxy就不能提供如此複雜的增值業務。而全部這一切的背後都是由B2BUA有一個寬泛的定義所致，這使得它有無限的能力去擴展（當 然，這也是爭議所在）。咱們能夠看下邊的這個結構圖：

咱們舉幾個B2BUA獨有支持的業務：

a.第三方呼叫控制機(3PCC)

這個業務的特色是一個實體（每每是一個控制器）爲兩個或多個對端創建鏈接，經常使用於運營商業務和電話會議。一些典型的應用是：在線計費、QoS、資源 優先分配，呼叫轉移、點擊撥號、呼叫中階段通知送達等。因爲例如Proxy服務器都是維護一個被動的非呼叫有狀態是沒法發起這樣的業務的，這就成了 B2BUA的專利。用B2BUA能夠自動的觸發3PCC動做，好比在一個在線計費系統中，根據餘額來掛掉一個呼叫。固然，這些也能夠經過一個遠程管理控制 （remote administrative control (OSS)）系統來完成，好比，去邀請多方加入一個多點會議會話中。

b.互操做性的網絡互連功能（IWF ）

IWF（Inter-working Functions ）是爲了解決SIP強大的擴展性所帶來的詬病，它對一個強大的SIP服務器有比較寬泛的定義，來完成對不一樣協議實現或者支持不一樣能力的SIP客戶端的互連。當它被使用在客戶端和網絡時，它實際就是一種接入設備。

例如：

• 經過添加或者刪除IMS中對於鏈接ISM網絡很重要的SIP協議擴展(AKA P-Headers) 來對SIP終端和IMS 網絡進行鏈接。
• 鏈接兩個不一樣會話計時器設置的客戶端。
• 經過在兩個不一樣控制會話類型中進行轉述來鏈接有不一樣媒體能力和不一樣SDP消息的兩個終端。
• 來支持不一樣的網絡類型（v4，v6）、和不一樣的傳輸類型，TCP/UDP/SCTP/TLS

c.多點呼叫管理

這個場景中多個CPE（CPE是「CustomerPremiseEquipment」的縮寫,直譯爲「用戶前端設備」）與B2BUA相連，由B2BUA爲全部CPE提供業務。

d.融入IMS網絡

在3GPP的IMS標準中，IMS的大量邏輯實體都是定義爲B2BUA模式的，這樣作的緣由是增值業務每每都是呼叫有狀態的，而這個要求遠遠超過了 基本呼叫代理所能及的範圍。在B2BUA應用服務器之上的應用能夠充分的完成SIP UA、SIP註冊服務器、SIP代理服務器等角色。

咱們在給出是一些B2BUA的應用例子：

• 在線計費、預付費功能
• 支持資源優先權和QoS的服務器
• 多點會議服務器
• IVR服務器
• PBX應用和軟交換
• 應用層網關
• 防火牆/NAT穿越應用
• 私有服務器
• 第三方呼叫控制應用
• 業務生成環境運行時引擎
• 會話邊界控制器
• IMS中的S-CSCF\P-CSCF\I-CSCF
• SIP網間互聯網關
• 安全網關
• 語音呼叫連續性業務

另外一方面，B2BUA面臨着諸多挑戰，好比產品上市週期、一致性、互操做性，爲私有業務提供定製，支持高可用性和冗餘等等。尤爲是在可伸縮性上很容 易成爲瓶頸。一個健壯的B2BUA框架應該有模塊化的程序設計結構以應對增加的靈活性、抽象性需求。對於通訊雙方來講，呼叫控制信令和媒體流在傳輸過程當中 均增長了一跳，隨着用戶的增長，B2BUA將成爲系統瓶頸。

咱們舉一個B2BUA是如何實現PBX的例子， B2BUA擔當兩臺UA（用戶代理服務器）功能，其中一臺模擬接收器，一臺模擬發送器，兩者之間安裝有控制邏輯。在這種控制邏輯下，B2BUA能控制 SIP數據流，將其轉換爲PSTN信令模式或廠商的專用控制協議方式,這是大多數廠商採用的PBX方式.另一些SIP廠商採用的是純SIP代理方式，它 不一樣於一般意義上的代理服務器。運用SIP代理服務，SIP信令流直接在兩UA間傳輸。毫無疑問，完善的SIP網絡缺乏不了B2BUA功能，由於要鏈接到 PSTN。但若是要在VoIP網關的核心實現B2BUA功能，則難度大多了。事實上，PBX廠商提供B2BUA功能實現成本要比SIP代理高得多，部分原 因是體系結構實現難。因爲SIP代理在呼叫創建階段不直接處理信令流，於是保持有關會話的狀態信息要比B2BUA方式少。並且，SIP代理的支撐硬件也比 B2BUA方式少，在同一平臺易於擴展支持更多UA。並且，企業電話運營所需的核心功能基於PBX實現，而不是B2BUA，這進一步增長了成本。

另外，SIP代理方式在安全性與可靠性方面也略勝一籌。因爲B2BUA會重寫數據包核心，存在潛在弱點，有受攻擊可能；而SIP代理在處理進程中僅 暴露SIP標題。B2BUA操做失敗的可能性也高於SIP代理方式，從而會影響到全部呼叫經過；SIP代理失敗僅影響新到呼叫，現行呼叫或已到達目標併爲 設備所俘獲的呼叫並不受影響。

最後，SIP代理服務器比B2BUA適應性更強。因爲B2BUA會中斷媒體會話，若是B2BUA不支持，UA功能就很難發揮。這意味着，若是UA功 能實現與B2BUA各異，一家廠商的電話就有可能沒法與另外一廠商的協同工做。運用SIP代理服務器就不同了，UA協議會話功能直接實現。

參考文獻：

1.http://colocation.tmcnet.com/topics/sip-and-open-standards/articles/18257-back-back-user-agents-telecommunications.htm

2.http://blog.sina.com.cn/s/blog_414e587f01000b9g.html

關於SIP的呼叫/對話/會話/事務概念，請參看：http://blog.csdn.net/gnuhpc/archive/2009/12/28/5089613.aspx