名詞解釋

• MQTT

  • 一種物聯網和移動互聯網領域的行業標準協議，適合移動終端之間的數據傳輸。云消息隊列 MQTT 版默認支持該協議。

• MQTT服務器

  • 云消息隊列 MQTT 版提供的MQTT協議交互的服務端節點，用于完成與MQTT客戶端和云消息隊列 RocketMQ 版各自的消息收發。

• MQTT客戶端

  • 用于和MQTT服務器交互的移動端節點，本方案中特指發送或接收音視頻通話請求的音視頻移動端應用。

• P2P消息

  • 云消息隊列 MQTT 版在標準的MQTT協議基礎上提供的一種特殊消息，該類型消息無需普通的訂閱關系匹配，便可直接發送給指定的單個目標MQTT客戶端。詳細信息，請參見P2P消息收發模式（MQTT）。

• RTC

  • 實時通信，一種主要面向語音、視頻領域的網絡通信方式。目前比較主流的應用場景是語音通話、視頻通話、視頻會議等。

• RTC服務器

  • 阿里云音視頻通信RTC提供的音視頻相關媒體通道服務。

• 音視頻業務管控服務器

  • 音視頻通信系統中的管控節點（下文簡稱音視頻管控服務）。音視頻管控服務需要由業務方自行建設，用于控制所有音視頻通信會話的生命周期。該管控節點一般部署在云端，使用阿里云的基礎產品搭建。

• 音視頻移動端應用

  • 音視頻通信系統中最終用戶持有的終端App（下文簡稱終端App）。用戶使用該App發起或者參與音視頻通話。

方案架構

方案架構展示了音視頻通信解決方案的架構。

如方案架構所示，音視頻管控服務和終端App之間通過阿里云消息隊列產品完成信令傳輸，通過阿里云音視頻通信RTC產品完成業務數據交互。詳情可參見下文中的數據交互部分。

方案優勢

音視頻通信解決方案的優勢如下所述：

• 服務能力彈性擴縮

  • 云消息隊列 MQTT 版和音視頻通信RTC服務都能實現按需使用，動態擴縮，輕松應對突發流量高峰。

• 網絡覆蓋范圍廣

  • 云消息隊列 MQTT 版和音視頻通信RTC都提供全球部署，實現服務就近接入，避免自建跨區跨國的成本。

• 建設周期短，接入簡單

  • 無運維建設過程，人力和硬件成本降低。

  • API簡單易用，快速上手。

• 安全可靠

  • 所有服務節點高可用，穩定性高。

  • 云消息隊列 MQTT 版支持SSL/TLS加密，媒體流支持SRTP保護。

數據交互

數據流所展示的是基于云消息隊列 MQTT 版和音視頻通信RTC實現一次音視頻通話會議的調用流程，其中灰色部分為您的自建開發程序或服務，藍色部分是云消息隊列 MQTT 版、云消息隊列 RocketMQ 版以及音視頻通信RTC所提供的服務。

如數據流所示，該場景中用戶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天前的消息）。

  cleanSession和QoS的更多信息，請參見名詞解釋。