干货 | 携程软件SBC实践

作者简介

韩海龙,携程通信技术中心工程师,负责VoIP,软交换相关领域技术研究与开发,及携程呼叫中心语音中继接入工作。

一、SBC简介

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

在VoIP网络架构中,不同于传统的语音交换机、网关等语音设备,SBC在VoIP通信中应用广泛,作用十分重要。SBC的全称是Session Border Controller。简单来说,SBC是部署在网络边界,用来控制SIP会话的设备或软件。Session 为会话,Border 为通信网络边界,Controller 为控制器。

目前在市面上,商用的SBC厂家非常的多,大多是专用的硬件物理设备;由于市场的需求,也有一些厂家推出了软件的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) 权限及安全控制

二、SBC应用场景

就使用场景来讲,个人认为大概分为3个场景:

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实践经验

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

下面根据不同场景,来介绍下我们的一些实践经验及踩过的坑。

1、移动软电话VAG(VoIP accessing gateway)

携程有一个服务于全公司的办公APP,有需求将VoIP软电话的功能也嵌入到APP里,方便公司同事可以在wifi或者4G网络环境下联系同事或者进行电话会议。在此场景下,就需要实现移动APP端client通过SBC接入到携程内部电话网络中,并打通语音网络,实现APP拨打内部办公电话和拨打PSTN电话的功能。

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

VAG大致的架构如下:

实现过程:

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消息,结束双发的会话。

常见问题:

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处理。

2、内部分公司组网VIG(VoIP interconnect gateway)

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

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

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

实现过程:

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

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

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

常见问题:

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

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

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

3、携程SIP语音中继接入(VoIP trunking gateway)

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

实现过程:

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

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

常见问题:

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解决方案。

总结一下,以上向大家介绍了我们在开源软件SBC的实践经验,有坑,但是更多的是对VoIP、SBC技术的深入了解,希望对大家有所帮助。

其实在未来的5G或者IMS网络中,SBC会扮演这越来越重要的角色,希望大家可以相互学习,相互分享,一起提高。

原文发布于微信公众号 - 携程技术中心(ctriptech)

原文发表时间:2018-01-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

解决方案提供商关注的5大顶级IoT网关

物联网网关 尽管有了数据分析工具,云计算和连接的设备仍然是构成物联网产品的关键,但网关也至关重要。 ? 网关具备设备连通性、协议转换、数据过滤和处理以及安全性等...

30230
来自专栏SAP梦心的SAP分享

【域控管理】域控的必要性

题记:本来域控这玩意儿跟我没有半毛钱关系,毕竟我是做应用类的,域控纯属系统管理范畴。 以前在TTE和LDS,公司里有使用域控,几年来以使用者的角度在观察,觉得这...

27450
来自专栏Crossin的编程教室

个人开发者如何申请微信小程序

作为一个间接性拖延症患者,直到昨天微信小程序疯转之后,我才想起来去做个 demo 试试。 把之前的 python 网页编辑器(公众号最右菜单栏->在线编程)移植...

55260
来自专栏SDNLAB

Neutron结合SDN的架构分析

编者按:来自武神的最新力作,Neutron 是 OpenStack 核心项目之一,提供云计算环境下的虚拟网络功能,本文将SDN与Neutron结合起来进行架构分...

33750
来自专栏SDNLAB

2015 ETSI NFV用例指南

TSI NFV ISG已经确定了9个潜在的NFV用例。本章节简单介绍了这些用例,完整的用例描述请参见ETSI网站. NFV基础设施即服务(NFVIaaS) NF...

34070
来自专栏喔家ArchiSelf

来吧,一个IoT应用设计

大量的研究表明,智能家居和可穿戴设备是目前最流行的物联网应用。嵌入式的MCU是这些物联网应用程序的核心。 然而,为了在这个快速而有竞争力的市场上成为一个有效的基...

18520
来自专栏FreeBuf

神器分享:物联网黑客工具包

今天,我将在BSides San Francisco做一个题为“物联网黑客工具包”的演讲。我会准备一个幻灯片并且发布一篇博客去参加这个演讲,如果有我演讲的视频链...

21600
来自专栏沈唁志

说一说平时遇到技术问题时的解决方法以及如何有效提问

51930
来自专栏老九学堂

为什么程序员总是发现不了自己的Bug?

程序员在普通人的印象里是一份严(ku)谨(bi)的职业,也是一个被搞怪吐槽乐此不疲的职业,程序员们面对复杂的代码敲打电脑时连眉头都不会皱一下,但是有一个词却是他...

9120
来自专栏SDNLAB

Neutron结合SDN的架构分析

OpenStack开源社区为云计算提供了最大平台,有多个组件分别实现计算(Nova)、存储(Cinder/Swift)、监控(Ceilometer)和网络(Ne...

35340

扫码关注云+社区

领取腾讯云代金券