WO2012103722A1 - Rtp媒体数据的接收、发送方法及装置、处理*** - Google Patents

Rtp媒体数据的接收、发送方法及装置、处理*** Download PDF

Info

Publication number
WO2012103722A1
WO2012103722A1 PCT/CN2011/076562 CN2011076562W WO2012103722A1 WO 2012103722 A1 WO2012103722 A1 WO 2012103722A1 CN 2011076562 W CN2011076562 W CN 2011076562W WO 2012103722 A1 WO2012103722 A1 WO 2012103722A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
dtls
header
data packet
header data
Prior art date
Application number
PCT/CN2011/076562
Other languages
English (en)
French (fr)
Inventor
舒续祖
陈明功
陈文盛
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2011/076562 priority Critical patent/WO2012103722A1/zh
Priority to CN201180000926.5A priority patent/CN102726024B/zh
Publication of WO2012103722A1 publication Critical patent/WO2012103722A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation

Definitions

  • the embodiments of the present invention relate to a data processing technology, and in particular, to a real-time transport protocol (RTT) media data receiving and transmitting method, device, and processing system.
  • RTT real-time transport protocol
  • RTP Real-time Transport Protocol
  • IP header (20 bytes) + User Datagram Protocol (UDP) header (8 bytes) + RTP header (12 bytes) + RTP payload (20 bytes).
  • UDP User Datagram Protocol
  • RTP payload (20 bytes).
  • DTLS Datagram Transport Layer Security
  • the format of the DTLS packet after the RTP packet is transmitted by DTLS is: IP header (20 bytes) + UDP header (8 bytes) + DTLS header (12 bytes) + DTLS payload, RTP with IP header and UDP header Package (greater than 40 bytes).
  • the payload associated with the RTP media data accounts for a serious decrease in the proportion of the entire IP packet, that is, the DTLS packet, thereby causing a decrease in the utilization rate of the transmission channel.
  • Embodiments of the present invention provide a method and a device for receiving and transmitting RTP media data, and a processing system for improving utilization of a transmission channel.
  • An aspect of the present invention provides a method for receiving RTP media data, including: Receiving a first DTLS data packet sent by the sending end device, where a DTLS header of the first DTLS data packet includes a data packet format identifier and an initial change byte identifier, where the DTLS payload of the first DTLS data packet includes the first Head data and RTP media data;
  • the data packet format identifier indicates a complete format, storing first header data in the first DTLS data packet as standard header data, and parsing the standard header data and the RTP media data deal with;
  • the data packet format identifier indicates a change format
  • Another aspect of the present invention provides a method for transmitting RTP media data, including:
  • the DTLS header of the first DTLS data packet includes a data packet format identifier and an initial change byte identifier
  • the DTLS payload of the first DTLS packet includes the first header data and the RTP media data, so that the receiving end device stores, according to the data packet format identifier, the first DTLS data packet.
  • the first header data is used as standard header data, and the standard header data and the RTP media data are parsed; or
  • the DTLS payload of the first DTLS data packet includes second header data and the RTP media data, so that the receiving end device identifies according to the data packet format, and according to the initial change byte identifier, Determining, by the standard header data and the second header data in the first DTLS data packet, the first header data, and parsing the first header data and the RTP media data,
  • the second header data is header data in which the first header data changes compared to the standard header data.
  • a receiving end device for RTP media data including: a receiving unit, configured to receive a first DTLS data packet sent by the sending end device, where a DTLS header of the first DTLS data packet includes a data packet format identifier and a start change byte identifier, and the DTLS of the first DTLS data packet
  • the payload includes first header data and RTP media data
  • a processing unit if the data packet format identifier indicates a full format, storing first header data in the first DTLS data packet as standard header data, and using the standard header data and the RTP media Data is parsed; if the packet format identifier is indicated as a change format, obtained according to the initial change byte identifier, the standard header data, and the first header data in the first DTLS packet a second header data, and parsing the second header data and the RTP media data, wherein the first header data is the second header data and the standard header data Than, the head data of the change.
  • Another aspect of the present invention provides a device for sending RTP media data, including: an obtaining unit, configured to obtain first header data and RTP media data;
  • a sending unit configured to send, to the receiving device, a first DTLS data packet, where the DTLS header of the first DTLS data packet includes a data packet format identifier and an initial change byte identifier, where
  • the first header data and the DTLS payload of the first DTLS packet are included
  • RTP media data so that the receiving end device identifies, according to the data packet format identifier, the first header data in the first DTLS data packet as standard header data, and the standard header data and Parsing the RTP media data; or
  • the DTLS payload of the first DTLS data packet includes second header data and the RTP media data, so that the receiving end device identifies according to the data packet format, and according to the initial change byte identifier, Determining, by the standard header data and the second header data in the first DTLS data packet, the first header data, and parsing the first header data and the RTP media data,
  • the second header data is header data in which the first header data changes compared to the standard header data.
  • Another aspect of the present invention provides a processing system for RTP media data, including a sender device and a sink device, where The sending end device is configured to obtain first header data and RTP media data, and send a first DTLS data packet to the receiving end device, where a DTLS header of the first DTLS data packet includes a data packet format identifier and An initial change byte identifier, and the first header data and the RTP media data are included in a DTLS payload of the first DTLS packet; or the second header is included in a DTLS payload of the first DTLS packet Data and the RTP media data;
  • the receiving end device is configured to receive the first DTLS data packet sent by the sending end device, and if the data packet format identifier indicates a complete format, storing the first header in the first DTLS data packet Data is used as standard header data, and the standard header data and the RTP media data are parsed; if the packet format identifier indicates a change format, according to the initial change byte identifier, The first header data is obtained by the standard header data and the second header data in the first DTLS data packet, and the first header data and the RTP media data are parsed, where The second header data is header data in which the first header data is changed compared to the standard header data.
  • the embodiment of the present invention passes the data packet format identifier and the initial change byte identifier included in the DTLS header of the DTLS data packet, so that the receiving end device can identify and start the change byte according to the foregoing data packet format.
  • the identifier, and the stored standard header data restore the incomplete header data contained in the DTLS payload of the DTLS packet to the complete header data, so as to complete the RTP packet with the IP header (ie including RTP)
  • the media data and the complete header data are parsed to avoid the payload associated with the RTP media data in the prior art due to the large amount of system overhead in the header data in the DTLS payload. The problem of a serious decrease in the proportion, thereby increasing the utilization of the transmission channel.
  • FIG. 1 is a schematic flowchart of a method for receiving RTP media data according to an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a method for transmitting RTP media data according to another embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of a device at a receiving end of RTP media data according to another embodiment of the present invention.
  • FIG. 4 is a schematic structural diagram of a device at a receiving end of RTP media data according to another embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of a device at a transmitting end of RTP media data according to another embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of a device at a transmitting end of RTP media data according to another embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a processing system for RTP media data according to another embodiment of the present invention. detailed description
  • FIG. 1 is a schematic flowchart of a method for receiving RTP media data according to an embodiment of the present invention. As shown in FIG. 1, the method for receiving RTP media data in this embodiment may include:
  • the 101 Receive a first DTLS data packet sent by the sending end device, where the DTLS header of the first DTLS data packet includes a data packet format identifier (Flag) and an initial change byte identifier (Offset).
  • the DTLS payload of the first DTLS packet includes the first header data and the RTP media data.
  • the data packet format identifier included in the DTLS header may include a complete format or a change format, which is 2 bits in total.
  • the full format may indicate that the first header data included in the DTLS payload of the first DTLS packet is complete header data, ie complete IP header data + complete UDP header data + complete RTP header data
  • the change format may indicate that the first header data included in the DTLS payload of the first DTLS packet is incomplete header data, that is, header data that changes compared to the complete header data, that is, the changed IP. Header data + changed UDP header data + changed RTP header data. It can be seen that the changed header data in the DTLS payload indicated by the change format occupies less bytes than the complete header data in the DTLS payload indicated by the full format, and can reduce the header in the DTLS payload. The overhead of data usage.
  • the value of the initial change byte identifier can start from 0, that is, from the 0th byte of the IP header data, define the byte that starts to change, a total of 4 bits.
  • the Length field is already included in the header data contained in the DTLS payload.
  • the data packet format identifier is indicated as a complete format, storing the first header data in the first DTLS data packet as standard header data, and the foregoing standard header data and the foregoing
  • RTP media data is parsed
  • the initial change byte identifier (Offset) can be invalidated, for example: Ignore the start change byte identifier (Offset).
  • the data packet format identifier is indicated as a change format
  • the first header data in step 103 is header data in which the second header data is changed compared to the standard header data.
  • the above-mentioned data packet format identifier indicates a change format
  • first determine the corresponding start change byte according to the above-mentioned initial change byte identifier and then according to the size of the first header data,
  • the corresponding change byte length is determined, and finally, the standard header data starts from the start change byte, and the total change byte length data is replaced with the first header data, and the other data in the standard header data is unchanged.
  • the second header data is constructed.
  • the execution body of the above 101 ⁇ 103 may be a receiving end device.
  • the receiving device is Storing the first header data in the first DTLS data packet as standard header data (ie, comparing template data), and parsing the standard header data (complete header data) and the RTP media data;
  • the packet format identifier included in the DTLS header is indicated as a change format, that is, the first DTLS packet received by the receiving device is a change packet (Vr_RTP, VRTP for short), and the receiving device identifies the first change byte according to the foregoing change byte.
  • Vr_RTP change packet
  • the receiving device processes the RTP packet with the IP header and the UDP header, for example: First, the IP header is removed from the IP layer and sent to the UDP layer, and then removed at the UDP layer. The UDP header finally parses the RTP packet (the RTP header and the RTP media data) to obtain the RTP media data, which will not be described here.
  • the data packet format identifier and the initial change byte identifier included in the DTLS header of the DTLS data packet enable the receiving end device to identify and start the change byte identifier according to the foregoing data packet format, and store the Standard header data, which restores incomplete header data contained in the DTLS payload of the DTLS packet to complete header data for complete RTP packets with IP headers (ie including RTP media data and complete).
  • the parsing process of the header data can avoid the problem that the ratio of the payload related to the RTP media data to the total DTLS packet is seriously degraded due to the large amount of system overhead occupied by the header data in the DTLS payload in the prior art. , thereby improving the utilization of the transmission channel.
  • the DTLS header of the first DTLS data packet received by the receiving end device may further include a serial number (Serial_No), which is 6 bits in total;
  • the receiving end device may further determine, after the preset time threshold or according to the sequence number included in the DTLS header, the sequence number of the first DTLS data packet that is not received, and send the out-of-synchronization indication information to the sending end device. And determining, by the sending end device, the first DTLS data packet identified by the serial number identifier and the first DTLS data packet after the first DTLS data packet, thereby implementing The first DTLS packet can be accurately retransmitted after it is lost.
  • the receiving device receives the first DTLS packet with sequence number 5 before, but before receiving the preset time threshold, no first DTLS packet is received, then the receiving device determines that it has not received.
  • the sequence number of the first DTLS packet is 6. For example, if the receiving device receives the first DTLS packet with the sequence number 5 and now receives the first DTLS packet with the sequence number 7, the receiving device determines that the first DTLS data is not received.
  • the serial number of the package is 6.
  • the receiving end device may send the second DTLS data packet to the sending end device, where the data packet format identifier included in the DTLS header of the second DTLS data packet is in a feedback state format, that is, the second sent by the receiving end device.
  • the DTLS data packet is a feedback data packet (Case_Echo, referred to as CE), and the above-mentioned out-of-synchronization indication information is included in the DTLS payload of the second DTLS data packet.
  • CE feedback data packet
  • the format of the feedback packet can be defined as the following format
  • Uint8 echo_type 2; //2 bits, 0 means out of synchronization; 1 means timeout; uint8 serial_no:6; //6 bits, indicating the sequence number of the first DTLS packet that was not received.
  • the DTLS header of the first DTLS data packet received by the receiving device may further include a media stream identifier (Streamjd) of the media stream to which the RTP media data belongs.
  • the receiving end device may specifically store the first header data in the first DTLS data packet as standard header data, and store the foregoing media stream identifier; correspondingly, in 103, The receiving end device may be configured to obtain, according to the media stream identifier, the initial change byte identifier, the standard header data corresponding to the media stream identifier, and the first header data in the first DTLS data packet, to obtain a second The header data, so that when multiple media sessions are implemented, the corresponding standard header data can be accurately obtained according to the media stream identifier, and the subsequent second header data can be obtained.
  • Streamjd media stream identifier
  • FIG. 2 is a schematic flowchart of a method for sending RTP media data according to another embodiment of the present invention. As shown in FIG. 2, the method for sending RTP media data in this embodiment may include:
  • the DTLS payload of the first DTLS data packet includes the first header data and the RTP media data, so that the receiving end device stores the first header data in the first DTLS data packet according to the data packet format identifier.
  • Flag data packet format identifier
  • Offset initial change byte identifier
  • the DTLS payload of the first DTLS data packet includes the second header data and the RTP media data, so that the receiving end device identifies according to the data packet format, and according to the initial change byte identifier, the standard header data. And obtaining the first header data by using the second header data in the first DTLS packet, and performing parsing processing on the first header data and the RTP media data.
  • the second header data is header data in which the first header data is changed compared to the standard header data.
  • the receiving device may first determine a corresponding start change byte according to the foregoing start change byte identifier, and then determine a corresponding according to the size of the first header data. The length of the byte is changed. Finally, the data of the changed byte length is replaced with the first header data in the standard header data, and the other data is unchanged, thereby constituting the second header data.
  • the execution bodies of the above 201 and 202 may be sender devices.
  • the packet format identifier contained in the DTLS header may include a full format and a change format, which are 2 bits in total.
  • the former may indicate that the first header data included in the DTLS payload of the first DTLS packet is complete header data, that is, complete IP header data + complete UDP header data + complete RTP header data;
  • the latter may indicate that the second header data included in the DTLS payload of the first DTLS packet is incomplete header data, that is, header data that changes compared with the complete header data, that is, the changed IP header.
  • Part data + changed UDP header data + changed RTP header data It can be seen that the changed header data in the DTLS payload indicated by the change format occupies less bytes than the complete header data in the DTLS payload indicated by the full format, and can reduce the header in the DTLS payload.
  • the overhead of data usage may indicate that the first header data included in the DTLS payload of the first DTLS packet is complete header data, that is, complete IP header data + complete U
  • the value of the initial change byte identifier can start from 0, that is, the 0th from the IP header data.
  • the byte starts counting and defines the byte that starts to change, a total of 4 bits.
  • the Length field is already included in the header data contained in the DTLS payload.
  • the sender device may indicate that the data packet format identifier included in the DTLS header of the first DTLS packet sent to the receiving device is a complete format, that is, sent by the sending device.
  • the first DTLS data packet is a complete data packet (Int-Header, IH for short), and the receiving end device stores the first header data in the first DTLS data packet as standard header data (ie, comparison template data), and The above standard header data (complete header data) and the above RTP media data are parsed; then, the sender device can then send the DTLS of the non-first DTLS packet (subsequent DTLS packet) to the receiving device.
  • the packet format identifier included in the header indicates a change format, that is, the first DTLS packet sent by the source device is a change packet (Var_RTP, VRTP for short), and the receiver device identifies the above-mentioned standard according to the above-mentioned initial change byte.
  • the data packet format identifier and the initial change byte identifier included in the DTLS header of the DTLS data packet enable the receiving end device to identify and start the change byte identifier according to the foregoing data packet format, and store the Standard header data, which restores incomplete header data contained in the DTLS payload of the DTLS packet to complete header data for complete RTP packets with IP headers (ie including RTP media data and complete).
  • the header data is parsed, which can avoid the prior art that the header data in the DTLS payload occupies a large amount of system overhead.
  • the resulting payload associated with RTP media data accounts for a significant drop in the proportion of the entire DTLS packet, thereby increasing the utilization of the transport channel.
  • the DTLS header of the first DTLS data packet sent by the sending end device may further include a serial number (Serial_No), a total of 6
  • the sending end device may further receive the out-of-synchronization indication information that is sent by the receiving end device and includes the serial number determined by the receiving end device, and resend the first DTLS data packet of the serial number identifier to the receiving end device. And the first DTLS packet after the first DTLS packet.
  • the out-of-synchronization indication information is sent after the receiving end device determines the sequence number of the first DTLS data packet that is not received after the preset time threshold or according to the sequence number included in the DTLS header. For example: the receiving device receives the first DTLS packet with sequence number 5 before, but before receiving the preset time threshold, no first DTLS packet is received, then the receiving device determines that it has not received. The sequence number of the first DTLS packet is 6. For another example, the receiving device receives the first DTLS packet with sequence number 5 before, and now receives the first DTLS packet with sequence number 7. Then, the receiving device determines that the first DTLS data is not received. The serial number of the package is 6.
  • the sending end device may specifically receive the second DTLS data packet sent by the receiving end device, where the data packet format identifier included in the DTLS header of the second DTLS data packet is in a feedback state format, that is, the second received by the sending end device.
  • the DTLS data packet is a feedback data packet (Case_Echo, referred to as CE), and the above-mentioned out-of-synchronization indication information is included in the DTLS payload of the second DTLS data packet.
  • CE feedback data packet
  • the format of the feedback packet can be defined as the following format
  • Uint8 echo_type 2; //2 bits, 0 means out of synchronization; 1 means timeout; uint8 serial_no:6; //6 bits, indicating the order of the first DTLS packet not received Column number.
  • the DTLS header of the first DTLS packet sent by the sending device may further include a media stream identifier (Streamjd) of the media stream to which the RTP media data belongs, in this embodiment.
  • the receiving end device may specifically store the first header data in the first DTLS data packet as standard header data, and store the foregoing media stream identifier; and the receiving end device may specifically The first header data is obtained according to the media stream identifier, the initial change byte identifier, the standard header data corresponding to the media stream identifier, and the second header data in the first DTLS packet.
  • the message carrying the first DTLS data packet or the second DTLS data packet in the embodiment of the present invention is an application data (Application Data) message
  • application data Application Data
  • the specific interaction process of the application data message may refer to related information in the prior art. Content, no more details here.
  • FIG. 3 is a schematic structural diagram of a device at the receiving end of RTP media data according to another embodiment of the present invention.
  • the receiving end device of the RTP media data in this embodiment may include a receiving unit 31 and a processing unit 32.
  • the receiving unit 31 is configured to receive a first DTLS data packet sent by the sending end device, where the DTLS header of the first DTLS data packet includes a data packet format identifier and a start change byte identifier, and the DTLS of the first DTLS data packet is used.
  • the first head data and the RTP media data are included in the payload; the processing unit 32 is configured to process the received first DTLS data packet, If the data packet format identifier is indicated as a complete format, storing the first header data in the first DTLS data packet as standard header data, and parsing the standard header data and the RTP media data; The packet format identifier is indicated as a change format, and the second header data is obtained according to the initial change byte identifier, the standard header data, and the first header data in the first DTLS packet, and the second header data is obtained. The header data and the above RTP media data are parsed.
  • the first header data is header data in which the second header data changes compared to the standard header data.
  • the method in the foregoing embodiment corresponding to FIG. 1 can be implemented by the receiving end device of the RTP media data provided in this embodiment.
  • the red processing unit 32 in this embodiment may determine, according to the initial change byte identifier, a corresponding start change byte, and determine a corresponding change byte according to the size of the first header data. a length, in the standard header data, starting from the start change byte, a total of the change byte length data is replaced by the first header data, and other data in the standard header data is unchanged Forming the second header data.
  • the DTLS header of the first DTLS data packet received by the receiving unit 31 may further include a serial number (Serial_No); correspondingly, as shown in FIG. 4
  • the receiving end device of the RTP media data provided in this embodiment may further include an indicating unit 41, configured to determine, after the preset time threshold, or according to the sequence number included in the DTLS header, to determine that the first one is not received.
  • the indication unit 41 may specifically send the second DTLS data packet to the foregoing sending end device, where the data packet format identifier included in the DTLS header of the second DTLS data packet is indicated as a feedback status format, and the second DTLS data packet is DTLS.
  • the above-mentioned out-of-step indication information is included in the payload.
  • the DTLS header of the first DTLS data packet received by the receiving unit 31 may further include a media stream identifier (Streamjd) of the media stream to which the RTP media data belongs.
  • Streamjd media stream identifier
  • the processing unit 32 in this embodiment may be specifically configured to: if the data packet format identifier is indicated as a complete format, storing the first header data in the first DTLS data packet as standard header data, and storing And the media stream identifier, and parsing the standard header data and the RTP media data; if the data packet format identifier indicates a change format, according to the media stream identifier, the initial change byte identifier, and the media stream Identifying the corresponding standard header data and the first header data in the first DTLS packet to obtain second header data, and performing parsing processing on the second header data and the RTP media data.
  • the data packet format identifier and the initial change byte identifier included in the DTLS header of the DTLS data packet enable the processing unit to identify and initiate the change byte identifier according to the foregoing data packet format, and the storage standard.
  • Header data the incomplete header data contained in the DTLS payload of the DTLS packet is restored to the complete header data, so as to complete the RTP packet with the IP header (ie including the RTP media data and the complete header)
  • the data is parsed, which can avoid the problem that the payload associated with the RTP media data accounts for a serious decrease in the proportion of the entire DTLS packet due to the large amount of system overhead occupied by the header data in the DTLS payload in the prior art. Thereby improving the utilization of the transmission channel.
  • FIG. 5 is a schematic structural diagram of a device of a transmitting end of RTP media data according to another embodiment of the present invention.
  • the transmitting end device of the RTP media data in this embodiment may include an obtaining unit 51 and a sending unit 52.
  • the obtaining unit 51 is configured to obtain the first header data and the RTP media data
  • the sending unit 52 is configured to send the first DTLS data packet to the receiving end device, where the DTLS header of the first DTLS data packet includes the data packet format identifier and Starting change byte identifier, and
  • the DTLS payload of the first DTLS data packet includes the first header data and the RTP media data, so that the receiving end device stores the first header data in the first DTLS data packet according to the data packet format identifier.
  • the DTLS payload of the first DTLS data packet includes the second header data and the RTP media data, so that the receiving end device identifies according to the data packet format, and according to the initial change byte identifier, the standard header data. And obtaining the first header data by using the second header data in the first DTLS data packet, and performing parsing processing on the first header data and the RTP media data, where the second header data is the foregoing
  • the first header data has changed head data as compared with the standard header data described above.
  • the method in the foregoing embodiment corresponding to FIG. 2 can be implemented by the sending end device of the RTP media data provided in this embodiment.
  • the DTLS header of the first DTLS data packet sent by the sending unit 52 may further include a serial number (Serial_No); correspondingly, as shown in FIG.
  • the transmitting end device of the RTP media data provided in this embodiment may further include a receiving unit 61, configured to receive the out-of-synchronization indication information sent by the receiving end device, where the out-of-synchronization indication information includes the sequence determined by the receiving end device.
  • the above-mentioned out-of-synchronization indication information is sent by the receiving end device after the preset time threshold or according to the sequence number included in the DTLS header, after determining the sequence number of the first DTLS packet that is not received; and receiving the foregoing The end device resends the first DTLS packet identified by the serial number above.
  • the receiving unit 61 may specifically receive the second DTLS data packet sent by the receiving end device, where the data packet format identifier included in the DTLS header of the second DTLS data packet is in a feedback state format, where the second DTLS data packet is The above-mentioned out-of-synchronization indication information is included in the DTLS payload.
  • the DTLS header of the first DTLS data packet sent by the sending unit 52 may further include a media stream identifier (Streamjd) of the media stream to which the RTP media data belongs. So that the receiving end device identifies according to the foregoing data packet format,
  • the data packet format identifier and the initial change byte identifier included in the DTLS header of the DTLS data packet sent by the sending unit enable the receiving end device to identify and start the change byte identifier according to the foregoing data packet format identifier.
  • the stored standard header data the incomplete header data contained in the DTLS payload of the DTLS packet is restored to the complete header data, so as to complete the RTP packet with the IP header (ie including the RTP media)
  • the data and the complete header data are parsed, which can avoid the proportion of the payload associated with the RTP media data to the total DTLS packet caused by the large amount of system overhead in the header data in the DTLS payload in the prior art. A serious drop in the problem, thereby increasing the utilization of the transmission channel.
  • FIG. 7 is a schematic structural diagram of a processing system for RTP media data according to another embodiment of the present invention.
  • the processing system for RTP media data in this embodiment may include a transmitting device 71 and a receiving device 72, where ,
  • the sending end device 71 is configured to obtain first header data and RTP media data, and send a first DTLS data packet to the receiving end device 72, where the DTLS header of the first DTLS data packet includes a data packet format.
  • the receiving end device 72 is configured to receive the first DTLS data packet sent by the sending end device 71, and if the data packet format identifier indicates a complete format, store the first one in the first DTLS data packet.
  • the header data is used as the standard header data, and the standard header data and the RTP media data are parsed; if the packet format identifier indicates a change format, according to the initial change byte identifier, The standard header data and the first of the first DTLS packets Obtaining the first header data, and performing parsing processing on the first header data and the RTP media data, where the second header data is the first header data The changed header data is compared to the standard header data.
  • the method in the embodiment corresponding to the foregoing FIG. 1 can be implemented by the receiving end device 72 in the processing system of the RTP media data provided in this embodiment.
  • the method in the corresponding embodiment of FIG. 2 can be used in the processing system of the RTP media data provided in this embodiment.
  • the transmitting device 71 is implemented.
  • the DTLS header of the first DTLS data packet sent by the sending end device 71 to the receiving end device 72 may further include a sequence number; correspondingly, the receiving end device 72 may further be used for a preset time threshold. And determining, according to the sequence number included in the DTLS header, a sequence number of the first DTLS packet that is not received, and sending out-of-synchronization indication information to the sending end device 71, where the out-of-synchronization indication information includes determining
  • the sequence device is further configured to receive the out-of-synchronization indication information sent by the receiving end device 72, and resend the first DTLS data of the serial number identifier to the receiving end device 72. package.
  • the receiving end device 72 may send a second DTLS data packet to the sending end device 71, where the data packet format identifier included in the DTLS header of the second DTLS data packet is a feedback status format, The out-of-synchronization indication information is included in the DTLS payload of the second DTLS data packet.
  • the sending end device 71 may specifically receive the second DTLS data packet sent by the receiving end device 72.
  • the DTLS header of the first DTLS packet sent by the sending device 71 to the receiving device 72 may further include a media stream identifier of the media stream to which the RTP media data belongs; correspondingly, the receiving device 72 is specifically And if the data packet format identifier is indicated as a complete format, storing first header data in the first DTLS data packet as standard header data, and storing the media stream identifier, and storing the standard
  • the header data and the RTP media data are parsed; if the data packet format identifier indicates a change format, and according to the media stream identifier, the initial change byte identifier, and the media stream identifier
  • the standard header data, and the second header data in the first DTLS data packet obtain the first header data, and The first header data and the RTP media data are parsed.
  • the data packet format identifier and the initial change byte identifier included in the DTLS header of the DTLS data packet sent by the sending end device enable the receiving end device to identify and start the change byte according to the foregoing data packet format.
  • the identifier, and the stored standard header data restore the incomplete header data contained in the DTLS payload of the DTLS packet to the complete header data, so as to complete the RTP packet with the IP header (ie including RTP)
  • the media data and the complete header data are parsed to avoid the payload associated with the RTP media data in the prior art due to the large amount of overhead of the header data in the DTLS payload. The problem of a serious decrease in the proportion, thereby increasing the utilization of the transmission channel.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not executed.
  • the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be electrical, mechanical or otherwise.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solution of the embodiment.
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or a software function list. The realization of the form of the yuan.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium.
  • the technical solution of the present invention may contribute to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium.
  • a number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and the like, and the program code can be stored. Medium.

Landscapes

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

Description

RTP媒体数据的接收、 发送方法及装置、 处理*** 技术领域
本发明实施例涉及数据处理技术， 尤其涉及一种实时传输协议 ( Real-time Transport Protocol, 简称 RTP )媒体数据的接收、 发送方法及 装置、 处理***。 背景技术
随着通信技术的不断发展， 出现了许多基于实时传输协议（Real-time Transport Protocol, 简称 RTP ) 的应用程序， 例如： 声音点播、 影视点播、 视频会议、 因特网电话、 在线游戏等， 用来传输媒体数据。 一般来说， RTP 数据包封装之后的格式为： IP头（ 20字节）+用户数据报协议（ User Datagram Protocol, 简称 UDP ) 头 （ 8字节） +RTP头 （ 12字节） +RTP载荷（ 20字 节）。 由于 RTP是 UDP之上的应用， 所以可以采用数据报传输层安全协议 ( Datagram Transport Layer Security, 简称 DTLS )进行 RTP数据包的传 输。 RTP数据包采用 DTLS传输之后的 DTLS数据包的格式为： IP头 （20 字节） +UDP头 （ 8字节） +DTLS头 （ 12字节） +DTLS载荷即带 IP头和 UDP头的 RTP包（大于 40字节）。
然而，由于 DTLS载荷中的头部数据占用了大量的***开销，使得与 RTP 媒体数据相关的有效载荷占整个 IP数据包即 DTLS数据包的比例严重下降， 从而导致了传输信道的利用率的降低。 发明内容
本发明实施例提供一种 RTP媒体数据的接收、发送方法及装置、 处理系 统， 用以提高传输信道的利用率。
本发明一方面提供了一种 RTP媒体数据的接收方法， 包括： 接收发送端设备发送的第一 DTLS数据包， 所述第一 DTLS数据包的 DTLS头中包含数据包格式标识和起始变化字节标识， 所述第一 DTLS数据 包的 DTLS载荷中包含第一头部数据和 RTP媒体数据；
若所述数据包格式标识指示为完整格式， 存储所述第一 DTLS数据包中 的第一头部数据以作为标准头部数据，并对所述标准头部数据和所述 RTP媒 体数据进行解析处理；
若所述数据包格式标识指示为变化格式， 根据所述起始变化字节标识、 所述标准头部数据和所述第一 DTLS数据包中的第一头部数据， 获得第二头 部数据， 并对所述第二头部数据和所述 RTP媒体数据进行解析处理， 其中， 所述第一头部数据为所述第二头部数据与所述标准头部数据相比， 发生变化 的头部数据。
本发明另一方面提供了一种 RTP媒体数据的发送方法， 包括：
获得第一头部数据和 RTP媒体数据；
向接收端设备发送第一 DTLS数据包， 所述第一 DTLS数据包的 DTLS 头中包含数据包格式标识和起始变化字节标识，
所述第一 DTLS数据包的 DTLS 载荷中包含所述第一头部数据和所述 RTP媒体数据， 以使所述接收端设备根据所述数据包格式标识， 存储所述第 一 DTLS数据包中的第一头部数据以作为标准头部数据， 并对所述标准头部 数据和所述 RTP媒体数据进行解析处理； 或者
所述第一 DTLS数据包的 DTLS载荷中包含第二头部数据和所述 RTP媒体 数据， 以使所述接收端设备根据所述数据包格式标识， 并根据所述起始变化 字节标识、 所述标准头部数据和所述第一 DTLS数据包中的第二头部数据， 获 得所述第一头部数据， 并对所述第一头部数据和所述 RTP媒体数据进行解析 处理， 其中， 所述第二头部数据为所述第一头部数据与所述标准头部数据相 比， 发生变化的头部数据。
本发明另一方面提供了一种 RTP媒体数据的接收端设备， 包括： 接收单元， 用于接收发送端设备发送的第一 DTLS 数据包， 所述第一 DTLS数据包的 DTLS头中包含数据包格式标识和起始变化字节标识， 所述 第一 DTLS数据包的 DTLS载荷中包含第一头部数据和 RTP媒体数据；
处理单元， 若所述数据包格式标识指示为完整格式，存储所述第一 DTLS 数据包中的第一头部数据以作为标准头部数据， 并对所述标准头部数据和所 述 RTP媒体数据进行解析处理； 若所述数据包格式标识指示为变化格式， 根 据所述起始变化字节标识、所述标准头部数据和所述第一 DTLS数据包中的第 一头部数据， 获得第二头部数据， 并对所述第二头部数据和所述 RTP媒体数 据进行解析处理， 其中， 所述第一头部数据为所述第二头部数据与所述标准 头部数据相比， 发生变化的头部数据。
本发明另一方面提供了一种 RTP媒体数据的发送端设备， 包括： 获得单元， 用于获得第一头部数据和 RTP媒体数据；
发送单元， 用于向接收端设备发送第一 DTLS数据包， 所述第一 DTLS 数据包的 DTLS头中包含数据包格式标识和起始变化字节标识，
所述第一 DTLS数据包的 DTLS 载荷中包含所述第一头部数据和所述
RTP媒体数据， 以使所述接收端设备根据所述数据包格式标识， 存储所述第 一 DTLS数据包中的第一头部数据以作为标准头部数据， 并对所述标准头部 数据和所述 RTP媒体数据进行解析处理； 或者
所述第一 DTLS数据包的 DTLS载荷中包含第二头部数据和所述 RTP媒 体数据， 以使所述接收端设备根据所述数据包格式标识， 并根据所述起始变 化字节标识、所述标准头部数据和所述第一 DTLS数据包中的第二头部数据， 获得所述第一头部数据，并对所述第一头部数据和所述 RTP媒体数据进行解 析处理， 其中， 所述第二头部数据为所述第一头部数据与所述标准头部数据 相比， 发生变化的头部数据。
本发明另一方面提供了一种 RTP媒体数据的处理***， 包括发送端设备 和接收端设备， 其中， 所述发送端设备， 用于获得第一头部数据和 RTP媒体数据， 并向所述接 收端设备发送第一 DTLS数据包， 所述第一 DTLS数据包的 DTLS头中包含 数据包格式标识和起始变化字节标识， 以及所述第一 DTLS数据包的 DTLS 载荷中包含所述第一头部数据和所述 RTP媒体数据；或者所述第一 DTLS数 据包的 DTLS载荷中包含第二头部数据和所述 RTP媒体数据；
所述接收端设备， 用于接收所述发送端设备发送的所述第一 DTLS数据 包， 若所述数据包格式标识指示为完整格式， 存储所述第一 DTLS数据包中 的第一头部数据以作为标准头部数据，并对所述标准头部数据和所述 RTP媒 体数据进行解析处理； 若所述数据包格式标识指示为变化格式， 根据所述起 始变化字节标识、 所述标准头部数据和所述第一 DTLS数据包中的第二头部 数据， 获得所述第一头部数据， 并对所述第一头部数据和所述 RTP媒体数据 进行解析处理， 其中， 所述第二头部数据为所述第一头部数据与所述标准头 部数据相比， 发生变化的头部数据。
由上述技术方案可知， 本发明实施例通过 DTLS数据包的 DTLS头中所 包含的数据包格式标识和起始变化字节标识， 使得接收端设备能够根据上述 数据包格式标识和起始变化字节标识， 以及存储的标准头部数据， 将 DTLS 数据包的 DTLS载荷中所包含的不完整的头部数据还原成完整的头部数据， 以便对完整的带 IP头的 RTP数据包（即包括 RTP媒体数据和完整的头部数 据 )进行解析处理， 能够避免现有技术中由于 DTLS载荷中的头部数据占用 了大量的***开销而导致的与 RTP媒体数据相关的有效载荷占整个 DTLS数 据包的比例严重下降的问题， 从而提高了传输信道的利用率。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实 施例或现有技术描述中所需要使用的附图作一简单地介绍， 显而易见地， 下 面描述中的附图是本发明的一些实施例， 对于本领域普通技术人员来讲， 在 不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明一实施例提供的 RTP媒体数据的接收方法的流程示意图； 图 2为本发明另一实施例提供的 RTP媒体数据的发送方法的流程示意 图；
图 3为本发明另一实施例提供的 RTP媒体数据的接收端设备的结构示意 图；
图 4为本发明另一实施例提供的 RTP媒体数据的接收端设备的结构示意 图；
图 5为本发明另一实施例提供的 RTP媒体数据的发送端设备的结构示意 图；
图 6为本发明另一实施例提供的 RTP媒体数据的发送端设备的结构示意 图；
图 7为本发明另一实施例提供的 RTP媒体数据的处理***的结构示意 图。 具体实施方式
为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本发 明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地描述， 显然， 所描述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于 本发明中的实施例， 本领域普通技术人员在没有作出创造性劳动前提下所获 得的所有其他实施例， 都属于本发明保护的范围。
图 1为本发明一实施例提供的 RTP媒体数据的接收方法的流程示意图， 如图 1所示， 本实施例的 RTP媒体数据的接收方法可以包括：
101、 接收发送端设备发送的第一 DTLS数据包， 上述第一 DTLS数据 包的 DTLS头中包含数据包格式标识（ Flag )和起始变化字节标识（ Offset ), 上述第一 DTLS数据包的 DTLS载荷中包含第一头部数据和 RTP媒体数据； 其中， DTLS 头中所包含的数据包格式标识可以包括完整格式或变化格 式， 共 2比特。 完整格式可以表明该第一 DTLS数据包的 DTLS载荷中所包 含的第一头部数据是完整的头部数据，即完整的 IP头部数据 +完整的 UDP头 部数据 +完整的 RTP 头部数据； 变化格式可以表明该第一 DTLS数据包的 DTLS 载荷中所包含的第一头部数据是不完整的头部数据即与完整的头部数 据相比发生变化的头部数据， 即变化的 IP头部数据 +变化的 UDP头部数据 + 变化的 RTP头部数据。 可以看出， 与完整格式所表明的 DTLS载荷中完整的 头部数据相比， 变化格式所表明的 DTLS载荷中变化的头部数据所占用的字 节较少， 能够降低 DTLS载荷中的头部数据占用的***开销。
其中，起始变化字节标识的值可以从 0开始， 即从 IP头部数据的第 0个 字节开始算起， 定义开始发生变化的字节， 共 4比特。 为在 DTLS载荷中包含的头部数据中已经包含长度（ Length )域。
102、 若上述数据包格式标识指示为完整格式， 存储上述第一 DTLS数 据包中的第一头部数据以作为标准头部数据， 并对上述标准头部数据和上述
RTP媒体数据进行解析处理；
此时， 可以对起始变化字节标识（Offset )进行无效处理， 例如： 忽略该 起始变化字节标识（ Offset )。
103、若上述数据包格式标识指示为变化格式，根据上述起始变化字节标 识、 上述标准头部数据和上述第一 DTLS数据包中的第一头部数据， 获得第 二头部数据， 并对上述第二头部数据和上述 RTP媒体数据进行解析处理。
其中，步骤 103中的第一头部数据为第二头部数据与标准头部数据相比， 发生变化的头部数据。
例如： 如果上述数据包格式标识指示为变化格式， 先根据上述起始变化 字节标识， 确定对应的起始变化字节， 然后再根据第一头部数据的大小， 确 定对应的变化字节长度， 最后将标准头部数据中从起始变化字节开始， 总共 变化字节长度的数据替换为第一头部数据，标准头部数据中的其他数据不变， 从而构成第二头部数据。
上述 101~103的执行主体可以为接收端设备。
一般来说， IP头、 UDP头和 RTP头中有一半的字节在整个连接期间保 持不变， 40个字节中有 28个字节是保持不变的， 12个字节是容易发生变化 的。 也就是说， 即使这 12个字节均发生变化， 那么， 一个 DTLS数据包的载 荷中只需要 32个字节传输变化的头部数据即第一头部数据（ 12字节）和 RTP 媒体数据 ( 20字节）， 至少可以节省 28个字节（现有的 DTLS数据包的载荷 中有 60 个字节的数据）， 节省了将近一半的带宽。 最好情况下， 即使这 12 个字节大致相同， 那么， 可以节省将近 40个字节（现有的 DTLS数据包的载 荷中有 60个字节的数据）， 节省了将近三分之二的带宽。
本实施例中，如果 DTLS头中所包含的数据包格式标识指示为完整格式， 即接收端设备接收到的第一 DTLS数据包为完整数据包（Int-Header, 简称 IH ),接收端设备则存储第一 DTLS数据包中的第一头部数据以作为标准头部 数据 (即对比模板数据）， 并对上述标准头部数据 (完整的头部数据 )和上述 RTP媒体数据进行解析处理； 若 DTLS头中所包含的数据包格式标识指示为 变化格式， 即接收端设备接收到的第一 DTLS 数据包为变化数据包 ( Var_RTP, 简称 VRTP ), 接收端设备则根据上述起始变化字节标识、 上述 标准头部数据和上述第一 DTLS数据包中的第一头部数据 (不完整的头部数 据）， 获得第二头部数据（完整的头部数据）， 并对上述第二头部数据和上述 RTP媒体数据进行解析处理。
可以理解的是： 本实施例中， 接收端设备对第一 DTLS数据包的 DTLS 载荷中的 RTP媒体数据和恢复的完整的头部数据进行解析处理的详细描述， 可以参见现有技术中接收端设备对带 IP头和 UDP头的 RTP包所进行处理的 相关内容， 例如： 首先在 IP层去掉 IP头送往 UDP层， 然后在 UDP层去掉 UDP头，最后解析 RTP包（ RTP头和 RTP媒体数据），获得 RTP媒体数据， 此处不再赘述。
本实施例中， 通过 DTLS数据包的 DTLS头中所包含的数据包格式标识 和起始变化字节标识， 使得接收端设备能够根据上述数据包格式标识和起始 变化字节标识， 以及存储的标准头部数据， 将 DTLS数据包的 DTLS载荷中 所包含的不完整的头部数据还原成完整的头部数据， 以便对完整的带 IP头的 RTP数据包（即包括 RTP媒体数据和完整的头部数据）进行解析处理， 能 够避免现有技术中由于 DTLS载荷中的头部数据占用了大量的***开销而导 致的与 RTP媒体数据相关的有效载荷占整个 DTLS数据包的比例严重下降的 问题， 从而提高了传输信道的利用率。
进一步地， 为了保证第一 DTLS数据包的连续性， 本实施例中， 接收端 设备接收到的第一 DTLS 数据包的 DTLS 头中还可以进一步包含序列号 ( Serial_No ), 共 6比特； 相应地， 接收端设备还可以进一步在预先设置的 时间阈值之后或者根据上述 DTLS头中包含的序列号， 确定没有接收到的第 一 DTLS数据包的序列号， 并向上述发送端设备发送失步指示信息， 该失步 指示信息中包含确定的序列号， 以使上述发送端设备重新发送上述序列号标 识的第一 DTLS数据包，以及该第一 DTLS数据包之后的第一 DTLS数据包， 从而实现了第一 DTLS数据包丟失之后能够准确的重传。 例如： 接收端设备 之前接收到序列号为 5的第一 DTLS数据包， 但是在预先设置的时间阈值到 来之前， 没有再接收到任何第一 DTLS数据包， 那么接收端设备则确定没有 接收到的第一 DTLS数据包的序列号为 6。 再例如： 接收端设备之前接收到 序列号为 5的第一 DTLS数据包， 而现在又接收到序列号为 7的第一 DTLS 数据包， 那么接收端设备则确定没有接收到的第一 DTLS数据包的序列号为 6。
如果接收端设备期望接收到第一 DTLS数据包的序列号为 n, 实际收到 的序列号为 m, 则认为的丟失的包个数1_=(^1+32- ％32； 如果 L>4, 则因为 时效的关系， 没有必要向发送端设备发送失步指示信息。
具体地，接收端设备具体可以向上述发送端设备发送第二 DTLS数据包， 上述第二 DTLS数据包的 DTLS头中包含的数据包格式标识指示为反馈状态 格式， 即接收端设备发送的第二 DTLS数据包为反馈数据包（Case_Echo, 简称 CE ), 上述第二 DTLS数据包的 DTLS载荷中包含上述失步指示信息。 例如： 反馈数据包的格式可以定义为如下格式
struct{
uint8 echo_type:2; //2比特， 0表示失步； 1表示超时； uint8 serial_no:6; //6比特，表示没有接收到的第一 DTLS数据包的序 列号。
}Cache_Echo;
进一步地， 为了能够同时进行多个媒体会话， 本实施例中， 接收端设备 接收到的第一 DTLS数据包的 DTLS头中还可以进一步包含上述 RTP媒体数 据所属媒体流的媒体流标识（ Streamjd ), 共 4比特； 相应地， 102中， 接 收端设备具体可以存储上述第一 DTLS数据包中的第一头部数据以作为标准 头部数据， 以及存储上述媒体流标识； 相应地， 103 中， 接收端设备具体可 以根据上述媒体流标识、 上述起始变化字节标识、 与上述媒体流标识对应的 上述标准头部数据、 以及上述第一 DTLS数据包中的第一头部数据， 获得第 二头部数据， 从而实现了多个媒体会话时， 能够准确根据媒体流标识获得对 应的标准头部数据， 用以进行后续的第二头部数据的获得。
图 2为本发明另一实施例提供的 RTP媒体数据的发送方法的流程示意 图， 如图 2所示， 本实施例的 RTP媒体数据的发送方法可以包括：
201、 获得第一头部数据和 RTP媒体数据；
202、 向接收端设备发送第一 DTLS数据包， 上述第一 DTLS数据包的 DTLS头中包含数据包格式标识（ Flag )和起始变化字节标识（ Offset ), 上述第一 DTLS数据包的 DTLS 载荷中包含上述第一头部数据和上述 RTP媒体数据， 以使上述接收端设备根据上述数据包格式标识， 存储上述第 一 DTLS数据包中的第一头部数据以作为标准头部数据， 并对上述标准头部 数据和上述 RTP媒体数据进行解析处理； 或者
上述第一 DTLS数据包的 DTLS载荷中包含第二头部数据和上述 RTP媒 体数据， 以使上述接收端设备根据上述数据包格式标识， 并根据上述起始变 化字节标识、上述标准头部数据和上述第一 DTLS数据包中的第二头部数据， 获得上述第一头部数据，并对上述第一头部数据和上述 RTP媒体数据进行解 析处理。 其中， 第二头部数据为第一头部数据与标准头部数据相比， 发生变 化的头部数据。
例如： 如果上述数据包格式标识指示为变化格式， 接收端设备可以先根 据上述起始变化字节标识， 确定对应的起始变化字节， 然后再根据第一头部 数据的大小， 确定对应的变化字节长度， 最后将标准头部数据中从起始变化 字节开始， 变化字节长度的数据替换为第一头部数据， 其他数据不变， 从而 构成第二头部数据。
上述 201和 202的执行主体可以为发送端设备。
其中， DTLS 头中所包含的数据包格式标识可以包括完整格式和变化格 式， 共 2比特。 前者可以表明该第一 DTLS数据包的 DTLS载荷中所包含的 第一头部数据是完整的头部数据，即完整的 IP头部数据 +完整的 UDP头部数 据 +完整的 RTP头部数据； 后者可以表明该第一 DTLS数据包的 DTLS载荷 中所包含的第二头部数据是不完整的头部数据即与完整的头部数据相比发生 变化的头部数据， 即变化的 IP头部数据 +变化的 UDP头部数据 +变化的 RTP 头部数据。 可以看出， 与完整格式所表明的 DTLS载荷中完整的头部数据相 比， 变化格式所表明的 DTLS载荷中变化的头部数据所占用的字节较少， 能 够降低 DTLS载荷中的头部数据占用的***开销。
其中，起始变化字节标识的值可以从 0开始， 即从 IP头部数据的第 0个 字节开始算起， 定义开始发生变化的字节， 共 4比特。 为在 DTLS载荷中包含的头部数据中已经包含长度（ Length )域。
本实施例中， 在发起一个媒体会话之后， 发送端设备可以在向接收端设 备发送的第一个 DTLS数据包的 DTLS头中包含的数据包格式标识指示为完 整格式， 即发送端设备发送的第一 DTLS数据包为完整数据包（ Int-Header, 简称 IH ), 接收端设备则存储第一 DTLS数据包中的第一头部数据以作为标 准头部数据（即对比模板数据）， 并对上述标准头部数据（完整的头部数据） 和上述 RTP媒体数据进行解析处理； 然后， 发送端设备则可以在向接收端设 备发送的非第一个 DTLS数据包（后续 DTLS数据包） 的 DTLS头中包含的 数据包格式标识指示为变化格式， 即发送端设备发送的第一 DTLS数据包为 变化数据包（Var_RTP, 简称 VRTP ), 接收端设备则根据上述起始变化字节 标识、 上述标准头部数据和上述第一 DTLS数据包中的第二头部数据（不完 整的头部数据）， 获得第一头部数据（完整的头部数据）， 并对上述第一头部 数据和上述 RTP媒体数据进行解析处理。
可以理解的是： 本实施例中， 接收端设备对完整的头部数据和 RTP媒体 数据进行解析处理的详细描述，可以参见现有技术中接收端设备对带 IP头和 UDP头的 RTP包所进行处理的相关内容， 例如： 首先在 IP层去掉 IP头送 往 UDP层， 然后在 UDP层去掉 UDP头， 最后解析 RTP包 ( RTP头和 RTP 媒体数据）， 获得 RTP媒体数据， 此处不再赘述。
本实施例中， 通过 DTLS数据包的 DTLS头中所包含的数据包格式标识 和起始变化字节标识， 使得接收端设备能够根据上述数据包格式标识和起始 变化字节标识， 以及存储的标准头部数据， 将 DTLS数据包的 DTLS载荷中 所包含的不完整的头部数据还原成完整的头部数据， 以便对完整的带 IP头的 RTP数据包（即包括 RTP媒体数据和完整的头部数据）进行解析处理， 能 够避免现有技术中由于 DTLS载荷中的头部数据占用了大量的***开销而导 致的与 RTP媒体数据相关的有效载荷占整个 DTLS数据包的比例严重下降的 问题， 从而提高了传输信道的利用率。
进一步地， 为了保证第一 DTLS数据包的连续性， 本实施例中， 本实施 例中， 发送端设备发送的第一 DTLS数据包的 DTLS头中还可以进一步包含 序列号 （Serial_No ), 共 6比特； 相应地， 发送端设备还可以进一步接收接 收端设备发送的包含该接收端设备确定的序列号的失步指示信息， 并向上述 接收端设备重新发送上述序列号标识的第一 DTLS数据包，以及该第一 DTLS 数据包之后的第一 DTLS数据包。 该失步指示信息为接收端设备在预先设置 的时间阈值之后或者根据上述 DTLS头中包含的序列号， 确定没有接收到的 第一 DTLS数据包的序列号之后发送的。 例如： 接收端设备之前接收到序列 号为 5的第一 DTLS数据包， 但是在预先设置的时间阈值到来之前， 没有再 接收到任何第一 DTLS数据包， 那么接收端设备则确定没有接收到的第一 DTLS数据包的序列号为 6。再例如：接收端设备之前接收到序列号为 5的第 一 DTLS数据包， 而现在又接收到序列号为 7的第一 DTLS数据包， 那么接 收端设备则确定没有接收到的第一 DTLS数据包的序列号为 6。
如果接收端设备期望接收到第一 DTLS数据包的序列号为 n, 实际收到 的序列号为 m, 则认为的丟失的包个数1_=(^1+32- ％32； 如果 L>4, 则因为 时效的关系， 没有必要向发送端设备发送失步指示信息。
具体地，发送端设备具体可以接收接收端设备发送的第二 DTLS数据包， 上述第二 DTLS数据包的 DTLS头中包含的数据包格式标识指示为反馈状态 格式， 即发送端设备接收的第二 DTLS数据包为反馈数据包（Case_Echo, 简称 CE ), 上述第二 DTLS数据包的 DTLS载荷中包含上述失步指示信息。 例如： 反馈数据包的格式可以定义为如下格式
struct{
uint8 echo_type:2; //2比特， 0表示失步； 1表示超时； uint8 serial_no:6; //6比特，表示没有接收到的第一 DTLS数据包的序 列号。
}Cache_Echo;
进一步地， 为了能够同时进行多个媒体会话， 本实施例中， 发送端设备 发送的第一 DTLS数据包的 DTLS头中还可以进一步包含上述 RTP媒体数据 所属媒体流的媒体流标识（ Streamjd ), 共 4比特； 相应地， 202中， 接收 端设备具体可以存储上述第一 DTLS数据包中的第一头部数据以作为标准头 部数据， 以及存储上述媒体流标识； 以及接收端设备具体还可以根据上述媒 体流标识、 上述起始变化字节标识、 与上述媒体流标识对应的上述标准头部 数据、 以及上述第一 DTLS数据包中的第二头部数据， 获得上述第一头部数 据。
可以理解的是： 本发明实施例中承载第一 DTLS数据包或第二 DTLS数 据包的消息为应用数据（Application Data ) 消息， 关于该应用数据消息的具 体交互流程可以参见现有技术中的相关内容， 此处不再赘述。
需要说明的是： 对于前述的各方法实施例， 为了简单描述， 故将其都表 述为一系列的动作组合， 但是本领域技术人员应该知悉， 本发明并不受所描 述的动作顺序的限制， 因为依据本发明， 某些步骤可以采用其他顺序或者同 时进行。 其次， 本领域技术人员也应该知悉， 说明书中所描述的实施例均属 于优选实施例， 所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中， 对各个实施例的描述都各有侧重， 某个实施例中没有 详述的部分， 可以参见其他实施例的相关描述。
图 3为本发明另一实施例提供的 RTP媒体数据的接收端设备的结构示意 图， 如图 3所示， 本实施例的 RTP媒体数据的接收端设备可以包括接收单元 31和处理单元 32。其中，接收单元 31用于接收发送端设备发送的第一 DTLS 数据包， 上述第一 DTLS数据包的 DTLS头中包含数据包格式标识和起始变 化字节标识， 上述第一 DTLS数据包的 DTLS 载荷中包含第一头部数据和 RTP媒体数据； 处理单元 32用于对接收到的第一 DTLS数据包进行处理， 若上述数据包格式标识指示为完整格式， 存储上述第一 DTLS数据包中的第 一头部数据以作为标准头部数据，并对上述标准头部数据和上述 RTP媒体数 据进行解析处理； 若上述数据包格式标识指示为变化格式， 根据上述起始变 化字节标识、上述标准头部数据和上述第一 DTLS数据包中的第一头部数据， 获得第二头部数据，并对上述第二头部数据和上述 RTP媒体数据进行解析处 理。
其中，上述第一头部数据为上述第二头部数据与上述标准头部数据相比， 发生变化的头部数据。
上述图 1对应的实施例中方法可以由本实施例提供的 RTP媒体数据的接 收端设备实现。
具体地，本实施例中红的处理单元 32具体可以根据所述起始变化字节标 识， 确定对应的起始变化字节， 根据所述第一头部数据的大小， 确定对应的 变化字节长度， 将所述标准头部数据中从所述起始变化字节开始， 总共所述 变化字节长度的数据替换为所述第一头部数据， 所述标准头部数据中其他数 据不变， 构成所述第二头部数据。
进一步地， 为了保证第一 DTLS数据包的连续性， 本实施例中， 接收单 元 31 接收到的第一 DTLS数据包的 DTLS 头中还可以进一步包含序列号 ( Serial_No ); 相应地， 如图 4所示， 本实施例提供的 RTP媒体数据的接收 端设备还可以进一步包括指示单元 41 , 用于在预先设置的时间阈值之后或者 根据上述 DTLS头中包含的序列号， 确定没有接收到的第一 DTLS数据包的 序列号， 并向上述发送端设备发送失步指示信息， 上述失步指示信息中包含 确定的序列号， 以使上述发送端设备重新发送上述序列号标识的第一 DTLS 数据包。
具体地，指示单元 41具体可以向上述发送端设备发送第二 DTLS数据包， 上述第二 DTLS数据包的 DTLS头中包含的数据包格式标识指示为反馈状态 格式， 上述第二 DTLS数据包的 DTLS载荷中包含上述失步指示信息。 进一步地， 为了能够同时进行多个媒体会话， 本实施例中， 接收单元 31 接收到的第一 DTLS数据包的 DTLS头中还可以进一步包含上述 RTP媒体数 据所属媒体流的媒体流标识（ Streamjd ); 相应地， 本实施例中的处理单元 32 具体可以用于若上述数据包格式标识指示为完整格式， 存储上述第一 DTLS数据包中的第一头部数据以作为标准头部数据， 以及存储上述媒体流 标识， 并对上述标准头部数据和上述 RTP媒体数据进行解析处理； 若上述数 据包格式标识指示为变化格式， 根据上述媒体流标识、 上述起始变化字节标 识、 与上述媒体流标识对应的上述标准头部数据、 以及上述第一 DTLS数据 包中的第一头部数据 ,获得第二头部数据 ,并对上述第二头部数据和上述 RTP 媒体数据进行解析处理。
本实施例中， 通过 DTLS数据包的 DTLS头中所包含的数据包格式标识 和起始变化字节标识， 使得处理单元能够根据上述数据包格式标识和起始变 化字节标识， 以及存储的标准头部数据， 将 DTLS数据包的 DTLS载荷中所 包含的不完整的头部数据还原成完整的头部数据， 以便对完整的带 IP 头的 RTP数据包（即包括 RTP媒体数据和完整的头部数据）进行解析处理， 能 够避免现有技术中由于 DTLS载荷中的头部数据占用了大量的***开销而导 致的与 RTP媒体数据相关的有效载荷占整个 DTLS数据包的比例严重下降的 问题， 从而提高了传输信道的利用率。
图 5为本发明另一实施例提供的 RTP媒体数据的发送端设备的结构示意 图， 如图 5所示， 本实施例的 RTP媒体数据的发送端设备可以包括获得单元 51和发送单元 52。 其中， 获得单元 51用于获得第一头部数据和 RTP媒体 数据；发送单元 52用于向接收端设备发送第一 DTLS数据包，上述第一 DTLS 数据包的 DTLS头中包含数据包格式标识和起始变化字节标识， 以及
上述第一 DTLS数据包的 DTLS 载荷中包含上述第一头部数据和上述 RTP媒体数据， 以使上述接收端设备根据上述数据包格式标识， 存储上述第 一 DTLS数据包中的第一头部数据以作为标准头部数据， 并对上述标准头部 数据和上述 RTP媒体数据进行解析处理； 或者
上述第一 DTLS数据包的 DTLS载荷中包含第二头部数据和上述 RTP媒 体数据， 以使上述接收端设备根据上述数据包格式标识， 并根据上述起始变 化字节标识、上述标准头部数据和上述第一 DTLS数据包中的第二头部数据， 获得上述第一头部数据，并对上述第一头部数据和上述 RTP媒体数据进行解 析处理， 其中， 上述第二头部数据为上述第一头部数据与上述标准头部数据 相比， 发生变化的头部数据。
上述图 2对应的实施例中方法可以由本实施例提供的 RTP媒体数据的发 送端设备实现。
进一步地， 为了保证第一 DTLS数据包的连续性， 本实施例中， 发送单 元 52 发送的第一 DTLS 数据包的 DTLS 头中还可以进一步包含序列号 ( Serial_No ); 相应地， 如图 6所示， 本实施例提供的 RTP媒体数据的发送 端设备还可以进一步包括接收单元 61 , 用于接收上述接收端设备发送的失步 指示信息， 上述失步指示信息中包含上述接收端设备确定的序列号， 上述失 步指示信息为上述接收端设备在预先设置的时间阈值之后或者根据上述 DTLS头中包含的序列号， 确定没有接收到的第一 DTLS数据包的序列号之 后发送；并向上述接收端设备重新发送上述序列号标识的第一 DTLS数据包。
具体地，接收单元 61具体可以接收上述接收端设备发送的第二 DTLS数 据包， 上述第二 DTLS数据包的 DTLS头中包含的数据包格式标识指示为反 馈状态格式，上述第二 DTLS数据包的 DTLS载荷中包含上述失步指示信息。
进一步地， 为了能够同时进行多个媒体会话， 本实施例中， 发送单元 52 发送的第一 DTLS数据包的 DTLS头中还可以进一步包含上述 RTP媒体数据 所属媒体流的媒体流标识（Streamjd ), 以使上述接收端设备根据上述数据 包格式标识，
存储上述第一 DTLS数据包中的第一头部数据以作为标准头部数据， 以 及存储上述媒体流标识，并对上述标准头部数据和上述 RTP媒体数据进行解 析处理； 或者
并根据上述媒体流标识、 上述起始变化字节标识、 与上述媒体流标识对 应的上述标准头部数据， 以及上述第一 DTLS数据包中的第二头部数据， 获 得上述第一头部数据，并对上述第一头部数据和上述 RTP媒体数据进行解析 处理。
本实施例中， 通过发送单元发送的 DTLS数据包的 DTLS头中所包含的 数据包格式标识和起始变化字节标识， 使得接收端设备能够根据上述数据包 格式标识和起始变化字节标识， 以及存储的标准头部数据， 将 DTLS数据包 的 DTLS载荷中所包含的不完整的头部数据还原成完整的头部数据， 以便对 完整的带 IP头的 RTP数据包（即包括 RTP媒体数据和完整的头部数据 )进 行解析处理， 能够避免现有技术中由于 DTLS载荷中的头部数据占用了大量 的***开销而导致的与 RTP媒体数据相关的有效载荷占整个 DTLS数据包的 比例严重下降的问题， 从而提高了传输信道的利用率。
图 7为本发明另一实施例提供的 RTP媒体数据的处理***的结构示意 图， 如图 7所示， 本实施例的 RTP媒体数据的处理***可以包括发送端设备 71和接收端设备 72, 其中，
所述发送端设备 71 , 用于获得第一头部数据和 RTP媒体数据， 并向所 述接收端设备 72发送第一 DTLS数据包， 所述第一 DTLS数据包的 DTLS 头中包含数据包格式标识和起始变化字节标识， 以及所述第一 DTLS数据包 的 DTLS载荷中包含所述第一头部数据和所述 RTP媒体数据；或者所述第一 DTLS数据包的 DTLS载荷中包含第二头部数据和所述 RTP媒体数据；
所述接收端设备 72,用于接收所述发送端设备 71发送的所述第一 DTLS 数据包， 若所述数据包格式标识指示为完整格式， 存储所述第一 DTLS数据 包中的第一头部数据以作为标准头部数据， 并对所述标准头部数据和所述 RTP媒体数据进行解析处理； 若所述数据包格式标识指示为变化格式， 根据 所述起始变化字节标识、 所述标准头部数据和所述第一 DTLS数据包中的第 二头部数据， 获得所述第一头部数据， 并对所述第一头部数据和所述 RTP媒 体数据进行解析处理， 其中， 所述第二头部数据为所述第一头部数据与所述 标准头部数据相比， 发生变化的头部数据。
上述图 1对应的实施例中方法可以由本实施例提供的 RTP媒体数据的处 理***中接收端设备 72实现；上述图 2对应的实施例中方法可以由本实施例 提供的 RTP媒体数据的处理***中发送端设备 71实现。
进一步地， 发送端设备 71向接收端设备 72发送的第一 DTLS数据包的 DTLS头中还可以进一步包含序列号； 相应地， 所述接收端设备 72还可以进 一步用于在预先设置的时间阈值之后或者根据所述 DTLS 头中包含的序列 号， 确定没有接收到的第一 DTLS数据包的序列号， 并向所述发送端设备 71 发送失步指示信息， 所述失步指示信息中包含确定的序列号； 所述发送端设 备 71还可以进一步用于接收所述接收端设备 72发送的所述失步指示信息， 向所述接收端设备 72重新发送所述序列号标识的第一 DTLS数据包。
具体地， 所述接收端设备 72 具体可以向所述发送端设备 71 发送第二 DTLS数据包， 所述第二 DTLS数据包的 DTLS头中包含的数据包格式标识 指示为反馈状态格式， 所述第二 DTLS数据包的 DTLS载荷中包含所述失步 指示信息； 相应地， 所述发送端设备 71具体可以接收所述接收端设备 72发 送的所述第二 DTLS数据包。
进一步地， 发送端设备 71向接收端设备 72发送的第一 DTLS数据包的 DTLS头中还可以进一步包含所述 RTP媒体数据所属媒体流的媒体流标识； 相应地，所述接收端设备 72具体可以用于若所述数据包格式标识指示为完整 格式， 存储所述第一 DTLS数据包中的第一头部数据以作为标准头部数据， 以及存储所述媒体流标识，并对所述标准头部数据和所述 RTP媒体数据进行 解析处理； 若所述数据包格式标识指示为变化格式， 并根据所述媒体流标识、 所述起始变化字节标识、 与所述媒体流标识对应的所述标准头部数据， 以及 所述第一 DTLS数据包中的第二头部数据， 获得所述第一头部数据， 并对所 述第一头部数据和所述 RTP媒体数据进行解析处理。
本实施例中， 通过发送端设备发送的 DTLS数据包的 DTLS头中所包含 的数据包格式标识和起始变化字节标识， 使得接收端设备能够根据上述数据 包格式标识和起始变化字节标识， 以及存储的标准头部数据， 将 DTLS数据 包的 DTLS载荷中所包含的不完整的头部数据还原成完整的头部数据， 以便 对完整的带 IP头的 RTP数据包（即包括 RTP媒体数据和完整的头部数据 ) 进行解析处理， 能够避免现有技术中由于 DTLS载荷中的头部数据占用了大 量的***开销而导致的与 RTP媒体数据相关的有效载荷占整个 DTLS数据包 的比例严重下降的问题， 从而提高了传输信道的利用率。
所属领域的技术人员可以清楚地了解到， 为描述的方便和简洁， 上述描 述的***， 装置和单元的具体工作过程， 可以参考前述方法实施例中的对应 过程， 在此不再赘述。
在本申请所提供的几个实施例中， 应该理解到， 所揭露的***， 装置和 方法， 可以通过其它的方式实现。 例如， 以上所描述的装置实施例仅仅是示 意性的， 例如， 所述单元的划分， 仅仅为一种逻辑功能划分， 实际实现时可 以有另外的划分方式， 例如多个单元或组件可以结合或者可以集成到另一个 ***， 或一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之间 的耦合或直接耦合或通信连接可以是通过一些接口， 装置或单元的间接耦合 或通信连接， 可以是电性， 机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的， 作 为单元显示的部件可以是或者也可以不是物理单元， 即可以位于一个地方， 或者也可以分布到多个网络单元上。 可以根据实际的需要选择其中的部分或 者全部单元来实现本实施例方案的目的。
另外 ,在本发明各个实施例中的各功能单元可以集成在一个处理单元中 , 也可以是各个单元单独物理存在， 也可以两个或两个以上单元集成在一个单 元中。 上述集成的单元既可以采用硬件的形式实现， 也可以采用软件功能单 元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售 或使用时， 可以存储在一个计算机可读取存储介质中。 基于这样的理解， 本 发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的 全部或部分可以以软件产品的形式体现出来， 该计算机软件产品存储在一个 存储介质中， 包括若干指令用以使得一台计算机设备 (可以是个人计算机， 服务器， 或者网络设备等）执行本发明各个实施例所述方法的全部或部分步 骤。 而前述的存储介质包括： U 盘、 移动硬盘、 只读存储器 （Read-Only Memory, 简称 ROM )、 随机存取存储器（ Random Access Memory, 简称 RAM ), 磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对其 限制； 尽管参照前述实施例对本发明进行了详细的说明， 本领域的普通技术 人员应当理解： 其依然可以对前述各实施例所记载的技术方案进行修改， 或 者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技 术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims

权 利 要求
1、 一种 RTP媒体数据的接收方法， 其特征在于， 包括：
接收发送端设备发送的第一 DTLS数据包， 所述第一 DTLS数据包的 DTLS头中包含数据包格式标识和起始变化字节标识， 所述第一 DTLS数据 包的 DTLS载荷中包含第一头部数据和 RTP媒体数据；
若所述数据包格式标识指示为完整格式， 存储所述第一 DTLS数据包中 的第一头部数据以作为标准头部数据，并对所述标准头部数据和所述 RTP媒 体数据进行解析处理；
若所述数据包格式标识指示为变化格式， 根据所述起始变化字节标识、 所述标准头部数据和所述第一 DTLS数据包中的第一头部数据， 获得第二头 部数据， 并对所述第二头部数据和所述 RTP媒体数据进行解析处理， 其中， 所述第一头部数据为所述第二头部数据与所述标准头部数据相比， 发生变化 的头部数据。
2、 根据权利要求 1所述的方法， 其特征在于， 所述根据所述起始变化字 节标识、 所述标准头部数据和所述第一 DTLS数据包中的第一头部数据， 获 得第二头部数据， 包括：
根据所述起始变化字节标识， 确定对应的起始变化字节；
根据所述第一头部数据的大小， 确定对应的变化字节长度；
将所述标准头部数据中从所述起始变化字节开始， 总共所述变化字节长 度的数据替换为所述第一头部数据， 所述标准头部数据中其他数据不变， 构 成所述第二头部数据。
3、根据权利要求 1或 2所述的方法， 其特征在于， 若所述数据包格式标 识指示为完整格式， 对所述起始变化字节标识进行无效处理。
4、 根据权利要求 1 至 3任一权利要求所述的方法， 其特征在于， 所述 DTLS头中还包含序列号； 所述方法还包括：
在预先设置的时间阈值之后或者根据所述 DTLS头中包含的序列号， 确 定没有接收到的第一 DTLS数据包的序列号；
向所述发送端设备发送失步指示信息， 所述失步指示信息中包含确定的 序列号，以使所述发送端设备重新发送所述序列号标识的第一 DTLS数据包。
5、 根据权利要求 4所述的方法， 其特征在于， 所述向所述发送端设备发 送失步指示， 包括：
向所述发送端设备发送第二 DTLS数据包， 所述第二 DTLS数据包的 DTLS头中包含的数据包格式标识指示为反馈状态格式， 所述第二 DTLS数 据包的 DTLS载荷中包含所述失步指示信息。
6、 根据权利要求 1 至 5任一权利要求所述的方法， 其特征在于， 所述 DTLS头中还包含所述 RTP媒体数据所属媒体流的媒体流标识；
所述存储所述第一 DTLS 数据包中的第一头部数据以作为标准头部数 据， 包括：
存储所述第一 DTLS数据包中的第一头部数据以作为标准头部数据， 以 及存储所述媒体流标识；
所述根据所述起始变化字节标识、 所述标准头部数据和所述第一 DTLS 数据包中的第一头部数据， 获得第二头部数据， 包括：
根据所述媒体流标识、 所述起始变化字节标识、 与所述媒体流标识对应 的所述标准头部数据、 以及所述第一 DTLS数据包中的第一头部数据， 获得 第二头部数据。
7、 一种 RTP媒体数据的发送方法， 其特征在于， 包括：
获得第一头部数据和 RTP媒体数据；
向接收端设备发送第一 DTLS数据包， 所述第一 DTLS数据包的 DTLS 头中包含数据包格式标识和起始变化字节标识，
所述第一 DTLS数据包的 DTLS 载荷中包含所述第一头部数据和所述 RTP媒体数据， 以使所述接收端设备根据所述数据包格式标识， 存储所述第 一 DTLS数据包中的第一头部数据以作为标准头部数据， 并对所述标准头部 数据和所述 RTP媒体数据进行解析处理； 或者
所述第一 DTLS数据包的 DTLS载荷中包含第二头部数据和所述 RTP媒 体数据， 以使所述接收端设备根据所述数据包格式标识， 并根据所述起始变 化字节标识、所述标准头部数据和所述第一 DTLS数据包中的第二头部数据， 获得所述第一头部数据，并对所述第一头部数据和所述 RTP媒体数据进行解 析处理， 其中， 所述第二头部数据为所述第一头部数据与所述标准头部数据 相比， 发生变化的头部数据。
8、根据权利要求 7所述的方法， 其特征在于， 所述 DTLS头中还包含序 列号； 所述方法还包括：
接收所述接收端设备发送的失步指示信息， 所述失步指示信息中包含所 述接收端设备确定的序列号， 所述失步指示信息为所述接收端设备在预先设 置的时间阈值之后或者根据所述 DTLS头中包含的序列号， 确定没有接收到 的第一 DTLS数据包的序列号之后发送；
向所述接收端设备重新发送所述序列号标识的第一 DTLS数据包。
9、 根据权利要求 8所述的方法， 其特征在于， 所述接收所述接收端设备 发送的失步指示信息， 包括：
接收所述接收端设备发送的第二 DTLS数据包， 所述第二 DTLS数据包 的 DTLS头中包含的数据包格式标识指示为反馈状态格式， 所述第二 DTLS 数据包的 DTLS载荷中包含所述失步指示信息。
10、 根据权利要求 7至 9任一权利要求所述的方法， 其特征在于， 所述
DTLS头中还包含所述 RTP媒体数据所属媒体流的媒体流标识；
所述接收端设备存储所述第一 DTLS数据包中的第一头部数据以作为标 准头部数据， 包括：
所述接收端设备存储所述第一 DTLS数据包中的第一头部数据以作为标 准头部数据， 以及存储所述媒体流标识；
所述接收端设备根据所述起始变化字节标识、 所述标准头部数据和所述 第一 DTLS数据包中的第二头部数据， 获得所述第一头部数据， 包括： 所述接收端设备根据所述媒体流标识、 所述起始变化字节标识、 与所述 媒体流标识对应的所述标准头部数据、 以及所述第一 DTLS数据包中的第二 头部数据， 获得所述第一头部数据。
11、 一种 RTP媒体数据的接收端设备， 其特征在于， 包括：
接收单元， 用于接收发送端设备发送的第一 DTLS 数据包， 所述第一 DTLS数据包的 DTLS头中包含数据包格式标识和起始变化字节标识， 所述 第一 DTLS数据包的 DTLS载荷中包含第一头部数据和 RTP媒体数据； 处理单元，若所述数据包格式标识指示为完整格式，存储所述第一 DTLS 数据包中的第一头部数据以作为标准头部数据， 并对所述标准头部数据和所 述 RTP媒体数据进行解析处理； 若所述数据包格式标识指示为变化格式， 根 据所述起始变化字节标识、 所述标准头部数据和所述第一 DTLS数据包中的 第一头部数据， 获得第二头部数据， 并对所述第二头部数据和所述 RTP媒体 数据进行解析处理， 其中， 所述第一头部数据为所述第二头部数据与所述标 准头部数据相比， 发生变化的头部数据。
12、 根据权利要求 11 所述的设备， 其特征在于， 所述处理单元具体用 于
根据所述起始变化字节标识， 确定对应的起始变化字节， 根据所述第一 头部数据的大小， 确定对应的变化字节长度， 将所述标准头部数据中从所述 起始变化字节开始， 所述变化字节长度的数据替换为所述第一头部数据， 所 述标准头部数据中其他数据不变， 构成所述第二头部数据。
13、 根据权利要求 1 1或 12所述的设备， 其特征在于， 所述 DTLS头中 还包含序列号； 所述设备还包括：
指示单元， 用于在预先设置的时间阈值之后或者根据所述 DTLS头中包 含的序列号， 确定没有接收到的第一 DTLS数据包的序列号， 并向所述发送 端设备发送失步指示信息， 所述失步指示信息中包含确定的序列号， 以使所 述发送端设备重新发送所述序列号标识的第一 DTLS数据包。
14、 根据权利要求 13 所述的设备， 其特征在于， 所述指示单元具体用 于
向所述发送端设备发送第二 DTLS数据包， 所述第二 DTLS数据包的 DTLS头中包含的数据包格式标识指示为反馈状态格式， 所述第二 DTLS数 据包的 DTLS载荷中包含所述失步指示信息。
15、 根据权利要求 12至 14任一权利要求所述的设备， 其特征在于， 所 述 DTLS头中还包含所述 RTP媒体数据所属媒体流的媒体流标识；所述处理 单元具体用于
若所述数据包格式标识指示为完整格式， 存储所述第一 DTLS数据包中 的第一头部数据以作为标准头部数据， 以及存储所述媒体流标识， 并对所述 标准头部数据和所述 RTP媒体数据进行解析处理；若所述数据包格式标识指 示为变化格式， 根据所述媒体流标识、 所述起始变化字节标识、 与所述媒体 流标识对应的所述标准头部数据、 以及所述第一 DTLS数据包中的第一头部 数据， 获得第二头部数据， 并对所述第二头部数据和所述 RTP媒体数据进行 解析处理。
16、 一种 RTP媒体数据的发送端设备， 其特征在于， 包括：
获得单元， 用于获得第一头部数据和 RTP媒体数据；
发送单元， 用于向接收端设备发送第一 DTLS数据包， 所述第一 DTLS 数据包的 DTLS头中包含数据包格式标识和起始变化字节标识，
所述第一 DTLS数据包的 DTLS 载荷中包含所述第一头部数据和所述 RTP媒体数据， 以使所述接收端设备根据所述数据包格式标识， 存储所述第 一 DTLS数据包中的第一头部数据以作为标准头部数据， 并对所述标准头部 数据和所述 RTP媒体数据进行解析处理； 或者
所述第一 DTLS数据包的 DTLS载荷中包含第二头部数据和所述 RTP媒 体数据， 以使所述接收端设备根据所述数据包格式标识， 并根据所述起始变 化字节标识、所述标准头部数据和所述第一 DTLS数据包中的第二头部数据， 获得所述第一头部数据，并对所述第一头部数据和所述 RTP媒体数据进行解 析处理， 其中， 所述第二头部数据为所述第一头部数据与所述标准头部数据 相比， 发生变化的头部数据。
17、 根据权利要求 16所述的设备， 其特征在于， 所述 DTLS头中还包 含序列号； 所述设备还包括：
接收单元， 用于接收所述接收端设备发送的失步指示信息， 所述失步指 示信息中包含所述接收端设备确定的序列号， 所述失步指示信息为所述接收 端设备在预先设置的时间阈值之后或者根据所述 DTLS头中包含的序列号， 确定没有接收到的第一 DTLS数据包的序列号之后发送；
向所述接收端设备重新发送所述序列号标识的第一 DTLS数据包。
18、 根据权利要求 17 所述的设备， 其特征在于， 所述接收单元具体用 于
接收所述接收端设备发送的第二 DTLS数据包， 所述第二 DTLS数据包 的 DTLS头中包含的数据包格式标识指示为反馈状态格式， 所述第二 DTLS 数据包的 DTLS载荷中包含所述失步指示信息。
19、 根据权利要求 16至 18任一权利要求所述的设备， 其特征在于， 所 述 DTLS头中还包含所述 RTP媒体数据所属媒体流的媒体流标识，以使所述 接收端设备根据所述数据包格式标识，
存储所述第一 DTLS数据包中的第一头部数据以作为标准头部数据， 以 及存储所述媒体流标识，并对所述标准头部数据和所述 RTP媒体数据进行解 析处理； 或者
并根据所述媒体流标识、 所述起始变化字节标识、 与所述媒体流标识对 应的所述标准头部数据， 以及所述第一 DTLS数据包中的第二头部数据， 获 得所述第一头部数据，并对所述第一头部数据和所述 RTP媒体数据进行解析 处理。
20、 一种 RTP媒体数据的处理***， 其特征在于， 包括发送端设备和接 收端设备， 其中，
所述发送端设备， 用于获得第一头部数据和 RTP媒体数据， 并向所述接 收端设备发送第一 DTLS数据包， 所述第一 DTLS数据包的 DTLS头中包含 数据包格式标识和起始变化字节标识， 以及所述第一 DTLS数据包的 DTLS 载荷中包含所述第一头部数据和所述 RTP媒体数据；或者所述第一 DTLS数 据包的 DTLS载荷中包含第二头部数据和所述 RTP媒体数据；
所述接收端设备， 用于接收所述发送端设备发送的所述第一 DTLS数据 包， 若所述数据包格式标识指示为完整格式， 存储所述第一 DTLS数据包中 的第一头部数据以作为标准头部数据，并对所述标准头部数据和所述 RTP媒 体数据进行解析处理； 若所述数据包格式标识指示为变化格式， 根据所述起 始变化字节标识、 所述标准头部数据和所述第一 DTLS数据包中的第二头部 数据， 获得所述第一头部数据， 并对所述第一头部数据和所述 RTP媒体数据 进行解析处理， 其中， 所述第二头部数据为所述第一头部数据与所述标准头 部数据相比， 发生变化的头部数据。
21、 根据权利要求 20所述的***， 其特征在于， 所述 DTLS头中还包 含序列号；
所述接收端设备,还用于在预先设置的时间阈值之后或者根据所述 DTLS 头中包含的序列号， 确定没有接收到的第一 DTLS数据包的序列号， 并向所 述发送端设备发送失步指示信息， 所述失步指示信息中包含确定的序列号； 所述发送端设备，还用于接收所述接收端设备发送的所述失步指示信息， 向所述接收端设备重新发送所述序列号标识的第一 DTLS数据包。
22、 根据权利要求 20所述的***， 其特征在于，
所述接收端设备具体用于向所述发送端设备发送第二 DTLS数据包， 所 述第二 DTLS数据包的 DTLS头中包含的数据包格式标识指示为反馈状态格 式， 所述第二 DTLS数据包的 DTLS载荷中包含所述失步指示信息； 所述发送端设备具体用于接收所述接收端设备发送的所述第二 DTLS数 据包。
23、 根据权利要求 20至 22任一权利要求所述的***， 其特征在于， 所 述 DTLS头中还包含所述 RTP媒体数据所属媒体流的媒体流标识；
所述接收端设备具体用于
若所述数据包格式标识指示为完整格式， 存储所述第一 DTLS数据包中 的第一头部数据以作为标准头部数据， 以及存储所述媒体流标识， 并对所述 标准头部数据和所述 RTP媒体数据进行解析处理；
若所述数据包格式标识指示为变化格式， 并根据所述媒体流标识、 所述 起始变化字节标识、 与所述媒体流标识对应的所述标准头部数据， 以及所述 第一 DTLS数据包中的第二头部数据， 获得所述第一头部数据， 并对所述第 一头部数据和所述 RTP媒体数据进行解析处理。
PCT/CN2011/076562 2011-06-29 2011-06-29 Rtp媒体数据的接收、发送方法及装置、处理*** WO2012103722A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2011/076562 WO2012103722A1 (zh) 2011-06-29 2011-06-29 Rtp媒体数据的接收、发送方法及装置、处理***
CN201180000926.5A CN102726024B (zh) 2011-06-29 2011-06-29 Rtp媒体数据的接收、发送方法及装置、处理***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/076562 WO2012103722A1 (zh) 2011-06-29 2011-06-29 Rtp媒体数据的接收、发送方法及装置、处理***

Publications (1)

Publication Number Publication Date
WO2012103722A1 true WO2012103722A1 (zh) 2012-08-09

Family

ID=46602072

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/076562 WO2012103722A1 (zh) 2011-06-29 2011-06-29 Rtp媒体数据的接收、发送方法及装置、处理***

Country Status (2)

Country Link
CN (1) CN102726024B (zh)
WO (1) WO2012103722A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110225212B (zh) * 2019-05-21 2021-08-06 中国电子科技集团公司第三十六研究所 一种VoIP语音恢复方法和装置
CN113364508B (zh) * 2021-04-30 2022-08-16 深圳震有科技股份有限公司 一种语音数据的传输控制方法、***及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101370004A (zh) * 2007-08-16 2009-02-18 华为技术有限公司 一种组播会话安全策略的分发方法及组播装置
CN101764825A (zh) * 2010-02-08 2010-06-30 成都市华为赛门铁克科技有限公司 虚拟专用网的数据传输方法、***及终端、网关设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100563210C (zh) * 2006-11-23 2009-11-25 华为技术有限公司 压缩报头的方法、压缩器及传输***
CN101534291A (zh) * 2008-03-13 2009-09-16 华为技术有限公司 Ip报文的发送、接收的方法及装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101370004A (zh) * 2007-08-16 2009-02-18 华为技术有限公司 一种组播会话安全策略的分发方法及组播装置
CN101764825A (zh) * 2010-02-08 2010-06-30 成都市华为赛门铁克科技有限公司 虚拟专用网的数据传输方法、***及终端、网关设备

Also Published As

Publication number Publication date
CN102726024A (zh) 2012-10-10
CN102726024B (zh) 2015-08-19

Similar Documents

Publication Publication Date Title
US10911510B2 (en) Apparatus and method for transmitting multimedia data in a broadcast system
JP5778672B2 (ja) バックワードルッキングロバストヘッダ圧縮レシーバ
JP4000905B2 (ja) 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム
US8954525B2 (en) Method and apparatus of performing remote computer file exchange
JPWO2005099188A1 (ja) 通信品質管理方法および装置
WO2020006912A1 (zh) 网络传输质量分析方法、装置、计算机设备和存储介质
US20120210195A1 (en) Method, device, and system for forward error correction
CN101854286B (zh) 基于用户数据报协议的数据流发送、接收方法及装置
US9392082B2 (en) Communication interface and method for robust header compression of data flows
EP2472799A1 (en) Method, apparatus and system for rapid acquisition of multicast realtime transport protocol sessions
CN113014586B (zh) Rtp数据包乱序处理及重组帧方法和***
WO2011137837A1 (zh) 一种快速频道切换时获取关键信息的方法、装置和***
CN111954028A (zh) 音频数据的投屏方法、装置、设备及存储介质
JP4600513B2 (ja) データ送信装置、送信レート制御方法およびプログラム
WO2011032482A1 (zh) 一种测量方法、装置和***
WO2012103722A1 (zh) Rtp媒体数据的接收、发送方法及装置、处理***
WO2017118273A1 (zh) 发送、接收时间戳信息的方法和装置
WO2014100973A1 (zh) 视频处理方法、设备及***
Fracchia et al. R-RoHC: A single adaptive solution for header compression
WO2024074085A1 (zh) 数据传输方法、电子设备、传屏器及存储介质
CN116896567B (zh) 网络层协议传输数据方法和装置
WO2024104016A1 (zh) 一种数据传输的方法、装置、电子设备及存储介质
CN109196870B (zh) 用于发射和接收mmtp分组的方法和装置
US20150063103A1 (en) Bandwidth-dependent compressor for robust header compression and method of use thereof
WO2014166217A1 (zh) 一种多媒体业务传输方法及终端

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180000926.5

Country of ref document: CN

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

Ref document number: 11857890

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11857890

Country of ref document: EP

Kind code of ref document: A1