地址：http://blog.sina.com.cn/s/blog_4ca9ceef0102xoaz.html

SBC概述

Session Border Controller，即会话边界控制器SBC已经逐渐成为NGN和IMS网络的标准配置产品（如同Lanswitch和路由器）。也被广泛称为BAC（边界接入控制器），定位在IMS网络的ABG (access border gateway) ，解决NGN业务部署中遇到的NAT/FW穿越、安全、互通、QoS等问题。

 

 

会话边缘控制器（SBC，或会话控制器）是VoIP呼叫控制产品，用于电话完全由VoIP传输而不需要网关的环境。它使用全部三种VoIP协议——H.323关守、SIP代理和媒体网关控制协议（MGCP）。它会在未来的VoIP服务提供中发挥重要作用，允许跨越多个IP网络，即使有防火墙要穿越，也能提供有质量保障的VoIP服务。

SBC一般位于控制VoIP服务的软交换和公共Internet之间，有如下功能：

l 网络地址转换和穿越：由于用户侧存在复杂的网络环境，比如防火墙、NAT（Network Address Translation），位于NAT后的用户可能无法正常地使用IMS网络的多媒体会话业务，而SBC的部署可以为多网络环境下的用户提供业务的接入和互通功能。

l 网络安全控制：用户行为是不可知的，广大通过互联网接入IMS网络的用户行为是不可控的，为防止对IMS网络的非法攻击，需要在网络的周边部署必要的防护措施，SBC网元在发起业务的同时会删除与路由相关的信息，从而完成网络拓扑隐藏的功能，避免IMS核心网成为攻击目标；此外SBC还具有门控功能，即根据特定的条件，允许或禁止某些用户通过其使用IMS网络业务；过载控制则是根据IMS网络的负荷，控制每秒钟的呼叫数量，以避免网络负荷过重而引起的系统瘫痪。

l QoS（Quality of Service）功能：即服务质量，指某网络提供更好服务的能力。在IP网络中QoS 用于确保重要的通话业务量不被延迟或丢弃，SBC网元可以基于呼叫数量进行限制，确保服务中的用户享受高质量的网络服务。

SBC产生背景

 

在前面的关于SIP和NAT问题的讲座中，我们花费了大量篇幅把整个关于SIP和NAT的各种问题做了比较全面和深入的探讨，同时，我们也介绍了各种针对NAT的解决方案，但是那些方案仅解决了SIP在互联网环境下的局部问题，也没有考虑到整个企业IPPBX环境所要求的其他业务能力的支持。尽管那些解决方案在某些特定的环境中实现了某些用户的要求，但是它们本身还是具有一定的局限性和针对性。SBC则比较好地解决了我们讨论的问题，但是目前在市场上很少看到对SBC技术的全面介绍和剖析，很多公司的SBC介绍也仅局限于市场需求，使用了太多市场语言把SBC，很多描述可能有一些含糊不清，另外，一些相关的技术问题也缺乏更多详细说明，用户在了解和学习这些相关知识时会产生很多困扰。

笔者虽然在差不多6年前开始接触SBC，这期间也多多少少接触了一些客户，基本上了解一些客户对SBC的需求和目前存在的潜在问题。为了结合我们的SIP系列讲座，笔者今天对SBC做一个比较全面的剖析，尽可能覆盖大部分用户所关心的问题，这样可以帮助SBC用户能够比较全面地对SBC有一个概括。我们讨论的范围从SBC使用背景和由来，市场需求，使用场景和存在的问题进行一个基本梳理。笔者不会在这里讨论过多某个SBC厂家的产品技术细节，如果特别需要可能会适当加入一点厂家的SBC内容，帮助用户理解SBC，否则读者可能产生歧义。

笔者主要从几个方面来剖析SBC的全貌，这些内容包括：SBC的基本概念，SBC产生的背景原因，SBC的市场情况，SBC的核心功能，SBC运营商和企业客户的使用场景，SBC的功能介绍，SBC录音时的性能问题，SBC部署时的问题，SBC对SIP的流程的影响，SBC在IMS网络中的角色，SBC虚拟化的可能性和基于开源解决方案等方面的内容做一个全面的剖析（尽可能全面），帮助用户全面了解SBC技术。

首先让我们介绍一下SBC产生的背景。任何技术的产生都是基于一定的背景，只有客户端需求越来越急迫的时候，一些对行业敏感的厂家就可能抓住机会来开发这样的产品满足消费者。举个例子，故事的大概过程是这样的。当年美国早期的淘金热时，Lee牛仔裤的畅销就是因为Lee的老板抓住了商机。当时西部淘金时矿工抱怨说为什么没有一条结实一点的裤子，同时裤兜的地方老是开裂，Lee当年正好从事布匹的批发业务，他琢磨了半天，把当时做帆船的帆布经过改造，结合裤子上打铆钉的创意生产出了非常结实的牛仔裤。然后，Lee就开始在全世界大卖。这样的例子数不胜数。VoIP的发展也是这样，随着VoIP的不断发展，服务提供商不只提供一个简单的语音通话的功能，在实际的VoIP运营环境中，SBC设备没有真正部署或应用之前，市场上没有专门的设备为服务提供商和服务提供商自己实现完整的对接解决方案，同时也没有一套完整的解决方案来实现运营商和终端客户之间的对接支持。为了满足运营商服务的要求，很多厂家开始研发SBC做为一个运营商边界网络的设备来支持运营商的需求。在典型的应用环境中，SBC作为运营商VoIP网络边界的互联设备，这样运营商之间可以实现通信和策略控制。

    SBC相关几个概念

在介绍SBC的细节之前，让我们首先明确几个基本的概念：

• SBC的全称是Session Border Controller。简单来说，SBC是部署在网络边界，用来控制SIP会话的设备或软件。Session 表示会话，Border 表示网络边界，Controller 表示控制器。注意，这里的控制器很多用户理解为是物理设备，事实上，也有很多厂家推出了基于软件的E-SBC。

• 除了我们讨论的SIP相关的技术范畴之内，目前没有关于SBC非常明确的定义规定。

• 根据RFC5853的定义，SBC被定义为一个B2BUAs，它可以实现对某些SIP 头消息和SDP媒体描述进行修改。

   

  
   

   

  在下面的图例中，橙色部分就是经过SBC处理以后的相关参数。注意，不同厂家的SBC或不同的业务需求对参数修改可能有所不同。这里的案例仅做示例来帮助用户了解SBC的流程。

   

• 
   

• 很多时候，一些客户使用常用的概念来表示SBC的部署边界。SBC在不同场景使用时的几个主要概念：Peering SBC支持服务提供商对服务提供商的对接，Access SBC提供运营商和企业用户SBC的对接，Enterprise SBC提供企业之间的对接。

  
   

市场发展的要求

综合前面讨论的几个NAT解决方案的介绍，无论从技术层面还是未来网络的拓展性方面，那些解决方案很难说是一个最终的解决办法。这些解决方案可能存在以下几个方面的问题和挑战：

• 不同客户的不同需求，几种NAT类型的解决方案面对的是不同的客户问题，不同的网络环境，不同的客户要求，所以，这些解决方案很难构成一个完整的解决方案去支持大部分的客户要求。

• 对服务提供商技术的挑战，几种解决方案对不同的公司有不同的要求，他们要求部署集成商提供专业的的技术水平，足够的网络带宽，良好的网络稳定性和兼容性。

• 终端用户的多样性，终端用户很难控制对端网络，对网络服务，语音质量，安全机制失了可控性，例如使用第三方的STUN/TURN服务。

• 缺乏统一管理的平台机制，对网络设置和安全机制的设置缺乏一个统一的管理机制。

• 终端对STUN，TURN和防火墙问题，对不同终端所要求的支持能力也可能完全不同。

• 未来的可拓展性，以上几种NAT解决方案缺乏对目前最新的SIP业务需求完整支持，例如IMS，电话转接业务，录音等要求。

• 对服务提供商的标准不同，缺乏对各种SIP服务提供商的兼容性测试标准，这样失去了对业务能力的保证。

• 对融合通信的支持问题，它们也缺乏融合通信的业务能力的支持包括未来业务的升级和拓展。

   

通过以上各种问题的总结，我们可以看到，SBC可能是目前SIP业务最佳的一种解决方案，这也是为什么最近几年SBC逐渐受到重视的原因。

市场调查

根据美国专注融合通信市场研究的Infonetrics所做的调查,到2018年, 预计SBC的市场需求是365 million 美金，大家可以看到这是一个非常庞大的市场。2013年是250 million 美金，到2018年则增长到了365 million 美金。增长速度非常惊人。

 

 

在此报告中同时列出了几个主要的SBC厂家：

 

在未来的5G/IMS网络中，SBC也扮演着非常重要的角色。我们在本章节的后续部分会介绍SBC在IMS网络中所扮演的角色。

 

 

 

 

SBC在运营商和企业用户的部署场景

大部分情况下，在介绍SBC的功能时，很多厂家的功能介绍解释的比较含糊，这样会导致用户对产品的认识缺乏明确的概念，客户可能丧失了购买信心。事实上，根据SBC使用的场景不同，SBC的功能有一定差别的。一般情况下，SBC 针对服务提供商和终端客户两种不同的场景需求。现在我们分别介绍一些功能要求。

 

 

 

以下图例标识了运营商和运营商对接的方式：

 

 

目前，综合各种SBC的功能需求，笔者把SBC的功能归纳为十大主要功能。根据服务提供商和          企业终端客户的需求不同，我们分别予以介绍。这里，笔者仅对不同服务根据业务的侧重点不同进行的简单分类，以方便用户掌握，不等于说运营商SBC和企业SBC功能上有什么特别的不同。SBC可以对服务提供商提供的支持包括：

1. IP地址隐藏

2. 权限访问控制，控制用户访问权限，控制呼叫数量。

3. 安全策略设置

4. QoS 保障

5. 计费功能

6. 服务提供商之间应该可以提供更大的拓展能力

    

 

 

SBC可以对本地企业IPPBX的功能包括：

1. 自动切换服务线路，如果服务提供商的工作中继出现问题，SBC可以自动切换到服务提供商的备份服务器。

2. 提供对本地IPPBX进行标准化处理，例如修改SIP SDP信息，编码转换，SIP-SS7的映射功能。

3. 提供QoS保障。

4. 可以提供协议的转换功能，例如内网使用TCP连接，连接服务提供商时则使用UDP连接。

5. 防止非法侵入和网络诈骗电话。来自Acme Packet的Kaplan总结了以下几种关于VOIP的攻击方式：

   
    

6. NAT支持，远端终端通过外网实现对内网IPPBX注册。

 

 

笔者根据不同的场景提供几个不同的解决方案图例：远端用户注册到企业内网SBC解决方案。托管IPPBX通过SBC对接的解决方案和企业SIP trunk的解决方案。

 

 

托管IPPBX通过SBC对接的案例。

 

企业用户接入SBC的案例：

 

 

当然，以上每一种功能都不一定是SBC用户必须使用的功能，根据融合通信行业著名市场分析公司IHS Markit的报告，它把SBC的几个主要核心功能概括为：编码转换，协议转换，NAT，拓扑隐藏，权限控制和安全控制。

 

 

 

另外，随着IMS网络的进一步普及，SBC需要支持IMS网络环境中，SBC需要支持sigaling plane（P-CSCF，I-BCF）和media plane（IMS-AGW，TrGW）。很多运营商已经对SBC在IMS网络的应用提出了非常紧迫的要求。因此，为了满足未来IMS的网络要求，SBC的功能不得不进行升级。在3GPP环境中，SBC必须实现可拓展性，虚拟化和分布式部署。

 

 

SBC在IMS网络中的功能模块：

 

 

 

在IMS架构中需要合并UNI边界部分和NNI的部分功能来实现SBC控制器功能。在UNI边界中的SBC控制部分：

 

 

在NNI边界部分的SBC控制部分，这里仅涉及了R7的访问。

 

 

目前，市场上比较领先的SBC设备一般集成IMS支持能力，也支持了以上几个主要的核心模块成为一个设备解决方案。

 

IMS网络非常复杂，笔者水平有限，加之篇幅问题，不能完整介绍整个IMS的架构。具体关于IMS网络的介绍，请读者查阅网络文档获得更加详细的介绍。

SBC功能详解

通过以上的篇幅，我们介绍了SBC的一些基本的功能和概念，笔者对SBC所支持功能归纳为十个具体的功能，它们分别是：

 

 

1. DoS预防：防止外网用户对内外IPPBX进行网络攻击，SBC可以提前设置一些策略来预防攻击。

2. DoS保护，如果有DoS攻击的话，SBC的处理能力可以支持DoS攻击，设置黑名单，设置尝试注册次数都是比较好的手段。

3. 权限控制：SBC可以控制用户认证身份，可以控制计费能力，可以控制呼叫能力权限。

4. QoS保障，通过SBC设置可以提供对QoS的语音保障。

5. 标准化重构，这里的标准化重构的含义是对用户提供的媒体能力，业务能力提供相应的转化，并且能够灵活地对对端进行支持，例如支持编码转换，SDP 消息体修改，SIP-SS7消息映射。

6. 检测功能，SBC可以检测网络状态，SIP信令状态，语音质量等相关信息。

7. VPN分离，SBC可以针对不同用户设置不同的VPN隧道功能。

8. 拓扑隐藏，SBC提供了内网IPPBX对外网不可见的能力，SBC提供修改后的IP地址相关信息，这样，外网用户不会看到内网PBX信息。但是，读者要注意，根据 RFC 5853中3.1.2的说明，SBC不能很好的配合Authenticated Identity Management 工作。

9. 系统资源优化，SBC可以提供SIP注册能力的均衡负载，SIP trunk的均衡负载，监控系统阀值，提供SIP/PSTN的逃生处理，保障系统达到最佳资源状态。

10. 防止非法入侵，SBC提供了对用户的认证和签权功能，同时提供了对信令语音的加密功能，SBC可以保障非法用户的入侵。

部署SBC需要关注的问题

尽管笔者花了很多时间介绍SBC的“好”， 但是在用户部署环境中仍然有一些问题需要用户考虑：

• 性能处理的问题，因为本身架构的问题，SBC是一个B2BUA，简单来说，就是SIP路径上的一个中间人。这样会导致很多问题出现，例如标准重构时需要处理大量的SDP消息，同时可能需要进行编码转换（关于编码转换的问题笔者以前专门做过介绍），可能还要接收和发送大量的注册消息，这些功能需要消耗大量的CPU资源和网络接口资源，可能导致SBC稳定性降低。

• 需要扩展逃生功能支持传统的PSTN，单纯的SBC设备为了支持SIP的服务，为了保证企业电话系统100%正常工作，需要增加多个trunk智能支持，也同时需要传统PSTN的接入。

• 国家法律的要求录音功能，大家知道，中国已经在最近几年开始要求一些敏感部门对电话进行录音。其实，美国在1994年就已经制定了关于通信设备支持电话侦听到法案（ CALEA）。在RFC 3924中也相应地规定了录音的要求。如果SBC不能支持录音的话，SBC的功能需求就大打折扣，很多项目中，客户也不敢使用不支持录音的SBC。但是，如果支持录音的话，SBC性能会受到很大影响，Menghui YANG 几年前发表了VoIP网络电话呼叫侦听对SBC性能的影响，以下是研究报告关于录音和不录音状态下，SBC的并发处理数据。通过此报告数据可以看出，录音或不录音状态下，对SBC的并发处理能力有很大差别。

  
   

• SIP REFER消息支持问题或呼叫业务转接支持也是一个值得重视的问题，有时，如果本地用户需要执行转接功能的话，运营商有两种处理方式，第一种运营商可能支持REFER，一般可能执行重新计费。当然，这里不排除利用转电话接功能实现长途呼叫功能，绕过运营商本地计费，事实上，这也是一种诈骗的方式。所以，运营商执行重新计费。第二种方式就是返回一个405 Method not Allowed消息，不支持本地用户的呼转服务。

   

  
   

  以下图例说明了在内网没有SBC的状况下，运营商会直接返回一个405消息，转接服务被拒绝。

  
   

  如果终端客户部署了SBC后，前面我们已经介绍过，SBC是一个B2BUA，可以修改SIP消息，重新发送一个带本地ID的Re-INVITE消息，运营商仍然看作是同一个呼叫，这样运营商会接受这个转接呼叫服务。

   

  再次说明，因为REFER存在着一个潜在的不安全因素，所以运营商一般会拒绝这个请求。关于REFER安全的讨论，大家可以查阅RFC3515的Authorization Consideration for REFER。

• 
   

• 关于号码归属地的问题。号码归属地可能导致计费错误，大部分情况这种可能性不会发生，但是有的运营商会根据SIP头带的号码来做一个简单的判断，判断号码属性。在用户多个分公司部署的环境下，如果没有严格设置号码路由，很可能出现分公司内网用户呼叫外地用户就变成长途呼叫的可能。例如，如果在深圳的分公司通过北京总部的PBX出局呼叫北京或者河北的用户，运营商很可能根据SIP带的号码归属地，认为这是来自深圳的呼叫，从而以长途计费。如果通过SBC重新修改成一个标识为本地PBX出局的号码身份，则运营商就会认为这是本地客户电话系统的呼叫，而不是一个来自外地的呼叫。SBC同时也可以根据路由的要求，添加一个号码归属地前缀，表示国家或者地区的属性。SBC也可以实现对tgrp的支持，通过添加tgrp标签，运营商也可以正确识别客户的SIP身份。

• SBC结合IPPBX的兼容性测试问题，网络有很多的讨论，笔者推荐根据Avaya的兼容性测试流程来进行测试。具体的测试项目包括：通过SBC IPPBX用户的呼出呼入测试，直接点对点的IP呼叫测试，DTMF测试-使用RFC2833进行IVR测试，语音等待测试流程测试，呼叫专接，电话会议，长时间呼叫摘机测试，录音测试和T38传真收发测试。如果读者真正想进行完整权威地对接测试，笔者建议参考SIPconnect 社区的测试标准来进行对接测试。

   

   

   

   

• 用户根据架构图实现兼容性测试，具体测试要求查阅参考资料的链接。以下是SIPConnect-2.0 的测试流程图：

•  

• 
   

•  

• SBC对WebRTC的支持问题。WebRTC技术是最近几年发展非常火的技术，在和SIP结合时，很多公司也建议使用SBC来解决编码转换的问题和语音加密的问题。这里需要注意，一些SBC编码转换功能可能还不能完全支持VP8 或最新的VP9。

   

 

SBC虚拟化的可行性研究

 

实际上，随着IMS 用户的不断增加，运营商对SBC的维护部署也有了新的要求，例如使用基于云的计算平台，使用虚拟化的解决方案都是可行的。首先了解一下传统的SBC架构，它是一种一体机设备的解决方案，包括DSP，Cryto 处理加密，TCAM处理媒体，CPU的核心要件。

 

 

 

 

国外一些公司已经开始着手进行SBC虚拟化解决方案的可行性研究，一些公司的虚拟化SBC解决方案已开始测试。他们的研究是基于目前比较成熟的云平台来实现。研究人员认为基本的云计算技术架构已经可以满足SBC的虚拟化部署，其主要根据是：

• Intel CPU的发展可以支持多核处理，支持虚拟化。

• Linux X86 结合强大的CPU 实现并行处理的能力不断强化，为SBC容量扩展提供了硬件支持。

• 开发自有的软件DSP负责编码转换，这里，研究人员也考虑了DSP的成本问题，不过，无论软硬件的DSP，成本一般都比较高。

• CPU可以被充分利用，DSP只做编码处理。

• 亚马逊的AWS对信令处理的性能比较满意，媒体处理能力也相对比较好。

• 分布式部署，信令和媒体独立处理，提高了扩容的可能性。

以上关于SBC虚拟化可行性的研究讨论都是基于云平台技术本身，当然也有赖于开发人员的技术实力。

SBC对SIP网络流程带来的挑战

我们在前面的很多章节中讨论了很多使用SBC的好处，但是SBC在实际网络环境的使用中，用户仍然需要面对很多不可知的挑战：

1. SBC会破坏整个端对端SIP的逻辑流程的自然属性。如果部署相对封闭的VoIP解决方案，SBC可能是一个需要考虑的问题。

2. SBC会破坏整个端对端SIP的呼叫流程，这样会导致UAS对SIP呼叫流程的监控和状态失去作用，并且增加了技术排查难度，可能增加其他设备或软件来弥补SBC带来的问题。

3. SBC不仅对信令进行二次处理，也对媒体进行二次处理，例如编码转换的流程。这样的话，会给双方的语音呼叫带来进一步的延迟，增加了运营商的带宽成本。但是，我们经常遇到的是，运营商提供的是相对占用带宽比较低的G.729, 这样就需要终端客户自己进行编码处理，这样就会导致本地IPPBX，网关或SBC必须做编码转换，同样增加本地用户的部署成本。

4. 加密以后的SIP和SBC结合会带来更加复杂的问题。记得一位麻省理工多媒体实验室的学者说过这样一句话- “Your advantages are your disadvantages”。 任何事情都带有两面性。具有讽刺意味的是，大家知道我们使用SBC是为了更加安全，如果IPPBX和终端之间已经使用了加密机制的话，SBC是最有可能出现问题的一个中间环节。根据RFC 5853 3.1.2 部分的说明，假设SIP终端都已经设置了加密的方式和IPPBX进行通信验证，SBC则需要获得SIP头内容和SDP的体，这里就要求SBC需要首先读取对发送到呼叫方的加密消息，并且SBC还要需要获得被呼叫方的确认和信任。访问被呼叫方的私钥可能还要涉及其他的服务认证设置。这样的流程就完全可能导致终端的协商失败。如果SBC移除加密机制，重新设置加密机制的话，那么SBC就会打破SIP终端之间的加密认证机制。这里再次提醒用户，根据 RFC 5853中3.1.2的说明，SBC不能很好地配合Authenticated Identity Management工作，具体说明读者可查阅RFC5853。

5. SBC支持媒体流量管理带来的问题。大家知道，SBC不仅仅对信令做出处理，同时也负责媒体的管理也包括媒体流量的管理。有时，SBC可以检测丢失Bye消息的媒体会话，丢失Bye消息可能就意味着这个呼叫在中间某个环节已经出现异常或者死掉，SBC必须通过检测媒体状态，然后返回信令挂机消息。有时，运营商会根据数据流量来计费，如果在媒体路径上部署了SBC的话，媒体经过SBC的转发处理，可能导致媒体数据丢失的问题，同时增加了SBC的负载。另外，和我们上面介绍的一样，如果终端客户双方进行了加密处理，SBC没有获得双方的许可，那么RTP加密认证又是一个问题。

6. SBC对标准化重构的支持问题。虽然SBC支持标准化重构。很多情况下，终端之间完全可能出现支持能力不同的问题，双方所各自支持的功能可能不完全匹配，这时运营商需要SBC重新进行标准化重构的机制，这样就可以满足双方的通话要求。如果在大并发处理的环境中出现大量类似的不同功能的标准化重构的话，SBC就需要支持大量的配置机制，并且能够保证并行处理大量的流程处理。例如，同时处理IPv4 和IPv6 转换，也可能同时处理G.711到G.729的转换，还有可能同时处理VP8 到G.711的转换或者TCP到UDP的转换。这个问题需要SBC用户尽可能做一些进一步的研究，选择真正有处理能力，能够完全支持复杂环境的SBC产品。

7. SBC备份的问题。如果一个单点SBC出现故障需要备份的话，主从服务器之间需要非常紧密的配合才能实现媒体和信令的成功切换，否则极有可能出现大批用户突然失去连接的问题。

8. SBC未来的功能支持，这个内容对于笔者来说太大，笔者仅根据RFC5853的一些建议对此做一个简单总结。SBC在未来的设计中应该支持一个对SIP更加友好的拓扑隐藏方式，应该支持一个对SIP更加友好的媒体流量管理方式，应该支持一个对SIP更加友好的标准化重构方式。

    

 

SBC开源解决方案

 

Kamalio，OpenSIPs结合Asterisk或者FreeSWITCH是一种相对比较“经济”的SBC解决方案。关于使用以上开源解决方案实现SBC的功能，笔者在几年前也做过类似的探讨，这里不会再次做过多详细的介绍，网络上有很多类似的文档可以参考。但是，客观地说，如果通过以上类似的非常庞大的软交换平台开发成为一个SBC的话，它距离真正的生产环境和商业使用还有很长的距离，需要开发人员投入很大的精力去完善。这里，笔者有几个方面的建议用户可以考虑：

• 使用以上开源平台，是否有足够的人力去开发维护。

• 目前网络上看到的SBC解决方案仅实现了SBC的部分功能，大部分仅实现了拓扑隐藏，防攻击，NAT基本功能，如果严格地说，还不能算一个完整的SBC解决方案。另外，很多公开的开源的SBC设置文档也缺乏对底层的优化，如果需要真正部署在用户环境，仍然需要优化。

• Kamalio/OpenSIPs 可以实现媒体的处理，但是需要第三方媒体服务器参与才能支持一个比较完整的SBC功能。

• 编码转换需要开发人员进一步投入才能完成，目前，还没有真正的开源的媒体转换的功能能够支持大量的媒体转换，过多可能还是有赖于Asterisk或者FreeSWITCH实现媒体转换的功能。

• Asterisk或者FreeSWITCH平台的SIP和媒体耦合度太紧密，媒体和信令独立或分离的可能性不大，这样的话就可能导致SBC缺乏真正的可拓展性。当然，用户确实有非常强大的技术研发队伍也可以进一步优化。

• Kamailio/OpenSIPs对SIP RFC的兼容性支持相当强大灵活，但是需要非常高的技术要求。

• 个人觉得，目前比较可行的企业级SBC开源解决方案是Kamailio做信令服务器，FreeSWITCH作为一个媒体服务器，负责录音和编码转换。编码转换可以使用基于硬件的编码转换卡来获得编码能力的支持，并且编码处理能力也可以做分布式部署拓展发布。关于此开源解决方案具体的部署方式，用户可以访问Kamailio或FreeSWITCH官方网站获得详细配置文件。

• 
   

• 使用OpenSIPS作为SBC来使用，OpenSIPS本身支持B2BUA模块，也可以实现SBC的功能，而且结合编码转换卡可以实现编码转换的功能，但是仍然缺乏媒体服务器的支持，还是需要依赖第三方的媒体服务器实现媒体的控制。

  
   

 

在本章节中，我们简单回顾了以前章节的一些NAT解决方案的内容和存在的问题，然后介绍了SBC的产生背景，SBC的用户场景和SBC的主要功能，同时，我们也探讨了SBC在部署时需要用户注意到问题，还有目前SBC对SIP的影响，最后我们分别介绍了SBC的虚拟化可行性研究探讨和基于开源解决方案的简单论述。通过以上大篇幅的介绍，我们希望给用户一个比较完整的SBC解决方案的剖析，然后用户要根据自己的使用场景，部署成本，可维护性，拓展性做一个正确的评价。最后，因为个人能力有限和篇幅的局限，很多技术细节没有深入太多讨论，也可能出现很多错误，希望谅解指正。

 

 

参考资料：

https://tools.ietf.org/html/rfc5853

http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc

https://www.opensips.org/Documentation/Tutorials-SangomaVoiceTranscoding

https://www.nanog.org/meetings/nanog34/presentations/kaplan.pdf

https://datatracker.ietf.org/doc/rfc3924/

https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818

 

部署VoIP呼叫实现网络侦听对SBC性能影响：Implementation and Performance for Lawful Intercept of VoIP calls based on SIP Session Border Controller

×××××××××××××××××××××

来源   james.zhu asterisk