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服务器的主流。

根据 的描述，Proxy模式和B2BUA的最大区别是前者是事务有状态（transaction-stateful），而后者是呼叫有状态（call stateful）。 也就是说，代理服务器只在SIP事务交互时（会话的开始和终结）保持状态，而并不是在整个呼叫中维护状态。而B2BUA则在两个或多个UA通过某种手段互联时起作用，B2BUA在整个呼叫中会维护一些状态（通常是内存中的一些结构）。B2BUA与SIP代理服务器不同，B2BUA可以接收呼叫，并能对其进行修改，以其它形式代表发起呼叫的UA向终端目标发起呼叫，并能充当呼叫双方的媒体协商代表或对其进行监控管理。B2BUA可以对经过它的来自于私网的呼叫进行处理完成NAT的穿越。为适应所有类型NAT的环境，B2BUA也需要做媒体流的中介。这就让B2BUA有了一些Proxy没有的特性，例如，B2BUA可以终结一个已经存在的呼叫，而Proxy不行。运行商常常为了不泄露其网络拓扑而多使用B2BUA。在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.

2.

本文转自gnuhpc博客园博客，原文链接http://www.cnblogs.com/gnuhpc/archive/2012/12/11/2813499.html，如需转载请自行联系原作者