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

本周的技术解码将为大家解析腾讯云实时音视频与 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、自动屏蔽出问题的资源等方式。

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