RTE2021 回顾丨面向 RTE 场景的新一代 API 探索和实践

本文整理自声网 Agora SDK 资深架构师章真在 RTE 2021 实时互联网大会大前端与应用开发专场上的演讲分享。章真在 2017 年加入声网，作为第二代架构师，目前负责声网 SDK的 API 和架构设计。在演讲中他主要围绕从 WebRTC 的引入到 JoinChannel（声网 Agora SDK 的一个 API），从实时音视频 RTC 到实时互动 RTE 时代，以及面向 RTE 的新一代实时音视频 API 的设计与使用。

▲图：声网Agora SDK 资深架构师 章真

章真认为 API 设计的首要要素是要解决用户的需求。开发人员如何在当前条件下以最优的方式去解决用户需求，再结合集成体验、设计原则，寻找最佳方案，才是 API 的设计过程，也是 API 的核心理念。

如果说 20 世纪人类的通讯方式是书信，工具是纸笔；21 世纪初人类的通讯方式是短信邮件，工具是键盘；如今，视频成了娱乐、学习、商务会议、社交、电商的载体，促进人类用影像而非仅文字去记录与沟通。而奠定这一发展的基础技术就是 WebRTC（Web Real-Time Communication）。那么 WebRTC 能为我们解决什么问题呢？章真介绍到，WebRTC 有四点特性：

1. WebRTC 是支持网页浏览器进行实时语音对话或视频对话的 API。

2. 支持 JavaScript API，符合现代浏览器开放标准。

3. 基于 P2P  RTC 的解决方案，具有低带宽消耗、低延时、端到端安全加密的特性。

4. 代码开源且可移植。

同时，他介绍到 WebRTC 的工作原理主要是四个核心概念：信令、连接、安全加密、通信。

首先，WEBRTC 不管理信令，开发者需要自己搭建信令系统用于建立会话；其次，连接过程依赖于不易用的文本化的 SDP；再次，WEBRTC 缺乏丰富的媒体管理的 API，比如 codec 依赖于浏览器协商。整合看来，WebRTC 的 API 对于 RTC 的入门来说，稍显复杂。

由于 WebRTC API中依赖的SDP 有不少局限性，因此微软进入到 WebRTC 领域后，推出了 NG RTC，也就是 ORTC。ORTC 面临要解决的问题如下：

1. ORTC 解决了连接过程依赖文本化 SDP 以及连接时长过长的问题，不使用 SDP 作为 API 的一部分；

2. 不再使用 Offer/Answer 的状态机作为建立连接的必要路径，而是通过更实时的同步方式协商，并动态响应媒体流的变化，让连接响应更快速；

3. 最后还抽象了一系列的 RTC 基础对象、功能对象，具备精确的能力描述，不用修改 SDP，可以通过设置对象参数的方式，来建立通话和控制媒体。

章真向我们展示了 ORTC 功能模块趋于抽象的结构图。结构图中显示抽象后的对象还是较多的，这些模块负责对于数据或是音视频源的控制，常见的模块有 Track，RtpTranseiver，Transport。随着 ORTC 模型的普及，以及清晰的 API 设计， WebRTC 1.0 就吸收了 ORTC 的很多设计原则，增加了对于音视频控制模块的抽象。

时间回到 2014 年，声网将 WebRTC 引入到中国，并在国内率先开启了实时音视频的赛道。在那时绝大部分开发者还不太了解 RTC 的概念，通过提高 RTC 易用性和降低 RTC 的准入门槛来普及 RTC 技术是声网要解决的首要问题。解决的方法，一是提供简单易用的 API 接入 RTC，二是提供“专线级”质量保证的 SD-RTN™。

所以易用性是第一代 API 设计的原则。首先在 API 表现层上，尽量的隐藏 RTC 细节，仅仅体现了 RTC 的业务，依赖频道、用户（主播/观众）、音视频流（本地/远播）的概念，降低了 RTC 的技术门槛。其次，而在API 交互上，提供了基于客户业务流程 API，让没有专业背景的人也能读懂 API 业务意图，对 App 集成提供了便利。

正是这种设计原则，声网 SDK 可以让开发者可以用 4 到 6 行代码，快速接入SD-RTN™ 中，完成实时音视频的业务。

章真认为实时音视频发展已经从互通 RTC 到万物互联的 RTE 时代。他向观众展示了声网在 2014 年到 2020 年的需求和场景来展示实时音视频的发展过程，在这个过程中，实时互动场景越来越丰富，而背后的需求和需要解决的问题也越来越复杂。

他以 2021 年新的场景“实时合唱”举例：实时合唱从 2016 年开始，从轮唱（AB 交替，同时只有一人在唱）到“伪”合唱（A 听不见 B，只能 2 人在唱），再到今天的实时合唱（AB 同时唱，互相听得见），技术不断的更新，核心技术点是需要多方多源同步、超低延迟与超级音效。

另一个举例场景是音乐美术等实时在线的素质教学，双减下，教育在转型，对音乐和美术的需求，促使架构和 API 的优化。这些新场景需要多路摄像头采集、多路音频源、声卡采集等，以及视频前处理，如梯形校正、暗光增强、鱼眼校正等。

API 本质也是架构的外在表现，为了满足 RTE 日新月异的需求，声网在内部不断升级音视频引擎，逐步形成了一套灵活可扩展微内核加组件化的架构。他在演讲中展示了一张视频引擎的架构图，并解释声网在架构上做的创新和改变。

需求在变，解决的问题也自然在变更，作为架构的外表，API 也需要适应新的变化。对于面向 RTE 的下一代的 API 话题，章真提到：

1、进一步拆分面向业务流程的 API。每个 API 都是一个独立的功能，把建立连接、创建媒体流、管理媒体流三个 API 都通过独立的 API 去交付，让客户自定义自己的业务流程。

2、抽象场景、用户、道具等基础的业务模块，更贴近 RTE 业务，灵活可拓展。

3、提供更多实时和非实时性组件，在易用性上做了一定的保持。如内置播放器、本地合图转码、本地推流器等新的业务组件，开发者非常容易通过内置组件完成复杂的场景。

章真总结，声网已经不仅提供 API、SDK，还在与生态厂商一起建立生态，希望最终实现“API as a Platform”的平台。其中，Agora RTC API 从“提供能力”出发设计，对外部客户提供 RTC SDK 的业务功能，简单集成，快速上线。更重要的，生态建设是以“用户需求”为中心设计。

声网的 API 是分层设计的，Low Level API 和 High Level API 两个层次的 API 保证了灵活性和易用性，开发者可以在 Low Level API 和 High Level API 之间拥有自己定制的最佳实践，同时投入开源计划，建立开发者社区，开发支持插件系统，最终共建 RTE 生态。同时，新版 API 还结合了声网云市场，为丰富的音视频插件提供支持。开发者可以在声网控制台自助开启插件功能，并且在代码层面，通过简易的代码设置，开启丰富的音视频插件功能。