SIP中的B2BUA调研
B2BUA是两个SIP组件的特殊组合-用户代理客户端（UAC）和用户代理服务器（UAS）。UAC是发送SIP消息并接收SIP响应的SIP实体，而UAS是接收SIP消息并发送SIP响应的SIP实体。
根据RFC7092规范的定义，B2BUA可分为多个类别，主要包括两个主类别和多个次类别：
Signaling Plane B2BUA Roles， 其子类别分别包括：Proxy-B2BUA， Signaling-only和 SDP-Modifying Signaling-only。这个类别中，B2BUA侧重于信令的处理，SDP的管理，它们本身不介于媒体路径上，所以，它们不能管理RTP头和payload。
Signaling/Media Plane B2BUA Roles，其子类别分别包括：Media Relay，Media Aware和Media Termination。扮演信令媒体的B2BUA，它们不仅那个管理SIP头，而且可以对RTP 头进行管理或者修改。通过此B2BUA处理后的信令和媒体能够保证双方的一致性。
B2BUA可以实现以下几个方面的应用场景：
基于SIP的IPPBX和软交换，市场上很多企业融合通信的IPPBX就是一个非常典型的B2BUA场景。比较熟悉的开源的Asterisk或FreeSWITCH，以及基于Asterisk引擎的开源IPPBX界面管理系统FreePBX
基于应用服务器支持，包括3GPP环境下的分机随行，ACD等服务
SBC边界控制器，笔者已经多次介绍
编码转换服务，支持不同编码转换，实现双方编码的一致性支持
会议服务器，通过B2BUA实现会议，以及会议控制功能，混音等
P-CSCF和IBCF Functions，支持IMS网络中的网关访问和切换功能
S-CSCF Function，支持IMS环境中的Proxy-B2BUA
在RFC7092规范中定义了具体的角色，但是规范并没有详细说明应用场景的具体的使用方式。
B2BUA工作原理。根据B2BUA的定义，为了管理双方的终端和对会话进行管理，B2BUA需要分别创建两个不同的会话，B2BUA根据终端的不同，B2BUA可以扮演UAS/UAC的功能，只有这样，B2BUA才能完全控制双方的呼叫流程，保证双方在同一信令路径上。
例如一个简单的双方终端呼叫的流程，B2BUA介于两个终端之间。此呼叫流程经过了大概四个步骤。
UAC对B2BUA发起一个INVITE请求，在B2BUA端，B2BUA是一个UAS来接收这个请求，创建了第一个会话来管理这个请求。双方保存了彼此的Route Set 记录消息。
为了对另外一个终端发起INVITE请求，B2BUA同时也扮演了一个UAC的角色，它创建了第二个会话，并且再次对下游终端发起INVITE请求。这里，UAC需要从UAS端拷贝SDP消息和其他必要消息内容。然后，UAC对下游终端发起INVITE请求。终端接收了INVITE请求，并且保存了Route Set数据记录。
为了响应INVITE请求，这里，下游终端就会变成一个UAS回复B2BUA 200 OK。B2BUA再次拷贝200 OK的消息，然后通过UAS再次返回到UAC终端。
UAC终端收到200 OK以后，保存为Route Set数据内容。
在最后的握手确认时，终端必须根据Route Set 返回到B2BUA，因为其中的Contact不是另外终端的Contact地址，而是B2BUA的Contact。接下来，UAC终端继续对B2BUA的UAS发送ACK消息。这里的UAC 终端必须通过B2BUA返回到另外一端，而不是直接进行ACK的交互，这样，B2BUA就会保证对终端双方的会话管理，同时可以支持其他业务功能的实现，例如，计费功能。
B2BUA负责桥接两个呼叫的会话，拷贝必要的消息内容。关于拷贝什么消息，不能拷贝什么消息，我们在接下来的章节介绍。另外，B2BUA保持会话内容，两个会话负责不同的终端。双方终端不知道对端的Contact地址。终端的Contact地址仅是B2BUA的地址。在这一点上，B2BUA和SIP Proxy有着非常明显的区别。因此，双方终端只能通过B2BUA才能进行信令路径的完整性处理。
透明B2BUA的工作方式类似于一个SIP Proxy，而且仍然利用了B2BUA的其他优点。
SIP Proxy和B2BUA消息重构
B2BUA是介于两个会话直接的一个逻辑实体，为了能够管理修改和保持双方的会话状态，B2BUA必须可以修改保存双方会话的消息数据，这样才能真正实现信令路径和媒体路径的完整性。因此，在B2BUA作为UAS/UAC角色切换时，UAS需要拷贝一些SIP消息到UAC，或者相反方向的SIP拷贝重构，否则没有办法获悉从上游过来的消息。但是，因为SIP协议中有很多规范是需要双方必须遵守的，因此，在拷贝双方的SIP消息时，需要考虑哪些SIP消息头是必须拷贝的，哪些SIP头是完全可能拷贝的，哪些SIP头是可以拷贝的。
示例是一个简单SIP终端通过B2BUA呼叫（INVITE）远端SIP电话。双方呼叫的会话没有直接的关系，这些SIP头的重构完全依赖于B2BUA本身。
介绍这些SIP头的处理。首先，在INVITE中的Request-URL可以拷贝也可以通过B2BUA自己重新定义。典型的应用方式是B2BUA直接拷贝这个地址。所以，这个地址是可以直接拷贝的地址。
Call-ID，根据RFC3261的定义，它是一个全局变量，并且具有唯一性，因此，两个会话都分别有各自不同的Call_ID，因此它是不能拷贝的。服务器端需要自己生成自己的ID。
Content-Length和Content-Type的处理，双方的呼叫中，包含了SDP消息和其他下游媒体说需要的参数来和终端协商，B2BUA可以利用它们的Content-Length和Content-Type作为另外一个UA的SDP消息数据。因此，这些数据是可以拷贝的。当然，如果B2BUA进行了特别的编码处理则是另外一个话题。
To和From 地址的处理，理论上说，B2BUA可以自由选择自己本身所需要的地址。但是，如果没有其他特别的要求，一般来说，B2BUA直接拷贝了另外一个UA的To地址。From 地址也是一样的道理，B2BUA可以直接拷贝上游From地址，然后传递给下游终端，这样SIP终端就会获悉是哪个SIP终端的呼叫。当然，为了更好管理终端之间的呼叫，B2BUA也可以修改为自己B2BUA的地址，下游SIP终端可以获悉是来自于B2BUA地址的3PCC呼叫。
Contact地址的处理，如果呼叫到远端SIP终端时，SIP终端就会保存Route Set的地址，这个地址用来支持后续的请求处理，这个Contact地址不应该是SIP终端地址，如果是SIP终端地址的话，两个分机就可以实现直接呼叫。
在B2BUA的模式下，这个Contact地址不能直接拷贝到下游的Contact地址，只能使用本地B2BUA地址，这样，下游的SIP终端收到的Contact地址就是B2BUA的地址。在呼叫创建时，下游终端就会通过B2BUA地址呼出。这样，B2BUA始终在呼叫双方的媒体路径和信令路径，保证B2BUA可以控制和管理呼叫流程。因此，这个Contact地址是不能直接拷贝的。
CSeq的处理，根据RFC3261的定义，CSeq method类型必须反映request method的类型。为了保证请求类型的正确，因此，在B2BUA中CSeq的值可以直接拷贝，也可以重新初始化一个新的计算器值。
Max-Forward的处理，因为SIP终端设备可以选择任何计算器的值，B2BUA可以自己决定重新设置为默认的计算器70。另外，因为在SIP路径经过了一个Hop，所以B2BUA也可以根据上游设备提供的计算器值，自动递减一次。因此，Max-Forward计算器值也可以直接拷贝或者直接使用上有的值。
Via 头的处理。Via地址通知下游设备回复响应的地址。上游的Via可能经过了多个Hop或者Proxy，对下游SIP终端发送Via时，这里的B2BUA不关心上游Via的结果，B2BUA仅关心下游SIP终端返回的响应地址，通知下游SIP终端返回到B2BUA的地址，而不是其他的地址。这个Via地址必须是B2BUA的地址，所以，B2BUA不能直接拷贝上游Via的地址。
在B2BUA的模式下，大部分的SIP头是可以拷贝重构的，Call-ID, Contact 地址和Via是完全不能拷贝的。基本上没有B2BUA必须拷贝的SIP头。因此，B2BUA是非常灵活，而且具有多种权限来管理SIP话话和应用服务。
可能有时出现一些比较特殊的应用场景，例如mid-call的应用场景（中间播放语音提示或者或其他业务流程），如果SIP终端通过Proxy呼叫一个功能服务器，Proxy希望功能服务器端能够快速响应，收到系统的请求返回到Proxy。但是，因为是B2BUA，功能服务器可能重新生成一个Call-ID, 这样会导致远端的SIP终端产生误解。如何解决这个问题，B2BUA只能拷贝原来的Call-ID确保这是一个同样的处理流程。具体此细节处理在RFC7329-4.5.2有定义。
