|
RTP (Real-timetransportprotocol) is a transmission protocol for multimedia data streams on the Internet. RTP is defined to work during one-to-one or one-to-many transmission. It aims to provide time information and implement stream synchronization. RTP usually uses UDP to transmit data, but RTP can also work on other protocols such as TCP or ATM. When an application starts a RTP session, two ports are used: one for RTP and the other for RTCP. RTP itself does not provide a reliable transmission mechanism for transmitting data packets in sequence, nor does it provide traffic control or congestion control. It relies on RTCP to provide these services. Generally, the RTP algorithm is not implemented as an independent network layer, but as part of the application code. Real-time transmission control protocol RTCP. RTCP (Real-timetransportcontrolprotocol) and RTP provide traffic control and congestion control services. During the RTP session, each participant periodically transmits the RTCP package. The RTCP package contains statistics such as the number of sent data packets and the number of lost data packets. Therefore, the server can use this information to dynamically change the transmission rate or even the payload type. RTP and RTCP can be used together to optimize transmission efficiency with effective feedback and minimal overhead. Therefore, RTP is particularly suitable for transmitting real-time online data. 6.2.1 RTP data transmission protocol RTP provides end-to-end network transmission, which is suitable for transmitting real-time data, such as video, audio, and simulation data, through multicast and on-demand transmission. RTP does not involve real-time services such as resource reservation and Quality Assurance. RTCP expands data transmission to allow monitoring data transmission and provides minimum control and recognition functions. RTP and RTCP are designed as independent transmission and network layers. 2.1.1 fixed RTP Header
The RTP Header Format is as follows:
Bytes -----------------------------------------------------------------------------------------------
| V = 2 | p | x | CC | M | Pt | serial number |
Bytes -----------------------------------------------------------------------------------------------
| Time scale |
Bytes -----------------------------------------------------------------------------------------------
| Synchronization source ID (SSRC) |
Bytes -----------------------------------------------------------------------------------------------
| Role ID (CSRC) |
|... |
Bytes ----------------------------------------------------------------------------------------------- The first 12 octal labels appear in each RTP packet, and the csrc id list only appears when the mixer is inserted.
2.1.2 reuse RTP connections
To make the protocol run effectively, the number of reuse points should be minimized. In RTP, multiplexing is provided by the destination transmission address (network address and port number) that defines the RTP connection. For example, for remote conferences with separate audio and video encoding, each media is carried in a separate RTP connection and has its own destination transmission address. The target does not place the audio and video in a single RTP connection, but does not perform multi-path Decomposition Based on the load type of the SSRC segment. When the same SSRC is used, cross packets with different load types may cause several problems:
If a load type is switched during connection, there is no way to identify that the new value will replace the old one.
SSRC is defined to identify a single time and serial number space. If the media clock rate is different and different serial numbers are required to indicate that the load type has packet loss, the cross-multiplexing load type requires different timing spaces.
The RTCP send and receive report may only describe the timing and serial number space of each SSRC, without carrying the load type segment.
The RTP mixer cannot merge incompatible media streams into one stream.
Carry multiple media in a RTP connection to block a few things: use different network paths or network resource allocation; accept a subset of media.
Use different SSRC for each media type, but sending with the same RTP connection can avoid the first three problems, but cannot avoid the last two problems. 2.1.3 modify specific settings of the RTP Header
It can be considered that the current RTP data header is complete for all the application classes supported by RTP. However, to maintain the alf design principles, the header can be cropped by changing or adding settings, and the setting of irrelevant monitoring and record tools is still allowed to work. The flag and load type segments carry specific settings, but many applications require them. Otherwise, they must be added with 32 characters, so they can be allocated to the fixed header. Octal segments that contain these segments can be customized to meet different requirements, such as using more or less flag bits. If there is a tag bit, since the unrelated monitor can observe the relationship between the packet loss mode and the tag bit, we can locate the most important bit in October.
The information required by other special loading formats (Video Encoding) should be carried in the load section of the package. It can appear in the header, always at the beginning of the load part, or in the reserved value of the data mode. If special application classes require additional functions in the form of independent loads, the application running settings should define additional fixed segments following the existing fixed head SSRC. These applications will be able to quickly and directly access the additional segment, while the settings unrelated to the monitor and recorder can still be explained by starting with only 12 octal workers to process RTP packets. If it is confirmed that the additional function is required by all settings, the new version of RTP should explicitly change the Fixed Header. |
