Communication method, communication device and computer readable storage medium

Abstract

The invention provides a communication method, a communication device and a computer readable storage medium, relates to the field of communication, and can compress a message header based on flow characteristics of a voice data flow so as to reduce the length of a voice message. The communication method comprises the following steps: sending a first message of a service to a receiving end; the message header of the first message comprises a first field, and the first field is a field contained in a Query User Data Protocol (QUIC) Internet Connection Protocol, or the first field is a field contained in a Real-time Transport Protocol (RTP) format; sending a second message of the service to a receiving end, wherein the second message and the first message belong to the same stream; the message header of the second message comprises a second field, and the second field and the first field indicate the same content; wherein the length of the second field is smaller than that of the first field. The embodiment of the invention is applied to communication.

Description

A communication method, a communication device, and a computer-readable storage medium Technical Field

[0001] This application relates to the field of communications, and more particularly to a communication method, a communication device, and a computer-readable storage medium. Background Technology

[0002] Real-time communication (RTC) systems are audio and video communication systems that achieve real-time interaction based on Internet Protocol (IP) technology.

[0003] RTC can be applied to various scenarios such as video calls, online meetings, interactive classrooms, and applications (APPs). When an RTC system conducts a real-time voice call (hereinafter referred to as a call), the sending end (the calling device) transmits voice messages to the receiving end (the called device). However, when users make calls in extremely weak network environments, such as when entering or exiting elevators or underground parking garages where network signal coverage is poor, insufficient bandwidth often leads to voice messages being dropped, resulting in issues such as missing words and call interruptions.

[0004] To address these issues, one approach is to compress the payload fields used to carry voice data in the voice message using a higher compression rate; another approach is to remove invalid or redundant fields from the content carried in a single voice message to reduce the size of the voice message and decrease its bandwidth usage.

[0005] However, even with one or more of the methods mentioned above, problems such as dropped words and call interruptions still exist in the RTC system. Summary of the Invention

[0006] Embodiments of this application provide a communication method, a communication device, and a computer-readable storage medium that can compress the header of a voice message based on the flow characteristics of the voice data stream, thereby reducing the length of the voice message, reducing the bandwidth occupied by the voice message transmission, and effectively improving the user experience.

[0007] Firstly, a communication method is provided. This communication method includes: sending a first message of a service to a receiving end; the header of the first message includes a first field, which is a field included in the Quick User Datagram Protocol Internet Connections (QUIC) protocol, or the first field is a field included in the Real-Time Transport Protocol (RTP) format; sending a second message of the service to the receiving end, the second message and the first message belonging to the same stream; the header of the second message includes a second field, the second field indicating the same content as the first field; wherein the length of the second field is less than the length of the first field.

[0008] This communication method can be executed by the communication device at the sending end.

[0009] In this communication method, for two messages corresponding to the same stream (i.e., the first message and the second message), the fields indicating the same content (i.e., the first field and the second field) have different lengths. The second field in the second message contains compressed content. Thus, compared to the first field in the first message, this method effectively reduces the length of the second message, thereby reducing the bandwidth required for message transmission and avoiding packet loss or communication interruptions due to insufficient bandwidth resources, effectively improving the user experience.

[0010] In one possible implementation, according to the relevant protocol, the content indicated by the first and second fields may exhibit a certain pattern of change (e.g., the content remains unchanged across multiple messages). This allows the receiving end to recover the uncompressed content of the second field based on this pattern, even if the content of the second field is compressed.

[0011] Overall, this communication method reduces voice word loss and call interruptions while ensuring normal service transmission.

[0012] In one possible implementation, the content indicated by the first field and the content indicated by the second field include at least one of the following: timestamp, sequence number, and synchronization source (SSRC) identifier.

[0013] In this implementation, the content indicated by the first field and the content indicated by the second field are at least one of the following: timestamp, sequence number, and synchronization source SSRC identifier. Specifically, according to the RTP protocol format, the sequence number in multiple packets within the same stream will increment, and the timestamp will increment at intervals. For example, the synchronization source SSRC identifier in multiple packets within the same stream will remain unchanged. In this way, the receiving end can recover the received packets based on this protocol format, thereby ensuring the normal transmission of services.

[0014] Optionally, the content indicated by the first field and the content indicated by the second field may also be the content specified by other protocol formats, and this application does not limit this.

[0015] In one possible implementation, the communication method further includes: sending a third message to the receiving end, the third message carrying first information, the first information indicating at least one of the following: the protocol version supported by the sending end for compression, the compression method supported by the sending end, and whether the sending end supports compression of the message header. The compression method includes: deleting a first field, and / or replacing the first field with a second field, the second field indicating the first information, the length of the second field being less than the length of the first field.

[0016] This implementation can be performed by the communication device at the sending end. By sending a third message carrying first information indicating its own performance to the receiving end, the device can inform the receiving end of the relevant parameters indicating its own performance.

[0017] Optionally, the relevant parameters indicating the device performance of the sending end's communication device include: the protocol version supported by the sending end's communication device, the compression method supported by the sending end's communication device, and whether the sending end's communication device supports compression of the message header.

[0018] In one possible implementation, if the contents indicated by the first and second fields remain unchanged, deleting the first field can compress the second message. Alternatively, if the contents indicated by the second field change relative to the first field, compression of the second message can be achieved by replacing the first field with the second field, making the length of the second field shorter than the length of the first field.

[0019] Therefore, when the sending and receiving ends transmit services, the transmission can be based on the performance of the sending end's communication equipment. Through this scheme, the sending end can promptly inform the receiving end of its equipment performance by sending corresponding messages, thus ensuring the quality of service transmission and consequently, call quality.

[0020] In one possible implementation, the above communication method further includes: receiving a fourth message from the receiving end, the fourth message carrying second information, the second information being used to indicate at least one of the following: the protocol version supported by the receiving end for compression, the compression method supported by the receiving end, and whether the receiving end supports compression of the message header.

[0021] This implementation can be performed by the communication device at the sending end. By receiving a fourth message from the receiving end carrying second information indicating the device performance of another communication device, the device performance of the other communication device can be obtained.

[0022] Optionally, parameters indicating the device performance of the receiving end's communication equipment include: the protocol version supported by the receiving end's communication equipment, the compression method supported by the receiving end's communication equipment, and whether the receiving end's communication equipment supports compression of the message header. Based on this, when the sending end and the receiving end conduct service transmission, the sending end can transmit voice messages to the receiving end based on the receiving end's device performance. Through the above scheme, the sending end can obtain the device performance of the receiving end's communication equipment based on the corresponding messages received from the receiving end, thereby performing service transmission based on the receiving end's communication equipment performance, ensuring call quality.

[0023] In one possible implementation, a second message is sent based on a compression algorithm of the Robust Header Compression (ROHC) protocol.

[0024] In the above scheme, the content indicated by the second field can be compressed using the compression algorithm of the ROHC protocol, making the length of the second field shorter than the length of the first field, thereby generating and sending the second message. Of course, the second field in the second message can be compressed based on other protocol formats or through other compression methods, and the embodiments of this application do not limit this.

[0025] Secondly, a communication method is provided for a relay device connected between a sender and a receiver. The communication method includes: sending a first service message to the receiver; the header of the first message includes a first field, which is a field included in the QUIC protocol, or a field included in the RTP protocol format; receiving a fifth service message from the sender; the fifth message and the first message belong to the same stream; the header of the fifth message includes a third field, which indicates the same content as the first field, and the length of the third field is less than the length of the first field; sending a second service message to the receiver, the second message and the first message belonging to the same stream; the header of the second message includes a second field, which indicates the same content as the first field; wherein the length of the second field is less than the length of the third field.

[0026] This communication method can be performed by a relay device connected between the sending end and the receiving end.

[0027] In this communication method, the relay device can receive a first message and a fifth message whose header content has been compressed. Specifically, the relay device can recover the uncompressed third field by decompressing the received fifth message. Furthermore, the relay device can also compress the header of the second message, that is, compress the second field, and send the compressed second message. Therefore, the above method can further save the bandwidth occupied by service transmission between the sending and receiving ends.

[0028] Optionally, the relay device may compress the second field in the second message using a different method than it compresses the third field in the received fifth message. Therefore, in scenarios where the compression capability supported by the sending communication device does not match the decompression capability of the receiving communication device, the above method can ensure normal service transmission.

[0029] Thirdly, a communication method is provided for a receiving end. The communication method includes: receiving a first message of a service from a sending end; the header of the first message includes a first field, which is a field included in the QUIC protocol, or the first field is a field included in the RTP protocol format; receiving a second message of a service from the sending end, the second message and the first message belonging to the same stream; the header of the second message includes a second field, the second field indicating the same content as the first field; wherein the length of the second field is less than the length of the first field.

[0030] This communication method can be executed by the communication device at the receiving end.

[0031] In this communication method, the receiving end can receive both the second message and the compressed second message. Specifically, based on the received first message, the content indicated by the first field can be obtained. Furthermore, by decompressing the second message, the content indicated by the second field can be recovered. Therefore, this communication method, based on the received uncompressed and compressed messages, can recover the content indicated by the corresponding fields, thus ensuring both call quality and normal service transmission.

[0032] In one possible implementation, the content indicated by the first field and the content indicated by the second field include at least one of the following: timestamp, serial number.

[0033] In one possible implementation, the above communication method further includes: receiving a fourth message from the sender, the fourth message carrying second information, the second information being used to indicate at least one of the following: the protocol version supported by the sender for compression, the compression method supported by the sender, and whether the sender supports compression of the message header; wherein the compression method includes: deleting a first field, and / or replacing the first field with a second field, the second field being used to indicate the first information, and the length of the second field being less than the length of the first field.

[0034] In one possible implementation, the above communication method further includes: sending a fifth message to the sending end, the fifth message carrying third information, the second information being used to indicate at least one of the following: the protocol version supported by the receiving end for compression, the compression method supported by the receiving end, and whether the receiving end supports compression of the message header.

[0035] In one possible implementation, the receiving end's communication device decompresses the second message based on the ROHC protocol's compression algorithm.

[0036] Fourthly, a communication device is provided. The communication device includes: a processor and a transceiver module coupled to the processor; wherein the processor is configured to execute computer instructions to control the transceiver module to perform the communication method as described in any one of the first, second, and third aspects.

[0037] Fifthly, a computer-readable storage medium is provided. This computer-readable storage medium stores a computer program or instructions that, when read and executed by a computer, cause the computer to perform the communication method as described in any one of the first, second, and third aspects.

[0038] Sixthly, a computer program product comprising instructions is provided. The computer program product includes: computer program code, which, when executed on a computer, enables the computer to perform the communication method as described in any one of the first, second, and third aspects.

[0039] The technical effects of any of the possible design methods in the third to sixth aspects mentioned above can be compared with the technical effects of different design methods in the first and second aspects mentioned above, and will not be elaborated here. Attached Figure Description

[0040] Figure 1 is a schematic diagram of a real-time communication system provided in an embodiment of this application;

[0041] Figure 2 is a schematic diagram of a voice message transmission process provided in an embodiment of this application;

[0042] Figure 3 is an architecture diagram of a real-time communication system provided in an embodiment of this application;

[0043] Figure 4 is a schematic diagram of a voice message provided in an embodiment of this application;

[0044] Figure 5 is an architecture diagram of a real-time communication system provided in another embodiment of this application;

[0045] Figure 6 is a schematic diagram of a communication method provided in an embodiment of this application;

[0046] Figure 7 is a schematic diagram of voice message compression provided in an embodiment of this application;

[0047] Figure 8 is a schematic diagram of a voice message decompression method provided in an embodiment of this application;

[0048] Figure 9 is a schematic diagram of a communication method provided in another embodiment of this application;

[0049] Figure 10 is a schematic diagram of a communication method provided in another embodiment of this application;

[0050] Figure 11 is a schematic diagram of a communication device provided in an embodiment of this application. Detailed Implementation

[0051] This application will present various aspects, embodiments, or features relating to systems that may include multiple devices, components, modules, etc. It should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Furthermore, combinations of these approaches may also be used. It should be noted that in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0052] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0053] The RTC system is an IP-based audio and video communication system that enables real-time interaction and can be applied to various scenarios such as video calls, online meetings, interactive classrooms, and mobile apps.

[0054] For example, referring to Figure 1, a schematic diagram of a possible real-time communication system is provided, illustrating an RTC system applied to real-time voice calls (i.e., calls). Specifically, as shown in Figure 1, the RTC system includes: a calling device deployed at the sending end (referred to as the calling device, referring to calling device 101 in Figure 1), a called device deployed at the receiving end (referred to as the called device, referring to called device 102 in Figure 1), and a selective forwarding unit (SFU) (referring to SFU 103 in Figure 1) connecting the calling device 101 and the called device 102. The calling device 101 at the sending end is used to send voice during the call, the called device 102 at the receiving end is used to receive voice from the calling device 101 during the call, and the SFU 103 is used to forward the received voice during the call.

[0055] In one possible implementation, the calling party 101 and the called party 102 are terminal devices; these terminal devices can be different types of devices such as mobile phones, tablets, smart TVs, and computers. Optionally, SFU 103 is implemented by a cloud server. Of course, the aforementioned calling party 101, called party 102, and SFU 103 can also be implemented by other communication devices capable of performing similar functions, and the embodiments of this application constitute a limitation. It is not difficult to understand that, for ease of explanation, only the architecture shown in Figure 1 is used as an example here, and it should not be construed as limiting the embodiments of this application.

[0056] Specifically, referring to Figure 1, during a call, the calling end 101 generates and sends a voice message, which is then transmitted to SFU 103. SFU 103 forwards the received voice message, which is then transmitted to the receiving end. The called end 102 receives the voice message.

[0057] Based on the architecture shown in Figure 1, and exemplarily with reference to Figure 2, a schematic diagram of a voice message transmission process is illustrated. As shown in Figure 2, this transmission process involves the calling party 101, the called party 102, and the SFU 103. It is understood that, for ease of explanation, the architecture shown in Figure 2 is used here only as an example and should not be construed as limiting the embodiments of this application.

[0058] Specifically, the transmission process includes:

[0059] Caller 101: First, it collects voice data, then encodes the voice data, and finally assembles it to generate a voice message.

[0060] SFU 103: Forward the received voice message from the calling party 101 to the called party 102.

[0061] Called 102: Decodes the received voice message and plays the voice message.

[0062] Based on Figures 1 and 2, and exemplarily referring to Figure 3, an embodiment of this application provides an architecture diagram of a real-time communication system, illustrating the process of transmitting voice messages during a call in an RTC system. Referring to Figure 3, this transmission process involves the calling party 101, the called party 102, and the SFU 103. It is understood that, for ease of explanation, the architecture shown in Figure 3 is used here only as an example and should not be construed as limiting the embodiments of this application.

[0063] Specifically, the transmission process includes:

[0064] The calling 101 process sequentially collects, encodes, and encapsulates the data. Specifically, the calling 101 first collects voice data, then encodes the voice data, and finally encapsulates it to generate a voice message.

[0065] SFU 103 sequentially decapsulates and recapsulates the received voice message from caller 101. Specifically, SFU 103 decapsulates the received voice message from caller 101, recapsulates it, and sends it to callee 102. In one possible implementation, SFU 103 can also perform corresponding statistics based on the received voice message (see the dashed box in SFU 103 in Figure 3). For example, SFU 103 decapsulates the received voice message from caller 101, performs statistics on the network performance of the RTC system based on the information obtained after decapsulation, recapsulates it to generate a voice message, and sends it to callee 102.

[0066] The called party 102 sequentially performs decryption, decoding, and playback. The called party 102 decrypts the received voice message to obtain the encoded voice data. The called party 102 then decodes the voice data to play the audio.

[0067] Based on the above, the voice data collected by the calling party 101 can be transmitted to the called party 102 and played, that is, communication is realized between the calling party and the called party.

[0068] For example, referring to Figure 4, a schematic diagram of a possible voice message is provided. Specifically, as shown in Figure 4, the voice message includes: multiple message headers and a payload field; wherein, the payload field is used to carry the encoded voice data. The message headers sequentially include: IP header, User Datagram Protocol (UDP) header, QUIC header, and RTP header.

[0069] It is easy to understand that, for ease of explanation, the architecture shown in Figure 1 is used here as an example only, and should not be construed as limiting the embodiments of this application. Based on the above, the calling and called parties in the RTC system can communicate by transmitting voice messages.

[0070] Based on the above architecture, when making a call, if the user (such as the caller or the called party) is in an extremely weak network environment (such as when entering or exiting an elevator, underground parking lot, or other places with poor network signal coverage), the voice message will often be dropped during transmission due to insufficient bandwidth, resulting in problems such as missing words and call interruption.

[0071] To improve call quality and ensure a better user experience, it's necessary to further reduce the size (usually referring to length) of voice messages, thereby reducing the bandwidth required for transmission. Typically, the size of voice messages can be reduced in the following ways.

[0072] Specifically, it includes the following two methods:

[0073] Method 1:

[0074] The payload field (i.e., the field that carries voice data) in the voice message is compressed using a higher compression ratio to reduce the size of the voice message.

[0075] The above scheme can reduce the size of the payload field in the voice message, thereby reducing the overall size of the voice message to some extent. However, this scheme only compresses the payload portion of the voice message, and the size of multiple message headers constitutes a considerable proportion of the voice message. Therefore, the above scheme cannot effectively reduce the overall size of the voice message, and the overall voice message cannot achieve the optimal compression rate.

[0076] Method 2:

[0077] To reduce the size of voice packets, duplicate information in the QUIC or RTP headers is compressed. Typically, based on the RTP protocol, the RTP header includes network statistics; similarly, based on the QUIC protocol, the QUIC header also includes network statistics. Therefore, this duplicate statistical information can be either included in the QUIC or RTP header, meaning that duplicate information in the QUIC or RTP headers of the voice packet is compressed (e.g., deleted).

[0078] The above scheme avoids duplicate information in the QUIC and RTP headers of voice messages, thus reducing the size of voice messages to some extent. However, the above scheme only compresses duplicate statistical information in the two headers of a single voice message and does not completely eliminate redundancy between voice messages (e.g., duplicate information exists between voice messages).

[0079] Therefore, even with one or more of the methods mentioned above, problems such as missing words in voice messages and call interruptions still exist in the RTC system.

[0080] To address the aforementioned issues, embodiments of this application provide a communication method that enables an RTC system to compress the header of voice packets based on the flow characteristics of the voice data stream during a call. Based on the architecture shown in Figure 3, and exemplarily referring to Figure 5, embodiments of this application provide an architecture diagram of a real-time communication system. As shown in Figure 5, this transmission process involves the calling party 101, the called party 102, and the SFU 103.

[0081] In one possible implementation, as shown in Figure 5, the calling party 101 and the called party 102 are terminal devices; these terminal devices can be different types of devices such as mobile phones, tablets, smart TVs, and computers. Optionally, the SFU 103 is implemented by a cloud server. Of course, the aforementioned calling party 101, called party 102, and SFU 103 can also be implemented by other communication devices capable of performing similar functions; the embodiments in this application constitute limitations.

[0082] It is easy to understand that, for ease of explanation, the architecture shown in Figure 5 is used here as an example only, and should not be used to limit the embodiments of this application.

[0083] Based on Figure 3, this communication method compresses the header of voice messages by adding corresponding functions to the calling 101, called 102, and SFU 103 respectively (refer to the underlined boxes in the calling 101, called 102, and SFU 103 in Figure 5).

[0084] Specifically, as shown in Figures 3 and 5, it includes:

[0085] The calling party 101 will still collect, encode, and encapsulate the data in sequence to generate a voice message.

[0086] However, in the communication method provided by the embodiments of this application, the caller 101 will compress the header of the generated voice message.

[0087] SFU 103 still sequentially decapsulates and recapsulates the data. However, based on the communication method provided in the embodiments of this application, SFU 103 first decompresses the header of the received voice message, and then sequentially decapsulates and recapsulates it. Furthermore, after SFU 103 recapsulates and generates a voice message, it compresses the header of the generated voice message.

[0088] For example, SFU 103 decompresses the header of the received voice message from caller 101 to recover the uncompressed voice message. SFU 103 then decapsulates the uncompressed voice message and performs statistical analysis on the network performance of the RTC system based on the information obtained after decompression. It then recapsulates the voice message, compresses its header, and sends it to callee 102.

[0089] The called party 102 will still proceed with unblocking, decoding, and playback in sequence.

[0090] However, in the communication method provided by the embodiments of this application, the called party 102 first decompresses the header of the received voice message, then deseals the received voice message, and then realizes voice playback.

[0091] Referring to Figure 5, the following embodiments will specifically describe the communication method provided by the embodiments of this application. For example, referring to Figure 6, an embodiment of this application provides a schematic diagram of a communication method. This communication method is capable of... The communication method provided by the embodiments of this application will now be described in detail with reference to Figure 6.

[0092] It should be noted that Figure 6 is used as an example to illustrate the communication method provided in this application embodiment through the sending end, relay device, and receiving end, and should not be construed as limiting the communication method provided in this application embodiment. For ease of explanation, referring to Figure 5, the following embodiments are described with the sending end as the calling party 101, the relay device as SFU 103, and the receiving end as the called party 102 as an example, and should not be construed as limiting the embodiments of this application. The communication method includes steps 601 to 606, which are described in detail below.

[0093] Step 601: The sending end sends the first message to the receiving end.

[0094] The header of the first message includes a first field, which is either a field included in the QUIC protocol or a field included in the RTP protocol format.

[0095] Specifically, referring to Figure 5, the calling party 101 sends a first message to the called party 102. Correspondingly, the called party 102 receives the first message. Optionally, the first message can be implemented using the voice message format shown in Figure 4.

[0096] In one possible implementation, during the transmission of the first message sent by the calling party 101 to the called party 102, the first message is received by the SFU 103. The SFU 103 forwards the first message received from the calling party 101 to the called party 102.

[0097] In one possible implementation, the sending end first collects voice data, then encodes the voice data, and finally encapsulates it to generate a first message and sends it. Of course, the sending end can also obtain the first message through other means, and the embodiments of this application do not limit this.

[0098] In one possible implementation, as shown in Figure 5, the called party 102 at the receiving end, based on the first message and the second message, recovers the uncompressed content indicated by the second field by decapsulating the received second message.

[0099] Step 602: The sending end sends a second message to the receiving end.

[0100] The second message and the first message belong to the same stream; the header of the second message includes a second field, which indicates the same content as the first field. The length of the second field is less than the length of the first field.

[0101] Specifically, referring to Figure 5, the calling party 101 sends a second message to the called party 102. Optionally, the second message is implemented using the voice message format shown in Figure 4.

[0102] In one possible implementation, during the transmission of the second message sent by the calling party 101 to the called party 102, the second message is received by the SFU 103. The SFU 103 forwards the second message received from the calling party 101 to the called party 102.

[0103] Generally speaking, the header of a voice message is used to carry the corresponding content (such as synchronization information, timestamps, etc.) according to the definition of the corresponding protocol.

[0104] Optionally, referring to Figure 4, for multiple voice messages in the same stream, the content indicated by the corresponding fields in the multiple voice messages may exhibit regular changes; or, the content indicated by the corresponding fields in the headers of multiple messages may be the same. Based on this, for the first message and the second message, the content indicated by the corresponding fields in the header can be compressed using appropriate compression methods.

[0105] Optionally, the compression method includes: deleting the first field, and / or replacing the first field with a second field, the second field being used to indicate the first information, the length of the second field being less than the length of the first field.

[0106] For example, based on the definition of the RTP protocol, the RTP header in a voice message includes an SSRC field that indicates the synchronization source identifier. The SSRC identifier indicated by the SSRC field remains unchanged within the same stream. Thus, the first field in the header of the first message is the SSRC field, and the second field in the header of the second message is the SSRC field; both the first and second fields indicate the same content.

[0107] Based on this, and in conjunction with steps 601 and 602 above, the compression method of the sending end for the second field in the second message is to delete the first field that indicates the same content, that is, to delete the second field in the second message.

[0108] In one possible implementation, the content indicated by the second field and the first field changes in an incremental pattern.

[0109] Based on this, and in conjunction with steps 601 and 602 above, the compression method of the second field in the second message by the sending end is to replace the content indicated by the second field with: the amount of change of the content indicated by the second field in the second message relative to the content indicated by the first field and the corresponding identifier.

[0110] Taking the RTP header of a voice message as an example, the RTP header includes: sequence number and timestamp.

[0111] For example, the first field in the header of the first message and the second field in the header of the second message both indicate a sequence number. Typically, over a period of time (e.g., a cycle), the sequence numbers indicated by the corresponding fields in multiple messages belonging to the same flow increase incrementally. Specifically, the second field in the header of the second message includes: the increment of the sequence number indicated by the second field relative to the sequence number indicated by the first field, and an identifier indicating that the increment is a sequence number.

[0112] For example, the first field in the header of the first message and the second field in the header of the second message both indicate timestamps. Typically, over a period of time (e.g., a cycle), the timestamps indicated by corresponding fields in multiple messages belonging to the same flow increase at intervals. Specifically, the second field in the header of the second message includes: the interval increment of the sequence timestamp indicated by the second field relative to the timestamp indicated by the first field, and an identifier indicating that this interval increment is a timestamp.

[0113] It is easy to understand that, based on different protocols, there may be multiple fields in the message header that exhibit regular changes in content. Furthermore, the content indicated by fields in the message header may also exhibit other possible regular changes. This explanation uses only the SSRC identifier, sequence number, and timestamp as examples to illustrate the communication method provided in the embodiments of this application, and should not be construed as limiting the embodiments of this application.

[0114] Based on the structure of the voice message shown in Figure 4, in one possible implementation, the IP header of the voice message includes 20 bytes, the UDP header includes 8 bytes, the QUIC header includes 12 bytes, the RTP header includes 12 bytes, and the payload field includes 15 bytes. For example, referring to Figure 7, an embodiment of this application provides a schematic diagram of message compression.

[0115] Specifically, as shown in Figure 7, if the QUIC header and RTP header in the second message are compressed using the compression method described above, the compressed content can be carried in the same ROHC field.

[0116] Optionally, the compression algorithm used in this compression process is the same algorithm used to compress RTP headers in protocols such as ROHC. This way, the compression method only compresses the application layer header, allowing the compressed voice messages to be adapted to the current infrastructure (such as currently deployed cloud servers), thus eliminating the need to modify the infrastructure below the network application layer.

[0117] In one possible implementation, the sending end first collects voice data, then encodes the voice data, encapsulates it to generate a second message, and then compresses the second field in the header of the generated second message using a compression method before sending it. Of course, the sending end can also obtain the second message through other methods, and the embodiments of this application do not limit this.

[0118] Accordingly, for the receiving end, the above communication method further includes steps 604 and 605. Any communication device at the receiving end can be used to implement these steps.

[0119] Step 603: The receiving end receives the first message from the sending end.

[0120] The header of the first message includes a first field, which is either a field included in the QUIC protocol or a field included in the RTP protocol format.

[0121] Specifically, as shown in Figure 5, the called party 102 receives the first message of the service from the calling party 101.

[0122] Step 604: The receiving end receives the second message from the sending end.

[0123] The second message and the first message belong to the same stream; the header of the second message includes a second field, which indicates the same content as the first field. The length of the second field is less than the length of the first field.

[0124] Specifically, as shown in Figure 5, the called party 102 receives the second message of the service from the calling party 101.

[0125] In one possible implementation, based on the received first message, the receiving end can obtain the information carried by the first message. For example, the information indicated by the first field of the first message. Furthermore, based on the received second message and the corresponding protocol format, the receiving end can recover the specific content indicated by the second field, which contains the same information as the first field, by decompressing the second message.

[0126] In one possible implementation, if the content indicated by the second field is the same as the content indicated by the first field, then the content indicated by the second field of the second message has been deleted. In this way, the receiving end can obtain the content indicated by the first field based on the received first message. Furthermore, based on the principle that the content indicated by the second field does not change compared to the content indicated by the first field, the deleted content of the second field can be recovered, thus achieving decompression of the second message.

[0127] In other examples, the content indicated by the second field changes systematically compared to the content indicated by the first field, indicating that the content indicated by the second field in the second message has been replaced. Thus, the receiving end can retrieve the content indicated by the first field based on the received first message. Furthermore, based on the systematic change in the content indicated by the second field compared to the first field, the replaced content in the second field can be recovered, enabling decompression of the second message.

[0128] Referring to Figure 7, and exemplarily to Figure 8, an embodiment of this application provides a schematic diagram of message decompression. Specifically, if the compressed second field is replaced with the ROHC field, the content indicated by the second field can be obtained by decompressing the ROHC field, and the QUIC header and RTP header of the second message can be recovered.

[0129] Therefore, based on steps 601 to 604 above, when the sending end and receiving end transmit services, the header of the voice message can be compressed based on the flow characteristics of the voice data stream. In this way, in weak network scenarios such as bandwidth limitation, the above solution can reduce the bandwidth occupied by the message when it is transmitted between the calling and called parties, ensure the continuity of the call, effectively avoid problems such as lost characters and call interruptions, and thus effectively improve the user experience.

[0130] It is easy to understand that in steps 601 to 604 above, the description is based on the sending end (i.e., the calling end 101) and the receiving end (the called end 102).

[0131] Typically, a forwarding device is also connected between the sending and receiving ends. For example, as shown in Figure 5, an SFU 103 is connected between the calling 101 and the called 102.

[0132] Optionally, the transfer device (i.e., SFU 103) can also be used to perform steps 601 and 602 above. Based on this, for the transfer device, before performing step 602 above, it also includes performing step 605 below (as shown by the dashed box in Figure 6).

[0133] Step 605: Receive the fifth message from the sending end. This fifth message belongs to the same flow as the first message. The header of the fifth message includes a third field, which indicates the same content as the first field, but the length of the third field is shorter than the length of the first field. Specifically, referring to Figure 5, SFU 103 receives the fifth message from the calling 101.

[0134] Further, before step 605, when the relay device is used to perform step 602, that is, SFU 103 sends a second message to the called party 102. The length of the second field of the second message is less than the length of the third field of the fifth message.

[0135] In one possible implementation, in conjunction with step 605, the relay device decompresses the received fifth message to recover the uncompressed fifth message and obtains the content indicated by the third field. Further, in conjunction with step 602, the relay device compresses the content indicated by the third field using a corresponding compression method to generate a second message. Then, the relay device sends the second message to the receiving end.

[0136] In this way, the relay device can send a second message compressed using the corresponding compression method based on the received compressed fifth message. Of course, the compression method used in the fifth message can be the same as or different from the compression method used in the second message; the embodiments of this application do not limit this. Thus, the relay device can generate and send another compressed message based on the received compressed message.

[0137] Therefore, based on steps 601, 602, and 605 above, the bandwidth occupied by messages during transmission between the calling party and the SFU, and between the SFU and the called party, can be further reduced. This further reduces the bandwidth occupied by services during transmission between the sending end and the relay equipment, and between the relay equipment and the called party, thus ensuring the quality of service transmission.

[0138] It should be noted that the embodiments of this application do not limit the type or structure of the sending and receiving devices. In other examples, the sending and receiving devices described above can also be implemented by other devices capable of performing similar functions, and this application does not limit them.

[0139] In the following embodiments of this application, the communication method provided by the embodiments of this application will be described in conjunction with specific application scenarios of the above-described communication method. For example, referring to FIG9, an embodiment of this application provides a schematic diagram of a possible communication method, illustrating the process of applying the above-described communication method to an RTC system.

[0140] The communication method provided in the embodiments of this application will be described in detail below with reference to Figure 9. It should be noted that the architecture shown in Figure 5 is used as an example here to describe the communication method provided in the embodiments of this application through the calling party 101, the called party 102, and the SFU 103, and this should not be construed as limiting the communication method provided in the embodiments of this application.

[0141] The communication method provided in the embodiments of this application includes two stages: a negotiation stage and a voice transmission stage. Specifically, the communication method includes steps 801 to 817, wherein the negotiation stage includes steps 801 to 808, and the voice transmission stage includes steps 809 to 817. The specific description of this communication method is as follows.

[0142] Negotiation phase:

[0143] In one possible implementation, the calling party 101 is used to perform steps 801 and 804 below, and the SFU 103 is used to perform steps 802 and 803 below.

[0144] Step 801: Caller 101 sends a third message to SFU 103.

[0145] The third message carries the first information.

[0146] Optionally, the first information is used to indicate at least one of the following: the protocol version supported by the calling 101 for compression, the compression method supported by the calling 101, and whether the calling 101 supports compression of the message header.

[0147] Step 802: SFU 103 receives the third message sent by the calling party 101.

[0148] Thus, through steps 801 to 802 above, the calling party 101 can promptly inform the SFU 103 of its own equipment performance by sending corresponding messages to the SFU 103, so that the SFU 103 can perform service transmission based on the received information about the equipment performance of the other party. For example, transmitting voice messages.

[0149] Step 803: SFU 103 sends the fourth message to the calling party 101.

[0150] The fourth message carries the second information.

[0151] Optionally, the second information is used to indicate at least one of the following: the protocol version supported by SFU 103 for compression, the compression method supported by SFU 103, and whether SFU 103 supports compression of the message header.

[0152] Step 804: Caller 101 receives the fourth message sent by SFU 103.

[0153] Thus, through steps 803 to 804 above, SFU 103 can promptly inform the calling party 101 of its own device performance by sending a corresponding message to the calling party 101, so that the calling party 101 can perform service transmission based on the received information about the device performance of the calling party. For example, transmitting voice messages.

[0154] Similarly, in conjunction with steps 801 to 804 above, SFU 103 is used to perform steps 805 and 808 below, and the called party 102 is used to perform steps 806 and 807 below.

[0155] Step 805: SFU 103 sends the sixth message to the called party 102.

[0156] The sixth message carries the third piece of information.

[0157] Optionally, the third information is used to indicate at least one of the following: the protocol version supported by SFU 103 for compression, the compression method supported by SFU 103, and whether SFU 103 supports compression of the message header.

[0158] Step 806: The called party 102 receives the sixth message sent by SFU 103.

[0159] Step 807: The called party 102 sends the seventh message to SFU 103.

[0160] The seventh message carries the fourth piece of information.

[0161] Optionally, the fourth information is used to indicate at least one of the following: the protocol version supported by the called 102 for compression, the compression method supported by the called 102, and whether the called 102 supports compression of the message header.

[0162] Step 808: SFU 103 receives the seventh message sent by the called party 102.

[0163] Through steps 805 to 808 above, the called party 102 and SFU 103 can promptly inform the other party of their own equipment performance, so that the other party can determine its own equipment performance based on the received message.

[0164] Thus, based on steps 801 to 808 above, the calling device 101 and SFU 103, and SFU 103 and the called device 102, can obtain the device performance of the other side and negotiate the compression method for message compression during the voice transmission phase. This ensures the quality of message transmission and, consequently, the quality of the call.

[0165] Voice transmission stage:

[0166] Step 809: Caller 101 sends the first message to SFU 103.

[0167] In one possible implementation, the calling unit 101 first collects voice data, then encodes the voice data, and finally encapsulates it to generate a first message and sends it. Of course, the calling unit 101 can also obtain the first message in other ways, and the embodiments of this application do not limit this.

[0168] Step 810: SFU 103 receives the first message sent by the calling party 101.

[0169] Step 811: Caller 101 sends a second message to SFU 103.

[0170] In one possible implementation, the calling party 101 determines the compression method of the second field of the second message based on the device information of SFU 103 obtained during the above negotiation process (e.g., the compression method supported by SFU 103), and obtains and sends the second message to SFU 103.

[0171] Step 812: SFU 103 receives the second message sent by the calling party 101.

[0172] Similarly, in conjunction with steps 809 to 812 above, SFU 103 is used to perform steps 813 and 815 below, and the called party 102 is used to perform steps 814 and 816 below:

[0173] Step 813: SFU 103 sends the eighth message to the called party 102.

[0174] In one possible implementation, SFU 103 first acquires voice data, then encodes the voice data, and finally encapsulates it to generate the eighth message and sends it. Of course, SFU 103 can also acquire the eighth message in other ways, and the embodiments of this application do not limit this.

[0175] Step 814: The called party 102 receives the eighth message sent by SFU 103.

[0176] Step 815: SFU 103 sends the ninth message to the called party 102.

[0177] Step 816: The called party 102 receives the ninth message sent by SFU 103.

[0178] Optionally, the called party 102 can obtain the uncompressed ninth message by decompressing and decoding the received ninth message, thereby obtaining voice data, playing the voice, and making a call.

[0179] In conjunction with the communication method described in Figure 6, steps 809 to 816 can be referred to steps 601 to 605 shown in Figure 6, and will not be repeated here.

[0180] It should be noted that the SFU 103 can also perform network performance statistics for the RTC based on the received packets.

[0181] Based on this, the above communication methods also include:

[0182] Step 817, SFU 103 Network Statistics.

[0183] Specifically, SFU 103 first decompresses and decodes the received message to recover the original, uncompressed message. Further, SFU 103 performs appropriate processing (e.g., calculations) to statistically analyze relevant network performance parameters, thereby determining the network status of the entire call system.

[0184] Based on steps 801 to 817 above, when the calling party and the SFU, and the SFU and the called party are communicating, they can each compress and decompress the messages, thereby effectively reducing the bandwidth occupied by the messages during transmission throughout the system. This solves the problem of high temporal redundancy of the voice header and impaired voice call experience in scenarios with limited bandwidth in weak networks.

[0185] It is easy to understand that, as a device with forwarding capabilities, the SFU 103 can also simply forward the received information without performing any further processing.

[0186] In the following embodiments of this application, the communication method provided by the embodiments of this application will be described in conjunction with specific application scenarios of the above-described communication method. Based on Figures 6 and 9, and exemplarily referring to Figure 10, an embodiment of this application provides a schematic diagram of a possible communication method, illustrating the application of the above-described communication method in a scenario where SFU 103 only performs forwarding.

[0187] The communication method provided in the embodiments of this application will be described in detail below with reference to Figure 10. It should be noted that the architecture shown in Figure 5 is used as an example to describe the communication method provided in the embodiments of this application through the calling party 101, the called party 102, and the SFU 103, and this should not be construed as limiting the communication method provided in the embodiments of this application.

[0188] Specifically, the communication method described below includes steps 901 to 908, comprising two phases: a negotiation phase and a voice transmission phase. The negotiation phase includes steps 901 to 904, and the voice transmission phase includes steps 905 to 908. The specific details of this communication method are as follows.

[0189] Negotiation phase:

[0190] Step 901: The calling party 101 sends a third message to the called party 102.

[0191] The third message carries the first information.

[0192] Optionally, the first information is used to indicate at least one of the following: the protocol version supported by the calling 101 for compression, the compression method supported by the calling 101, and whether the calling 101 supports compression of the message header.

[0193] Optionally, the calling party 101 first sends a third message to SFU 103, which then forwards the third message sent by the calling party 101 to the called party 102.

[0194] Step 902: The called party 102 receives the third message sent by the calling party 101.

[0195] In one possible implementation, in conjunction with step 901, the called party 102 receives the third message forwarded by SFU 103 from the called party 101.

[0196] Step 903: The called party 102 sends the fourth message to the calling party 101.

[0197] The fourth message carries the fourth piece of information.

[0198] Optionally, the fourth information is used to indicate at least one of the following: the protocol version supported by the called 102 for compression, the compression method supported by the called 102, and whether the called 102 supports compression of the message header.

[0199] Optionally, the called party 102 first sends a fourth message to SFU 103, which then forwards the fourth message sent by the called party 102 to the calling party 101.

[0200] Step 904: The calling party 101 receives the fourth message sent by the called party 102.

[0201] In one possible implementation, in conjunction with step 903, the calling party 101 receives the fourth message forwarded from the called party 102 by SFU 103.

[0202] Voice transmission stage:

[0203] Step 905: The calling party 101 sends the first message to the called party 102.

[0204] Optionally, the calling party 101 first sends a first message to SFU 103, which then forwards the first message sent by the calling party 101 to the called party 102.

[0205] Step 906: The called party 102 receives the first message sent by the calling party 101.

[0206] In one possible implementation, in conjunction with step 905, the called party 102 receives the first message forwarded by the called party 101 from the SFU 103.

[0207] Step 907: The calling party 101 sends a second message to the called party 102.

[0208] Optionally, the calling party 101 first sends a second message to SFU 103, which then forwards the second message sent by the calling party 101 to the called party 102.

[0209] Step 908: The called party 102 receives the second message sent by the calling party 101.

[0210] In one possible implementation, in conjunction with step 907, the called party 102 receives the second message forwarded by SFU 103 from the called party 101.

[0211] Optionally, in conjunction with the communication method described in Figure 6, steps 905 to 908 above can be referred to the communication method shown in Figure 6, which will not be repeated here.

[0212] In other examples, in conjunction with the communication method described in Figure 9, steps 901 to 904 above can be referred to the communication method shown in Figure 9, which will not be repeated here.

[0213] Therefore, based on steps 901 to 908 above, the SFU does not process the received content (e.g., compressed messages) (e.g., decompress and compress), but only forwards the received content. In this way, the calling and called parties can directly negotiate the specific compression method and compress the transmitted messages based on the negotiation result, thereby improving the user's call continuity experience.

[0214] For example, referring to FIG11, an embodiment of this application provides a communication device. Specifically, the communication device includes one or more transceivers 1101 and processors 1102. Detailed descriptions of the transceivers 1101 and processors 1102 can be found in FIG6, FIG9, and FIG10 or the method embodiments shown above, and will not be elaborated here.

[0215] For details regarding the specific terms or steps in the above embodiments, please refer to the descriptions in the above method embodiments; they will not be elaborated upon here.

[0216] In various implementations of the communication device shown in Figure 11, the transceiver may include a receiver and a transmitter. The transceiver performs the transmission functions described above, which may specifically include receiving or transmitting. For example, the receiver performs the function (or operation) of receiving, and the transmitter performs the function (or operation) of transmitting. The transceiver also communicates with other devices / appliances via a transmission medium.

[0217] Optionally, the communication device may further include one or more memories 1103 for storing program instructions and / or data. The memory 1103 is coupled to the processor 1102. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1102 may operate in conjunction with the memory 1103. The processor 1102 can execute program instructions stored in the memory 1103. Optionally, at least one of the above-mentioned memories may be included in the processor.

[0218] This application embodiment does not limit the specific connection medium between the transceiver 1101, processor 1102, and memory 1103. In Figure 11, the memory 1103, processor 1102, and transceiver 1101 are connected via a bus 1104, which is represented by a thick line in Figure 11. The connection methods between other components are only for illustrative purposes and are not intended to be limiting. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 11, but this does not mean that there is only one bus or one type of bus.

[0219] In the embodiments of this application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules within the processor.

[0220] In this application embodiment, the memory may include, but is not limited to, non-volatile memory such as hard disk drive (HDD) or solid-state drive (SSD), random access memory (RAM), erasable programmable read-only memory (EPROM), read-only memory (ROM), or compact disc read-only memory (CD-ROM), etc. Memory is any storage medium capable of carrying or storing program code in the form of instructions or data structures, and capable of being read and / or written by a computer (such as the communication device shown in this application), but is not limited to this. The memory in this application embodiment may also be a circuit or any other device capable of implementing storage functions, used to store program instructions and / or data.

[0221] The processor 1102 is mainly used to process communication protocols and communication data, control the entire communication device, execute software programs, and process the data of the software programs. The memory 1103 is mainly used to store software programs and data. The transceiver 1101 may include control circuitry and an antenna. The control circuitry is mainly used for converting baseband signals to radio frequency signals and processing radio frequency signals. The antenna is mainly used for transmitting and receiving radio frequency signals in the form of electromagnetic waves. Input / output devices, such as touchscreens, displays, and keyboards, are mainly used to receive user input data and output data to the user.

[0222] The communication device shown in this application embodiment may also have more components than those in Figure 11, and this application embodiment does not limit this. The methods executed by the processor and transceiver shown above are only examples, and the specific steps executed by the processor and transceiver can be referred to the methods described above.

[0223] In one possible implementation, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to perform the methods of any of the above-described method embodiments.

[0224] In one possible implementation, embodiments of this application also provide a computer program product containing instructions, the computer program product comprising: computer program code, which, when run on a computer, enables the computer to perform the methods in any of the above method embodiments.

[0225] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, it can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that can be integrated with one or more media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)). In embodiments of this application, the computer may include the aforementioned apparatus.

[0226] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0227] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A communication method, characterized in that, The communication method is used at the sending end, and includes: sending a first message of a service to the receiving end; the header of the first message includes a first field, which is a field contained in the Fast User Datagram Protocol (QUIC) or a field contained in the Real-Time Transport Protocol (RTP); sending a second message of the service to the receiving end, the second message and the first message belonging to the same stream; the header of the second message includes a second field, the second field indicating the same content as the first field; wherein the length of the second field is less than the length of the first field.

2. The communication method according to claim 1, characterized in that, The content indicated by the first field and the content indicated by the second field include at least one of the following: timestamp, sequence number, and synchronization source SSRC identifier.

3. The communication method according to claim 1 or 2, characterized in that, The communication method further includes: sending a third message to a receiving end, the third message carrying first information, the first information being used to indicate at least one of the following: the protocol version supported by the sending end for compression, the compression method supported by the sending end, and whether the sending end supports compression of the message header; wherein, the compression method includes: deleting the second field, and / or replacing the first field with the second field, the second field being used to indicate the first information, and the length of the second field being less than the length of the first field.

4. The communication method according to claim 3, characterized in that, The communication method further includes: receiving a fourth message from the receiving end, the fourth message carrying second information, the second information being used to indicate at least one of the following: the protocol version supported by the receiving end for compression, the compression method supported by the receiving end, and whether the receiving end supports compression of the message header.

5. A communication method, characterized in that, The communication method is used in a relay device connected between a sending end and a receiving end. The communication method includes: sending a first service message to the receiving end; the header of the first message includes a first field, which is a field included in the Fast User Datagram Protocol (QUIC) or a field included in the Real-Time Transport Protocol (RTP); receiving a fifth service message from the sending end; the fifth message and the first message belong to the same stream; the header of the fifth message includes a third field, which indicates the same content as the first field, and the length of the third field is less than the length of the first field; sending a second service message to the receiving end, the second message and the first message belonging to the same stream; the header of the second message includes a second field, which indicates the same content as the first field; wherein the length of the second field is less than the length of the third field.

6. The communication method according to claim 5, characterized in that, The content indicated by the first field, the second field, and the third field includes at least one of the following: timestamp and serial number.

7. A communication method, characterized in that, The communication method is used at a receiving end, and includes: receiving a first message of a service from a sending end; the header of the first message includes a first field, which is a field contained in the Fast User Datagram Protocol (QUIC) Internet Connection Protocol, or the first field is a field contained in the Real-Time Transport Protocol (RTP) format; receiving a second message of the service from the sending end, the second message and the first message belonging to the same stream; the header of the second message includes a second field, the second field indicating the same content as the first field; wherein the length of the second field is less than the length of the first field.

8. The communication method according to claim 7, characterized in that, The content indicated by the first field and the content indicated by the second field include at least one of the following: timestamp, sequence number, and synchronization source SSRC identifier.

9. The communication method according to claim 7 or 8, characterized in that, The communication method further includes: receiving a fourth message from a sender, the fourth message carrying second information, the second information indicating at least one of the following: the protocol version supported by the sender for compression, the compression method supported by the sender, and whether the sender supports compression of the message header; wherein the compression method includes: deleting the first field, and / or replacing the first field with the second field, the second field indicating the first information, and the length of the second field being less than the length of the first field.

10. The communication method according to claim 9, characterized in that, The communication method further includes: sending a fifth message to the sending end, the fifth message carrying third information, the second information being used to indicate at least one of the following: the protocol version supported by the receiving end for compression, the compression method supported by the receiving end, and whether the receiving end supports compression of the message header.

11. A communication device, characterized in that, The communication device includes: a processor and a transceiver module coupled to the processor; wherein the processor is configured to execute computer instructions to control the transceiver module to perform the communication method as described in any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions, which, when read and executed by a computer, cause the computer to perform the communication method as described in any one of claims 1 to 10.

13. A computer program product containing instructions, characterized in that, The computer program product includes: computer program code, which, when run on a computer, enables the computer to perform the communication method as described in any one of claims 1 to 10.

Images