RTP: A Transport Protocol for Real-Time Applications
obsoleted by
- rfc-3550 — RTP: A Transport Protocol for Real-Time Applications
Extracted elements (29)
Profile-specific sender/receiver report extensions are preferred over new RTCP packet types because extensions require fewer octets (no extra RTCP header or SSRC field) and allow faster parsing since applications always expect the extension at a fixed location after reception report blocks.
RTP follows the Application Level Framing (ALF) principle: it is deliberately incomplete and intended to be integrated into application processing rather than implemented as a separate layer. Complete specifications require companion profile and payload format documents; new common functions require a new RTP version rather than a general option mechanism.
Separate RTP sessions for separate media are required because interleaving media by payload type would require different timing and sequence number spaces per SSRC, would prevent RTCP from describing both streams, would prevent mixers from combining incompatible streams, and would preclude selective reception or per-medium path allocation.
The marker bit and payload type field are placed in the RTP fixed header rather than a profile extension because most applications need them and would otherwise require an extra 32-bit word. Profiles may redefine the octet but any marker bit should remain in the most significant position so profile-independent monitors can observe packet-loss correlation.
The 2-bit version field (V) in the RTP fixed header identifies this specification as version 2. Version 1 was used in the first RTP draft; version 0 was used by the 'vat' audio tool. Audio/video streams using different media types must use different RTP sessions and cannot be associated at the RTP level, only via matching CNAME in RTCP.
All participants in a session must use the same constant values (including the 5% RTCP bandwidth fraction) so that every participant independently calculates the same RTCP transmission interval; these constants should be fixed for a particular profile.
All RTCP packets must be sent in a compound packet of at least two individual packets. The first RTCP packet in the compound must always be a report packet (SR or RR) to facilitate header validation—even when no data has been sent or received, in which case an empty RR is sent.
All RTP implementations must be prepared to detect and resolve SSRC identifier collisions. If a source changes its source transport address, it must also choose a new SSRC identifier to avoid being interpreted as a looped source.
An SDES packet containing a CNAME item must be included in each compound RTCP packet so that receivers can identify the source and begin associating media for lip-sync as soon as possible.
Each medium in a multimedia session should be carried in a separate RTP session with its own destination transport address; it is not intended that different media be carried in a single RTP session and demultiplexed by payload type or SSRC fields.
No more than 20% of the RTCP bandwidth allocated to a single participant should be used to carry additional SDES information beyond CNAME, as excess SDES slows the rate of reception reports and CNAME transmission, impairing protocol performance.
Senders are collectively allocated at least 1/4 of the RTCP control traffic bandwidth so that newly joining participants receive CNAME for active sending sites quickly. The RTCP interval is varied randomly over [0.5, 1.5] times the calculated value to avoid unintended synchronization.
The calculated interval between RTCP packets is required to be greater than a minimum of 5 seconds to avoid bursts of RTCP traffic exceeding allowed bandwidth when the number of participants is small and traffic does not smooth according to the law of large numbers.
The initial value of the RTP sequence number must be random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt, because packets may flow through a translator that does.
Interarrival jitter is estimated continuously using J = J + (|D(i-1,i)| − J) / 16, where D(i,j) = (Rj−Ri) − (Sj−Si) is the difference in relative transit time between packet pairs received in arrival order. The result is carried as a 32-bit unsigned integer in timestamp units in each reception report block.
The CNAME (canonical end-point identifier) SDES item provides a persistent binding to an RTP participant that remains constant across SSRC changes due to conflicts or restarts. It should be unique per session and fixed across all RTP sessions belonging to the same multimedia conference participant.
The CSRC (contributing source) list, inserted by RTP mixers, contains up to 15 SSRC identifiers (32 bits each) of sources that contributed to the packet payload, enabling correct talker indication at receivers even though all packets carry the mixer's own SSRC.
The synchronization source (SSRC) is a 32-bit randomly chosen identifier unique within an RTP session that labels a stream of RTP packets sharing a single timing and sequence number space. A participant generating multiple streams in one session must identify each as a different SSRC.
Wallclock time in RTCP SR packets is represented as a 64-bit NTP timestamp (seconds since 0h UTC 1 January 1900); compact representations elsewhere use the middle 32 bits (low 16 of integer part, high 16 of fractional part). The DLSR field is expressed in units of 1/65536 seconds.
RTCP packet type (PT) values are assigned by IANA: SR=200, RR=201, SDES=202, BYE=203, APP=204. Implementations may ignore incoming RTCP packets with unknown PT values; additional packet types may be registered with IANA.
SDES item type values are assigned by IANA: END=0 (list terminator), CNAME=1, NAME=2, EMAIL=3, PHONE=4, LOC=5, TOOL=6, NOTE=7, PRIV=8. All profiles share one common type space; additional items may be registered with IANA.
RTP data and RTCP control packets may be encrypted for confidentiality; the encryption algorithm and key distribution are handled by non-RTP means. When an RTCP compound packet is encrypted, a random 32-bit prefix is prepended and the entire compound packet is encrypted as a whole.
RTP does not provide built-in authentication or message integrity; applications requiring these properties must use lower-layer or external mechanisms. The random initial sequence number reduces known-plaintext attack risk against stream encryption even when only a relay encrypts the packets.
When an SSRC collision is detected (a packet arrives from a different transport address using the receiver's own SSRC), the affected participant sends an RTCP BYE for the old SSRC and selects a new SSRC. The same mechanism detects forwarding loops: a source receiving its own packets from an unexpected address treats this as a collision and rebinds.
The RTCP Receiver Report (PT=201) has the same structure as the SR packet but omits the 20-octet sender information section; the packet type constant is 201 instead of 200. An empty RR (RC=0) is placed at the head of a compound RTCP packet when there is nothing to report.
The RTCP SDES packet (PT=202) contains one or more chunks, each 32-bit-boundary-aligned, beginning with an SSRC/CSRC identifier followed by a list of items. Each item has an 8-bit type, 8-bit length, and UTF-8 text up to 255 octets; the item list is terminated by one or more null octets padded to a 32-bit boundary.
The RTCP Sender Report (PT=200) carries an 8-octet header, a 20-octet sender info section (64-bit NTP wallclock timestamp, 32-bit RTP timestamp, 32-bit packet count, 32-bit octet count), and zero or more 24-octet reception report blocks each containing: fraction lost (8 bits), cumulative packets lost (24 bits), extended highest sequence number received (32 bits), interarrival jitter (32 bits), last SR timestamp LSR (32 bits), and delay since last SR DLSR (32 bits).
The RTP fixed header occupies 12 octets minimum: V(2 bits)=2, P(1 bit), X(1 bit), CC(4 bits), M(1 bit), PT(7 bits), sequence number(16 bits), timestamp(32 bits), SSRC(32 bits), followed by 0–15 CSRC identifiers of 32 bits each. The first twelve octets are present in every RTP packet; the CSRC list is present only when inserted by a mixer.
When the X bit in the RTP header is set, a variable-length header extension follows the CSRC list: a 16-bit profile-defined field, a 16-bit length counting 32-bit words in the extension body (zero is valid), then the extension data. Only a single extension may be appended.