- File formats:
- INTERNET STANDARD (changed from DRAFT STANDARD)
- RFC 1889
- Updated by:
- RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860
- H. Schulzrinne
- avt (rai)
Cite this RFC: TXT | XML | BibTeX
Discuss this RFC: Send questions or comments to the mailing list email@example.com
Other actions: View Errata | Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 3550
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]
For the definition of Status, see RFC 2026.
For the definition of Stream, see RFC 8729.