Cache-based RTP packet retransmission control method and system

Abstract

The invention discloses a cache-based RTP packet retransmission control method and system, and the method comprises the steps: verifying RTP data transmission requests of a plurality of transmitting ends, and determining the RTP data transmission planning attribute of each transmitting end; according to RTP data sending planning attributes, local cache configuration of each sending end at a data receiving end is set; monitoring RTP packet label change information of each local cache space of the data receiving end within a preset time range; determining a transmission packet loss event of each sending end according to the RTP packet label change information; determining RTP packet information needing to be retransmitted of the plurality of transmitting ends according to the transmission packet loss events of the plurality of transmitting ends; and dynamically adjusting the queue of the RTP packets needing to be retransmitted according to the information of the RTP packets needing to be retransmitted and the network working state. According to the technical scheme, the packet loss detection accuracy and the real-time transmission reliability are improved.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, and in particular to a cache-based RTP packet retransmission control method and system. Background Technology

[0002] Real-time Transport Protocol (RTP) is widely used in network data transmission scenarios. In real-time transmission, RTP packets are transmitted sequentially in a queue. Due to the sending end's own operating status and network transmission status, some RTP packets may fail to reach the receiving end, resulting in packet loss. Existing technologies identify lost RTP packets by comparing their sequence numbers with adjacent received RTP packets, thus instructing the sending end to resend the corresponding RTP packet. While this method can accurately identify and replenish lost RTP packets in a single-sender scenario, it cannot effectively handle both RTP packet loss and multi-source retransmission in a multi-sender scenario. This reduces the accuracy of RTP packet loss detection, easily leading to RTP packet transmission disorder and wasted bandwidth, and ultimately failing to guarantee the reliability of real-time data transmission. Summary of the Invention

[0003] Considering that existing RTP packet loss detection methods are only effective for single-sender scenarios, they are prone to problems such as missed packet loss detection and retransmission disorder in multi-sender scenarios, reducing the accuracy of RTP packet loss detection, easily leading to wasted RTP packet transmission bandwidth, and failing to guarantee the reliability of real-time data transmission. In view of the above problems, this invention is proposed to provide a cache-based RTP packet retransmission control method to overcome or at least partially solve the above problems, including:

[0004] Verify the RTP data transmission requests from several sending ends, determine the RTP data transmission planning attributes of each sending end, and set the local caching configuration for each sending end at the data receiving end based on the RTP data transmission planning attributes.

[0005] Monitor the RTP packet tag change information of each local buffer space of the data receiving end within a preset time range; determine the transmission packet loss event of each sending end based on the RTP packet tag change information;

[0006] Based on the packet loss events of the aforementioned sending ends, determine the RTP packet information that needs to be retransmitted by the aforementioned sending ends; based on the RTP packet information that needs to be retransmitted and the network working status, dynamically adjust the RTP packet queue that needs to be retransmitted.

[0007] Optionally, verify the RTP data transmission requests of several sending ends to determine the RTP data transmission planning attributes of each sending end; based on the RTP data transmission planning attributes, set the local buffer configuration for each sending end at the data receiving end, including:

[0008] Authentication is performed on all senders that initiate data transmission requests, and the data transmission protocols currently supported by all senders are identified in order to identify the senders that initiate RTP data transmission requests.

[0009] The RTP data transmission requests from the plurality of sending ends are parsed to obtain the RTP packet partitioning information and RTP packet transmission bandwidth information corresponding to each of the plurality of sending ends during the data transmission process; wherein, the RTP packet partitioning information refers to the number of RTP packet partitions and the data volume of each RTP packet; the RTP packet transmission bandwidth information refers to the bandwidth allowed to be used when each RTP packet is transmitted; based on the RTP packet partitioning information and the RTP packet transmission bandwidth information, the RTP data transmission planning attribute of each sending end is determined; wherein, the RTP data transmission planning attribute refers to the transmission order and transmission time interval of all RTP packets corresponding to each sending end;

[0010] Based on the sending order and sending time interval, estimate the maximum buffer space capacity that each sending end needs to use locally at the data receiving end; based on the maximum buffer space capacity that each of the several sending ends needs to use, set the buffer configuration for each sending end locally at the data receiving end.

[0011] Optionally, the RTP packet tag change information of each local buffer space of the data receiving end within a preset time range is monitored; based on the RTP packet tag change information, the transmission packet loss event of each sending end is determined, including:

[0012] The system monitors the RTP packet tag sequence number information in each local buffer space of the data receiving end within a preset time range; wherein the RTP packet tag sequence number information refers to the sequence number carried by all RTP packets received by the data receiving end from the same sending end within the preset time range.

[0013] By comparing the RTP packet tag sequence number information corresponding to any two adjacent preset time ranges, the missing RTP packet tag sequence number is obtained, which is used as the RTP packet tag change information.

[0014] Based on the missing RTP packet tag sequence number, a traceability query is returned to the corresponding sender to determine the corresponding sender's packet loss event; wherein the packet loss event refers to an RTP packet that the sender failed to send.

[0015] Optionally, based on the packet loss events of the plurality of sending ends, the information on RTP packets that need to be retransmitted by the plurality of sending ends is determined; based on the information on RTP packets that need to be retransmitted and the network operating status, the queue of RTP packets that need to be retransmitted is dynamically adjusted, including:

[0016] Based on the packet loss events of all sending ends, a collection pool is built within all sending ends; wherein the collection pool is used to store RTP packets that the sending ends failed to send; and based on the RTP packet storage status of the collection pool, the information of the RTP packets that need to be retransmitted by the sending ends is determined.

[0017] Based on the information on RTP packets that need to be retransmitted and the real-time available transmission bandwidth of the network, the retransmission time order and / or time interval of RTP packets in the collection pool of the plurality of sending ends are dynamically adjusted.

[0018] As one aspect of the present invention, embodiments of the present invention also provide a cache-based RTP packet retransmission control system, including:

[0019] The transmission planning determination module is used to verify the RTP data transmission requests of several senders and determine the RTP data transmission planning attributes of each sender.

[0020] The cache configuration setting module is used to set the cache configuration for each sender locally at the data receiver based on the RTP data transmission planning attributes.

[0021] The RTP packet monitoring module is used to monitor the RTP packet tag change information of each local cache space of the data receiving end within a preset time range;

[0022] The packet loss event determination module is used to determine the transmission packet loss event of each sender based on the RTP packet tag change information.

[0023] The RTP packet retransmission determination module is used to determine the RTP packet retransmission information of the plurality of sending ends based on the packet loss events of the plurality of sending ends.

[0024] The retransmission adjustment module is used to dynamically adjust the queue of RTP packets to be retransmitted based on the information of the RTP packets to be retransmitted and the network working status.

[0025] Optionally, the transmission planning determination module is used to verify the RTP data transmission requests of several sending ends and determine the RTP data transmission planning attributes of each sending end, including:

[0026] Authentication is performed on all senders that initiate data transmission requests, and the data transmission protocols currently supported by all senders are identified in order to identify the senders that initiate RTP data transmission requests.

[0027] The RTP data transmission requests from the plurality of sending ends are parsed to obtain the RTP packet partitioning information and RTP packet transmission bandwidth information corresponding to each of the plurality of sending ends during the data transmission process; wherein, the RTP packet partitioning information refers to the number of RTP packet partitions and the data volume of each RTP packet; the RTP packet transmission bandwidth information refers to the bandwidth allowed to be used when each RTP packet is transmitted; based on the RTP packet partitioning information and the RTP packet transmission bandwidth information, the RTP data transmission planning attribute of each sending end is determined; wherein, the RTP data transmission planning attribute refers to the transmission order and transmission time interval of all RTP packets corresponding to each sending end;

[0028] The cache configuration setting module is used to set the cache configuration for each sender locally at the data receiver based on the RTP data transmission planning attributes, including:

[0029] Based on the sending order and sending time interval, estimate the maximum buffer space capacity that each sending end needs to use locally at the data receiving end; based on the maximum buffer space capacity that each of the several sending ends needs to use, set the buffer configuration for each sending end locally at the data receiving end.

[0030] Optionally, the RTP packet monitoring module is used to monitor the RTP packet tag change information of each local buffer space of the data receiving end within a preset time range, including:

[0031] The system monitors the RTP packet tag sequence number information in each local buffer space of the data receiving end within a preset time range; wherein the RTP packet tag sequence number information refers to the sequence number carried by all RTP packets received by the data receiving end from the same sending end within the preset time range.

[0032] By comparing the RTP packet tag sequence number information corresponding to any two adjacent preset time ranges, the missing RTP packet tag sequence number is obtained, which is used as the RTP packet tag change information.

[0033] The packet loss event determination module is used to determine the transmission packet loss event for each sender based on the RTP packet tag change information, including:

[0034] Based on the missing RTP packet tag sequence number, a traceability query is returned to the corresponding sender to determine the corresponding sender's packet loss event; wherein the packet loss event refers to an RTP packet that the sender failed to send.

[0035] Optionally, the RTP packet retransmission determination module is used to determine the RTP packet retransmission information of the plurality of sending ends based on the packet loss events of the plurality of sending ends, including:

[0036] Based on the packet loss events of all sending ends, a collection pool is built within all sending ends; wherein the collection pool is used to store RTP packets that the sending ends failed to send; and based on the RTP packet storage status of the collection pool, the information of the RTP packets that need to be retransmitted by the sending ends is determined.

[0037] The retransmission adjustment module is used to dynamically adjust the queue of RTP packets to be retransmitted based on the RTP packet retransmission information and network operating status, including:

[0038] Based on the information on RTP packets that need to be retransmitted and the real-time available transmission bandwidth of the network, the retransmission time order and / or time interval of RTP packets in the collection pool of the plurality of sending ends are dynamically adjusted.

[0039] The beneficial effects of the above-mentioned technical solutions provided in the embodiments of the present invention include at least the following:

[0040] This invention provides a cache-based RTP packet retransmission control method and system. The method verifies RTP data transmission requests from multiple sending ends, determines the RTP data transmission planning attributes of each sending end, sets the local cache configuration for each sending end at the data receiving end based on the RTP data transmission planning attributes, monitors RTP packet tag changes in each cache space at the data receiving end within a preset time range, determines packet loss events for each sending end based on the RTP packet tag changes, determines the RTP packets requiring retransmission from multiple sending ends based on the packet loss events, and dynamically adjusts the RTP packet retransmission queue based on the retransmission information and network operating status. By setting the local cache configuration for multiple sending ends at the data receiving end, the method accurately identifies the packet loss events of each sending end and adjusts RTP packet retransmission based on network operating status, thereby improving the accuracy of packet loss detection and the reliability of real-time transmission.

[0041] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0042] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0043] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0044] Figure 1 This is a flowchart illustrating the cache-based RTP packet retransmission control method provided in this embodiment of the invention.

[0045] Figure 2 This is a schematic diagram of the structure of the cache-based RTP packet retransmission control system provided in an embodiment of the present invention. Detailed Implementation

[0046] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0047] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," "outer," "far," "near," "front," and "rear," etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the accompanying drawings and are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0048] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0049] Please see Figure 1 As shown, an embodiment of this application provides a cache-based RTP packet retransmission control method. This cache-based RTP packet retransmission control method includes:

[0050] Verify the RTP data transmission requests from several sending ends and determine the RTP data transmission planning attributes for each sending end; based on the RTP data transmission planning attributes, set the local caching configuration for each sending end at the data receiving end.

[0051] Monitor the RTP packet tag change information of each local buffer space of the data receiving end within a preset time range; determine the transmission packet loss event of each sending end based on the RTP packet tag change information;

[0052] Based on packet loss events at several sending ends, determine the RTP packet information that needs to be retransmitted at several sending ends; and dynamically adjust the RTP packet queue that needs to be retransmitted based on the RTP packet information that needs to be retransmitted and the network working status.

[0053] The beneficial effects of the above embodiments are that the cache-based RTP packet retransmission control method accurately identifies the transmission packet loss event of each sender by setting the local cache configuration of the data receiver for multiple senders, and adjusts the RTP packet retransmission in combination with the network working status, thereby improving the accuracy of packet loss detection and the reliability of real-time transmission.

[0054] In another embodiment, the RTP data transmission requests of several sending ends are verified to determine the RTP data transmission planning attributes of each sending end; based on the RTP data transmission planning attributes, a local buffer configuration is set for each sending end at the data receiving end, including:

[0055] Authentication is performed on all senders that initiate data transmission requests, and the data transmission protocols currently supported by all senders are identified in order to identify the senders that initiate RTP data transmission requests.

[0056] The RTP data transmission requests from several sending ends are parsed to obtain the RTP packet partitioning information and RTP packet transmission bandwidth information for each sending process at each sending end. The RTP packet partitioning information refers to the number of RTP packet partitions and the data size of each RTP packet; the RTP packet transmission bandwidth information refers to the bandwidth allowed for each RTP packet transmission. Based on the RTP packet partitioning information and the RTP packet transmission bandwidth information, the RTP data transmission planning attributes for each sending end are determined. The RTP data transmission planning attributes refer to the transmission order and transmission time interval of all RTP packets corresponding to each sending end.

[0057] Based on the sending order and sending time interval, estimate the maximum buffer space capacity that each sender needs to use locally at the data receiver; based on the maximum buffer space capacity that each sender needs to use locally at the data receiver, set the buffer configuration for each sender locally at the data receiver.

[0058] The beneficial effects of the above embodiments are that, in practical work, the sending end can select a suitable protocol for data transmission according to its own needs. To cope with packet loss in real-time transmission protocol usage scenarios, the data transmission protocols supported by the sending end are first screened, and the data transmission protocols currently supported by each sending end that initiates a data transmission request are authenticated and identified. Several sending ends that support real-time transmission protocols are then identified, i.e., several sending ends that initiate RTP data transmission requests are determined. When the sending end performs real-time data transmission, it divides the data it needs to send into several RTP packets. The total number of RTP packet divisions and the data volume of each RTP packet are not fixed but vary depending on the data to be sent. Furthermore, the transmission bandwidth required for each RTP packet transmission is also different; generally, the larger the data volume of the RTP packet, the larger the required transmission bandwidth. The RTP packet situation corresponding to different sending ends during data transmission also varies under different circumstances. To ensure that each sending end can stably send RTP packets, the sending order and sending time interval of all RTP packets corresponding to each sending end are determined based on the RTP packet division information and RTP packet transmission bandwidth information during data transmission, so that each sending end sends all RTP packets in an orderly manner.

[0059] Furthermore, after the sending end sends an RTP packet to the receiving end, it stores the completed RTP packet locally on the receiving end. Simultaneously, the receiving end also stores the position information of the completed RTP packet within the entire RTP packet queue. Ideally, when no RTP packet loss occurs at the sending end, the RTP packets received locally by the receiving end should be continuous. This continuity is mainly reflected in the continuity of the position information of all RTP packets. To ensure that the receiving end has sufficient buffer space to temporarily store and analyze RTP packets received in the current time interval, the maximum buffer space capacity required by each sending end on the receiving end is estimated based on the sending order, sending time interval, and data size of each RTP packet. Based on the maximum buffer space capacity required by each sending end, a buffer configuration is set for each sending end on the receiving end, ensuring that each sending end has corresponding buffer space on the receiving end, thus meeting the requirement for independent analysis of RTP packets from each sending end.

[0060] In one embodiment, the above-mentioned "authenticating all senders that initiate data transmission requests, identifying the data transmission protocols currently supported by all senders, and thereby identifying several senders that initiate RTP data transmission requests" can be implemented as the following sub-steps:

[0061] Step S11: The target data receiver sends a protocol capability probe request to each sender. The request contains an RTP protocol feature identifier sequence list. The response time of each sender to each RTP protocol feature probe request is determined based on the response time of each sender returning the response message of the request.

[0062] Specifically, the target data receiver (which is the authentication entity and can select one data receiver as the target data receiver) sends a protocol capability probe request containing an ordered sequence list of RTP protocol feature identifiers to the sender i. This request is used to inquire whether the sender supports each RTP protocol feature in the sequence list; the time of sending this request is recorded as the request sending timestamp.

[0063] Upon receiving the request, sender i generates a response message containing whether it supports each RTP protocol feature in the sequence list and returns it to the target data receiver. The target data receiver, after receiving and verifying the response message, records its reception timestamp. Based on the request sending timestamp and the response receiving timestamp, the unified response time of sender i for this round of protocol capability probing is calculated and denoted as . This unified response time Assign a value to each RTP protocol feature identifier in the request list. That is, for the first RTP feature identifier in the list... One characteristic identifier (of which) (where m is the list length), the sending end i controls the list. Response time of an RTP feature detection request All were recorded as :

[0064] If within the preset response timeout threshold If the target data receiver does not receive the aforementioned response message from sender i, then sender i will... Response time of each RTPRTP feature probe request All were recorded as .

[0065] Step S12: Determine the dynamic support level of each sender for each RTP protocol feature based on the response time of each sender to each RTP protocol feature probe request.

[0066] Wherein, the dynamic support of sender i for the k-th RTP protocol feature. It can be calculated according to the following formula (1):

[0067] (1)

[0068] in, This is a preset global optimal response time reference value, in units of time; This is the preset response timeout threshold, expressed in time units. Greater than .

[0069] in, The preset value can be based on the sum of the minimum theoretical round-trip time (RTT) of the network infrastructure and the basic overhead of the protocol stack processing. For example, it can be determined by doubling the typical minimum one-way transmission delay of the network environment where the target data receiver is located (e.g., 1 millisecond for a local area network, and estimated based on the physical distance for a wide area network), and adding a fixed protocol processing margin (e.g., 2 milliseconds). For example, in a local area network environment, it can be... Set to 5 milliseconds. This is based on the application layer's tolerance limit for real-time interaction, which can be preset. For example, the maximum end-to-end latency acceptable to the target real-time application (such as audio and video calls) can be subtracted from the time consumed in encoding, decoding, and rendering, with the remaining amount serving as the maximum allowable time for network transmission and protocol response. For instance, for a video conferencing application requiring 200 milliseconds of end-to-end latency, the maximum allowable time for network transmission and protocol response can be... The initial value is set to 50 milliseconds. In one implementation, the system may use a default set of initial values ​​(e.g., ...). It also allows system administrators to manually configure and adjust the configuration based on the actual network deployment scenario and application requirements.

[0070] According to formula (1), when the sender's response time reaches or exceeds the optimal baseline, a full support score (1.0) is directly assigned, indicating that the requirements are fully met; when the response time is between the optimal and timeout, the support score decreases linearly with increasing latency, directly reflecting performance degradation; when the response time exceeds... When the support drops to zero, the formula (1) transforms the abstract protocol support into a stable and fair score through quantification, which not only incentivizes the sender to optimize performance, but also provides a reliable and standardized basis for subsequent admission decisions, ensuring the objectivity of the authentication process and the robustness of the system.

[0071] Step S13: For each sender, determine its multidimensional fusion score based on its historical transmission behavior data.

[0072] The multidimensional fusion score for each transmitter can be determined according to the following formula (2):

[0073] (2)

[0074] in, The multidimensional fusion score corresponding to sender i; This is a preset adjustment parameter, with a value range of 2 to 10. For example, a value of 5 is used to control the stability score. For the final score Sensitivity to impact;

[0075] in, Let i be the entropy stability index of the sending end;

[0076] ;

[0077] in, ; The actual entropy of sender i; For the sending end The first preset historical time period The ratio of the number of RTP packets sent within a preset time period to the total number of all RTP packets sent by the sending end i within a first preset historical time period; The total number of preset time periods into which the first preset historical time period is divided; , The theoretical maximum entropy of sender i; The method for determining this quantifies the regularity of historical traffic at sender i. The closer it is to 1, the more stable and predictable the sending rhythm of sender i is.

[0078] in, The modified burst fitness coefficient of sender i; ;

[0079] in, , Let be the burst fitness coefficient of transmitter i; A preset positive constant is introduced to prevent the denominator from being zero (preferably, its value should be less than 1, for example, ). );

[0080] This represents the arithmetic mean of the RTP data transmission rate samples of sender i during all burst transmission periods within the second preset historical time period; This represents the standard deviation of the RTP data transmission rate sample value of sender i during all burst transmission periods within the second preset historical time period;

[0081] The specific acquisition method is as follows: Within the second preset historical time period prior to the current moment, the RTP data transmission rate of sender i (i.e., the amount of effective RTP protocol data successfully transmitted to the target data receiver per unit time) is monitored in real time, and this rate is sampled at a preset sampling period (e.g., per second). Based on this rate sampling sequence, its average value within the most recent preset time window (e.g., the past 60 seconds) is calculated and recorded as the baseline average rate. Periods within the second preset historical time period that have multiple consecutive sampling periods, and where the rate sampled in each sampling period exceeds the baseline average rate by a certain set multiple (e.g., twice), are defined as burst transmission periods. The rate sampling values ​​within all burst transmission periods are statistically analyzed, and the arithmetic mean of these rate sampling values ​​is calculated. This arithmetic mean is the... Calculate the standard deviation of these rate sample values; this standard deviation is... .

[0082] It assesses the ability of sender i to maintain high and stable throughput during traffic bursts. A large value indicates the average throughput during a burst ( High and volatile The `max(1, ·)` operation ensures that stable transmitters without significant bursts of traffic are not penalized. The value is 1.

[0083] This represents the timing continuity index of sender i, used to measure the proportion of RTP packets arriving at the target data receiver in order, reflecting the reliability of transmission; where, The principle is as follows: At the target data receiving end, the most recent data from the sending end i is... The sequence numbers of 1000 (e.g., 1000) RTP packets are checked to count the number of out-of-order packets. ; This is the disorder penalty adjustment coefficient, and its value range is... to This is used to adjust the sensitivity of the timing continuity score according to different real-time transmission scenarios; the default value can be 1.

[0084] Step S14: For each sender, determine whether to mark the sender as the sender that initiated the RTP data transmission request based on its dynamic support for each RTP protocol feature and the corresponding multi-dimensional fusion score.

[0085] Specifically, for each sender, when the sender simultaneously meets the protocol support basic conditions and the transmission behavior compliance conditions, the sender is identified as the sender that initiated the RTP data transmission request; wherein, the protocol support basic conditions are that the dynamic support of the sender for each RTP protocol feature is greater than zero; the transmission behavior compliance conditions are that the multi-dimensional fusion score corresponding to the sender is equal to or greater than the preset score threshold.

[0086] The beneficial effects of the above technical solution are as follows:

[0087] The protocol capability detection and dynamic support calculation mechanism designed in steps S11 and S12 enables an accurate assessment of the sender's RTP protocol support capability. Traditional authentication relies solely on static protocol declarations, while this invention, by measuring actual response time and mapping uniform time consumption to support levels for various features, can not only identify whether the sender claims to support RTP but also evaluate the implementation efficiency and response agility of its protocol stack. This performance-based quantitative screening eliminates the participation of slow-responding or poorly implemented senders in real-time sessions from the outset, laying a reliable data source foundation for subsequent buffer allocation and retransmission coordination, and reducing the risk of packet loss or congestion caused by the sender's own performance limitations.

[0088] Step S13 introduces a multi-dimensional fusion scoring model based on entropy stability, burst adaptability, and temporal continuity, overcoming the limitations of evaluating senders from a single dimension. This model profiles the historical and real-time performance of senders from three core dimensions: regularity of transmission behavior, network stress adaptability, and transmission reliability. This allows the system to accurately identify senders that not only have complete protocol support but also exhibit high stability and resilience in actual transmission behavior. Using this score as an admission criterion ensures that the group of senders allowed into the system possesses high predictability and strong anti-interference capabilities. This makes subsequent independent planning of caching, packet loss monitoring, and retransmission coordination strategies more efficient and accurate, thereby optimizing overall system resource utilization and improving the transmission reliability of multi-stream concurrency.

[0089] In summary, this series of steps together constitutes a pre-emptive intelligent admission filter. Through a multi-dimensional and quantitative evaluation system, it constructs a transmission environment composed of high-performance and high-reliability transmitters, alleviating problems such as packet loss detection interference and retransmission scheduling disorder caused by inconsistent source quality in multi-transmitter scenarios. This allows the cache management and retransmission control mechanism of this invention to operate under better input conditions, thereby synergistically amplifying the overall solution's technical effects in improving packet loss detection accuracy and ensuring real-time transmission reliability.

[0090] In another embodiment, the RTP packet tag change information of each local buffer space of the data receiving end is monitored within a preset time range; based on the RTP packet tag change information, the transmission packet loss event of each sending end is determined, including:

[0091] Monitor the RTP packet tag sequence number information of each buffer space on the local data receiving end within a preset time range; where RTP packet tag sequence number information refers to the sequence number carried by all RTP packets from the same sending end that the local data receiving end has received within the preset time range.

[0092] By comparing the RTP packet tag sequence number information corresponding to any two adjacent preset time ranges, the missing RTP packet tag sequence number is obtained, which is used as the RTP packet tag change information.

[0093] Based on the missing RTP packet tag sequence number, a traceback query is returned to the corresponding sender to determine the corresponding sender's packet loss event; where a packet loss event refers to an RTP packet that the sender failed to send.

[0094] The beneficial effect of the above embodiments is that each buffer space on the local side of the data receiving end is periodically monitored to obtain the RTP packet tag sequence number information of each buffer space within each preset time range. The preset time range is a series of time ranges sequentially extracted along the time-shifting direction at preset time differences within a fixed time-length window. Then, the RTP packet tag sequence number information corresponding to any two adjacent preset time ranges is compared to obtain the missing RTP packet tag sequence numbers, i.e., the missing sequence numbers that cause the sequence numbers to be discontinuous at the sequence number design level. Finally, based on the missing RTP packet tag sequence numbers, a traceback query is returned to the corresponding sending end, comparing the missing RTP packet tag sequence numbers with the tag sequence numbers of all RTP packets originally planned to be sent by the sending end, thereby identifying the RTP packets that the sending end failed to send, providing an accurate basis for subsequently instructing the sending end to resend RTP packets.

[0095] In another embodiment, based on packet loss events at several sending ends, information on RTP packets requiring retransmission is determined for several sending ends; the queue of RTP packets requiring retransmission is dynamically adjusted based on the information on RTP packets requiring retransmission and the network operating status, including:

[0096] Based on the packet loss events of all senders, a collection pool is built within all senders; the collection pool is used to store RTP packets that the senders failed to send; based on the RTP packet storage status in the collection pool, information on RTP packets that need to be retransmitted by several senders is determined.

[0097] Based on the information on RTP packets that need to be retransmitted and the real-time available transmission bandwidth of the network, the retransmission time order and / or time interval of RTP packets in the collection pool of several sending ends are dynamically adjusted.

[0098] The beneficial effects of the above embodiments, in practical work, are that, based on the packet loss time of all sending ends, a collection pool is built within each sending end to store RTP packets that were not successfully sent in the previous transmission. It can be understood that the RTP packets stored in the collection pool serve as the data source for subsequent retransmissions. Based on the RTP packet storage status in the collection pool (e.g., the length of time they have been stored), information on RTP packets that need to be retransmitted by several sending ends is determined. Generally, the longer the storage time, the higher the priority of retransmission. Furthermore, based on the information on RTP packets to be retransmitted and the real-time available network bandwidth, the retransmission time order and / or time interval of RTP packets in the collection pools of several sending ends are dynamically adjusted. For example, when the real-time available transmission bandwidth is small and the total amount of RTP packets to be retransmitted is large, priority is given to sending individual RTP packets with smaller data sizes and / or increasing the transmission time interval between two adjacent RTP packets during retransmission, thereby improving the retransmission efficiency and reliability of RTP packets while fully utilizing network bandwidth.

[0099] Please see Figure 2 As shown, an embodiment of this application provides a cache-based RTP packet retransmission control system. This cache-based RTP packet retransmission control system includes:

[0100] The transmission planning determination module is used to verify the RTP data transmission requests of several senders and determine the RTP data transmission planning attributes of each sender.

[0101] The cache configuration setting module is used to set the cache configuration for each sender on the local data receiver based on the RTP data transmission planning attributes.

[0102] The RTP packet monitoring module is used to monitor the changes in RTP packet tags in each local buffer space of the data receiving end within a preset time range.

[0103] The packet loss event determination module is used to determine the packet loss event of each sender based on the RTP packet tag change information.

[0104] The RTP packet retransmission determination module is used to determine the RTP packet retransmission information of several senders based on the packet loss events of several senders.

[0105] The retransmission adjustment module is used to dynamically adjust the queue of RTP packets that need to be retransmitted based on the information of RTP packets that need to be retransmitted and the network working status.

[0106] The beneficial effects of the above embodiments are that the cache-based RTP packet retransmission control system accurately identifies the packet loss event of each sender by setting the local cache configuration of the data receiver for multiple senders, and adjusts the RTP packet retransmission in combination with the network working status, thereby improving the accuracy of packet loss detection and the reliability of real-time transmission.

[0107] In another embodiment, the transmission planning determination module is used to verify the RTP data transmission requests of several transmitters and determine the RTP data transmission planning attributes of each transmitter, including:

[0108] Authentication is performed on all senders that initiate data transmission requests, and the data transmission protocols currently supported by all senders are identified in order to identify the senders that initiate RTP data transmission requests.

[0109] The RTP data transmission requests from several sending ends are parsed to obtain the RTP packet partitioning information and RTP packet transmission bandwidth information for each sending process at each sending end. The RTP packet partitioning information refers to the number of RTP packet partitions and the data size of each RTP packet; the RTP packet transmission bandwidth information refers to the bandwidth allowed for each RTP packet transmission. Based on the RTP packet partitioning information and the RTP packet transmission bandwidth information, the RTP data transmission planning attributes for each sending end are determined. The RTP data transmission planning attributes refer to the transmission order and transmission time interval of all RTP packets corresponding to each sending end.

[0110] The cache configuration setting module is used to set the cache configuration for each sender locally at the data receiver based on the RTP data transmission planning attributes, including:

[0111] Based on the sending order and sending time interval, estimate the maximum buffer space capacity that each sender needs to use locally at the data receiver; based on the maximum buffer space capacity that each sender needs to use locally at the data receiver, set the buffer configuration for each sender locally at the data receiver.

[0112] In another embodiment, the RTP packet monitoring module is used to monitor RTP packet tag change information in each local buffer space of the data receiver within a preset time range, including:

[0113] Monitor the RTP packet tag sequence number information of each buffer space on the local data receiving end within a preset time range; where RTP packet tag sequence number information refers to the sequence number carried by all RTP packets from the same sending end that the local data receiving end has received within the preset time range.

[0114] By comparing the RTP packet tag sequence number information corresponding to any two adjacent preset time ranges, the missing RTP packet tag sequence number is obtained, which is used as the RTP packet tag change information.

[0115] The packet loss event determination module is used to determine the transmission packet loss events for each sender based on RTP packet tag change information, including:

[0116] Based on the missing RTP packet tag sequence number, a traceback query is returned to the corresponding sender to determine the corresponding sender's packet loss event; where a packet loss event refers to an RTP packet that the sender failed to send.

[0117] In another embodiment, the RTP packet retransmission determination module is used to determine, based on several packet loss events of several sending ends, several RTP packet retransmission information of several sending ends, including:

[0118] Based on the packet loss events of all senders, a collection pool is built within all senders; the collection pool is used to store RTP packets that the senders failed to send; based on the RTP packet storage status in the collection pool, information on RTP packets that need to be retransmitted by several senders is determined.

[0119] The retransmission adjustment module dynamically adjusts the queue of RTP packets to be retransmitted based on the information about the RTP packets to be retransmitted and the network operating status. This includes:

[0120] Based on the information on RTP packets that need to be retransmitted and the real-time available transmission bandwidth of the network, the retransmission time order and / or time interval of RTP packets in the collection pool of several sending ends are dynamically adjusted.

[0121] The operation and effect of the cache-based RTP packet retransmission control system of the present invention are consistent with the above-mentioned cache-based RTP packet retransmission control method, and the cache-based RTP packet retransmission control system will not be described again here.

[0122] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. This disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims. Thus, if these modifications and variations of the invention fall within the scope of the claims of the invention and their equivalents, the invention is also intended to include these modifications and variations.

Claims

1. A cache-based RTP packet retransmission control method, characterized in that, include: Verify the RTP data transmission requests from several senders and determine the RTP data transmission planning attributes for each sender; Based on the RTP data transmission planning attributes, configure the local caching settings for each sender at the data receiver. Monitor the RTP packet tag change information of each local buffer space of the data receiving end within a preset time range; determine the transmission packet loss event of each sending end based on the RTP packet tag change information; Based on the packet loss events of the aforementioned sending ends, determine the RTP packet information that needs to be retransmitted by the aforementioned sending ends; based on the RTP packet information that needs to be retransmitted and the network working status, dynamically adjust the RTP packet queue that needs to be retransmitted.

2. The cache-based RTP packet retransmission control method as described in claim 1, characterized in that: Verify the RTP data transmission requests from several senders and determine the RTP data transmission planning attributes for each sender; Based on the RTP data transmission planning attributes, configure the local buffering for each sender at the data receiver, including: Authentication is performed on all senders that initiate data transmission requests, and the data transmission protocols currently supported by all senders are identified in order to identify the senders that initiate RTP data transmission requests. The RTP data transmission requests from the plurality of sending ends are parsed to obtain the RTP packet partitioning information and RTP packet transmission bandwidth information corresponding to each of the plurality of sending ends during the data transmission process; wherein, the RTP packet partitioning information refers to the number of RTP packet partitions and the data volume of each RTP packet; the RTP packet transmission bandwidth information refers to the bandwidth allowed to be used when each RTP packet is transmitted; based on the RTP packet partitioning information and the RTP packet transmission bandwidth information, the RTP data transmission planning attribute of each sending end is determined; wherein, the RTP data transmission planning attribute refers to the transmission order and transmission time interval of all RTP packets corresponding to each sending end; Based on the sending order and sending time interval, estimate the maximum buffer space capacity that each sending end needs to use locally at the data receiving end; based on the maximum buffer space capacity that each of the several sending ends needs to use, set the buffer configuration for each sending end locally at the data receiving end.

3. The cache-based RTP packet retransmission control method as described in claim 1, characterized in that: Monitor the RTP packet tag change information of each local cache space of the data receiving end within a preset time range; Based on the RTP packet tag change information, determine the packet loss event for each sender, including: The RTP packet tag sequence number information is monitored in each local buffer space of the data receiving end within a preset time range; wherein the RTP packet tag sequence number information refers to the sequence number carried by all RTP packets received by the data receiving end from the same sending end within the preset time range. By comparing the RTP packet tag sequence number information corresponding to any two adjacent preset time ranges, the missing RTP packet tag sequence number is obtained, which is used as the RTP packet tag change information. Based on the missing RTP packet tag sequence number, a traceability query is returned to the corresponding sender to determine the corresponding sender's packet loss event; wherein the packet loss event refers to an RTP packet that the sender failed to send.

4. The cache-based RTP packet retransmission control method as described in claim 1, characterized in that: Based on the packet loss events of the aforementioned sending ends, determine the RTP packet retransmission information of the aforementioned sending ends; based on the RTP packet retransmission information and network operating status, dynamically adjust the RTP packet retransmission queue, including: Based on the packet loss events of all sending ends, a collection pool is built within all sending ends; wherein the collection pool is used to store RTP packets that the sending ends failed to send; and based on the RTP packet storage status of the collection pool, the information of the RTP packets that need to be retransmitted by the sending ends is determined. Based on the information on RTP packets that need to be retransmitted and the real-time available transmission bandwidth of the network, the retransmission time order and / or time interval of RTP packets in the collection pool of the plurality of sending ends are dynamically adjusted.

5. A cache-based RTP packet retransmission control system, characterized in that, include: The transmission planning determination module is used to verify the RTP data transmission requests of several senders and determine the RTP data transmission planning attributes of each sender. The cache configuration setting module is used to set the cache configuration for each sender locally at the data receiver based on the RTP data transmission planning attributes. The RTP packet monitoring module is used to monitor the RTP packet tag change information of each local cache space of the data receiving end within a preset time range; The packet loss event determination module is used to determine the transmission packet loss event of each sender based on the RTP packet tag change information. The RTP packet retransmission determination module is used to determine the RTP packet retransmission information of the plurality of sending ends based on the packet loss events of the plurality of sending ends. The retransmission adjustment module is used to dynamically adjust the queue of RTP packets to be retransmitted based on the information of the RTP packets to be retransmitted and the network working status.

6. The cache-based RTP packet retransmission control system as described in claim 5, characterized in that: The transmission planning determination module is used to verify the RTP data transmission requests of several sending ends and determine the RTP data transmission planning attributes of each sending end, including: Authentication is performed on all senders that initiate data transmission requests, and the data transmission protocols currently supported by all senders are identified in order to identify the senders that initiate RTP data transmission requests. The RTP data transmission requests from the plurality of sending ends are parsed to obtain the RTP packet partitioning information and RTP packet transmission bandwidth information corresponding to each of the plurality of sending ends during the data transmission process; wherein, the RTP packet partitioning information refers to the number of RTP packet partitions and the data volume of each RTP packet; the RTP packet transmission bandwidth information refers to the bandwidth allowed to be used when each RTP packet is transmitted; based on the RTP packet partitioning information and the RTP packet transmission bandwidth information, the RTP data transmission planning attribute of each sending end is determined; wherein, the RTP data transmission planning attribute refers to the transmission order and transmission time interval of all RTP packets corresponding to each sending end; The cache configuration setting module is used to set the cache configuration for each sender locally at the data receiver based on the RTP data transmission planning attributes, including: Based on the sending order and sending time interval, estimate the maximum buffer space capacity that each sending end needs to use locally at the data receiving end; based on the maximum buffer space capacity that each of the several sending ends needs to use, set the buffer configuration for each sending end locally at the data receiving end.

7. The cache-based RTP packet retransmission control system as described in claim 5, characterized in that: The RTP packet monitoring module is used to monitor the RTP packet tag change information of each local cache space of the data receiving end within a preset time range, including: The RTP packet tag sequence number information is monitored in each local buffer space of the data receiving end within a preset time range; wherein the RTP packet tag sequence number information refers to the sequence number carried by all RTP packets received by the data receiving end from the same sending end within the preset time range. By comparing the RTP packet tag sequence number information corresponding to any two adjacent preset time ranges, the missing RTP packet tag sequence number is obtained, which is used as the RTP packet tag change information. The packet loss event determination module is used to determine the transmission packet loss event for each sender based on the RTP packet tag change information, including: Based on the missing RTP packet tag sequence number, a traceability query is returned to the corresponding sender to determine the corresponding sender's packet loss event; wherein the packet loss event refers to an RTP packet that the sender failed to send.

8. The cache-based RTP packet retransmission control system as described in claim 5, characterized in that: The RTP packet retransmission determination module is used to determine the RTP packet retransmission information of the plurality of sending ends based on the packet loss events of the plurality of sending ends, including: Based on the packet loss events of all sending ends, a collection pool is built within all sending ends; wherein the collection pool is used to store RTP packets that the sending ends failed to send; and based on the RTP packet storage status of the collection pool, the information of the RTP packets that need to be retransmitted by the sending ends is determined. The retransmission adjustment module is used to dynamically adjust the queue of RTP packets to be retransmitted based on the RTP packet retransmission information and network operating status, including: Based on the information on RTP packets that need to be retransmitted and the real-time available transmission bandwidth of the network, the retransmission time order and / or time interval of RTP packets in the collection pool of the plurality of sending ends are dynamically adjusted.

Images