EP3672189B1

EP3672189B1 - Data transmission method, device and system

Info

Publication number: EP3672189B1
Application number: EP18846893.8A
Authority: EP
Inventors: Anmin XIN
Original assignee: Hangzhou Hikvision Digital Technology Co Ltd
Current assignee: Hangzhou Hikvision Digital Technology Co Ltd
Priority date: 2017-08-14
Filing date: 2018-08-14
Publication date: 2022-07-06
Anticipated expiration: 2038-08-14
Also published as: EP3672189A4; CN109391605A; CN109391605B; US11196792B2; EP3672189A1; WO2019034061A1; US20210176293A1

Description

TECHNICAL FIELD

Embodiments of the present invention relate to a method, device and system of transmitting data.

BACKGROUND

In the technical field of communications, data can be transmitted between a transmitting end and a receiving end under the Real-time Transport Protocol (RTP). Exemplarily, the transmitting end can establish an RTP data link with the receiving end, and transmits RTP data packets to the receiving end over the RTP data link. It should be noted that each RTP data link only allows transmission of one type of RTP data packets. An effective payload type (PT) flag in this type of RTP data packets corresponds to the RTP data link.
RFC4588 (RTP RETRANSMISSION PAYLOAD FORMAT) discloses an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available.
CN102595251A discloses a method and a system for realizing streaming media packet loss retransmission. The method comprises the following steps that: a transmitting end transmits retransmission configuration information through a transmission mode as same as that of a media code stream, and the retransmission configuration information comprises a feedback standard identification and a retransmission standard identification; a receiving end receives and configures the retransmission configuration information; the receiving end configures and transmits a packet loss feedback message according to a cached retransmission configuration information when detecting packet loss; the transmitting end configures and transmits a retransmission packet according to the retransmission configuration information after receiving the packet loss feedback message; and the receiving end receives the retransmission packet according to the cached retransmission configuration information.
WO 0215434A1 discloses an apparatus and a method for retransmitting a failing RLP frame assigned with a new unique identifier agreed to between the transmitting and receiving RLP processors instead of the original sequence number. The receiving RLP processor requests the transmitting RLP processor to retransmit a failing RLP frame assigned with a new identifier determined by the receiving RLP processor. Responding to the request, the transmitting RLP processor retransmits the failing RLP frame assigned with the requested new identifier instead of the original sequence number.
RFC3550 (RTP: A Transport Protocol for Real-Time Application) discloses a RTP, the real-time transport protocol.

SUMMARY

The present invention is defined by the subject-matter of the independent claims, with further details defined in the dependent claims; the invention provides a method and computer device for transmitting data, which may solve the problems that the steps of data packet retransmission are complex, and the efficiency of data transmission is low. The technical solutions are as follows:
In the first aspect, a method of transmitting data, applicable to a transmitting end, is provided. The method comprises:

transmitting a plurality of first Real-time Transport Protocol (RTP) data packets to a receiving end over an RTP data link established with a receiving end;
receiving a retransmission indication message sent by the receiving end, the retransmission indication message being intended to indicate an RTP data packet to be retransmitted among the plurality of first RTP data packets;
suffixing a adding unit to the RTP data packet to be retransmitted according to the retransmission indication message to obtain a second RTP data packet, wherein the second RTP data packet comprises an RTP padding field intended to indicate that the second RTP data packet is a retransmitted RTP data packet, a type flag of the second RTP data packet is same as a type flag of the first RTP data packet, and an RTP padding field in the second RTP data packet comprises the padding unit, characterized in that, the padding unit comprises a retransmission indication byte and a length indication byte, and the retransmission indication byte at least comprises a retransmission flag, a count flag and a data flag, wherein the retransmission flag being intended to indicate that the second RTP data packet is the retransmitted RTP data packet, the count flag being intended to indicate the number of times that the transmitting end transmits the second RTP data packet, the data flag being intended to indicate whether an RTP data field in the second RTP data packet is an RTP data field in the RTP data packet to be retransmitted, and the length indication byte being intended to indicate a length of the RTP padding field in the second RTP data packet; and
Optionally, the retransmission indication byte is a penultimate byte in the padding unit, and the length indication byte is a last byte in the padding unit;
the retransmission flag comprises two bits, the count flag comprises three bits, and the data flag comprises one bit; and
the retransmission flag, the data flag and the count flag are arranged in sequence in the retransmission indication byte, and the two bits in the retransmission flag are first two bits in the retransmission indication byte.
Optionally, suffixing a padding unit to the RTP data packet to be retransmitted according to the retransmission indication message comprises:
- judging whether the RTP data packet to be retransmitted comprises the RTP padding field;
- when the RTP data packet to be retransmitted comprises the RTP padding field, suffixing a padding unit to the RTP data packet to be retransmitted to obtain the second RTP data packet, the padding unit comprising a retransmission indication byte, the retransmission indication byte being intended to indicate that the second RTP data packet is a retransmitted RTP data packet; or
- when the RTP data packet to be retransmitted does not comprise the RTP padding field, suffixing a padding unit to the RTP data packet to be retransmitted, and updating a padding flag in an RTP header field in the RTP data packet to be retransmitted to obtain the second RTP data packet, wherein the updated padding flag is intended to indicate that the second RTP data packet comprises the RTP padding field.

Optionally, suffixing a padding unit to the RTP data packet to be retransmitted according to the retransmission indication message further comprises:

acquiring a predetermined bytes per unit, a total bytes of the RTP data packet to be retransmitted being an integer multiple of the bytes per unit, and the bytes per unit being an n^th power of 2, n being an integer greater than or equal to 1; and
determining, according to the bytes per unit, the padding unit constituted by m bytes, m being an integer multiple of the bytes per unit.

In the second aspect, a method of transmitting data, applicable to a receiving end, is provided. The method comprises:

receiving an Real-time Transport Protocol (RTP)data packet sent by a transmitting end over an RTP data link established with a transmitting end; and
acquiring a retransmission indication byte in the RTP padding field, when the RTP data packet comprises the RTP padding field, characterized in that, the retransmission indication byte at least comprises a retransmission flag, a count flag and a data flag, the count flag being intended to indicate the number of times that the transmitting end transmits the RTP data packet;
determining (305), according to the retransmission flag in the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet;
when the retransmission flag is intended to indicate that the RTP data packet is the retransmitted RTP data packet, acquiring the data flag in the retransmission indication byte;
when the data flag is intended to indicate that an RTP data field in the RTP data packet is an RTP data field in the RTP data packet to be retransmitted, acquiring and storing the RTP data field in the RTP data packet; and
when the data flag is intended to indicate that an RTP data field in the RTP data packet is not an RTP data field in the RTP data packet to be retransmitted, deleting the RTP data packet,
wherein, the retransmitted RTP data packet is the corresponding retransmitted RTP data packet of a first RTP data packet, and the retransmitted RTP data and the first RTP data packet are transmitted over the same RTP data link.

Optionally, after receiving the RTP data packet from the receiving end over the RTP data link established with the transmitting end, the method further comprises:

acquiring a length indication byte in the RTP padding field;
determining a length of the RTP padding field according to the length indication byte;
acquiring a predetermined length of an RTP header field in the RTP data packet; and
determining the RTP data field in the RTP data packet according to the length of the RTP padding field and the predetermined length of the RTP header field in the RTP data packet,
wherein the retransmitted RTP data packet is the corresponding retransmitted RTP data packet of a first RTP data packet, and the retransmitted RTP data and the first RTP data packet are transmitted over the same RTP data link.

Optionally, the retransmission indication byte is a penultimate byte in an padding unit, and the length indication byte is a last byte in the padding unit;

the retransmission flag comprises two bits, and the count flag comprises three bits, and the data flag comprises one bit; and
the retransmission flag, the data flag and the count flag are arranged in sequence in the retransmission indication field, and the two bits in the retransmission flag are first two bits in the retransmission indication byte.

Optionally, prior to determining, according to the retransmission flag in the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet, the method further comprises:

acquiring a padding flag in an RTP header field in the RTP data packet; and
determining, according to the padding flag, whether the RTP data packet comprises the RTP padding field.

acquiring a predetermined bytes per unit;
partitioning the RTP data packet into a plurality of data segments according to the bytes per unit, a total bytes of each of the data segments being equal to the bytes per unit; and
parsing the plurality of data segments respectively.

In the third comparative example, a data transmitting device, applicable to a transmitting end, is provided. The data transmitting device comprises: a first transmitting module, configured to transmit, over a Real-time Transport Protocol (RTP) data link established with a receiving end, a plurality of first RTP data packets to the receiving end;

a receiving module, configured to receive a retransmission indication message sent by the receiving end, the retransmission indication message being intended to indicate an RTP data packet to be retransmitted among the plurality of first RTP data packets;
an encapsulating module, configured to encapsulate the RTP data packet to be retransmitted according to the retransmission indication message to obtain a second RTP data packet, wherein the second RTP data packet comprises an RTP padding field intended to indicate that the second RTP data packet is a retransmitted RTP data packet, and a type flag of the second RTP data packet is same as a type flag of the first RTP data packet; and
a second transmitting module, configured to transmit the second RTP data packet to the receiving end over the RTP data link.

Optionally, the encapsulating module is further configured to:
suffix a padding unit to the RTP data packet to be retransmitted, the RTP padding field in the second RTP data packet comprising the padding unit, the padding unit comprising a retransmission indication byte, the retransmission indication byte being intended to indicate that the second RTP data packet is a retransmitted RTP data packet.
Optionally, the retransmission indication byte at least comprises a retransmission flag and a count flag; wherein

the retransmission flag is intended to indicate that the second RTP data packet is the retransmitted RTP data packet; and
the count flag is intended to indicate the number of times that the transmitting end transmits the second RTP data packet.

Optionally, the retransmission indication byte further comprises: a data flag;
the data flag is intended to indicate whether an RTP data field of the second RTP data packet is an RTP data field of the RTP data packet to be retransmitted.
Optionally, the padding unit further comprises a length indication byte, the length indication byte being intended to indicate a length of the RTP padding field of the second RTP data packet.
Optionally, the retransmission indication byte is a penultimate byte in the padding unit, and the length indication byte is a last byte in the padding unit;

Optionally, the encapsulating module is further configured to:

judge whether the RTP data packet to be retransmitted comprises the RTP padding field;
when the RTP data packet to be retransmitted comprises the RTP padding field, suffix a padding unit to the RTP data packet to be retransmitted to obtain the second RTP data packet, the padding unit comprising a retransmission indication byte, the retransmission indication byte being intended to indicate that the second RTP data packet is the retransmitted RTP data packet; or
when the RTP data packet to be retransmitted does not comprise the RTP padding field, after suffix a padding unit to the RTP data packet to be retransmitted, and update a padding flag in an RTP header field in the RTP data packet to be retransmitted to obtain the second RTP data packet, wherein the updated padding flag is intended to indicate that the second RTP data packet comprises the RTP padding field.

Optionally, the encapsulating module is further configured to:

acquire a predetermined bytes per unit, a total bytes of the RTP data packet to be retransmitted being an integer multiple of the bytes per unit, and the bytes per unit being an n^th power of 2, n being an integer greater than or equal to 1; and
determine, according to the bytes per unit, the padding unit constituted by m bytes, m being an integer multiple of the bytes per unit.

In the fourth comparative example, a data transmitting device, applied to a receiving end, is provided. The data transmitting device comprises:

a receiving module, configured to receive an RTP data packet from a receiving end over a Real-time Transport Protocol (RTP) data link established with the transmitting end; and
a first determining module, configured to, determine, according to the RTP padding field in the RTP data packet, whether the RTP data packet is a retransmitted RTP data packet when the RTP data packet comprises an RTP padding field.

Optionally, the first determining module is further configured to:

acquire a retransmission indication byte in the RTP padding field; and
determine, according to the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet.

Optionally, the retransmission indication byte at least comprises a retransmission flag and a count flag, the count flag being intended to indicate the number of times that the transmitting end sends the RTP data packet; and the first determining module is further configured to:
determine, according to the retransmission flag in the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet.
Optionally, the retransmission indication byte further comprises: a data flag; and the data transmitting device further comprises:

a first acquiring module, configured to acquire the data flag in the retransmission indication byte, when the retransmission flag is intended to indicate that the RTP data packet is the retransmitted RTP data packet;
a second acquiring module, configured to acquire and store the RTP data field in the RTP data packet when the data flag is intended to indicate that the RTP data field in the RTP data packet is an RTP data field in the RTP data packet to be retransmitted; or
a deleting module, configured to delete the RTP data packet when the data flag is intended to indicate that the RTP data field in the RTP data packet is not an RTP data field in the RTP data packet to be retransmitted.

Optionally, the data transmitting device further comprises:

a fifth acquiring module, configured to acquire a length indication byte in the RTP padding field;
a third determining module, configured to determine a length of the RTP padding field according to the length indication byte;
a sixth acquiring module, configured to acquire a predetermined length of an RTP header field of the RTP data packet; and
a fourth determining module, configured to determine the RTP data field in the RTP data packet according to the length of the RTP padding field and the predetermined length of the RTP header field in the RTP data packet.

Optionally, the retransmission indication byte is a penultimate byte in the padding unit, and the length indication byte is a last byte in the padding unit;

Optionally, the data transmitting device further comprises:

a third acquiring module, configured to acquire a padding flag in an RTP header field in the RTP data packet; and
a second determining module, configured to determine, according to the padding flag, whether the RTP data packet comprises the RTP padding field.

Optionally, the data transmitting device further comprises:

a fourth acquiring module, configured to acquire a predetermined bytes per unit;
a partitioning module, configured to partition the RTP data packet into a plurality of data segments according to the bytes per unit, a total bytes of each of the data segments being equal to the bytes per unit; and
a parsing module, configured to parse the plurality of data segments respectively.

In the fifth comparative example, a system for transmitting data is provided. The system comprises: a transmitting end and a receiving end; wherein the transmitting end comprises the data transmitting device as provided by the third aspect, and the receiving end comprises the data transmitting device as provided by the fourth aspect.
In the sixth aspect, a computer device is provided. The device comprises a processor and a memory;
Wherein the memory is configured to store a computer program; and the processor is configured to execute the program stored on the memory to perform the method as defined in any one of claims 1 to 4 or perform the method as defined in any one of claims 5 to 9.
In the seventh comparative example, a computer-readable storage medium is provided, storing at least one code instruction; wherein the at least one code instruction is executed by a processor to perform the method as provided by the first aspect or perform the method as provided by the second aspect.
The technical solutions provided by the present invention may comprise the following benefits.
The present invention provides a method, data transmitting device and system of transmitting data. In the method of transmitting data, in a second RTP data packet obtained after the transmitting end encapsulates an RTP data packet to be retransmitted, an RTP padding field may indicate that the second RTP data packet is a retransmitted RTP data packet, and a type flag in a first RTP data packet is the same as a type flag in the second RTP data packet. Therefore, the second RTP data packet and the first RTP data packet may be transmitted over the same RTP data link, and prior to retransmission of the RTP data packet to be retransmitted, the transmitting end does not need to establish the RTP data link with the receiving end. In this way, the steps of data packet retransmission are simplified, and the efficiency of data transmission is improved.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the technical solutions in the embodiments of the present invention more clearly, the following briefly introduces the accompanying drawings required for describing the embodiments. Apparently, the accompanying drawings in the following description show merely some embodiments of the present invention, and a person of ordinary skill in the art may also derive other drawings from these accompanying drawings without creative efforts.

FIG. 1 is a schematic structural diagram of an RTP frame according to an embodiment of the present invention;
FIG. 2 is a flowchart of a method of transmitting data according to an embodiment of the present invention;
FIG. 3 is a flowchart of a method of obtaining a second RTP data packet by a transmitting end according to an embodiment of the present invention;
FIG. 4 is a schematic structural diagram of a padding unit according to an embodiment of the present invention;
FIG. 5 is a schematic structural diagram of an RTP data packet to be retransmitted and a second RTP data packet according to an embodiment of the present invention;
FIG. 6 is a flowchart of a method of parsing a received RTP data packet by a receiving end according to an embodiment of the present invention;
FIG. 7 is a schematic structural diagram of a data transmitting device according to an embodiment of the present invention;
FIG. 8 is a schematic structural diagram of a data transmitting device according to another embodiment of the present invention;
FIG. 9 is a schematic structural diagram of a transmitting data device according to still another embodiment of the present invention;
FIG. 10 is a schematic structural diagram of a data transmitting device according to still yet another embodiment of the present invention;
FIG. 11 is a schematic structural diagram of a data transmitting device according to another embodiment of the present invention;
FIG. 12 is a schematic structural diagram of a data transmitting device according to another embodiment of the present invention;
FIG. 13 is a schematic structural diagram of a light strip according to an embodiment of the present invention; and
FIG. 14 is a schematic structural diagram of a computer device according to an embodiment of the present invention.

DETAILED DESCRIPTION

The present invention will be described in further detail with reference to the accompanying drawings, to present the objects, technical solutions, and advantages of the present invention more clearly.
In the technical field of communications, a transmitting end and a receiving end can transmit data under a RTP (for example, the RTP with version number RFC3550). Optionally, the transmitting end can establish an RTP data link with the receiving end, and transmit an RTP frame constituted by at least one RTP data packet to the receiving end over the RTP data link. Optionally, both the transmitting end and the receiving end can be a device having a data transmission function, for example, a terminal, a server, or a server cluster constituted by a plurality of servers, which is not limited in the embodiments of the present invention.
In the related art, upon receiving the RTP data packets transmitted by the transmitting end over the RTP data link, the receiving end can determine an RTP data packet to be retransmitted among a plurality of RTP data packets (that is, lost RTP data packets among the plurality of RTP data packets), and transmit a retransmission indication message to the receiving end, wherein the retransmission indication message is intended to indicate the RTP data packet to be retransmitted. Upon receiving the retransmission indication message, the transmitting end can modify the PT flag in the RTP data packet to be retransmitted to obtain a new RTP data packet. The transmitting end further needs to establish a data link corresponding to the modified PT flag with the receiving end, and transmit the new RTP data packet to the receiving end over the RTP data link.
In the related art, upon receiving the retransmission indication message, the transmitting end is required to reestablish an RTP data link again, and a process for establishing the RTP data link is complex. Therefore, retransmission of the data packet is complicated, and the efficiency of data transmission is low.
FIG. 1 is a schematic structural diagram of an RTP frame according to an embodiment of the present invention. As illustrated in FIG. 1, one RTP frame comprises at least one RTP data packet, and FIG. 1 uses a case where one RTP frame comprises a plurality of RTP data packet as an example. Each RTP data packet may comprise an RTP header standard field (hereinafter referred to as an RTP header field), an RTP data field (not illustrated in FIG. 1), and an RTP padding field. The RTP data field may comprise an RTP standard load field, and the RTP data packet may further comprise an RTP header private extension field located between the RTP header field and the RTP data field. It should be noted that some RTP data packets in the RTP frame may comprise the RTP padding field whereas some of the RTP data packet may not comprise the RTP padding field, some RTP data packets may comprise the RTP header private extension field whereas some RTP data packet may not comprise the RTP header private extension field, and some RTP data packets may comprise the RTP data field whereas some RTP data packets may not comprise the RTP data field. In FIG. 1, the case where the RTP data packet comprises the RTP header private extension field, the RTP data field and the RTP padding field is taken as an example.
Further, FIG. 1 further illustrates a syntax format of a RTP header field. As illustrated in FIG. 1, in the syntax format of the RTP header field, "+" denotes a space symbol, and "—" or "=" between every adjacent two symbols "+" denotes 1 bit.
The RTP header field comprises a plurality of bits, wherein V=2 denotes a version flag which occupies 2 bits, and indicates a version of the RTP data packet of V=2.
P denotes a padding flag which occupies one bit and is intended to indicate whether a tail of the RTP data packet where the P is located is provided with an RTP padding field. Optionally, if the padding flag P is set to 1, it indicates that an RTP padding field is provided at the tail of the RTP data packet; and if the padding flag P is set to 0, it indicates that no RTP padding field is provided at the tail of the RTP data packet.
X denotes an extension flag which occupies one bit and is intended to indicate whether an extension field (that is, an RTP header private extension field) is present between the RTP header field and the RTP data field in the RTP data packet where X is located. Optionally, if the extension flag X is set to 1, it indicates that an extension field is present between the RTP header field and the RTP data field in the RTP data packet; and if the extension flag X is set to 0, it indicates that no extension field is present between the RTP header field and the RTP data field in the RTP data packet.
CC denotes a contributing source field flag which occupies 4 bits and is intended to indicate the contributing source count (CSRC).
M denotes a marker flag which occupies one bit and is intended to indicate whether the RTP data packet where M is located is the last RTP data packet in the RTP frame where the RTP data packet is located. Optionally, if the marker flag M is set to 1, it indicates that the RTP data packet is the last RTP data packet in the RTP frame; and if the marker flag M is set to 0, it indicates that the RTP data packet is not the last RTP data packet in the RTP frame.
PT denotes a valid payload type flag, which occupies 7 bits and is intended to indicate the type of the RTP data field in the RTP data packet where the PT is located, and the type of the RTP data packet is the same as the type of the RTP data field in the RTP data packet.
SN denotes a sequence number flag, which occupies 16 bits and is intended to indicate a transmission sequence of the RTP data packet where the SN is located, that is, a sequence of transmitting the RTP data packet by the receiving end to a decoder upon receiving the RTP data packet. In the process of transmitting a plurality of RTP data packets by the transmitting end, the value of the sequence number flag SN of the RTP data packet is typically increased by 1 each time an RTP data packet is transmitted. Optionally, sequence number flags of three RTP data packets A1, A2 and A3 transmitted by the transmitting end in sequence may be , 0000000000000000, 0000000000000001 and 0000000000000010 in sequence.
A timestamp flag occupies 32 bits and is intended to indicate a sampling instant of the RTP data field in the RTP data packet where the timestamp is located.
The syntax format of the RTP header field further comprises some other bits, for example, a synchronization source (SSRC) identifier, and a CSRC identifier, and the like, which are not described herein any further. In the syntax format of the RTP header field, the number of bits occupied by each of the flags may be adjusted. For example, the sequence number flag SN may further occupy 15 bits, and the valid payload type flag PT may further occupy 6 bits.
FIG. 2 is a flowchart of a method of transmitting data according to an embodiment of the present invention. The embodiment of the present invention Optionally describes the process that after the transmitting end initially transmits a plurality of first RTP data packets to the receiving end, the receiving end fails to receive all the first RTP data packets such that the transmitting end needs to retransmit data packets to be retransmitted among the plurality of first RTP data packets. Optionally, it is also possible that the receiving end receives all the first RTP data packets, which is not described in the embodiment of the present invention. As illustrated in FIG. 2, the method comprises the following steps:
Step 201: The transmitting end establishes an RTP data link with the receiving end.
In one embodiment of the present invention, each RTP data link only allows transmission of a type of RTP data packets. The type indicated by a type flag in such an RTP data packet corresponds to the RTP data link. For example, assuming that an RTP data link only allows transmission of RTP data packet of a media type. The type flag in such a media-type RTP data packet may be a valid payload type flag PT. If the valid payload type flag PT corresponds to bits 0000001, it may be indicated that the RTP data packet is of the media type, and in this case, in each RTP data packet transmitted over the RTP data link, the bits corresponding to the type flag, that is, the valid payload type flag PT, are 0000001.
Step 202: The transmitting end transmits a plurality of first RTP data packets to the receiving end over the RTP data link.
The transmitting end can transmit a plurality of first RTP data packets over the data link established in step 201, wherein the plurality of first RTP data packets are RTP data packets of the same type. Optionally, when the RTP data link established in step 201 is for transmitting data packets of the media type, the type flag (the valid payload type flag PT or the SSRC identifier as illustrated in FIG. 1) in each of the plurality of first RTP data packets may be intended to indicate that the first RTP data packets are of the media type.
In step 202, the transmitting end may transmit in sequence the plurality of first RTP data packets to the receiving end, and the transmission sequence of the plurality of first RTP data packets may be reflected by sequence numbers (that is, the values of the sequence number flags) in the first RTP data packets.
Step 203: The receiving end parses the received first RTP data packets.
By parsing the first RTP data packets, the receiving end may acquire each bit in the first RTP data packets, determine content of each bit, and thus determine information indicated by the content of each bit. The receiving end can further determine whether the first RTP data packets are retransmitted RTP data packets according to information indicated by the content of the bits in the first RTP data packets.
It should be noted that step 203 can be implemented by the embodiment corresponding to FIG. 6, which is not described herein any further.
Step 204: The receiving end stores RTP data fields in the first RTP data packets according to parsing results of the first RTP data packets.
In the embodiment of the present invention, description is given using the first RTP data packets are RTP data packets initially transmitted by the transmitting end. In this case, in step 203, the parsing results of the first RTP data packets show that the first RTP data packets are not the retransmitted RTP data packets, that is, the first RTP data packets are the RTP data packets that are initially transmitted by the transmitting end. In step 204, the receiving end can directly store the RTP data fields in the first RTP data packets in the format of the data that is initially transmitted.
Step 205: The receiver determines, according to the parsing results of the first RTP data packets, RTP data packets to be retransmitted.
In step S205, the receiving end may determine the RTP data packets to be retransmitted according to the parsing results obtained in step 203. Optionally, in step 203, the receiving end can further acquire a sequence number of each of the received first RTP data packets when parsing in sequence the received first RTP data packets. If a difference between a sequence number currently acquired by the receiving end and a previous sequence number acquired by the receiving end is greater than 1, in step 205, the receiving end may determine that the first RTP data packet corresponding to the sequence number between these two sequence numbers is lost.
Optionally, in step 203, the receiving end can further acquire a marker flag of each of the first RTP data packets when paring the received first RTP data packets, and determine, according to the marker flag whether the current first RTP data packet is the last RTP data packet transmitted by the transmitting end (that is, the last data packet among the plurality of first RTP data packets in step 202). When parting the received last first RTP data packet, if the receiving end determines that the received last RTP data packet is the last first RTP data packet that is transmitted by the transmitting end, the receiving end can determine that no data packet is lost after the received last first RTP data packet that is currently parsed. If the received last RTP data packet is not the last first RTP data packet that is transmitted by the transmitting end, the receiving end can determine the first RTP data packets following the currently parsed first RTP data packet in the plurality of first RTP data packets that are transmitted by the transmitting end are all lost. In step 205, the receiving end can determine that each lost first RTP data packet as an RTP data packet to be retransmitted.
Optionally, if the transmitting end transmits 5 first RTP data packets to the receiving end, A1, A2, A3, A4 and A5, respectively, wherein the sequence number in A1 is 0 (herein the sequence number is converted to a decimal for exemplary illustration), the sequence number in A2 is 1, the sequence number in A3 is 2, the sequence number in A4 is 3, and the sequence number in A5 is 4. In addition, the marker flag in A5 is intended to indicate that A5 is the last first RTP data packet transmitted by the transmitting end. If the receiving end receives in sequence A1, A2 and A4, by parsing A1, A2 and A4, the receiving end can determine that the difference (i.e., 2) between the sequence number (3) in A4 and the sequence number (1) in A2 is greater than 1, and the receiving end can determine that A3 corresponding to the sequence number 2 is lost. In addition, A4 is the last first RTP data packet received by the receiving end, after parsing A4, and the receiving end determines that A4 is not the last first RTP data packet transmitted by the transmitting end. In this case, the receiving end can determine the first RTP data packets following A4 among the plurality of RTP data packet transmitted by the transmitting end are all lost. Therefore, the receiving end can determine that the RTP data packets to be retransmitted comprise A3 and each of the first RTP data packet (that is, A5) transmitted by the transmitter after A4.
Step 206: The receiving end retransmits a retransmission indication message to the transmitting end, wherein the retransmission indication message is intended to indicate RTP data packets to be retransmitted among the plurality of first RTP data packets.
Optionally, the receiving end can transmit the retransmission indication message to the transmitting end to indicate that among the plurality of first RTP data packets A1, A2, A3, A4 and A5, packets A3 and A5 are the RTP data packets to be retransmitted.
Step 207: The transmitting end encapsulates, according to the retransmission indication message, the RTP data packets to be retransmitted to obtain a second RTP data packet.
Optionally, the second RTP data packet can comprise an RTP padding field indicating that the second RTP data packet is a retransmitted RTP data packet, and a type flag in the second RTP data packet is the same as a type flag in the first RTP data packet. Optionally, the type flag can be a valid payload type flag PT or an SSRC identifier.
As illustrated in FIG. 3, step 207 may comprise the following steps:
Step 2071: The transmitting end acquires a predetermined bytes per unit.
Optionally, in order to ensure that the receiving end conveniently processes the RTP data packets upon receiving the RTP data packets, the transmitting end can set the total bytes of the transmitted RTP data packets as an integer multiple of the bytes per unit, and the bytes per unit is an n^th power of 2, n being an integer greater than or equal to 1. Therefore, in the embodiment of the present invention, the total bytes of an RTP data packet to be transmitted may further be set as an integer multiple of the bytes per unit.
Optionally, the bytes per unit may be 4, and the total bytes of the RTP data packet to be retransmitted may be 100. The embodiment of the present invention is described by taking the bytes per unit as 4 as an example. Optionally, the bytes per unit may further be 2, or 8 or the like, which is not limited in the embodiment of the present invention.
Step 2072: The transmitting end determines, according to the bytes per unit, a padding unit constituted by m bytes.
m is an integer multiple of the bytes per unit. For example, the padding unit may be constituted by four bytes, that is, m=4.
Step 2073: The transmitting end encapsulates, according to the padding units, the RTP data packets to be retransmitted to obtain a second RTP data packet.
Optionally, when encapsulating, according to the padding units, the RTP data packets to be retransmitted, the transmitting end can first acquire padding flags in the RTP data packets to be retransmitted, and then determine, according to the padding flags, whether the RTP data packets to be retransmitted comprise padding fields.
If the RTP data packet to be retransmitted comprises a padding field, the transmitting end can directly suffix the padding unit to the RTP data packet to be retransmitted to obtain a second RTP data packet, wherein the padding flag (the same as the padding flag in the RTP header field in the RTP data packet to be retransmitted) in RTP header field in the second RTP data packet is intended to indicate that the second RTP data packet comprises a RTP padding field.
If the RTP data packet to be retransmitted does not comprise the RTP padding field, the transmitting end can suffix a padding unit to the RTP data packet to be retransmitted, and update the padding flag in the RTP header field in the RTP data packet to be retransmitted to obtain a second RTP data packet. In this way, the updated padding flag (different from the padding flag in the RTP header field in the RTP data packet to be retransmitted) is intended to indicate that the second RTP data packet comprises the RTP padding field.
Optionally, if a padding flag is 0, the padding flag is intended to indicate that the corresponding RTP data packet does not comprise an RTP padding field; and if a padding flag is 1, the padding flag is intended to indicate that the corresponding RTP data packet comprises an RTP padding field.
If the padding flag in the RTP header field in an RTP data packet to be retransmitted is 1, in step 2073, the transmitting end can suffix a padding unit to the RTP data packet to be retransmitted to obtain a second RTP data packet. In this way, the padding flag (that is, 1) in the RTP header field in the second RTP data packet is intended to indicate that the second RTP data packet comprises an RTP padding field. In this case, the RTP padding field in the second RTP data packet comprises the RTP padding field and the padding unit in the RTP data packet to be retransmitted. If the padding flag in the RTP header field in an RTP data packet to be retransmitted is 1, in step 2073, the transmitting end can suffix a padding unit to the RTP data packet to be retransmitted, and update the padding flag in the RTP data packet to be retransmitted from 0 to 1, such that a second RTP data packet is obtained. In this way, the padding flag (that is, 1) in the RTP header field in the second RTP data packet is intended to indicate that the second RTP data packet comprises an RTP padding field. In this case, the RTP padding field in the second RTP data packet comprises a padding unit.
Optionally, the padding unit can comprise a retransmission indication byte and a length indication byte. In each RTP data packet, the retransmission indication byte may be intended to indicate whether the RTP data packet is a retransmitted RTP data packet. Since the RTP data packet to be retransmitted is encapsulated in step 2073, in the padding unit added in the encapsulation process, the retransmission indication byte is intended to indicate that the second RTP data packet obtained by encapsulation is a retransmitted RTP data packet, and the retransmission indication byte may be a penultimate byte in the padding unit. The length indication byte is intended to indicate a length of the RTP padding field in the second RTP data packet, and the length indication byte may be a last byte in the padding unit.
The retransmission indication byte may comprise a retransmission flag, a data flag and a count flag that are arranged in sequence in the retransmission indication byte. In each RTP data packet, the retransmission flag in the retransmission indication byte may be intended to indicate whether the RTP data packet is a retransmitted RTP data packet. Since the RTP data packet to be retransmitted is encapsulated in step 2073, in the padding unit added in the encapsulation process, the retransmission flag is intended to indicate that the second RTP data packet obtained by encapsulation is a retransmitted RTP data packet, and the retransmission flag may comprise two bits, wherein these two bits may be the first two bits in the retransmission indication byte. The data flag in the retransmission indication byte is intended to indicate whether an RTP data field in the second RTP data packet is an RTP data field in the RTP data to be retransmitted, and the data flag may comprise 1 bit. The count flag in the retransmission indication byte is intended to indicate the quantity of times that the transmitting end transmits the second RTP data packet, and the count flag may comprise 3 bits. In addition to the retransmission indication byte and the length indication byte, the padding unit may not comprise other bytes, or may comprise other bytes. If the padding unit further comprises other bytes other than the retransmission indication byte and the length indication byte, each bit in the other bytes may be 1.
Prior to step 207, if the transmitting end has not deleted the RTP data packet to be retransmitted, the data flag in the padding unit determined by the transmitting end is intended to indicate that the RTP data field in the RTP data packet is the same as the RTP data field in the RTP data packet to be retransmitted. Prior to step 207, if the transmitting end has deleted the RTP data packet to be retransmitted, after step 206, the transmitting end may randomly select an RTP data packet as an alternative data packet, and perform step 207 on the alternative data packet, that is, encapsulating the alternative packet to obtain a second RTP data packet. In this case, the data flag in the padding unit determined by the transmitting end can be intended to indicate that the RTP data field in the RTP data packet is different from the RTP data field in the RTP data packet to be retransmitted.
Upon transmitting a retransmission instruction to the transmitting end, the receiving end may detect, at regular time intervals, whether the second RTP data packet transmitted by the transmitting end is received. If the receiving end fails to detect the second RTP data packet transmitted by the transmitting end when the predetermined time period expires, the receiving end will re-transmit a retransmission instruction to the transmitting end to instruct the transmitting end to retransmit the second RTP data packet. In this way, it can be ensured that the receiving end receives the retransmitted RTP data packet. Correspondingly, in the padding unit, the count flag N is intended to indicate the number of times that the transmitting end transmits the second RTP data packet, and a count of bits occupied by the count flag N is intended to limit a maximum transmission count (that is, the maximum number of times that the transmitting end transmits the same second RTP data packet to the receiving end). That is, in the embodiment of the present invention, the maximum number of times that the transmitter transmits the second RTP data packet to the receiving end is limited. As such, the transmitting end is prevented from transmitting the second RTP data packet for multiple times to the receiving end where the receiving end encounters a fault and thus fails to receive the second RTP data packet, such that waste of resources is reduced.
Optionally, FIG. 4 is a schematic structural diagram of a padding unit 40. As illustrated in FIG. 4, the padding unit 40 can be constituted by 4 bytes. These 4 bytes may comprise a retransmission indication byte a and a length indication byte b. The retransmission indication byte a is a penultimate byte in the padding unit 40, and the length indication byte is a last byte in the padding unit 40. The retransmission indication byte a can comprise a retransmission flag V, a data flag F, a count flag N and a reserved flag R. The retransmission flag V, the data flag F, the count flag N and the reserved bit R are arranged in sequence in the retransmission indication byte. The value of the reserved bit R may be set according to the actual needs, and if the reserved bit R has no predefined designated meaning, the value of the reserved bit R can be set to a predetermined value, for example, 1 or 0. It should be noted that the symbol "-" between each two adjacent symbols "+" represents one bit in FIG. 4. The retransmission flag V occupies two bits, the data flag F occupies one bit, the count flag N occupies three bits, and the reserved bit R occupies two bits.
Optionally, if the retransmission flag V is 01, it indicates that the second RTP data packet is a retransmitted RTP data packet; and if the retransmission flag V is 00, 10 or 11, it indicates that the second RTP data packet is not a retransmitted RTP data packet. If the retransmission flag V is 01 and the data flag F is 1, it indicates that the second RTP data packet is a retransmitted RTP data packet requested by the receiving end; and if the retransmission flag V is 01 and the data flag F is 0, it indicates that the second RTP data packet is not a retransmitted RTP data packet requested by the receiving end, and may be a common RTP data packet. The count flag N in FIG. 4 occupies three bits. When the transmitting end transmits the second RTP data packet for a first time, the count flag N is 000; when the transmitting end transmits the second RTP data packet for a second time, the count flag N is 001; and analogously, when the transmitting end transmits the second RTP data packet for an eighth time, the count flag N is 111, which is the last time that the transmitting end transmits the second RTP data packet to the receiving end.
It should be noted that when the transmitting end performs step 2073, if the RTP data packet to be retransmitted does not comprise an RTP padding field, the RTP padding field in the second RTP data packet obtained by the transmitting end only comprises a padding unit; and if the RTP data packet to be retransmitted comprises an RTP padding field, the RTP padding filed in the second RTP data packet obtained by the transmitting end comprises a padding unit and the RTP padding field in the RTP data packet to be retransmitted.
Assuming that the RTP data packet to be retransmitted does not comprise an RTP padding field, that is, the RTP padding field in the second RTP data packet only comprises a padding unit 40 as illustrated in FIG. 4, the padding unit 40 is constituted by four bytes, and in this case, the content of the length indication byte b is 00000100. Still assuming that the RTP data packet to be retransmitted does comprise an RTP padding field, and the RTP padding field in the second RTP data packet is as illustrated in FIG. 1, the RTP padding field may comprise a padding data portion, a user-defined portion and an extension length portion. The padding data portion may be the RTP padding field in the RTP data packet to be retransmitted, and the user-defined portion and the extension length portion may collaboratively constitute a padding unit, the extension length portion may be a length indication byte in the padding unit, and the user-defined portion may be a remaining portion in the padding unit except the length indication byte. For example, if the padding data is constituted by four bytes, and the padding unit is still the padding unit 40 as illustrated in FIG. 4, the content of the length indication byte b is 00001000.
FIG. 5 is a schematic structural diagram of an RTP data packet to be retransmitted and a second RTP data packet according to an embodiment of the present invention. Optionally, FIG. 5 illustrates four RTP data packets obtained by encapsulating four different RTP data packets. As illustrated in FIG. 5, in each RTP data packet to be retransmitted, each small cell denotes 4 bytes; and in each second RTP data packet, each cell denotes 1 byte. As illustrated in FIG. 5, a first RTP data packet to be retransmitted comprise an RTP padding field having a length of 8 bytes, a second RTP data packet to be retransmitted comprises an RTP padding field having a length of 7 bytes, a third RTP data packet to be retransmitted comprise an RTP padding field having a length of 4 bytes, and a fourth RTP data packet to be retransmitted comprises no RTP padding field. When encapsulating each RTP data packet to be retransmitted, the transmitting end can suffix a padding unit having a length of 4 bytes to each RTP data packet to be retransmitted, wherein a penultimate byte in the padding unit is a retransmission indication byte, and a last byte is a length indication byte.
In four second RTP data packets as illustrated in FIG. 5, an RTP padding field in a first second RTP data packet may have a length of 12 bytes (8 bytes + 4 bytes), and in this case a length indication byte b1 has bits of 00001100; an RTP padding field in a second RTP data packet may have a length of 11 bytes (7 bytes + 4 bytes), and in this case a length indication byte b2 has bits of 00000111; an RTP padding field in a third second RTP data packet may have a length of 8 bytes (4 bytes + 4 bytes), and in this case a length indication byte b3 has bits of 00001000; and an RTP padding field in a fourth second RTP data packet may have a length of 4 bytes (0 byte + 4 bytes), and in this case a length indication byte b4 has bits of 00000100.
Step 208: The transmitting end transmits second RTP data packets to the receiving end over the RTP data link.
The RTP data link herein is the RTP data link established between the transmitting end and the receiving end in step 201. Since the type flag in the second RTP data packet is the same as the type flag in each of the first RTP data packets (comprising the RTP data packets to be retransmitted, the type of the second RTP data packet is the same as the type of the first RTP data packet. Therefore, the transmitting end can transmit the second RTP data packets to the receiving end over the RTP data link established in step 201, with no need to establish a new RTP data link.
Step 209: The receiving end parses the received second RTP data packets.
By parsing the second RTP data packet, the receiving end can acquire each bit in the second RTP data packet, determine content of each bit, and thus determine information indicated by the content of each bit, such that the receiving end determines, according to the information indicated by the content of the bits in the second RTP data packet, whether the second RTP data packet is a retransmitted RTP data packet.
Step 209 can be implemented by the embodiment corresponding to FIG. 6, which is not described herein any further.
Step 210: The receiving end stores RTP data fields in the second RTP data packets according to parsing results of the second RTP data packets.
In the embodiment of the present invention, since the second RTP data packet is as the RTP data packet retransmitted by the transmitting end, and the RTP data field in the second RTP data packet is the same as the RTP data field in the RTP data packets for which the transmitting end requests retransmission, in step 209, the parsing result of the second RTP data packet is that the second RTP data packet is a retransmitted RTP data packet, that is, the second RTP data packet is an RTP data packet retransmitted by the transmitting end. In step 210, the receiving end can directly store the RTP data field in the second RTP data packet in a format of retransmission.
In step 204 and step 210, when the receiving end stores the RTP data field in the RTP data packet, the RTP data field is stored in the format of retransmission and in the format of initial transmission respectively. Therefore, the RTP data field in the RTP data packet that is initially transmitted may be effectively distinguished from the RTP data field in the retransmitted RTP data packet. Hence, packet loss ratios (the packet loss ratio is a ratio of the number of packets lost within a unitary time period to the number of packets that shall be theoretically received) may be more conveniently collected. It should be noted that, on one hand, the lost packets may comprise RTP data packets that are successfully retransmitted and RTP data packet that fail to be successfully retransmitted; and on the other hand, the lost packets can only comprise RTP data packets that fail to be successfully retransmitted (without RTP data packets that are successfully retransmitted).
Further, in step 203 and step 209, the receiving end parses the received RTP data packet (for example, in step 203, the receiving end parses the received first RTP data packet, and in step 209, the receiving end parses the received second RTP data packet). Upon parsing the RTP data packet, the receiving end stores the RTP data field in the RTP data packet according to the parsing result (for example, upon step 203, the receiving end stores the RTP data field in the first RTP data packet according to the parsing result of the first RTP data packet; and upon step 209, the receiving end stores the RTP data field in the second RTP data packet according to the parsing result of the second RTP data packet).
Optionally, when parsing the received RTP data packet, the receiving end can first acquire a predetermined bytes per unit, and then partition the received RTP data packet (the first RTP data packet or the second RTP data packet) into a plurality of data segments, wherein each data segment has a total bytes equal to the bytes per unit. Finally, the receiving end can parse the plurality of data segments in the RTP data packet respectively, that is, the receiving end parses each bit in the RTP data packet with the data segment as a unit. For example, the receiving end parses the padding flag, the retransmission flag, the data flag and the count flag in the RTP data packet.
As illustrated in FIG. 6, the receiving end parsing the received RRP data packets, and storing the RTP data fields in the RTP data packets according to the parsing results of the RTP data packets may specifically comprise:
Step 301: The receiving end acquires the padding flags in the RTP header fields in the RTP data packets. Step 302 is performed.
As illustrated in FIG. 1, the receiving end may acquire the third bit (that is, the padding flag) in the RTP header field.
Step 302: The receiving end judges, according to the padding flags, whether the RTP data packets comprise a RTP padding field. If the RTP data packets comprise the RTP padding fields, step 303 is performed; and if the RTP data packets do not comprise the RTP padding fields, step 309 is performed.
Optionally, the padding flag in the RTP header field in the RTP data packet may be intended to indicate whether the RTP data packet comprises an RTP padding field. Therefore, the receiving end may determine, according to the padding flags, whether the RTP data packet comprises the RTP padding field.
Step 303: The receiving end acquires the retransmission flags in the RTP padding fields in the RTP data packets, and judges whether the RTP data packets are the retransmitted RTP data packets. If the RTP data packets are the retransmitted RTP data packets, step 304 is performed. If the RTP data packets are not the retransmitted RTP data packets, step 309 is performed.
Referring to FIG. 4, in step 303, the receiving end may acquire the first two bits (that is, the retransmission flags) in the penultimate byte in the RTP padding field. Optionally, if the retransmission flag V is 01, it indicates that the RTP data packet is a retransmitted RTP data packet; and if the retransmission flag V is 00, 10 or 11, it indicates that the RTP data packet is not a retransmitted RTP data packet.
Step 304: The receiving end acquires the data flags in the RTP padding fields in the RTP data packets. Step 305 is performed.
Referring to FIG. 4, the receiving end may acquire the third bits (that is, the data flags) in the penultimate byte in the RTP padding field.
Step 305: The receiving end judges, according to the data flags, whether the RTP data fields in the RTP data packets are the RTP data fields in the RTP data packets to be retransmitted. If the RTP data packets in the RTP data packets are the RTP data fields in the RTP data packets to be retransmitted, step 306 is performed. If the RTP data packets in the RTP data packets are not the RTP data fields in the RTP data packets to be retransmitted, step 308 is performed.
Optionally, still referring to FIG. 4, the receiving end acquires the data flag F in the RTP data packet. If the data flag F is 1, it indicates that the RTP data field in the RTP data packet is the RTP data field in the RTP data packet to be retransmitted. If the data flag F is 0, it indicates that the RTP data field in the RTP data packet is not the RTP data field in the RTP data packet to be retransmitted.
Step 306: The receiving end acquires bits in the length indication bytes in the RTP padding fields in the RTP data packets. Step 307 is performed.
Step 307: The receiving end acquires and stores the RTP data fields in the RTP data packets according to the bits in the length indication bytes and a predetermined lengths of the RTP header fields.
In step 307, the receiving end may first determine the length of the RTP padding field according to the bits in the length indication byte; and then the receiving end may acquire the predetermined length of the RTP header field in the RTP data packet, and determine the bits corresponding to the RTP data field in the RTP data packet according to the length of the RTP padding field and the predetermined length of the RTP header field in the RTP data packet. Finally, the receiving end may acquire the RTP data field according to the bits corresponding to the RTP data field, and store the RTP data field a the format of retransmission.
Optionally, the bits of the length indication byte in an RTP data packet may be 00001000, and the receiving end may determine that the padding field in the RTP data packet has a length of 8 bytes according to the length flag. The receiving end may further acquire the predetermined length of the RTP header field in the RTP data packet, for example, the predetermined length is 9 bytes. In this case, the receiving end may determine that in the RTP data packet, the bits of all the bytes between the ninth byte to the ninth last byte are bits corresponding to the RTP data field, and then the receiver may acquire the RTP data field according to the bits and stores the RTP data field in the format of retransmission.
Step 307 corresponds to step 210 in the embodiment as illustrated in FIG. 2. With respect to the second RTP data packet determined in step 207 in the above embodiment, upon step 304 and step 305, if the receiving end determines that the RTP data field in the second RTP data packet is the RTP data field in the RTP data packet to be retransmitted, the receiving end may directly store the RTP data field in the second RTP data packet in the format of retransmission.
Step 308: The receiving end deletes the RTP data packets.
In step 308, the receiving end may determine, according to a judgment result in step 305, whether to perform the step of deleting the RTP data packets in step 308. Optionally, if the receiving end determines in step 305 that the RTP data field in the RTP data packet is not the RTP data field in the RTP data packet to be retransmitted, the receiving end can determine that the received RTP data packet is an alternative data packet transmitted by the transmitting end other than the RTP data packet for which the receiving end requests retransmission. Therefore, the receiving end can directly delete the RTP data packet.
Step 309: The receiving end acquires and stores the RTP data fields in the RTP data packets according to the predetermined lengths of the RTP header fields in the RTP data packets.
Optionally, if it is determined in step 302 that a received RTP data packet comprises no RTP padding field, or it is determined in step 303 that the RTP data packet is not the retransmitted RTP data packet, the receiving end can determine that the RTP data packet is the RTP data packet that is initially transmitted by the transmitting end, and perform the step of acquiring the RTP data field in the RTP data packet in step 309. The receiving end can further perform step 204, that is, can store the RTP data field in the format of initial transmission.
In step 309, the receiving end can first acquire the predetermined length of the RTP header field in the RTP data packet, and then determine the bits corresponding to the RTP data field in the RTP data packet according to the length of the RTP padding field. Finally, the receiving end can acquire the RTP data field in the RTP data packet, and stores the RTP data field in the RTP data packet in a format of initial transmission.
Optionally, if the receiving end determines that the received RTP data packet comprises no RTP padding field, the receiver can determine that the RTP data packet is an RTP data packet that is initialed transmitted by the transmitting end, and the receiving end can acquire a predetermined length of the RTP header field in the RTP data packet, for example, the predetermined length is 9 bytes. The receiving end can determine bits of all the bytes following the ninth byte in the RTP data packet as the bits corresponding to the RTP data field, acquire the RTP data field in the RTP data packet according to the bits, and store the RTP data field in a format of initial transmission.
Step 309 corresponds to step 204 in the embodiment as illustrated in FIG. 2. With respect to the first RTP data packet in the above embodiment, upon step 302 and step 303, if the receiving end can determine that the first RTP data packet is the RTP data packet that is initially transmitted by the transmitting end, the receiving end can directly store the RTP data field in the first RTP data packet in a format of initial transmission.
In step 307 and step 309, when the receiving end stores the RTP data field in the RTP data packet, the RTP data field is stored in a format of retransmission and in a format of initial transmission respectively. Therefore, the RTP data field in the RTP data packet that is initially transmitted can be effectively distinguished from the RTP data field in the retransmitted RTP data packet. Hence, packet loss ratios (the packet loss ratio is a ratio of the number of packets lost within a unit time period to the number of packets that shall be theoretically received) can be more conveniently collected. It should be noted that, on one hand, the lost packets can comprise RTP data packets that are successfully retransmitted and RTP data packet that fail to be successfully retransmitted; and on the other hand, the lost packets may only comprise RTP data packets that fail to be successfully retransmitted (without RTP data packets that are successfully retransmitted).
In summary, in the method of transmitting data according to the embodiment of the present invention, in a second RTP data packet obtained after the transmitting end encapsulates an RTP data packet to be retransmitted, the RTP padding field can indicate that the second RTP data packet is a retransmitted RTP data packet, and the type flag in the first RTP data packet is the same as the type flag in the second RTP data packet. Therefore, the second RTP data packet and the first RTP data packet can be transmitted over the same RTP data link, and prior to transmitting the RTP data packet to be retransmitted, the transmitting end does not need to establish an RTP data link with the receiving end. In this way, the steps of data packet retransmission are simplified, and the efficiency of data transmission is improved.
FIG. 7 is a schematic structural diagram of a data transmitting device 70 according to an embodiment of the present invention. The device is applicable to a transmitting end. As illustrated in FIG. 7, the device 70 comprises:

a first transmitting module 701, configured to transmit a plurality of first RTP data packets to a receiving end over a Real-time Transport Protocol (RTP) data link established with the receiving end;
a receiving module 702, configured to receive a retransmission indication message sent by the receiving end, the retransmission indication message being intended to indicate an RTP data packet to be retransmitted in the plurality of first RTP data packets;
an encapsulating module 703, configured to encapsulate the RTP data packet to be retransmitted according to the retransmission indication message to obtain a second RTP data packet, wherein the second RTP data packet comprises an RTP padding field intended to indicate that the second RTP data packet is a retransmitted RTP data packet, and a type flag in the second RTP data packet is the same as a type flag in the first RTP data packet; and
a second transmitting module 704, configured to transmit the second RTP data packet to the receiving end over the RTP data link.

In summary, in the data transmitting device according to the embodiment of the present invention, in a second RTP data packet obtained after the encapsulating module encapsulates an RTP data packet to be retransmitted, the RTP padding field can indicate that the second RTP data packet is a retransmitted RTP data packet, and the type flag in the first RTP data packet is the same as the type flag in the second RTP data packet. Therefore, the second RTP data packet and the first RTP data packet can be transmitted over the same RTP data link, and prior to transmitting the RTP data packet to be retransmitted, the transmitting end does not need to establish an RTP data link with the receiving end. In this way, the steps of data packet retransmission are simplified, and the efficiency of data transmission is improved.
Optionally, the encapsulating module is further configured to suffix a padding unit to the RTP data packet to be retransmitted, the RTP padding field in the second RTP data packet comprising the padding unit, the padding unit comprising a retransmission indication byte, the retransmission indication byte being intended to indicate that the second RTP data packet is the retransmitted RTP data packet.
Optionally, the retransmission indication byte at least comprises a retransmission flag and a count flag. The retransmission flag is intended to indicate that the second RTP data packet is the retransmitted RTP data packet; and the count flag is intended to indicate the times that the transmitting end transmits the second RTP data packet.
Optionally, the retransmission indication byte further comprises a data flag. The data flag is intended to indicate whether an RTP data field in the second RTP data packet is an RTP data field in the RTP data packet to be retransmitted.
Optionally, the padding unit further comprises a length indication byte, wherein the length indication byte is intended to indicate a length of the RTP padding field in the second RTP data packet.
Optionally, the retransmission indication byte is a penultimate byte in the padding unit, and the length indication byte is a last byte in the padding unit; the retransmission indication byte comprises two bits, and the count indication byte comprises three bits, and the data indication byte comprises one bit; and the retransmission flag, the data flag and the count flag are arranged in sequence in the retransmission indication field, and the two bits in the retransmission flag are first two bits in the retransmission indication byte.
Optionally, the encapsulating module is further configured to: judge whether the RTP data packet to be retransmitted comprises the RTP padding field; if the RTP data packet to be retransmitted comprises the RTP padding field, suffix a padding unit to the RTP data packet to be retransmitted to obtain a second RTP data packet, the padding unit comprising a retransmission indication byte, the retransmission indication byte being intended to indicate that the second RTP data packet is the retransmitted RTP data packet; or if the RTP data packet to be retransmitted does not comprise a RTP padding field, suffix a padding unit to the RTP data packet to be retransmitted, and update a padding flag in an RTP header field in the RTP data packet to be retransmitted to obtain the second RTP data packet, wherein the updated padding flag is intended to indicate that the second RTP data packet comprises the RTP padding field.
Optionally, the encapsulating module is further configured to: acquire a predetermined bytes per unit, a total bytes of the RTP data packet to be retransmitted being an integer multiple of the bytes per unit, and the bytes per unit being an nth power of 2, n being an integer greater than or equal to 1; and determine, according to the bytes per unit, the padding unit constituted by m bytes, m being an integer multiple of the bytes per unit.
FIG. 8 is a schematic structural diagram of another data transmitting device80 according to an embodiment of the present invention. The data transmitting device is applicable to a receiving end. As illustrated in FIG. 8, the data transmitting device 80 comprises:

a receiving module 801, configured to receive an RTP data packet from a transmitting end over a Real-time Transport Protocol (RTP) data link established with the transmitting end; and
a first determining module 802, configured to determine whether the RTP data packet is a retransmitted RTP data packet according to the RTP padding field in the RTP data packet when the RTP data packet comprises an RTP padding field.

In summary, in the data transmitting device according to the embodiment of the present invention, the first determining module can determine, according to an RTP padding field in an RTP data packet, whether the RTP data packet is a retransmitted RTP data packet. That is, a retransmitted RTP data packet can be identified according to an RTP padding field, with no need to modify a type flag in the retransmitted RTP data packet. Therefore, the receiving end and the transmitting end do not need to reestablish an RTP data link to transmit the RTP data packet to be retransmitted. In this way, the steps of data packet retransmission are simplified, and the efficiency of data transmission is improved.
Optionally, the first determining module can be further configured to: acquire a retransmission indication byte in the RTP padding field; and determine, according to the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet.
Optionally, the retransmission indication byte at least comprises a retransmission flag and a count flag, the count flag being intended to indicate the times that the transmitting end sends the RTP data packet.
The first determining module can be further configured to determine, according to the retransmission flag in the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet.
Optionally, the retransmission indication byte can further comprise a data flag. As illustrated in FIG. 8, based on FIG. 9, the data transmitting device 80 can further comprise:

a first acquiring module 803, configured to acquire the data flag in the retransmission indication byte when the retransmission flag is intended to indicate that the RTP data packet is the retransmitted RTP data packet;
a second acquiring module 804, configured to acquire and store the RTP data field in the RTP data packet when the data flag is intended to indicate that the RTP data field in the RTP data packet is an RTP data field in the RTP data packet to be retransmitted; or
a deleting module 805, configured to delete the RTP data packet if the data flag is intended to indicate that the RTP data field in the RTP data packet is not an RTP data field in the RTP data packet to be retransmitted.

Optionally, as illustrated in FIG. 12, based on FIG. 9, the data transmitting device 80 can further comprise:

a fifth acquiring module 811, configured to acquire a length indication byte in the RTP padding field;
a third determining module 812, configured to determine a length of the RTP padding field according to the length indication byte;
a sixth acquiring module 813, configured to acquire a predetermined length of an RTP header field in the RTP data packet; and
a fourth determining module 814, configured to determine the RTP data field in the RTP data packet according to the length of the RTP padding field and the predetermined length of the RTP header field in the RTP data packet.

Optionally, the retransmission indication byte can be a penultimate byte in the padding unit, and the length indication byte can be a last byte in the padding unit; the retransmission flag can comprise two bits, and the count flag may comprise three bits, and the data flag may comprise one bit; and the retransmission flag, the data flag and the count flag can be arranged in sequence in the retransmission indication field, and the two bits in the retransmission flag can be first two bits in the retransmission indication byte.
Optionally, as illustrated in FIG. 10, based on FIG. 8, the data transmitting device 80 can further comprise:

a third acquiring module 806, configured to acquire a padding flag in an RTP header field in the RTP data packet; and
a second determining module 807, configured to determine, according to the padding flag, whether the RTP data packet comprises the RTP padding field.

Optionally, as illustrated in FIG. 11, based on FIG. 8, the data transmitting device 80 can further comprise:

a fourth acquiring module 808, configured to acquire a predetermined bytes per unit;
a partitioning module 809, configured to partition the RTP data packet into a plurality of data segments according to the bytes per unit, a total bytes of each of the data segments being equal to the bytes per unit; and
a parsing module 810, configured to parse the plurality of data segments respectively.

In summary, in the data transmitting device according to the embodiment of the present invention, the first determining module may determine, according to an RTP padding field in an RTP data packet, whether the RTP data packet is a retransmitted RTP data packet. That is, a retransmitted RTP data packet can be identified according to an RTP padding field, with no need to modify a type flag in the retransmitted RTP data packet. Therefore, the receiving end and the transmitting end do not need to reestablish an RTP data link to transmit the RTP data packet to be retransmitted. In this way, the steps of data packet retransmission are simplified, and the efficiency of data transmission is improved.
An embodiment of the present invention provides a system for transmitting data. The system may comprise a transmitting end and a receiving end.
The transmitting end may comprise the data transmitting device as illustrated in FIG. 7, and the receiving end may comprise the data transmitting device as illustrated in any one of FIG. 8 to FIG. 12.
FIG. 13 is a schematic structural diagram of a computer device 01 according to an embodiment of the present invention. The computer device may be applied to the transmitting end in the system for transmitting data. The computer device 01 may comprise a processor 011 and a memory 012.
The memory 012 is configured to store a computer program.
The processor 011 is configured to perform the program stored on the memory 012 to perform step 201, step 202, step 207, and step 208 in the above method of transmitting data. Optionally, the method can comprise:

transmitting a plurality of first RTP data packets to a receiving end over a Real-time Transport Protocol (RTP) data link established with the receiving end;
receiving a retransmission indication message sent by the receiving end, the retransmission indication message being intended to indicate an RTP data packet to be retransmitted among the plurality of first RTP data packets;
encapsulating the RTP data packet to be retransmitted according to the retransmission indication message to obtain a second RTP data packet, wherein the second RTP data packet comprises an RTP padding field intended to indicate that the second RTP data packet is a retransmitted RTP data packet, and a type flag in the second RTP data packet is the same as a type flag in the first RTP data packet; and
transmitting the second RTP data packet to the receiving end over the RTP data link.

Optionally, the processor 011 comprises one or a plurality of processing cores. The processor 011 runs the computer program stored on the memory 012 to perform various functional applications and data processing, wherein the computer program comprises software applications and units.
The computer program stored on the memory 012 comprises software applications and units. Optionally, the memory 012 can store an operating system 0121, and an application program unit 0122 required for at least one function. The operating system 0121 can be Real Time eXecutive (RTX), LINUX, UNIX, WINDOWS or OS X or the like operating system. The application program unit 0122 may comprise a first transmitting unit 0122a, a receiving unit 0122b, an encapsulating unit 0122c and a second transmitting unit 0122d.
The first transmitting unit 0222a has the same or similar function as the first transmitting module 701 in the data transmitting device as illustrated in FIG. 7.
The receiving unit 0122b has the same or similar function as the receiving module 702 in the data transmitting device as illustrated in FIG. 7.
The encapsulating unit 0122c has the same or similar function as the encapsulating module 703 in the data transmitting device as illustrated in FIG. 7.
The second transmitting unit 0122d has the same or similar function as the second transmitting module 704 in the data transmitting device as illustrated in FIG. 7.
FIG. 14 is a schematic structural diagram of a computer device 02 according to another embodiment of the present invention. The computer device can be applicable to the receiving end in the system for transmitting data. The computer device 02 may comprise a processor 021 and a memory 022.
The memory 022 is configured to store a computer program.
The processor 021 is configured to perform the program stored on the memory 022 to perform step 201, step 203, step 204, step 205, step 206, step 209 and step 210 in the above method of transmitting data. Optionally, the method may comprise:

receiving an RTP data packets from a transmitting end over a Real-time Transport Protocol (RTP) data link established with a transmitting end; and
if the RTP data packet comprises an RTP padding field, determining, according to the RTP padding field in the RTP data packet, whether the RTP data packet is a retransmitted RTP data packet.

Optionally, the processor 021 comprises one or a plurality of processing cores. The processor 021 runs the computer program stored on the memory 022 to perform various functional applications and data processing, wherein the computer program comprises software applications and units.
The computer program stored on the memory 022 comprises software applications and units. Optionally, the memory 022 can store an operating system 0221, and an application program unit 0222 desired by at least one function. The operating system 0221 may be RTX, LINUX, UNIX, WINDOWS or OS X or the like operating system. The application program unit 0222 may comprise a receiving unit 0222a and a first determining unit 0222b.
The receiving unit 0222a has the same or similar function as the receiving module 801 in the data transmitting device as illustrated in FIG. 8.
The first determining unit 0222b has the same or similar function as the first determining module 802 in the data transmitting device as illustrated in FIG. 8.
An embodiment of the present invention provides a storage medium. The storage medium may be a non-volatile computer-readable storage medium which stores code instructions. The code instructions may be executed by a processor to perform step 201, step 202, step 205, step 207 and step 208 in the above method of transmitting data or perform step 201, step 203, step 204, step 205, step 206, step 209 and step 210 in the above method of transmitting data.
An embodiment of the present invention further provides a computer program product comprising instructions. The computer program product, when being run on a computer, may cause the computer to perform step 201, step 202, step 205, step 207 and step 208 in the above method of transmitting data or perform step 201, step 203, step 204, step 205, step 206, step 209 and step 210 in the above method of transmitting data.
An embodiment of the present invention further provides a chip. The chip comprises a programmable logic circuit and/or program instructions. When the chip runs, the programmable logic circuit and/or program instructions may be configured to perform step 201, step 202, step 205, step 207 and step 208 in the above method of transmitting data or perform step 201, step 203, step 204, step 205, step 206, step 209 and step 210 in the above method of transmitting data.
It should be noted that, during data transmission by the data transmitting device according to the above embodiments, the data transmitting device are described by only using division of the above functional modules as examples. In practice, the functions may be assigned to different functional modules for implementation as required. To be specific, the internal structure of the data transmitting device is divided into different functional modules to implement all or part of the above-described functions. In addition, the data transmitting device according to the above embodiment is based on the same inventive concept as the method of transmitting data according to the embodiments of the present invention. The specific implementation is elaborated in the method embodiments, which is not be detailed herein any further.

Claims

A method of transmitting data, applicable to a transmitting end, the method comprises:
transmitting (202) a plurality of first Real-time Transport Protocol, RTP, data packets to a receiving end over an RTP data link established previously (201) with the receiving end;

receiving (206) a retransmission indication message sent by the receiving end, the retransmission indication message indicating an RTP data packet to be retransmitted among the plurality of first RTP data packets; and

suffixing (207) a padding unit to the RTP data packet to be retransmitted according to the retransmission indication message to obtain a second RTP data packet, wherein the second RTP data packet comprises an RTP padding field that indicates that the second RTP data packet is a retransmitted RTP data packet, a type flag of the second RTP data packet is same as a type flag of the first RTP data packet, and an RTP padding field in the second RTP data packet comprises the padding unit, wherein

the padding unit comprises a retransmission indication byte and a length indication byte, and the retransmission indication byte at least comprises a retransmission flag, a count flag and a data flag, wherein the retransmission flag indicates that the second RTP data packet is the retransmitted RTP data packet, the count flag indicates the number of times that the transmitting end transmits the second RTP data packet, the data flag indicates whether an RTP data field in the second RTP data packet is an RTP data field in the RTP data packet to be retransmitted, and the length indication byte indicates a length of the RTP padding field in the second RTP data packet;

the method further comprises:
transmitting (208) the second RTP data packet to the receiving end over the RTP data link, wherein the second RTP data packet and the first data packets are transmitted over the same RTP data link.
The method according to claim 1, wherein
the retransmission indication byte is a penultimate byte in the padding unit, and the length indication byte is a last byte in the padding unit;

the retransmission flag comprises two bits, the count flag comprises three bits, and the data flag comprises one bit; and

the retransmission flag, the data flag and the count flag are arranged in sequence in the retransmission indication byte, and the two bits in the retransmission flag are first two bits in the retransmission indication byte.
The method according to claim 1, wherein suffixing (207) a padding unit to the RTP data packet to be retransmitted according to the retransmission indication message comprises:
judging whether the RTP data packet to be retransmitted comprises the RTP padding field;

when the RTP data packet to be retransmitted comprises the RTP padding field, suffixing a padding unit to the RTP data packet to be retransmitted to obtain the second RTP data packet, the padding unit comprising a retransmission indication byte, the retransmission indication byte indicating that the second RTP data packet is a retransmitted RTP data packet; or

when the RTP data packet to be retransmitted does not comprise the RTP padding field, suffixing a padding unit to the RTP data packet to be retransmitted, and updating a padding flag in an RTP header field in the RTP data packet to be retransmitted to obtain the second RTP data packet, wherein the updated padding flag indicating that the second RTP data packet comprises the RTP padding field.
The method according to any one of claims 2 to 3, wherein suffixing (207) a padding unit to the RTP data packet to be retransmitted according to the retransmission indication message further comprises:
acquiring (2071) a predetermined bytes per unit, a total bytes of the RTP data packet to be retransmitted being an integer multiple of the bytes per unit, and the bytes per unit being an n^th power of 2, n being an integer greater than or equal to 1; and

determining (2072), according to the bytes per unit, the padding unit constituted by m bytes, m being an integer multiple of the bytes per unit.
A method of transmitting data, applicable to a receiving end, the method comprises:
sending a retransmission indication message (206) to a transmitting end, the retransmission indication message indicating an RTP data packet to be retransmitted among a plurality of first RTP data packets, and in response receiving the RTP data packet sent by the transmitting end (207) over a Real-time Transport Protocol, RTP, data link established previously (201) with the transmitting end; and

acquiring a retransmission indication byte in the RTP padding field, when the RTP data packet comprises the RTP padding field and a length indication byte indicating a length of the RTP padding field, wherein

the retransmission indication byte at least comprises a retransmission flag, a count flag and a data flag, the count flag indicating the number of times that the transmitting end transmits the RTP data packet;

determining (303) , according to the retransmission flag in the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet;

when the retransmission flag indicates that the RTP data packet is the retransmitted RTP data packet, acquiring (304) the data flag in the retransmission indication byte;

when the data flag indicates that an RTP data field in the RTP data packet is an RTP data field in the RTP data packet to be retransmitted, acquiring and storing (307) the RTP data field in the RTP data packet; and

when the data flag indicates that an RTP data field in the RTP data packet is not an RTP data field in the RTP data packet to be retransmitted, deleting (308) the RTP data packet;

wherein, the retransmitted RTP data packet is the corresponding retransmitted RTP data packet of a first RTP data packet, and the retransmitted RTP data and the first RTP data packet are transmitted over the same RTP data link.
The method according to claim 5, wherein after receiving the RTP data packets sent by the transmitting end over the RTP data link established with the transmitting end, the method further comprises:
acquiring the length indication byte in the RTP padding field;

determining a length of the RTP padding field according to the length indication byte;

acquiring a predetermined length of an RTP header field in the RTP data packet; and

determining the RTP data field in the RTP data packet according to the length of the RTP padding field and the predetermined length of the RTP header field in the RTP data packet.
The method according to claim 6, wherein
the retransmission indication byte is a penultimate byte in a padding unit, and the length indication byte is a last byte in the padding unit;

the retransmission flag comprises two bits, and the count flag comprises three bits, and the data flag comprises one bit; and

the retransmission flag, the data flag and the count flag are arranged in sequence in the retransmission indication field, and the two bits in the retransmission flag are first two bits in the retransmission indication byte.
The method according to claim 5, wherein prior to determining (305), according to the retransmission flag in the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet, the method further comprises:
acquiring (301) a padding flag in an RTP header field in the RTP data packet; and

determining (302), according to the padding flag, whether the RTP data packet comprises the RTP padding field.
The method according to any one of claims 5 to 8, wherein prior to determining (305), according to the retransmission flag in the retransmission indication byte, whether the RTP data packet is the retransmitted RTP data packet, the method further comprises:
acquiring a predetermined bytes per unit;

partitioning the RTP data packet into a plurality of data segments according to the bytes per unit, a total bytes of each of the data segments being equal to the bytes per unit; and

parsing the plurality of data segments respectively.
A computer device, comprising a processor and a memory; wherein
the memory is configured to store a computer program; and

the processor is configured to execute the program stored on the memory to perform the method as defined in any one of claims 1 to 4 or perform the method as defined in any one of claims 5 to 9.