作者:gnuhpc
出处:http://www.cnblogs.com/gnuhpc/
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。在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客户端的互连。当它被使用在客户端和网络时,它实际就是一种接入设备。
例如:
c.多点呼叫管理
这个场景中多个CPE(CPE是“CustomerPremiseEquipment”的缩写,直译为“用户前端设备”)与B2BUA相连,由B2BUA为所有CPE提供业务。
d.融入IMS网络
在3GPP的IMS标准中,IMS的大量逻辑实体都是定义为B2BUA模式的,这样做的原因是增值业务往往都是呼叫有状态的,而这个要求远远超过了基本呼叫代理所能及的范围。在B2BUA应用服务器之上的应用可以充分的完成SIP UA、SIP注册服务器、SIP代理服务器等角色。
我们在给出是一些B2BUA的应用例子:
另一方面,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协议会话功能直接实现。
参考文献:
2.http://blog.sina.com.cn/s/blog_414e587f01000b9g.html
关于SIP的呼叫/对话/会话/事务概念,请参看:http://blog.csdn.net/gnuhpc/archive/2009/12/28/5089613.aspx