Analysis of the header structure of RTP protocol

The real-time transport protocol RTP,RTP provides end-to-end data transfer services with real-time features, such as interactive audio and video. Those services include payload type definition, serial number, timestamp, and transmission monitoring control. The application runs RTP on UDP to use its Multipath technology and checksum services. There are 2 protocols that provide some of the functionality of the transport protocol. However, RTP may be used by other appropriate downlevel networks and transport protocols. If the underlying network supports, RTP support data is forwarded to multiple destinations using a multicast distribution mechanism. Note that RTP itself does not provide any mechanism to ensure real-time transmission or other service quality assurance, but is done by low-level services. It does not guarantee transmission or prevent disorderly transmission, it does not assume that the underlying network is reliable, whether the packet is transmitted sequentially. RTP contains serial numbers that allow the recipient to refactor the sender's packet order, but the serial number is also used to determine the correct location of a packet, for example, without sequentially decoding the packet when the video is decoded. But RTP's original design was designed to meet the needs of multi-participant multimedia conferencing, which was not limited to specialized applications. Storage of continuous data, interactive distributed simulations, dynamic tagging, and control and measurement applications may also be suitable for use with RTP. 1, RTP fixed head structure RTP fixed head structure 2 is shown. Figure 1 The first 12 bytes of the RTP fixed header format appear in each RTP package, and only the CSRC identifier list appears when the mixer is inserted. The meanings of each domain are as follows: (1) version (V): 2 bits, this domain defines the version of RTP. The version defined by this protocol is 2. (The value 1 is used by the RTP draft version, and the value 0 is used in the protocol originally used by the "VAT" voice tool.) ) (2) Fill (P): 1 bits, if the filler bit is set, then this package contains one to multiple padding bits attached to the end, and the padding bits do not count as part of the load. The last byte of the padding indicates how many padding bits can be ignored. Padding may be used for certain cryptographic algorithms with fixed lengths, or for transferring multiple RTP packets in the underlying data unit. (3) extension (X): 1 bit, if the extension bit is set, the fixed head (only) follows a head extension. (4) CSRC count (CC): 4 bits, CSRC count contains the number of CSRC identifiers followed by the fixed head. (5) Mark (M): 1 bits, the interpretation of the logo is stipulated by the specific agreement. It is used to allow the marking of important events, such as frame boundaries, in the bitstream. (6) Load type (PT): 7 bits, this domain defines the format of the payload, which is interpreted by the application, and the protocol can dictate a default match between the payload type code and the payload format. Other load type codes can be dynamically defined by non-RTP methods. The RTP sender emits a separate RTP at any given time Load type; This field does not have to be used for different media streams. (7) Serial numbers (sequence number): 16 bits, each sending a RTP packet, the serial number plus 1, the receiver can detect the packet loss and reconstruction package sequence. The initial value of the sequence number is random (unpredictable), so that even if the source itself is not encrypted (and sometimes the packet is going through the translator, it will), the ordinary text attacks on the cryptographic algorithm will be more difficult to understand. (8) Timestamp (timestamp): 32 bits, the timestamp reflects the sampling time of the first byte in the RTP packet. The clock frequency is dependent on the payload data format and is described in the profile. The payload format can also be described dynamically through the RTP method. If the RTP packets are generated periodically, the nominal sampling time determined by the sampling clock is used instead of the system time. For example, for a fixed rate of audio, the sampling clock will increase by 1 over each cycle. If an audio reads a block with 160 sample cycles from the input device, the timestamp value increases by 160 for each block. The initial value of the timestamp should be random, just like the ordinal. Several successive RTP packets are generated at the same time. For example: RTP packets belonging to the same video frame will have the same serial number. RTP timestamps for different media streams may grow at different rates. And there will be an independent random offset. Therefore, although these timestamps are sufficient to reconstruct the time of a separate stream, the timestamp of the direct comparison of the different media streams cannot be synchronized. For each media, we associate the RTP timestamp associated with the sampling time with the timestamp (NTP) from the reference clock. So the timestamp of the reference clock is the sampling time of the data. (That is, the RTP timestamp can be used to achieve synchronization of different media streams, and the NTP timestamp solves the problem of a random offset of the RTP timestamp.) The reference clock is used to synchronize the common time of all media. This timestamp pair (RTP timestamp and NTP timestamp) is used to determine the corresponding relationship between the RTP timestamp and the NTP timestamp in order to synchronize the media stream. They are not sent in every packet, but in the SR (Sender report) of the RTCP with a lower transmit rate. If the transmitted data is stored well rather than sampled in real time, then the virtual representation timeline (Virtual presentation timeline) obtained from the reference clock is used. To determine how long each media in the storage data should be rendered in the next frame or the next unit. In this case, the RTP timestamp reflects the time at which each unit should be played back. The real replay will be decided by the receiver. (9) ssrc:32 bits, which are used to identify the synchronization source. Identifiers are randomly generated so that no two synchronization sources in the same RTP session have the sameThe SSRC identifier. Although the probability of selecting the same SSRC identifier for multiple sources is low, all RTP implementation tools must be prepared to detect and resolve conflicts. If a source changes its source transport address, a new SSRC identifier must be selected to avoid being treated as a loop source. The source of the RTP packet stream, identified by the SSRC identifier of the 32-bit value in the RTP header, so that it does not depend on the network address. All packages of a synchronization source make up part of the same timing and serial number space so that the receiver can put together a synchronization source package for replay. Examples of synchronization sources, such as the sender of a packet stream from the same source, such as a microphone, a camera, and an RTP mixer, are synchronous sources. A synchronization source may change its data format, such as audio encoding, over time. The SSRC identifier is a randomly selected value that is globally unique (globally unique) in a particular RTP session. The participant does not need to use the same SSRC identifier in all RTP sessions of a multimedia conference, and the SSRC identifier is bound through RTCP. If a contributor generates multiple streams in one RTP session, such as from multiple cameras, each camera must be identified as a separate synchronization source. CSRC list: 0 to 15 items, 32 bits per item, CSRC list identifies all contributing sources for the payload in this package. The number of identifiers is given in the CC field. If there are more than 15 contributing sources, only 15 are identified. The CSRC identifier is inserted by the mixer and lists the SSRC identifiers for all contributing sources. For example, a voice pack, a mix of all sources that generate new packages, SSRC identifiers are listed to correctly indicate participants at the receiving end. If the source of a RTP packet stream acts on a combined stream generated by the RTP mixer, it is a source of action. A list of SSRC identifiers that function as a source for a particular package's build, and are inserted into the RTP header of the package by the mixer. This list is called the CSRC table. Examples of relevant applications such as in audio conferencing, the mixer points out to all speakers (talker) that whose word (speech) will be combined into the forthcoming package, even if all packages are contained in the same (mixer) SSRC identifier, allowing the listener (receiver) It is clear who is currently speaking. 2. RTP extension Header structure RTP provides an extension mechanism to allow personalization: Some new additional information that is required for the load format independent functionality is transmitted in the RTP header. This method can be designed so that other non-extended interactions ignore this header extension. RTP Expansion Header Format 2 is shown. Figure 2 RTP Expansion header format if the extended bit position in the RTP fixed header is 1, a variable-length header extension is added to the RTP pin. Header extension contains 16 ratioA length field that indicates the number of 32-bit words in the extension, excluding the 4-byte expansion header (so 0 is a valid value). Only one header extension is allowed after the RTP fixed head. To allow multiple interop implementations to independently generate different header extensions, or a particular implementation has several different header extensions, the first 16 bits of an extension are used to identify identifiers or parameters. The 16-bit format is defined by the implementation-specific upper layer protocol. The basic RTP description does not define any header extensions themselves. 3, RTP packet parsing RTP Packet Parsing example is shown below: [CPP] view plaincopy static int Parsingrtppacket (uint8_t *data, size_t size) {if (Size < 12) {// Too short to be a valid RTP header. return-1; } if ((Data[0] >> 6)! = 2) {//currently, the version is 2, if are not 2, unsupported. return-1;} if (Data[0] & 0x20) {//Padding present. size_t paddinglength = data[size-1]; if (paddinglength + > size) {return-1;} size -= Paddinglength; } int numcsrcs = data[0] & 0x0f; size_t Payloadoffset = 4 * NUMCSRCS; if (Size < Payloadoffset) {//Not enough data to fit the basic header and all the CSRC entries. return-1;} if (data[ 0] & 0x10) {//Header extension present. if (Size < Payloadoffset + 4) {//Not enough data to fit the basic Heade R, all CSRC entries and the first 4 bytes of the extension header. return-1; } const uint8_t *extensiondata = &data[payloadOffset]; size_t extensionlength = 4 * (extensiondata[2] << 8 | extensiondata[3]); if (Size < Payloadoffset + 4 + extensionlength) {return-1;} Payloadoffset + = (4 + extensionlength); } uint32_t rtptime = data[4] << 24 | DATA[5] << 16 | DATA[6] << 8 | DATA[7]; uint32_t srcid = data[8] << 24 | DATA[9] << 16 | DATA[10] << 8 | DATA[11]; uint32_t seqNum = data[2] << 8 | DATA[3]; return 0; }

Header structure parsing of RTP protocol