OpenSIPS B2BUA实现介绍

概述

OpenSIPS有许多功能，但在建立媒体会话时的方式上，它就不只是一个代理了，这意味着它只是接收来自一侧的消息并传递给另一侧。然而，这已被证明不足以为服务端提供了解会话状态、监视和控制会话所需的某些服务。背靠背用户代理就是这样的，一个SIP网络中的实体，它能够控制或启动媒体会话。名称来源于行为，因为事实上，B2BUA需要站在中间，建立两个具有最终交换媒体的端点的会话。
OpenSIPS中的B2BUA是RFC 3261中定义的B2BU行为的实现，它提供了在其上构建特定服务的可能性。它由两个模块组成：

b2b_entities：底层部分，实现UAC和UAS（B2BUA）的行为

b2b_logic：上层部分，实现用于分析和应用服务场景的逻辑，以实现所需的B2BUA特定服务。

下图展示了B2BUA架构的实现：

编写路由脚本

特殊的B2B脚本

       B2BUA服务接收到的请求和回复（属于它正在处理的dialogs）不会像正常请求那样进入脚本。原因在于这不是作为代理服务器的正常请求，此时服务端是此dialog中的端点，因此它们不应该经过相同的路由。但是，从脚本中可以看到这个请求，并允许脚本编写者正常地根据这些请求进行所需的处理。为此，可以定义两个特殊的B2B路由，一个用于请求，一个用于回复。路由类型为route，其名称在模块参数script_req_route和script_reply_route中定义。

示例：

modparam("b2b_entities", "script_req_route", "b2b_request")
modparam("b2b_entities", "script_reply_route", "b2b_reply")

route[b2b_request] {
  xlog("b2b_request ($ci)");
}


route[b2b_reply] {
  xlog("b2b_reply ($ci)");
}

B2B不支持故障路由（Failover）

       在B2BUA场景（有多个对话，有多个事务）中不可能有t_on_failure()机制，因为它是指定事务的。对于复杂的场景，有多个对话，无法确定要为哪个事务触发失败路由。"top hiding"场景是一个非常简单的B2BUA场景，但不能为所有B2BUA方案都有一个通用的“on_failure”概念。
       一个解决方案是考虑b2bua是一个单独的实例（逻辑上讲），它选择目的地的类型/类别。代理实例将负责在目的地类内进行路由。
        例如：在一个场景中，我们可以首先将呼叫发送到媒体服务器以进行一些公告，然后再发送到PSTN网关。在第一步中，b2bua将会把指向一类媒体服务器的RURI的呼叫发送给proxy，proxy将选择适当的媒体服务器并在媒体服务器之间进行故障切换，对b2bua完全透明。以类似的方式，在第二步，b2bua脚本将向proxy指示它希望将呼叫发送到PSTN网关（作为目的地类型），proxy将在网关之间执行lcr、drooting和故障切换。