关于rtc:拍乐云解析融合语音通话技术实践

近日，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 的互联互通，同时反对多平台集成，跨不同的终端，用户可按需抉择接入形式，享受高质量、高稳固的语音通话体验。
当然，拍乐云的指标不止于此，咱们期待通过继续的产品迭代和技术创新，重塑人与人的连贯、人与物的连贯，让信息传递更高效。