Editing Real-time Transport Protocol

{{short description|Protocol for delivering audio and video over IP networks}}

{{Infobox networking protocol
| title        = Real-time Transport Protocol
| logo         = 
| logo alt     = 
| image        = 
| image alt    = 
| caption      = 
| is stack     = No 
| abbreviation = RTP
| purpose      = Delivering audio and video
| developer    = Audio-Video Transport Working Group of the [[IETF]]
| date         = {{Start date and age|1996|01}}
| based on     = [[Network Voice Protocol]]{{sfn|Perkins|2003|p=6}}
| influenced   = 
| osilayer     = 
| ports        =
| rfcs         = {{IETF RFC|1889|3550|3551}}
| hardware     = 
}}
{{IPstack}}

The '''Real-time Transport Protocol''' ('''RTP''') 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]], [[IPTV|television services]] and web-based [[push-to-talk]] features.

RTP typically runs over [[User Datagram Protocol]] (UDP).   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 establishes 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 {{IETF RFC|1889}} which was then superseded by {{IETF RFC|3550}} in 2003.<ref>{{Cite web |last=Wright |first=Gavin |title=What is the Real-time Transport Protocol (RTP)? |url=https://www.techtarget.com/searchnetworking/definition/Real-Time-Transport-Protocol |access-date=2022-11-10 |website=TechTarget |language=en}}</ref>

==Overview==
Research on audio and video over packet-switched networks dates back to the early 1970s. The [[Internet Engineering Task Force]] (IETF) published {{IETF RFC|741}} in 1977 and began developing RTP in 1992,{{sfn|Perkins|2003|p=6}} and would go on to develop [[Session Announcement Protocol]] (SAP), the [[Session Description Protocol]] (SDP), and the [[Session Initiation Protocol]] (SIP).

RTP is designed for [[End-to-end principle|end-to-end]], [[real-time computing|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]].<ref name="Hardy_298">{{Cite book| author=Daniel Hardy | title=Network | page= [https://books.google.com/books?id=Oq8SEUW1wdQC&pg=PT320 298] | publisher= De Boeck Université | year= 2002}}</ref> RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.<ref name="Perkins_55" />{{update inline|reason=Need a more recent source to verify continued importance|date=February 2025}} 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 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 an 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.<ref name="Perkins_46">{{harvnb|Perkins|2003|p=46}}</ref> The [[Transmission Control Protocol]] (TCP), although standardized for RTP use,{{Ref RFC|4571}} 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).<ref name="Perkins_46"/> Other transport protocols specifically designed for multimedia sessions are [[SCTP]]<ref>{{Cite book|last=Farrel|first=Adrian |title=The Internet and its protocols|publisher=Morgan Kaufmann|year=2004|page=363|url=https://books.google.com/books?id=LtBegQowqFsC&q=rtp+sctp&pg=PA363|isbn=978-1-55860-913-6}}</ref> and [[DCCP]],<ref>{{Cite book|last=Ozaktas|first=Haldun M.|author2=Levent Onural |title=THREE-DIMENSIONAL TELEVISION|publisher=Springer|year=2007|page=356|url=https://books.google.com/books?id=kQvCHpuXji8C&q=rtp+dccp&pg=PA356|isbn=978-3-540-72531-2}}</ref> although, {{As of|2012|lc=on}}, they were not in widespread use.<ref>{{Cite news|url=http://www.networkworld.com/article/2222277/cisco-subnet/what-about-stream-control-transmission-protocol--sctp--.html|archive-url=https://web.archive.org/web/20140830095541/http://www.networkworld.com/article/2222277/cisco-subnet/what-about-stream-control-transmission-protocol--sctp--.html|url-status=dead|archive-date=August 30, 2014|title=What About Stream Control Transmission Protocol (SCTP)?|last=Hogg|first=Scott|newspaper=Network World|access-date=2017-10-04}}</ref>

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]].<ref name="Perkins_55">{{harvnb|Perkins|2003|p=55}}</ref> 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.<ref name="Peterson_430"/>

The data transfer protocol, RTP, carries real-time data. Information provided by this protocol includes timestamps (for synchronization), sequence numbers (for packet loss and reordering detection) and the payload format which indicates the encoded format of the data.<ref name="Colins_56">{{harvnb|Perkins|2003|p=56}}</ref> The control protocol, RTCP, is used for quality of service (QoS) feedback and synchronization between the media streams. The bandwidth of RTCP traffic compared to RTP is small, typically around 5%.<ref name="Colins_56"/><ref>{{harvnb|Peterson|Davie|2007|p=435}}</ref>

RTP sessions are typically initiated between communicating peers using a signaling protocol, such as H.323, the [[Session Initiation Protocol]] (SIP), RTSP, or [[Jingle (protocol)|Jingle]] ([[XMPP]]). These protocols may use the [[Session Description Protocol]] to specify the parameters for the sessions.{{Ref RFC|8866}}

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.<ref name="Zurawski_28">{{Cite book|last=Zurawski|first=Richard|title=The industrial information technology handbook|publisher=CRC Press|year=2004|pages=[https://books.google.com/books?id=MwMDUBKZ3wwC&pg=PT225&dq=RTP+session 28–7]|chapter=RTP, RTCP and RTSP protocols|chapter-url=https://books.google.com/books?id=MwMDUBKZ3wwC|isbn=978-0-8493-1985-3}}</ref> The RTP and RTCP design is independent of the transport protocol. Applications most typically use UDP with port numbers in the unprivileged range (1024 to 65535).<ref name="Collins_47">{{Cite book|last=Collins|first=Daniel|title=Carrier grade voice over IP|publisher=McGraw-Hill Professional|year=2002|pages=[https://books.google.com/books?id=PVIuN9Y5FGMC&pg=PA47&dq=RTP+session 47]|chapter=Transporting Voice by using IP|isbn=978-0-07-136326-6}}</ref> The [[Stream Control Transmission Protocol]] (SCTP) and the [[Datagram Congestion Control Protocol]] (DCCP) may be used when a reliable transport protocol is desired. The RTP specification recommends even port numbers for RTP and the use of the next odd port number for the associated RTCP session.{{Ref RFC|3550|rp=68}} A single port can be used for RTP and RTCP in applications that multiplex the protocols.{{Ref RFC|5761}}

RTP is used by real-time multimedia applications such as [[voice over IP]], [[audio over IP]], [[WebRTC]],  [[Internet Protocol television]], and [[professional video over IP]] including [[SMPTE 2022]] and [[SMPTE 2110]].

==Profiles and payload formats==
{{main|RTP payload formats}}

RTP is designed to carry a multitude of multimedia formats, which permits the development of 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. For each class of application (e.g., audio, video), RTP defines a ''profile'' and associated ''payload formats''.<ref name="Peterson_430">{{Cite book| author=Larry L. Peterson | title=Computer Networks | page= [https://books.google.com/books?id=zGVVuO-6w3IC&pg=PA430 430] | publisher=Morgan Kaufmann | year=2007 | isbn=978-1-55860-832-0}}</ref> Every instantiation of RTP in a particular application requires a profile and payload format specifications.<ref name=RFC3550>{{IETF RFC|3550}}</ref>{{rp|71}}

The profile defines the codecs used to encode the payload data and their mapping to payload format codes in the protocol field ''Payload Type'' (PT) of the RTP header. Each profile is accompanied by several payload format specifications, each of which describes the transport of particular encoded data.<ref name="Perkins_55"/> Examples of audio payload formats are [[G.711]], [[G.723]], [[G.726]], [[G.729]], [[GSM]], [[QCELP]], [[MP3]], and [[DTMF]], and examples of video payloads are [[H.261]], [[H.263]], [[H.264]], [[H.265]] and [[MPEG-1]]/[[MPEG-2]].<ref name="perkins_60">{{harvnb|Perkins|2003|p=60}}</ref> The mapping of [[MPEG-4]] audio/video streams to RTP packets is specified in {{IETF RFC|3016}}, and H.263 video payloads are described in {{IETF RFC|2429}}.<ref name=Chou2007>{{Cite book|last=Chou|first=Philip A. |author2=Mihaela van der Schaar |title=Multimedia over IP and wireless networks|publisher=Academic Press|year=2007|pages=[https://books.google.com/books?id=zeLFs3GD0QQC&pg=PA514 514]|isbn=978-0-12-088480-3}}</ref>

Examples of RTP profiles include:
* The ''RTP profile for Audio and video conferences with minimal control'' ({{IETF RFC|3551}}) 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]] (SDP).
* The [[Secure Real-time Transport Protocol]] (SRTP) ({{IETF RFC|3711}}) defines an RTP profile that provides [[cryptographic]] services for the transfer of payload data.<ref>{{harvnb|Perkins|2003|p=367}}</ref>
* The experimental ''Control Data Profile for RTP'' (RTP/CDP) for [[machine-to-machine]] communications.<ref name=Breese2010>{{Cite book|last=Breese|first=Finley|title=Serial Communication over RTP/CDP|publisher=BoD - Books on Demand|year=2010|pages=[https://books.google.com/books?id=t18ehd_vM6wC&lpg=PP1&pg=PA9]|isbn=978-3-8391-8460-8}}</ref>

==Packet header==
RTP packets are created at the application layer and handed to the transport layer for delivery. Each unit of RTP media data created by an application begins with the RTP packet header.
{{APHD|start|title=RTP packet header}}
{{APHD|0|bits1=2|bits4=4|bits6=7|bits7=16|field1=Version|field2=P|field3=X|field4=CC|field5=M|field6=PT|field7=Sequence Number}}
{{APHD|4|bits1=32|field1=Timestamp}}
{{APHD|8|bits1=32|field1=SSRC Identifier}}
{{APHD|12|bits1=32|background1=linen|border1=bottom|field1=CSRC Identifier(s)}}
{{APHD|999|bits1=32|background1=linen|border1=top|field1=&vellip;}}
{{APHD|999|hoctets=12+4&times;CC|hbits=96+32&times;CC|bits1=16|bits2=16|background1=linen|background2=linen|field1=Profile-specific Extension Header ID|field2=Extension Header Length}}
{{APHD|999|hoctets=16+4&times;CC|hbits=128+32&times;CC|bits1=32|background1=linen|field1=Extension Data}}
{{APHD|999|bits1=32|background1=linen|border1=top|field1=&vellip;}}
{{APHD|end}}

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.<ref>{{harvnb|Peterson|Davie|2007|p=430}}</ref> The fields in the header are as follows:
;{{APHD|def|name=Version|length=2 bits|text=Indicates the version of the protocol. Current version is 2.<ref name="peterson_431">{{harvnb|Peterson|Davie|2007|p=431}}</ref>}}
;{{APHD|def|name=Padding|short=P|length=1 bit|text=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 (including itself).{{Ref RFC|3550|rp=12}}<ref name="peterson_431"/>}}
;{{APHD|def|name=Extension|short=X|length=1 bit|text=Indicates presence of an ''Extension Header'' between the header and payload data. The extension header is application or profile specific.<ref name="peterson_431"/>}}
;{{APHD|def|name=CSRC Count|short=CC|length=4 bits|text=Contains the number of CSRC identifiers (defined below) that follow the SSRC (also defined below).{{Ref RFC|3550|rp=12}}}}
;{{APHD|def|name=Marker|short=M|length=1 bit|text=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.{{Ref RFC|3550|rp=13}}}}
;{{APHD|def|name=Payload Type|short=PT|length=7 bits|text=Indicates the format of the payload and thus determines its interpretation by the application. Values are profile specific and may be dynamically assigned.<ref>{{harvnb|Perkins|2003|p=59}}</ref>}}
;{{APHD|def|name=Sequence Number|length=16 bits|text=The sequence number is incremented for each RTP data packet sent and is to be used by the receiver to detect packet loss<ref name="Hardy_298"/> and to accommodate [[out-of-order delivery]]. The initial value of the sequence number should be randomized to make [[known-plaintext attack]]s on [[Secure Real-time Transport Protocol]] more difficult.{{Ref RFC|3550|rp=13}}}}
;{{APHD|def|name=Timestamp|length=32 bits|text=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.{{efn|{{IETF RFC|7273}} provides a means for signalling the relationship between media clocks of different streams.}} The granularity of the timing is application specific. For example, an audio application that samples data once every 125&nbsp;μs (8&nbsp;kHz, a common sample rate in digital telephony) would use that value as its clock resolution. Video streams typically use a 90&nbsp;kHz clock. The clock granularity is one of the details that is specified in the RTP profile for an application.<ref name="peterson_432">Peterson, p.[https://books.google.com/books?id=zGVVuO-6w3IC&pg=PA432 432]</ref>}}
;{{APHD|def|name=SSRC|length=32 bits|text=''Synchronization Source Identifier'' uniquely identifies the source of a stream. The synchronization sources within the same RTP session will be unique.{{Ref RFC|3550|rp=15}}}}
;{{APHD|def|name=CSRC|length=Variable (''CSRC Count'' &times; 32 bits)|text=''Contributing Source IDs'' enumerate contributing sources to a stream that has been generated from multiple sources.{{Ref RFC|3550|rp=15}}}}
;{{APHD|def|name=Header Extension|length=Variable|constraint=Exists when X=1|text=When ''Extension'' is true, this optional field contains:}}
:;{{APHD|def|name=Profile-specific Extension Header ID|length=16 bits|text=a profile-specific identifier}}
:;{{APHD|def|name=Extension Header Length|length=16 bits|text=indicates the length of the extension in 32-bit units, excluding the 32 bits of the extension header.}}
:;{{APHD|def|name=Extension Header Data|length=Variable|text=The data of the extension header.{{Ref RFC|3550|rp=18}}}}

==Application design==
A functional multimedia application requires other protocols and standards used in conjunction with RTP. Protocols such as SIP, [[Jingle (protocol)|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 for encoding the payload data as specified by the applicable RTP profile.<ref name="perkins_11">{{harvnb|Perkins|2003|pp=11–13}}</ref>

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.<ref name="perkins_11"/>

==Standards documents==
* {{Sum RFC|3550|ref=yes}}
* {{Sum RFC|3551|ref=yes}}
* {{Sum RFC|4855|ref=yes}}
* {{Sum RFC|4856|ref=yes}}
* {{Sum RFC|7656|ref=yes}}
* {{Sum RFC|3190|ref=yes}}
* {{Sum RFC|6184|ref=yes}}
* {{Sum RFC|3640|ref=yes}}
* {{Sum RFC|6416|ref=yes}}
* {{Sum RFC|2250|ref=yes}}
* {{Sum RFC|4175|ref=yes}}
* {{Sum RFC|6295|ref=yes}}
* {{Sum RFC|4696|ref=yes}}
* {{Sum RFC|7164|ref=yes}}
* {{Sum RFC|7587|ref=yes}}
* {{Sum RFC|7798|ref=yes}}

==See also==
* [[Real Data Transport]]
* [[Real Time Streaming Protocol]]
* [[ZRTP]]

==Notes==
{{Notelist}}

==References==
{{Reflist}}
{{refbegin}}
* {{Cite book |last=Perkins |first=Colin |title=RTP: Audio and Video for the Internet |publisher=Addison-Wesley |year=2003 |isbn=978-0-672-32249-5 |url=https://books.google.com/books?id=OM7YJAy9_m8C}}
* {{Cite book |last1=Peterson |first1=Larry L. |last2=Davie | first2=Bruce S. |title=Computer Networks |publisher=Morgan Kaufmann |year=2007 |edition=4 |isbn=978-0-12-374013-7}}
{{refend}}

==Further reading==
* {{Cite book |publisher=Javvin Technologies | title=Network Protocols Handbook |chapter=RTP |chapter-url=https://books.google.com/books?id=D_GrQa2ZcLwC&pg=PA144 | year=2005 | isbn=978-0-9740945-2-6}}

==External links==
* [https://www.cs.columbia.edu/~hgs/rtp Henning Schulzrinne's RTP page] (including [https://www.cs.columbia.edu/~hgs/rtp/faq.html FAQ])
* [https://www.gnu.org/software/ccrtp/ GNU ccRTP]
* [http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib JRTPLIB, a C++ RTP library]
* [http://net7mma.codeplex.com Managed Media Aggregation] {{Webarchive|url=https://web.archive.org/web/20180109033607/http://net7mma.codeplex.com/ |date=2018-01-09 }}: [[.NET Framework|.NET]] [[C Sharp (programming language)|C#]] RFC compliant implementation of RTP / RTCP written in completely managed code.
* {{Citation |publisher=Ministry of Human resources, India | title=Broadband Networks |chapter=RTP |chapter-url=https://www.youtube.com/watch?v=OaL2vVFbCG4&feature=channel_page | archive-url=https://ghostarchive.org/varchive/youtube/20211118/OaL2vVFbCG4| archive-date=2021-11-18 | url-status=live|year=2008}}{{cbignore}}

{{Digital audio and video protocols}}

{{DEFAULTSORT:Real-Time Transport Protocol}}
[[Category:Streaming]]
[[Category:Application layer protocols]]
[[Category:VoIP protocols]]
[[Category:Audio network protocols]]