世界进入混沌状态。这本身就已经是一件非常痛苦的事情，更痛苦的是从事VoIP行业的一些读者对SIP技术中B2BUA的功能角色也一直是“混沌”的，也经常对SIP B2BUA概念产生疑惑。特别是随着互联网，云计算的技术不断变化，基于SIP技术网络的各种应用也在不停地发生变化，SIP服务器端的应用场景也呈现了更多的形态，从本地部署到混合云，公有云，智能终端部署，边缘智能终端和计算等等环境也介入到了企业网络环境中，这些眼花缭乱的变化让更多技术人员对一些方向性的技术架构产生了更多的疑问，天天面对这个十万个为什么问题。实际上，具体来说，SIP B2BUA（背靠背代理）其功能根据实际场景的不同也调整支持了不同的业务场景。目前很多读者对SIP B2BUA的理解可能仅仅停留在了媒体服务器或者IPPBX，呼叫中心这这些经常看到的典型的应用场景中。在现实环境中，随着IMS网络和SIP技术架构的不断扩展，其支持的功能出现了更多的场景，包括目前客户需求激增的IMS必要进入产品-会话边界控制器（SBC）。所以，在本文章中，笔者希望对读者提供一个完整的概览，帮助或者唤醒对SIP B2BUA概念功能仍然混沌的读者。当然，如果读者还对SIP技术知识仍然处于“酣睡”的基础阶段，笔者提供的这种“唤醒服务”内容可能对这些读者也有一定难度，笔者建议读者可以参考笔者其他关于SIP系列讲座基础历史文档学习。

叫醒服务-英国1930时代的服务

　　笔者在以前的文档中大量介绍过关于B2BUA的分类。但是，那些文章因为主题内容讨论的不同，仍然没有太多细节的说明。笔者今天针对关于B2BUA实体分类做应该完整的说明，可以进一步帮助读者完全消化这些林林总总的概念以及其应用场景。事实上，关于B2BUA实体分类是根据RFC规范7092来规范定义的，为了方便更多读者了解其抽象概念，可能结合一些具体应用场景来加以说明。如果读者对笔者历史文档中关于有兴趣的话，可以查阅此历史文档链接学习。

　　在以上文档中主要针对B2BUA的主要类型SBC进行说明。本文章中将针对更多的关于B2BUA的实体分类进行说明。在以下图例中，我们可以看到，SIP信令和RTP媒体流完全实现了解藕（decouple）。

关于SIP协议B2BUA实体分类架构推荐

　　以上推荐架构可以满足最新互联网云平台分布式部署和RTP处理的分离，并且可以实现完全兼容IMS网络环境或者网络虚拟化虚拟IMS支持扩展。这种新的部署方式是有其理论依据的。在RFC7092中，针对SIP实体中B2BUA做了比较详细的详解，包括了其B2BUA的实体分类和相关定义。现在，我们针对B2BUA的实体分类进行细节讨论。具体的B2BUA定义分类包括以下几个大类和子类别。笔者针对这些实体分类角色进行逐一说明。

　　SIP信令面的B2BUA角色是B2BUA经常使用的一个角色分类。我们可以根据其定义大概知道其具体的功能。它主要的功能就是负责信令处理功能， 它仅对SIP 消息和SIP头进行操作，不涉及对媒体路径的处理。虽然它可以保存SDP或者对SDP中的MIME进行操作，但是，整体来说，这样的处理方式不会涉及SDP消息体修改。它进一步细分为以下三个子分类：

　　Proxy-B2BUA，它是基于RFC3261规范细分的一个SIP代理，也包括其扩展协议功能，只是它会维持一个足够的dialog状态在在某些场景中生成in-dialog SIP消息。最典型的Proxy-B2BUA常见场景是它会生成一个BYE请求来实现对不再存活的会话的拆线功能支持。根据RFC3261规范详解说明，Proxy-B2BUA不能修改收到的SIP头消息，例如To，From，Contact，Proxy-B2BUA仅能修改Via和Record-Route头和其扩展。如果Proxy-B2BUA能生成in-dialogSIP消息，它生成自己的信息以后，它也需要修改CSeg头。另外，Proxy-B2BUA既不能修改MIME消息体（包括SDP），也不能检查MIME消息体（包括SDP），它对媒体是无感知的，将转发任何的method类型。

　　Signaling-only，它运行在SIP层，虽然可以正常转发请求，但是超出了RFC3261的SIP代理范围。例如，这样的B2BUA可能替换Contact URL，修改或者移除所有的Via和Record-Route头，修改To和From头，修改和检查特定的MIME消息体等。 它可以拷贝任何在UAS端收到的SIP头到UAC端生成的请求中。这样的典型的应用场景包括了一些应用服务器，例如IPPBX。这样的B2BUA代理可以在REFER目标路径中从逻辑上处理REFER请求，然后生成新的INVITE请求。另外一个例子就是Privacy 服务代理，它对privacy头进行处理。

　　SDP-Modifying Signaling-only， 此类型的B2BUA仅能够运行在信令面，不会运行在媒体路径。但是，它可以修改SDP消息体，对SDP语法和语义有感知。在一些应用场景中，应用服务器或者PBX可以移除某些编码选项或者合并两个媒体流为一个SDP offer。这个类型的B2BUA不会修改媒体执行的媒体路径。具体来说，此代理不会把自己插入到媒体路径中，但是他们可以对SDP做出修改来影响媒体面中需要发送到媒体内容。

　　SIP信令面/媒体面的B2BUA角色，它可以在SIP面和媒体面进行操作执行，包括SDP，RTP和RTCP层面或者其他媒体的执行操作。这样的B2BUA有可能替换Contact URL，修改或移除所有的Via和Record-Route头，修改To和From头等。它可以拷贝任何在UAS端收到的SIP头到UAC端生成的请求中，其SDP也可以被修改。这样的B2BUA在具体应用场景中包括了目前经常使用的SBC，编码转换服务器，振铃音服务器，以及录音服务器。另外，还有一个例子就是Privacy 服务代理，它对privacy头进行处理。这样的B2BUA不需要部署在一台物理服务器，它可以解耦，独立部署为信令服务器和媒体服务器。此类型的B2BUA可以进一步划分为以下几种B2BUA子类型：

　　Media Relay， 它支持媒体转发类型的B2BUA，顾名思义是执行一个媒体转发的角色，它主要负责终止在UAS和UAC端的IP或者TCP/UDP层的媒体面，但是它不会修改或者限制数据包中payload的格式。相反，它可以透明地从一端拷贝到另外一端。因此，它可能仅支持TCP，或者UDP，也可能同时支持TCP和UDP或者其他的传输方式。它可能涉及到IP包的管理策略来限定网络带宽以及IPv4和IPv6之间的转换。它所涉及的NAT处理非常类似于NAT双向操作，但是NAT双向操作可以执行数据源和目的地之间的双向转换，一些读者可能在SBC的默认配置场景中看到类似的转换。

　　Media Aware， 此B2BUA执行媒体感知的角色，除了它检查和可能修改在UDP或者TCP传输的payload以外，工作方式类似于媒体转发服务器，但是它不会对编码本身或者更高层级进行处理。比较常见的示例是SRTP终端服务器，这一类型的终端不关注RTP payload，但是它关注RTP header。另外一种终端，它检测RTCP来获取QoS值等，还有在5元组中的多路复用和多路复用分离RTP和RTCP的设备等。

　　Media Termination， 此B2BUA承担媒体终端或者”终止“的角色，它仅在媒体payload层执行，例如RTP/RTCP编码，消息会话转发层（MSRP）或者更高层处理。这样的B2BUA仅可以终止或者生成特有的RTP媒体，例如DTMF拨号音，也可以执行媒体编码转换。它也可以像背靠背MSRP代理一样工作，这种工作方式由编码转换服务器或者会议服务器来实现。

　　在以上章节中，我们主要介绍了关于B2BUA的分类和一些子分类。对于读者来说，大部分的概念理解还是比较抽象的。在RFC7092中，这些分类和子分类都会映射到具体的实际的应用环境中。读者通过在实际应用环境中了解这些概念会比较容易。映射到具体业务形态的B2BUA应用场景包括以下几种：

　　SIP PBXs and Softswitches， 这个类型是读者经常可以接触到的用户场景。基于SIP的IPPBX或者软交换可以对SIP层和媒体进行管理修改。这些名称都是一些市场产品通俗的称谓，根据其业务功能要求，SIP PBX 或者软交换可以实现以上B2BUA的各种特定功能需求，无标准化的官方说明。因此，建议读者根据具体的应用场景来理解B2BUA的映射关系。我们也可能看到，某些提供商产品可能为了市场宣传，重点突出了某些热点功能，事实上，软交换或者基于SIP 的PBX可以实现很多媒体服务层面的需求，这些功能实现完全取决于厂家的定义或者支持水平。

　　Application Servers， 应用服务器包括的类型很多，它可以对SIP头或者其他字段进行管理也可以修改一些必要的字段。和前面的软交换或者SIP PBX 类似，在市场上，它本身也没有特定的官方标准来定义应用服务器的属性，目前比较官方的定义是在3GPP中对Application Servers（SIP AS， OSA AS， CAMEL IM-SSF等）的具体功能说明和规范，比如应用服务器中的消息等待指示（MWIs），分机随行服务等。这些服务有的在SIP信令面执行，有的在媒体面执行，也有的的提供媒体应用提供终端服务，包括IVR，语音邮箱服务器集成等业务。

　　Session Border Controllers， 这个类型的B2BUA可以对SIP层消息和媒体进行比较深度的干预管理以及修改。SBC是目前企业语音通信中部署的主流产品，读者可以参考RFC5853获得更多关于SBC功能的介绍，它更多依赖于逻辑功能设置来管理SIP信令和媒体的转发处理。默认环境中，SBC是一个媒体转发服务器或者对媒体感知的B2BUA代理服务器，它可以替换Contact URL，修改Via和Record-Route头，修改Call-ID， To， From等头域值，并且可以按照路由要求修改SDP。根据配置策略，SBC可以拒绝某些SIP methods， 也可以透传某些SIP头消息字段。读者也可以观看以下视频获得更多关于SBC的概览介绍。

　　Transcoders， 这个类型主要针对媒体类型进行必要的修改或者管理，具体来说就是编码转换服务器对语音编码或者视频编码进行不同格式的转换，例如，比较典型的用例就是G.711转为G.729。尽管它们媒体之间的转换仅发生在某些特定需求中的编码互相不匹配的转换，像媒体转换这样的应用场景，它实际上执行了一个典型的媒体-终端或者“终止”服务器角色。关于对SIP编码转换有两种类型的定义规范，它们分别是RFC5369和RFC5370。在实战环境中，比较受欢迎的规范是后者的处理方式，通过内联会议桥接方式来实现B2BUA的角色，而没有使用请求列表中包含请求源URL的机制实现，通过B2BUA内置SIP编码转换器极大简化了正常请求的路由。SIP编码转换架构都基于所有从来自于SIP媒体服务器和SBC到TDM环路中的必要资源。因此，这样的处理机制就可以处理整个逻辑流程，从仅替换特定消息头/消息体和SDP需要执行的某些功能到替换几乎所有的SIP头和SDP content。一些编码转换器可以从UAC中的INVITE保存或移除SDP offer，等待一个从UAS响应的offer，这种处理方式来自于第三方呼叫控制（SPCC）模式。还有一些其他的编码转换器可以在SDP offer中插入其他的编码，如果被插入的编码类型是answer列表中选择的编码类型，则对其进行转换。

　　Conference Servers， 一般来说，会议服务器的功能定位不能完全符合B2BUA的定义，因为在会议服务器的应用中都涉及了多个各自独立的UAC发起的SIP会话，然后这些独立的会话最后汇聚到单个UAS端。但是，会议服务器支持RFC5366，在此RFC中，会议通过SIP包含请求URL的方式来创建，收到的INVITE请求会触发会议对UAS进行中心化处理，然后作为UAC对多个INVITE请求执行初始化流程。当执行这些功能时，它将以媒体-终端或者“终止”服务器的形式出现。

　　P-CSCF 和 IBCF Functions，3GPP定义了Proxy-Call Session Control Function (P-CSCF)和Interconnection Border Control Function (IBCF)功能，当需要配合IMS媒体面网关（AGW）和转换面网关TrGW等网关工作时，这些网关也承担着媒体转发和媒体感知的B2BUA的角色。

　　S-CSCF Function，同样，3GPP IMS也定义了Serving-Call Session Control Function (S-CSCF)，它承担了Proxy-B2BUA的角色。

　　关于B2BUA在3GPP IMS中会话控制层的接口，读者可以参阅基于开源SER扩展开发的FOKUS OpenIMS core的示例来加以说明。更多关于3GPP IMS core，笔者在后期的文档针对3GPP IMS core中会话控制部分加以详解说明。

　　在以上章节中，笔者根据RFC7092对SIP技术架构中背靠背代理做了深入解读。可能读者也注意到了这些概念之间存在着互相“冲突和重叠”的内容说明。从理论来说，这些分类是必要的，为我们了解这些模块提供了指导和技术结构脉络。但是，在具体应用环境中，这些分类角色实际上是混合在一起使用部署的。伟大领袖一直告警我们反对教条主义。所以，为了避免我们成为新生代的“杠精” 或者非黑即白者，我们一定不能以绝对化或者简单化乃至于非常教条的思维去理解这些功能概念。笔者建议，读者可以从三个比较大的抽象层面理解它们之间的不同。第一个理解层面是根据SIP信令面和媒体面两个基本的层级进行分解。另外，读者必须根据这些B2BUA对信令控制程度和媒体控制程度加以区分。并且，在某些具体功能管理实现方面，它们的功能侧重点也做出了相应的调整。通过以上几个角度的分析，我们就基本明确了这些角色分类的必要性。同时，我们也知道，在商业产品中和环境中，客户需求是一个真实的存在，产品定位是根据具体客户需求来开发的，它可能同时支持了多种具体的B2BUA的业务角色。因此，一个完整的产品是支持多种B2BUA角色功能的，这些产品可以根据功能需求做灵活设置。比如，一个B2BUA的SIP IPPBX场景中，它可能可以支持SIP 信令中某些消息头字段的修改，SDP修改，也可以实现编码转换功能。当然，它可以根据具体的业务场景需求，可能仅对某些功能执行转发功能。另外一个当前比较常见的B2BUA角色场景是会话边界控制器-SBC，笔者在很多历史文档和本文档中做了很多的深度解读和技术讨论，它就是一个非常典型的对SIP信令面，媒体面以及业务功能管理几个方面深度介入和进行管理的B2BUA角色场景。SBC必须对这些数据进行深度介入管理才能作为IMS网络中核心的网元产品，否则就不能完全接管SIP/IMS接入的需求。当然笔者要提醒读者，在实际应用环境中，绝大部分厂家的会话边界控制器产品根据自己的开发定位对功能侧重点支持有所不同，但是其核心呼叫控制的逻辑是完全一致的。

　　在本分享文章中，笔者根据RFC7092对B2BUA做了比较初浅的分享。这些内容涵盖了RFC7092的基本全部内容。在此文章中针对SIP技术架构中我们经常看到的B2BUA进行了详细说明解读，同时笔者根据具体B2BUA的分类针对不同的用户场景和应用做了说明，最后，因为读者对B2BUA的分类概念比较迷惑，笔者针对这些概念和具体应用，以商业的角度对根据三个不同层面来帮助读者理解这些设计的合理性。

　　笔者再次提醒，对于SIP B2BUA分类仅是一个理论层面的规范，在实际应用中无此严格的规定和定义。所以，大家仍然需要从理论指导实践的角度理解B2BUA，同时能够把这些概念灵活运用到实际用户环境中。如果实现了以上的目标，笔者的“唤醒者”的小目标也达到了。
 

　　www.dinstar.com

　　www.asterisk.org.cn

　　https://www.rfc-editor.org/rfc/rfc3261

　　https://datatracker.ietf.org/doc/html/rfc7092

　　https://www.rfc-editor.org/rfc/rfc5366

　　https://www.rfc-editor.org/rfc/rfc5370

　　https://www.rfc-editor.org/rfc/rfc5369

　　https://www.rfc-editor.org/rfc/rfc4975