CN111131179B - Service processing method, device, network equipment and storage medium - Google Patents
Service processing method, device, network equipment and storage medium Download PDFInfo
- Publication number
- CN111131179B CN111131179B CN201911233169.0A CN201911233169A CN111131179B CN 111131179 B CN111131179 B CN 111131179B CN 201911233169 A CN201911233169 A CN 201911233169A CN 111131179 B CN111131179 B CN 111131179B
- Authority
- CN
- China
- Prior art keywords
- rtp
- receiving
- message
- data stream
- sequence number
- 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.)
- Active
Links
Images
Classifications
-
- 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/80—Responding to QoS
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
-
- 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]
Abstract
The embodiment of the invention relates to the technical field of communication, and discloses a service processing method, which comprises the following steps: judging whether the RTP data stream has packet loss or not; and if the RTP data stream is judged to have packet loss, initiating an RTP retransmission request to a source server of the RTP data stream. The embodiment of the invention also provides a device, network equipment and a storage medium. The service processing method, the device, the network equipment and the storage medium provided by the embodiment of the invention can improve the transmission efficiency of the RTP data stream.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a service processing method and apparatus, a network device, and a storage medium.
Background
Real-time Transport Protocol (RTP) is a network Transport Protocol, provides an end-to-end transmission service with Real-time characteristics for multimedia data, and is widely applied to video conferences, internet televisions and video monitoring.
However, the inventors found that at least the following problems exist in the prior art: during the RTP transmission process, network abnormality or network instability may occur, which causes packet loss of the RTP data stream. When a data receiving terminal finds that a packet loss condition exists in an RTP data stream, a retransmission request is sent to a multicast server, and a retransmitted RTP message occupies RTP uplink and downlink bandwidth resources of a whole transmission link, so that the transmission efficiency of the RTP data stream is low.
Disclosure of Invention
The embodiment of the invention aims to provide a service processing method, a service processing device, network equipment and a storage medium, so that the transmission efficiency of an RTP data stream is improved.
In order to solve the above technical problem, an embodiment of the present invention provides a service processing method, including: judging whether the RTP data stream has packet loss or not; and if the RTP data stream is judged to have packet loss, initiating an RTP retransmission request to a source server of the RTP data stream.
The embodiment of the present invention further provides a service processing apparatus, including: the packet loss judging module is used for judging whether the RTP data stream has packet loss or not; and the retransmission request initiating module is used for initiating an RTP retransmission request to a source server of the RTP data stream when the RTP data stream is judged to have packet loss.
An embodiment of the present invention further provides a network device, including: at least one processor; and a memory communicatively coupled to the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the service processing method.
The embodiment of the invention also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to realize the service processing method.
Compared with the prior art, the embodiment of the invention judges whether the RTP data stream has packet loss, and when the network node equipment judges that the RTP data stream has packet loss, the network node equipment initiates an RTP retransmission request to a source server of the RTP data stream. Because the RTP retransmission request only needs to be transmitted between the network node equipment and the source server of the RTP data stream, and the source server of the RTP data stream only needs to send the retransmitted RTP message to the network node equipment initiating the RTP retransmission request, the transmission is not needed to be carried out on the transmission link of the whole RTP data stream, and the occupied uplink and downlink bandwidth resources of the RTP are less, the transmission efficiency of the RTP data stream can be improved; meanwhile, for some receiving terminals which do not support to initiate the RTP retransmission request, the quality of the RTP data stream received by the receiving terminals can be ensured.
In addition, judging whether the RTP data stream has packet loss includes: judging whether a first sequence number of a currently received RTP message falls in a receiving window or not; if the first sequence number falls in the receiving window, whether packet loss exists in the RTP data stream is judged according to the first sequence number and a second sequence number, and the second sequence number is the current message sequence number of the receiving window. The serial number of the RTP message received currently is judged according to the message serial number of the receiving window, so that whether the RTP data stream has packet loss or not can be judged, and a basis is provided for whether an RTP retransmission request is initiated or not.
In addition, whether packet loss exists in the RTP data stream is judged according to the first sequence number and the second sequence number, which specifically comprises the following steps: calculating the number of lost packets according to the following calculation formula:
dropnum＝NT-(NT-1+1)；
where dropnum is the number of lost packets, NTIs a first sequence number, NT-1Is a second serial number; and when the number of the packet loss is more than zero, judging that the RTP data stream has the packet loss.
In addition, the service processing method further comprises the following steps: judging whether a first sequence number of a currently received RTP message falls in a retransmission window or not; if the first sequence number falls in the retransmission window, judging whether the RTP message exists in an RTP message receiving record or not; and if the RTP message exists in the RTP message receiving record, directly discarding the RTP message. In the process of retransmitting the RTP message, if the retransmitted RTP message arrives in a delayed manner, the RTP retransmission request is initiated again, so that a plurality of retransmitted RTP messages can exist, and if the retransmitted RTP messages all arrive at a receiving terminal, the receiving terminal is impacted, so that the receiving quality of the RTP data stream of the receiving terminal is influenced; meanwhile, downlink bandwidth resources are occupied, and transmission efficiency is reduced; therefore, whether the currently received RTP message is the repeatedly retransmitted RTP message or not is judged according to the RTP message receiving record, and if the currently received RTP message is the repeatedly retransmitted RTP message, the repeatedly retransmitted RTP message is discarded, so that the influence on the receiving quality of the RTP data stream of the receiving terminal can be avoided, meanwhile, the downlink bandwidth resource is saved, and the transmission efficiency of the RTP data stream is improved.
In addition, the service processing method further comprises the following steps: judging whether a first sequence number of a currently received RTP message falls outside a receiving window and a retransmission window; if the first sequence number falls outside the receiving window and the retransmission window, judging whether the receiving time difference is greater than or equal to a preset time threshold value, wherein the receiving time difference is the time difference between the receiving of the RTP message and the receiving of the previous RTP message; if the receiving time difference is larger than or equal to the preset time threshold, the RTP message received currently is forwarded, and the message serial numbers of the receiving window and the retransmission window are updated. When the receiving time difference is larger than or equal to a preset time threshold value due to network abnormality, a retransmission request is initiated for the RTP message with lost packet, and the retransmitted RTP message cannot meet the real-time requirement of the RTP data stream; therefore, when the receiving time difference is greater than or equal to the preset time threshold, the currently received RTP message is directly forwarded, and the real-time performance of the RTP data stream can be ensured.
In addition, after determining whether the receiving time difference is greater than the preset time threshold, the method further includes: and if the receiving time difference is smaller than the preset time threshold, discarding the currently received RTP message. When the receiving time difference is small, the currently received RTP message is directly discarded, so that the interference of noise on the RTP data stream can be avoided, and the transmission quality of the RTP data stream is ensured.
In addition, before determining whether there is packet loss in the RTP data stream, the method further includes: and recording the receiving state of the RTP message by using the bit table to form an RTP message receiving record.
Drawings
One or more embodiments are illustrated by the corresponding figures in the drawings, which are not meant to be limiting.
Fig. 1 is a schematic diagram of a transmission process of an RTP data stream in the prior art;
fig. 2(a) is a schematic diagram of data flow when RTP retransmission is performed in the prior art;
fig. 2(b) is a schematic diagram of data flow when the service processing method provided by the first embodiment of the present invention performs RTP data flow;
fig. 3 is a schematic flow chart of a service processing method according to a first embodiment of the present invention;
fig. 4 is a schematic flowchart of the step of refining S101 in the service processing method according to the first embodiment of the present invention;
fig. 5 is a schematic diagram of a receiving window and a retransmission window in a service processing method according to a first embodiment of the present invention;
FIG. 6 is a diagram illustrating an example of expanding contents of a bitmap record according to the first embodiment of the present invention;
fig. 7 is a schematic flow chart of another service processing method provided in the first embodiment of the present invention;
fig. 8 is a flowchart illustrating a further service processing method according to the first embodiment of the present invention;
fig. 9 is a diagram illustrating a specific flow of a service processing method according to a first embodiment of the present invention;
fig. 10 is a schematic block diagram of a service processing apparatus according to a second embodiment of the present invention;
fig. 11 is a schematic structural diagram of a network device according to a third embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, it will be appreciated by those of ordinary skill in the art that numerous technical details are set forth in order to provide a better understanding of the present application in various embodiments of the present invention. However, the technical solution claimed in the present application can be implemented without these technical details and various changes and modifications based on the following embodiments.
The first embodiment of the present invention relates to a service processing method, which is applied to a network node device in an RTP data stream transmission process, and initiates an RTP retransmission request to a source server of an RTP data stream by determining whether the RTP data stream has a packet loss or not, when determining that the RTP data stream has the packet loss. Because the network node equipment can know whether the RTP data stream has packet loss or not, if the packet loss exists, the network node equipment directly initiates an RTP retransmission request to a source server of the RTP data stream, and the RTP retransmission request and a retransmitted RTP message are not transmitted in the whole transmission link of the RTP data stream, the uplink and downlink bandwidth resources of the RTP can be saved, and the transmission efficiency of the RTP data stream can be improved.
Please refer to fig. 1, which illustrates a transmission process of an RTP data stream in the prior art. Specifically, the user sends an IGMP (network group management protocol) protocol packet through the receiving terminal of the RTP data stream to pull the required multicast data traffic from the server. The intermediate network node equipment produces multicast list items through IGMP snooping or IGMP proxy, and copies and forwards the multicast data stream. When packet loss occurs in the RTP data during transmission, a receiving terminal initiates an RTP retransmission request, and when a source server (multicast server) of the RTP data stream receives the RTP retransmission request, the source server retransmits the lost packet to the receiving terminal.
Please refer to fig. 2(a), which is a schematic diagram illustrating a data flow when an RTP data flow is retransmitted in the prior art. Specifically, when a receiving terminal learns that a packet loss exists in an RTP data stream, a retransmission request is initiated to a multicast server, and after receiving the retransmission request, the multicast server returns a retransmitted RTP packet to the receiving terminal, and the RTP packet passes through a plurality of network nodes such as a gateway, a multicast router, the internet, and the like. There are at least two problems with this approach to RTP retransmission: firstly, when the receiving terminal does not support the initiation of the retransmission request, the lost RTP message cannot be obtained again, the receiving of the complete RTP message by the user is influenced, and the quality of the RTP video watched by the user cannot be ensured; secondly, the RTP retransmission request initiated by the user and the RTP packet retransmitted by the multicast server are transmitted in the whole transmission link, thereby occupying the uplink and downlink bandwidth resources of the RTP, increasing the network load and affecting the transmission efficiency of the RTP data stream.
Please refer to fig. 2(b), which is a schematic diagram of a data flow when the service processing method according to the embodiment of the present invention performs an RTP data flow retransmission. Specifically, a network node device (in the figure, a multicast router is taken as an example) in an RTP data stream transmission process can judge whether a packet loss exists in an RTP data stream, when the packet loss of the RTP data stream is judged, a retransmission request is initiated to a multicast server, the RTP retransmission request is transmitted between the network node device and the multicast server, the multicast server only needs to transmit a retransmitted RTP message to the multicast router, the RTP retransmission request and the retransmitted RTP message do not need to be transmitted on a whole transmission link, and fewer RTP uplink and downlink bandwidth resources are occupied, so that the transmission efficiency of the RTP data stream can be improved; for some receiving terminals which do not support retransmission, the receiving terminals do not need to initiate an RTP retransmission request, so that the quality of the RTP video watched by the user can be ensured.
It should be noted that the network node device may include a device used in the RTP data streaming process, such as a gateway, a router, or a CDN node, that is, a device of an intermediate node.
A specific flow of the service processing method provided by the embodiment of the present invention is shown in fig. 3, and specifically includes the following steps:
s101: and judging whether the RTP data stream has packet loss or not.
S102: and if the RTP data stream is judged to have packet loss, initiating an RTP retransmission request to a source server of the RTP data stream.
The method for determining whether the RTP data stream has packet loss by the network node device may determine whether the packet sequence number of the RTP data stream is continuous, or may be other methods, which is not limited herein.
Specifically, the network node device may determine whether a packet loss occurs in the RTP data stream by using a preset packet loss detection method, and initiate an RTP retransmission request to a source server of the RTP data stream when determining that the packet loss occurs in the RTP data stream.
Compared with the prior art, according to the service processing method provided by the embodiment of the invention, when the network node equipment judges that the RTP data stream has packet loss, the network node equipment initiates an RTP retransmission request to a source server of the RTP data stream. Because the RTP retransmission request only needs to be transmitted between the network node equipment and the source server of the RTP data stream, and the source server of the RTP data stream only needs to send the retransmitted RTP message to the network node equipment initiating the RTP retransmission request, the transmission is not needed to be carried out on the transmission link of the whole RTP data stream, and the occupied uplink and downlink bandwidth resources of the RTP are less, the transmission efficiency of the RTP data stream can be improved; meanwhile, for some receiving terminals which do not support to initiate the RTP retransmission request, the quality of the RTP data stream received by the receiving terminals can be ensured.
In a specific example, in S101, that is, whether there is a packet loss in the RTP data stream is determined, as shown in fig. 4, the method specifically includes the following steps:
s1011: and judging whether the first sequence number of the RTP message received currently falls in the receiving window.
S1012: if the first sequence number falls in the receiving window, whether packet loss exists in the RTP data stream is judged according to the first sequence number and a second sequence number, and the second sequence number is the current message sequence number of the receiving window.
Wherein, the receiving window is composed of a message serial number in a certain range. Referring to fig. 5, the current sequence number in fig. 5 is the current sequence number of the receiving window, i.e. the second sequence number. The interval of the message serial number of the receiving window is [ N, N + N ], and the size of the receiving window is N. Optionally, the size of the receiving window may be determined according to a message receiving rate of an RTP data stream of the network node device, that is, when the message receiving rate is higher, the interval range of the receiving window is larger, and n is larger; when the message receiving rate is low, the interval range of the receiving window is small, and n is small.
It can be understood that to detect packet loss of an RTP data stream, first, the transmission state of an RTP packet needs to be recorded. Optionally, the receiving status of the RTP packet may be recorded by using a bit table. Because the sequence number occupies 16 bits in the format of the RTP packet, the maximum value of the sequence number of the RTP packet is 65535, that is, the range is 0 to 65535. Wherein each byte of the bit table has 8 bits, 8192 bytes are required to represent the serial numbers 0-65535. In the bit of each byte, 1 represents that the RTP message of the serial number is received, and 0 represents that the RTP message of the serial number is not received. For example, bit _ seq [0] records the message receiving status of sequence numbers 0 to 7, and if bit _ seq [0] is 7, that is, the value is 7, the development is as shown in fig. 6, which indicates that the RTP message with sequence numbers 0, 1, and 2 has been received, and the first sequence number of the currently received RTP message is 2.
The receiving state of the RTP message is recorded through the bit table, and the receiving state of each sequence number message can be clearly obtained. Further, an RTP packet reception record may be formed according to the record of the bit table.
It should be understood that the receiving window is updated according to the sequence number of the received RTP packet, so as to determine and process the subsequent received RTP packet.
Specifically, the network node device compares a first sequence number of a currently received RTP packet with a receiving window, and determines whether a packet loss exists in an RTP data stream according to the first sequence number and a second sequence number if the first sequence number falls in the receiving window and indicates that the RTP packet is an RTP packet that needs to be received.
Alternatively, the number of packet losses may be calculated according to the following calculation formula:
dropnum＝NT-(NT-1+1)；
where dropnum is the number of lost packets, NTIs a first sequence number, NT-1Is a second serial number; and when the calculated packet loss number is larger than 0, the network node equipment judges that the RTP data stream has packet loss.
Optionally, if the calculated number of packet losses is greater than or equal to 0, the network node device forwards the currently received packet, updates the current packet sequence number of the receiving window, records the packet receiving time, and moves the receiving window to the right at the same time.
The serial number of the RTP message received currently is judged according to the message serial number of the receiving window, so that whether the RTP data stream has packet loss or not can be judged, and a basis is provided for whether an RTP retransmission request is initiated or not.
In a specific example, as shown in fig. 7, the service processing method provided in the embodiment of the present invention further includes the following steps:
s201: and judging whether the first sequence number of the RTP message received currently falls in a retransmission window.
S202: and if the first sequence number falls in the retransmission window, judging whether the RTP message exists in the RTP message receiving record.
S203: and if the RTP message exists in the RTP message receiving record, directly discarding the RTP message.
The retransmission window is composed of a range of message sequence numbers, please refer to fig. 5, the current sequence number in fig. 5 is also the current sequence number of the retransmission window, the sequence number of the received RTP message can be compared with the current sequence number of the retransmission window, and if the sequence number is smaller than the current sequence number of the retransmission window, it indicates that the RTP message is the retransmitted RTP message. The interval of the message sequence number of the retransmission window is [ N-m, N ], and the size of the retransmission window is m. Optionally, the size of the retransmission window may be determined according to a packet receiving rate of an RTP data stream of the network node device, that is, when the packet receiving rate is higher, an interval range of the retransmission window is larger, and m is larger; when the message receiving rate is low, the interval range of the retransmission window is small, and m is small.
Specifically, the network node device determines a first sequence number of a currently received RTP packet, and if the first sequence number falls within a retransmission window and indicates that the currently received RTP packet is a retransmitted RTP packet, determines whether the RTP packet exists in an RTP packet reception record; if the RTP message exists in the RTP message receiving record, it indicates that the same RTP message has been received by the network node device, and the currently received RTP message is a repeatedly retransmitted RTP message, the RTP message is directly discarded. Optionally, if the result of the determination is that the currently received RTP packet does not exist in the RTP packet receiving record, which indicates that the network node device has not received the RTP packet, the network node device forwards the RTP packet, and records in the RTP packet receiving record, so as to subsequently receive determination and processing of the repeatedly retransmitted RTP packet, update the current serial number of the retransmission window to the first serial number, and move the retransmission window to the right. The RTP packet receiving record may be recorded by the bit table.
In the process of retransmitting the RTP message, if the retransmitted RTP message arrives in a delayed manner, the RTP retransmission request is initiated again, so that a plurality of retransmitted RTP messages can exist, and if the retransmitted RTP messages all arrive at a receiving terminal, the receiving terminal is impacted, so that the receiving quality of the RTP data stream of the receiving terminal is influenced; meanwhile, downlink bandwidth resources are occupied, and transmission efficiency is reduced; therefore, whether the currently received RTP message is the repeatedly retransmitted RTP message or not is judged according to the RTP message receiving record, and if the currently received RTP message is the repeatedly retransmitted RTP message, the repeatedly retransmitted RTP message is discarded, so that the impact on a receiving terminal can be avoided, meanwhile, the downlink bandwidth resource is saved, and the transmission efficiency of the RTP data stream is improved.
In a specific example, as shown in fig. 8, the service processing method provided in the embodiment of the present invention further includes the following steps:
s301: and judging whether the first sequence number of the RTP message received currently falls outside a receiving window and a retransmission window.
S302: if the first sequence number is outside the receiving window and the retransmission window, judging whether the receiving time difference is larger than or equal to a preset time threshold value, wherein the receiving time difference is the time difference between the receiving of the RTP message and the receiving of the previous RTP message.
S303: if the receiving time difference is larger than or equal to the preset time threshold, the RTP message received currently is forwarded, and the message serial numbers of the receiving window and the retransmission window are updated.
S304: and if the receiving time difference is smaller than the preset time threshold, discarding the currently received RTP message.
Specifically, the network node device judges a first sequence number of a currently received RTP packet, and if the first sequence number falls outside a receiving window and a retransmission window, it indicates that network interruption caused by network instability may exist, so that the first sequence number falls outside the receiving window and the retransmission window; the network node equipment judges the receiving time difference between the currently received RTP message and the last RTP message, if the receiving time difference is larger than or equal to a preset time threshold value, the network interruption time is too long, the currently received RTP message is forwarded, and the message serial numbers of the receiving window and the retransmission window are updated. Since the RTP packet is a real-time packet, if the receiving time difference is greater than or equal to the preset time threshold, it is meaningless to initiate an RTP retransmission request for the previously lost RTP packet, so that the currently received RTP packet is forwarded. The preset time threshold value can be set according to actual needs. Optionally, the preset time threshold may be equal to the number of packet sequence numbers of the receiving window divided by the average receiving rate of the RTP packets.
If the receiving time difference is smaller than the time threshold, it indicates that it may be an unrelated RTP data stream caused by the network anomaly, i.e. the "noise" or "packet" of the RTP data stream, and the network node device directly discards the currently received RTP packet.
When the receiving time difference is larger than or equal to a preset time threshold value due to network abnormality, a retransmission request is initiated for the RTP message with lost packet, and the retransmitted RTP message cannot meet the real-time requirement of the RTP data stream; therefore, when the receiving time difference is greater than or equal to the preset time threshold, the currently received RTP message is directly forwarded, and the real-time performance of the RTP data stream can be ensured; when the receiving time difference is small, the currently received RTP message is directly discarded, so that the interference of noise on the RTP data stream can be avoided, and the transmission quality of the RTP data stream is ensured.
Please refer to fig. 9, which is a flowchart illustrating a specific flow of a service processing method according to an embodiment of the present invention. Specifically, the network node device performs window judgment on a serial number of a currently received RTP packet, determines whether the currently received RTP packet is a repeatedly retransmitted RTP packet according to a receiving record of the RTP packet if the serial number is in a retransmission window, and performs statistics on a discarding record of the RTP packet and discards the RTP packet if the currently received RTP packet is the repeatedly retransmitted RTP packet; if the RTP message is not the repeated retransmission RTP message, counting the retransmission message of the RTP message and forwarding the RTP message; if the serial number of the currently received RTP message is in the receiving window, calculating the number of packet losses (dropnum), if the number of packet losses (dropnum) is more than 0, counting the number of packet losses, updating the receiving serial number and the message receiving time of the RTP, counting the receiving of the RTP message, and then moving the receiving window and the retransmission window to the right and forwarding the RTP message; if the number of the lost packets is equal to 0, directly updating the receiving sequence number and the message receiving time of the RTP, carrying out RTP message receiving statistics, and then moving a receiving window and a retransmission window to the right and forwarding the RTP message; if the serial number of the RTP message received currently is outside the receiving window and the retransmission window, calculating the receiving time interval of the RTP message, if the time interval is more than or equal to the number of the message serial numbers of the receiving window except the average receiving rate of the RTP message, updating the receiving serial number and the message receiving time of the RTP message, carrying out RTP message receiving statistics, and then moving the receiving window and the retransmission window to the right and forwarding the RTP message; if the time interval is smaller than the number of the message serial numbers of the receiving window divided by the average receiving rate of the RTP messages, counting the discarding records of the RTP messages and discarding the RTP messages.
The steps of the above methods are divided for clarity, and the implementation may be combined into one step or split some steps, and the steps are divided into multiple steps, so long as the steps contain the same logical relationship, which is within the protection scope of the present patent; it is within the scope of the patent to add insignificant modifications to the algorithms or processes or to introduce insignificant design changes to the core design without changing the algorithms or processes.
A second embodiment of the present invention relates to a service processing apparatus, as shown in fig. 10, including: a packet loss judging module 401 and a retransmission request initiating module 402.
A packet loss determining module 401, configured to determine whether a packet loss exists in an RTP data stream;
a retransmission request initiating module 402, configured to initiate an RTP retransmission request to a source server of an RTP data stream when it is determined that the RTP data stream has packet loss.
Further, the packet loss determining module 401 is further configured to:
judging whether a first sequence number of a currently received RTP message falls in a receiving window or not;
if the first sequence number falls in the receiving window, whether packet loss exists in the RTP data stream is judged according to the first sequence number and a second sequence number, and the second sequence number is the current message sequence number of the receiving window.
Further, the packet loss determining module 401 is further configured to:
calculating the number of lost packets according to the following calculation formula:
dropnum＝NT-(NT-1+1)；
where dropnum is the number of lost packets, NTIs a first sequence number, NT-1Is a second serial number;
and when the number of the packet loss is more than zero, judging that the RTP data stream has the packet loss.
Further, the service processing apparatus further includes a repeat retransmission determining module, where the repeat retransmission determining module is configured to:
judging whether a first sequence number of a currently received RTP message falls in a retransmission window or not;
if the first sequence number falls in the retransmission window, judging whether the RTP message exists in an RTP message receiving record or not;
and if the RTP message exists in the RTP message receiving record, directly discarding the RTP message.
Further, the service processing apparatus further includes an interrupt processing module, where the interrupt processing module is configured to:
judging whether a first sequence number of a currently received RTP message falls outside a receiving window and a retransmission window;
if the first sequence number falls outside the receiving window and the retransmission window, judging whether the receiving time difference is greater than or equal to a preset time threshold value, wherein the receiving time difference is the time difference between the receiving of the RTP message and the receiving of the previous RTP message;
if the receiving time difference is larger than or equal to the preset time threshold, the RTP message received currently is forwarded, and the message serial numbers of the receiving window and the retransmission window are updated.
Further, the interrupt handling module is further configured to:
and if the receiving time difference is smaller than the preset time threshold, discarding the currently received RTP message.
Further, the service processing apparatus further includes a message receiving and recording module, where the message recording module is configured to: and recording the receiving state of the RTP message by using the bit table to form an RTP message receiving record.
It should be understood that this embodiment is an example of the apparatus corresponding to the first embodiment, and may be implemented in cooperation with the first embodiment. The related technical details mentioned in the first embodiment are still valid in this embodiment, and are not described herein again in order to reduce repetition. Accordingly, the related-art details mentioned in the present embodiment can also be applied to the first embodiment.
It should be noted that each module referred to in this embodiment is a logical module, and in practical applications, one logical unit may be one physical unit, may be a part of one physical unit, and may be implemented by a combination of multiple physical units. In addition, in order to highlight the innovative part of the present invention, elements that are not so closely related to solving the technical problems proposed by the present invention are not introduced in the present embodiment, but this does not indicate that other elements are not present in the present embodiment.
A third embodiment of the present invention relates to a network device, as shown in fig. 11, including at least one processor 501; and a memory 502 communicatively coupled to the at least one processor 501; the memory 502 stores instructions executable by the at least one processor 501, and the instructions are executed by the at least one processor 501, so that the at least one processor 501 can execute the service processing method.
The memory 502 and the processor 501 are coupled by a bus, which may include any number of interconnected buses and bridges that couple one or more of the various circuits of the processor 501 and the memory 502 together. The bus may also connect various other circuits such as peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver may be one element or a plurality of elements, such as a plurality of receivers and transmitters, providing a means for communicating with various other apparatus over a transmission medium. The data processed by the processor 501 is transmitted over a wireless medium through an antenna, which further receives the data and transmits the data to the processor 501.
The processor 501 is responsible for managing the bus and general processing and may also provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. And memory 502 may be used to store data used by processor 501 in performing operations.
A fourth embodiment of the present invention relates to a computer-readable storage medium storing a computer program. The computer program realizes the above-described method embodiments when executed by a processor.
That is, those skilled in the art can understand that all or part of the steps in the method of the foregoing embodiments may be implemented by a program to instruct related hardware, where the program is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, etc.) or a processor (processor) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
It will be understood by those of ordinary skill in the art that the foregoing embodiments are specific examples for carrying out the invention, and that various changes in form and details may be made therein without departing from the spirit and scope of the invention in practice.
Claims (8)
1. A service processing method is characterized in that, a network node device applied in the transmission process of RTP data stream includes:
judging whether the RTP data stream has packet loss or not;
if the RTP data stream is judged to have packet loss, an RTP retransmission request is sent to a source server of the RTP data stream;
further comprising:
judging whether a first sequence number of a currently received RTP message falls outside a receiving window and a retransmission window;
if the first sequence number falls outside the receiving window and the retransmission window, judging whether a receiving time difference is larger than or equal to a preset time threshold, wherein the receiving time difference is the time difference between the receiving of the RTP message and the receiving of the previous RTP message;
if the receiving time difference is greater than or equal to the preset time threshold, forwarding the currently received RTP message, and updating the message serial numbers of the receiving window and the retransmission window;
and if the receiving time difference is smaller than the preset time threshold, discarding the currently received RTP message.
2. The service processing method according to claim 1, wherein said determining whether there is packet loss in the RTP data stream includes:
judging whether a first sequence number of a currently received RTP message falls in a receiving window or not;
if the first sequence number falls in the receiving window, judging whether packet loss exists in the RTP data stream according to the first sequence number and a second sequence number, wherein the second sequence number is the current message sequence number of the receiving window.
3. The service processing method according to claim 2, wherein the determining whether the RTP data stream has a packet loss according to the first sequence number and the second sequence number specifically includes:
calculating the number of lost packets according to the following calculation formula:
dropnum＝NT-(NT-1+1)；
drop is the number of lost packets, NTIs the first sequence number, NT-1The second serial number;
and when the packet loss number is larger than zero, judging that the RTP data stream has packet loss.
4. The traffic processing method according to claim 1, further comprising:
judging whether a first sequence number of a currently received RTP message falls in a retransmission window or not;
if the first sequence number falls in the retransmission window, judging whether the RTP message exists in an RTP message receiving record;
and if the RTP message exists in the RTP message receiving record, directly discarding the RTP message.
5. The service processing method according to claim 4, wherein before said determining whether there is packet loss in the RTP data stream, further comprising:
and recording the receiving state of the RTP message by using a bit table to form the RTP message receiving record.
6. A traffic processing apparatus, comprising:
the packet loss judging module is used for judging whether the RTP data stream has packet loss or not;
a retransmission request initiating module, configured to initiate an RTP retransmission request to a source server of the RTP data stream when it is determined that the RTP data stream has packet loss;
the interrupt processing module is used for judging whether a first serial number of the currently received RTP message falls outside a receiving window and a retransmission window; if the first sequence number falls outside the receiving window and the retransmission window, judging whether the receiving time difference is greater than or equal to a preset time threshold value, wherein the receiving time difference is the time difference between the receiving of the RTP message and the receiving of the previous RTP message; if the receiving time difference is larger than or equal to a preset time threshold, forwarding the currently received RTP message, and updating message serial numbers of a receiving window and a retransmission window; and if the receiving time difference is smaller than the preset time threshold, discarding the currently received RTP message.
7. A network device, comprising:
at least one processor; and the number of the first and second groups,
a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a business process method as claimed in any one of claims 1 to 5.
8. A computer-readable storage medium, storing a computer program, wherein the computer program, when executed by a processor, implements a traffic processing method according to any of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911233169.0A CN111131179B (en) | 2019-12-05 | 2019-12-05 | Service processing method, device, network equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911233169.0A CN111131179B (en) | 2019-12-05 | 2019-12-05 | Service processing method, device, network equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111131179A CN111131179A (en) | 2020-05-08 |
| CN111131179B true CN111131179B (en) | 2022-01-25 |
Family
ID=70497564
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911233169.0A Active CN111131179B (en) | 2019-12-05 | 2019-12-05 | Service processing method, device, network equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111131179B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112073206B (en) * | 2020-10-26 | 2022-08-16 | 上交所技术有限责任公司 | Method for realizing reliable multicast oriented data packet filtering based on programmable network hardware equipment |
| CN112333276B (en) * | 2020-11-09 | 2021-09-14 | 珠海格力电器股份有限公司 | Network access method, system, storage medium and electronic device |
| CN113726486B (en) * | 2021-11-03 | 2021-12-28 | 湖南麒麟信安科技股份有限公司 | Message duplication removing method, system and storage medium in parallel redundant network |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101697504A (en) * | 2009-09-08 | 2010-04-21 | 杭州华三通信技术有限公司 | Method and device for improving data transmission quality |
| CN106341368A (en) * | 2015-07-06 | 2017-01-18 | 中兴通讯股份有限公司 | Data processing method and device |
| CN107786506A (en) * | 2016-08-26 | 2018-03-09 | 中兴通讯股份有限公司 | Data processing method, device, Wireless Communication Equipment and Radio Network System |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20120123144A (en) * | 2006-09-26 | 2012-11-07 | 리베우 리미티드 | Remote transmission system |
| US8320252B2 (en) * | 2009-11-03 | 2012-11-27 | Nxp B.V. | System and method for data communications using a sliding window protocol with selective retransmission |
-
2019
- 2019-12-05 CN CN201911233169.0A patent/CN111131179B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101697504A (en) * | 2009-09-08 | 2010-04-21 | 杭州华三通信技术有限公司 | Method and device for improving data transmission quality |
| CN106341368A (en) * | 2015-07-06 | 2017-01-18 | 中兴通讯股份有限公司 | Data processing method and device |
| CN107786506A (en) * | 2016-08-26 | 2018-03-09 | 中兴通讯股份有限公司 | Data processing method, device, Wireless Communication Equipment and Radio Network System |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111131179A (en) | 2020-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220014312A1 (en) | Data transmission method and apparatus | |
| US10972226B2 (en) | Disabling, using an explicit indication, hybrid automatic repeat request (HARQ) acknowledgments for packets for which acknowledgements are supported at a network or higher layer | |
| US10237153B2 (en) | Packet retransmission method and apparatus | |
| US20190268797A1 (en) | Data transmission method and apparatus | |
| CN110086578B (en) | Data transmission method, device and system | |
| KR100785293B1 (en) | System and Method for TCP Congestion Control Using Multiple TCP ACKs | |
| US9059916B2 (en) | Apparatus and method for transmitting packets in a communication system | |
| US7277390B2 (en) | TCP processing apparatus of base transceiver subsystem in wired/wireless integrated network and method thereof | |
| US9325628B2 (en) | Packet handling method, forwarding device and system | |
| CN111131179B (en) | Service processing method, device, network equipment and storage medium | |
| WO2012066824A1 (en) | Communication apparatus and communication system | |
| KR100750170B1 (en) | Method and apparatus for transmitting data frame efficiently in communication network | |
| US20040105463A1 (en) | Method for enhancing transmission quality of streaming media | |
| CN109120540B (en) | Method for transmitting message, proxy server and computer readable storage medium | |
| EP1798913B1 (en) | Transport control method in wireless communication system | |
| EP1873994A1 (en) | Quality of service securing method and apparatus | |
| US8312339B2 (en) | Apparatuses and methods for controlling automatic repeat request (ARQ) reset in broadband wireless communication system | |
| JP5124591B2 (en) | Method for displaying consecutive data units in RAN | |
| US11502986B2 (en) | Reducing transmission delay of transmitting data in Wi-Fi | |
| KR20060090138A (en) | A transmission method and apparatus of peoriodic status report in communication system | |
| Ho et al. | Snug-Vegas and Snug-Reno: efficient mechanisms for performance improvement of TCP over heterogeneous networks | |
| CN114422441A (en) | Method and device for controlling flow | |
| JP2006086604A (en) | Control unit and control method of radio network |
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 |