SBC的背景介绍，两种工作模式
SBC的七大核心功能，包括基本要求，技术架构带来的问题，流程示例
1、这里，笔者简单通俗地介绍一下SBC的诞生。因为最近几年的IP化过程越来越快，运营商对语音服务的能力支撑也发生了很多变化。IMS网络是其中的一个重要里程碑。如果不同运营商之间对接时，首先需要安全方面的保证，同时需要两个网络之间可以实现良好地兼容性支持。因此两个运营商都需要在网络边界的地方做一些管理控制来支持运营商自己的业务流程，而且能够支持第三方运营商对接的业务协议规范。为了保证几个运营商之间的对接连接，也为了保证运营商本身的业务安全，因此，需要一个边界会话控制的设备或者解决方案来扮演一个边界控制的角色。SBC就因此逐渐出现在了通信产品的市场上。
尽管现在市场上很多的SBC厂家，每个厂家都有各自不同的特点，而且很多时候，厂家之间的兼容性也存在很多的问题，但是因为市场需求的原因，所以很多运营商客户和企业客户仍然需要SBC这个产品。今天，RFC5835协议中重点讨论的是如何使用SBC来保证运营商的需求，同时说明这些架构中存在的一些问题，让客户明白目前存在的这些问题，以便能够让客户在部署SBC方案时有充分的论证。
客观地说，目前没有一个关于SBC的标准功能的明确说明。很多厂家基本上都支持大部分客户需要的功能。一般的SBC会部署在两个运营商网络之间，来支持peering的网络环境，也可能部署在主干网络和企业客户之间实现access 网络环境。他们都会提供基于会话的媒体服务，包括权限访问控制，防攻击，NAT服务，流量管理，终端集成等相关功能。当然，终端也可能提供一些类似功能，实现一些或者部分的SBC功能，例如编码转换，简单访问控制等功能。
2、基于SIP的SBC一般来说可以提供对信令和会话的处理，工作方式可以看作是一个私有服务处理，执行对header的私有服务处理。在进行私有参数进行处理时就可能涉及一些SIP header，session的修改。关于SIP privacy的处理机制，用户可以参考RFC3323进行进一步的学习。SBC需要修改一些SIP header和消息体来保证服务的成功，但是proxy则不会支持这样的操作。我们以前介绍过，SBC一般来说就是一个B2BUA，SBC可以修改一些必要的SIP数值。SBC是一个透明代理，它可以根据功能的需求来执行一些必要的修改。以下是一个SBC的简单技术架构，通过配置SBC可以实现对inner network的管理。
一些SBC的操作支持用户准许的，对用户本身没有什么影响。但是一些SBC的应用场景中，SBC的操作是没有支持用户准许的，SBC可以修改一些必要的SIP消息来完成某些运营商或第三方的要求。因此，这样的结果就会导致一些潜在的问题。在某些应用场景中，运营商可以强制要求企业用户的SIP服务必须通过SBC来实现互联互通，而在另外的场景中，运营商为了满足编码转换的要求，可能需要把SBC部署在企业语音网关的前端来实现编码转换。下面，我们介绍一下SBC的两种部署方式：Peering 模式和Access 模式。
在Peering 模式环境下，两个运营商的服务通过SBC来进行对接，运营商之间互相进行数据通信。当运营商A 对SBC发起一个INVITE时，SBC会转发此INVITE到运营商B的软交换（SS-B），软交换SS-B经过路由处理以后，SS-B 会redirct 3xx 消息到SBC，SBC 然后路由到运营商B中的GW-B1终端。 如果运营商B没有部署SBC，这软交换会直接回复给运营商A发起INVITE 的网关。
如果从SBC的网络角度，结合前面的图例，我们可以看出，这里的运营商A就是outer network，运营商B则是inner network。运营商B使用SBC来保护自己的内网网关，软交换，进行数据管理。运营商B可以简化自己的网络，实现最少的ACL用户的管理，运营商B内网的网关，软交换和其他媒体服务器没有暴露在peer的网络中，运营商完全通过SBC避免了网络的暴露，实现了严格的安全控制。
在Access的部署场景中，SBC需要部署在outer 网络或者access 的网络和运营商的边界。这里的运营商网络就是一个inner network网络。因为SBC是呼叫 stateful的，它可以实现访问的控制，例如订阅功能的设定，防止服务器过载。SBC可以作为终端的outbound proxy地址。SBC则可以运营商的proxy部署支持。
这里的SBC可以根据终端用户的实际情况，可以部署在一般的企业用户侧，也可以部署在运营商侧。无论如何部署，实际上，运营商都可以控制SBC的访问和对外部网络的保护。
大部分情况下，终端会部署在在企业客户场景中（如以上图例所示），本身可能面对NAT的问题。这里的Access 网络可能就是一个私网环境。SBC可以通过修改Path header或者Contact Header来实现NAT的转换。关于如何通过Path添加一个SIP 节点记录的技术细节，以及Path和Record-Router的不同，用户可以参考RFC3327来进一步学习。
这里，我们会介绍SBC的七大核心功能，这里的七大功能仅是RFC5853中所涵盖的功能要求，不会涉及具体厂家的第三方功能。我们主要介绍SBC的七大核心功能，架构所带来的问题和流程示例。根据RFC5835的说明，SBC所具备的七大SBC核心功能包括：
1 拓扑隐藏
1.1 背景介绍
拓扑隐藏的主要目的是运营商不想把运营商网络中的网关，软交换，应用服务器等相关的信息暴露给外部网络。这样可以防止来自外部的网络攻击。同时，运营商也不能把运营商网络的所有内部网关，媒体服务器，其他软交换暴露给终端客户。一般的拓扑隐藏的实现方式是通过截取Via和Record-Route header，替换Contact header甚至于通过修改call-IDs的方式来实现。但是，在实际部署环境中，SBC替换一些header时会面对很多的问题，一些IP地址和header值也不能移除。使用SBC的IP地址可替换这些IP地址来实现网络拓扑隐藏方式。有很多种拓扑隐藏的方式，其中一种，在信令路径中插入一个中间节点就是其中一种方式，SBC就是这种方式的典型代表。另外的方式也可以使用User-Agent-Driven Privacy Mechanism 来实现，具体的规定用户可以参考rfc5767。
1.1 技术架构问题
拓扑隐藏架构带来的问题也是非常明显的。因为，SBC没有获得用户准许，修改了用户的信息来实现网络拓扑隐藏。这里的用户是基于Hop-By-Hop的信任模式来进行通信的，而不是End-to-End 信任模式实现，因此是没有获得用户准许的。SBC是修改了很多的用户私有消息，安全信息才能实现用户的要求，用户没有办法区别是来自于SBC的呼叫还是中间人（MITM）的攻击。另外，SBC可能导致身份认证机制失败。因为身份认证机制（RFC4474）是通过From, To, Call-ID， CSeq， Date，Contact和消息体构成，认证机制是通过四个步骤，基于哈希值获得的。如果SBC没有提供认证服务的话，修改过的SIP消息通过认证机制计算后可能出现安全认证失败。
1.2 示例
现在，我们通过一个示例来看一下如何修改Record-Route和Via实现拓扑隐藏。SBC（p4.domain.example.com）收到的INVITE消息，修改前的信息是：
经过SBC修改以后，移除了Via和Record-Route，保存了修改记录后，实现了拓扑隐藏，地址修改INVITE的SIP消息修改为 SBC的地址：
SBC会保存所有相关的修改记录，如果SBC重新启动或者出现故障的话，这里的会话记录可能会丢失。这里，除了SBC可以实现拓扑隐藏以外，SBC也可以实现身份隐藏，例如订阅身份的隐藏。SBC可以修改Contact header值或其他和身份修改的值域来实现身份隐藏，其修改的身份信息包括：P-Asserted-Identity，Referred-By，Identity和Identity-Info。这些参数的修改完全取决于用户的实际要求。这里不再继续展开。
2 媒体流量管理
2.1 背景介绍
SBC的媒体流量管理功能的目的是控制媒体理论，并且对其进行管理。运营商需要对订阅的用户进行媒体流量管理。一个重要任务就是对订阅用户根据不同的业务进行不同的计费，例如视频呼叫或者语音呼叫。另外，根据用户订阅的要求，实现对用户实现强制编码使用。
很多情况下，根据一些运营商或者国家相关的法律规定，需要对某些呼叫进行监听。运营商可以通过监听设备来实现对呼叫话务的监听，而无需SBC。大家知道，一般情况下，信令路径和媒体路径是完全不同的，信令路径必须通过运营商，但是媒体路径是不一定的。除非SBC修改了媒体的路径，这样，媒体才能经过SBC。SBC通过修改媒体描述可以强制媒体转发。这样的话，可以支持QoS服务和强制使用运营商指定的编码（例如，强制使用G.729等）。还有一些运营商可能不会对媒体进行管理，因为某些业务的规定，可以对某些已订阅的用户进行检测流量。使用SBC来管理媒体还可以对呼叫的“Bye 消息丢失”进行处理。很多情况下，终端因为某些原因，例如网络问题或者终端突然不能正常工作，可能出现丢失Bye消息的问题。丢失Bye消息可能导致很多的问题，首先用户体验不好，其次，对终端用户计费失去控制，出现计费错误等。SBC会使用VAD或者其他手段检测到用户用户的媒体处于无流量状态，SBC发送一个Bye消息到终端用户。最后，如果终端用户在呼叫过程中出现欠费问题，运营商可以及时检测到此问题，同时发送一个计费提示或者结束呼叫。
2.2 技术架构问题
SBC对媒体流量进行管理会带来很多的技术问题。通常情况下，因为SBC需要修改SIP的会话描述来实现对媒体的管理。但是，如果终端对媒体或者信令进行了加密处理的话，那么SBC就可能不能正常工作。如果SBC进行了会话描述的修改，则会破坏用户的准许，而且终端用户没有办法正确判断是SBC执行的流程还是中间人攻击的流程。另外，如果SBC在媒体路径中插入了媒体转发的服务，此服务如果不能正常工作或者缺乏良好地兼容性的话，SBC的媒体转发服务可能破坏IP和传输层某些功能需求，例如反馈协议失败（ECN）或最大传输单元的问题（PMTUD）。这里读者还要注意，如果SBC来集中处理媒体的话，可能导致SBC服务器的负载增加，同时可能导致媒体路径转发路径的阻塞，出现语音质量问题和迟延。
2.3 示例
SBC对媒体管理的应用示例中就会说明在B2BUA的环境中，SBC如何实现修 改编码的管理。SBC收到一个从outer 网络来的INVITE，这里的outer网络是Access 模式的SBC网络环境。SIP的修改前的SDP 消息如下：
经过媒体协商，SBC的媒体管理功能修改后的消息如下，其中重写了m=行，移除了a=rtpmap:98 L16/16000/2：
在实际部署环境中，很多不同的终端支持了不同的编码支撑能力，而且可能出现很多新的编码支持能力，所以需要SBC能够同时支持不同编码之间的协商，保证各种终端能够完全正常工作，这对于SBC的性能和处理会话描述的能力是一个非常大的挑战。
3 修复支持能力错误匹配
3.1 背景介绍
SBC的修复支持能力错误匹配功能可以支持不同终端用户和不同拓展的通信。SBC可以支持普通SIP用户连接3GPP网络，终端双方具有不同的IP地址版本，不同的编码格式，或者不同的地址realms。SBC可以对这些支撑能力进行匹配，最后实现正常的业务需求。另外，在实际部署环境中，SIP终端可能支持很多不同的拓展和methods，SBC修复这些支撑能力。
3.2 技术架构问题
和前面讨论的媒体流量管理一样，如果要求SBC支撑不同的能力，并且对其加以修复的话，SBC需要在媒体路径插入一些必要的SIP SDP描述。这样的话，SBC也没有经过用户准许，它破坏了端对端的安全机制，也破坏了应用场景的协商机制。如果大量终端用户需要支撑能力修复的话，SBC就会产生很高的负载，最终导致SBC需要同时并行处理大量的错误匹配修复任务。
3.1 示例
SBC错误匹配功能的修复有很多示例。现在来看一个简单的示例，终端用户IP地址的修复，从IPv4 修改到IPv6。这里的inner network是一个Access 网络，带了IPv4的地址，outer 网络带了IPv6的地址。SBC从Access 网络收到了一个INVITE消息，带有以下会话描述：
经过SBC的错误匹配修复以后，SBC添加了Record-Route, 另外一个Via，增加了一行带IPv6的c=。以下消息会发送到IPv6的网络中。
4 保持SIP相关NAT绑定
4.1 背景介绍
SBC必须支持NAT相关的绑定来保证NAT功能的实现。这里的NAT指的是通过特别的消息修改来帮助终端用户保持一个SIP的媒体有效的媒体连接。通常情况下，位于NAT后的终端用户和代理或注册服务器，或者其他的终端需要一个持续连接的状态来保证终端用户的有效性。SBC的NAT相关绑定功能就是为了控制NAT后的终端用户的连接性。SBC通过周期性地生成网络流量来支持绑定的生命周期。SBC的相关NAT绑定功能要求SBC是在NAT之外。
SBC的NAT绑定功能支持NAT后的终端用户和注册服务器之间的通信。NAT问题普遍存在于各种网络环境中，运营商要求支持注册服务的功能。但注册服务器收到了来自于终端用户的REGISTER请求时，它会回复一个200 OK的响应消息给终端用户，这里的SBC需要修改一个响应消息，降低注册的认证时间响应。这样的话，SBC就需要强制用户很快重新发送一个新的REGISTER请求来保持一个生命周期的存活，终端用户在NAT环境中能够始终保持绑定状态，不会出现绑定超时的问题。 这里，读者要注意，SBC无需转发所有从终端用户来的注册请求消息到注册服务器。在注册超时之前，SBC会自己对来自终端的注册请求重新生成对注册服务器的响应消息，保证注册不会超时。另外，SBC同样需要控制终端用户注册失败的流程，如果终端用户没有注册成功的话，即使这个注册请求在注册服务器仍然处于有效状态，SBC需要执行一个业务处理，它不再为此终端用户发起注册请求。这也是很多实际工作场景中，一些终端用户为什么有时会出现注册失败的原因。以上所介绍的是关于信令方面的绑定设置，SBC同样也可以为了NAT强制媒体转发。这里不再做过多讨论。
4.2 技术架构问题
SBC支持了NAT绑定的功能以后，技术架构同样也面临很多问题。如果一些安全机制处理方式使用了S/MIME的话，SBC实现的NAT相关绑定不能支持端-对-端的安全机制或安全保护机制。因为，这里，SBC被认为是MITM中间人攻击的角色，SBC需要修改终端用户和注册服务器之间的消息体。另外一个问题是和SBC设置的注册生命周期相关。SBC可能需要这个时间设置越高越好。为了保持生命周期的存活，这个生命周期可能需要调整在一个非常合适的值来保持NAT绑定的状态。一些SBC产品可能没有这么非常灵活的设置，同时，终端用户的网络环境差异也非常大，所以可能导致用户的NAT绑定出现问题。SBC的NAT相关绑定功能也可能引起媒体处理的问题。SBC通常情况下会猜测媒体流中接收方公网IP地址，这个媒体流可能是这个SBC转发的，侦测到的媒体流源地址，也完全可能是同一SBC转发的媒体流地址。这样可能出现安全问题和兼容性的问题，或者转发到错误目地地。网络攻击者可以侦测到SBC中的媒体转发的IP地址和端口，对这些地址进行发送数据。另外一个问题是如果在NAT后的终端用户通过re-INVITE切换了媒体流的IP地址。如果媒体流数据出现发送顺序问题或者网络时延，即使re-INVITE可以成功通过，SBC仍然可能会过滤这个地址切换后发送的媒体流数据。
4.3 示例
现在，我们看一个相关NAT绑定的示例，此示例说明了通过SBC修改了超时设置的参数。SBC部署在终端用户和注册服务器之间。SBC收到了以下注册响应消息：
通过SBC相关绑定的功能修改后的消息如下：
当然还有其他的方式对NAT的生命周期进行绑定处理，我们这里仅讨论在SBC中的功能设置。
5 访问控制
5.1 背景介绍
SBC需要支持访问控制功能。访问控制是运营商网络环境中一个必不可少的功能要求，运营商需要对人员进入到运营商网络内部的用户，业务进行控制管理。SBC可以设置成为一个SIP的防火墙，对SIP数据进行流量管理或者路由，同时SBC的控制管理可以根据管理员的业务要求设置一定的权限。
SBC的访问控制功能可以应用在信令或信令媒体两种环境中。如果SBC的访问控制功能仅支持了信令的话，SBC可以看作为一个代理服务器的角色。如果SBC的访问控制功能支持了信令和媒体的话，则SBC的访问控制就被看作是一个B2BUA的方式，SBC的访问控制可以对已认证的会话进行媒体转发处理。
SBC的访问控制功能同样也可以实现比较具体的业务功能，他们包括：防止DoS攻击，数据的优先级管理/重新路由等相关功能，执行均衡负载管理/降低设备的负载处理。另外，SBC还可以应用在一些网络带宽非常限的环境中。SBC可以计算用户根据编码支持能力所需的网络带宽。结合网络带宽的要求，SBC可以在网络带宽耗尽之前拒绝拒绝新的会话进入，同时能够保证当前会话的语音质量和服务。否则，网络连接就会出现用户过载的问题，用户服务不能得到充分的保证。当然，SBC可以通过一定的拓展，对接运营商的业务保障服务器，可以对基于每个会话服务进行策略支持来决定是否网络有足够的带宽来支持用户。
5.2 技术架构问题
SBC的访问控制功能同样也需要面对很多的技术架构的问题，这些问题可能需要拓展其他的应用来实现。很多时候，SBC设备是一台单点设备或者基于云部署的解决方案，为了保证大批量用户的正常工作状态，SBC同样需要双备份冗余的配置来防止单点设备故障出现的呼叫丢失或会话丢失的问题。另外，如果SBC的访问控制仅实现的是信令控制的话，其基本架构和SIP的其他技术架构是一样的，读者仅需要按照一般SIP技术架构来面对这些问题。如果SBC的访问控制功能支持了信令和媒体的话，那么访问控制的技术架构带来的问题或者挑战和媒体管理功能是一样的。
5.3 示例
SBC的访问控制实现示例如以上图例所示（为了简单说明问题，忽略了ACK消息），SBC首先确认呼叫方的身份，然后修改会话描述中的一些SDP参数。这里，呼叫方需要通过注册认证服务器的认证。然后，SBC把修改后的消息发送到被呼叫方，被呼叫方返回200 OK和SDP消息，SBC返回修改的SDP消息和200 OK 到呼叫发起方。双方进行媒体通信，SBC检测协商的编码类型是否一致，最后创建媒体流。
6 协议修复
6.1 背景介绍
SBC的协议修复功能可以支持一些非标准的，由非标准设备或终端生成的协议消息。运营商可能需要SBC来支持某些协议修复的功能来支持更多的终端用户。这里读者要注意，协议修复功能仅可能影响SBC的信令模块，协议修复功能和协议转换和完全不同的。
6.2 技术架构问题
SBC的协议修复功能的目的是支持修复SIP header来兼容SIP的协议架构，它不会破坏SIP端-对-端的模式。SBC的协议修复消息可以被看作是一个代理服务器的处理流程，它们相对比较宽泛，它可以接受或限制它们发生的信息。但是，SBC的协议修复仍然存在技术兼容性的问题。协议修复可能破坏某些安全机制，这些安全机制结合SIP header使用了不同的算法。需要修复同样也会修改SDP消息体的内容，这样会导致身份认证管理和端对端安全机制的兼容性问题。最后，如果进行协议修复的话，同样会导致和修复支撑能力匹配一样的问题，SBC的修复协议的功能会更加复杂。
6.3 示例
SBC的协议修复示例如下图例所示，这是一个相对比较新的用户的INVITE消息，它经过SBC的协议修复功能处理以后，在Via header中添加了重写的参数lr设置为true或ON（kamalio rr模块配置为on）来支持一些非标准的SIP协议场景需求。
7 媒体加密
7.1 背景介绍
SBC同样也可以支持媒体加密的功能，这也是运营商或企业用户在某些特定场景下所必须支持的功能要求。它可以支持在网络边界处进行媒体加密或解密。有一种情况，但媒体加密（例如，SRTP）运行在Access网络（outer网络侧），在inner网络中传输未加密的媒体流。一些运营商可以提供合法侦听，这些运营商同时也提供access网络的加密处理能力。这样的话，运营商就需要SBC具有媒体加密的功能服务。
7.2 技术架构问题
SBC的媒体加密技术架构需要在媒体路径中注入SBC自己的控制参数，也可能需要其他第三方的实体注入到媒体路径。这样就会导致前面我们讨论的问题，可能出现中间人攻击的问题。
7.3 示例
这里我们简单介绍一个SBC媒体加密的处理流程：
首先，UAC发送一个INVITE请求，第一个SBC通过自己的方式修改SDP消息，注入自己的媒体路径。第二个也执行同样的流程，然后发送到UAS。UAS 返回 200 OK， SBC 同样在返回的媒体路径注入自己参数。信令交互完成以后，开始媒体互通，两个SBC执行媒体加密和解密处理。
3、以上部分是完整RFC5853的关于SBC部署的标准协议。今天的IMS网络环境中，SBC扮演着更加重要的角色。为了让读者能够对SBC的功能有一个更加清晰地认识，笔者结合IMS网络，对SBC在IMS网络中的功能做一个简单介绍，让读者能够全面了解SBC的功能和作用。在3GPP的IMS架构中，SBC包括了A-SBC（Access Session Border Controller ）和I-SBC（Interconnect Session Border Controller 两种，它们分别执行不同的功能。在下面的介绍中，笔者分别列出了不同的管理模块，方便读者做进一步的了解。如果读者需要对IMS中的SBC做更多了解，读者可以查阅3GPP技术细节。以下图例是一个非常简单的两个运营商之间的SBC对接方式，另外，在IMS核心网中A-SBC所控制的模块。
4、这里，笔者主要列出IMS网络中A-SBC和I-SBC各自执行的功能，因为IMS网络中的SBC功能不是我们今天讨论的重点，另外篇幅有限，笔者不可能完全展开讨论。今天，我们通过简单的功能列表配合图例可以非常清楚地了解IMS中A-SBC和I-SBC的功能，笔者读者清晰判断各自的功能。
IMS中的A-SBC主要负责处理用户订阅和IMS核心网的边界管理。
企业SBC对接方式，IPPBX下挂SIP终端，网关等设备。
A-SBC支持的功能包括：
- Proxy Call Session Control Function （P-CSCF）功能。
- Core Border Gateway Function （C-BGF）功能
- Tunnel Terminating Gateway （TTG） 功能
- IMS网络中的I-SBC功能主要负责不同运营商之间的连接的边界管理。
I-SBC支持的功能包括：
- Interconnect Border Control Function （I-BCF） ，Translation Gateway，Topology Hiding Interwork Gateway （THIG）。
- Inter-Working Function （IWF） ：IMS网络和非IMS网络的对接。
- Interconnect Border Gateway Function （I-BGF）
6、今天，我们全面讨论了SBC-边界会话控制器部署协议-RFC5853，它是一个关于SBC部署的规范建议，重点说明了SBC的七大核心功能，每个功能带来的技术问题和挑战，然后通过对应的示例，说明了这些功能的工作流程。这是目前为止，SBC部署最权威的规范，读者可以通过这些规范了解SBC的功能和部署时需要注意的问题。结合IMS网络中的SBC子功能，笔者通过完整图例介绍了IMS网络中SBC中的A-SBC和I-SBC的功能，希望能够帮助读者完整了解SBC技术架构和相关规范。有兴趣的读者可以继续根据IMS网络的模块做进一步的学习。
参考资料：
https://tools.ietf.org/rfc/rfc5853
https://www.rfc-editor.org/info/rfc3323
https://datatracker.ietf.org/doc/rfc3327/?include_text=1
https://datatracker.ietf.org/doc/rfc5767/?include_text=1
https://www.rfc-editor.org/rfc/rfc4474.txt
https://telcoloewe.wordpress.com/2010/02/10/session-border-controller-sbc-border-gateway-in-3gpp/
https://wiki.freepbx.org/display/SBC/SIP+Trunking
http://freepbx.org.cn/wiki/index.php?title=SBC%E5%BA%94%E7%94%A8%E5%9C%BA%E6%99%AF
关注微信公众号：asterisk-cn，获得有价值的Asterisk行业分享
Asterisk freepbx 中文官方论坛：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技术文档： www.freepbx.org.cn
融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com
Asterisk/FreePBX中国合作伙伴，官方qq技术分享群（3000千人）：589995817
