6月29日，音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题，针对腾讯云音视频及融合通信产品的技术全面剖析，为大家带来纯干货的技术分享。下面是颜学伟老师关于实时音频与传统PSTN语音业务如何融合在一起，以及融合过程中的碰到的难点和解决方案的分享。
讲师介绍：颜学伟，腾讯云高级工程师，10年腾讯工作经验，先后负责过QQ空间后台开发、QQ音视频后台开发和QQ混音系统后台开发；目前主要负责腾讯云PSTN号码保护、云呼叫中心语音业务开发。
我今天讲的内容主要分为以下几个部分，首先简单地介绍一下实时音频和PSTN，说下它们为什么需要融合；第二，实时音视频是今年的热点，而PSTN是比较古老的技术，简单地说是手机和固话，这两者如何融合到一起；第三，融合之后上线使用会碰到一些问题，以及我们如何对这些问题进行优化。
实时音视频（RTC），从字面上理解就是实时的进行音频和视频的交流，最主要的特点是“实时”。目前实时一般划分可以分为三个档次，大于3秒以上称之为“伪实时”，1秒到3秒称为“准实时”，真正的实时是小于1秒以内。腾讯云上的实时音视频，实时语音可以做到300毫秒以下延迟。
我们常见的QQ和微信上的语音通话、视频通话，就是实时音视频的应用场景。实时用另一句话来解释就是低延迟，那为什么会产生延迟呢？我们先举例来说下语音通话的大概过程，以QQ为例。两个QQ用户通过外网发起语音通话，主叫方发起通话呼叫接听方，这个过程一般会分为两层来处理，一个是信令层的处理，另一个是码流层的处理。
信令层主要用于通话的建立、连接、资源的准备，并协商码流编解码类型等相关信息，码流层专注于音视频数据处理。下面主要以音频来说明，要进行实时语音通话，则要进行音频数据的采集、预处理、编码、解码、播放等步骤。由于双方都是在Internet上进行通话，需要将主叫的声音传输到被叫方，即是将采集到的语音数据传输到接收端。接收端收到音频流数据后，会进行解码，之后是播放器进行播放。这里面有很关键的一点，就是我们的通话是建立在Internet之上，这种语音通话也称之为VOIP，是需要依赖网络传输的，所以就会产生延迟。从主叫说话的第一个字开始到被加听到的那个字之间会经过一定距离的物理传输，这就产生了延时。
而实时音视频要做到比较低的延时，我们在传输协议上直接选择UDP，因为UDP虽然不可靠，但是它的性能比较高，相对于TCP少了三次握手和四次挥手。
因为外网的环境时好时坏，UDP又是不可靠的，在Internet传输音视频数据时容易产生抖动，所以我们需要一个抗抖动的能力。当网络质量不好产生丢包时，我们也需要一个抗丢包的能力。而且外网的质量波动比较大，也需要一种自适应的方式来动态调节发送的码流，称之为流控，就是随时检测主被叫双方接收的包量，来计算丢包率、延时和码率，用于来控制发送端的采样率和发送的码率，当时网络质量不好时，我们可以把发送端的采样率和码率降低，减少发送的整体包量，进而减小网络的拥堵。网络质量好时，我们可以提高发送端的采样率和码率，增加发送的整体包量，会让接收端有较好的语音质量。
既然说的是音视频处理（这里重点说的是音频），必须会涉及到语音的增强处理。语音进行采集后，会进行一些预处理。比如说主叫端在说话的时候离麦克风比较远，造成采集的音量比较小，这样接收端听到声音就会小。但是我们做下AGC处理后，可以把音量适当的调大，让接收端听到正常的声音。还有回声消除AEC用于消除听到回声情况，当噪声比较大时，我们通过ANC把噪声降下来，让人说话的声音突出，可以在接收端清晰听见说话内容。
腾讯的实时音视频在云官网上线比较早，云官网上面实时音视频和QQ音视频的内核是一样的，只不过在云官网上是去掉了QQ音视频的一些特殊业务逻辑，然后把核心的编码、解码和语音优化的能力抽取出来，做成的实时音视频的SDK。
下面来说一下PSTN，从字面意思来看就是公共交换电话网，这是一种比较老的技术。为什么说它老呢？因为第一部电话发明是由美国贝尔1876年发明的，距离今天有143的历史了。虽然历史比较古老，但电话现在还是我们使用和应用场景比较广泛的一种实时的语音通话方式。大家有一些重要的事情基本上都优先打电话，而且打电话在手机端各种操作系统里面，优先级是最高的，属于一种强提醒方式。
（见PPT）这是座机，通过电话线和PBX相联（程控交换机）然后通过物理线路，连到运营商公共专用网络，进行语音流、信令流的传输，再传输到被叫用户最近的PBX，通过电话线呼起被叫。被加的手机就响铃了，被叫一接听，手机的麦克风会采集对应的人声，通过相同的交换机传回来，这样主被叫双方就可以进行实时通话。
PSTN都采用专线专网，它的缺点就是网络利用率比较低。两个电话用户同时进行通话会独占一路物理线路，这路物理线路在那一刻就只供主被叫双方使用用，不像英特网一样都是多种通话共享占用。
随着技术的发展，PSTN也出现了一种新的方式，在PSTN网络可以使用SIP_TRUNK的方式，把里面的信令流和数据流传到Internet上。处理信令的方式是采用标准的SIP协议，码流采用标准的RTP协议来传输。
下面再来说下为什么实时音视频要和PSTN结合？比如在QQ讨论组里多个人想一起进行语音通话，但是他邀请的其中一个用户可能是QQ离线，如果是离线，那这个人就无法无法加入了。这时候可不可以通过打电话的方式接进来呢？多人会议也类似，这个场景是一般都比较紧急，大家希望可以直接打电话就可以把他接入到会议中，直接进行语音讨论。还有就是一个智能门禁场景，目前智能门禁系统，简单地来说类似一个IPAD，里面是安卓的操作系统，里面安装了一个类似于QQ或者是实时音视频的APP，可以让拜访者跟业主进行交流。这种APP一般在业主的手机上是经常不会长期启动，不会像QQ和微信一样长期处于在线状态。当这个APP离线的时候，访客拜访业主，通过APP就会找不到业主了，此时如果可以通过门禁直接打电话，业主和拜访者互相进行语音通话交流，随后业主也通过电话的方式把门禁打开。还有在各种网站上的客服电话，直接在网页上点击一下就可以打电话给客服人员，并进行语音交流。要实现上面各种业务场景需求，就需要将实时音视频VOIP和传统的PSTN融合起来。
那怎么样融合呢？首先我们要看一下两者的差异。实时音视频我主要以QQ语音通话为例，刚才也说过一个完整的音视频处理是要分很多步的，音频采集、预处理、编码、网络传输、解码和播放。网络传输协议上，QQ语音通话是使用自己的私有协议，而PSTN使用的是标准的SIP RTP协议，这是语音运营商采用的标准协议。
QQ支持的编码有很多，有SILK、AAC、OPUS等，但对于PSTN，使用SIP_TRUNK方式对接的语音编码，目前三大运营商，电信、联通和移动，仅支持G711A、G711U、G729等编码。
RTC采样率都是16K、48K，PSTN一般为8K。
组包间隔，语音数据包发送的时候需要以一定的时间间隔来周期进行发送，比如说像QQ支持20毫秒、40毫秒、60毫秒的间隔发送，PSTN基本上是20毫秒。
语音质量，对于VOIP会有很多相应的语音的优化手段，但是PSTN是专用网络，网络质量相对高，丢包较少，优化的手段也比较少。
RTC除了1对1绝大多数场景是支持多人，比如说纯视频、纯语音通话可以支持客户端混音和服务端混音，但是手机端基本上是1V1。多人会议是多个人，但是手机端是不支持同时接收多路码进行混音的，必须要混好成一路后，才能下发给手机。显然这是两者之间的差异。
有这么多的差异，我们有没有方法把两者结合起来呢？我们就要找一个突破口——求同存异，适配融合。
刚才说的是差异的地方，有没有相同的地方呢？PSTN经过长时间的发展，可以把PSTN专用网络的信令流和数据流通过SIP_TRUNK的方式在Internet上面传输，这就是一个相同的地方。这个地方存在的突破口，存在可以融合的点。剩下对其它不同的部分进行融合适配，即对音频码流和信令协议进行适配。
我们融合的方式的实现有两种，第一种是让QQ客户端去适配PSTN的差异，第二种是让PSTN去适配VOIP的差异。首先PSTN是国际通用的标准，让它适应VOIP众多的编码和私有协议，那么现在的手机设备肯定要更新升级，这显然不大现实。另外一种就是让QQ去适应PSTN的差异。QQ同样有历史包袱，他发展了那么多年，如果支持RTP和SIP改动也很大，开发周期也是非常漫长的。即然这两种方法都不行，我们就想到新增一个中间模块去分别适配VOIP和PSTN的差异。这个模块我们称之为适配层，可以放到Internet上，让VOIP和PSTN协议互转和码流互转。适配层有两个主要功能，一个是对信令的适配，还有一个是对码流的适配。
最终系统架构图
最上面一部分是实时音视频对外提供的OpenSdk，它跟QQ的音视频内核是一样的，只是去掉了QQ那些特殊的业务逻辑，它目前支持安卓、IOS、windows、web SDK，基本上是全终端。客户端信令发向后台互动直播系统，首先经过信令处理模块App，进行机器调度分配要经过Info，由于我们整个过程都是要动态自适应调整，会有一个流控模块。然后这个信令会转到一个信令适配模块，我们叫会控。而码流的适配、编码的转换，有一个模块就是混音。因为手机端不具备多路混音的能力，所以我们必须在服务端进行混音，这样将多人的码流混成一路发给手机端，手机端就能听到多个人的声音了。
下面那部分进入PSTN网络，会控把QQ私有协议转换成内部私有协议，通过PSTN策略进行一系列的分配策略，再通过处理信令的sip_server将内部私有协议转换成标准的SIP协议和运营商的SIP_SERVER相通，同理将对应的码流通过混音和proxy转成标准rtp码和运营商媒体Svr相通。
重点说一下混音，从QQ的私有协议转到标准的RTP协议还算比较容易，但编码转换就要复杂很多。因为手机端不具备混音的能力，所以我们这部分不像VOIP客户端可以客户端混音，手机端必须要在服务端混好才能下发一路码流给手机端。我们是采用服务端混音，如有多个VOIP进行互相通话的时候会同时发多路音频流，由外网传输到混音后台，首先会选路操作。选路是指在多个说话的人里面最多选几路语音流来进行混音操作，比如说QQ语音通话最多选六路。主要原因，第一个是说话的人多了大家听不清楚，第二人就是选择的语音流路数越多越消耗服务器资源，这样一台服务器就支持不了多少人了。选路之后，就要进行解码，解码完再进行重采样，然后再进行混音，之后就要编码，然后再通过Proxy进行传输最后会传输到运营商的媒体SVR，最后到运营商网络，就可以下发到手机端，这样就实现了手机端也可听到多路语音的功能。
因为是语音通话，所以系统上线之后，在语音上面增强必不可少。手机端的语音增强手段比较有限，因为它在运营商的公共网络相对外网质量比较好，少抖动和少丢包。在VOIP端由于直接是外网，所以要做的语音质量优化比较多。比如说语音采样之后，会进行回音消除和降噪。为了避免抖动会引入jitterbuffer，jitterbuffer有一定缓存包它有一定大小，如果在缓存范围外的丢包，则要通过PLC进行补包。还有为了节省带宽我们会做VAD，如果VOIP端长期不说话的时候，我们可以不发完整的静音包，可以会发特殊的EOS包。网络质量是随时动态变化的，所以我们要进行自适应调节，以2秒为一个单位来，实时统计一下当前网络的超时率、丢包、抖动情况，综合调节客户端的采样率和码率。
因为是实时音视频，所以低延时是重中之重。在外网传输，延时大部分引入有很多是在媒体SVR的分配上面。如在不同运营商的延时会有10到25毫秒延时，而且不同的运营商某些城市可能会有丢包，不同的机房网络延迟差不多是20到35毫秒，如果直接外网，易抖动、质量不稳定。对于这些问题，我们可能通过调度分配来解决，我们尽量将媒体SVR分配到同一运营商，尽量分配到同机房。对于有条件的地方可以直接专线相连接。
抗网络丢包有两种方法，第一种是ARQ自动重传。我们每一个媒体节点都是采用UDP来传输且每一个媒体节点都会缓存一定数量的音频包，每个音频包里面会有一个序号，接收客户端收包时会根据包中的序列号判断是否是连续的，如果不是则有丢包，此时会去它的前一个媒体节点问一下，缓存中有没有这个包，有的话就直接重发一次，没有的话，它就再向前一个节点问一下，如果所有中间节点都没有就会一直问到发送端，发送端再把这个包再传一次。ARQ明显缺点是增加延迟。
第二种是FEC，发送端在发音频包的时候，可以多发几个冗余包。接收到如果发现音频包丢了，而冗余包没有丢，则会尝试使用冗余包把音频包恢复。增加FEC也是动态的，当网络质量不好会多加一些冗余包，反之则会少加一些。
最后一个是提高系统可用性。只要是大规模的应用或系统，这是必不可少的要解决的问题，解决这个问题简单来说就两个方面，第一个是增加冗余资源，第二是实现自动切换。机器冗余可以多运营商部署、多机房部署，多地部署，自动切换则是死机时可以自动切换、IDC异常时可以自动屏蔽出问题的IDC、自动屏蔽出问题的资源等方式。
好了，我今天的分享就到这些，谢谢。
Q：您好，首先非常感谢您的精彩发言，我有个问题咨询一下，咱们跟运营商打通会不会有门槛？
A：主要是SIP协议和RIP协议联调开发，运营商是管理的是所有的码号。运营商需要一定的资质，比如说SP的资质、公司规模、以及有没有经营呼叫中心等电信增值许可证等。
Q：如果在车上或者船上的话网络环境会更恶劣，如果要进行多人会议，咱们这边有没有更好的解决方法？
A：我们主要以软件方式实现多人会议，比较重度依赖于网络，如果网络质量比较差的话，我们目前暂时没有太好的办法。
