Real-time Transport Protocol
The Real-time Transport Protocol is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.
RTP typically runs over User Datagram Protocol. RTP is used in conjunction with the RTP Control Protocol. While RTP carries the media streams, RTCP is used to monitor transmission statistics and quality of service and aids synchronization of multiple streams. RTP is one of the technical foundations of Voice over IP and in this context is often used in conjunction with a signaling protocol such as the Session Initiation Protocol which establishes connections across the network.
RTP was developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force and first published in 1996 as which was then superseded by in 2003.
Overview
RTP is designed for end-to-end, real-time transfer of streaming media. The protocol provides facilities for jitter compensation and detection of packet loss and out-of-order delivery, which are common especially during UDP transmissions on an IP network. RTP allows data transfer to multiple destinations through IP multicast. RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format. The design of RTP is based on the architectural principle known as application-layer framing where protocol functions are implemented in the application as opposed to in the operating system's protocol stack.Real-time multimedia streaming applications require timely delivery of information and often can tolerate some packet loss to achieve this goal. For example, loss of a packet in audio application may result in loss of a fraction of a second of audio data, which can be made unnoticeable with suitable error concealment algorithms. The Transmission Control Protocol, although standardized for RTP use, is not normally used in RTP applications because TCP favors reliability over timeliness. Instead the majority of the RTP implementations are built on the User Datagram Protocol. Other transport protocols specifically designed for multimedia sessions are SCTP and DCCP, although,, they are not in widespread use.
RTP was developed by the Audio/Video Transport working group of the IETF standards organization. RTP is used in conjunction with other protocols such as H.323 and RTSP. The RTP specification describes two protocols: RTP and RTCP. RTP is used for the transfer of multimedia data, and the RTCP is used to periodically send control information and QoS parameters.
The data transfer protocol, RTP, carries real-time data. Information provided by this protocol includes timestamps, sequence numbers and the payload format which indicates the encoded format of the data. The control protocol, RTCP, is used for quality of service feedback and synchronization between the media streams. The bandwidth of RTCP traffic compared to RTP is small, typically around 5%.
RTP sessions are typically initiated between communicating peers using a signaling protocol, such as H.323, the Session Initiation Protocol, RTSP, or Jingle. These protocols may use the Session Description Protocol to specify the parameters for the sessions.
An RTP session is established for each multimedia stream. Audio and video streams may use separate RTP sessions, enabling a receiver to selectively receive components of a particular stream. The specification recommends that RTP port numbers be chosen to be even and that each associated RTCP port be the next higher odd number. However, a single port is chosen for RTP and RTCP in applications that multiplex the protocols. RTP and RTCP typically use unprivileged UDP ports, but may also use other transport protocols, most notably, SCTP and DCCP, as the protocol design is transport independent.
RTP is used by real-time multimedia applications such as voice over IP, audio over IP, WebRTC and Internet Protocol television
Profiles and payload formats
One of the design considerations for RTP is to carry a range of multimedia formats and allow new formats without revising the RTP standard. To this end, the information required by a specific application of the protocol is not included in the generic RTP header but is instead provided through separate RTP profiles and associated payload formats. For each class of application, RTP defines a profile and one or more associated payload formats. A complete specification of RTP for a particular application usage requires profile and payload format specifications.The profile defines the codecs used to encode the payload data and their mapping to payload format codes in the Payload Type field of the RTP header. Each profile is accompanied by several payload format specifications, each of which describes the transport of a particular encoded data. The audio payload formats include G.711, G.723, G.726, G.729, GSM, QCELP, MP3, and DTMF, and the video payload formats include H.261, H.263, H.264, H.265 and MPEG-1/MPEG-2. The mapping of MPEG-4 audio/video streams to RTP packets is specified in, and H.263 video payloads are described in.
Examples of RTP profiles include:
- The RTP profile for Audio and video conferences with minimal control defines a set of static payload type assignments, and a dynamic mechanism for mapping between a payload format, and a PT value using Session Description Protocol.
- The Secure Real-time Transport Protocol defines an RTP profile that provides cryptographic services for the transfer of payload data.
- The experimental Control Data Profile for RTP for machine-to-machine communications.
Packet header
The RTP header has a minimum size of 12 bytes. After the header, optional header extensions may be present. This is followed by the RTP payload, the format of which is determined by the particular class of application. The fields in the header are as follows:
- Version: Indicates the version of the protocol. Current version is 2.
- P : Used to indicate if there are extra padding bytes at the end of the RTP packet. Padding may be used to fill up a block of certain size, for example as required by an encryption algorithm. The last byte of the padding contains the number of padding bytes that were added.
- X : Indicates presence of an extension header between the header and payload data. The extension header is application or profile specific.
- CC : Contains the number of CSRC identifiers that follow the SSRC.
- M : Signaling used at the application level in a profile-specific manner. If it is set, it means that the current data has some special relevance for the application.
- PT : Indicates the format of the payload and thus determines its interpretation by the application. Values are profile specific and may be dynamically assigned.
- Sequence number: The sequence number is incremented for each RTP data packet sent and is to be used by the receiver to detect packet loss and to accommodate out-of-order delivery. The initial value of the sequence number should be randomized to make known-plaintext attacks on Secure Real-time Transport Protocol more difficult.
- Timestamp: Used by the receiver to play back the received samples at appropriate time and interval. When several media streams are present, the timestamps may be independent in each stream. The granularity of the timing is application specific. For example, an audio application that samples data once every 125 µs would use that value as its clock resolution. Video streams typically use a 90 kHz clock. The clock granularity is one of the details that is specified in the RTP profile for an application.
- SSRC: Synchronization source identifier uniquely identifies the source of a stream. The synchronization sources within the same RTP session will be unique.
- CSRC: Contributing source IDs enumerate contributing sources to a stream which has been generated from multiple sources.
- Header extension: The first 32-bit word contains a profile-specific identifier and a length specifier that indicates the length of the extension in 32-bit units, excluding the 32 bits of the extension header. The extension header data follows.
System operation
An RTP sender captures the multimedia data, then encodes, frames and transmits it as RTP packets with appropriate timestamps and increasing timestamps and sequence numbers. The sender sets the payload type field in accordance with connection negotiation and the RTP profile in use. The RTP receiver detects missing packets and may reorder packets. It decodes the media data in the packets according to the payload type and presents the stream to its user.
Standards documents
- , Standard 64, RTP: A Transport Protocol for Real-Time Applications
- , Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
- , Media Type Registration of RTP Payload Formats
- , Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences
- , A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol Sources
- , RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio
- , RTP Payload Format for H.264 Video
- , RTP Payload Format for Transport of MPEG-4 Elementary Streams
- , RTP Payload Format for MPEG-4 Audio/Visual Streams
- , RTP Payload Format for MPEG1/MPEG2 Video
- , RTP Payload Format for Uncompressed Video
- , RTP Payload Format for MIDI
- , An Implementation Guide for RTP MIDI
- , RTP Payload Format for the Opus Speech and Audio Codec
- , RTP Payload Format for High Efficiency Video Coding