拍乐云解析融合语音通话技术实践

近日，RTSCon2021 开发者沙龙以线上的方式顺利举办。拍乐云服务端专家沈伟锋受邀参会，并带来了《拍乐云融合语音通话技术实践》主题演讲，分享了融合语音通话的需求背景、技术基础、架构搭建和技术实践，博得参会嘉宾的一致好评。

以下为演讲实录：

PART 01 融合语音通话需求背景

网络覆盖不全

从贝尔 1876 年发明电话，到 1965 年 5 月，美国贝尔系统的 1 号电子交换机（模拟）问世，再到 1970 年，法国开通的第一部程控数字交换机 E10，之后，电话网络在全世界范围内得到了大规模的发展。而因特网（也叫互联网）起源于 1969 年美国军方正式启动的阿帕网（“ARPAnet”），到 1989 年开始才从军用转向民用，此后，因特网开始大规模地发展起来。事实上，因特网构建的基础网络（物理网络）很大一部分是基于 PSTN 的电路交换网络。正是由于这个历史原因，PSTN 网络的覆盖率要远高于因特网，在我国的一些偏远山区，尤其是人迹稀少的地方，PSTN 网络的覆盖率都是要好于互联网的。

使用成本

对于使用者来说，如果只是呼入，PSTN 一般都是免费，而基于分组数据的网络，流量的费用不管是上行的流量或下行的流量都不是免费的。在不同的国家，流量的费用从小于一美元/1G 到几十美元/1G 不等，还是非常昂贵的，以下是部分国家 2020 年 1GB（移动数据）平均费用：

• 中国-0.61 美元/GB

• 墨西哥-4.77 美元/GB

• 新西兰-6.06 美元/GB

• 美国-12 美元/GB

• 加拿大-12.55 美元/GB

使用的便利性

使用电话的时候不需要任何下载，一般也不需要任何设置。但基于互联网的 App，一般需要提前下载 App，并设置相应的环境：比如摄像头、麦克风、扬声器(耳机)、网络等。在实际的使用中经常会碰到网络不通、网络不佳、或听不到声音等问题，这些问题一般需要具备一定的专业知识的人才能解决。

特定用户群体

对于一些特定的人群，比如老年人，他们接触互联网、智能手机、电脑等比较少，尤其是广大农村的老年人。对于这样的人群，使用电话肯定会比使用 App 更容易上手。

用户惯性

目前，有一些互联网的应用系统，是从传统的呼叫中心发展过来的，他们的系统核心已经从过去的呼叫中心演变到了基于互联网 RTC 的系统，这些系统所服务的新用户群体可以是完全基于互联网 App 的，但对于一些已经习惯于电话使用该系统的老用户群体，会需要一个使用习惯的转换过程，不然这样的客户群体有可能会慢慢流失。

PART 02 PSTN 融合 RTC 的技术基础

• PSTN

PSTN ( Public Switched Telephone Network )：公共交换电话网络。PSTN 是一种以模拟技术为基础的电路交换网络。

• 因特网/互联网

因特网（Internet）是由广域网上众多的物理网络（子网）相互连接而成一个逻辑网络，也叫互联网。它是基于一些共同的协议，并通过众多交换机/路由器实现分组数据交换，多路复用等技术连接而成的网络。

• PSTN 和互联网之间关系

PSTN 可以是互联网 7 层网络中的物理层。在众多的广域网互连技术中，基于 PSTN 进行互连所要求的通信费用最低，但同时 PSTN 的网络资源利用率也比较低。

• IMS

IMS(IP Multimedia Subsystem)：网际协议多媒体子系统，是由朗讯（Lucent）提出的下一代通信网（NGN）实现大融合方案的网络架构，被认为是下一代网络的核心技术。IMS 的目标不仅是在现网基础上提供新的业务，而且它还要能提供现在以及未来因特网上能够承载的所有的业务。

• SIP

SIP(Session Initialization Protocol)：会话初始化协议。IMS 系统采用 SIP 协议进行端到端的呼叫控制。

• SDP

SDP(Session Description Protocol)：会话描述协议。SIP 协议使用 SDP 来描述如何设置和初始化会话及会话中使用到的多媒体，主要包括会话者信息，会话时间，网络传输方式，媒体信息等等。

• RTP/RTCP

RTP（Real-time Transport Protocol）实时传输协议，定义了在互联网上传输多媒体时的标准数据包格式。RTCP（Real-time Transport Control Protocol）实时传输控制协议，主要用于 QoS 反馈和同步媒体流。

PART 03 融合语音通话技术实践

我们来看看电话呼入的一个基本流程：

首先用户侧使用电话拨入会议专用号码，经过 IMS 系统承载的 SIP 呼入 Pano 服务，经过 Pano 前置四层负载均衡器，进入其中一个可用的 Pano SIP LB。Pano SIP LB 分配一个可用的 SIP2RTC Gateway。SIP2RTC Gateway 发起 re-Invite，并开始 IVR 交互入会过程，同时请求 Pano Service LB 分配 RTC 媒体服务，并加入媒体服务。最后 SIP2RTC Gateway 桥接两边的会话，并做相应的协议转换和媒体转码合流。

基于此，融合语音通话就需要具备如下技术特性：

服务的高可用

• SIP LB Active-Standby 模式防止单节点故障，可演进到 Active-Active 模式的 SIP LB 池来支持水平扩展；

• SIP2RTC Gateway 池可水平扩展，支持高并发；

• SIP LB/SIP2RTC Gateway 任何一个节点失效后，系统会自动快速进行会话迁移，保障通话不中断；

• 加持 Pano RTC 媒体服务的高可用高并发。

完善的会控能力

锁住会议、静音参会者、移除参会者、分组讨论、查询/关闭会议等

多运营商多线路负载均衡

得益于 IMS 对后端运营商的各种网络的融合，我们可以用统一的接口对接所有运营商的网络。PSTN 网络是基于电路交换的网络，而且是对线路独占的，同一个号码能支持的线路资源是有限的，本系统通过多线路资源负载均衡达到高并发的需求。

IVR 个性化定制

会议场景的 IVR 主要包括：入会引导，信息或错误提示等，本系统支持对所有这些交互 IVR 的定制。

再来说说我们在过程中遇到了哪些坑。

NAT keepalive, 导致 SIP(over UDP) NAT 没有被转换

这个问题在 SIP over TCP 的情况下并不存在，只有在 SIP over UDP 时才会碰到。为了能到达正确的目的地及响应能按原路正确的返回，SIP（over UDP）会话在经过 NAT 的时候，会在 via 头中添加路由信息，还会改写 request-line 的目标地址。这种应用层的 NAT 转换在不同的设备上的实现方式各不相同，尤其是软件实现的 NAT，有些 NAT 会自动根据 UDP 会话的第一个包是不是 SIP 协议来自动标记是否需要做 SIP 的 NAT 转换。

一开始我们是通过软终端(linephone)模拟电话呼入来测试的，但是经常发现过一段时间，SIP 的 NAT 转换莫名其妙的没有了。后来发觉，这个软终端会定期发送 NAT keepalive 包，来做 UDP 的保活，避免 NAT 上的 UDP 五元组的对应关系被删除，但是当我们的 PC 经过一段时间的休眠状态后，在激活的时候，NAT 上的这个五元组对应关系已经被删除，并且这个软终端在激活的时候首先发出了 NAT keepalive，导致 NAT 认为这个“新”的 UDP 会话不是 SIP 会话，最终导致 SIP NAT 转换没有被启动。

乱序的容错处理(sip over UDP)

这个问题是由于 UDP 的乱序导致后续的 re-Invite 先于前面的 200 OK 的响应。对于一个容错处理好的系统，比较合适的做法是当收到新的 re-Invite 的时候，应该允许进入新的重新协商的阶段，而不是简单的拒绝，当老的 200 OK 到达的时候直接丢弃就可以了。然后，在我们对接的过程中发现，这种情况下，re-Invite 会被直接拒绝掉。解决这个问题的最简单的办法是把 SIP over UDP 改成 SIP over TCP，或者对 re-Invite 做适当的延迟处理即可。

PART 04 一个 SDK 连接所有语音通话场景

截止当前，融合语音通话已服务于视频会议、远程问诊、金融营销、远程面试、智能硬件五大场景客户，一个 SDK 连接所有语音通话场景，实现 VoIP 和 PSTN 的互联互通，同时支持多平台集成，跨不同的终端，用户可按需选择接入方式，享受高质量、高稳定的语音通话体验。

当然，拍乐云的目标不止于此，我们期待通过持续的产品迭代和技术创新，重塑人与人的连接、人与物的连接，让信息传递更高效。