World Library  
Flag as Inappropriate
Email this Article

Real-time Transport Protocol

Article Id: WHEBN0000026163
Reproduction Date:

Title: Real-time Transport Protocol  
Author: World Heritage Encyclopedia
Language: English
Subject: GPAC Project on Advanced Content, Real Time Streaming Protocol, Session Initiation Protocol, H.323, List of RFCs
Collection: Application Layer Protocols, Streaming, Voip Protocols, Voip Terminology & Concepts
Publisher: World Heritage Encyclopedia

Real-time Transport Protocol

The Real-time Transport Protocol (RTP, sometimes referred to as RTTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features.

RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) 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 (SIP) which assists in setting up connections across the network.

RTP was developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) and first published in 1996 as RFC 1889, superseded by RFC 3550 in 2003.


  • Overview 1
    • Protocol components 1.1
    • Sessions 1.2
  • Profiles and Payload formats 2
  • Packet header 3
  • RTP-based systems 4
  • RFC references 5
  • See also 6
  • Notes 7
  • References 8
  • External links 9


RTP is designed for end-to-end, real-time, transfer of stream data. The protocol provides facilities for jitter compensation and detection of out of sequence arrival in data, which are common during transmissions on an IP network. RTP allows data transfer to multiple destinations through IP multicast.[1] RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.[2]

Real-time multimedia streaming applications require timely delivery of information and 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.[3] The Transmission Control Protocol (TCP), although standardized for RTP use,[4] 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 (UDP).[3] Other transport protocols specifically designed for multimedia sessions are SCTP[5] and DCCP, although, as of 2010, they are not in widespread use.[6]

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.[2] The RTP standard defines a pair of protocols, RTP and RTCP. RTP is used for transfer of multimedia data, and the RTCP is used to periodically send control information and QoS parameters.[7]

Protocol components

The RTP specification describes two sub-protocols:

  • The data transfer protocol, RTP, which deals with the transfer of real-time data. Information provided by this protocol include timestamps (for synchronization), sequence numbers (for packet loss and reordering detection) and the payload format which indicates the encoded format of the data.[8]
  • The control protocol RTCP is used to specify quality of service (QoS) feedback and synchronization between the media streams. The bandwidth of RTCP traffic compared to RTP is small, typically around 5%.[8][9]
  • An optional signaling protocol such as H.323, Session Initiation Protocol (SIP), or Jingle (XMPP)
  • An optional media description protocol such as Session Description Protocol


An RTP Session is established for each multimedia stream. A session consists of an IP address with a pair of ports for RTP and RTCP. For example, audio and video streams will have separate RTP sessions, enabling a receiver to deselect a particular stream.[10] The ports which form a session are negotiated using other protocols such as RTSP (using SDP in the setup method)[11] and SIP. According to the specification, an RTP port should be even and the RTCP port is the next higher odd port number.[12]:68[1] RTP and RTCP typically use unprivileged UDP ports (1024 to 65535),[14] but may use other transport protocols (most notably, SCTP and DCCP) as well, as the protocol design is transport independent.

Profiles and Payload formats

One of the design considerations of RTP was to carry a range of multimedia formats (such as H.264, MPEG-4, MJPEG, MPEG, etc.) and allow new formats to be added without revising the RTP standard. The design of RTP is based on the architectural principle known as application level framing (ALF). The information required by a specific application's needs is not included in the generic RTP header, but is instead provided through RTP profiles and payload formats.[7] For each class of application (e.g., audio, video), RTP defines a profile and one or more associated payload formats.[7] A complete specification of RTP for a particular application usage will require a profile and payload format specification(s).[12]:71

The profile defines the codecs used to encode the payload data and their mapping to payload format codes in the Payload Type (PT) field of the RTP header (see below). Each profile is accompanied by several payload format specifications, each of which describes the transport of a particular encoded data.[2] 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,[15] H.264, and MPEG-4.[15][16]

Examples of RTP Profiles include:

  • The RTP profile for Audio and video conferences with minimal control (RFC 3551) defines a set of static payload type assignments, and a mechanism for mapping between a payload format, and a payload type identifier (in header) using Session Description Protocol (SDP).
  • The Secure Real-time Transport Protocol (SRTP) (RFC 3711) defines a profile of RTP that provides cryptographic services for the transfer of payload data.[17]
  • The experimental Control Data Profile for RTP (RTP/CDP[18]) for machine-to-machine communications.

Packet header

RTP packet header
Bit offset[2] 0-1 2 3 4-7 8 9-15 16-31
0 Version P X CC M PT Sequence Number
32 Timestamp
64 SSRC identifier
96 CSRC identifiers
96+32×CC Profile-specific extension header ID Extension header length
128+32×CC Extension 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.[19] The fields in the header are as follows:

  • Version: (2 bits) Indicates the version of the protocol. Current version is 2.[20]
  • P (Padding): (1 bit) Used to indicate if there are extra padding bytes at the end of the RTP packet. A padding might 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 (including itself).[12]:12[20]
  • X (Extension): (1 bit) Indicates presence of an Extension header between standard header and payload data. This is application or profile specific.[20]
  • CC (CSRC Count): (4 bits) Contains the number of CSRC identifiers (defined below) that follow the fixed header.[12]:12
  • M (Marker): (1 bit) Used at the application level and defined by a profile. If it is set, it means that the current data has some special relevance for the application.[12]:13
  • PT (Payload Type): (7 bits) Indicates the format of the payload and determines its interpretation by the application. This is specified by an RTP profile. For example, see RTP Profile for audio and video conferences with minimal control (RFC 3551).[21]
  • Sequence Number: (16 bits) The sequence number is incremented by one for each RTP data packet sent and is to be used by the receiver to detect packet loss and to restore packet sequence. The RTP does not specify any action on packet loss; it is left to the application to take appropriate action. For example, video applications may play the last known frame in place of the missing frame.[22] According to RFC 3550, the initial value of the sequence number should be random to make known-plaintext attacks on encryption more difficult.[12]:13 RTP provides no guarantee of delivery, but the presence of sequence numbers makes it possible to detect missing packets.[1]
  • Timestamp: (32 bits) Used to enable the receiver to play back the received samples at appropriate intervals. When several media streams are present, the timestamps are independent in each stream, and may not be relied upon for media synchronization. The granularity of the timing is application specific. For example, an audio application that samples data once every 125 µs (8 kHz, a common sample rate in digital telephony) could use that value as its clock resolution. The clock granularity is one of the details that is specified in the RTP profile for an application.[22]
  • SSRC: (32 bits) Synchronization source identifier uniquely identifies the source of a stream. The synchronization sources within the same RTP session will be unique.[12]:15
  • CSRC: (32 bits each) Contributing source IDs enumerate contributing sources to a stream which has been generated from multiple sources.[12]:15
  • Extension header: (optional) The first 32-bit word contains a profile-specific identifier (16 bits) and a length specifier (16 bits) that indicates the length of the extension (EHL=extension header length) in 32-bit units, excluding the 32 bits of the extension header.[12]:17

RTP-based systems

A complete network based system includes other protocols and standards in conjunction with RTP. Protocols such as SIP, Jingle, RTSP, H.225 and H.245 are used for session initiation, control and termination. Other standards, such as H.264, MPEG and H.263, are used to encode the payload data as specified via RTP Profile.[23]

An RTP sender captures the multimedia data, then encodes, frames and transmits it as RTP packets with appropriate timestamps and increasing sequence numbers. Depending on the RTP Profile in use, the sender may set the Payload Type field. The RTP receiver captures the RTP packets, detects missing packets, and may reorder packets. It decodes the frames according to the payload format and presents the stream to its user.[23]

RFC references

  • RFC 3550, Standard 64, RTP: A Transport Protocol for Real-Time Applications
  • RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
  • RFC 3190, RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio
  • RFC 6184, RTP Payload Format for H.264 Video
  • RFC 4103, RTP Payload Format for Text Conversation
  • RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams
  • RFC 6416, RTP Payload Format for MPEG-4 Audio/Visual Streams
  • RFC 2250, RTP Payload Format for MPEG1/MPEG2 Video
  • RFC 4175, RTP Payload Format for Uncompressed Video
  • RFC 6295, RTP Payload Format for MIDI
  • RFC 4696, An Implementation Guide for RTP MIDI

See also


  1. ^ In conformance language should designates a recommendation, not a requirement. Not all RTP applications use the recommended port convention. Some applications use an SDP attribute to indicate the RTCP port number.[13]
  2. ^ Bits are ordered most significant to least significant; bit offset 0 is the most significant bit of the first octet. Octets are transmitted in network order. Bit transmission order is medium dependent.


  1. ^ a b Daniel Hardy (2002). Network. De Boeck Université. p. 298. 
  2. ^ a b c Perkins 2003, p. 55
  3. ^ a b Perkins 2003, p. 46
  4. ^ RFC 4571
  5. ^ Farrel, Adrian (2004). The Internet and its protocols. Morgan Kaufmann. p. 363.  
  6. ^ Ozaktas, Haldun M.; Levent Onural (2007). THREE-DIMENSIONAL TELEVISION. Springer. p. 366.  
  7. ^ a b c Larry L. Peterson (2007). Computer Networks. Morgan Kaufmann. p. 430.  
  8. ^ a b Perkins 2003, p. 56
  9. ^ Peterson 2007, p. 435
  10. ^ Zurawski, Richard (2004). "RTP, RTCP and RTSP protocols". The industrial information technology handbook. CRC Press. pp. 28–7.  
  11. ^ RFC 4566: SDP: Session Description Protocol, M. Handley, V. Jacobson, C. Perkins, IETF (July 2006)
  12. ^ a b c d e f g h i RFC 3550
  13. ^ RFC 3605
  14. ^ Collins, Daniel (2002). "Transporting Voice by using IP". Carrier grade voice over IP. McGraw-Hill Professional. pp. 47.  
  15. ^ a b Chou, Philip A.; Mihaela van der Schaar (2007). Multimedia over IP and wireless networks. Academic Press. pp. 514.  
  16. ^ Perkins 2003, p. 60
  17. ^ Perkins 2003, p. 367
  18. ^ Breese, Finley (2010). Serial Communication over RTP/CDP. BoD - Books on Demand. pp. [1].  
  19. ^ Peterson 2007, p. 430
  20. ^ a b c Peterson, p.431
  21. ^ Perkins 2003, p. 59
  22. ^ a b Peterson, p.432
  23. ^ a b Perkins 2003, pp. 11–13
  • Perkins, Colin (2003), RTP, Addison-Wesley,  
  • Peterson, Larry L.; Bruce S. Davie (2007), Computer Networks (4 ed.), Morgan Kaufmann,  
  • "RTP". Network Protocols Handbook. Javvin Technologies. 2005.  
  • "RTP". Broadband Networks. Ministry of Human resources, India. 2008. 

External links

  • oRTP, RTP library from Linphone written in C
  • Henning Schulzrinne's RTP page (including FAQ)
  • GNU ccRTP
  • JRTPLIB, a C++ RTP library
  • Managed Media Aggregation: .NET C# RFC complaint implementation of RTP / RTCP written in completely managed code.
  • RTPMobile .NET, an open source .NET RTP library
  • LScube project, providing a full streaming suite including experimental SCTP capability
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from World eBook Library are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.