文档

音视频通信解决方案(MQTT)

更新时间:
一键部署

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

名词解释

  • MQTT

    • 一种物联网和移动互联网领域的行业标准协议,适合移动终端之间的数据传输。云消息队列 MQTT 版默认支持该协议。

  • MQTT服务器

    • 云消息队列 MQTT 版提供的MQTT协议交互的服务端节点,用于完成与MQTT客户端和云消息队列 RocketMQ 版各自的消息收发。

  • MQTT客户端

    • 用于和MQTT服务器交互的移动端节点,本方案中特指发送或接收音视频通话请求的音视频移动端应用。

  • P2P消息

    • 云消息队列 MQTT 版在标准的MQTT协议基础上提供的一种特殊消息,该类型消息无需普通的订阅关系匹配,便可直接发送给指定的单个目标MQTT客户端。详细信息,请参见P2P消息收发模式(MQTT)

  • RTC

    • 实时通信,一种主要面向语音、视频领域的网络通信方式。目前比较主流的应用场景是语音通话、视频通话、视频会议等。

  • RTC服务器

    • 阿里云音视频通信RTC提供的音视频相关媒体通道服务。

  • 音视频业务管控服务器

    • 音视频通信系统中的管控节点(下文简称音视频管控服务)。音视频管控服务需要由业务方自行建设,用于控制所有音视频通信会话的生命周期。该管控节点一般部署在云端,使用阿里云的基础产品搭建。

  • 音视频移动端应用

    • 音视频通信系统中最终用户持有的终端App(下文简称终端App)。用户使用该App发起或者参与音视频通话。

方案架构

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

图 1. 方案架构方案架构

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

方案优势

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

  • 服务能力弹性扩缩

    • 云消息队列 MQTT 版和音视频通信RTC服务都能实现按需使用,动态扩缩,轻松应对突发流量高峰。

  • 网络覆盖范围广

    • 云消息队列 MQTT 版和音视频通信RTC都提供全球部署,实现服务就近接入,避免自建跨区跨国的成本。

  • 建设周期短,接入简单

    • 无运维建设过程,人力和硬件成本降低。

    • API简单易用,快速上手。

  • 安全可靠

    • 所有服务节点高可用,稳定性高。

    • 云消息队列 MQTT 版支持SSL/TLS加密,媒体流支持SRTP保护。

数据交互

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

图 2. 数据流数据流

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

  1. 终端App的某个用户A发起会议请求,通过发送MQTT消息将请求传递到MQTT服务端,消息经过云消息队列 MQTT 版路由到云消息队列 RocketMQ 版,业务方自行开发的音视频管控服务通过接收消息处理该会议请求,验证通过后调用音视频通信RTC的API注册本次通信的相关资源和参数。

  2. 音视频管控服务收到参数后将参数封装成邀请入会的消息,发送到云消息队列 RocketMQ 版,经过云消息队列 MQTT 版路由后消息会投递给发起者用户A使用的终端App,用户A的终端App根据参数加入会议频道完成入会操作。

  3. 音视频管控服务还需要根据用户A邀请的信息找到用户B信息,同样封装一条邀请入会的消息,传递流程同步骤2

  4. 会议参与者用户B收到参数后加入会议,本次通信初始化完成。

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

注意事项

上述流程简要描述了如何使用云消息队列 MQTT 版和音视频通信RTC快速构建自己的音视频通话App。具体的SDK说明,请参见云消息队列 MQTT 版云消息队列 RocketMQ 版以及音视频通信(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消息的详细信息,请参见P2P消息收发模式(MQTT)

  • 收发消息参数设计

    由于移动App可能存在应用切入后台被杀死(Kill)导致移动App不在线的情况,需对终端App做以下配置,以确保终端App离线重连后可以收到之前的消息:

    • cleanSession参数设置为“false”

    • QoS设置成“1”

    终端App应该对收到的消息做去重以及时效性校验(例如终端App离线超过1天,再次上线收到了1天前的消息)。

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