2016年4月21日-23日，QCon（全球软件开发大会）北京站正式开幕，云之讯作为受邀伙伴，和诸多国内外顶级软件研发大师及各路开发领域一线专家一起，分享技术创新与实践。云之讯CTO贾俊杰作为“移动开发与技术实践”专场嘉宾进行了题为“移动互联网时代融合通信关键技术与应用”的演讲，现奉上贾俊杰现场演讲实录，供未去现场的小伙伴们分享。
大家好！非常荣幸在这里跟大家做一个分享，今天跟大家分享的主题是移动互联网时代融合通信的关键技术和应用。首先自我介绍一下，我是来自云之讯的贾俊杰，之前一直在华为工作，主要从事融合通讯产品的架构设计、研究工作。过去十年甚至更长的一时间里，其实是通讯行业大发展的时代。我们经历了从非常传统的窄带的通讯，到后面的NGN、IMS很多代的变革。通讯带给我们的体验也是从最开始非常简单的通讯形式，到后来越来越复杂，越来越多样性的通讯体验。
随着互联网及移动互联网的发展，我们发现传统的通讯能力、体验却跟不上互联网发展的需要。在互联网应用，移动互联网应用的时候，你在获取一种传统的通讯能力的时候，难度是非常大的。无论是基础短信的业务，还是语音通话的业务难度是非常大的。我们就想怎么能够帮助这些互联网企业，非常容易的获得传统通讯的资源和能力呢？我们就做了云之讯。我们定位是想把传统的通讯功能，通过互联网技术的结合，再通过一些开放的标准化的接口或SDK方式开放给互联网企业，进行一些业务的融合，来提供这种通讯的服务。
所以，我们在做云之讯的过程中，其实也和合作伙伴构建了非常多样性的，非常有意思的融合通信的应用，所以今天也是想借这个机会，跟大家就融合通信的一些解决方案和应用，以及中间碰到的各种问题，我们怎么去解决的，跟大家做一个分享。
首先我们看一下融合通信的概念，融合通信RAS，很早就有这个概念了。在不同领域有着不同的解读。我们的理解，在移动互联网应用下的融合通信我们是这样看的，我们觉得融合通信的出现根本的助推器就是IP技术的发展。因为传统窄带通信是不可能存在融合的，因为传统窄带通信不管是带宽上还是从扩展性上是非常受限的，所以它只能提供最基础的消息，语音服务。随着IP技术的发展，我们知道在IP上面带宽是无限的，是很大的，它的扩展能力是非常强的，你可以基于IP通道做非常多的事情，所以IP技术的发展是整个融合通信的助推器。
在互联网和移动互联网发展的当前，我们怎么去解读这个融合通信的概念呢，我认为有三方面是融合通信非常重要的要素：
1.全能力的通信服务
我们现在很多互联网、移动互联网的应用，绝对不能再停留在原来这种短信、消息、基础语音通话上，我们更多互联网的应用是基于全能力的需求，包括消息类的。比如短信IM，包括语音类的，包括视频类的，甚至后续也有VR、AR这类的通信技术，我相信未来是全能力的通信服务。
2.跨网络的通信服务
跨网络有很多概念，之前说几网融合，其实讲的是我们的一个现状。我们存在传统的通信网，就是PSPN网络，技术通信网，以及现在的互联网，另外包含了很多企业的企业内部网。在这种不同的网络存在的情况下，不同的网络对于一些协议的设计，以及安全的要求，安全的策略上面其实都是不一样的。我们在做通信业务服务的时候跨网互通是非常重要，也是非常关键的，而且跨网互通是非常关键的要素。
3.场景化的通信服务
这个在融合通信里面讲也是非常重要的概念，这个怎么理解？我们现在很多业务都在讲场景化，通信也是一样的。大家之前应该也有很多体验，比如说假如你要租一个房，你可能要找一个网站，在网站上看到房源之后，看到联系人的号码，这时候你可能会抄一个电话，或者找到一个手机去拨号码，跟房源的联系人沟通。沟通完之后，如果有成交意向还要保存它的联系方式，后面再进行沟通，如果不合适你还要再去浏览网站，再去找其他房源。
为什么会这样？因为传统能力是单一的，而且是封闭的，所以通信跟你所需要的业务场景，以及业务流程所需要的关键因素都是分离的，隔离开的。所以你在进行你的服务的时候需要各种终端，进行来回的切换。但是场景化的通信能够非常好的解决这样的一个问题，你可以在看到一个联系人的时候一键点击就可以了，不需要再找他的电话，拨他的手机号码，后面我们也会有一个具体的分析和讲解。
融合通信主要是这三个核心要素构成的：就是全能力、跨网络、场景化。
刚才讲的融合通信的这些要素的前提下，不管是技术上还是产品设计上，都会有很多的挑战。这些挑战来自于我们刚才总结的那几点核心要素，比如说在通信能力融合方面，我们会看到用户是非常需要一致性体验的。如图所示：
下面我们举一个比较典型的融合通信的场景，结合这个场景展开一些问题和挑战，我们怎么去解决。这是什么场景呢？大家如果用过很多APP，尤其是电商、O2O的，就会发现电商里面其实存在着客服的概念，很多电商会嵌入客服电话，也就是传统的400电话。比如说你在购物的时候想反馈一些问题，拨打400电话是怎样的体验？点击400电话的时候，它会退出你系统拨号的界面，通过系统拨号盘把这个电话播出到电商呼叫中心里去。这是我们跟一个合作伙伴做的融合通信IP客服的解决方案，这种场景会有很多方式接入它的客服。当你在有流量的情况下可以通过IP方式呼叫到呼叫中心里，当然你也可以跳出到系统拨号盘，通过400方式呼叫到呼叫中心。
另外在WiFi形式下沟通的时候，你可以结合到购物的上下游，登录之后在系统里面可以直接通过IP方式，把你的订单号，以及你个人的信息资料传给后端，这时候你不需要再跟客服去沟通你订单的情况以及你的个人资料，效率是大大提升的。这种情景体现在两方面，一个是能力的融合，就是IP语音合坐席的沟通，以及文本、上下文的结合。另外再这种场景下，会有针对电商场景的深层次业务理解，包括对你集成包的大小，流量的业务，这都会有一些场景化的业务优化。
在这种融合通信的场景下怎么做通信的服务？就是我们融合通信PaaS的平台。这里面有几个关键点，一个是互联网QOS的保障，这是怎么保障的？这是我们通过底层构建了一个OTT的网络，后面我们会介绍，我们完全是为了解决移动互联网QOS没有保障的问题的。另外在接入层我们会考虑跨网络的综合接入，这个综合接入是什么概念？了解传统通信的同学知道，传统通信实际上有一些标准。传统通信一般都是用（英文）协议通信的，互联网通话的业务设计很少用（英文）协议，会采用一些高效的通信的协议，包括刚才融云介绍的一些协议进行互通。因为（英文）协议是基于传统通信网进行设计的协议标准，协议冗余度非常高，流程也非常复杂，所以完全不适合移动互联网高效通信的需要。所以我们在接入层会考虑高效率的综合接入，互联网侧我们也是用的自己私有的算法，非常高效的二进制的协议进行传输。
另外在核心业务上，我们本身要设计为一种多业务能力互通，多能力融合的。我们在整体架构核心点上会有一个多业务的路由中心，这个路由中心是支撑了互联网业务的路由，互联网业务的路由其实相对会灵活很多。因为我们协议的定义完全可以依赖于自己的一些协议进行定义，但是传统的通信网的业务分发和逻辑，其实很多是根据号码的概念，备叫号码的概念去做号码的识别和分析，进行业务路由的。我们做的其实是一个综合的路由方案，互联网和通信网是有差异的。
在这上面我们会提供非常灵活的，包括消息的服务，包括语音的服务，还有视频的服务。在这之上，我们会提供标准的接口，包括现在主流采用的（英文）一些接口，通过这种服务跟互联网的各种应用去结合。
另外一个核心的重点是解决跨网的问题，这个跨网问题为什么非常严重呢？也是基于根据我们讲的跨网的现状。通信网、企业网、互联网所采用的协议标准是不一样的，通信网我们主要是用的（英文）协议，（英文）协议互通性比较差，我们存在防火墙，存在net的情况下，比如说限制IP、端口、白名单、黑名单简单策略的时候是完全互通不了的，就会出现接不通，接通之后存在语言单通或者不通的问题。因为（英文）协议本身是设计为控制和媒体进行分开的，很多端口是通过控制协议去动态分配的，这个时候我们必须去动态的识别这种协议的负载，就是我们所说的ALG的方案。我们识别协议里面协商了哪些端口，在协商的过程中先把这个端口打开然后去识别，进行网络的穿越，后面是一个标准的结构图。在很多互通的情况下，我们会部署一些SBC的设备，刚才介绍的IP客服的解决方案也是一样的，会部署一些轻量级的SBC的设备，来解决刚才这种互通的问题。
另外一个核心的问题是通信过程中关键信息传输的可靠性保障上面，通信传输里面其实很关键的一个因素是号码，不管是在各种通话过程中会有号码的传递，这个号码是非常关键的。比如说我们按一个银行账号，一个密码的时候，如果号码错误会导致你整个流程失败。所以说号码传递的可靠性要求非常高。传统的号码传递的格式，比如说用TKMF的模式，或者2833的模式，它本身有一些抗丢包机制的。比如说2833，本身负载和截止位都会传多份，最多的时候传七份。
这种冗余的机制在通信网里丢了一两个包是完全没有问题的，信息传递是没有任何问题的，不会丢失。但是在互联网领域里面，这种冗余机制基本不适用，因为互联网不管是丢包率，以及抖动的情况要比通信网差很多。顺时丢包达到50%、70%都有可能，这时候做关键的信息传递的时候就会存在失败，就会导致非常恶性的错误。所以在互联网传输的过程中，我们会做一些优化和加强。优化的策略有两种，一种是基于内部的优化，因为我们会根据一些实说的标识，我们会判断这种起始位和负载位，我们没有截止位的时候也依然会保证这个号码不丢失。在这种情况下，我们能包括丢包率50%左右，这个号码都是准确的。
另外通过（英文）的方式进行传输，就是通过一些可靠性的传输机制，确认机制，来保证号码百分之百的可靠性，在SIPINFO协议里也有SIPINFO机制，以及有多次同传。
在接入中会面临一些问题，包体本身是非常小的单元，对于第三方SDK的接入指标要求的非常高。但是本身如果做通信的一些功能，会涉及到非常多的功能和组件，比如说我们做语音通信大家都知道，你需要SDK包里面涉及到语音数据的采集，编码前处理、后处理，再到解码协议的封装传输，这是必不可少的。所以适应场景化需要的时候要有多个挑战，我们的策略分为以下几点，我们讲的是SDK的极件化，包括几个方面。
一个包括SDK的包是最小化的。我们知道为了满足这种场景化的需要，只会保留IP、客服这样的场景IP通话功能，我们会把所有的视频编解码的信息，以及ICE穿透的能力都会简化掉。另外因为涉及不到一些互通的问题，所以我们只会保留一种编解码的格式。另外在接口上，正常的通信里面有很多通话状态，要接通，初始化，做振铃，有很多状态，但是这里不需要很多状态，只需要有接通状态。我们会在接层做集成化的管理，只需要提供一个非常简单的接口就完成跟用户沟通的场景。
在连接时间最短上面，也会做一些优化。正常的你即使用系统拨号盘拨电话的时候，一般接通时间都在5秒左右。但是我们通过去DIS的机制，我们会保证接通时间尽量优化，可以优化到3秒以内，这对用户的体验是非常好的。包括我们刚才讲的SDK的包大小，我们可以优化到800k以内。这是什么概念呢？通过对竞品的了解，大家会了解到，我们包含了编码、解码，以及音视频处理的要素在里面，一般的情况下是会增加2-3兆的水平，我们做了简化，能做到800k的水平，这是针对SDK场景化的优化措施上。
另外互联网通信一个非常关键的要素，是怎么保障QOS。我们的措施是建一张自己OTT的转发网络，这个转发网络怎么建呢？我们会采用一个分布式部署的策略，就会把所有的媒体转发分散在不同的节点上，每个节点贴近用户去部署。也就是说，我们在全国目前大概部署了80个节点的转发节点，来分布式部署它在不同区域里，不同用户之间的媒体数据。这些节点之间又会构建一些自己的路由策略，在转发的过程中会判断哪个网路径最优，会分骨干层、边缘层的节点。很多边缘层节点会通过中继层来转发，可以保障两个终端用户在通话的过程中，是动态的选择媒体转发策略，而我们设计的结果，专发的路径是采用通用的互联网，和我们自己建的综合路由进行可以动态切换的机制。两个用户在转发的过程中，我都可以通过我的网络选择最优的转发策略。
我们刚才讲了共网路由非常随机，而且路由策略有时候非常差，有是在跨网的情况下。另外一个保障机制是采用FEC机制，就是前项纠错的处理。我们知道你在通话、语音的过程中难免会出现丢包的情况，丢包就会导致你语音的质量下降。FEC机制就会把同一份语音数据或视频数据进行复制，在通话过程中会发多份，即使某一份丢掉，数据可以通过前后的补位来进行恢复。
另外还有一个策略是通过动态的策略调整，我们知道在通话过程中，整个影响通话质量的是视频的码率、帧率、分辨率的因素。你带宽占用越多的时候，就会导致你的数据更容易丢失，这时候我们会采用一个策略，就是我们所有的通话参数都会动态的进行调整。在开始的时候，会根据当前的网络判断去选择一个初始码率，这个码率不会太高也不会太低。在通话过程中会根据中间节点，以及被叫方接收端的丢包率，时延抖动参数发回来，再去动态调节分辨率的参数、复杂度的参数这些策略。通过这些策略我们能够保障在整个互联网通信平均丢包率达到30%的时候，他的通话效果是完全能接受的。
这是我们实际的测试数据，就是应用我们OTT网络和一些QOS的机制。上面是走共网以及OTT对比的结果，从这里可以看出来，在共网的时候高峰期丢包率是非常不稳定的，有时候丢包率非常高能达到10%多的水平。经过OTT多路由的转发可以抑制这种丢包率，基本可以降到5%以内。包括高峰期时延结果也是这样的，这是两个国内的机房对比数据。高峰期时延能达到80毫秒左右的情况，通过OTT的转发可以控制到40毫秒左右。对于FEC的效果也是非常明显的，下面的数据没有做FEC的策略，前面是丢包，中间是延迟，后面是抖动的情况。随着丢包率的增加，或者网络抖动的增加，会发现语音质量下降的非常快，但是增加了动态FEC机制之后，语音质量没有明显的下降，这是非常明显的。当然现在也在优化，因为FEC本身是有双面性的，他能够保证语音质量抗丢包，抗抖动，但是会增加传输的带宽，去增加流量，我们现在也在逐步的优化，就怎么在有效的保障语音质量的前提下，又要降低FEC带来的流量增加。
另外在安全机制上会有非常多的要求和体现，为什么呢？因为大家都知道传统的通信网，安全的要求非常高。而且我们讲的融合通信的很多场景，用户对通话信息的保障要求非常高。所以我们总结了一点，就是全方位的安全保障。我们会从用户信息的安全，以及传输内容的安全，以及系统的安全上面去做多层的保护。针对用户信息的保障，我们要保障用户不被骚扰，我们设计了动态黑名单的机制。在整个通话过程中，我们会根据主被叫通话的历史记录去识别，哪些用户可能会被骚扰，这时候我们会把主叫用户记录在黑名单。过一旦时间之后，如果骚扰解除了，我们会把用户从黑名单拉出来，是动态黑名单的机制，来保证实时用户防骚扰的机制。
另外我们还会针对通话号码做一些保障机制，通过一些呼转机制，针对一些场景把某些主被叫号码隐藏，跟O2O企业有一些案例。通信内容安全保障上我们也做了很多，基于消息类的开放了用户可自定义的消息加密机制。用户在传输之前就可以把你的消息按照自己的加密方式进行传输，即使整个过程经历了云平台的转发，你也可以保证这个信息完全不泄露。另外针对音视频也是一样的，我们也是开放了，在收端发端可以用自己加密的措施，来加密你的语音流、视频流，来保障整个传输的各个中都不会有外部的泄露风险。另外系统安全上我们会做一些智能分层的流控，会针对入口，跟跨网的互通上都会做流控机制。来保障系统的安全，另外也保障跨网不同网络的安全，这是安全的考虑。
刚才也讲了有这样一些关键的融合通信的问题，在解决的基础上我们还是想通过融合通信技术，来解决实际互联网应用面临的问题。下面我们会介绍几个典型的案例给大家，我们怎么通过融合通信的技术来解决互联网的应用的，下面是非常典型的一个场景。我不知道大家有没有用过滴滴，包括Uber，都推出了隐号通话的方案。现在在打车行业里，非常常见的一个问题，就是骚扰的问题。乘客不愿意泄露自己的手机号码，我们知道现在手机号码是严重被资产化的东西，泄露出去对个人的很多东西影响是非常大的。针对这个行业，针对这个场景我们推出了隐号通话的解决方案。
这是怎么实现的呢？主要是针对O2O的领域，我们会在订单的信息中生成一个中间号码，把订单交易双方关联到中间号码中去，在某一方寻找另一方的时候，你不需要知道他的实际手机号码，只需要拨打中间号码就可以，拨打时候平台会根据关联关系找到真实的号码进行转接，同样的道理针对被叫也是一样的，被叫在寻找另一方的时候，也是采用同样的方式可以找到另一方。在交易结束之后，整个的中间号码会被释放，这样就保证了在交易过程中临时的过程，保障交易双方的隐私。这本质是用通信技术加互联网信息绑定的关系，利用通信的转接技术来实现的。这个场景后面会更多的应用在金融、电商，后面会成为一个主流的应用。
另外我们在智慧社区里的一些融合通信应用，我们认为智能硬件是非常重要的沟通载体，现在大家主要都在用手机进行通话，未来随着物联网的发展，其实你通话不一定只依赖于手机，你可以在家里，在外面的很多场景下，一些智能硬件的设备进行沟通。所以智能硬件是一个沟通的重要在地，这个时候我们也是在文件对讲上，硬件上可以植入融合通信的SDK，去实现硬件与传统电话、固话、收集APP融合沟通，实现你一键开门，或者说远程对讲之类的功能，这是非常灵活的。后面也会针对于手表，很多智能硬件领域都会有类似的应用出来。
这是安全通信的场景，刚才也介绍到了，我们会开放端到端加密的机制，保障整个通话过程中对隐私不泄密的问题。
讲了这么多，我们想总结一下，融合通信与互联网的结合，它为什么有价值？它的竞争力在哪儿？我们写了一句话，开放平台等于融合，很多开放平台都是因为融合去做的，通信其实也不例外。我们把很多通信的能力跟非常多的移动应用结合，来提供一致性的用户体验，其实这是融合通信本质的竞争力，它能够解决之前说的，你的通信和业务场景隔离的问题。
一个根本的竞争力在于成本，IP通话成本非常低，传统通话成本非常高，之前案例的对比，发现成本上面能节省50%以上，这也是融合通信对互联网应用一个非常大的诱惑或竞争力的体现。我想这个不单针对IP客服的场景，针对于其他很多电商O2O的领域，其实具有同样的优势。
今天跟大家介绍这么多，这就是融合通信和互联网应用的结合，希望大家能关注融合通信，关注云之讯，谢谢。
演讲现场
图为演讲后，贾俊杰接受极客邦记者采访。
