今年火热的实时音视频技术为什么要和古老的PSTN融合？-InfoQ

抖音技术能力大揭密！钜惠大礼、深度体验，尽在火山引擎增长沙龙，就等你来！立即报名>> 了解详情 



 写点什么

6 月 29 日，音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题，针对腾讯云音视频及融合通信产品的技术全面剖析，为大家带来纯干货的技术分享。下面是颜学伟老师关于实时音频与传统 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

下面来说一下 PSTN，从字面意思来看就是公共交换电话网，这是一种比较老的技术。为什么说它老呢？因为第一部电话发明是由美国贝尔 1876 年发明的，距离今天有 143 的历史了。虽然历史比较古老，但电话现在还是我们使用和应用场景比较广泛的一种实时的语音通话方式。大家有一些重要的事情基本上都优先打电话，而且打电话在手机端各种操作系统里面，优先级是最高的，属于一种强提醒方式。

（见下图）这是座机，通过电话线和 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、自动屏蔽出问题的资源等方式。