ApsaraMQ for MQTT：音視頻通訊解決方案（MQTT）

名詞解釋

• MQTT

  • 一種物聯網和移動互連網領域的行業標準協議，適合移動終端之間的資料轉送。雲Message QueueTT 版預設支援該協議。

• MQTT伺服器

  • 雲Message QueueTT 版提供的MQTT協議互動的服務端節點，用於完成與MQTT用戶端和雲訊息佇列 RocketMQ 版各自的訊息收發。

• MQTT用戶端

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

• P2P訊息

  • 雲Message QueueTT 版在標準的MQTT協議基礎上提供的一種特殊訊息，該類型訊息無需普通的訂閱關係匹配，便可直接發送給指定的單個目標MQTT用戶端。詳細資料，請參見P2P訊息收發模式（MQTT）。

• RTC

  • 即時通訊，一種主要面向語音、視頻領域的網路通訊方式。目前比較主流的應用情境是語音通話、視訊通話、視頻會議等。

• RTC伺服器

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

• 音視頻業務管控伺服器

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

• 音視頻移動端應用

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

方案架構

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

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

方案優勢

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

• 服務能力彈性擴縮

  • 雲Message QueueTT 版和音視頻通訊RTC服務都能實現按需使用，動態擴縮，輕鬆應對突發流量高峰。

• 網路覆蓋範圍廣

  • 雲Message QueueTT 版和音視頻通訊RTC都提供全球部署，實現服務就近接入，避免自建跨區跨國的成本。

• 建設周期短，接入簡單

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

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

• 安全可靠

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

  • 雲Message QueueTT 版支援SSL/TLS加密，媒體流支援SRTP保護。

資料互動

資料流所展示的是基於雲Message QueueTT 版和音視頻通訊RTC實現一次音視訊通話會議的調用流程，其中灰色部分為您的自建開發程式或服務，藍色部分是雲Message QueueTT 版、雲訊息佇列 RocketMQ 版以及音視頻通訊RTC所提供的服務。

如資料流所示，該情境中使用者A將邀請使用者B加入音視頻會議，具體流程如下所述：

1. 終端App的某個使用者A發起會議邀請，通過發送MQTT訊息將請求傳遞到MQTT服務端，訊息經過雲Message QueueTT 版路由到雲訊息佇列 RocketMQ 版，業務方自行開發的音視頻管控服務通過接收訊息處理該會議邀請，驗證通過後調用音視頻通訊RTC的API註冊本次通訊的相關資源和參數。

2. 音視頻管控服務收到參數後將參數封裝成邀請入會的訊息，發送到雲訊息佇列 RocketMQ 版，經過雲Message QueueTT 版路由後訊息會投遞給發起者使用者A使用的終端App，使用者A的終端App根據參數加入會議頻道完成入會操作。

3. 音視頻管控服務還需要根據使用者A邀請的資訊找到使用者B資訊，同樣封裝一條邀請入會的訊息，傳遞流程同步驟2。

4. 會議參與者使用者B收到參數後加入會議，本次通訊初始化完成。

基於上述設計思路，可以使用雲Message QueueTT 版訊息實現其他自訂流程，例如銷毀會議、中途拉人入會、禁言等操作。雲Message QueueTT 版在音視頻會議情境中充當了信令傳輸的角色。

注意事項

上述流程簡要描述了如何使用雲Message QueueTT 版和音視頻通訊RTC快速構建自己的音視訊通話App。具體的SDK說明，請參見雲Message QueueTT 版、雲訊息佇列 RocketMQ 版以及音視頻通訊（RTC）文檔。

其中使用雲Message QueueTT 版構建音視訊通話情境的信令傳輸時，相關的訊息類型設計以及參數設計請儘可能遵循如下原則：

• 用戶端ID映射

  MQTT協議要求每個用戶端都有一個全域唯一的Client ID，Client ID由以下兩部分組成，這兩部分通過 “@@@” 分隔字元串連，只需要保證最終的Client ID唯一且總長度不超過64個字元即可：

  • 首碼Group ID：Group ID需在雲Message QueueTT 版控制台申請。建議Group ID按照App的平台或者渠道進行粗分類，例如Android和iOS的用戶端分成不同的Group ID，或者不同版本的用戶端使用不同的Group ID，方便問題定位。

  • 尾碼Device ID：Device ID由應用產生。Device ID可以和使用者App帳號ID進行一一映射，確保全域唯一。

  Client ID的更多資訊，請參見名詞解釋。

• Topic名稱映射

  使用雲Message QueueTT 版收發訊息需要瞭解MQTT協議訂閱關係的模型，詳細資料，請參見協議文檔和官網文檔。

  MQTT是遵循發布/訂閱模型的訊息協議，訂閱關係和Topic符合分類樹格式，Topic可分為父級Topic和子級Topic，Topic（包含父級Topic和子級Topic）的總長度不能超過64個字元：

  • 父級Topic：通常稱分類樹第一級的Topic為父級Topic。父級Topic需要在雲Message QueueTT 版控制台申請後才可使用，申請後相當於一個Namespace。

  • 子級Topic：分類樹第一級的Topic的後續部分稱為子級Topic。子級Topic無需申請，業務方可以隨意指定。

  Topic的更多資訊，請參見名詞解釋。

  業務方設計用於訊息收發的Topic時，需要遵循以下原則：

  • 上行訊息（終端App發給管控服務的訊息）和下行訊息（管控服務發給終端App的訊息）使用不同的父級Topic。

  • 不同優先順序或者訊息量級差別比較大的訊息使用不同的父級Topic。

  對於上文描述的互動流程，建議使用雲Message QueueTT 版提供的P2P訊息，P2P訊息不需要訂閱，發送方直接指定對端接收即可，P2P訊息的詳細資料，請參見P2P訊息收發模式（MQTT）。

• 收發訊息參數設計

  由於移動App可能存在應用切入後台被殺死（Kill）導致移動App不線上的情況，需對終端App做以下配置，以確保終端App離線重連後可以收到之前的訊息：

  • cleanSession參數設定為“false”

  • QoS設定成“1”

  終端App應該對收到的訊息做去重以及時效性校正（例如終端App離線超過1天，再次上線收到了1天前的訊息）。

  cleanSession和QoS的更多資訊，請參見名詞解釋。