Real-Time Transport Protocol
|RTP (Real-Time Transport Protocol)|
|Operation area:||Transport of media streams|
|Port:||any free, even port greater than 1024|
RFC 3550 (RTP: A Transport Protocol
for Real-Time Applications, 2003 )
The Real-Time Transport Protocol ( RTP ) is a protocol for the continuous transmission of audiovisual data ( streams ) over IP -based networks . The protocol was first standardized in RFC 1889 in 1996 . In 2003 it was replaced by RFC 3550 .
It serves Multimedia - data streams ( audio , video , text , etc.) via networks to transport, d. H. encode, package and send the data. RTP is a packet- based protocol and is normally operated over UDP . RTP can be used both for unicast connections and for multicast communication on the Internet. The RealTime Control Protocol (RTCP) works together with RTP and is used to negotiate and maintain Quality-of-Service parameters (QoS).
- Synchronization Source
- The data source is called the Synchronization Source (SSRC) and is identified by an identifier (32 bits) in the header.
- A translator forwards incoming RTP packets, leaving the SSRC identifier intact. Translators can leave the data unchanged and are used, for example, to overcome firewalls . However, you can also change the coding of the transmitted data; the fields Payload Type and Timestamp must be adapted in the header . The recoding is done transparently for the recipient.
- Mixers combine the data streams from several sources into a new data stream and forward it. The coding can also be changed. Since the data streams from the sources to be combined are not necessarily synchronized, the mixer must generate its own timing for the combined stream. For this reason, the mixer enters its own SSRC ID in the corresponding field for all outgoing packets. In order to preserve the identity of the original sources, their SSRC identifiers are entered in the list of CSRC identifiers.
- The recipient of the RTP packets sorts them using the sequence numbers and makes them available to the respective application.
- RTP packet
- An RTP packet consists of a header with version and sequence number, data format, sender ID and time stamp and the user data part.
|Byte 0||Byte 1||Byte 2||Byte 3|
|Bit 0||1||2||3||4th||5||6th||7th||Bit 0||1||2||3||4th||5||6th||7th||Bit 0||1||2||3||4th||5||6th||7th||Bit 0||1||2||3||4th||5||6th||7th|
|V = 2||P||X||CC||M.||PT||Sequence Number|
|Timestamp (in sample rate units)|
|Synchronization Source (SSRC) identifier|
|Contributing Source (CSRC) identifiers (optional)|
|Header Extension (optional)|
- Version (V), 2 bit
- Version status of the RTP protocol
- Padding (P), 1 bit
- The filling bit is set if one or more filling bytes are appended to the end of the packet that do not belong to the actual data content (payload). The last filler byte indicates the number of filler bytes added. Padding bytes are only required if subsequent protocols require a specified block size, e.g. B. Encryption Algorithms.
- Extension (X), 1 bit
- The extension bit is set if the header is supplemented by exactly one extension header.
- CSRC Count (CC), 4 bit
- The CSRC counter indicates the number of CSRC identifiers.
- Marker (M), 1 bit
- The marker bit is reserved for application-specific uses. It is used to identify events, e.g. B. the occurrence of the end of a frame of a video sequence.
- Payload Type (PT), 7 bit
- This field describes the format of the RTP content to be transported, i.e. the user data (payload).
|Payload No.||Codec||Audio / video||sampling rate||Audio channels||RFC|
|14th||MPA||A.||90 kHz||1||[RFC3551, RFC2250]|
|25th||CelB||V||90 kHz||[RFC3551, RFC2029]|
|26th||JPEG||V||90 kHz||[RFC3551, RFC2435]|
|31||H.261||V||90 kHz||[RFC3551, RFC2032]|
- Sequence number, 16 bit
- The sequence number is increased for each additional RTP data packet. The start number is chosen randomly and cannot be determined in advance. The recipient can use the sequence number to restore the order of the packets and recognize the loss of packets.
- Timestamp, 32 bit
- The time stamp indicates the time of the first byte of the RTP data packet. The point in time must be based on a clock that is continuous and linear, so that the synchronicity of the stream can be ensured and runtime differences in the transmission path (jitter) can be determined. Like the sequence number, the start value should be a random value. Successive packets can have the same time stamp if the transported data is e.g. B. belong to the same single image ("video frame"). Packets with consecutive sequence numbers can also contain non-consecutive time stamps if, for example, B. in the case of compressed video, the order of transmission and playback do not match.
- SSRC, 32 bit
- This field is used to identify the synchronization source. The value is determined randomly so that two sources within the RTP session do not have the same identification number.
- CSRC List, 0 to 15 fields each 32 bit
- The CSRC list is used to identify the sources that are contained in the RTP user data. The number of list fields is specified in the CC field. If there are more than 15 sources, only 15 are identified. The list is inserted by mixers that use the content of the SSRC field of the sources involved.
- Ulrich Trick, Frank Weber: SIP, TCP / IP and telecommunications networks. 2nd edition, Oldenbourg, 2005, ISBN 978-3-486-57796-9 .
Norms and standards
- RFC 1889 - RTP: A Transport Protocol for Real-Time Applications [1996, obsolete]
RFC 3550 - RTP: A Transport Protocol for Real-Time Applications [2003, current]
- Addition RFC 5506 - Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences [2009, current]
- Addition RFC 5761 - Multiplexing RTP Data and Control Packets on a Single Port [2010, current]
- Addition RFC 6051 - Rapid Synchronization of RTP Flows [2010, current]
- Supplement to RFC 7022 - Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [2013, current]
- Addition RFC 7160 - Support for Multiple Clock Rates in an RTP Session [2014, current]
- Addition RFC 7164 - RTP and Leap Seconds [2014, current]
- Addition RFC 8083 - Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions [2017, current]
- RFC 1890 - RTP Profile for Audio and Video Conferences with Minimal Control [1996, obsolete]
RFC 3551 - RTP Profile for Audio and Video Conferences with Minimal Control [2003, current]
- Addition RFC 7007 - Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP / AVP) [2013, current]
- RTP Control Data Profile (RTP / CDP) for machine-to-machine applications