5）利用开源软交换来开发SBC
利用开源平台开发SBC图例
目前市场上主流的SBC 设备厂家相对来说技术实力比较强，同时对底层设备架构性能有充分的了解。硬件设备相对稳定一些。但是目前很多开源的软交换也具备SBC的某些功能，例如openSIPS， kamailio 或者FreeSWICTH。这些平台本身具有注册，路由，NAT处理的能力，但是首先这些软交换平台基本都不具有编码转换处理的能力，本身没有对编码的处理，只能对SIP消息做规范化处理，其次，几个平台对接的技术难度很高，维护成本高，所以只能部分实现SBC功能。如果需要对编码转换进行处理的话，必须借助第三方DSP处理或者软转码，目前类似的算法基本上都需要通过购买商业许可证来实现。所以严格意义上这样的架构并不是SBC的标准设备。
6）SBC 部署类型 目前SBC部署支持两种形式：
6.1）设备类型。设备类型支持企业级和运营商级的部署，从400路到2000路以上，或者更高级别的处理。
SBC 在企业语音业务中的应用拓扑图
6.2）VMware 平台安装部署eSBC。这样的方式适合于中小型企业的IPPBX对接，SIP中继对接或者企业融合通信的管理。SBC 是以软件形式安装在企业内部的虚拟机上，可以根据不同配置来支持编码转换，另外一个软编码的局限性在于支持的编码类型非常有限，而且市场上编码类型又不断丰富。编码转换的处理包括软件形式的，很多厂家都有自己的算法，但是并发数量和虚拟机的性能有严格的要求，同时支持的编码类型非常有限。Sangoma 的eSBC 则通过外置的编码DSP设备处理，通过IP对接，来对RTP流进行处理。这样保证了处理能力，可以根据企业用户的增加适当拓展并发数量，调整编码转换设备的容量。用户通过ESBC 对接基于云的IPPBX，例如可以部署IPPBX在阿里云，亚马逊云，百度云，然后在本地进行编码处理。
SBC 在AWS云平台部署图例
7）SBC 在VoIP环境中主要面对的挑战
VoIP的技术日新月异，笔者不敢轻易断定网络会有什么不可预知的问题。当然，以目前的技术水平和网络环境来看，无论是什么样的设备，什么样的功能，面对的一个主要问题就是网络的稳定性问题，用户网络环境复杂等等问题。这些问题通常是厂家不可预知的问题。这些也都是VoIP环境一直面对的难题。比较好的解决办法就是设备端必须支持完善的排查工具，包括QOS，SIP消息，语音抓包等等工具，用户可以轻松检查出问题所在，能够快速解决问题，或者反馈问题。
总结，从我们介绍的以上内容中我们不难看出，SBC设备是目前VoIP网络环境中最为可靠的解决方案，具有对SIP完整的支持，同时解决了安全问题。一句话，SBC 就是为SIP所生！
参考资料：
1）http://wiki.sangoma.com/NetBorder-Session-Controller
2）http://www.dummies.com/
3）http://en.wikipedia.org/wiki/Session_border_controller
4）http://en.wikipedia.org/wiki/Back-to-back_user_agent
5）http://blogs.trilogy-lte.com/post/77427158750/how-webrtc-is-revolutionizing-telephony
6）http://www.frafos.com/wp-content/uploads/2012/10/FRAFOS_Underdstanding_SBC.pdf
