技术解码丨实时音视频与PSTN融合的解决方案

一、背景

01

什么是实时音视频（RTC）

实时音视频（Real-Time Communication，简称RTC），从字面上理解就是实时的进行音频和视频的交流，最主要的特点就是“实时”。这里的实时性可以分为三个档次：

腾讯云实时音视频 TRTC 延时已经可以做到300ms以下，我们常见的QQ和腾讯会议上的语音通话、视频通话，都是实时音视频的应用场景。

首先，我们来了解下为什么会产生延时。以QQ为例，两个QQ用户通过外网发起语音通话，主叫方语音呼叫接听方，这个过程一般会分为两层来处理。一个是信令层的处理，另一个是码流层的处理。信令层主要用于通话的建立、连接、资源的准备，并协商码流编解码类型等相关信息，码流层专注于音视频数据处理。这里主要以音频来说明，要进行实时语音通话，则要进行音频数据的采集、预处理、编码、网络传输、解码、播放等步骤。由于双方都是在Internet上进行通话，需要将主叫的声音传输到被叫方，即是将采集到的语音数据传输到接收端。接收端收到音频流数据后，会进行解码，之后是播放器进行播放。这里面有很关键的一点，就是我们的通话是建立在Internet之上，这种语音通话也称之为VOIP，是需要依赖网络传输的，所以就会产生延时。从主叫说话的第一个字开始到被加听到的那个字之间会经过一定距离的物理传输，这就产生了延时。

那么如何才能做到低延时呢？我们在传输协议上直接选择来UDP。UDP虽然不可靠，但是它的传输效率比较高，相对于TCP少了三次握手和四次挥手。因为外网的环境时好时坏，UDP又是不可靠的，在Internet传输音视频数据时容易产生抖动，所以我们需要一个抗抖动的能力。当网络质量不好产生丢包时，我们也需要一个抗丢包的能力。外网的质量波动比较大，也需要一种自适应的方式来动态调节发送的码流，称之为流控，可以按一定的周期来检测主被叫双方接收的包量，来计算丢包率、延时和码率等，用于来控制发送端的采样率、发送的码率和组包间隔；当时网络质量不好时，我们可以把发送端的采样率和码率降低，减少发送的整体包量，进而减小网络的拥堵。网络质量好时，我们可以提高发送端的采样率和码率，增加发送的整体包量，会让接收端有较好的语音质量。

音视频处理（这里要重点说的是音频），必然会涉及到语音的增强处理。语音进行采集后，会进行一些预处理。比如说主叫端在说话的时候离麦克风比较远，造成采集的音量比较小，这样接收端听到声音就会小。但是经过AGC处理后，可以把音量适当的调大，让接收端听到正常的声音。还有回声消除AEC用于消除听到回声情况，当噪声比较大时，通过ANC把噪声降下来，让人说话的声音突出，可以在接收端清晰听见说话内容。下图是常用的提高语音质量需要考虑的方面。

02

什么是PSTN

PSTN，从字面意思来看就是公共交换电话网，是一种比较老的技术。虽然历史较久，但电话现在依然是我们使用和应用场景最广泛的一种实时语音通话方式。通常有着急的事情大家都会优先选择电话的方式来沟通。座机或手机通过电话线和PBX相联（程控交换机）然后通过物理线路，连到运营商公共专用网络，进行语音流、信令流的传输，再传输到被叫用户最近的PBX，通过电话线呼起被叫。被叫的手机响铃，被叫就可以选择接听，手机的麦克风会采集对应的人声，通过相同的交换机传回来，这样主被叫双方就可以进行实时通话。

PSTN一般都采用专线专网，它的缺点就是网络利用率比较低。两个电话用户同时进行通话会独占一路物理线路，这路物理线路在那一刻就只供主被叫双方使用，不像英特网一样都是多种通话共享占用。随着技术的发展，PSTN也出现了一种新的方式，在PSTN网络可以使用SIP_TRUNK的方式，把里面的信令流和数据流传到Internet上。处理信令的方式是采用标准的SIP协议，码流采用标准的RTP协议来传输。

03

为什么要融合

主要原因是有较多的业务场景需要。

• 如在QQ讨论组里多个人想一起进行语音通话，但是他邀请的其中一个用户可能是QQ离线的，这个离线用户就无法加入进来了。
• 多人会议也类似，开会的场景一般都比较紧急，大家希望可以直接打个电话就可以把用户接入到会议中进行讨论。
• 另一个场景就是智能门禁，现在的智能门禁系统，简单地来说类似一个Pad，使用Android操作系统，安装了一个类似QQ或者实时音视频的App，可以让拜访者跟业主进行交流。这种App在业主的手机上通常不会长期启动，不像QQ或者微信那样长期处于在线状态。当这个App离线时，访客拜访业主，通过App就会找不到业主，此时如果可以通过门禁直接打电话，业主和拜访者就可以相互进行语音通话了，随后业主再通过电话的方式把门禁打开。
• 还有在各种网站上的客服电话，直接在网页上点击一下就可以打电话给客服人员，进行语音沟通。

要实现上面各种业务场景需求，就需要将实时音视频VOIP和传统的PSTN融合起来。

二、如何融合

01

分析差异

首先我们要看一下两者的差异。以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绝大多数场景是支持多人，比如说纯视频、纯语音通话可以支持客户端混音和服务端混音，但是PSTN手机端基本上是1V1。多人会议是多个人，但是手机端是不支持同时接收多路码进行混音的，必须要混好成一路后，才能下发给手机。显然这些都是两者之间的差异。

02

融合方法：寻找共性，适配差异

上面是差异的地方，有没有相同的地方呢？PSTN经过长时间的发展，目前演进到了IMS网络架构，可以把专用网络的信令流和数据流通过SIP_TRUNK的方式在Internet上面传输，这就是一个相同的地方。这个地方存在的突破口，存在可以融合的点。剩下要对差异的部分进行适配，即对音频码流和信令协议进行适配。

我们融合的方式的实现有两种，第一种是让QQ客户端去适配PSTN的差异，第二种是让PSTN去适配VOIP的差异。首先PSTN是国际通用的标准，让它适应VOIP众多的编码和私有协议，那么现在的手机设备肯定要更新升级，这显然不大现实。另外一种就是让QQ去适应PSTN的差异。QQ同样有历史包袱，他发展了那么多年，如果支持RTP和SIP改动也很大，开发周期也是非常漫长的。即然这两种方法都不行，我们就想到新增一个中间模块去分别适配VOIP和PSTN的差异。这个模块我们称之为适配层，可以放到Internet上，让VOIP和PSTN协议互转和码流互转。适配层有两个主要功能，一个是对信令的适配，还有一个是对码流的适配。

03

最终系统架构图

最上面一部分是实时音视频对外提供的OpenSdk，主要是封装了RTC一些基本操作步骤和能力，它目前支持安卓、IOS、windows、web SDK，基本上是全终端。客户端信令发向后台互动直播系统，首先经过信令处理模块App，通过多个Info模块进行机器调度分配。由于我们整个过程都是要动态自适应调整，会有一个流控模块，主要用于通话过程中音频质量的实时调节。最后信令会转到一个信令适配模块，我们称之为会控。而码流的适配、编码的转换，需要另一个适配模块混音。因为手机端不具备多路混音的能力，所以我们必须在服务端进行混音，这样将多人的码流混成一路发给手机端，手机端就能听到多个人的声音了。

上图中下面的部分是进入PSTN网络，会控把QQ私有协议转换成内部私有协议，通过PSTN策略进行一系列的分配策略，再通过处理信令的sip_server将内部私有协议转换成标准的SIP协议和运营商的SIP_SERVER相通，同理将对应的码流通过混音和proxy转成标准rtp码流和运营商媒体Svr相通。

重点说一下混音，从QQ的私有协议转到标准的RTP协议还算比较容易，但编码转换就要复杂很多。因为手机端不具备混音的能力，所以我们这部分不像VOIP客户端可以客户端混音，手机端必须要在服务端混好后才能下发一路码流给手机端。我们是采用服务端混音，如有多个VOIP进行互相通话的时候会同时发多路音频流，由外网传输到混音后台，首先会选路操作。选路是指在多个说话的人里面最多选几路语音流来进行混音操作，比如说QQ语音通话最多选六路。主要原因，第一个是说话的人多了大家听不清楚，第二个就是选择的语音流路数越多越消耗服务器资源，这样一台服务器就支持不了多少人了。选路之后，就要进行解码，解码完再进行重采样，进行混音和编码，然后再通过Proxy进行传输。最后会传输到运营商的媒体SVR，进入到运营商网络，通过用户最近的基站下发到手机端，这样就实现了手机端也可听到多路语音的功能。

三、系统优化

01

语音质量增强

语音通话中，提高语音质量是优化核心体验较为重要的一环。手机端的语音增强手段比较有限，因为它在运营商的封闭专用网络中，相对外网质量较好，少抖动和少丢包。但在VOIP端直接使用公网，所以要做的语音质量优化比较多。比如说语音采样之后，会进行回音消除和降噪。为了避免抖动会引入jitterbuffer，jitterbuffer会缓存音频包，它有一定大小，如果在缓存范围外的丢包，则要通过PLC进行补包。还有为了节省带宽我们会做VAD，如果VOIP端长期不说话的时候，我们可以不发完整的静音包，可以会发特殊的EOS包。网络质量是随时动态变化的，所以我们要进行自适应调节，以2秒为一个单位来，实时统计一下当前网络的延时、丢包、抖动等情况，综合调节客户端的采样率和码率。

02

优化语音延迟

实时音视频，低延时是重中之重。在外网传输，延时大部分引入有很多是在媒体SVR的分配上面。如在不同运营商的延时会有10到25毫秒延时，而且不同的运营商某些城市可能会有丢包，不同的机房网络延时差不多是20到35毫秒，如果直接外网，易抖动、质量不稳定。对于这些问题，我们可能通过调度分配来解决，我们尽量将媒体SVR分配到同一运营商，尽量分配到同机房。对于有条件的地方可以直接专线相连接。

03

优化网络丢包

抗网络丢包有两种方法，第一种是ARQ自动重传。我们每一个媒体节点都是采用UDP来传输且每一个媒体节点都会缓存一定数量的音频包，每个音频包里面会有一个序号，接收客户端收包时会根据包中的序列号判断是否是连续的，如果不是则有丢包，此时会去它的前一个媒体节点问一下，缓存中有没有这个包，有的话就直接重发一次，没有的话，它就再向前一个节点问一下，如果所有中间节点都没有就会一直问到发送端，发送端再把这个包再传一次。ARQ明显缺点就是会增加延时。

第二种是FEC，发送端在发音频包的时候，可以多发几个冗余包。接收到如果发现音频包丢了，而冗余包没有丢，则会尝试使用冗余包把音频包恢复。增加FEC也是动态的，当网络质量不好会多加一些冗余包，反之则会少加一些。

04

提高可用性

只要是大规模的应用或系统，这是必不可少的要解决的问题，解决这个问题简单来说就两个方面，第一个是增加冗余资源，第二是实现自动切换。机器冗余可以多运营商部署、多机房部署，多地部署，自动切换则是死机时可以自动切换、IDC异常时可以自动屏蔽出问题的IDC、自动屏蔽出问题的资源等方式。

四、总结

综上所述，融合系统的本质是一个寻找共性，适配差异的过程。本文给大家做融合类系统提供一个参考思路。如今这套融合系统已经上线公司内多个业务，目前整体服务稳定，当然还有很多需要优化的地方，如存在系统耦合模块较多、整体复杂性较高、查找问题耗时长等问题。这提醒我们仍旧需要继续努力，不断优化和迭代，将整体系统做到更好。

腾讯云通信

一直致力于

让每个企业

都享受智慧服务带来的改变

END

未来可期

长按扫码关注腾讯云通信官方微信公众号

以获取更多更专业的云通信知识