WO2012083737A1 - 丢包检测方法、系统和媒体客户端 - Google Patents

丢包检测方法、系统和媒体客户端 Download PDF

Info

Publication number
WO2012083737A1
WO2012083737A1 PCT/CN2011/079717 CN2011079717W WO2012083737A1 WO 2012083737 A1 WO2012083737 A1 WO 2012083737A1 CN 2011079717 W CN2011079717 W CN 2011079717W WO 2012083737 A1 WO2012083737 A1 WO 2012083737A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
sequence number
current
packets
sent
Prior art date
Application number
PCT/CN2011/079717
Other languages
English (en)
French (fr)
Inventor
朱晓斌
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2012083737A1 publication Critical patent/WO2012083737A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809—Selective-repeat protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures

Definitions

  • the present invention relates to streaming media technologies, and in particular, to a packet loss detecting method, system, and media client.
  • the packet loss retransmission technology is often used to deal with the network packet loss problem.
  • the existing packet loss retransmission technology can be roughly divided into two types: transport layer implementation and application layer implementation. .
  • the transport layer implements packet loss and retransmission, and uses a connection protocol to transmit media data, such as a transmission control protocol (TCP).
  • TCP transmission control protocol
  • the transport layer protocol itself detects the packet loss, and automatically initiates a retransmission when the packet is lost.
  • This method utilizes the packet loss retransmission function that is provided by the transport layer, and the implementation cost is low.
  • the resource overhead of such a protocol is large, and the packet retransmission function is not controlled, and it is easy to fall into a "congestion" when the network is congested. The vicious circle of losing one packet is more congested.
  • the application layer implements packet loss retransmission, and uses user data such as the UDP protocol to transmit media data.
  • the application layer detects the packet loss and initiates a retransmission request. This method requires application layer participation, and the implementation is more complicated. However, the resource overhead of the transport layer protocol is relatively low, and the transmission and response of the retransmission request are implemented by the application layer.
  • the related policies can be flexibly adjusted according to the network conditions, which is more suitable for streaming media. business.
  • the current trend in the industry is to use UDP protocol to carry media data.
  • the application layer packet loss retransmission technology is becoming more and more mature. These technologies are similar.
  • the basic idea is that the sender adds continuous packets for each media (data) packet.
  • the incremented packet sequence number the receiver detects whether the received media packet sequence number is continuous. If the packet is found to be intermittent, the packet loss is considered to occur, and the sequence number of the lost packet is fed back to the sender through an independent channel, and the sender receives the feedback information. , the corresponding media package is resent to the recipient.
  • the premise that the packet loss is detected is that the packet in front of it is not completely lost, that is, at least one of all media packets smaller than the missing media packet number. The ones have been successfully received by the receiver. This means: If the first media packet originally sent by the streaming server is lost or all consecutive packets starting from the first media packet are lost, the receiver is not detected; that is, the packet loss retransmission cannot be overwritten. The whole process of the conversation.
  • the patent CN101123584 is entitled "A Method and Apparatus for Measuring Packet Loss of an IP Link".
  • a method for measuring packet loss at the IP layer is disclosed.
  • a delimited packet is sent separately, and the delimited packet includes a period of time.
  • the receiving end can correctly calculate the packet loss on the link according to the information and the number of packets received during the period.
  • There is an out-of-order phenomenon in the transmission of IP packets and the delimited packet in the invention only contains the total number of packets sent by the sender, and lacks information associated with a particular packet, so the receiver can know that it has been lost for a period of time. How many packets, but it is impossible to know exactly which two IP packets are actually involved in these packets, and it is impossible to accurately know the total number of packets sent by the sender from the first packet to a specific IP packet. Unable to detect initial packet loss.
  • the application number is CN101616316, and the patent application named "a method for transmitting and receiving video data and transmitting and receiving methods" does not use the conventional method of detecting packet loss by the receiving end, but the information of the packet received by the receiving end.
  • the summary feedback is sent to the sender, and the sender compares the packet with the packet sent by itself to detect the packet loss, and then performs the packet loss retransmission.
  • the sender can detect the initial packet loss in this way, but the packet loss in the IP network is a very small number of events, and the invention needs to continuously feed back information to the sender, which consumes a large amount of network bandwidth;
  • the packet loss detection work originally distributed on each client is concentrated on the transmitting end, and the processing capability of the transmitting end is inevitably consumed.
  • the cost of deploying this approach is relatively high, so it is less used in practice.
  • the server may carry the RTP-Info header field in the response message of the PLAY operation, and the sequence number of the first RTP packet through the seq subfield therein.
  • the notification is sent to the client, and the client compares the received RTP packet sequence number with the value to detect the initial packet loss.
  • two separate underlying channels are used to carry RTSP and RTP data respectively (typically, TCP is used to carry RTSP, and UDP is used to carry RTP). It is not guaranteed that the client can obtain RTP in time. According to the information about the Info header field, it can be seen that the initial packet loss is detected by the RTSP method, and the timeliness is not guaranteed, and the effect is not good.
  • the present invention provides a packet loss detection method, system and media client, which can be detected at low cost.
  • the initial packet loss and the packet loss retransmission are implemented, and the packet loss retransmission can be performed when the streaming server is switched.
  • the present invention provides a method for implementing packet loss detection, the method comprising:
  • the receiving end acquires the packet sequence number of the data packet received by itself;
  • the receiving end acquires the total number of packets sent by the sending end
  • the receiving end detects the lost data packet according to the packet sequence number and the total number of packets sent.
  • the foregoing packet loss detection method has the following features:
  • the receiving end obtains the total number of packets sent by the sending end, including:
  • the receiving end determines that the received current data packet is the first received data packet, the total number of the starting packet information is extracted from the IP packet carrying the current data packet.
  • the foregoing packet loss detection method may further have the following features:
  • the receiving end detects the lost data packet according to the packet sequence number and the total number of packets sent by the receiving end, and the receiving end generates the reference sequence number according to the total number of packets sent by the receiving end;
  • the current serial number of the current data packet is taken as the current serial number
  • the current sequence number is equal to the reference sequence number plus one, it is determined that no packet loss occurs, and the current sequence number is used as a new reference sequence number; if the current sequence number is not equal to the reference sequence number plus one, then all packet loss between the reference sequence number and the current sequence number is determined. , and the current serial number is used as the reference serial number.
  • the foregoing packet loss detection method may further have the following features:
  • the foregoing method further includes:
  • the sender generates the total number of packets sent, and carries the total number of packets sent in the packet containing the packet.
  • the IP packet is sent to the receiving end.
  • the foregoing packet loss detection method may further have the following features: Generating the total number of packets to be sent at the transmitting end, and carrying the total number of packets sent in the IP packet containing the data packet to the receiving end,
  • the sender counts the sent data packet, and carries the above-mentioned count in the above IP packet and sends it to the receiving end;
  • the sender carries the first packet sequence number in the above IP packet and sends it to the receiving end.
  • the foregoing packet loss detection method may further have the following features:
  • the method further includes:
  • the source IP address of the current IP packet is extracted, and a retransmission request is sent to the corresponding sender;
  • the current IP packet and the source IP address of the previous IP packet are extracted; by comparing the current IP packet with the source IP address of the previous IP packet, it is determined whether the two are from The same sender, if yes, sends a retransmission request to the corresponding sender, if not, extracts the first packet sequence number of the current data packet, and sends the weight to the sender of the first two sessions respectively by using the first packet sequence number as the boundary Pass the request.
  • the present invention provides a media client, where the media client includes:
  • the sequence number obtaining module is configured to obtain a packet sequence number of the data packet received by the media client, and the information obtaining module is configured to obtain information about the total number of packets sent by the media server, and the detecting module is configured to set the packet number according to the packet sequence number and the total number of packets to be sent. A missing packet was detected.
  • the media client may have the following characteristics:
  • the information obtaining module is further configured to: when determining, that the received current data packet is the first received data packet, extracting the total number of the starting packet information from the IP packet carrying the current data packet;
  • the detecting module is further configured to: generate a reference sequence number according to the total number of packets sent; use the packet sequence number of the current data packet as the current sequence number; and if the current sequence number is equal to the reference sequence number plus one, determine that no packet loss occurs, and use the current sequence number as Reference sequence number; if the current sequence number is not equal to the reference sequence number plus one, then all packet loss between the reference sequence number and the current sequence number is determined; and the current sequence number is used as a reference Serial number.
  • the above media client may also have the following characteristics:
  • the above media clients also include:
  • the retransmission request module is configured to: when there are multiple media servers transmitting IP packets in turn, if it is determined that the packet loss occurs during the first session, the source IP address of the current IP packet is extracted, and the corresponding media server is sent If it is determined that the packet loss does not occur during the first session, the current IP packet and the source IP address of the previous IP packet are extracted, and the source IP address of the current IP packet and the previous IP packet are compared to determine the second IP address. Whether the source is from the same sender, if yes, a retransmission request is sent to the corresponding media server, and if not, the first packet sequence number of the current data packet is extracted, and the media of the first two sessions are respectively bounded by the first packet sequence number. The server issues a retransmission request.
  • the present invention also provides a packet loss detection system, the system comprising the above media client and media server, wherein:
  • the media server is configured to generate the total number of packets to be sent, and carry the total number of the packets to be sent to the media client in an IP packet containing the data packet.
  • the above packet loss detection method, system and media client can detect the initial packet loss and realize the packet loss retransmission at low cost and in time.
  • FIG. 1 is a flowchart of implementing packet loss retransmission according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a packet loss detection method according to an embodiment of the present invention.
  • FIG. 3 is a schematic structural diagram of a deployment model 1 according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram of a general format of an RTP packet header extension field according to an embodiment of the present invention
  • FIG. 6 is a schematic diagram of a format of an RTP packet header extension field according to Embodiment 1 of the present invention
  • FIG. 7 is a schematic structural diagram of a deployment model 2 according to an embodiment of the present invention.
  • FIG. 9 is a value of a media packet sequence number and a first packet sequence number field according to Embodiment 2 of the present invention
  • 10 is a flowchart of a receiving end determining a transport layer session to which a packet belongs and transmitting a retransmission request according to Embodiment 2 of the present invention
  • FIG. 11 is a schematic diagram of receiving a packet at a receiving end according to Embodiment 2 of the present invention
  • FIG. 12 is a schematic structural diagram of a media server according to an embodiment of the present invention.
  • FIG. 13 is a schematic structural diagram of a packet loss detection system according to an embodiment of the present invention.
  • the media server is the streaming server, which is equivalent to the "Media Server” in RFC 2326.
  • the application layer data is the data transmitted by the application layer through the underlying IP link, and the application layer data is the ultimate purpose of the data communication, and other auxiliary information added for the purpose is not belong to the application layer data; for example, in the streaming media application
  • the media data is application layer data, and the information used for packet loss detection and retransmission does not belong to the application layer data.
  • the sender is an IP communication entity that generates application layer data and sends it to the outside. In most cases, the sender is a streaming server. The sender also cooperates with the packet loss retransmission function.
  • the receiving end is an IP communication entity that receives application layer data, and cooperates with the sending end to implement a packet loss retransmission function.
  • the sender and receiver of this paper are differentiated according to the flow direction of application layer data, rather than the flow direction of a specific IP packet.
  • a transport layer session is a process of continuously transmitting and receiving data packets between a specific transmitting end and a receiving end. A change of the transmitting end or the receiving end generates a new transport layer session, so that a single application layer communication is performed. Multiple transport layer sessions can occur during the process. In the subsequent sections of this paper, the transport layer session is simply referred to as "session" in the case of no confusion.
  • packet loss refers to an event in which the first packet sent by the sender in a session is lost or all consecutive packets from the first packet are lost, which may be referred to as "initial packet loss”.
  • the embodiment provides a packet loss detection method, where the foregoing method includes: Step 1: The receiving end acquires the packet serial number of the data packet received by itself;
  • Step 2 The receiving end obtains the total number of sent packets sent by the sending end;
  • Step 3 The receiving end detects the lost data packet according to the packet sequence number and the total number of packets sent.
  • the method may further include: the receiving end sends a retransmission request to the sending end, so that the receiving end retransmits the lost data packet.
  • FIG. 1 it is a flowchart of implementing packet loss retransmission according to an embodiment of the present invention, where the method includes:
  • Step 101 The sending end generates information about the total number of sent packets.
  • Total Packet Information does not correspond to a specific specific form. Its purpose is to enable the receiving end to accurately know the total number of packets that have been sent by the sender when any packet is sent, including but not limited to the following forms:
  • Packet count The sender counts the sent packets, and initializes the count when the session starts, and then monotonically increments. Depending on the implementation, the packet count may contain the packet that is currently being sent, or it may not contain the packet that is currently being sent. The packet count is used as the total number of packets to be sent, and the receiver can directly obtain the information.
  • First packet serial number Specifically refers to the serial number of the first packet sent by the sender, and the receiving end subtracts the serial number of the first packet from the serial number of any packet, and also obtains the corresponding total number of packets sent;
  • Step 102 The sending end sends the total number of sent packets.
  • the total number of packets sent by the in-band mode is sent, and the sender directly adds the total number of packets to the IP packet carrying the application layer data, and sends the packet to the receiving end.
  • the sender directly adds the total number of packets to the IP packet carrying the application layer data, and sends the packet to the receiving end.
  • Step 103 The receiving end performs packet loss detection according to the received total number of sent packets.
  • the receiving end knows the total number of packets received by itself, and according to the total number of packets sent by the sending end, the total number of lost packets when each IP packet is received can be calculated, and combined with the received packet serial number, each receiver can also obtain each The exact serial number of the lost packet; although the method of generating and transmitting the total number of packets is different, the specific implementation of the above process is different, but the result does not change;
  • the total number of packets received is 1 and the total number of packets sent is greater than 1.
  • the difference between the two is the total number of initial packets.
  • the sequence number of the packet that arrives is decremented, which is the sequence number of each lost packet; thus, it can be seen that the technical solution supports the detection of the initial packet loss;
  • Step 104 The receiving end sends a retransmission request.
  • the receiving end generates a retransmission request packet according to the foregoing packet loss detection result, where the retransmission request packet carries the sequence number information of the lost packet, and is sent by the receiving end to the sending end;
  • Step 105 The sender responds to the retransmission request.
  • the sender After receiving the retransmission request, the sender resends the corresponding lost packet to the receiving end according to the sequence number information.
  • the sending end of the present embodiment provides the total number of packets sent to the receiving end, and the receiving end can accurately know the total number of packets sent by the sending end when any data packet is sent, so that the packet loss in the initial phase can be detected;
  • the internal mode carries the total number of packets sent, and the total number of packets sent to the receiving end together with the application layer data can detect the initial packet loss as long as the packet is received, thereby ensuring timeliness.
  • FIG. 2 it is a flowchart of a packet loss detection method according to an embodiment of the present invention.
  • the embodiment is described from a receiving end side, where each data packet carries a packet sequence number field, which is a prominent point.
  • the embodiment does not consider the processing of the out-of-order packet and the retransmission packet.
  • the packet loss detection process includes: Step 201: Wait until a data packet is received;
  • Step 202 it is determined whether it is the first time to receive the data packet, and if so, step 203 is performed, otherwise, the process proceeds to step 204;
  • Step 203 Extract the total number of packets sent, and generate a reference sequence number according to the method
  • the specific processing of this step is also different: If the packet count is used as the total number of packets to be sent, the sequence number of the current packet (that is, the first packet received) is subtracted from the corresponding packet count. (If the sender does not include the current packet when generating the packet count, it needs to subtract 1 from this basis, which is the reference sequence number; If the first packet sequence number is used as the total number of packets to be sent, the reference packet number is obtained by subtracting 1 from the first packet sequence number; Step 204, extracting the sequence number of the current packet as the current sequence number;
  • Step 205 determining whether the current serial number is equal to the reference serial number +1, and if yes, proceeding to step 207, otherwise, performing step 206;
  • Step 206 The current received packet and the sequence number of the previous received packet are discontinuous, and the packet corresponding to the intermediate vacancy sequence number is regarded as having been lost, and a retransmission request is sent;
  • Step 207 Save the current serial number as a reference serial number
  • Step 208 Determine whether the media session ends. If not, go to step 201, otherwise, end.
  • the receiving end mainly uses the total number of packets to be sent to perform packet loss detection, and the reference sequence number derived from the total number of packets sent in FIG. 2 is used for packet loss detection, which should be regarded as a technical solution of the present embodiment. Equivalent form.
  • the embodiment can determine the reference sequence number by using the total number of packets to be sent and use the packet loss detection for the packet itself, that is, the detection of the packet loss in the initial phase is realized.
  • FIG. 3 it is a schematic structural diagram of a deployment model 1 according to an embodiment of the present invention.
  • the media server 31 provides a unicast streaming service for the media client 32, and a letter is established between the two.
  • the channel 33 the media server 31 sends the media packet to the media client 32 through the RTP media channel 34.
  • the media client 32 After detecting the packet loss, the media client 32 sends a retransmission request through the retransmission request channel 35.
  • the signaling channel 33 and the retransmission request channel 35 may use RTSP or Real Time Transport Control Protocol (RTCP), or any similar protocol based on TCP or UDP, and the signaling channel 33 may also serve as a retransmission.
  • Channel 35 is requested, at which point the two channels are physically combined into one channel.
  • the RTP protocol is used to carry the application layer data, and the RTP packet format on the RTP tunnel 34 needs to be extended.
  • FIG. 4 it is an RTP packet header format according to Embodiment 1 of the present invention.
  • the value of the X field is 1; the meaning of the remaining fields in the RTP header can be referred to RFC 3550.
  • RFC 3550 is a generic format given for the RTP header extension field, when RTP When the extended field flag in the header is 1, the extension field is followed by the end of the standard RTP header.
  • the meanings of the fields are as follows:
  • the length of the extension field (length) is in units of 32 bits, excluding the 32 bits of the length field itself;
  • the length of the header extension must be an integer multiple of 32 bits.
  • the RTP header extension field format for transmitting the total number of packets sent is determined.
  • the format of the RTP header extension field can be seen in FIG. 6, where:
  • the magic number is the extended field format as specified in Figure 5.
  • the value is hexadecimal 0x12345678;
  • the length value is 1 , indicating that there are 32-bit extensions after the field;
  • the packet number indicates the total number of packets sent by the sender including the RTP packet since the session started.
  • the streaming media server 31 serves as a transmitting end, and outputs an RTP packet carrying the packet sending count according to the format of FIG. 4 to FIG. 6.
  • the streaming media client 32 functions as a receiving end to perform the process shown in FIG. 2: After receiving the first RTP packet, The initial value is added to the reference sequence number by subtracting the sequence number from the sequence number, thereby detecting all packet loss events including the initial packet loss, and initiating a retransmission request when the packet loss is detected.
  • the streaming media server 31 cooperates with the streaming client 32 to implement packet loss retransmission in response to the retransmission request.
  • FIG. 7 it is a schematic structural diagram of a deployment model 2 provided by an embodiment of the present invention, where the control module 71 controls a plurality of streaming media servers 72, and the control module 71 and each streaming media server 72 establish a control channel 73. For communication of control information.
  • Control module 71 is logically independent but can be deployed in conjunction with a streaming server 72.
  • Control module 71, streaming server 72 and control channel 73 together form a virtual media server 74.
  • the media client 75 establishes a signaling channel 76 with the control module 71.
  • the control module 71 controls each of the streaming servers 72 via the control channel 73, and transmits the RTP format media stream to the media client 75 in turn through the media channel 77. Only one streaming server 72 is sending at the same time The code stream, the code stream RTP packet sequence number sent by the two adjacent streaming media servers 72 in the transmission time remains continuous. After detecting the packet loss, the media client 75 issues a retransmission request to the media server 72 through the retransmission request channel 78.
  • the RTP protocol is used to carry the application layer data, and the RTP packet on the media channel 77 needs to be extended, and the RTP packet is still extended in accordance with the provisions of RFC 3550.
  • the RTP header extension field format of the second embodiment of the present invention is:
  • the first sequence number indicates the sequence number of the first media packet
  • the length indicates the length
  • the length of the first packet sequence number is zero.
  • the media packet sequence number and the first packet sequence number field of the second embodiment of the present invention are values, where:
  • 91, 92, 93, and 94 represent a series of media servers participating in the streaming media server-A, streaming media server-B, streaming media server-C, and streaming media server-X, corresponding to the streaming media server in FIG. 72.
  • the following series of small squares 95 represent RTP packets sent by each streaming server.
  • Each RTP packet has two numbers. The above number is the RTP serial number, and the lower digit is the first packet serial number. Taking the packet 96 as an example, the packet number is 152, and the first packet number is 151. According to the analysis of each RTP packet number given in Figure 9, the order of each RTP packet in time is from top to bottom and then from left to right.
  • the primary media service in the second embodiment will be composed of multiple transport layer sessions.
  • the RTP sequence numbers are distinguished, and the serial numbers belong to [1, 100], [101, 150] respectively.
  • the [151, 280], [501, 650], [651, 701], [702, 800] packets in the closed range each constitute a session.
  • This embodiment can not only detect the initial packet loss, but also accurately determine the transport layer session to which the packet belongs, so that a retransmission request can be sent to the corresponding media server. As shown in FIG.
  • the receiving end determines a flow chart of a transport layer session to which a packet belongs and sends a retransmission request, and the processing mechanism after the receiving end finds that the packet is lost is highlighted.
  • the processing of out-of-order packets and retransmission packets is not considered in the figure.
  • the process includes:
  • Step 1001 Determine whether the current packet loss is in the first session in the entire media service process, and if yes, perform step 1002; otherwise, go to step 1003;
  • Step 1002 The packet loss occurs during the first session, and the source IP address of the current packet is taken out, and a retransmission request is sent to the corresponding sender, and the process ends;
  • Step 1003 The source IP address is removed from the two packets before and after, so as to identify the corresponding sender; the "previous packet” refers to the packet received by the receiver at the previous time, and the “last packet” is the current packet. Packets received, when the packet loss occurs, the RTP numbers of the two packets are not consecutive;
  • Step 1004 Determine whether they are from the same sender by comparing the source IP addresses of the two packets before and after, and if yes, go to step 1005, otherwise go to step 1006;
  • Step 1005 Send a retransmission request to the sending end; end;
  • Step 1006 Take out the first packet sequence number field of the current packet, and send a retransmission request to the sending end of the two previous sessions respectively;
  • the last two packets come from different senders, they belong to two different sessions. Then, the first packet sequence number field of the current packet needs to be taken out, so that the retransmission request is sent to the senders of the two previous sessions.
  • FIG. 11 it is a schematic diagram of the receiving end receiving situation in the second embodiment of the present invention.
  • the step 1006 in FIG. 10 is further illustrated:
  • the previous media server in and the current media server 1 12 respectively represent two transmitting ends, and two transport layer sessions are generated.
  • the corresponding RTP packet sets are 1 13 and 1 14 respectively, and the serial numbers of the RTP packets are respectively SN.
  • P A SNPB SNPC the first packet sequence number is FSN P
  • the serial number of each RTP packet is SN C A SNcB SNcC
  • the first packet sequence number is FSN C A
  • the RTP packet sets 113 and 114 sent by the transmitting ends 111 and 112 are transmitted through the network, and three different packet loss phenomena may occur when the transmitting end receives, corresponding to 115, 116 and 117 in FIG. 11 (the solid border indicates the packet is Successfully received, the dotted border indicates that the packet was lost during transmission).
  • the receiver receives the serial number 115 of all packets after sequence number (inclusive) and SN C B (inclusive) including SN C A package including all lost between SN P C and SN C B before SN P C ;
  • 116 is a sequence number of all packets received by the receiver, after the sequence number (inclusive) and SN C A (inclusive) including SN P C including all lost packets between SN P B before and SN C A SN P B;
  • Table 1 shows the key variables of the three types of packet loss conditions corresponding to 115, 116, and 117 in step 1006 in Figure 10:
  • the packet loss detection method provided by the embodiment of the present invention can detect the initial packet loss and realize the packet loss retransmission at low cost and in time, and can perform packet loss retransmission when switching the streaming media server.
  • the media client includes a sequence number obtaining module 121, an information acquiring module 122, and a detecting module 123.
  • the sequence number obtaining module is configured to acquire itself.
  • the information acquisition module is configured to obtain the total number of packets sent by the sender;
  • the detection module is configured to detect the lost packet according to the packet sequence number and the total number of packets sent.
  • the information acquiring module may be configured to: when the current data packet is received as the first received data packet, the total number of the starting packets is extracted from the IP packet carrying the current data packet.
  • the detection module may be further configured to generate a reference sequence number according to the total number of packets sent; the current sequence number of the current data packet is used as the current serial number; and if the current serial number is equal to the reference sequence number plus one, the current serial number is used as the reference serial number; If the reference sequence number is not equal to one, all packet loss between the reference sequence number and the current sequence number is detected.
  • the process of detecting the lost data packet by the media client can be seen in Figure 2.
  • the process of retransmitting the lost data can be seen in Figure 1, and will not be described here.
  • reference number and the current serial number are the left closed right open interval, that is, the reference serial number is included, but the data packet represented by the current serial number is not included.
  • the media client may further include a retransmission request module 124, and the retransmission request module may be configured to: if it is determined that the data packet loss occurs during the first session, extract the source IP address of the current IP packet, and correspondingly The sender sends a retransmission request; if it is determined that the packet loss does not occur during the first session, the current IP packet and the source IP address of the previous IP packet are extracted, by comparing the current IP packet with the source of the previous IP packet. The IP address is used to determine whether the two are from the same sender. If yes, the retransmission request is sent to the corresponding sender. If not, the first packet sequence number of the current data packet is extracted, and the first packet sequence number is used as the boundary.
  • the sender of both sessions issues a retransmission request. For details, refer to Figure 10, and details are not described here. Pass, and can retransmit the packet when changing the media client. ' ⁇
  • FIG. 13 is a schematic structural diagram of a packet loss detection system according to an embodiment of the present invention.
  • the system includes a media server 131 and a media client 132.
  • the structure of the media client is the same as that of the media client shown in FIG.
  • the structure is the same and has the same function, and will not be described here.
  • the media server is configured to generate the total number of packets to be sent, and the total number of the packets to be sent is carried in the IP packet including the data packet, and sent to the media server.
  • the media server may be configured to count the sent data packet, and carry the foregoing packet in the IP packet to send to the receiving end; or carry the first packet serial number in the IP packet and send the packet to the receiving end.
  • the packet loss detection system can detect the initial packet loss and realize the packet loss retransmission at a low cost and in time through the interaction between the media server and the media client, and can perform packet loss retransmission when switching the streaming media server. .
  • the foregoing technical solution provides a packet loss detection method, system, and media client, so that the initial packet loss can be detected at a low cost and packet loss retransmission is implemented, and packet loss retransmission can be performed when the streaming media server is switched. It overcomes the shortcomings of the prior art that it is impossible to detect the initial packet loss or can detect it but the effect is not good or the cost is high and it is not easy to promote.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

本发明提供了一种丢包检测方法、系统和媒体客户端，其中，该丢包检测方法包括：接收端获取自身收到的数据包的包序号；接收端获取发送端发送的发包总数信息；以及接收端根据上述包序号和发包总数信息检测出丢失的数据包。本发明提供的丢包检测方法、系统和媒体客户端，能够以低成本且及时地检测出初始丢包并进而实现丢包重传，并可在切换流媒体服务器时进行丢包重传。

Description

丢包检测方法、 系统和媒体客户端
技术领域
本发明涉及流媒体技术， 尤其涉及一种丟包检测方法、 系统和媒体客户 端。
背景技术
随着宽带接入的普及， 流媒体技术的应用越来越广泛,而媒体码流在 IP 网络上传输， 不可避免地会遭遇到丟包， 从而导致画面花屏停顿和声音断续 变调， 严重影响媒体播放质量。 在工程实践中， 经常釆用丟包重传技术来应 对网络丟包问题， 按具体实现的层次划分， 现有的丟包重传技术可大致划分 为两种类型： 传输层实现和应用层实现。
其中， 传输层实现丟包重传釆用传输控制协议（TCP )等有连接协议传 输媒体数据， 由传输层协议本身对丟包进行检测， 在丟包时自动发起重传。 这种方式利用的是传输层自带的丟包重传功能， 实现成本较低， 但此类协议 资源开销较大，而且丟包重传功能不受控制，在网络拥塞时容易陷入"拥塞一 丟包一重传一更拥塞" 的恶性循环。 应用层实现丟包重传釆用用户数据 4艮协 议（UDP )等无连接协议传输媒体数据， 由应用层对丟包进行检测并发起重 传请求。 这种方式需要应用层序参与， 实现比较复杂， 但传输层协议的资源 开销比较低， 而且重传请求的发送和响应都由应用层实现， 可以根据网络情 况灵活调整相关策略， 比较适合流媒体业务。
目前业界的趋势是釆用 UDP协议承载媒体数据，与此对应的则是应用层 丟包重传技术日趋成熟， 这些技术大同小异， 基本思想都是发送方为每个媒 体（数据） 包加上连续递增的包序号， 接收方检测收到的媒体包序号是否连 续， 如果发现断续就认为发生了丟包， 并将丟失包的序号通过独立的通道反 馈给发送方， 发送方收到反馈信息后， 就将相应的媒体包重新发送给接收方。
对上述方案稍加分析就可以发现： 丟包被检测到的前提条件是其前面的 包没有完全丟失， 也就是说比丟失媒体包序号小的所有媒体包中至少要有一 个已经被接收方成功接收。 这就意味着： 如果流媒体服务器最初发送的第一 个媒体包丟失或从第一个媒体包开始的连续若干个包全部丟失的话， 接收方 是检测不到的； 即丟包重传无法覆盖会话的全过程。
申请号 CN101123584名为 《一种测量 IP链路丟包情况的方法及设备》 的专利公开了一种测量 IP层丟包的方法： 单独发送定界包， 定界包中包含一 段时间内发送的 IP包的数量信息， 接收端根据这个信息， 再结合期间接收到 的包数量， 即可正确计算出链路上的丟包情况。 IP包的传输存在乱序现象， 而该发明中的定界包仅包含发送端发送的包总数信息， 缺乏与特定的某个包 进行关联的信息， 所以接收端虽然能够知道一段时间内丟失了多少包， 但无 法精确获知这些丟包具体发生在哪两个 IP包之间， 也无法精确获知从第一个 包到某个特定 IP包为止发送端发送的包总数一一这意味着其无法检测初始丟 包。
申请号为 CN101616316, 名为《一种视频数据的发送、接收装置及发送、 接收方法》 的专利申请没有釆用接收端进行丟包检测的常规方法， 而是由接 收端接收到的包的信息汇总反馈给发送端， 发送端将其与自身发送的包的情 况进行对比就能检测丟包， 并进而执行丟包重传。 理论上， 发送端能够通过 这种方式对初始丟包进行检测， 但在 IP网络中丟包毕竟是极少数事件， 而该 发明需要持续向发送端反馈信息， 对网络带宽消耗较大； 另外， 将原本分布 在各客户端的丟包检测工作集中在发送端，也必然会消耗发送端的处理能力。 总之， 这种做法的部署成本相对较高， 所以在实践中应用较少。
另外， 在请求评议（RFC ) 2326定义的实时流传输协议（RTSP ) 中， 服 务器可以在 PLAY操作的响应消息中携带 RTP-Info头域， 通过其中的 seq子 域将第一个 RTP包的序号通知给客户端，客户端将收到的 RTP包序号与该值 比较， 即可检测初始丟包。 在工程实践中， 大部分时候都是釆用两个单独的 底层通道分别承载 RTSP和 RTP数据 (典型配置是釆用 TCP承载 RTSP, 釆 用 UDP承载 RTP ) , 不能保证客户端及时获取到 RTP-Info头域的相关信息， 可见， 釆用 RTSP给出的这种方式检测初始丟包， 无法保证及时性， 效果欠 佳。 发明内容
为了克服现有技术无法检测初始丟包或虽能检测但效果不好或成本较高 不易推广的缺点， 本发明提出一种丟包检测方法、 系统和媒体客户端， 以能 够以低成本检测出初始丟包并进而实现丟包重传， 并可在切换流媒体服务器 时进行丟包重传。
本发明提供了一种实现丟包检测方法， 该方法包括：
接收端获取自身收到的数据包的包序号；
接收端获取发送端发送的发包总数信息； 以及
接收端根据上述包序号和发包总数信息检测出丟失的数据包。
优选地， 上述丟包检测方法可具有如下特点：
上述接收端获取发送端发送的发包总数信息包括：
在会话过程中， 当接收端判断出接收到的当前数据包为第一次收到的数 据包时， 从携带上述当前数据包的 IP包中提取出发包总数信息。
优选地， 上述丟包检测方法还可具有如下特点：
上述接收端根据上述包序号和发包总数信息检测出丟失的数据包包括： 上述接收端根据上述发包总数信息生成参考序号；
将当前数据包的包序号作为当前序号； 以及
若当前序号等于参考序号加一， 则确定未发生丟包， 并将当前序号作为 新的参考序号； 若当前序号不等于参考序号加一， 则确定参考序号和当前序 号之间的所有数据包丟失， 并将当前序号作为参考序号。
优选地， 上述丟包检测方法还可具有如下特点：
在从携带上述当前数据包的 IP包中提取出发包总数信息之前， 上述方法 还包括：
发送端生成发包总数信息， 并将上述发包总数信息携带在包含数据包的
IP包中发送给接收端。
优选地， 上述丟包检测方法还可具有如下特点： 在上述发送端生成发包总数信息， 并将上述发包总数信息携带在包含数 据包的 IP包中发送给接收端的处理中，
发送端对发出的数据包进行计数， 并将上述计数携带在上述 IP包中发送 给接收端； 或
发送端将首包序号携带在上述 IP包中发送给接收端。
优选地， 上述丟包检测方法还可具有如下特点：
在上述检测出参考序号和当前序号之间的所有数据包丟失之后， 当存在 多个发送端轮流发送 IP包时， 上述方法还包括：
若判断出数据包丟失发生在首次会话期间， 则提取出当前 IP 包的源 IP 地址， 并向对应的发送端发出重传请求；
若判断出数据包丟失不是发生在首次会话期间， 则提取当前 IP包和前一 IP包的源 IP地址；通过比较上述当前 IP包和上述前一 IP包的源 IP地址来判 断二者是否来自同一发送端， 若是， 则向对应的发送端发出重传请求， 若不 是， 则提取出当前数据包的首包序号， 并以上述首包序号为界分别向前后两 个会话的发送端发出重传请求。
本发明提供了一种媒体客户端， 上述媒体客户端包括：
序号获取模块， 设置为获取所述媒体客户端收到的数据包的包序号； 信息获取模块， 设置为获取媒体服务器发送的发包总数信息； 以及 检测模块，设置为根据上述包序号和发包总数信息检测出丟失的数据包。 优选地， 上述媒体客户端可具有如下特点：
上述信息获取模块， 还设置为在会话过程中， 当判断出接收到的当前数 据包为第一次收到的数据包时，从携带上述当前数据包的 IP包中提取出发包 总数信息；
上述检测模块， 还设置为根据所述发包总数信息生成参考序号； 将当前 数据包的包序号作为当前序号； 以及若当前序号等于参考序号加一， 则确定 未发生丟包， 并将当前序号作为参考序号； 若当前序号不等于参考序号加一， 则确定参考序号和当前序号之间的所有数据包丟失； 并将当前序号作为参考 序号。
优选地， 上述媒体客户端还可具有如下特点：
上述媒体客户端还包括：
重传请求模块， 设置为当存在多个媒体服务器轮流发送 IP包时， 若判断 出数据包丟失发生在首次会话期间， 则提取出当前 IP包的源 IP地址， 并向 对应的媒体服务器发出重传请求； 若判断出数据包丟失不是发生在首次会话 期间 , 则提取当前 IP包和前一 IP包的源 IP地址 , 通过比较上述当前 IP包和 上述前一 IP包的源 IP地址来判断二者是否来自同一发送端， 若是， 则向对 应的媒体服务器发出重传请求， 若不是， 则提取出当前数据包的首包序号， 并以上述首包序号为界分别向前后两个会话的媒体服务器发出重传请求。
本发明还提供了一种丟包检测系统， 上述系统包括上述媒体客户端和媒 体服务器， 其中：
上述媒体服务器， 设置为生成发包总数信息， 并将上述发包总数信息携 带在包含数据包的 IP包中发送给上述媒体客户端。
上述的丟包检测方法、 系统和媒体客户端， 能够以低成本且及时地检测 出初始丟包并进而实现丟包重传。 附图概述
图 1为本发明实施方式所提供的实现丟包重传的流程图；
图 2为本发明实施方式所提供的丟包检测方法的流程图；
图 3为本发明实施方式所提供的的部署模型一的结构示意图；
图 4为本发明实施例一的 RTP包头格式；
图 5为本发明实施方式所提供的 RTP包头扩展字段通用格式示意图； 图 6为本发明实施例一的 RTP包头扩展字段格式示意图；
图 7为本发明实施方式所提供的的部署模型二的结构示意图；
图 8为本发明实施例二的 RTP包头扩展字段格式；
图 9为本发明实施例二的媒体包序号和首包序号字段取值； 图 10 为本发明实施例二中接收端确定丟包所属传输层会话并发送重传 请求的流程图； 图 11为本发明实施例二中接收端收包情况示意图；
图 12为本发明实施方式所提供的媒体服务器的结构示意图；
图 13为本发明实施方式所提供的丟包检测系统的结构示意图。
本发明的较佳实施方式
下面结合附图对技术方案的实施作进一步地详细描述：
为便于后文表述， 在此定义如下术语：
媒体服务器即流媒体服务器，相当于 RFC 2326中的 "媒体服务器 ( Media Server )，， 。
应用层数据为应用层通过底层 IP链路传送的数据，应用层数据是该次数 据通讯的最终目的，为实现该目的而增加的其它辅助信息不属于应用层数据； 例如， 在流媒体应用中， 媒体数据是应用层数据， 而用于丟包检测和重传的 信息则不属于应用层数据。
发送端为生成应用层数据并对外发送的 IP通信实体，在本文中大多数情 况下， 发送端都是一个流媒体服务器。 发送端还要配合实现丟包重传功能。
接收端为接收应用层数据的 IP通讯实体， 与发送端配合实现丟包重传功 能。 本文的发送端和接收端是根据应用层数据的流向来区分的， 而不是某个 具体 IP包的流向。
传输层会话为发生在特定发送端和接收端之间的一次在时间上连续发送 和接收数据包的过程 ,发送端或接收端的变更都会产生一个新的传输层会话 , 故在单次应用层通讯过程中可能发生多次传输层会话。 本文随后部分在不致 引起混淆的场合， 均将传输层会话简称为 "会话" 。
初始阶段丟包指的是发送端在某次会话中发送的第一个包丟失或从第一 个包开始的连续若干个包全部丟失的事件， 可简称为 "初始丟包" 。
本实施方式提供了一种丟包检测方法， 上述方法包括： 步骤一、 接收端获取自身收到的数据包的包序号；
步骤二、 接收端获取发送端发送的发包总数信息； 以及
步骤三、 接收端根据上述包序号和发包总数信息检测出丟失的数据包。 在步骤三之后， 该方法还可以包括： 接收端向发送端发送重传请求， 以 便接收端重传丟失的数据包。
如图 1所示， 为本发明实施方式所提供的实现丟包重传的流程图， 该方 法包括：
步骤 101、 发送端生成发包总数信息；
"发包总数信息" 并不对应特定的具体形式， 其宗旨是能让接收端精确 获知任何一个数据包被发送时发送端已经发送的包总数， 包括但不限于如下 形式：
1 )发包计数： 发送端对发出的包进行计数， 会话启动时对该计数进行初 始化， 此后单调递增。 根据具体实现的不同， 发包计数可以包含当前将要发 送的数据包， 也可以不包含当前将要发送的数据包。 将发包计数作为发包总 数信息， 接收端可直接获得该信息。
2 )首包序号： 特指发送端发送的第一个包的序号， 接收端将任一包的序 号减去首包序号， 也可获得对应的发包总数信息；
步骤 102、 发送端发送发包总数信息；
本实施例中釆用带内方式发送发包总数信息， 发送端直接将发包总数信 息添加到携带有应用层数据的 IP包中， 一并发送给接收端， 对此， 也有很多 种不同的方式， 例如：
1 )以发出的包计数作为包序号，那么接收端收到的包序号就是发包总数；
2 )在应用层数据包中增加一个专门的字段用来传输发包总数信息， 此时 要求应用层数据包另外设置序号字段；
步骤 103、 接收端根据接收的发包总数信息进行丟包检测；
接收端知晓自身收到的包总数， 根据发送端提供的发包总数信息， 就可 计算出每个 IP包被接收时的丟包总数， 再结合收到的包序号， 还能得到每个 丟失包的准确序号； 尽管发包总数信息的生成和发送方式不同， 上述过程的 具体实现方式也不同， 但结果不会变化；
如果发生初始阶段丟包， 当接收端成功接收第一个 IP包时， 收包总数为 1 , 而对应的发包总数则大于 1 , 两者的差值即为初始丟包的总数量， 将收到 的这个包的序号递减即为各个丟失包的序号； 由此可见， 本技术方案支持对 初始丟包的检测；
步骤 104、 接收端发出重传请求；
接收端根据上述丟包检测结果生成重传请求包， 该重传请求包中携带有 丟失包的序号信息， 被接收端发送到发送端；
步骤 105、 发送端响应该重传请求。
发送端接收到重传请求后， 根据序号信息将对应的丟失包重新发送给接 收端。
本实施方式的发送端将发包总数信息提供给接收端， 接收端据此可精确 获知任何一个数据包被发送时发送端发送的包总数， 从而可对初始阶段丟包 进行检测； 由于釆用带内方式携带发包总数信息， 发包总数信息与应用层数 据一同到达接收端， 只要收到了包就能检测初始丟包， 因而保证了及时性。
如图 2所示， 为本发明实施方式所提供的丟包检测方法的流程图， 该实 施例是从接收端侧进行描述， 其中每个数据包都携带有包序号字段， 为突出 重点， 该实施例没有考虑乱序包和重传包的处理， 该丟包检测过程包括： 步骤 201、 等待直到接收到一个数据包；
步骤 202、 判断是否是第一次收到数据包， 如果是， 则执行步骤 203 , 否 则， 转向步骤 204;
步骤 203、 提取发包总数信息， 并据此生成参考序号；
根据发包总数信息的具体形式不同， 这一步骤的具体处理也有所不同： 若以发包计数作为发包总数信息， 则将当前包（即接收到的第一个包） 的序号减去对应的发包计数（如果发送端生成发包计数时未包含当前包， 则 需要在此基础上再减去 1 ) , 即为参考序号； 若以首包序号作为发包总数信息，将首包序号减去 1即可获得参考序号； 步骤 204、 提取当前包的序号作为当前序号；
步骤 205、 判断当前序号是否等于参考序号 +1 , 若是， 则转向步骤 207 , 否则， 执行步骤 206;
步骤 206、 当前收到的包和前一个收到包的序号不连续， 将中间空缺序 号对应的包视为已经丟失， 发出重传请求；
步骤 207、 将当前序号作为参考序号加以保存；
步骤 208、 判断媒体会话是否结束， 若未结束， 则转向步骤 201 , 否则， 结束。
在上述步骤 101 中， 接收端主要使用发包总数信息来进行丟包检测， 而 图 2中使用由发包总数信息导出的参考序号来进行丟包检测， 应视为本实施 方式的技术方案的一种等价形式。
可见， 该实施例可通过发包总数信息来确定参考序号并用于对该包本身 的丟包检测， 即实现了对初始阶段丟包的检测。
如图 3所示， 为本发明实施方式所提供的的部署模型一的结构示意图， 在该实施例中， 媒体服务器 31为媒体客户端 32提供单播流媒体服务， 两者 之间建立一个信令通道 33 ,媒体服务器 31通过 RTP媒体通道 34向媒体客户 端 32发送媒体包， 媒体客户端 32检测到丟包后， 通过重传请求通道 35发送 重传请求。
在实践中， 信令通道 33和重传请求通道 35可釆用 RTSP或实时传输控 制协议（RTCP ) , 也可以釆用任何基于 TCP或 UDP的类似协议， 信令通道 33也可同时充当重传请求通道 35 , 此时两个信道在物理上合并为一个信道。
该实施例釆用 RTP协议承载应用层数据， 需要对 RTP通道 34上的 RTP 包格式进行扩展。 如图 4所示， 为本发明实施例一的 RTP包头格式， 该 RTP 包头格式由 RFC 3550规定， 字段 X为扩展字段标志， X=0表示该 RTP包头 没有扩展字段， X=l表示该 RTP包头存在扩展字段， 在本实施例中， X字段 取值为 1 ; RTP包头其余字段的含义可参考 RFC 3550。
如图 5所示，是 RFC 3550为 RTP包头扩展字段给出的通用格式，当 RTP 包头中的扩展字段标志为 1时， 在标准 RTP包头的尾部紧跟的是扩展字段， 各字段含义如下：
由应用决定（ defined by profile )的取值由具体的应用决定， RFC 3550不 做规定；
扩展字段的长度（length ) 以 32比特为单位， 不包括 length字段本身所 在的 32比特；
由于 length字段以 32比特为单位， 具体的扩展头部 （ header extension ) 长度必须为 32比特的整数倍。
根据图 4和图 5的定义确定了用于传输发包总数信息的 RTP包头扩展字 段格式， 该 RTP包头扩展字段格式可参见图 6, 其中：
幻数（ magic number )是符合图 5规定的扩展字段格式， 取值为 16进制 数 0x12345678;
length取值为 1 , 表示该字段后有 32比特的扩展内容；
发包计数（packet number ) , 表示发送端从会话开始以来包括该 RTP包 在内发送的数据包总数。
流媒体服务器 31作为发送端，按照图 4至图 6的格式输出携带发包计数 的 RTP包， 流媒体客户端 32作为接收端执行图 2所示的流程： 当收到第一 个 RTP包后， 将序号减去发包计数即可对参考序号赋初值， 从而实现对包括 初始丟包在内的全部丟包事件的检测， 并在检测到丟包时发起重传请求。 流 媒体服务器 31则响应重传请求， 与流媒体客户端 32配合实现丟包重传。
如图 7所示， 为本发明实施方式所提供的部署模型二的结构示意图， 其 中， 控制模块 71控制多个流媒体服务器 72, 控制模块 71和各流媒体服务器 72之间建立控制信道 73用于控制信息的通讯。 控制模块 71在逻辑上独立， 但可与某个流媒体服务器 72合并部署。 控制模块 71、 流媒体服务器 72和控 制信道 73—起构成了一个虚拟的媒体服务器 74。
媒体客户端 75与控制模块 71之间建立信令通道 76, 控制模块 71则通 过控制信道 73控制各个流媒体服务器 72, 轮流通过媒体通道 77向媒体客户 端 75发送 RTP格式的媒体码流。 同一时间仅有一个流媒体服务器 72在发送 码流， 在发送时间上相邻的两个流媒体服务器 72发出的码流 RTP包序号保 持连续。 媒体客户端 75检测到丟包后， 通过重传请求通道 78向媒体服务器 72发出重传请求。
该实施例釆用 RTP协议承载应用层数据， 需要对媒体通道 77上的 RTP 包进行扩展， 在此依然遵循 RFC 3550的规定来扩展 RTP包。 如图 8所示， 为本发明实施例二的 RTP包头扩展字段格式， 其中：
首包序号 ( first sequence number )表示第一个媒体包的序号, Length表 示长度， 首包序号的长度为零； 具体地， 每切换一次， 负责发送码流的媒体 服务器 72和新开始发包的媒体服务器都要将本次发送的所有 RTP包中的该 字段设置为本次发送的第一个媒体包的序号。
如图 9所示， 为本发明实施例二的媒体包序号和首包序号字段取值， 其 中：
91、 92、 93和 94代表流媒体服务器 -A、 流媒体服务器 -B、 流媒体服务 器 -C直到流媒体服务器 -X的一系列参与轮流发包的媒体服务器， 对应于图 7 中的流媒体服务器 72。下方一系列小方块 95代表各流媒体服务器发出的 RTP 包， 每个 RTP包内有两个数字， 上面的数字为 RTP序号， 而下面的数字则为 首包序号。 以包 96为例， 其包序号为 152, 而首包序号为 151。 才艮据图 9中 给出的各 RTP包序号分析可知：各 RTP包在时间上的先后顺序是先从上到下 再从左到右。
在图 9中， 同一个流媒体服务器发出的媒体包在垂直方向是对齐的 （为 便于观察， 图中用了双点划线区分） 。 可见， 每次当用于发包的媒体服务器 即发送端发生切换， RTP包的首包序号字段取值也随之发生变化——被设置 为该媒体服务器此次发送的第一个 RTP包的序号。
由于釆用多个媒体服务器轮流发包， 故实施例二中的一次媒体服务将由 多个传输层会话组成， 对于图 9来说， 以 RTP序号范围来区分， 序号分别属 于 [1,100]、 [101,150]、 [151,280]、 [501,650]、 [651,701]、 [702,800]这些闭区间 范围内的包各自构成一次会话。 该实施例不但可检测初始丟包， 还能准确确 定丟包所属的传输层会话， 从而可向相应的媒体服务器发出重传请求。 如图 10所示，为本发明实施例二中接收端确定丟包所属传输层会话并发 送重传请求的流程图， 这里给出的是接收端发现丟包之后的处理机制， 为突 出重点， 图中没有考虑乱序包和重传包的处理， 该过程包括：
步骤 1001、 判断当前丟包是否处于整个媒体服务过程中的第一次会话， 若是， 则执行步骤 1002 , 否则， 转向步骤 1003 ;
由于第一次会话期间的丟包不会牵涉到多个发送端， 故增加这个判断步 骤；
步骤 1002、丟包发生在第一次会话期间， 取出当前包的源 IP地址， 向对 应的发送端发出重传请求， 结束；
步骤 1003、从前后两个包之间取出源 IP地址，从而识别出对应的发送端； 这里的 "前一个包" 指的是接收端上一次收到的包， "后一个包" 则为 当前收到的包， 当丟包发生时， 这两个包的 RTP序号不连续；
步骤 1004、 通过比较前后两个包的源 IP地址来判断它们是否来自同一 个发送端， 若是， 则执行步骤 1005 , 否则转向步骤 1006 ;
步骤 1005、 向发送端发出重传请求； 结束；
当前后两个包属于同一个会话， 且都来自当前的发送端时， 则向该发送 端发出重传请求；
步骤 1006、 取出当前包的首包序号字段， 以此为界分别向前后两个会话 的发送端发出重传请求； 结束。
当前后两个包来自不同的发送端时， 则属于两个不同会话， 则需取出当 前包的首包序号字段，以此为界分别向前后两个会话的发送端发出重传请求。
如图 1 1所示， 为本发明实施例二中接收端收包情况示意图， 在描述接收 端收包过程中对图 10中的步骤 1006给出了进一步说明：
前一媒体服务器 i n和当前媒体服务器 1 12分别表示前后两个发送端， 产生了两个传输层会话， 对应的 RTP包集合分别为 1 13和 1 14 , 1 13各 RTP 包的序号分别为 SNPA SNPB SNPC, 首包序号均为 FSNP , 1 14各 RTP 包的序号分别为 SNCA SNcB SNcC , 首包序号均为 FSNCA , 显然， FSNC = SNCA = SNPC + 1。
发送端 111和 112发送的 RTP包集合 113和 114经过网络传输， 发送端 接收时可能会发生三种不同的丟包现象，对应图 11中的 115、 116和 117 (实 线边框表示该包被成功接收， 虚线边框表示该包在传输过程中丟失） 。
其中， 115为接收端收到序号在 SNPC之前（含）和 SNCB (含）之后的所 有包， 序号在 SNPC和 SNCB之间包括 SNCA在内的包全部丟失；
116为接收端收到序号在 SNPB之前（含）和 SNCA (含）之后的所有包， 序号在 SNPB和 SNCA之间包括 SNPC在内的包全部丟失；
117为接收端收到序号在 SNPB之前（含）和 SNCB (含）之后的所有包， 序号在 SNPB和 SNCB之间包括 SNPC和 SNCA在内的包全部丟失。
表 1给出了图 10中步骤 1006对应 115、 116和 117三种丟包情况的关键 变量取值：
不同丟包情况下的关键变量取值表
Figure imgf000015_0001
相应的处理方式如表 2所示 （序号范围均为闭区间） ：
不同丟包情况下的处理方式
Figure imgf000015_0002
本发明实施方式提供的丟包检测方法， 能够以低成本且及时地检测出初 始丟包并进而实现丟包重传， 并可在切换流媒体服务器时进行丟包重传。
如图 12所示， 为本发明实施方式所提供的媒体客户端的结构示意图， 上 述媒体客户端包括序号获取模块 121、信息获取模块 122和检测模块 123; 其 中， 序号获取模块设置为获取自身收到的数据包的包序号； 信息获取模块设 置为获取发送端发送的发包总数信息； 检测模块设置为根据上述包序号和发 包总数信息检测出丟失的数据包。
优选地， 上述信息获取模块还可以设置为在会话过程中， 当判断出接收 到的当前数据包为第一次收到的数据包时，从携带上述当前数据包的 IP包中 提取出发包总数信息； 上述检测模块还可以设置为根据上述发包总数信息生 成参考序号； 将当前数据包的包序号作为当前序号； 以及若当前序号等于参 考序号加一， 则将当前序号作为参考序号； 若当前序号不等于参考序号加一， 则检测出参考序号和当前序号之间的所有数据包丟失。 该媒体客户端检测丟 失的数据包的过程可参见图 2, 实现重传丟失的数据的过程可参见图 1 , 此处 不再赘述。
需要说明的是， 参考序号和当前序号之间为左闭右开区间， 即包括参考 序号， 但不包括当前序号表示的数据包。
优选地， 上述媒体客户端还可以包括重传请求模块 124, 该重传请求模 块可以设置为若判断出数据包丟失发生在首次会话期间， 则提取出当前 IP包 的源 IP地址， 并向对应的发送端发出重传请求； 若判断出数据包丟失不是发 生在首次会话期间 , 则提取当前 IP包和前一 IP包的源 IP地址 , 通过比较上 述当前 IP包和上述前一 IP包的源 IP地址来判断二者是否来自同一发送端， 若是， 则向对应的发送端发出重传请求， 若不是， 则提取出当前数据包的首 包序号，并以上述首包序号为界分别向前后两个会话的发送端发出重传请求。 具体实现过程可参见图 10, 此处不再赘述。 传， 并可在 换流媒 客户端时进行丟包重传。 ' ^
如图 13所示， 为本发明实施方式所提供的丟包检测系统的结构示意图， 上述系统包括媒体服务器 131和媒体客户端 132, 其中， 媒体客户端的结构 与图 12中所示的媒体客户端的结构相同且具有相同的功能， 此处不再赘述。 其中， 上述媒体服务器设置为生成发包总数信息， 并将上述发包总数信 息携带在包含数据包的 IP包中发送给上述媒体服务器。 具体地， 上述媒体服 务器还可以设置为对发出的数据包进行计数， 并将上述计数携带在上述 IP包 中发送给接收端； 或将首包序号携带在上述 IP包中发送给接收端。
该丟包检测系统通过媒体服务器和媒体客户端之间的交互， 能够以低成 本且及时地检测出初始丟包并进而实现丟包重传， 并可在切换流媒体服务器 时进行丟包重传。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成， 上述程序可以存储于计算机可读存储介质中， 如只读 存储器、 随机访问存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部 分步骤也可以使用一个或多个集成电路来实现。 相应地， 上述实施例中的各 模块 /单元可以釆用硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本发明的技术方案不限制于任何特定形式的硬件和软件的结合。
以上实施例仅用以说明本发明的技术方案而非限制， 仅仅参照较佳实施 例对实施方式进行了详细说明。 本领域的普通技术人员应当理解， 可以对上 述实施方式的技术方案进行修改或者等同替换， 而不脱离本发明技术方案的 精神和范围， 均应涵盖在本发明的权利要求范围当中。 工业实用性
上述技术方案提供一种丟包检测方法、 系统和媒体客户端， 以能够以低 成本检测出初始丟包并进而实现丟包重传， 并可在切换流媒体服务器时进行 丟包重传。 其克服了现有技术无法检测初始丟包或虽能检测但效果不好或成 本较高不易推广的缺点。

Claims

权 利 要 求 书
1、 一种丟包检测方法， 其中包括：
接收端获取自身收到的数据包的包序号；
所述接收端获取发送端发送的发包总数信息； 以及
所述接收端根据所述包序号和所述发包总数信息检测出丟失的数据包。
2、 根据权利要求 1所述的丟包检测方法， 其中， 所述接收端获取发送端 发送的发包总数信息的步骤包括：
在会话过程中， 当所述接收端判断出接收到的当前数据包为第一次收到 的数据包时， 从携带所述当前数据包的网络协议（IP ) 包中提取出所述发包 总数信息。
3、 根据权利要求 1所述的丟包检测方法， 其中， 所述接收端根据所述包 序号和所述发包总数信息检测出丟失的数据包的步骤包括：
所述接收端根据所述发包总数信息生成参考序号；
将当前数据包的包序号作为当前序号； 以及
若所述当前序号等于所述参考序号加 1 , 则确定未发生丟包， 并将当前 序号作为新的参考序号； 若当前序号不等于参考序号加 1 , 则确定所述参考 序号和所述当前序号之间的所有数据包丟失， 并将所述当前序号作为新的参 考序号。
4、 根据权利要求 2所述的丟包检测方法， 其中， 在所述接收端从携带所 述当前数据包的 IP包中提取出所述发包总数信息的步骤之前， 所述方法还包 括：
所述发送端生成所述发包总数信息， 并将所述发包总数信息携带在包含 数据包的 IP包中发送给所述接收端。
5、 根据权利要求 4所述的丟包检测方法， 其中， 在所述发送端生成所述 发包总数信息， 并将所述发包总数信息携带在包含数据包的 IP包中发送给接 收端的处理中，
所述发送端对发出的数据包进行计数， 并将所述计数携带在所述 IP包中 发送给所述接收端； 或
所述发送端将首包序号携带在所述 IP包中发送给所述接收端。
6、 根据权利要求 3-5任一权利要求所述的丟包检测方法， 其中， 在所述 检测出所述参考序号和所述当前序号之间的所有数据包丟失之后， 如果存在 多个发送端发送 IP包， 则所述方法还包括：
若判断出数据包丟失发生在首次会话期间， 则提取出当前 IP 包的源 IP 地址， 并向对应的发送端发出重传请求；
若判断出数据包丟失不是发生在首次会话期间， 则提取当前 IP包和前一 IP包的源 IP地址；通过比较所述当前 IP包和所述前一 IP包的源 IP地址来判 断二者是否来自同一发送端， 若是， 则向对应的发送端发出重传请求， 若不 是， 则提取出当前数据包的首包序号， 并以所述首包序号为界分别向前后两 个会话的发送端发出重传请求。
7、 一种媒体客户端， 其包括：
序号获取模块， 其设置为： 获取所述媒体客户端收到的数据包的包序号； 信息获取模块， 其设置为： 获取媒体服务器发送的发包总数信息； 以及 检测模块， 其设置为： 根据所述包序号和所述发包总数信息检测出丟失 的数据包。
8、 根据权利要求 7所述的媒体客户端， 其中：
所述信息获取模块是设置为： 在会话过程中， 当判断出接收到的当前数 据包为第一次收到的数据包时， 从携带所述当前数据包的网络协议（IP ) 包 中提取出所述发包总数信息；
所述检测模块是设置为： 根据所述发包总数信息生成参考序号； 将当前 数据包的包序号作为当前序号； 以及若所述当前序号等于所述参考序号加 1 , 则确定未发生丟包， 并将所述当前序号作为新的参考序号； 若所述当前序号 不等于所述参考序号加 1 , 则确定所述参考序号和所述当前序号之间的所有 数据包丟失， 并将所述当前序号作为新的参考序号。
9、 根据权利要求 8所述的媒体客户端， 其中， 所述媒体客户端还包括： 重传请求模块， 其设置为： 当存在多个媒体服务器轮流发送 IP包时， 若 判断出数据包丟失发生在首次会话期间， 则提取出当前 IP包的源 IP地址， 并向对应的媒体服务器发出重传请求； 若判断出数据包丟失不是发生在首次 会话期间 , 则提取当前 IP包和前一 IP包的源 IP地址 , 通过比较所述当前 IP 包和所述前一 IP包的源 IP地址来判断二者是否来自同一发送端， 若是， 则 向对应的媒体服务器发出重传请求， 若不是， 则提取出当前数据包的首包序 号，并以所述首包序号为界分别向前后两个会话的媒体服务器发出重传请求。
10、 一种包括权利要求 7-9任一权利要求所述的媒体客户端的丟包检测 系统， 所述系统还包括媒体服务器， 其中：
所述媒体服务器设置为： 生成发包总数信息， 并将所述发包总数信息携 带在包含数据包的 IP包中发送给所述媒体客户端。
PCT/CN2011/079717 2010-12-21 2011-09-16 丢包检测方法、系统和媒体客户端 WO2012083737A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010599130.3A CN102546081B (zh) 2010-12-21 2010-12-21 丢包检测方法、系统和媒体客户端
CN201010599130.3 2010-12-21

Publications (1)

Publication Number Publication Date
WO2012083737A1 true WO2012083737A1 (zh) 2012-06-28

Family

ID=46313116

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/079717 WO2012083737A1 (zh) 2010-12-21 2011-09-16 丢包检测方法、系统和媒体客户端

Country Status (2)

Country Link
CN (1) CN102546081B (zh)
WO (1) WO2012083737A1 (zh)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103684923B (zh) * 2013-12-24 2017-10-17 华为技术有限公司 一种丢包测量的方法及网络设备
CN105791154B (zh) * 2014-12-26 2019-05-24 浙江大华技术股份有限公司 一种基于udp的数据传输方法及装置
WO2017133014A1 (zh) * 2016-02-06 2017-08-10 中国科学院计算技术研究所 Tcp传输流中基于接收端的网络性能检测方法及系统
CN106209915A (zh) * 2016-08-31 2016-12-07 深圳聚点互动科技有限公司 一种实时流媒体无线传输方法及其系统
CN109391605B (zh) * 2017-08-14 2021-01-26 杭州海康威视数字技术股份有限公司 数据传输方法、装置及系统
CN109587096B (zh) * 2017-09-28 2021-09-14 中国移动通信集团浙江有限公司 一种识别rtp尾部丢包的方法及装置
CN109842465A (zh) * 2017-11-24 2019-06-04 阿里巴巴集团控股有限公司 数据传输方法、数据端设备
CN108173807B (zh) * 2017-11-28 2021-12-03 贵阳语玩科技有限公司 统一消息发送、处理方法及装置
CN108377427B (zh) * 2018-01-29 2021-11-26 明博教育科技股份有限公司 一种实时视频传输方法和系统
CN109586931B (zh) * 2018-10-18 2021-01-15 招商证券股份有限公司 组播方法及终端设备
CN109889314A (zh) * 2018-12-29 2019-06-14 视联动力信息技术股份有限公司 信息处理方法和装置
CN109889913B (zh) * 2019-03-21 2021-07-20 南京威翔科技有限公司 一种网络环境中的数据丢包的分析方法
CN110677314B (zh) * 2019-08-29 2021-09-21 视联动力信息技术股份有限公司 网络接口测试方法、系统、电子设备及存储介质
CN110855626B (zh) * 2019-10-18 2022-03-11 北京字节跳动网络技术有限公司 电子白板丢包处理方法、系统、介质和电子设备
CN111277576A (zh) * 2020-01-14 2020-06-12 广州华多网络科技有限公司 绘制数据展示方法、装置、计算机设备和存储介质
CN111953454A (zh) * 2020-07-16 2020-11-17 西安万像电子科技有限公司 丢包重传方法、设备及存储介质
CN112637162A (zh) * 2020-12-14 2021-04-09 上海金仕达软件科技有限公司 一种udp数据包处理方法及装置
CN113473111A (zh) * 2021-05-29 2021-10-01 江苏网进科技股份有限公司 一种基于rtsp协议检测视频卡顿现象的方法
CN113259062B (zh) * 2021-05-31 2021-10-29 恒生电子股份有限公司 丢包重传的方法、装置、可读介质以及设备
CN113542061B (zh) * 2021-07-08 2023-03-31 阳光电源股份有限公司 一种数据传输控制方法及相关装置
CN113364814B (zh) * 2021-08-10 2021-11-30 北京翔东智能科技有限公司 基于rtp的抗弱网传输方法
CN114422397A (zh) * 2021-12-27 2022-04-29 中国电信股份有限公司 流媒体通道监测方法、装置、电子设备和可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1503535A (zh) * 2002-11-20 2004-06-09 华为技术有限公司 简单网络管理协议中数据包传送的可靠性保证方法
CN101123584A (zh) * 2007-05-21 2008-02-13 华为技术有限公司 一种测量ip链路丢包情况的方法及设备
CN101159520A (zh) * 2007-10-29 2008-04-09 中兴通讯股份有限公司 数据传输方法
CN101296166A (zh) * 2007-04-29 2008-10-29 中兴通讯股份有限公司 基于索引的多媒体数据的测量方法
CN101662418A (zh) * 2008-08-26 2010-03-03 华为技术有限公司 一种传输文件的检测方法及终端

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100373870C (zh) * 2003-02-26 2008-03-05 华为技术有限公司 通讯设备丢包数量的统计方法
CN101686184A (zh) * 2008-09-23 2010-03-31 中兴通讯股份有限公司 多媒体广播组播业务同步组网的业务数据丢包的处理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1503535A (zh) * 2002-11-20 2004-06-09 华为技术有限公司 简单网络管理协议中数据包传送的可靠性保证方法
CN101296166A (zh) * 2007-04-29 2008-10-29 中兴通讯股份有限公司 基于索引的多媒体数据的测量方法
CN101123584A (zh) * 2007-05-21 2008-02-13 华为技术有限公司 一种测量ip链路丢包情况的方法及设备
CN101159520A (zh) * 2007-10-29 2008-04-09 中兴通讯股份有限公司 数据传输方法
CN101662418A (zh) * 2008-08-26 2010-03-03 华为技术有限公司 一种传输文件的检测方法及终端

Also Published As

Publication number Publication date
CN102546081A (zh) 2012-07-04
CN102546081B (zh) 2015-09-16

Similar Documents

Publication Publication Date Title
WO2012083737A1 (zh) 丢包检测方法、系统和媒体客户端
US8171123B2 (en) Network bandwidth detection and distribution
US8484331B2 (en) Real time protocol packet tunneling
WO2022247550A1 (zh) 数据重传处理方法、装置、计算机设备和存储介质
WO2010031337A1 (zh) 一种基于流的服务质量处理的方法、设备及系统
US20140297805A1 (en) Method and apparatus for assigning priority levels to streams by a network element in a communications network
US10027496B2 (en) Method for distributing identifiers of multicast sources
JPWO2005099188A1 (ja) 通信品質管理方法および装置
EP1820318B1 (en) A method for identifying real-time traffic hop by hop in an internet network
US9838209B2 (en) Method for subscribing to streams from multicast clients
CN101656747A (zh) 流媒体数据的传输方法及系统
JP2002281078A (ja) 通信品質制御方法、通信品質制御システム、パケット解析装置及びデータ送信端末装置
US8788682B2 (en) Communication device, and method, in an internet protocol network, of controlling a communication device
JP2007049382A (ja) 無線中継装置、無線中継方法およびそのコンピュータ・プログラム
WO2016034029A1 (zh) 业务流量的处理方法和装置
US8363573B2 (en) Method for ringcasting with improved reliability
JP4798495B2 (ja) 映像配信品質測定システム、装置および方法
TWI298590B (en) A method for transporting real-time audio and video data
CN103220585B (zh) 一种支持QoS的网络视频传输方法
US9276975B2 (en) Method and apparatus for monitoring quality of service of network
CN101222454B (zh) 一种拒绝非法业务流的方法
Haefeli et al. TPF-TOOLS-A MULTI-INSTANCE JACKTRIP CLONE
CN111385241B (zh) 多媒体数据的丢包修复方法、装置、系统和可读存储介质
US20070086352A1 (en) Method of monitoring multimedia stream exchange session initialization messages and a server and an installation for carrying out said method
JP5659802B2 (ja) 通信端末およびその送受信方法ならびにその端末を含む通信システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11850320

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11850320

Country of ref document: EP

Kind code of ref document: A1