Shulou(Shulou.com)06/01 Report--

RTP protocol

Real-time Transport Protocol RTP (Real-time Transport Protocol) is a network transport protocol. It was published in RFC 1889 by IETF's Multimedia Transport working Group in 1996, and then updated in RFC3550.

The International Telecommunication Union (ITU-T) also released its own RTP document as H.225.0, but was later cancelled when IETF released its stable standard RFC. It is described in detail in [RFC 3550] as an Internet standard.

The RTP protocol details the standard packet format for transmitting audio and video over the Internet. It was originally designed as a multicast protocol, but it has since been used in many unicast applications. RTP protocol is often used in streaming media systems (with RTSP protocol), video conferencing and push-to-talk (Push toTalk) systems (with H.323 or SIP), making it the technical foundation of the IP telephone industry. The RTP protocol is used with the RTP control protocol RTCP, and it is based on the user Datagram protocol (UDP).

RTP is widely used in streaming media-related communications and entertainment, including telephone, video conferencing, television and web-based push-to-talk services (similar to walkie-talkie calls)

The RTP standard defines two subprotocols, RTP and RTCP

Data transfer protocol RTP, used for real-time transmission of data. The information provided by the protocol includes a timestamp (for synchronization), a sequence number (for packet loss and reordering detection), and a payload format (used to describe the encoding format of the data).

The control protocol RTCP is used for QoS feedback and synchronizing media streams. Compared to RTP, RTCP takes up a very small amount of bandwidth, usually only 5%.

Why use RTP

When it comes to streaming media transmission, video surveillance, video conference and voice call (VOIP), we can't do without the application of RTP protocol. But when everyone chooses RTP protocol according to their experience or other people's application, have you ever wondered why we use RTP for streaming media transmission? Why do we have to use RTP? Can't TCP, UDP or other network protocols meet our requirements?

Reliable transport protocols such as TCP ensure the correctness of every bit in the transmission data stream through timeout and retransmission mechanisms, but this will make the implementation of the protocol and the transmission process very complex. Moreover, when there is data loss in the transmission process, due to the detection of data loss (timeout detection) and retransmission, the transmission of the data stream will be forced to pause and delay.

You may say that we can use the client to construct a large enough buffer to ensure normal display. This method is acceptable for playing audio and video from the network, but for some situations that require real-time interaction (such as video chat, video conference, etc.), if this buffer exceeds 200ms, it will produce an unacceptable real-time experience.

Why RTP can solve the above delay problem

RTP protocol is a transmission protocol based on UDP. RTP itself can not provide a reliable transmission mechanism for sending data packets sequentially, nor does it provide flow control or congestion control. It relies on RTCP to provide these services. In this way, for those lost packets, there is no delay caused by timeout detection, and for those dropped packets, the upper layer can selectively retransmit them according to their importance. For example, for I frame, P frame and B frame data, because their importance decreases in turn, in the case of bad network condition, we can consider not to retransmit in the case of B frame loss or even P frame loss. In this way, on the client side, although there may be a short unclear picture, it ensures the real-time experience and requirements.

A sublayer of the transport layer at the protocol level of RTP

Figure 1 shows a typical protocol architecture in streaming media applications.

As can be seen from the figure, RTP is divided into the transport layer, which is based on UDP. Like UDP protocol, RTP has a fixed form of encapsulation in order to realize its real-time transmission function. RTP is used to provide time information and stream synchronization for end-to-end real-time transmission, but does not guarantee the quality of service. The quality of service is provided by RTCP.

The working mechanism of RTP is:

When the application establishes a RTP session, the application determines a pair of destination transport addresses. The destination transmission address consists of a network address and a pair of ports, with two ports: one for RTP packet and one for RTCP packet, so that RTP/RTCP data can be sent correctly. RTP data is sent to even-numbered UDP ports, while the corresponding control signal RTCP data is sent to adjacent odd-numbered UDP ports (even-numbered UDP ports + 1), thus forming a UDP port pair. The sending process of the RTP is as follows, and the receiving process is the opposite.

1) RTP protocol receives the stream of streaming media information (such as H.263) from the upper layer and encapsulates it into RTP packets; RTCP receives control information from the upper layer and encapsulates it into RTCP control packets. 2) RTP sends RTP packets to even ports in UDP port pairs, and RTCP sends RTCP control packets to odd ports in UDP port pairs.

RTP packets contain only RTP data, while control is provided by the RTCP protocol. RTP chooses an unused even UDP port number between 1025 and 65535, while RTCP in the same session uses the next odd UDP port number. Port numbers 5004 and 5005 are used as default port numbers for RTP and RTCP, respectively. The header format of the RTP packet is shown in figure 2, where the first 12 bytes are required.

Part of the application layer

From the application developer's point of view, RTP should be part of the application layer. On the sending side of the application, the developer must write the program code that encapsulates the packet with RTP, and then gives the RTP packet to the UDP socket interface. At the receiving end, after the RTP packet enters the application layer through the UDP socket interface, the application data block is extracted from the RTP packet by using the program code written by the developer.

Streaming Media characteristics in RTP header

First, let's take a look at the Baotou of RTP.

RTP header format (see RFC3550 Page12):

Version number (V): 2 bits, used to identify the RTP version used.

Padding bit (P): 1 bit, if this bit, the tail of the RTP packet contains additional padding bytes.

Expansion bit (X): 1 bit, if this position, the RTP fixed head followed by an expansion head.

CSRC counter (CC): 4 bits containing the number of CSRC followed by a fixed head.

Tag bit (M): 1 bit, the interpretation of which is borne by the configuration document (Profile).

Load type (PayloadType): 7 bits, which identifies the type of RTP load.

Sequence number (SN): 16 bits, each time a RTP packet is sent, the sequence number increases by 1. The receiver can detect packet loss and reconstruct the packet sequence accordingly.

Timestamp: 2 bits, recording the sampling time of the first byte of the data in the packet. At the beginning of a session, the timestamp is initialized to an initial value. Even when there is no signal, the value of the timestamp increases over time (time is running out). The clock rate depends on the payload data format and is described in the description file (profile).

Synchronization source identifier (× × C): 32 bits. The synchronization source refers to the source of the RTP packet stream. You cannot have two identical × × C values in the same RTP session. The identifier is randomly selected. RFC1889 recommends the MD5 random algorithm.

List of contribution sources (CSRC List): 15 entries, 32 bits each, used to identify the sources of all RTP packages that contributed to a new package generated by a RTP mixer. The mixer inserts these contributed × × C identifiers into the table. The × × C identifiers are listed so that the receiver can correctly identify both sides of the conversation.

RTP extension header structure

Figure Rtp extension header

If the extension bit position 1 in the RTP fixed head (note: if there is a CSRC list, after the CSRC list), then a variable length extension of the head is added to the RTP fixed head. The header extension contains a 16-bit length field that indicates the number of 32-bit words in the extension, excluding 4-byte extension headers (so zero is a valid value).

Only one header extension is allowed after the RTP is fixed. To allow multiple interoperable implementations to independently generate different header extensions, or to have multiple different header extensions for a particular implementation, the first 16 bits of the extension are used to identify identifiers or parameters. The 16-bit format is defined by the upper layer protocol of the specific implementation. The basic RTP specification does not define any header extension itself.

The conversational process of RTP

When the application establishes a RTP session, the application determines a pair of destination transport addresses. The destination transmission address consists of a network address and a pair of ports, with two ports: one for RTP packet and one for RTCP packet, so that RTP/RTCP data can be sent correctly. RTP data is sent to even-numbered UDP ports, while the corresponding control signal RTCP data is sent to adjacent odd-numbered UDP ports (even-numbered UDP ports + 1), thus forming a UDP port pair.

The sending process of the RTP is as follows, and the receiving process is the opposite.

The RTP protocol receives the stream of streaming media information (such as H.263) from the upper layer and encapsulates it into RTP packets; RTCP receives control information from the upper layer and encapsulates it into RTCP control packets.

RTP sends RTP packets to even ports in the UDP port pair; RTCP sends RTCP control packets to the receive port in the UDP port pair.

Profile Mechanism of RTP

RTP provides great flexibility for specific applications. It separates the transport protocol from the specific application environment and specific control strategy. The transport protocol itself only provides a mechanism to complete real-time transmission. Developers can choose the appropriate configuration environment and appropriate control strategy according to different application environments.

The control strategy here means that you can implement specific RTCP control algorithms according to your specific application requirements, such as the above-mentioned packet loss detection algorithm, packet loss retransmission strategy, control scheme in some video conference applications, and so on (these strategies may be described in subsequent articles).

For the appropriate configuration environment mentioned above, it mainly refers to the relevant configuration of RTP and the definition of load format. In order to support a wide range of multimedia formats (such as H.264, MPEG-4, MJPEG, MPEG), RTP protocol does not reflect the specific application configuration in the protocol, but is provided in the form of profile configuration file and load type format description file. For any particular application, RTP defines a profile file and the associated payload format description, which is as follows:

RTP Profile for Audio and Video Conferences with Minimal Control (RFC3551)

"RTP Payload Format for H.264 Video" (RFC3984)

RTP Payload Format for MPEG-4 Audio/Visual Streams (RFC3016)

Wait a minute. For more information, please click here: http://en.wikipedia.org/wiki/RTP_audio_video_profile

Note: if the application does not use a proprietary scheme to provide a payload type (payload type), sequence number, or timestamp, but uses the standard RTP protocol, it will be easier for the application to run with other network applications, which is what everyone wants. For example, if two different companies are developing Internet telephony software, they both incorporate RTP into their products, so there is hope that users using different companies' telephony software will be able to communicate with each other.

Encapsulation of RTCP

The main functions of RTCP are:

Quality of service monitoring and feedback, synchronization between media, and identification of members of multicast groups. During the RTP session, participants periodically transmit RTCP packets. RTCP packets contain statistics such as the number of packets sent and the number of packets lost. Therefore, participants can use these information to dynamically change the transmission rate, and even change the type of payload. When RTP and RTCP are used together, they can optimize transmission efficiency with effective feedback and minimum overhead, so they are especially suitable for transmitting real-time data on the Internet.

RTCP is also transmitted by UDP, but RTCP only encapsulates some control information, so the packet is very short, so multiple RTCP packets can be encapsulated in a UDP packet. RTCP has the following five grouping types.

Type abbreviation indicates use 200SR (Sender Report) sender report 201RR (Receiver Report) receiver report 202SDES (Source Description Items) source point description 203BYE end transmission 204. APP specific application

The encapsulation of the above five groups is more or less the same. Only the SR type is described below, while for other types, please refer to RFC3550.

The sender report packet SR (Sender Report) is used to enable the sender to report transmission to all receivers in a multicast manner. The main contents of SR packets are: the × × C of the corresponding RTP stream, the timestamp of the newly generated RTP packet in the RTP stream, the number of packets contained in the NTP,RTP stream, and the number of bytes contained in the RTP stream. The encapsulation of the SR package is shown in figure 3.

Version (V): same as RTP header domain.

Fill (P): same as RTP header field.

The receive report counter (RC): 5 bits, and the number of received report blocks in the SR packet can be zero.

Packet type (PT): 8 bits, SR packet is 200.

Length field (Length): 16 bits, in which the total length of the SR packet is reduced by one in 32 bits.

Synchronization source (× × C): the synchronization source identifier of the sender of the SR packet. Same as × × C in the corresponding RTP package.

The absolute time value when the NTP Timestamp (Network time protocol) SR packet was sent. The role of NTP is to synchronize different RTP media streams.

RTP Timestamp: corresponding to the NTP timestamp, it has the same unit and random initial value as the RTP timestamp in the RTP packet.

Sender's packet count: the total number of SR packets sent by the sender between the start of sending the packet and the generation of the RTP packet. When × × C is changed, the domain is cleared.

Sender's octet count: the total number of bytes of payload data sent by the sender (excluding headers and padding) between the start of sending the packet and the generation of the SR packet. When the sender changes its × × C, this field needs to be cleared.

Synchronize the × × C identifier of source n: this report block contains statistics on packets received from this source.

Loss rate (Fraction Lost): indicates the loss rate of RTP packets from the synchronization source n (× × RR) since the last SR or RTP packet was sent.

Cumulative number of packet losses: the total number of RTP packets lost from the beginning of receiving xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcn to sending SR.

Extended maximum sequence number received: the largest sequence number of RTP packets received from × × Crunn

Reception Jitter (Interarrival jitter): statistical variance estimation of the acceptance time of RTP packets

Last SR timestamp (Last SR,LSR): take the middle 32 bits of the NTP timestamp in the recent SR packet received from × × Centrn. If the SR packet has not been received yet, the domain is zeroed.

Delay since the last SR (Delay since last SR,DLSR): the delay from the last receipt of the SR packet from × × Centrn to the sending of this report.

Attached: code description RTP header: / * * RTP header * / typedef struct {# if 0 / / BIG_ENDIA unsigned int version:2; / * protocol version * / unsigned int PRV 1; / * padding flag * / unsigned int XRV 1; / * header extension flag * / unsigned int cc:4; / * CSRC count * / unsigned int mV1; / * marker bit * / unsigned int pt:7 / * payload type * / unsigned int seq:16; / * sequence number * / # else unsigned int cc:4; / * CSRC count * / unsigned int XRV 1; / * header extension flag * / unsigned int PRV 1; / * padding flag * / unsigned int version:2; / * protocol version * / unsigned int pt:7; / * payload type * / unsigned int MVA 1 / * marker bit * / unsigned int seq:16; / * sequence number * / # endif u_int32 ts; / * timestamp * / u_int32 * * c; / * synchronization source * / u_int32 csrc [1]; / * optional CSRC list * /} rtp_hdr_t 1234567891011121314151617181920212223242526272829RTCP Common header: / * * RTCP common header word * / typedef struct {# if 0 / / BIG_ENDIA unsigned int version:2; / * protocol version * / unsigned int pv1; / * padding flag * / unsigned int count:5; / * varies by packet type * / # else unsigned int count:5; / * varies by packet type * / unsigned int pv1; / * padding flag * / unsigned int version:2 / * protocol version * / # endif unsigned int pt:8; / * RTCP packet type * / unsigned short length; / * pkt len in words, w this word * /} rtcp_common_t

Scan the QR code below to follow

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.