CN111385158A - Communication method and communication device - Google Patents

Communication method and communication device Download PDF

Info

Publication number
CN111385158A
CN111385158A CN201811614154.4A CN201811614154A CN111385158A CN 111385158 A CN111385158 A CN 111385158A CN 201811614154 A CN201811614154 A CN 201811614154A CN 111385158 A CN111385158 A CN 111385158A
Authority
CN
China
Prior art keywords
time
real
terminal
packet loss
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811614154.4A
Other languages
Chinese (zh)
Other versions
CN111385158B (en
Inventor
胡昭程
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Viazijing Technology Co ltd
Original Assignee
Beijing Viazijing Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Viazijing Technology Co ltd filed Critical Beijing Viazijing Technology Co ltd
Priority to CN201811614154.4A priority Critical patent/CN111385158B/en
Publication of CN111385158A publication Critical patent/CN111385158A/en
Application granted granted Critical
Publication of CN111385158B publication Critical patent/CN111385158B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/189—Transmission or retransmission of more than one copy of a message
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

The invention provides a communication method and a communication device, wherein the communication method comprises the following steps: receiving a packet loss detection message generated by the second terminal based on the real-time transmission control protocol, wherein the type field of the packet loss detection message comprises application indication information of service data, and the application indication information of the service data is used for indicating the application service type of the real-time transmission protocol packet; analyzing packet loss repairing custom content written in the application indication information to determine a subtype and a name; and when the subtype code is determined to be a preset value and the name is a preset character, feeding back a response message for confirming packet loss repair of the real-time transmission protocol packet to the second terminal. By the technical scheme, packet loss repairing can be performed on the real-time transmission protocol packet according to various application scenes, data conflict in the packet loss repairing process is reduced, reliability of the packet loss repairing scheme is improved, and sensory experience of users on audio and video resources is further improved.

Description

Communication method and communication device
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a communication method and a communication apparatus.
Background
RTP (Real-time Transport Protocol) provides time information and stream synchronization for end-to-end Real-time transmission on the Internet, but does not guarantee quality of service, which is provided by RTCP (Real-time Transport Control Protocol).
Specifically, RTP and RTCP are designed based on UDP (User Datagram Protocol), and the UDP cannot guarantee that a data packet is delivered to a receiving device due to the most important defect, so that when the communication quality is poor (such as insufficient bandwidth, traffic congestion, high signal error rate, and high inherent loss rate), the RTP packet is lost, and the quality of audio resources and video resources is reduced.
In the related art, two schemes of forward error correction and retransmission are usually adopted for packet loss RTP, on one hand, the existing packet loss repair scheme has poor applicability to various audio and video application scenarios, and on the other hand, communication delay is not accurately and effectively evaluated, so that data collision may occur in the packet loss repair process.
Disclosure of Invention
The present invention is directed to solving at least one of the problems of the prior art or the related art.
To this end, it is an object of the present invention to provide a communication method.
Another object of the present invention is to provide a communication apparatus.
Another object of the present invention is to provide a video terminal.
It is another object of the present invention to provide a computer-readable storage medium.
In order to achieve the above object, according to an embodiment of a first aspect of the present invention, there is provided a communication method including: receiving a packet loss detection message generated by the second terminal based on the real-time transmission control protocol, wherein the type field of the packet loss detection message comprises application indication information of service data, and the application indication information of the service data is used for indicating the application service type of the real-time transmission protocol packet; analyzing packet loss repairing custom content written in the application indication information to determine a subtype and a name; and when the subtype code is determined to be a preset value and the name is a preset character, feeding back a response message for confirming packet loss repair of the real-time transmission protocol packet to the second terminal.
In the technical scheme, a packet loss detection message generated by a second terminal based on a real-time transmission control protocol is received, a type field of the packet loss detection message comprises application indication information of service data, the application indication information of the service data is used for indicating an application service type of a real-time transmission protocol packet, the round-trip delay requirement of RTP packet transmission can be determined, further, a sub-type and a name are determined by analyzing packet loss repair custom content written in the application indication information, and when the code of the sub-type is determined to be a preset value and the name is a preset character, a response message for confirming the packet loss repair of the real-time transmission protocol packet is fed back to the second terminal, namely the packet loss repair custom content based on the RTCP protocol, so that the handshake negotiation process before the packet loss repair defined by the application is realized between the first terminal and the second terminal for RTP packet transmission, the reliability and the safety of the packet loss repairing scheme are improved.
In any of the above technical solutions, preferably, in any link delay test period when the real-time transport protocol packet is transmitted, a round-trip delay message is sent to the second terminal; receiving a response message fed back by the second terminal in response to the round trip delay message; determining the round-trip delay parameter of the current period according to the time difference between the time stamp of the round-trip delay message and the time stamp of the response message; and updating the pre-stored round-trip delay parameter in real time according to the preset weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter.
In this technical solution, a Round Trip delay parameter of a current period is determined by a Time difference between a Time stamp of a Round Trip delay message (RTT) and a Time stamp of a response message (RAK, RTT acknowledgement), and further, updating the pre-stored round-trip delay parameter in real time according to the pre-set weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter, improving the accuracy and reliability of the round-trip delay parameter, the first terminal feeds back the packet loss information of the RTP packet to the second terminal according to the real-time estimated round-trip delay parameter, and the second terminal can selectively retransmit the lost RTP packet based on the real-time evaluated round trip delay parameter, and timely purge the local buffer data, the cache data is mainly the sent RTP packet, and therefore reliability of the communication interaction process is improved.
In the process of transmitting the RTP packet, the first terminal refers in particular to a terminal for receiving the RTP packet, and the second terminal refers in particular to a terminal for sending the RTP packet.
It is noted that the predetermined weight is an empirical parameter determined by a number of experiments, and is usually a value between 0 and 1.
In any of the above technical solutions, preferably, the method further includes: resetting the minimum buffer time and/or the maximum overtime time according to the real-time updated round-trip delay parameter and the application service type; and packaging the minimum buffering time and/or the maximum overtime time, and feeding back the minimum buffering time and/or the maximum overtime time to the second terminal, wherein the minimum buffering time is used for indicating the cycle time for carrying out disorder processing on the real-time transmission protocol packet, and the maximum overtime time is used for indicating the cycle time for waiting for the second terminal to resend the real-time transmission protocol packet confirming the packet loss.
In the technical scheme, the minimum buffering time and/or the maximum timeout time are reset according to the real-time updated round-trip delay parameter and the application service type, and the minimum buffering time and/or the maximum timeout time are encapsulated and fed back to the second terminal, so that on one hand, the real-time updated round-trip delay parameter reflects the communication quality of a communication channel, and on the other hand, the packet loss repairing scheme is further optimized by combining the round-trip delay parameter and the application service type, for example, for a video conference service, the communication delay is required to be as small as possible, and a small amount of packet loss can be received, and at this time, the minimum buffering time and the maximum timeout time need to be set to be smaller values, for example, set to be 60 milliseconds and 200 milliseconds respectively. For the video broadcast service, the requirement on delay is not high, and it is better to ensure no packet loss, at this time, the minimum buffering time and/or the maximum timeout time may be set to a larger value, for example, set to 1000 milliseconds and 5000 milliseconds, respectively.
Specifically, the RTP packet received by the first terminal and sent by the second terminal may be out of order, the out-of-order packet is not subjected to packet loss repair processing, and the RTP packet that is not received by the first terminal after exceeding the minimum buffering time is determined as a packet loss to be retransmitted, in addition, the maximum timeout time is the maximum duration of the packet loss to be retransmitted, when the packet loss to be retransmitted by the first terminal exceeds the maximum timeout time, it is determined that packet loss repair fails, the second terminal is not requested to retransmit the RTP packet that is lost, and the second terminal is instructed to delete the cache data of the RTP packet that is failed to repair.
In any of the above technical solutions, preferably, the method further includes: when the fact that the time length of a real-time transmission protocol packet for confirming packet loss waiting to be retransmitted exceeds the maximum overtime time is detected, the real-time transmission protocol packet for confirming packet loss is determined as a received real-time transmission protocol packet; and sending a confirmation message to the second terminal according to a preset forward feedback period, wherein the confirmation message carries the maximum sequence number of the real-time transmission protocol packet received by the first terminal.
In the technical scheme, the confirmation message is sent to the second terminal according to the preset forward feedback period to indicate that the second terminal deletes the cache data of the RTP packet determined to be received by the first terminal, wherein the received RTP packet comprises the RTP packet actually received by the first terminal and the RTP packet failed to be repaired, so that the utilization rate of the cache space of the second terminal can be effectively improved, the occupation of redundant data is reduced, the operation fluency and the communication efficiency of the second terminal are further improved, and meanwhile, the second terminal does not repeatedly retransmit the RTP packet failed to be repaired, so that the data throughput rate of the communication network is improved.
The maximum timeout time is determined based on the real-time updated round-trip delay information and the application service type, and especially under the condition that the retransmission of the RTP packet fails due to poor network communication quality, in order to improve the reliability of communication data and the conference adaptation experience, the second terminal may delete the cache data of the RTP packet with the failed repair according to the confirmation message, thereby further improving the reliability of packet loss repair.
In any of the above technical solutions, preferably, the method further includes: and sending negative response messages to the second terminal according to a preset packet loss feedback cycle, wherein the negative response messages carry the sequence numbers of the real-time transmission protocol packets confirming packet loss, and the time interval between any two negative response messages sent by any real-time transmission protocol packet confirming packet loss is greater than or equal to the minimum buffer time.
In the technical scheme, the negative response message is sent to the second terminal according to the preset packet loss feedback cycle, the second terminal can be instructed to retransmit the RTP packet to be lost in the minimum buffering time interval, and the time interval between any two negative response messages sent by any real-time transmission protocol packet for confirming packet loss is greater than or equal to the minimum buffering time, so that the reliability of packet loss repair is further improved.
The minimum buffer time is determined based on the round-trip delay information updated in real time and the application service type, so that when the requirement of the application service type on the real-time performance of the audio and video resources is not high, and the round-trip delay is large due to poor network communication quality, the possibility of disorder of the RTP packets is high, and therefore the minimum buffer time can be properly improved to improve the reliability of the negative response message, further the disorder of the RTP packets is prevented from being retransmitted by the second terminal for many times, and the data collision in the communication process is reduced.
According to an aspect of the second aspect of the present invention, there is provided a communication apparatus including: the receiving unit is used for receiving a packet loss detection message generated by the second terminal based on the real-time transmission control protocol, wherein the type field of the packet loss detection message comprises application indication information of service data, and the application indication information of the service data is used for indicating the application service type of the real-time transmission protocol packet; the analysis unit is used for analyzing the packet loss repairing custom content written in the application indication information to determine the subtype and the name; and the sending unit is used for feeding back a response message for confirming packet loss repair of the real-time transmission protocol packet to the second terminal when the fact that the code of the subtype is the preset value and the name is the preset character is determined.
In the technical scheme, a packet loss detection message generated by a second terminal based on a real-time transmission control protocol is received, a type field of the packet loss detection message comprises application indication information of service data, the application indication information of the service data is used for indicating an application service type of a real-time transmission protocol packet, the round-trip delay requirement of RTP packet transmission can be determined, further, a sub-type and a name are determined by analyzing packet loss repair custom content written in the application indication information, and when the code of the sub-type is determined to be a preset value and the name is a preset character, a response message for confirming the packet loss repair of the real-time transmission protocol packet is fed back to the second terminal, namely the packet loss repair custom content based on the RTCP protocol, so that the handshake negotiation process before the packet loss repair defined by the application is realized between the first terminal and the second terminal for RTP packet transmission, the reliability and the safety of the packet loss repairing scheme are improved.
In any of the above technical solutions, preferably, the sending unit is further configured to: in any link delay test period when the real-time transmission protocol packet is transmitted, sending a round-trip delay message to the second terminal; the receiving unit is further configured to: receiving a response message fed back by the second terminal in response to the round trip delay message; the communication apparatus further includes: a determining unit, configured to determine a round trip delay parameter of a current period according to a time difference between a timestamp of the round trip delay message and a timestamp of the response message; and the calculating unit is used for updating the pre-stored round-trip delay parameter in real time according to the preset weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter.
In this technical solution, a Round Trip delay parameter of a current period is determined by a Time difference between a Time stamp of a Round Trip delay message (RTT) and a Time stamp of a response message (RAK, RTT acknowledgement), and further, updating the pre-stored round-trip delay parameter in real time according to the pre-set weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter, improving the accuracy and reliability of the round-trip delay parameter, the first terminal feeds back the packet loss information of the RTP packet to the second terminal according to the real-time estimated round-trip delay parameter, and the second terminal can selectively retransmit the lost RTP packet based on the real-time evaluated round trip delay parameter, and timely purge the local buffer data, the cache data is mainly the sent RTP packet, and therefore reliability of the communication interaction process is improved.
In the process of transmitting the RTP packet, the first terminal refers in particular to a terminal for receiving the RTP packet, and the second terminal refers in particular to a terminal for sending the RTP packet.
It is noted that the predetermined weight is an empirical parameter determined by a number of experiments, and is usually a value between 0 and 1.
In any of the above technical solutions, preferably, the method further includes: the setting unit is used for resetting the minimum buffer time and/or the maximum overtime time according to the real-time updated round-trip delay parameter and the application service type; the sending unit is further configured to: and packaging the minimum buffering time and/or the maximum overtime time, and feeding back the minimum buffering time and/or the maximum overtime time to the second terminal, wherein the minimum buffering time is used for indicating the cycle time for carrying out disorder processing on the real-time transmission protocol packet, and the maximum overtime time is used for indicating the cycle time for waiting for the second terminal to resend the real-time transmission protocol packet confirming the packet loss.
In the technical scheme, the minimum buffering time and/or the maximum timeout time are reset according to the real-time updated round-trip delay parameter and the application service type, and the minimum buffering time and/or the maximum timeout time are encapsulated and fed back to the second terminal, so that on one hand, the real-time updated round-trip delay parameter reflects the communication quality of a communication channel, and on the other hand, the packet loss repairing scheme is further optimized by combining the round-trip delay parameter and the application service type, for example, for a video conference service, the communication delay is required to be as small as possible, and a small amount of packet loss can be received, and at this time, the minimum buffering time and the maximum timeout time need to be set to be smaller values, for example, set to be 60 milliseconds and 200 milliseconds respectively. For the video broadcast service, the requirement on delay is not high, and it is better to ensure no packet loss, at this time, the minimum buffering time and/or the maximum timeout time may be set to a larger value, for example, set to 1000 milliseconds and 5000 milliseconds, respectively.
Specifically, the RTP packet received by the first terminal and sent by the second terminal may be out of order, the out-of-order packet is not subjected to packet loss repair processing, and the RTP packet that is not received by the first terminal after exceeding the minimum buffering time is determined as a packet loss to be retransmitted, in addition, the maximum timeout time is the maximum duration of the packet loss to be retransmitted, when the packet loss to be retransmitted by the first terminal exceeds the maximum timeout time, it is determined that packet loss repair fails, the second terminal is not requested to retransmit the RTP packet that is lost, and the second terminal is instructed to delete the cache data of the RTP packet that is failed to repair.
In any of the above technical solutions, preferably, the method further includes: the timing unit is used for determining the real-time transmission protocol packet with the confirmed packet loss as a received real-time transmission protocol packet when the time length of the real-time transmission protocol packet with the confirmed packet loss waiting for being sent again is detected to exceed the maximum overtime time; the sending unit is further configured to: and sending a confirmation message to the second terminal according to a preset forward feedback period, wherein the confirmation message carries the maximum sequence number of the real-time transmission protocol packet received by the first terminal.
In the technical scheme, the confirmation message is sent to the second terminal according to the preset forward feedback period to indicate that the second terminal deletes the cache data of the RTP packet determined to be received by the first terminal, wherein the received RTP packet comprises the RTP packet actually received by the first terminal and the RTP packet failed to be repaired, so that the utilization rate of the cache space of the second terminal can be effectively improved, the occupation of redundant data is reduced, the operation fluency and the communication efficiency of the second terminal are further improved, and meanwhile, the second terminal does not repeatedly retransmit the RTP packet failed to be repaired, so that the data throughput rate of the communication network is improved.
The maximum timeout time is determined based on the real-time updated round-trip delay information and the application service type, and especially under the condition that the retransmission of the RTP packet fails due to poor network communication quality, in order to improve the reliability of communication data and the conference adaptation experience, the second terminal may delete the cache data of the RTP packet with the failed repair according to the confirmation message, thereby further improving the reliability of packet loss repair.
In any of the above technical solutions, preferably, the sending unit is further configured to: and sending negative response messages to the second terminal according to a preset packet loss feedback cycle, wherein the negative response messages carry the sequence numbers of the real-time transmission protocol packets confirming packet loss, and the time interval between any two negative response messages sent by any real-time transmission protocol packet confirming packet loss is greater than or equal to the minimum buffer time.
In the technical scheme, the negative response message is sent to the second terminal according to the preset packet loss feedback cycle, the second terminal can be instructed to retransmit the RTP packet to be lost in the minimum buffering time interval, and the time interval between any two negative response messages sent by any real-time transmission protocol packet for confirming packet loss is greater than or equal to the minimum buffering time, so that the reliability of packet loss repair is further improved.
The minimum buffer time is determined based on the round-trip delay information updated in real time and the application service type, so that when the requirement of the application service type on the real-time performance of the audio and video resources is not high, and the round-trip delay is large due to poor network communication quality, the possibility of disorder of the RTP packets is high, and therefore the minimum buffer time can be properly improved to improve the reliability of the negative response message, further the disorder of the RTP packets is prevented from being retransmitted by the second terminal for many times, and the data collision in the communication process is reduced.
According to a technical solution of a third aspect of the present invention, there is provided a video terminal, comprising: the communication device defined in any one of the preceding claims.
According to an aspect of the fourth aspect of the present invention, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed, implements the communication method defined in any one of the above aspects.
Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.
Drawings
The above and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:
fig. 1 shows a schematic flow diagram of a communication method according to an embodiment of the invention;
FIG. 2 shows a schematic block diagram of a communication device according to an embodiment of the invention;
FIG. 3 shows a schematic block diagram of a video terminal according to an embodiment of the present invention;
FIG. 4 illustrates a schematic diagram of an RTCP packet of a communication scheme in accordance with an embodiment of the present invention;
fig. 5 shows an interaction diagram of a communication scheme according to an embodiment of the invention.
Detailed Description
In order that the above objects, features and advantages of the present invention can be more clearly understood, a more particular description of the invention will be rendered by reference to the appended drawings. It should be noted that the embodiments and features of the embodiments of the present application may be combined with each other without conflict.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, however, the present invention may be practiced in other ways than those specifically described herein, and therefore the scope of the present invention is not limited by the specific embodiments disclosed below.
The first embodiment is as follows:
fig. 1 shows a schematic flow diagram of a communication method according to an embodiment of the invention.
As shown in fig. 1, a communication method according to an embodiment of the present invention includes: step S102, receiving a packet loss detection message generated by a second terminal based on a real-time transmission control protocol, wherein the type field of the packet loss detection message comprises application indication information of service data, and the application indication information of the service data is used for indicating the application service type of a real-time transmission protocol packet; step S104, analyzing the packet loss repairing custom content written in the application indication information to determine the subtype and the name; and step S106, when the subtype code is determined to be the preset value and the name is the preset character, feeding back a response message for confirming packet loss repair of the real-time transmission protocol packet to the second terminal.
In the technical scheme, a packet loss detection message generated by a second terminal based on a real-time transmission control protocol is received, a type field of the packet loss detection message comprises application indication information of service data, the application indication information of the service data is used for indicating an application service type of a real-time transmission protocol packet, the round-trip delay requirement of RTP packet transmission can be determined, further, a sub-type and a name are determined by analyzing packet loss repair custom content written in the application indication information, and when the code of the sub-type is determined to be a preset value and the name is a preset character, a response message for confirming the packet loss repair of the real-time transmission protocol packet is fed back to the second terminal, namely the packet loss repair custom content based on the RTCP protocol, so that the handshake negotiation process before the packet loss repair defined by the application is realized between the first terminal and the second terminal for RTP packet transmission, the reliability and the safety of the packet loss repairing scheme are improved.
In any of the above technical solutions, preferably, in any link delay test period when the real-time transport protocol packet is transmitted, a round-trip delay message is sent to the second terminal; receiving a response message fed back by the second terminal in response to the round trip delay message; determining the round-trip delay parameter of the current period according to the time difference between the time stamp of the round-trip delay message and the time stamp of the response message; and updating the pre-stored round-trip delay parameter in real time according to the preset weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter.
In this technical solution, a Round Trip delay parameter of a current period is determined by a Time difference between a Time stamp of a Round Trip delay message (RTT) and a Time stamp of a response message (RAK, RTT acknowledgement), and further, updating the pre-stored round-trip delay parameter in real time according to the pre-set weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter, improving the accuracy and reliability of the round-trip delay parameter, the first terminal feeds back the packet loss information of the RTP packet to the second terminal according to the real-time estimated round-trip delay parameter, and the second terminal can selectively retransmit the lost RTP packet based on the real-time evaluated round trip delay parameter, and timely purge the local buffer data, the cache data is mainly the sent RTP packet, and therefore reliability of the communication interaction process is improved.
In the process of transmitting the RTP packet, the first terminal refers in particular to a terminal for receiving the RTP packet, and the second terminal refers in particular to a terminal for sending the RTP packet.
It is noted that the predetermined weight is an empirical parameter determined by a number of experiments, and is usually a value between 0 and 1.
In any of the above technical solutions, preferably, the method further includes: resetting the minimum buffer time and/or the maximum overtime time according to the real-time updated round-trip delay parameter and the application service type; and packaging the minimum buffering time and/or the maximum overtime time, and feeding back the minimum buffering time and/or the maximum overtime time to the second terminal, wherein the minimum buffering time is used for indicating the cycle time for carrying out disorder processing on the real-time transmission protocol packet, and the maximum overtime time is used for indicating the cycle time for waiting for the second terminal to resend the real-time transmission protocol packet confirming the packet loss.
In the technical scheme, the minimum buffering time and/or the maximum timeout time are reset according to the real-time updated round-trip delay parameter and the application service type, and the minimum buffering time and/or the maximum timeout time are encapsulated and fed back to the second terminal, so that on one hand, the real-time updated round-trip delay parameter reflects the communication quality of a communication channel, and on the other hand, the packet loss repairing scheme is further optimized by combining the round-trip delay parameter and the application service type, for example, for a video conference service, the communication delay is required to be as small as possible, and a small amount of packet loss can be received, and at this time, the minimum buffering time and the maximum timeout time need to be set to be smaller values, for example, set to be 60 milliseconds and 200 milliseconds respectively. For the video broadcast service, the requirement on delay is not high, and it is better to ensure no packet loss, at this time, the minimum buffering time and/or the maximum timeout time may be set to a larger value, for example, set to 1000 milliseconds and 5000 milliseconds, respectively.
Specifically, the RTP packet received by the first terminal and sent by the second terminal may be out of order, the out-of-order packet is not subjected to packet loss repair processing, and the RTP packet that is not received by the first terminal after exceeding the minimum buffering time is determined as a packet loss to be retransmitted, in addition, the maximum timeout time is the maximum duration of the packet loss to be retransmitted, when the packet loss to be retransmitted by the first terminal exceeds the maximum timeout time, it is determined that packet loss repair fails, the second terminal is not requested to retransmit the RTP packet that is lost, and the second terminal is instructed to delete the cache data of the RTP packet that is failed to repair.
In any of the above technical solutions, preferably, the method further includes: when the fact that the time length of a real-time transmission protocol packet for confirming packet loss waiting to be retransmitted exceeds the maximum overtime time is detected, the real-time transmission protocol packet for confirming packet loss is determined as a received real-time transmission protocol packet; and sending a confirmation message to the second terminal according to a preset forward feedback period, wherein the confirmation message carries the maximum sequence number of the real-time transmission protocol packet received by the first terminal.
In the technical scheme, the confirmation message is sent to the second terminal according to the preset forward feedback period to indicate that the second terminal deletes the cache data of the RTP packet determined to be received by the first terminal, wherein the received RTP packet comprises the RTP packet actually received by the first terminal and the RTP packet failed to be repaired, so that the utilization rate of the cache space of the second terminal can be effectively improved, the occupation of redundant data is reduced, the operation fluency and the communication efficiency of the second terminal are further improved, and meanwhile, the second terminal does not repeatedly retransmit the RTP packet failed to be repaired, so that the data throughput rate of the communication network is improved.
The maximum timeout time is determined based on the real-time updated round-trip delay information and the application service type, and especially under the condition that the retransmission of the RTP packet fails due to poor network communication quality, in order to improve the reliability of communication data and the conference adaptation experience, the second terminal may delete the cache data of the RTP packet with the failed repair according to the confirmation message, thereby further improving the reliability of packet loss repair.
In any of the above technical solutions, preferably, the method further includes: and sending negative response messages to the second terminal according to a preset packet loss feedback cycle, wherein the negative response messages carry the sequence numbers of the real-time transmission protocol packets confirming packet loss, and the time interval between any two negative response messages sent by any real-time transmission protocol packet confirming packet loss is greater than or equal to the minimum buffer time.
In the technical scheme, the negative response message is sent to the second terminal according to the preset packet loss feedback cycle, the second terminal can be instructed to retransmit the RTP packet to be lost in the minimum buffering time interval, and the time interval between any two negative response messages sent by any real-time transmission protocol packet for confirming packet loss is greater than or equal to the minimum buffering time, so that the reliability of packet loss repair is further improved.
The minimum buffer time is determined based on the round-trip delay information updated in real time and the application service type, so that when the requirement of the application service type on the real-time performance of the audio and video resources is not high, and the round-trip delay is large due to poor network communication quality, the possibility of disorder of the RTP packets is high, and therefore the minimum buffer time can be properly improved to improve the reliability of the negative response message, further the disorder of the RTP packets is prevented from being retransmitted by the second terminal for many times, and the data collision in the communication process is reduced.
Example two:
fig. 2 shows a schematic block diagram of a communication device according to an embodiment of the invention.
As shown in fig. 2, a communication apparatus 200 according to an embodiment of the present invention includes: a receiving unit 202, configured to receive a packet loss detection message generated by the second terminal based on the real-time transmission control protocol, where a type field of the packet loss detection message includes application indication information of service data, and the application indication information of the service data is used to indicate an application service type of the real-time transmission protocol packet; an analyzing unit 204, configured to analyze the packet loss repair custom content written in the application indication information to determine a subtype and a name; a sending unit 206, configured to feed back, to the second terminal, a response message for confirming packet loss repair of the real-time transport protocol packet when it is determined that the subtype code is the preset value and the name is the preset character.
In the technical scheme, a packet loss detection message generated by a second terminal based on a real-time transmission control protocol is received, a type field of the packet loss detection message comprises application indication information of service data, the application indication information of the service data is used for indicating an application service type of a real-time transmission protocol packet, the round-trip delay requirement of RTP packet transmission can be determined, further, a sub-type and a name are determined by analyzing packet loss repair custom content written in the application indication information, and when the code of the sub-type is determined to be a preset value and the name is a preset character, a response message for confirming the packet loss repair of the real-time transmission protocol packet is fed back to the second terminal, namely the packet loss repair custom content based on the RTCP protocol, so that the handshake negotiation process before the packet loss repair defined by the application is realized between the first terminal and the second terminal for RTP packet transmission, the reliability and the safety of the packet loss repairing scheme are improved.
In any of the above technical solutions, preferably, the sending unit 206 is further configured to: in any link delay test period when the real-time transmission protocol packet is transmitted, sending a round-trip delay message to the second terminal; the receiving unit 202 is further configured to: receiving a response message fed back by the second terminal in response to the round trip delay message; the communication apparatus 200 further includes: a determining unit 208, configured to determine a round trip delay parameter of the current period according to a time difference between a timestamp of the round trip delay message and a timestamp of the response message; the calculating unit 210 is configured to update the pre-stored round-trip delay parameter in real time according to a preset weight, the pre-stored round-trip delay parameter, and a weighting calculation result of the current round-trip delay parameter.
In this technical solution, a Round Trip delay parameter of a current period is determined by a Time difference between a Time stamp of a Round Trip delay message (RTT) and a Time stamp of a response message (RAK, RTT acknowledgement), and further, updating the pre-stored round-trip delay parameter in real time according to the pre-set weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter, improving the accuracy and reliability of the round-trip delay parameter, the first terminal feeds back the packet loss information of the RTP packet to the second terminal according to the real-time estimated round-trip delay parameter, and the second terminal can selectively retransmit the lost RTP packet based on the real-time evaluated round trip delay parameter, and timely purge the local buffer data, the cache data is mainly the sent RTP packet, and therefore reliability of the communication interaction process is improved.
In the process of transmitting the RTP packet, the first terminal refers in particular to a terminal for receiving the RTP packet, and the second terminal refers in particular to a terminal for sending the RTP packet.
It is noted that the predetermined weight is an empirical parameter determined by a number of experiments, and is usually a value between 0 and 1.
In any of the above technical solutions, preferably, the method further includes: a setting unit 212, configured to reset a minimum buffer time and/or a maximum timeout time according to the real-time updated round-trip delay parameter and the application service type; the sending unit 206 is further configured to: and packaging the minimum buffering time and/or the maximum overtime time, and feeding back the minimum buffering time and/or the maximum overtime time to the second terminal, wherein the minimum buffering time is used for indicating the cycle time for carrying out disorder processing on the real-time transmission protocol packet, and the maximum overtime time is used for indicating the cycle time for waiting for the second terminal to resend the real-time transmission protocol packet confirming the packet loss.
In the technical scheme, the minimum buffering time and/or the maximum timeout time are reset according to the real-time updated round-trip delay parameter and the application service type, and the minimum buffering time and/or the maximum timeout time are encapsulated and fed back to the second terminal, so that on one hand, the real-time updated round-trip delay parameter reflects the communication quality of a communication channel, and on the other hand, the packet loss repairing scheme is further optimized by combining the round-trip delay parameter and the application service type, for example, for a video conference service, the communication delay is required to be as small as possible, and a small amount of packet loss can be received, and at this time, the minimum buffering time and the maximum timeout time need to be set to be smaller values, for example, set to be 60 milliseconds and 200 milliseconds respectively. For the video broadcast service, the requirement on delay is not high, and it is better to ensure no packet loss, at this time, the minimum buffering time and/or the maximum timeout time may be set to a larger value, for example, set to 1000 milliseconds and 5000 milliseconds, respectively.
Specifically, the RTP packet received by the first terminal and sent by the second terminal may be out of order, the out-of-order packet is not subjected to packet loss repair processing, and the RTP packet that is not received by the first terminal after exceeding the minimum buffering time is determined as a packet loss to be retransmitted, in addition, the maximum timeout time is the maximum duration of the packet loss to be retransmitted, when the packet loss to be retransmitted by the first terminal exceeds the maximum timeout time, it is determined that packet loss repair fails, the second terminal is not requested to retransmit the RTP packet that is lost, and the second terminal is instructed to delete the cache data of the RTP packet that is failed to repair.
In any of the above technical solutions, preferably, the method further includes: a timing unit 214, configured to determine, when it is detected that a duration of a real-time transport protocol packet for confirming packet loss waiting to be retransmitted exceeds a maximum timeout time, the real-time transport protocol packet for confirming packet loss as a received real-time transport protocol packet; the sending unit 206 is further configured to: and sending a confirmation message to the second terminal according to a preset forward feedback period, wherein the confirmation message carries the maximum sequence number of the real-time transmission protocol packet received by the first terminal.
In the technical scheme, the confirmation message is sent to the second terminal according to the preset forward feedback period to indicate that the second terminal deletes the cache data of the RTP packet determined to be received by the first terminal, wherein the received RTP packet comprises the RTP packet actually received by the first terminal and the RTP packet failed to be repaired, so that the utilization rate of the cache space of the second terminal can be effectively improved, the occupation of redundant data is reduced, the operation fluency and the communication efficiency of the second terminal are further improved, and meanwhile, the second terminal does not repeatedly retransmit the RTP packet failed to be repaired, so that the data throughput rate of the communication network is improved.
The maximum timeout time is determined based on the real-time updated round-trip delay information and the application service type, and especially under the condition that the retransmission of the RTP packet fails due to poor network communication quality, in order to improve the reliability of communication data and the conference adaptation experience, the second terminal may delete the cache data of the RTP packet with the failed repair according to the confirmation message, thereby further improving the reliability of packet loss repair.
In any of the above technical solutions, preferably, the sending unit 206 is further configured to: and sending negative response messages to the second terminal according to a preset packet loss feedback cycle, wherein the negative response messages carry the sequence numbers of the real-time transmission protocol packets confirming packet loss, and the time interval between any two negative response messages sent by any real-time transmission protocol packet confirming packet loss is greater than or equal to the minimum buffer time.
In the technical scheme, the negative response message is sent to the second terminal according to the preset packet loss feedback cycle, the second terminal can be instructed to retransmit the RTP packet to be lost in the minimum buffering time interval, and the time interval between any two negative response messages sent by any real-time transmission protocol packet for confirming packet loss is greater than or equal to the minimum buffering time, so that the reliability of packet loss repair is further improved.
The minimum buffer time is determined based on the round-trip delay information updated in real time and the application service type, so that when the requirement of the application service type on the real-time performance of the audio and video resources is not high, and the round-trip delay is large due to poor network communication quality, the possibility of disorder of the RTP packets is high, and therefore the minimum buffer time can be properly improved to improve the reliability of the negative response message, further the disorder of the RTP packets is prevented from being retransmitted by the second terminal for many times, and the data collision in the communication process is reduced.
Example three:
fig. 3 shows a schematic block diagram of a video terminal according to an embodiment of the invention.
As shown in fig. 3, the video terminal 300 according to an embodiment of the present invention includes: such as the communication device 200 shown in fig. 2.
The communication device 200 may be compatible with or integrated in a video terminal such as a mobile phone, a tablet computer, an audio/video player, a monitoring device, a navigation device, and the like having a communication module, the determining unit 208, the calculating unit 210, the setting unit 212, and the analyzing unit 204 may be a processor (CPU), a controller (MCU), an embedded micro-control chip, a baseband processor, and the like of the communication device 200, the transmitting unit 206 and the receiving unit 202 may be an antenna, a carrier modulation module, and the like of the communication device 200, and the timing unit 214 may be a crystal module of the communication device 200.
Example four:
fig. 4 shows a schematic diagram of an RTCP packet of a communication scheme according to an embodiment of the present invention.
Fig. 5 shows an interaction diagram of a communication scheme according to an embodiment of the invention.
As shown in fig. 4, the RTCP packet of the communication scheme according to the embodiment of the present invention is a 32-bit data structure in which:
the version number (V) occupies 2 bits and is used to mark the version information of the RTP packet used, and the version number V field in this application is written in binary "01".
The padding bit (P) occupies 1 bit and if it is set, the end of the RTP packet contains additional padding bytes.
The Payload Type (PT) occupies 7 bits, identifying the type of RTP payload, and the payload type PT field in this application writes binary "11001100", i.e., "204" in decimal.
The synchronization source identifier (SSRC) occupies 32 bits, and the synchronization source refers to the transmission source of the RTP packet. There cannot be two identical SSRC values in the same RTP session. The identifier is a randomly chosen RFC1889 recommended MD5 random algorithm. The contributing source identifier (CSRC) occupies 4 bits, containing the number of CSRCs followed by a fixed header.
The Length field occupies 16 bits and identifies the Length of a plurality of packet loss repair data used for identifying data repair of the RTP packet.
How the "Name" field, "Application-dependent data" field, "sequence number" field, and "Mask" field in the RTCP packet are defined will be described in detail below with reference to fig. 4 and 5.
1. "NAME" is defined as "VZJ 0", and in the embodiment of the present application, "VZJ 0" is used as an identification NAME, but not limited thereto, "subtype" is set to 0, which means that the packet loss repairing method defined in the present application is used, and other fields are set according to the standard RTCP requirements. The application-dependent data is variable-length protocol data, and self-defined information is stored in the application-dependent data.
2. The writing self-defining message format in the application-dependency data is as follows:
Figure BDA0001925461030000161
specifically, what is contained in the "application-dependent data" is the private signaling defined in the present application, i.e. 1 or more SArqCommand structures, and the specific examples are described as follows:
(1) magic information field: 4 bytes set to "VZJ 0";
(2) len information field: a byte length indicating a frame structure of the present data instruction;
(3) cmd information field: the fixed setting is '0', and the data instruction is a packet loss repairing command;
(4) type information field: the method comprises the steps of indicating a packet loss repairing message type;
(5) baseSeqNo information field: for indicating a base sequence number;
(6) mask information field: for indicating the multipurpose parameter.
3. The packet loss repair message type is defined as:
Figure BDA0001925461030000162
Figure BDA0001925461030000171
4. before the sending and receiving parties do not negotiate the successful packet loss repair capability, the sending party (i.e. the second terminal) will periodically and actively send a repair probe message to the receiving party (i.e. the first terminal) for capability negotiation. After receiving the repair probe message, the receiver returns a message of a specified type (one of RTT, RAK, ACK, NAK, and repair probe message having the same structure as the RTCP packet definition) to indicate that the negotiation is successful. After the negotiation is successful, the sender does not send the repair probe message any more. The repair probe message is the only message that the sender sends on its own initiative. And the receiver does not send any packet loss repairing message before not receiving the repairing detection message. Both the sending and receiving parties can perform the following work only after the negotiation is successful.
5. The receiver regularly sends RTT messages for link delay test, and the sender must immediately return RAK messages to respond after receiving the RTT messages. And after receiving the RAK message, the receiver calculates the link delay according to the time difference between the RAK message and the RTT message, and updates the evaluation value of the link delay according to the link delay. The weighted calculation formula is RTTEvaluation of＝p×RTTEvaluation of+(1-p)×RTTThis timeWherein p is an empirical parameter and ranges from 0 to 1.
6. And the receiver sets the minimum buffer time and the maximum timeout time according to the application data type and the RTT updated in real time. The minimum buffering time is used for out-of-order processing of RTP packets, and the out-of-order packets are not processed as possible packet loss within this time period. The maximum timeout is the longest waiting time for packet loss, and beyond this time period, the packet loss will be considered as a repair failure and no repair is attempted. For different application scenes and service requirements, the optimal repairing effect can be achieved by reasonably setting the two parameters. For the video conference service, it is required that the communication delay is as small as possible, and at the same time, a small amount of packet loss can be received, and these two parameters are set to have small values, such as 60 ms and 200 ms. For the video broadcast service, the requirement on delay is not high, and it is better to ensure no packet loss, at this time, the two parameters can be set to be larger values, such as 1000 milliseconds and 5000 milliseconds.
7. The receiving party sends an ACK message to the sending party periodically to inform the sending party of the maximum packet sequence number which is successfully received and is not lost, so that the sending party can clear the sending buffer queue. In particular, for a lost packet that has not been received yet due to timeout (the aforementioned maximum timeout time), no attempt is made to repair the packet as having been received.
8. If the receiver finds the packet loss, the receiver will periodically (according to RTT)Evaluation ofTo determine this period) to actively send a NAK message to the senderReporting packet loss. The sender should retransmit these lost data as soon as possible after receiving the NAK message. For any packet that may be lost, the interval between two packet loss feedbacks cannot be smaller than the RTT updated in real timeEvaluation of。
9. The NAK message reports the serial number of the packet loss by adopting a mode of combining baseSeqNo and mask. Wherein the baseSeqNo is the sequence number of the 1 st packet loss in the message, the mask is a 32-bit mask, the least significant bit (least significant bit) represents the baseSeqNo, and the most significant bit (most significant bit) represents the baseSeqNo + 31. Those packets in which the bit in the mask is set to 1 are missing data packets.
10. In a packet loss repair command (a custom RTCP packet), multiple NAK messages can be included at the same time to report packet loss conditions exceeding 32 bits.
11. And (3) customizing a plurality of lost packet repairing messages contained in the RTCP packet, and normally processing the lost packet repairing messages according to the data length of the length field and the data length defined by the SarqCommand field.
12. The "Application-dependent data" field in the customized RTCP packet should be encrypted by an encryption algorithm to improve the security of the above communication scheme. The sender and receiver receive a custom RTCP packet (RTCP packet of APP type with subtype 0 and Name "VZJ 0"), and after decryption, should check if "magic" in SArqCommand is "VZJ 0", and if not, must directly discard this RTCP packet.
The 'Application-dependent data' includes private signaling defined in the present Application, that is, 1 or more SArqCommand structures, where the SArqCommand includes parameters such as a command, a serial number, and a mask.
13. The packet loss is determined according to the sequence number in the RTP data. The packet timeout time is determined based on the timestamp in the RTP data.
Example five:
according to an embodiment of the present invention, there is also provided a computer-readable storage medium having stored thereon a computer program which, when executed, performs the steps of: receiving a packet loss detection message generated by the second terminal based on the real-time transmission control protocol, wherein the type field of the packet loss detection message comprises application indication information of service data, and the application indication information of the service data is used for indicating the application service type of the real-time transmission protocol packet; analyzing packet loss repairing custom content written in the application indication information to determine a subtype and a name; and when the subtype code is determined to be a preset value and the name is a preset character, feeding back a response message for confirming packet loss repair of the real-time transmission protocol packet to the second terminal.
In the technical scheme, a packet loss detection message generated by a second terminal based on a real-time transmission control protocol is received, a type field of the packet loss detection message comprises application indication information of service data, the application indication information of the service data is used for indicating an application service type of a real-time transmission protocol packet, the round-trip delay requirement of RTP packet transmission can be determined, further, a sub-type and a name are determined by analyzing packet loss repair custom content written in the application indication information, and when the code of the sub-type is determined to be a preset value and the name is a preset character, a response message for confirming the packet loss repair of the real-time transmission protocol packet is fed back to the second terminal, namely the packet loss repair custom content based on the RTCP protocol, so that the handshake negotiation process before the packet loss repair defined by the application is realized between the first terminal and the second terminal for RTP packet transmission, the reliability and the safety of the packet loss repairing scheme are improved.
In any of the above technical solutions, preferably, in any link delay test period when the real-time transport protocol packet is transmitted, a round-trip delay message is sent to the second terminal; receiving a response message fed back by the second terminal in response to the round trip delay message; determining the round-trip delay parameter of the current period according to the time difference between the time stamp of the round-trip delay message and the time stamp of the response message; and updating the pre-stored round-trip delay parameter in real time according to the preset weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter.
In this technical solution, a Round Trip delay parameter of a current period is determined by a Time difference between a Time stamp of a Round Trip delay message (RTT) and a Time stamp of a response message (RAK, RTT acknowledgement), and further, updating the pre-stored round-trip delay parameter in real time according to the pre-set weight, the pre-stored round-trip delay parameter and the weighting calculation result of the current round-trip delay parameter, improving the accuracy and reliability of the round-trip delay parameter, the first terminal feeds back the packet loss information of the RTP packet to the second terminal according to the real-time estimated round-trip delay parameter, and the second terminal can selectively retransmit the lost RTP packet based on the real-time evaluated round trip delay parameter, and timely purge the local buffer data, the cache data is mainly the sent RTP packet, and therefore reliability of the communication interaction process is improved.
In the process of transmitting the RTP packet, the first terminal refers in particular to a terminal for receiving the RTP packet, and the second terminal refers in particular to a terminal for sending the RTP packet.
It is noted that the predetermined weight is an empirical parameter determined by a number of experiments, and is usually a value between 0 and 1.
In any of the above technical solutions, preferably, the method further includes: resetting the minimum buffer time and/or the maximum overtime time according to the real-time updated round-trip delay parameter and the application service type; and packaging the minimum buffering time and/or the maximum overtime time, and feeding back the minimum buffering time and/or the maximum overtime time to the second terminal, wherein the minimum buffering time is used for indicating the cycle time for carrying out disorder processing on the real-time transmission protocol packet, and the maximum overtime time is used for indicating the cycle time for waiting for the second terminal to resend the real-time transmission protocol packet confirming the packet loss.
In the technical scheme, the minimum buffering time and/or the maximum timeout time are reset according to the real-time updated round-trip delay parameter and the application service type, and the minimum buffering time and/or the maximum timeout time are encapsulated and fed back to the second terminal, so that on one hand, the real-time updated round-trip delay parameter reflects the communication quality of a communication channel, and on the other hand, the packet loss repairing scheme is further optimized by combining the round-trip delay parameter and the application service type, for example, for a video conference service, the communication delay is required to be as small as possible, and a small amount of packet loss can be received, and at this time, the minimum buffering time and the maximum timeout time need to be set to be smaller values, for example, set to be 60 milliseconds and 200 milliseconds respectively. For the video broadcast service, the requirement on delay is not high, and it is better to ensure no packet loss, at this time, the minimum buffering time and/or the maximum timeout time may be set to a larger value, for example, set to 1000 milliseconds and 5000 milliseconds, respectively.
Specifically, the RTP packet received by the first terminal and sent by the second terminal may be out of order, the out-of-order packet is not subjected to packet loss repair processing, and the RTP packet that is not received by the first terminal after exceeding the minimum buffering time is determined as a packet loss to be retransmitted, in addition, the maximum timeout time is the maximum duration of the packet loss to be retransmitted, when the packet loss to be retransmitted by the first terminal exceeds the maximum timeout time, it is determined that packet loss repair fails, the second terminal is not requested to retransmit the RTP packet that is lost, and the second terminal is instructed to delete the cache data of the RTP packet that is failed to repair.
In any of the above technical solutions, preferably, the method further includes: when the fact that the time length of a real-time transmission protocol packet for confirming packet loss waiting to be retransmitted exceeds the maximum overtime time is detected, the real-time transmission protocol packet for confirming packet loss is determined as a received real-time transmission protocol packet; and sending a confirmation message to the second terminal according to a preset forward feedback period, wherein the confirmation message carries the maximum sequence number of the real-time transmission protocol packet received by the first terminal.
In the technical scheme, the confirmation message is sent to the second terminal according to the preset forward feedback period to indicate that the second terminal deletes the cache data of the RTP packet determined to be received by the first terminal, wherein the received RTP packet comprises the RTP packet actually received by the first terminal and the RTP packet failed to be repaired, so that the utilization rate of the cache space of the second terminal can be effectively improved, the occupation of redundant data is reduced, the operation fluency and the communication efficiency of the second terminal are further improved, and meanwhile, the second terminal does not repeatedly retransmit the RTP packet failed to be repaired, so that the data throughput rate of the communication network is improved.
The maximum timeout time is determined based on the real-time updated round-trip delay information and the application service type, and especially under the condition that the retransmission of the RTP packet fails due to poor network communication quality, in order to improve the reliability of communication data and the conference adaptation experience, the second terminal may delete the cache data of the RTP packet with the failed repair according to the confirmation message, thereby further improving the reliability of packet loss repair.
In any of the above technical solutions, preferably, the method further includes: and sending negative response messages to the second terminal according to a preset packet loss feedback cycle, wherein the negative response messages carry the sequence numbers of the real-time transmission protocol packets confirming packet loss, and the time interval between any two negative response messages sent by any real-time transmission protocol packet confirming packet loss is greater than or equal to the minimum buffer time.
In the technical scheme, the negative response message is sent to the second terminal according to the preset packet loss feedback cycle, the second terminal can be instructed to retransmit the RTP packet to be lost in the minimum buffering time interval, and the time interval between any two negative response messages sent by any real-time transmission protocol packet for confirming packet loss is greater than or equal to the minimum buffering time, so that the reliability of packet loss repair is further improved.
The minimum buffer time is determined based on the round-trip delay information updated in real time and the application service type, so that when the requirement of the application service type on the real-time performance of the audio and video resources is not high, and the round-trip delay is large due to poor network communication quality, the possibility of disorder of the RTP packets is high, and therefore the minimum buffer time can be properly improved to improve the reliability of the negative response message, further the disorder of the RTP packets is prevented from being retransmitted by the second terminal for many times, and the data collision in the communication process is reduced.
The technical solution of the present invention is described in detail above with reference to the accompanying drawings, and the present invention provides a communication method, an apparatus, a video terminal and a computer readable storage medium, wherein a packet loss detection message generated by a second terminal based on a real-time transmission control protocol is received, a type field of the packet loss detection message includes application indication information of service data, the application indication information of the service data is used to indicate an application service type of a real-time transmission protocol packet, and a round-trip delay requirement for RTP packet transmission can be determined, further, a packet loss repair custom content written in the application indication information is analyzed to determine a subtype and a name, and when a subtype code is determined to be a preset value and the name is a preset character, a response message confirming packet loss repair of the real-time transmission protocol packet, that is, a packet loss repair custom content based on an RTCP protocol, is fed back to the second terminal, the first terminal and the second terminal which carry out RTP packet transmission realize the handshake negotiation process before packet loss repair defined by the application, and the reliability and the safety of the packet loss repair scheme are improved.
The steps in the method of the invention can be sequentially adjusted, combined and deleted according to actual needs.
The units in the device of the invention can be merged, divided and deleted according to actual needs.
It will be understood by those skilled in the art that all or part of the steps in the methods of the embodiments described above may be implemented by instructions associated with a program, which may be stored in a computer-readable storage medium, where the storage medium includes Read-Only Memory (ROM), Random Access Memory (RAM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), One-time Programmable Read-Only Memory (OTPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), compact disc-Read-Only Memory (CD-ROM), or other Memory, magnetic disk, magnetic tape, or magnetic tape, Or any other medium which can be used to carry or store data and which can be read by a computer.
The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (10)

1. A communication method is applied to a first terminal, and the first terminal receives a real-time transport protocol packet sent by a second terminal, and is characterized by comprising the following steps:
receiving a packet loss detection message generated by the second terminal based on a real-time transmission control protocol, wherein a type field of the packet loss detection message comprises application indication information of service data, and the application indication information of the service data is used for indicating an application service type of the real-time transmission protocol packet;
analyzing the packet loss repairing custom content written in the application indication information to determine the subtype and the name;
and when the subtype code is determined to be a preset value and the name is a preset character, feeding back a response message for confirming packet loss repair of the real-time transmission protocol packet to the second terminal.
2. The communication method according to claim 1, further comprising:
sending a round-trip delay message to the second terminal in any link delay test period when the real-time transport protocol packet is transmitted;
receiving a response message fed back by the second terminal in response to the round trip delay message;
determining the round trip delay parameter of the current period according to the time difference between the time stamp of the round trip delay message and the time stamp of the response message;
and updating the pre-stored round trip delay parameter in real time according to the preset weight, the pre-stored round trip delay parameter and the weighting calculation result of the current round trip delay parameter.
3. The communication method according to claim 2, further comprising:
resetting the minimum buffer time and/or the maximum overtime time according to the real-time updated round-trip delay parameter and the application service type;
encapsulating the minimum buffering time and/or the maximum timeout time and feeding back to the second terminal,
the minimum buffering time is used for indicating the cycle time for carrying out disorder processing on the real-time transmission protocol packet, and the maximum overtime time is used for indicating the cycle time for waiting for the second terminal to resend the real-time transmission protocol packet for confirming packet loss.
4. The communication method according to claim 3, further comprising:
when detecting that the time length of a real-time transmission protocol packet for confirming packet loss waiting to be retransmitted exceeds the maximum overtime time, determining the real-time transmission protocol packet for confirming packet loss as a received real-time transmission protocol packet;
and sending a confirmation message to the second terminal according to a preset forward feedback period, wherein the confirmation message carries the maximum sequence number of the real-time transmission protocol packet received by the first terminal.
5. The communication method according to claim 3 or 4, further comprising:
sending a negative response message to the second terminal according to a preset packet loss feedback cycle, wherein the negative response message carries a sequence number of a real-time transmission protocol packet for confirming packet loss,
and the time interval between any two negative acknowledgement messages sent by any real-time transmission protocol packet for confirming packet loss is greater than or equal to the minimum buffering time.
6. A communication device adapted to a first terminal, the first terminal receiving a real-time transport protocol packet sent by a second terminal, the communication device comprising:
a receiving unit, configured to receive a packet loss detection message generated by the second terminal based on a real-time transmission control protocol, where a type field of the packet loss detection message includes application indication information of service data, and the application indication information of the service data is used to indicate an application service type of the real-time transmission protocol packet;
the analysis unit is used for analyzing the packet loss repairing custom content written in the application indication information to determine the subtype and the name;
and the sending unit is used for feeding back a response message for confirming packet loss repair of the real-time transport protocol packet to the second terminal when the fact that the code of the subtype is a preset value and the name is a preset character is determined.
7. The communication device of claim 6,
the sending unit is further configured to: sending a round-trip delay message to the second terminal in any link delay test period when the real-time transport protocol packet is transmitted;
the receiving unit is further configured to: receiving a response message fed back by the second terminal in response to the round trip delay message;
the communication apparatus further includes:
a determining unit, configured to determine a round trip delay parameter of a current period according to a time difference between a timestamp of the round trip delay message and a timestamp of the response message;
and the calculating unit is used for updating the pre-stored round trip delay parameter in real time according to the preset weight, the pre-stored round trip delay parameter and the weighting calculation result of the current round trip delay parameter.
8. The communications device of claim 7, further comprising:
the setting unit is used for resetting the minimum buffer time and/or the maximum overtime time according to the real-time updated round-trip delay parameter and the application service type;
the sending unit is further configured to: encapsulating the minimum buffering time and/or the maximum timeout time and feeding back to the second terminal,
the minimum buffering time is used for indicating the cycle time for carrying out disorder processing on the real-time transmission protocol packet, and the maximum overtime time is used for indicating the cycle time for waiting for the second terminal to resend the real-time transmission protocol packet for confirming packet loss.
9. The communications device of claim 8, further comprising:
a timing unit, configured to determine, when it is detected that a time length of a real-time transport protocol packet for packet loss confirmation waiting for retransmission exceeds the maximum timeout time, the real-time transport protocol packet for packet loss confirmation as a received real-time transport protocol packet;
the sending unit is further configured to: and sending a confirmation message to the second terminal according to a preset forward feedback period, wherein the confirmation message carries the maximum sequence number of the real-time transmission protocol packet received by the first terminal.
10. The communication device according to claim 8 or 9,
the sending unit is further configured to: sending a negative response message to the second terminal according to a preset packet loss feedback cycle, wherein the negative response message carries a sequence number of a real-time transmission protocol packet for confirming packet loss,
and the time interval between any two negative acknowledgement messages sent by any real-time transmission protocol packet for confirming packet loss is greater than or equal to the minimum buffering time.
CN201811614154.4A 2018-12-27 2018-12-27 Communication method and communication device Active CN111385158B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811614154.4A CN111385158B (en) 2018-12-27 2018-12-27 Communication method and communication device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811614154.4A CN111385158B (en) 2018-12-27 2018-12-27 Communication method and communication device

Publications (2)

Publication Number Publication Date
CN111385158A true CN111385158A (en) 2020-07-07
CN111385158B CN111385158B (en) 2021-11-12

Family

ID=71216497

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811614154.4A Active CN111385158B (en) 2018-12-27 2018-12-27 Communication method and communication device

Country Status (1)

Country Link
CN (1) CN111385158B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112181883A (en) * 2020-09-24 2021-01-05 乐唯科技(深圳)有限公司 Data transmission method, system and storage medium for serial communication

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102595251A (en) * 2011-01-11 2012-07-18 中兴通讯股份有限公司 Method and system for realizing streaming media packet loss retransmission
CN107241564A (en) * 2016-03-29 2017-10-10 华为技术有限公司 Multi-stream video conference method based on IMS network architecture, apparatus and system
CN107306361A (en) * 2016-04-22 2017-10-31 华为技术有限公司 Code stream transmission method, device and IP Camera
CN107483144A (en) * 2016-06-07 2017-12-15 中兴通讯股份有限公司 Forward error correction feedback information transmission method, device
CN107919996A (en) * 2016-10-10 2018-04-17 大唐移动通信设备有限公司 A kind of data pack transmission method and equipment
CN108174234A (en) * 2018-01-12 2018-06-15 珠海全志科技股份有限公司 A kind of flow-medium transmission method and system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102595251A (en) * 2011-01-11 2012-07-18 中兴通讯股份有限公司 Method and system for realizing streaming media packet loss retransmission
CN107241564A (en) * 2016-03-29 2017-10-10 华为技术有限公司 Multi-stream video conference method based on IMS network architecture, apparatus and system
CN107306361A (en) * 2016-04-22 2017-10-31 华为技术有限公司 Code stream transmission method, device and IP Camera
CN107483144A (en) * 2016-06-07 2017-12-15 中兴通讯股份有限公司 Forward error correction feedback information transmission method, device
CN107919996A (en) * 2016-10-10 2018-04-17 大唐移动通信设备有限公司 A kind of data pack transmission method and equipment
CN108174234A (en) * 2018-01-12 2018-06-15 珠海全志科技股份有限公司 A kind of flow-medium transmission method and system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
张淼: "基于RTP的流媒体自适应QoS传输技术的研究与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112181883A (en) * 2020-09-24 2021-01-05 乐唯科技(深圳)有限公司 Data transmission method, system and storage medium for serial communication
CN112181883B (en) * 2020-09-24 2022-11-08 深圳市乐唯科技开发有限公司 Data transmission method, system and storage medium for serial communication

Also Published As

Publication number Publication date
CN111385158B (en) 2021-11-12

Similar Documents

Publication Publication Date Title
US9049017B2 (en) Efficient TCP ACK prioritization in wireless networks
US7562277B2 (en) Data transmitting/receiving system and method thereof
US7036069B2 (en) Method and entity of packet loss distinction
CN107257270B (en) Data transmission method and system based on hybrid automatic repeat request
US7693058B2 (en) Method for enhancing transmission quality of streaming media
US20090319850A1 (en) Local drop control for a transmit buffer in a repeat transmission protocol device
KR20040023568A (en) Forward error correction system and method for packet based communication systems
JP2005518142A (en) Method and apparatus for performing retransmission by ARQ
US10069595B2 (en) Forward error correction in cellular networks
CN113765626B (en) Data transmission method and device of mobile communication system
US11477170B2 (en) Decoding method and apparatus
CN111385158B (en) Communication method and communication device
JP2003037624A (en) Selective packet retransmission for timing control in transmitter terminal
US11470502B2 (en) Congestion notification by data packet from intermediate node
CN112333850B (en) Method for preventing downlink desynchronization, communication device and readable storage medium
CN114500672A (en) Data transmission method and system
KR100756183B1 (en) Network transmission apparatus having fake-ack layer and tcp packet sending/receiving method using there of
CN105871501B (en) Data transmission method, system and relevant device
CN116896567B (en) Method and device for transmitting data by network layer protocol
KR100780921B1 (en) System and method for sctp transmission using chunk checksum in wireless internet system
EP1733527B1 (en) Technique for handling outdated information units
JP2013157706A (en) Radio communication device and communication control method
CN109246063B (en) L SB (Business card Specification) wrapping optimization method and device
GB2523151A (en) Method and device for data communication in a communication network
Cui et al. Partial CRC checksum of SCTP for error control over wireless networks

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant