RTP: A Transport Protocol for Real-Time Applications
obsoletes
- rfc-1889 — RTP: A Transport Protocol for Real-Time Applications
updated by
- rfc-5506 — Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences
- rfc-5761 — Multiplexing RTP Data and Control Packets on a Single Port
- rfc-6051 — Rapid Synchronisation of RTP Flows
- rfc-6222 — Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
- rfc-7022 — Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
- rfc-7160 — Support for Multiple Clock Rates in an RTP Session
- rfc-7164 — RTP and Leap Seconds
- rfc-8083 — Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
- rfc-8108 — Sending Multiple RTP Streams in a Single RTP Session
- rfc-8860 — Sending Multiple Types of Media in a Single RTP Session
also
- std-64
Extracted elements (30)
NTP 64-bit timestamps are carried in RTCP SR packets rather than RTP data packets because inter-media synchronization requires infrequent wallclock correlation, not per-packet overhead. RTP timestamps are media-clock-relative and advance at different rates per medium; SR's NTP/RTP timestamp pairs provide the cross-media mapping at lower bandwidth cost.
RTP follows the Application Level Framing (ALF) principle: the protocol is deliberately incomplete and intended to be tailored by profile and payload format specifications rather than providing general-purpose option parsing. This allows application-specific optimizations without burdening all implementations with unused complexity.
The RTCP timer reconsideration algorithm backs off RTCP transmission when group membership is growing rapidly (e.g., many simultaneous joins), preventing momentary RTCP bandwidth bursts. The complementary reverse reconsideration algorithm accelerates transmission when membership shrinks, enabling faster adaptation.
All RTP and RTCP integer fields are in network byte order (big-endian). All header fields are aligned to their natural length (16-bit fields on even offsets, 32-bit fields at 4-byte boundaries). Implementations must observe these alignment requirements for correct interoperation across architectures.
RTP version 2 (V=2) is the current version; V=1 was the first draft and V=0 was used by the 'vat' audio tool. There are no wire-format changes between RFC 1889 and RFC 3550; only the RTCP transmission interval algorithm and related rules were updated.
A receiver MUST ignore RTP packets with payload types it does not understand. The payload type field SHOULD NOT be used for multiplexing separate media streams.
All RTP implementations MUST be prepared to detect and resolve SSRC collisions. If a source changes its transport address, it MUST choose a new SSRC identifier to avoid being misidentified as a forwarding loop.
An SDES packet containing a CNAME item MUST be included in every compound RTCP packet, except when the compound packet is split for partial encryption. This is required so new receivers quickly learn the canonical name of each source.
Every compound RTCP packet MUST begin with an SR or RR report packet to enable header validation. Even if no data has been sent or received, an empty RR MUST be sent as the first packet of the compound.
In a multimedia conference, each medium SHOULD be carried in a separate RTP session with its own destination transport address. Separate media streams SHOULD NOT be multiplexed within one RTP session using PT or SSRC as demultiplexing keys, because RTCP reports cannot distinguish them and mixer combination becomes impossible.
RTCP bandwidth is RECOMMENDED to be fixed at 5% of session bandwidth, with 1/4 of that allocated to senders and 3/4 to receivers. All participants MUST use the same session bandwidth value so all compute the same RTCP transmission interval.
The initial RTP sequence number SHOULD be random to harden against known-plaintext attacks on encryption, even if the local source does not encrypt, because packets may traverse a translator that does.
The RTP timestamp MUST be derived from a clock that increments monotonically and linearly in time. The clock resolution MUST be sufficient for synchronization accuracy and jitter measurement. The initial timestamp SHOULD be random.
When a participant with more than 50 current members decides to leave, it MUST apply the BYE back-off algorithm: reinitialize state, compute a BYE transmission interval based on observed BYE traffic, and schedule BYE transmission accordingly, to prevent bandwidth floods when many participants depart simultaneously.
A Contributing Source (CSRC) list (0–15 entries, 32 bits each) is inserted by an RTP mixer into the packet header to identify the original SSRCs whose streams were combined. This enables correct talker indication at receivers even though all mixed packets carry the mixer's SSRC.
A Mixer is an intermediate RTP node that receives packets from one or more sources, possibly transcodes, combines them into a new stream with its own SSRC, and adjusts timing. A Translator forwards packets with their original SSRC intact, performing address translation or encoding conversion without resynchronization.
A Synchronization Source (SSRC) is a randomly chosen 32-bit identifier carried in every RTP packet header that uniquely identifies an RTP stream within a session. All packets from one SSRC share a single timing and sequence number space. If a participant generates multiple streams in one session, each MUST use a different SSRC.
RTCP defines five core packet types: SR (Sender Report, type 200), RR (Receiver Report, type 201), SDES (Source Description, type 202), BYE (Goodbye, type 203), and APP (Application-defined, type 204). Each begins with a fixed header similar to RTP and MUST end on a 32-bit boundary.
The RTCP CNAME (Canonical End-Point Identifier) is a persistent, globally unique identifier for each RTP participant carried in SDES packets. It allows receivers to track participants across SSRC changes, associate multiple streams from the same endpoint, and perform inter-media (lip-sync) synchronization using NTP/RTP timestamp pairs from SR packets.
The RTCP Sender Report (SR) is sent by active data senders and conveys a 64-bit NTP wallclock timestamp, a 32-bit RTP timestamp, a 32-bit cumulative sender packet count, and a 32-bit cumulative octet count, followed by up to 31 reception report blocks (one per source).
RTCP packet types are registered with IANA. Values defined in this document: SR=200, RR=201, SDES=202, BYE=203, APP=204. Implementations SHOULD ignore RTCP packets with unknown types. Additional types may be registered with IANA.
RTCP SDES item types are registered with IANA. Values defined in this document: END=0, CNAME=1, NAME=2, EMAIL=3, PHONE=4, LOC=5, TOOL=6, NOTE=7, PRIV=8. Additional SDES types may be registered with IANA.
RTP applications MUST implement congestion control because UDP has none. Since RTP data rates can be high and multicast can affect many paths simultaneously, unconstrained senders risk congestion collapse. The RTCP feedback loop is integral to detecting and adapting to congestion.
RTP confidentiality is provided by encrypting the payload and RTCP fields using an external mechanism. When a compound RTCP packet is encrypted, it MUST be prefixed by a random 32-bit quantity redrawn per packet to prevent replays. Partial encryption (excluding the SDES CNAME) is permitted.
RTP provides no built-in authentication or message integrity; these are expected from profile-defined mechanisms or companion protocols (e.g., SRTP). Random initial sequence numbers and SSRCs offer weak protection against off-path injection but are insufficient against on-path attackers.
SSRC collision resolution: upon detecting that own SSRC is in use by a different source transport address, the participant sends RTCP BYE for the old SSRC (unless it has not yet sent data) and selects a new SSRC. Loop detection uses the same mechanism: receiving own RTP packets from an unexpected address signals a forwarding loop.
The RTCP transmission state machine tracks: tp (last transmission time), tc (current time), tn (next scheduled transmission), pmembers/members (group size), senders, rtcp_bw, we_sent, avg_rtcp_size, and initial. Transitions: on timer expiry (compute interval, conditionally transmit); on receiving RTP/RTCP (update tables, apply timer reconsideration); on receiving BYE (remove SSRC, apply reverse reconsideration to accelerate next transmission).
A compound RTCP packet is formed by concatenating individual RTCP packets (each ending on a 32-bit boundary) into a single UDP datagram. If encrypted, a random 32-bit prefix is prepended. The compound packet must begin with SR or RR, followed by SDES (with CNAME), then optionally BYE or APP in any order.
The RTP fixed header is 12 octets: V (2 bits, version=2), P (1 bit, padding), X (1 bit, extension present), CC (4 bits, CSRC count), M (1 bit, marker), PT (7 bits, payload type), sequence number (16 bits), timestamp (32 bits), SSRC (32 bits). Optionally followed by 0–15 CSRC identifiers (32 bits each).
When the X bit is set, a header extension MUST immediately follow the CSRC list. It begins with a 16-bit profile-defined identifier and a 16-bit length field counting 32-bit words in the extension body (zero is valid, header not counted). Only one extension may be appended per packet.