音视频通信解决方案是由阿里云微消息队列 MQTT 和音视频通信 RTC 联合推出的有助于快速搭建各种实时通信场景产品,譬如在线音视频会议、1 对 1 语音通话应用的解决方案。本文将详细描述该解决方案的系统架构、数据流设计以及相关注意事项。

名词解释

MQTT
一种物联网和移动互联网领域的行业标准协议,适合移动终端之间的数据传输。微消息队列 MQTT 默认支持该协议。
MQTT 服务器
微消息队列 MQTT 提供的 MQTT 协议交互的服务端节点,用于完成与 MQTT 客户端和消息队列 MQ 各自的消息收发。
MQTT 客户端
用于和 MQTT 服务器交互的移动端节点,本方案中特指发送或接收音视频通话请求的音视频移动端应用。
P2P 消息
微消息队列 MQTT 在标准的 MQTT 协议基础上提供的一种特殊消息,该类型消息无需普通的订阅关系匹配,便可直接发送给指定的单个目标 MQTT 客户端。详情请参见 P2P 消息收发模式(MQTT)
RTC
实时通信,一种主要面向语音、视频领域的网络通信方式。目前比较主流的应用场景是语音通话、视频通话、视频会议等。
RTC 服务器
阿里云音视频通信 RTC 提供的音视频相关媒体通道服务。
音视频业务管控服务器
音视频通信系统中的管控节点(下文简称音视频管控服务)。音视频管控服务需要由业务方自行建设,用于控制所有音视频通信会话的生命周期。该管控节点一般部署在云端,使用阿里云的基础产品搭建。
音视频移动端应用
音视频通信系统中最终用户持有的终端 App(下文简称终端 App)。用户使用该 App 发起或者参与音视频通话。

方案架构

图 1 展示了音视频通信解决方案的架构。

图 1. 方案架构


图 1 所示,音视频管控服务和终端 App 之间通过阿里云消息队列产品完成信令传输,通过阿里云音视频通信 RTC 产品完成业务数据交互。详情可参见下文中的数据交互部分。

方案优势

音视频通信解决方案的优势如下所述:

  • 服务能力弹性扩缩
    • 微消息队列 MQTT 和音视频通信 RTC 服务都能实现按需使用,动态扩缩,轻松应对突发流量高峰。
  • 网络覆盖范围广
    • 微消息队列 MQTT 和音视频通信 RTC 都提供全球部署,实现服务就近接入,避免自建跨区跨国的成本。
  • 建设周期短,接入简单
    • 无运维建设过程,人力和硬件成本降低。
    • API 简单易用,快速上手。
  • 安全可靠
    • 所有服务节点高可用,稳定性高。
    • 微消息队列 MQTT 支持 SSL/TLS 加密,媒体流支持 SRTP 保护。

数据交互

图 2 所展示的是基于微消息队列 MQTT 和音视频通信 RTC 实现一次音视频通话会议的调用流程,其中灰色部分为您的自建开发程序或服务,蓝色部分是微消息队列 MQTT、消息队列 MQ 以及音视频通信 RTC 所提供的服务。

图 2. 数据流


图 2 所示,该场景中用户 A 将邀请用户 B 加入音视频会议,具体流程如下所述:

  1. 终端 App 的某个用户 A 发起会议请求,通过发送 MQTT 消息将请求传递到 MQTT 服务端,消息经过微消息队列 MQTT 路由到消息队列 MQ,业务方自行开发的音视频管控服务通过接收消息处理该会议请求,验证通过后调用音视频通信 RTC 的 API 注册本次通信的相关资源和参数。
  2. 音视频管控服务收到参数后将参数封装成邀请入会的消息,发送到消息队列 MQ,经过微消息队列 MQTT 路由后消息会投递给发起者用户 A 使用的终端 App,用户 A 的终端 App 根据参数加入会议频道完成入会操作。
  3. 音视频管控服务还需要根据用户 A 邀请的信息找到用户 B 信息,同样封装一条邀请入会的消息,传递流程同步骤 2
  4. 会议参与者用户 B 收到参数后加入会议,本次通信初始化完成。

基于上述设计思路,可以使用微消息队列 MQTT 消息实现其他自定义流程,例如销毁会议、中途拉人入会、禁言等操作。微消息队列 MQTT 在音视频会议场景中充当了信令传输的角色。

注意事项

上述流程简要描述了如何使用微消息队列 MQTT 和音视频通信 RTC 快速构建自己的音视频通话 App。具体的 SDK 说明请参见微消息队列 MQTT消息队列 MQ 以及音视频通信(RTC)文档。

其中使用微消息队列 MQTT 构建音视频通话场景的信令传输时,相关的消息类型设计以及参数设计请尽可能遵循如下原则:

  • 客户端 ID 映射

    MQTT 协议要求每个客户端都有一个全局唯一的 Client ID,Client ID 由以下两部分组成,这两部分通过 “@@@” 分隔符连接,只需要保证最终的 Client ID 唯一且总长度不超过 64 个字符即可:
    • 前缀 Group ID:Group ID 需在微消息队列 MQTT 控制台申请。建议 Group ID 按照 App 的平台或者渠道进行粗分类,例如 Android 和 iOS 的客户端分成不同的 Group ID,或者不同版本的客户端使用不同的 Group ID,方便问题定位。
    • 后缀 Device ID:Device ID 由应用生成。Device ID 可以和用户 App 账号 ID 进行一一映射,确保全局唯一。

    Client ID 的更多信息请参见名词解释

  • Topic 名称映射

    使用微消息队列 MQTT 收发消息需要了解 MQTT 协议订阅关系的模型,详情请参见协议文档官网文档

    MQTT 是遵循发布/订阅模型的消息协议,订阅关系和 Topic 符合目录树格式,Topic 可分为父级 Topic 和子级 Topic,Topic(包含父级 Topic 和子级 Topic)的总长度不能超过 64 个字符:
    • 父级 Topic:通常称目录树第一级的 Topic 为父级 Topic。父级 Topic 需要在微消息队列 MQTT 控制台申请后才可使用,申请后相当于一个 Namespace。
    • 子级 Topic:目录树第一级的 Topic 的后续部分称为子级 Topic。子级 Topic 无需申请,业务方可以随意指定。

    Topic 的更多信息请参见名词解释

    业务方设计用于消息收发的 Topic 时,需要遵循以下原则:

    • 上行消息(终端 App 发给管控服务的消息)和下行消息(管控服务发给终端 App 的消息)使用不同的父级 Topic。
    • 不同优先级或者消息量级差别比较大的消息使用不同的父级 Topic。

    对于上文描述的交互流程,建议使用微消息队列 MQTT 提供的 P2P 消息,P2P 消息不需要订阅,发送方直接指定对端接收即可,详情请参见 P2P 消息收发模式(MQTT)

  • 收发消息参数设计

    由于移动 App 可能存在应用切入后台被杀死(Kill)导致移动 App 不在线的情况,需对终端 App 做以下配置,以确保终端 App 离线重连后可以收到之前的消息:
    • cleanSession 参数设置为 “false”
    • QoS 设置成 “1”
    终端 App 应该对收到的消息做去重以及时效性校验(比如终端 APP 离线超过 1 天,再次上线收到了 1 天前的消息)。

    cleanSession 和 QoS 的更多信息,请参见名词解释