ApsaraMQ for MQTT:Real-time communication solution (MQTT)

Terms

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. ApsaraMQ for MQTT The MQTT protocol is supported by default.

MQTT broker

ApsaraMQ for MQTT The MQTT broker is used as a server node to interact with MQTT clients and ApsaraMQ for 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

ApsaraMQ 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

Solution architecture shows the architecture of the audio/video communication solution.

As shown in Solution architecture, 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.

Highlights

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

• Service capabilities are scalable.
  • ApsaraMQ for MQTT and Alibaba Cloud RTC can be used on demand and dynamically scaled up to handle burst traffic peaks.
• Network coverage is widespread.
  • ApsaraMQ 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.
  • ApsaraMQ for MQTT supports SSL/TLS encryption and media streams support SRTP protection.

Data interaction

Data flows The presentation is based on ApsaraMQ 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 ApsaraMQ for MQTT, ApsaraMQ for RocketMQ and Real-Time Communication RTC services.

As shown in Data flows, 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 ApsaraMQ for MQTT route to ApsaraMQ for 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 ApsaraMQ for RocketMQ, after ApsaraMQ 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 ApsaraMQ 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. ApsaraMQ for MQTT plays the signaling role in audio/video conferencing scenarios.

Precautions

The preceding process briefly describes how to use ApsaraMQ 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 ApsaraMQ for MQTT, ApsaraMQ for RocketMQ and Real-Time Communication (RTC) documents.

Where use ApsaraMQ 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 ApsaraMQ 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 ApsaraMQ 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 ApsaraMQ 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 ApsaraMQ 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.