Real-Time Transport Protocol

from Wikipedia, the free encyclopedia
RTP (Real-Time Transport Protocol)
Family: Network protocol
Operation area: Transport of media streams
Port: any free, even port greater than 1024
RTP in the TCP / IP protocol stack :
application RTP
transport UDP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus 		Token
ring 		FDDI ...
Default: 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).

It is used in many areas, including a. it is used with the IP telephony standards H.323 and SIP to transmit the audio and video streams of the call.

The main function of RTP is to transmit data streams that require real-time , while the Real-Time Streaming Protocol (RTSP) is used to control and monitor data transmission.

The Datagram Congestion Control Protocol (DCCP) is a current approach to enable congestion control for media streams based on RTP / UDP.

architecture

Synchronization Source
The data source is called the Synchronization Source (SSRC) and is identified by an identifier (32 bits) in the header.
Translator
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.
mixer
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.
receiver
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.

RTP header

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
0 PCMU A. 8 kHz 1 [RFC3551]
3 GSM A. 8 kHz 1 [RFC3551]
4th G723 A. 8 kHz 1 [RFC3551]
5 DVI4 A. 8 kHz 1 [RFC3551]
6th DVI4 A. 16 kHz 1 [RFC3551]
7th LPC A. 8 kHz 1 [RFC3551]
8th PCMA A. 8 kHz 1 [RFC3551]
9 G.722 A. 8 kHz 1 [RFC3551]
10 L16 A. 44.1 kHz 2 [RFC3551]
11 L16 A. 44.1 kHz 1 [RFC3551]
12 QCELP A. 8 kHz 1 [RFC3551]
13 CN A. 8 kHz 1 [RFC3389]
14th MPA A. 90 kHz 1 [RFC3551, RFC2250]
15th G.728 A. 8 kHz 1 [RFC3551]
16 DVI4 A. 11.025 kHz 1
17th DVI4 A. 22.05 kHz 1
18th G.729 A. 8 kHz 1 [RFC3551]
25th CelB V 90 kHz [RFC3551, RFC2029]
26th JPEG V 90 kHz [RFC3551, RFC2435]
28 nv V 90 kHz [RFC3551]
31 H.261 V 90 kHz [RFC3551, RFC2032]
32 MPV V 90 kHz [RFC3551,2250]
33 MP2T AV 90 kHz [RFC3551,2250]
34 H.263 V 90 kHz [RFC3551,2250]
96-127 dynamic [RFC3551]
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.

literature

  • Ulrich Trick, Frank Weber: SIP, TCP / IP and telecommunications networks. 2nd edition, Oldenbourg, 2005, ISBN 978-3-486-57796-9 .

Norms and standards

Main line:

  • 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]

Branch line:

  • 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]

Web links

Individual evidence

  1. ↑ Finley Breese: Serial Communication over RTP / CDP . BoD - Books on Demand, 2010, ISBN 9783839184608 , p.  [1] .