Real-Time Communication solution is developed by Alibaba Cloud Message Queue for MQTT alibaba Cloud and Alibaba Real-Time Communication RTC jointly launched products to help you quickly build a variety of real-time communication scenarios, such as online audio and video conferencing and one-to-one voice call applications. This topic describes the system architecture, data flow design, and related matters for attention in detail.


Message Queuing Telemetry Transport (MQTT protocol)
The MQTT protocol is an industry-standard protocol for the Internet of Things (IoT) and mobile Internet, which is suitable for data transmission between mobile devices. Message Queue for MQTT The MQTT protocol is supported by default.
MQTT broker
Message Queue for MQTT The MQTT broker is used as a server node to interact with MQTT clients and Message Queue for Apache RocketMQ respective message sending and receiving.
MQTT client
The MQTT client is the node that is used to interact with the MQTT broker. In this solution, it specifically indicates the audio/video mobile application that sends or receives audio/video calling requests.
P2P message
Message Queue for MQTT A special type of message that is provided based on the standard MQTT protocol. This type of message can be directly sent to a specified target MQTT client without subscription matching. For more information, see P2P Messaging model (MQTT).
Real-Time Communication (RTC)
A real-time network communication method for the voice and video fields. Currently, the mainstream use cases include voice calling, video calling, and video conferencing.
RTC server
This server hosts the audio/video and related media channel services provided by Alibaba Cloud RTC.
RTC service management server
These servers are the control nodes in the audio/video communication system, which are referred to as audio/video management services in this topic. The RTC management service must be manually created, and controls the lifecycles of all RTC sessions. The management node is normally deployed in the cloud, and is constructed using Alibaba Cloud products.
Audio/video mobile application
This is the application on the terminal that is used by the end user in the audio/video communication system, which is referred to as the terminal application in this topic. The user uses this application to initiate or participate in audio/video calls.

Solution architecture

Figure 1 shows the architecture of the audio/video communication solution.

Figure 1. Solution architecture
Solution architecture

As shown in Figure 1, the audio/video management service and the terminal application signal by using the AliwareMQ for RocketMQ, and implement service data interactions through Alibaba Cloud RTC. For more information, see Data interaction.


The advantages of the audio/video communication solution are as follows:

  • Service capabilities are scalable.
    • Message Queue for MQTT and Alibaba Cloud RTC can be used on demand and dynamically scaled up to handle burst traffic peaks.
  • Network coverage is widespread.
    • Message Queue for MQTT and Alibaba Cloud RTC provide global deployment capabilities to achieve local service access and save cross-zone and cross-nation costs.
  • The construction period is short, supporting easy access.
    • The construction process is O&M-free, reducing labor and hardware costs.
    • The API is easy to use, supporting rapid implementation.
  • High Reliability
    • All service nodes are highly available and stable.
    • Message Queue for MQTT supports SSL/TLS encryption and media streams support SRTP protection.

Data interaction

Figure 2 The presentation is based on Message Queue for MQTT and Real-Time Communication RTC to call an audio /video Conference. The gray part indicates your self-built development programs or services. The Blue part indicates Message Queue for MQTT, Message Queue for Apache RocketMQ and Real-Time Communication RTC services.

Figure 2. Data flows
Data flows

As shown in Figure 2, User A invites User B to join an audio/video conference. The specific process is as follows:

  1. User A of the terminal application initiates A meeting request and sends the request to the MQTT broker by sending an MQTT message. The Message passes through Message Queue for MQTT route to Message Queue for Apache RocketMQ the audio /video management service developed by the business side processes the meeting request by receiving the message. After the verification, it calls the Alibaba Cloud RTC API Real-Time Communication register the resources and parameters for this communication.
  2. After receiving the parameters, the audio /video management service encapsulates the parameters in an invitation message and sends the parameters to the Message Queue for Apache RocketMQ, after Message Queue for MQTT the message is then delivered to the terminal application of user A. The terminal application of user A is added to the conference channel based on the parameters.
  3. The audio/video management service also needs to find User B's information based on the information in User A's invitation. Similarly, the service also encapsulates the parameters into an invitation message, and the transfer process for User B is the same as that for User A described in Step 2.
  4. The conference member User B joins the conference after receiving the parameters, and the communication initialization is completed.

Based on the preceding design ideas, you can use the Message Queue for MQTT implement other custom processes for sending messages. For example, you can destroy a meeting, invite others to join a meeting, and block a speech. Message Queue for MQTT plays the signaling role in audio/video conferencing scenarios.


The preceding process briefly describes how to use Message Queue for MQTT and Real-Time Communication RTC to quickly build your own audio and video calling App. For more information about the SDK description, see Message Queue for MQTT, Message Queue for Apache RocketMQ and Real-Time Communication (RTC) documents.

Where use Message Queue for MQTT when constructing a signaling channel for real-time communication, follow these principles for message type and parameter design:

  • MQTT client ID mapping
    The MQTT protocol requires that each client have a globally unique client ID. A client ID consists of two parts concatenated with the @@@ separator. The final client ID must be unique and its total length cannot exceed 64 characters. The following describes the two parts of a client ID:
    • Prefix Group ID: The Group ID must be Message Queue for MQTT apply for the console. You are advised to classify the group IDs by application platform or channel to facilitate troubleshooting. For example, Android and iOS clients can be divided into different group IDs, or clients of different versions use different group IDs.
    • Device ID that is the suffix in a client ID: A device ID is generated by an application. Device IDs can be mapped to application account IDs to ensure their global uniqueness.

    For more information about client IDs, see Terms.

  • Topic name mapping

    Use Message Queue for MQTT to send and receive messages, you must understand the publish /subscribe pattern of the MQTT Protocol. For more information, see agreement document and official documentation.

    The MQTT protocol is a message protocol based on the publish/subscribe pattern. The subscriptions and topics follow the directory tree format. Topics can be divided into parent topics and subtopics. The total length of a topic including the parent topic and subtopics cannot exceed 64 characters. The following describes the types of topics:
    • Parent topic: The topic at the first level of the directory tree is a parent topic. The parent Topic must be Message Queue for MQTT can be used only after applying for permissions in the console. A Namespace is equivalent to a Namespace.
    • Subtopic: A topic under a level-1 topic in the directory tree in MQTT is a subtopic. You can specify subtopics as needed without having to apply for them.

    For more information about topics, see Terms.

    When designing a topic for sending and receiving messages, you must comply with the following principles:

    • Different parent topics are used for upstream messages (messages sent from the terminal application to the management service) and downstream messages (messages sent from the management service to the terminal application).
    • Messages with different priorities or large size differences use different parent topics.

    For the interaction process described above, we recommend that you use Message Queue for MQTT P2P messages do not need to be subscribed, and the sender can directly specify the peer end to receive them. For more information, see P2P Messaging model (MQTT).

  • Parameter design for message sending and receiving
    Mobile applications may be killed in the background, making the mobile application offline. To handle this situation, you are advised to configure the terminal application as follows to ensure that the terminal application receives the previous message after it goes back online:
    • Set the CleanSession parameter to "false".
    • Set QoS to "1".
    The terminal application should perform deduplication and timeliness verification on the received messages (for example, if the terminal application remains offline for more than one day and then receives the messages from the previous day when it goes online again).

    For more information about CleanSession and QoS, see Terms.