学习SBC在携程中应用的实践与技巧

        随着互联网及融合通信（Unified Communication）技术的不断发展，使得VoIP技术 近几年又火了起来。VoIP就是Voice Over Internet Protocol，简单来说就是只要你有质量不错的网络条件，就可以和外界进行语音通信了。只不过传统的语音通信都是通过模拟线路来进行信号传输的，而VoIP则是通过因特网借助IP包来传输数字语音信号。

SBC的全称是Session Border Controller。简单来说，SBC是部署在网络边界，用来控制SIP会话的设备或软件。Session 为会话，Border 为通信网络边界，Controller 为控制器。

目前在市面上，商用的SBC厂家非常的多，例如国产品牌鼎信通达、华为、讯时、三汇等品牌；国外知名品牌Oracle Acme 、Sonus、AudioCodes等品牌。大多品牌是专用的硬件物理设备；由于市场的需求，也有一些厂家推出了软件的SBC，例如通信行业新兴起的神州网讯品牌，但是一般语音编解码的板卡还是用DSP来实现的。

总的来说，SBC没有太确切的定义，但就RFC的一些描述和个人的理解，SBC应该就是基于SIP的B2BUA（背靠背代理），能够解析SIP协议，并对SIP协议进行各种操作，比如添加SIP Header，修改SDP等等。

SBC一般部署在语音网络边界，用于控制SIP信令，通常也包含了语音流的建立，控制与释放，因为部署在边界，就设计到两边SIP业务参数的不同，所以适配的功能也是必不可少的。

在VoIP网络安全方面，SBC也起到语音会话层面的安全，QoS，准入控制等作用。更为简单的说，SBC就像是VoIP的防火墙，提供了IP语音网络的接入服务。

其实简单来讲，SBC的核心功能可以概括为：

1） 协议转换；

2） codec编码转换；

3） 信令及媒体的NAT;

4） 内部通信网络拓扑隐藏；

5） 权限及安全控制

1） 企业之间的SIP组网，比如公司之间，或者总公司和分公司之间可以通过专线或者Internet进行IP语音系统对接；

2） SIP客户端接入，比如软件的SIP client通过公网，由SBC充当代理接入到IP语音网络中；

3） 运营商IMS对接，可以与SIP trunk开放的运营商进行语音中继接入的实现。

目前在IP通信电话系统中，无论是中继线路，移动办公，企业组网等都进行了大量的VoIP实践。在实践过程中，需要SBC设备的接入；由于是互联网公司，那通信应用也要朝着互联网发展方向，我们决定选择开源+软交换的方法来满足自身对SBC的需求，同时进行了向成熟产品方向的改造。

去朝着这个方向走，其实也是通过了解，认为SBC虚拟化，软件化是可行的。Linux OS的架构以及CPU的不断强劲，虚拟机包括docker等技术的不断成熟，都使的软件的SBC可以有不错的性能。

首先介绍下软SBC的整体架构，下图从类ISO的分层模型来展示我们SBC功能模块，以及管理界面：

通过技术选型，我们采用了OpenSIPS+RTPProxy组合的方式来实现APP端软电话的接入，我们称之为VAG。OpenSIPS是一个已经非常成熟的开源SIP服务器，它不仅仅可以当作SIP代理，同时它包含了一些应用层的功能，比如我们上文提到的SIP背靠背代理功能。通过OpenSIPS，我们可以轻松的实现SBC需要的SIP协议转换，NAT功能，拓扑隐藏等等。

3.1.1 实现操作过程：

1）通过OpenSIPS实现了SIP client 注册消息的转发，将client的注册消息转发至后端办公电话系统上，实现client在服务端的注册与鉴权；

2）client发起呼叫时，invite消息将发向VAG，VAG中OpenSIPS将invite消息转发到后端办公电话系统，可以高效处理transaction以及dialog；

3）Invite relay的时候VAG实现SIP消息公网与私网的NAT，NAT不止是IP包地址的转换，还包括SIP应用层NAT穿越；

4）信令建立好后，根据SDP中协商的媒体地址，SIP客户端通过VAG与办公电话系统建立RTP的传输，此处也包含了RTP流的NAT穿越；

5）会话结束后，VAG通过relay BYE消息，结束双发的会话。

3.1.2 遇到常见问题

1）在会话过程中需要注意SIP信令的NAT穿越问题，否则会出现32s自动拆线，挂不断等问题。踩过的坑就是client发来的200OK地址要修改为其公网地址等；在openSIPs中需要将其公网地址及对应的端口配置在配置文件中：

advertised_address = "x.x.x.x"

advertised_port=5060

2）很多情况下电话拨打都可以振铃、接通，但是没有声音；这时候就出现了RTP NAT的问题，根因就是client或者服务端双方的RTP流都发到了错误的地址，基本都是发到了对端的一个内网地址上，那这样是肯定没声音的。所以要注意在会话建立阶段，双方SDP协商中提供的其可用的media地址，RTP流地址传输对了，那自然就可以正常通话了；

3）大家可能注意到VAG实现了三家运营商网络的接入，也是为了不通运营商的手机用户可以使用本运营商的网络接入，提高接入速度及质量。此处的实现可以通过交换机网络接入，VAG多网卡或者虚拟网卡来实现，需要对应做好SIP及RTP NAT处理。

公司内部的分公司或者子公司之间需要实现语音网络的打通，提高沟通效率或者通话费用的节省；如果通过PSTN方式的话，成本高，也很难实现内部的统一通信。

如果企业内部各物理节点或者独立语音系统，通过网络实现内部的SIP组网，IP语音网络打通，那上述的需求就完美解决了。

在实践过程中，我们总公司和分公司之间就是通过VIG来实现双方语音网络互通的。这里我们使用了FreeSWITCH来作为VIG技术选型。VIG大致架构如上图所示。

3.2.1 实现操作过程：

1）双方在自身语音网络边界部署VIG，VIG则和各自内部通信交换核心组建SIP trunk；

2）通信时，SIP请求通过双方VIG组建的SIP trunk进行通信，VIG作为中间人同时处理SIP消息中的随路数据及双方语音编解码的适配与转换；

3）双方在对接时，可以起到自身网络拓扑的隐藏；一方面隔离了双方原有的通信网络，安全性提高了，另一方面做到双方应用对彼此透明，一切通信都是通过VIG来进行。

3.2.2 遇到常见问题

1）如果双方通过网络专线打通内网网络，那其实VIG就不必考虑太多的NAT问题，因为一切通信都是通过内网地址来进行的。

2）双方通过VIG实现通信网络组网后，会遇到SIP协议适配，号段冲突等各层次的问题，那就需要VIG进行双方固有语音网络设备协议适配，比如一些商用硬件PBX，IVR系统，话机等。

3）双方本是独立的语音系统，打通后势必会碰到号段冲突的问题，此时在VIG上实现一些号段的映射转换等，我这边是通过添加插码来识别，然后通话删除插码来进行内部路由的。

语音中继线路，之前都是通过传统中继线路+网关的方式来对内提供服务的。但随着运营商SIP中继技术的不断成熟及不断的开放；通过SBC实现SIP中继的接入是未来的发展方向。在VTG实践中，我们使用了FreeSWITCH作为VTG的技术基底。VTG大致架构如下：

3.3.1实现操作过程：

1）自身部署VTG，运营商SIP中继通过专线的方式对接VTG服务器，此时VTG服务器需要两个外卡来实现对外与运营商SBC对接，对内与内部电话系统对接。

2）如果运营商提供的是公网IP，那还需要通过VTG解决SIP及RTP NAT问题。解决的办法可以通过，建立两个UA，一个对内，一个对外，然后在VTG内部将两个UA对接起来。

3.3.2 遇到常见问题：

1）对接中继线路，VTG需能承受大量话务并发，故需对其进行高并发的压力测试；我们使用的是SIPp来模拟定量的caps及并发呼叫，测试信令流程如下：

具体的测试数据，与自身服务器配置及网络环境有一定关系，这里也就不分享了，但是测试结果是满足我们的需求的；

2）在高可用方面，我们采用的是虚拟IP漂移应用主备的方式；在keepalived和heartbeat两款软件方面都有过使用经验，个人比较推荐keepalived , 使用及配置起来更为方便。加入脚本后，如果检测到主机应用宕机，可以在1s内将虚拟IP切换到备机上，备机继续提供服务。这里有个坑就是，在配置keepalived过程中，如果出现虚拟IP无法切换或者脑裂问题时，可以通过抓取日志消息对比，再看看服务器所处网络环境的通讯模式，大多就可以解决问题了。

3） 在对接测试的过程中，也出现过DTMF失效的情况，各种抓包分析排查下来，发现运营商的SBC用的是inband的模式，我们这边也是适配了inband，但是还是不行，最后才发现inband模式只在G711编码的模式生效，其他有过压缩的编码方式确实会导致DTMF传输出现问题。

        上面就是SBC的几个典型的应用场景。当基本功能都具备后，就考虑向一个产品去优化。软件SBC不仅支持私有云，同时也支持公有云的部署；支持SBC系统性能与业务层的监控告警；支持数据实时落库，也提供标准的数据接口。目的就是让我们的软件SBC可以成为一个专业的软件SBC解决方案。在接下来的5的通信中，随着IMS网络对于企业的接入全面开放，在NAT、安全防护、信令校正等流媒体的通信中，SBC将会扮演这越来越重要的桥接跨域通信。