RFC 3550
RTP: A Transport Protocol for Real-Time Applications
RFC 3550: RTP: A Transport Protocol for Real-Time Applications 🦋
Okay bestie, this is the big one 💅 RFC 3550 is an Internet standards track document from the Network Working Group, dated July 2003. The authors are H. Schulzrinne (Columbia University), S. Casner (Packet Design), R. Frederick (Blue Coat Systems Inc.), and V. Jacobson (Packet Design). It obsoletes RFC 1889, and the title block doesn't list any RFCs it updates 🎀
Status of This Memo 🌸
This document specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions so it can get better 🫶 If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so go share it 💜
Copyright Notice 🧚
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
Abstract ✨
Okay so this memo is all about RTP, the real-time transport protocol 🎀 RTP gives you end-to-end network transport functions for apps that send real-time data, like audio, video, or simulation data, over multicast or unicast network services. Lowkey important: RTP does not handle resource reservation, and it does not guarantee quality of service for real-time stuff 🙈
The data transport gets backup from a control protocol called RTCP. It lets you monitor data delivery in a way that still scales to big multicast networks, and it gives you minimal control and identification features 📡 RTP and RTCP are designed to be independent of the underlying transport and network layers, so they don't care what's beneath them 🦋 The protocol also supports RTP-level translators and mixers 🔥
Most of this memo is identical to RFC 1889, which it obsoletes. There are no changes in the packet formats on the wire. The only changes are to the rules and algorithms for how the protocol gets used 💅 The biggest change is an upgrade to the scalable timer algorithm that decides when to send RTCP packets. The goal is to keep transmission from going over the intended rate when a bunch of participants join a session at the same time 😭✨
Table of Contents 🎀
1. Introduction ................................................ 4
1.1 Terminology ............................................ 5
2. RTP Use Scenarios ........................................... 5
2.1 Simple Multicast Audio Conference ...................... 6
2.2 Audio and Video Conference ............................. 7
2.3 Mixers and Translators ................................. 7
2.4 Layered Encodings ...................................... 8
3. Definitions ................................................. 8
4. Byte Order, Alignment, and Time Format ...................... 12
5. RTP Data Transfer Protocol .................................. 13
5.1 RTP Fixed Header Fields ................................ 13
5.2 Multiplexing RTP Sessions .............................. 16
5.3 Profile-Specific Modifications to the RTP Header ....... 18
5.3.1 RTP Header Extension ............................ 18
6. RTP Control Protocol -- RTCP ................................ 19
6.1 RTCP Packet Format ..................................... 21
6.2 RTCP Transmission Interval ............................. 24
6.2.1 Maintaining the Number of Session Members ....... 28
6.3 RTCP Packet Send and Receive Rules ..................... 28
6.3.1 Computing the RTCP Transmission Interval ........ 29
6.3.2 Initialization .................................. 30
6.3.3 Receiving an RTP or Non-BYE RTCP Packet ......... 31
6.3.4 Receiving an RTCP BYE Packet .................... 31
6.3.5 Timing Out an SSRC .............................. 32
6.3.6 Expiration of Transmission Timer ................ 32
6.3.7 Transmitting a BYE Packet ....................... 33
6.3.8 Updating we_sent ................................ 34
6.3.9 Allocation of Source Description Bandwidth ...... 34
6.4 Sender and Receiver Reports ............................ 35
6.4.1 SR: Sender Report RTCP Packet ................... 36
6.4.2 RR: Receiver Report RTCP Packet ................. 42
6.4.3 Extending the Sender and Receiver Reports ....... 42
6.4.4 Analyzing Sender and Receiver Reports ........... 43
6.5 SDES: Source Description RTCP Packet ................... 45
6.5.1 CNAME: Canonical End-Point Identifier SDES Item . 46
6.5.2 NAME: User Name SDES Item ....................... 48
6.5.3 EMAIL: Electronic Mail Address SDES Item ........ 48
6.5.4 PHONE: Phone Number SDES Item ................... 49
6.5.5 LOC: Geographic User Location SDES Item ......... 49
6.5.6 TOOL: Application or Tool Name SDES Item ........ 49
6.5.7 NOTE: Notice/Status SDES Item ................... 50
6.5.8 PRIV: Private Extensions SDES Item .............. 50
6.6 BYE: Goodbye RTCP Packet ............................... 51
6.7 APP: Application-Defined RTCP Packet ................... 52
7. RTP Translators and Mixers .................................. 53
7.1 General Description .................................... 53
7.2 RTCP Processing in Translators ......................... 55
7.3 RTCP Processing in Mixers .............................. 57
7.4 Cascaded Mixers ........................................ 58
8. SSRC Identifier Allocation and Use .......................... 59
8.1 Probability of Collision ............................... 59
8.2 Collision Resolution and Loop Detection ................ 60
8.3 Use with Layered Encodings ............................. 64
9. Security .................................................... 65
9.1 Confidentiality ........................................ 65
9.2 Authentication and Message Integrity ................... 67
10. Congestion Control .......................................... 67
11. RTP over Network and Transport Protocols .................... 68
12. Summary of Protocol Constants ............................... 69
12.1 RTCP Packet Types ...................................... 70
12.2 SDES Types ............................................. 70
13. RTP Profiles and Payload Format Specifications .............. 71
14. Security Considerations ..................................... 73
15. IANA Considerations ......................................... 73
16. Intellectual Property Rights Statement ...................... 74
17. Acknowledgments ............................................. 74
Appendix A. Algorithms ........................................ 75
Appendix A.1 RTP Data Header Validity Checks ................... 78
Appendix A.2 RTCP Header Validity Checks ....................... 82
Appendix A.3 Determining Number of Packets Expected and Lost ... 83
Appendix A.4 Generating RTCP SDES Packets ...................... 84
Appendix A.5 Parsing RTCP SDES Packets ......................... 85
Appendix A.6 Generating a Random 32-bit Identifier ............. 85
Appendix A.7 Computing the RTCP Transmission Interval .......... 87
Appendix A.8 Estimating the Interarrival Jitter ................ 94
Appendix B. Changes from RFC 1889 ............................. 95
References ...................................................... 100
Normative References ............................................ 100
Informative References .......................................... 100
Authors' Addresses .............................................. 103
Full Copyright Statement ........................................ 1041. Introduction ✨
okay bestie, this doc is literally the spec for RTP, the real-time transport protocol 🦋 It's built for data with real-time vibes, like interactive audio and video. The services it gives you are payload type identification, sequence numbering, timestamping, and delivery monitoring 💖 Apps usually run RTP on top of UDP so they can use its multiplexing and checksum stuff. Both protocols handle parts of the transport work together 🫶 RTP can also ride on other suitable network or transport protocols (see Section 11), and if the underlying network supports multicast, RTP can send data to multiple destinations at once 🌈
ngl, RTP does NOT promise timely delivery or any other quality-of-service guarantees by itself 💀 It leans on lower-layer services for that. It doesn't guarantee delivery, it doesn't stop out-of-order delivery, and it doesn't assume the network is reliable or delivers packets in sequence 🙈 The sequence numbers let the receiver rebuild the sender's packet order, but they can also tell you where a packet belongs, like in video decoding, without decoding packets in order ✨
RTP was mainly made for multi-participant multimedia conferences, but it's not limited to that 👑 Storage of continuous data, interactive distributed simulation, active badge systems, and control and measurement apps might find it useful too 🧚
This document defines RTP as two closely linked parts 💅
- the real-time transport protocol (RTP), which carries data with real-time properties.
- the RTP control protocol (RTCP), which monitors quality of service and shares info about the participants in an ongoing session 🎀 The RTCP part might be enough for "loosely controlled" sessions, meaning sessions with no explicit membership control or setup 🌸 It isn't really meant to cover every control communication an app needs, though. A separate session control protocol might fully or partly take that over, and that's outside this document 🍓
RTP is a whole new style of protocol that follows the principles of application level framing and integrated layer processing, which Clark and Tennenhouse proposed [10] 😭 RTP is meant to be malleable, so it can provide whatever info a specific app needs, and it's often built right into the app's processing instead of living as its own separate layer 💜 It's a protocol framework that's deliberately not complete. This document only covers the functions expected to be common across all the apps where RTP would fit 🔥 Conventional protocols add features by making themselves more general or by adding an option mechanism that needs parsing, but RTP is tailored by modifying and/or adding to the headers as needed 🙌 Examples are in Sections 5.3 and 6.4.3.
So, besides this document, a complete RTP spec for a particular app needs one or more companion documents (see Section 13) 🫶
- a profile specification document, which defines a set of payload type codes and how they map to payload formats (like media encodings). A profile can also define extensions or changes to RTP that are specific to one class of apps 💖 Usually an app only runs under one profile. A profile for audio and video data is in the companion RFC 3551 [1] ✨
- payload format specification documents, which define how a particular payload, like an audio or video encoding, gets carried in RTP 🦋
If you want a deep dive on real-time services, how to implement them, and some background on RTP's design decisions, check out [11] 🤓
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14, RFC 2119 [2] 📚 They show the requirement levels for compliant RTP implementations. Important, so don't skip it 🎀
2. RTP Use Scenarios 🌈
These sections walk through some ways RTP gets used 💅 The examples were picked to show how apps using RTP basically work, not to limit what RTP can be used for ✨ In all of them, RTP rides on top of IP and UDP and follows the conventions set by the audio and video profile in the companion RFC 3551 🦋
2.1 Simple Multicast Audio Conference
Picture this: an IETF working group meets to talk about the latest protocol document, using Internet IP multicast for voice 🎧 Through some allocation mechanism, the working group chair gets a multicast group address and a pair of ports 🙌 One port carries the audio data, and the other carries the control (RTCP) packets. That address and port info gets sent out to the intended participants 💌 If they want privacy, the data and control packets can be encrypted as specified in Section 9.1, and then an encryption key has to be generated and distributed too 🔐 The exact details of how allocation and distribution work are beyond RTP's scope, so that's not on this doc 🙈
Each conference participant's audio app sends audio in small chunks, like 20 ms each 🎶 Every chunk gets an RTP header in front of it, and the RTP header and data sit inside a UDP packet 📦 The RTP header says what type of audio encoding (like PCM, ADPCM, or LPC) is in each packet, so senders can switch encodings mid-conference 🔄 That's useful if a new participant joins over a low-bandwidth link, or if the sender needs to react to signs of network congestion 🚦
The Internet, like other packet networks, sometimes loses packets, reorders them, and delays them by different amounts of time 😤 To handle this, the RTP header includes timing info and a sequence number. Together they let receivers rebuild the timing the source produced, so in this example, audio chunks get played out the speaker contiguously every 20 ms 🔊 That timing reconstruction happens separately for each source of RTP packets in the conference 🧚 The sequence number can also help the receiver estimate how many packets are getting lost 📉
Since working group members keep joining and leaving during the conference, it helps to know who's participating at any moment and how well they're receiving the audio 👀 So each instance of the audio app periodically multicasts a reception report plus its user's name on the RTCP (control) port 📣 The reception report shows how well the current speaker is being received, and it can be used to control adaptive encodings 🎛️ Other identifying info can be included too, as long as it fits within the control bandwidth limits 💜 When a site leaves the conference, it sends the RTCP BYE packet (Section 6.6) 👋
2.2 Audio and Video Conference
If a conference uses both audio and video, each medium goes out as its own separate RTP session 🎬 So separate RTP and RTCP packets go out for each medium, using two different UDP port pairs and/or multicast addresses 🌸 At the RTP level, the audio and video sessions aren't directly coupled 🙅♀️ The one exception: a user in both sessions should use the same distinguished (canonical) name in their RTCP packets for both, so the sessions can be linked together 💖
Why split them up? So some participants can receive just one medium if they want to 🙌 Section 5.2 explains that more. Even though they're separate, you can still get synchronized playback of a source's audio and video, using timing info carried in the RTCP packets for both sessions 🎀✨
2.3 Mixers and Translators
So far we've assumed every site wants to receive media in the same format. But that's not always the move 🤔 Say some participants in one area are on a slow link, while most of the conference has high-speed access 🐢 Instead of making everyone use a lower-bandwidth, lower-quality audio encoding, you can put an RTP-level relay called a mixer near the slow area 🔀 The mixer resyncs incoming audio packets to rebuild the constant 20 ms spacing the sender made, mixes those reconstructed streams into one stream, translates the audio into a lower-bandwidth encoding, and forwards that lighter stream across the slow link 🪄 Those packets can go to one recipient as unicast, or go out on a different multicast address to several recipients 📡 The RTP header has a way for mixers to identify which sources went into a mixed packet, so receivers can show the right talker indication 🗣️
Some intended participants might have fast links but can't be reached directly with IP multicast 🚧 For example, they could be behind an application-level firewall that blocks all IP packets 🧱 In that case mixing isn't needed. Instead, you use another RTP-level relay called a translator 🦋 You install two translators, one on each side of the firewall. The outside one funnels all the multicast packets it receives through a secure connection to the translator inside the firewall 🔒 The inside translator then sends them out again as multicast packets to a multicast group limited to the site's internal network 🏠
Mixers and translators can be built for all sorts of purposes 🎨 One example is a video mixer that scales each person's image from separate video streams and composites them into one video stream, to simulate a group scene 👯 Translation can also mean connecting a group of hosts that only speak IP/UDP to a group of hosts that only understand ST-II 🛰️ Or it can mean translating video encodings packet by packet from individual sources, without resynchronizing or mixing 💅 Full details on how mixers and translators work are in Section 7 🌟
2.4. Layered Encodings ✨
okay so bestie, multimedia apps need to be able to change how fast they send stuff, either to match what the receiver can handle or to get out of the way when the network is congested 🌊. The problem is that a lot of implementations dump that job on the source, and that does NOT slay with multicast 💀 because every receiver has totally different bandwidth needs. The result is basically a least-common-denominator situation, where the slowest pipe in the whole mesh decides the quality of the entire live "broadcast" for everyone 😭.
The fix is to put the rate-adaptation job on the receivers instead 🫶. You do that by pairing a layered encoding with a layered transmission system. For RTP over IP multicast, the source can spread the progressive layers of a hierarchically encoded signal across multiple RTP sessions, and each of those sessions gets its own multicast group 🦋. Then receivers can handle network differences themselves and control how much bandwidth they pull in, just by joining the right subset of those multicast groups. It's giving main character energy for the receivers 👑.
Details on using RTP with layered encodings are in Sections 6.3.9, 8.3 and 11 📚.
3. Definitions 💅
Okay, time for the vocab, bestie 🧚. Here's everything you need:
- RTP payload 🎀: The data that RTP carries in a packet, like audio samples or compressed video data. The payload format and how it gets interpreted are out of scope for this doc, so we're not going there today 🙈.
- RTP packet 📦: A data packet made up of the fixed RTP header, a list of contributing sources (more on those below) that might be empty, and the payload data. Some underlying protocols need an RTP packet to be wrapped in an encapsulation that gets defined separately. Usually one packet of the underlying protocol holds a single RTP packet, but several RTP packets MAY be included if the encapsulation method allows it (see Section 11) 🌸.
- RTCP packet 💌: A control packet with a fixed header that looks a lot like an RTP data packet's header, followed by structured elements that depend on the RTCP packet type. The formats are defined in Section 6. Usually several RTCP packets travel together as one compound RTCP packet inside a single packet of the underlying protocol, and the length field in each RTCP packet's fixed header is what makes that work 🧩.
- Port 🚪: The "abstraction that transport protocols use to distinguish among multiple destinations within a given host computer. TCP/IP protocols identify ports using small positive integers." [12] The transport selectors (TSEL) used by the OSI transport layer are the same idea as ports. RTP relies on the lower-layer protocol to give it some mechanism, like ports, for multiplexing the RTP and RTCP packets of a session 🌈.
- Transport address 📍: The combo of a network address and a port that pins down a transport-level endpoint, like an IP address plus a UDP port. Packets get sent from a source transport address to a destination transport address 🚀.
- RTP media type 🎬: An RTP media type is the collection of payload types that can be carried within a single RTP session. The RTP Profile is what assigns RTP media types to RTP payload types 🗂️.
- Multimedia session 🎥: A set of concurrent RTP sessions among a shared group of participants. For example, a videoconference is a multimedia session, and it can contain an audio RTP session and a video RTP session at the same time 🍿.
- RTP session 🫧: An association among a set of participants who are communicating with RTP. One participant can be part of several RTP sessions at once. In a multimedia session, each medium usually gets its own RTP session with its own RTCP packets, unless the encoding itself multiplexes several media into a single data stream 🎶. A participant tells multiple RTP sessions apart by the fact that each session arrives on a different pair of destination transport addresses, where a pair is one network address plus a pair of ports, one for RTP and one for RTCP. Everyone in an RTP session might share one destination transport address pair, like with IP multicast, or each participant might have its own pair, like with individual unicast addresses and port pairs. In the unicast case, a participant can receive from everyone else in the session on the same pair of ports, or it can use a separate pair of ports for each sender 🔌.
The defining thing about an RTP session is that each one keeps its own full, separate space of SSRC identifiers (more on those next) 💜. The set of participants in one RTP session is made up of everyone who can receive an SSRC identifier sent by any one of the participants, whether it shows up in RTP as the SSRC or a CSRC, or in RTCP. Let's walk through an example. Picture a three-party conference over unicast UDP, where each participant receives from the other two on separate port pairs. If each participant sends RTCP feedback about the data it got from one other participant back only to that participant, then the conference is really three separate point-to-point RTP sessions 🔁. But if each participant sends its RTCP feedback about its reception of one other participant to both of the other participants, then the conference is one multi-party RTP session. That second case mimics what would happen with IP multicast among the three of them 🤝.
The RTP framework allows the variations described here, but a particular control protocol or application design will usually put constraints on those variations 🧠.
- Synchronization source (SSRC) 🎤: The source of a stream of RTP packets. It's identified by a 32-bit numeric SSRC identifier that goes in the RTP header, so it doesn't depend on the network address. All packets from one synchronization source share the same timing and sequence number space, which is why a receiver groups packets by synchronization source when it plays them back ⏯️. Examples of synchronization sources include the sender of a stream of packets from a signal source like a microphone or camera, or an RTP mixer (see below). A synchronization source can change its data format over time, like switching its audio encoding 🔄. The SSRC identifier is a randomly chosen value that's meant to be globally unique within a particular RTP session (see Section 8) 🎲. A participant doesn't have to use the same SSRC identifier across all the RTP sessions in a multimedia session. The binding of SSRC identifiers is handled through RTCP (see Section 6.5.1) 🔗. If a participant generates multiple streams in one RTP session, like from separate video cameras, each one MUST be identified as a different SSRC 📹.
- Contributing source (CSRC) 🙋: A source of a stream of RTP packets that contributed to the combined stream an RTP mixer (see below) produces. The mixer puts a list of the SSRC identifiers of the sources that went into a particular packet into that packet's RTP header. That list is called the CSRC list. A good example is audio conferencing, where the mixer lists all the talkers whose speech got combined into the outgoing packet. That way the receiver can tell who's talking right now, even though every audio packet has the same SSRC identifier, which belongs to the mixer 🎙️✨.
- End system 💻: An application that generates the content to send in RTP packets and/or consumes the content of received RTP packets. An end system can act as one or more synchronization sources in a particular RTP session, but it usually only acts as one 🧍.
- Mixer 🌀: An intermediate system that gets RTP packets from one or more sources, might change the data format, combines the packets somehow, and then forwards a new RTP packet. The timing across multiple input sources usually isn't synchronized, so the mixer makes timing adjustments among the streams and generates its own timing for the combined stream. That means every data packet coming out of a mixer gets identified with the mixer as its synchronization source 🎛️.
- Translator 🔀: An intermediate system that forwards RTP packets with their synchronization source identifier left intact. Examples include devices that convert encodings without mixing, replicators that go from multicast to unicast, and application-level filters in firewalls 🛡️.
- Monitor 👀: An application that receives the RTCP packets participants send in an RTP session, especially the reception reports, and estimates the current quality of service. It's used for distribution monitoring, fault diagnosis and long-term statistics 📊. The monitor function is probably built into the application(s) taking part in the session, but it can also be a separate application that doesn't otherwise participate and doesn't send or receive the RTP data packets (since those travel on a separate port). These are called third-party monitors 🕵️. It's also fine for a third-party monitor to receive the RTP data packets without sending RTCP packets or otherwise being counted in the session 🫥.
- Non-RTP means 🧰: Protocols and mechanisms that might be needed alongside RTP to provide a usable service. For multimedia conferences especially, a control protocol might distribute multicast addresses and encryption keys, negotiate which encryption algorithm to use, and define dynamic mappings between RTP payload type values and the payload formats they represent, for formats that don't have a predefined payload type value. Examples of such protocols include the Session Initiation Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14], and applications that use SDP (RFC 2327 [15]), such as RTSP (RFC 2326 [16]). For simple applications, electronic mail or a conference database might also get the job done 📬. Specifying these protocols and mechanisms is outside the scope of this document 🌷.
4. Byte Order, Alignment, and Time Format ✨
okay so first up, the byte order rules 🍓 Every integer field gets sent in network byte order, which means most significant byte (octet) first. People call this big-endian, and it's the transmission order described in detail in [3]. Unless it says otherwise, numeric constants are in decimal (base 10) 🔢
All header data is aligned to its natural length. So 16-bit fields sit on even offsets, 32-bit fields sit at offsets divisible by four, and so on 📏 Any octets marked as padding have the value zero 🫶
Now for time 🕰️ Wallclock time (the absolute date and time) is written in the timestamp format of the Network Time Protocol (NTP), which counts seconds from 0h UTC on 1 January 1900 [4]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number. The integer part lives in the first 32 bits and the fractional part lives in the last 32 bits. Some fields want something more compact, so they only use the middle 32 bits. That means the low 16 bits of the integer part and the high 16 bits of the fractional part. The high 16 bits of the integer part must be determined independently 🧚
You don't actually have to run the Network Time Protocol to use RTP 🙅♀️ Other time sources can be used, or none at all (see the description of the NTP timestamp field in Section 6.4.1). That said, running NTP might be useful for synchronizing streams that come from separate hosts, so it's a solid move 💜
The NTP timestamp wraps around to zero sometime in the year 2036. But RTP only ever uses differences between pairs of NTP timestamps, so the wraparound doesn't matter 💖 As long as the pairs of timestamps are within 68 years of each other, doing subtraction and comparison with modular arithmetic makes the wraparound irrelevant. Iconic, honestly 💅
5. RTP Data Transfer Protocol 🎀
5.1 RTP Fixed Header Fields 🦋
okay this is the RTP header, and it's giving structure 🧱 Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The first twelve octets show up in every RTP packet 📦 The CSRC list only shows up when a mixer puts it in 🎚️ Here's what each field means:
version (V): 2 bits 🔖 This tells you which version of RTP you're looking at. The version defined by this specification is two (2). (The value 1 was used by the first draft version of RTP, and the value 0 was used by the protocol first implemented in the "vat" audio tool. Old school, lol 🙈)
padding (P): 1 bit 🫧 If the padding bit is set, the packet has one or more extra padding octets at the end that aren't part of the payload. The last octet of the padding is a count of how many padding octets to ignore, and that count includes itself. Padding can be needed by some encryption algorithms with fixed block sizes, or for carrying several RTP packets in a lower-layer protocol data unit 🔐
extension (X): 1 bit 🧩 If the extension bit is set, the fixed header MUST be followed by exactly one header extension, with a format defined in Section 5.3.1. No skipping, bestie 🙅♀️
CSRC count (CC): 4 bits 🔢 This one contains the number of CSRC identifiers that follow the fixed header.
marker (M): 1 bit 🚩 What the marker means is up to a profile. It's meant to flag big moments like frame boundaries in the packet stream. A profile MAY define additional marker bits, or it MAY specify that there is no marker bit at all by changing the number of bits in the payload type field (see Section 5.3). Flexible, kinda iconic 💖
payload type (PT): 7 bits 🎵 This field says what format the RTP payload is in, and the application uses it to figure out how to interpret the payload. A profile MAY specify a default static mapping of payload type codes to payload formats. More payload type codes MAY be defined dynamically through non-RTP means (see Section 3). A set of default mappings for audio and video is specified in the companion RFC 3551 [1]. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams (see Section 5.2). Not the move 🙅♀️
A receiver MUST ignore packets with payload types it doesn't understand. Just scroll past, periodt 🙈
sequence number: 16 bits 🔢 The sequence number goes up by one for every RTP data packet sent. The receiver can use it to detect packet loss and to put packets back in order 🧩 The initial value of the sequence number SHOULD be random (unpredictable). That makes known-plaintext attacks on encryption harder, even if the source doesn't encrypt using the method in Section 9.1, because the packets might flow through a translator that does 🕵️♀️ Techniques for picking unpredictable numbers are discussed in [17] 🌸
timestamp: 32 bits ⏱️ The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant MUST be derived from a clock that increments monotonically and linearly in time, so you can do synchronization and jitter calculations (see Section 6.4.1). The clock's resolution MUST be enough for the synchronization accuracy you want and for measuring packet arrival jitter. (One tick per video frame is typically not sufficient, sis 😭) The clock frequency depends on the format of the data carried as payload. It's specified statically in the profile or payload format specification that defines the format, or it MAY be specified dynamically for payload formats defined through non-RTP means. If RTP packets are generated periodically, use the nominal sampling instant from the sampling clock, NOT a reading of the system clock 🚫⏰ For example, with fixed-rate audio the timestamp clock would probably go up by one for each sampling period. If an audio app reads blocks covering 160 sampling periods from the input device, the timestamp goes up by 160 for each block, whether or not that block gets sent in a packet or dropped as silent 🎧
The initial value of the timestamp SHOULD be random, same as the sequence number ✨ Several consecutive RTP packets will have equal timestamps if they were (logically) generated at once, like when they belong to the same video frame 🎬 Consecutive RTP packets MAY contain timestamps that aren't monotonic, if the data isn't transmitted in the order it was sampled. MPEG interpolated video frames are the classic example 🎞️ (The sequence numbers of the packets, as transmitted, will still be monotonic, so relax 😌)
RTP timestamps from different media streams can advance at different rates, and they usually have independent, random offsets 🌈 So even though these timestamps are enough to rebuild the timing of a single stream, comparing RTP timestamps across different media doesn't work well for synchronization 🙅♀️ Instead, each medium's RTP timestamp gets paired with a timestamp from a reference clock (wallclock) that shows when the data behind that RTP timestamp was sampled. Every medium being synchronized shares the same reference clock 🕰️ These timestamp pairs aren't sent in every data packet. They go out at a lower rate in RTCP SR packets, as described in Section 6.4.
The sampling instant is picked as the reference point for the RTP timestamp because the sending endpoint knows it, and it has the same definition for every medium, no matter the encoding delays or other processing 💅 The whole point is to let all media sampled at the same time get presented in sync 🫶
Apps that send stored data instead of real-time sampled data usually use a virtual presentation timeline based on wallclock time. That timeline decides when the next frame or other unit of each medium should be presented 🎥 In that case, the RTP timestamp reflects the presentation time for each unit. So the RTP timestamp for each unit relates to the wallclock time when that unit becomes current on the virtual presentation timeline. The actual presentation happens a bit later, as decided by the receiver 🍿
Here's a juicy example that shows why the sampling instant is the right reference point 👀 Imagine someone doing live audio narration over prerecorded video. The video gets shown locally so the narrator can watch it, and at the same time it's sent over RTP. The "sampling instant" of a video frame sent in RTP is set by tying its timestamp to the wallclock time when that frame was shown to the narrator. The sampling instant for the audio RTP packets with the narrator's speech is set by tying them to that same wallclock time, when the audio was sampled. The audio and video can even come from different hosts, as long as the reference clocks on both hosts are synced by something like NTP. Then a receiver can line up the presentation of the audio and video packets by relating their RTP timestamps using the timestamp pairs in RTCP SR packets 🧠✨
SSRC: 32 bits 🆔 The SSRC field identifies the synchronization source. This identifier SHOULD be picked randomly, so that no two synchronization sources in the same RTP session end up with the same SSRC identifier. An example algorithm for generating a random identifier is in Appendix A.6 🎲 Even though multiple sources picking the same identifier is unlikely, every RTP implementation must be prepared to detect and resolve collisions. Section 8 covers the probability of collision, plus a mechanism for resolving collisions and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identifier. If a source changes its source transport address, it must also pick a new SSRC identifier, so it doesn't get mistaken for a looped source (see Section 8.2) 🔁 Not the vibe to get mixed up with a loop, fr
CSRC list: 0 to 15 items, 32 bits each 🎤 The CSRC list identifies the contributing sources for the payload in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified 🙃 CSRC identifiers are inserted by mixers (see Section 7.1), using the SSRC identifiers of the contributing sources. For example, for audio packets, the SSRC identifiers of all the sources mixed together to make a packet get listed. That way the receiver can tell who's talking, which is giving main character energy 🎙️👑
5.2 Multiplexing RTP Sessions 💖
okay so, for efficient protocol processing you want the number of multiplexing points to be minimized, bestie, as described in the integrated layer processing design principle [10]. 💅 In RTP, multiplexing happens through the destination transport address (network address and port number), and that address is different for each RTP session. 🌸 Picture a teleconference where audio and video are encoded separately: each medium SHOULD be carried in a separate RTP session with its own destination transport address. 🎀
Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. 🙅 Interleaving packets with different RTP media types but using the same SSRC would cause a whole list of problems, no cap 💀:
- If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings. 😭
- An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ, and would require different sequence number spaces to tell which payload type suffered packet loss. 🕰️
- The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC, and they do not carry a payload type field. 📋
- An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. 🙅
- Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. 🚫
Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two. 🤔
On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. 🌈 The problems listed above don't apply here: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply. ✨
5.3 Profile-Specific Modifications to the RTP Header 🎀
The existing RTP data packet header is believed to be complete for the set of functions required in common across all the application classes that RTP might support. 💁 However, in keeping with the ALF design principle, the header MAY be tailored through modifications or additions defined in a profile specification, while still allowing profile-independent monitoring and recording tools to function. ✨
- The marker bit and payload type field carry profile-specific information, but they are allocated in the fixed header since many applications are expected to need them and might otherwise have to add another 32-bit word just to hold them. The octet containing these fields MAY be redefined by a profile to suit different requirements, for example with more or fewer marker bits. If there are any marker bits, one SHOULD be located in the most significant bit of the octet, since profile-independent monitors may be able to observe a correlation between packet loss patterns and the marker bit. 🔥
- Additional information that is required for a particular payload format, such as a video encoding, SHOULD be carried in the payload section of the packet. This might be in a header that is always present at the start of the payload section, or might be indicated by a reserved value in the data pattern. 🎬
- If a particular class of applications needs additional functionality independent of payload format, the profile under which those applications operate SHOULD define additional fixed fields to follow immediately after the SSRC field of the existing fixed header. Those applications will be able to quickly and directly access the additional fields, while profile-independent monitors or recorders can still process the RTP packets by interpreting only the first twelve octets. 👑
If it turns out that additional functionality is needed in common across all profiles, then a new version of RTP should be defined to make a permanent change to the fixed header. 🦋
5.3.1 RTP Header Extension 🦋
An extension mechanism is provided so individual implementations can experiment with new payload-format-independent functions that require additional information to be carried in the RTP data packet header. 🧪 This mechanism is designed so that the header extension may be ignored by other interoperating implementations that have not been extended. 🫶
Note that this header extension is intended only for limited use! Most potential uses of this mechanism would be better done another way, using the methods described in the previous section. For example, a profile-specific extension to the fixed header is less expensive to process, because it is not conditional nor in a variable location. Additional information required for a particular payload format SHOULD NOT use this header extension, but SHOULD be carried in the payload section of the packet. 🚨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |If the X bit in the RTP header is one, a variable-length header extension MUST be appended to the RTP header, following the CSRC list if present. 🧩 The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length). Only a single extension can be appended to the RTP data header. 📦 To allow multiple interoperating implementations to each experiment independently with different header extensions, or to allow a particular implementation to experiment with more than one type of header extension, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. 🌸 The format of these 16 bits is to be defined by the profile specification under which the implementations are operating. This RTP specification does not define any header extensions itself. 🙌
6. RTP Control Protocol -- RTCP 👑
The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. 📡 The underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions:
- The primary function is to provide feedback on the quality of the data distribution. This is an integral part of RTP's role as a transport protocol, and it is related to the flow and congestion control functions of other transport protocols (see Section 10 on the requirement for congestion control). The feedback may be directly useful for control of adaptive encodings [18,19], but experiments with IP multicasting have shown that it is also critical to get feedback from the receivers to diagnose faults in the distribution. Sending reception feedback reports to all participants allows one who is observing problems to evaluate whether those problems are local or global. 🔍 With a distribution mechanism like IP multicast, it is also possible for an entity such as a network service provider, who is not otherwise involved in the session, to receive the feedback information and act as a third-party monitor to diagnose network problems. 🕵️♀️ This feedback function is performed by the RTCP sender and receiver reports, described below in Section 6.4.
- RTCP carries a persistent transport-level identifier for an RTP source called the canonical name, or CNAME (Section 6.5.1). Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant. 🪪 Receivers may also require the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. Inter-media synchronization also requires the NTP and RTP timestamps included in RTCP packets by data senders. ⏱️
- The first two functions require that all participants send RTCP packets, so the rate must be controlled in order for RTP to scale up to a large number of participants. 📈 By having each participant send its control packets to all the others, each one can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent, as explained in Section 6.2. 🧮
- A fourth, OPTIONAL function is to convey minimal session control information, for example participant identification to be displayed in the user interface. 🏷️ This is most likely to be useful in "loosely controlled" sessions, where participants enter and leave without membership control or parameter negotiation. RTCP serves as a convenient channel to reach all the participants, but it is not necessarily expected to support all the control communication requirements of an application. A higher-level session control protocol, which is beyond the scope of this document, may be needed. 🧚
Functions 1-3 SHOULD be used in all environments, but particularly in the IP multicast environment. 🌍 RTP application designers SHOULD avoid mechanisms that can only work in unicast mode and will not scale to larger numbers. 🙅♀️ Transmission of RTCP MAY be controlled separately for senders and receivers, as described in Section 6.2, for cases such as unidirectional links where feedback from receivers is not possible. 🔄
Non-normative note: In the multicast routing approach called Source-Specific Multicast (SSM), there is only one sender per "channel" (a source address, group address pair), and receivers (except for the channel source) cannot use multicast to communicate directly with other channel members. 🧃 The recommendations here accommodate SSM only through Section 6.2's option of turning off receivers' RTCP entirely. Future work will specify adaptation of RTCP for SSM so that feedback from receivers can be maintained. 🔮
6.1 RTCP Packet Format ✨
okay bestie, this is where RTCP gets to show off its packet types 💅 There are five of them:
- SR: Sender report 📣 Carries transmission and reception stats from participants who are active senders.
- RR: Receiver report 👂 Carries reception stats from participants who are not active senders. Combined with SR, it also covers active senders reporting on more than 31 sources.
- SDES: Source description items, including CNAME 🏷️
- BYE: Says "I'm leaving the chat" 👋
- APP: Application-specific functions 🧚
Every RTCP packet starts with a fixed part that's kinda giving RTP data packet energy 🦋 After that comes structured stuff. That stuff MAY be variable length depending on the packet type, but it MUST end on a 32-bit boundary. The alignment rule and the length field in that fixed part are what make RTCP packets "stackable" 🥞 You can stack them with zero separators between them to make a compound RTCP packet, sent in one packet of the lower layer protocol, like UDP. There's no explicit count of how many packets are inside, because the lower layer is expected to give you the overall length, so you know where the compound packet ends 🎀
Each packet in a compound packet can be processed on its own, with no rules about order or combination. Still, to get the protocol's jobs done, there are a few constraints:
- Reception statistics (in SR or RR) should be sent as often as bandwidth constraints will allow, to maximize the resolution of the statistics 📊 So every periodically transmitted compound RTCP packet MUST include a report packet 💖
- New receivers need the CNAME for a source ASAP so they can identify the source and start linking media together for stuff like lip-sync 👄✨ So each compound RTCP packet MUST also include the SDES CNAME, except when the compound packet is split for partial encryption as described in Section 9.1 🔐
- The number of packet types allowed to appear first in the compound packet needs to be limited 🙅♀️ That keeps more constant bits in the first word, and makes it more likely you can successfully validate RTCP packets against misaddressed RTP data packets or other unrelated packets 🕵️♀️
Thus, all RTCP packets MUST be sent in a compound packet of at least two individual packets, with the following format:
- Encryption prefix: If and only if the compound packet is going to be encrypted using the method in Section 9.1, it MUST be prefixed by a random 32-bit quantity that gets redrawn for every compound packet transmitted 🎲 If padding is needed for the encryption, it MUST be added to the last packet of the compound packet 🧁
- SR or RR: The first RTCP packet in the compound packet MUST always be a report packet, so header validation works as described in Appendix A.2 🔍 This is true even if no data has been sent or received, in which case an empty RR MUST be sent. It's also true even if the only other RTCP packet in the compound packet is a BYE 💀
- Additional RRs: If the number of sources whose reception stats are being reported goes over 31 (the number that fits into one SR or RR packet), then additional RR packets SHOULD follow the initial report packet 📚
- SDES: An SDES packet containing a CNAME item MUST be included in each compound RTCP packet, except as noted in Section 9.1 🏷️ Other source description items MAY optionally be included if a particular application needs them, subject to bandwidth constraints (see Section 6.3.9) 🌈
- BYE or APP: Other RTCP packet types, including ones that haven't been defined yet, MAY follow in any order. The one exception is that BYE SHOULD be the last packet sent with a given SSRC/CSRC 👋 Packet types MAY appear more than once 🔁
An individual RTP participant SHOULD send only one compound RTCP packet per report interval, so that the RTCP bandwidth per participant can be estimated correctly (see Section 6.2). The exception is when the compound packet is split for partial encryption as described in Section 9.1 🔐 If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without going over the maximum transmission unit (MTU) of the network path, then only the subset that fits into one MTU SHOULD be included in each interval. Those subsets SHOULD be selected round-robin across multiple intervals, so every source gets reported eventually 🔄✨
It is RECOMMENDED that translators and mixers combine the individual RTCP packets from the multiple sources they're forwarding into one compound packet whenever it's feasible, to amortize the packet overhead (see Section 7) 🫶 An example RTCP compound packet, like one a mixer might produce, is shown in Fig. 1 below. If the overall length of a compound packet would go over the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets, each sent in a separate packet of the underlying protocol 🧩 This doesn't hurt the RTCP bandwidth estimation, because each compound packet represents at least one distinct participant 🦋 Note that each of the compound packets MUST begin with an SR or RR packet 💜
An implementation SHOULD ignore incoming RTCP packets with types it doesn't know 🙈 Additional RTCP packet types may be registered with the Internet Assigned Numbers Authority (IANA) as described in Section 15 🌸
if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
| receiver chunk chunk
V reports item item item item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
| |
|<----------------------- compound packet ----------------------->|
|<-------------------------- UDP packet ------------------------->|
#: SSRC/CSRC identifierFigure 1: Example of an RTCP compound packet 🎀
6.2. RTCP Transmission Interval ✨
okay so RTP is built to scale from a tiny hangout with a few friends all the way up to thousands of people 🌍💖. In an audio conference the data traffic is basically self-limiting, bc only one or two people talk at a time 🎙️, so with multicast the data rate on any link stays pretty steady no matter how big the room gets 🫶. The control traffic is NOT self-limiting 💀. If every participant sent reception reports at a constant rate, the control traffic would grow linearly with the number of participants 📈. So the rate has to get scaled down by dynamically calculating the interval between RTCP packet transmissions 🧮✨.
Next up is the session bandwidth 🍰. For each session, the data traffic is assumed to have an aggregate limit called the "session bandwidth", which gets divided among the participants. This bandwidth might be reserved, and the network might enforce the limit 🔒. If there's no reservation, other constraints in the environment may set the "reasonable" maximum the session can use, and that becomes the session bandwidth 🌸. It's kinda independent of the media encoding, but the encoding choice may be limited by the session bandwidth 💅. It may be chosen based on some cost or on what's already known about the available network bandwidth for the session. Often the session bandwidth is the sum of the nominal bandwidths of the senders expected to be active at the same time. For teleconference audio, that's usually just one sender's bandwidth 🎧. For layered encodings, each layer is its own RTP session with its own session bandwidth parameter 🧅.
The session bandwidth parameter is expected to be handed over by a session management app when it starts a media app 📲, but media apps MAY set a default based on the single-sender data bandwidth for the encoding picked for the session 🎶. The app MAY also enforce bandwidth limits based on multicast scope rules or other criteria 🚧. And all participants MUST use the same value for the session bandwidth, so everyone works out the same RTCP interval 🫶💜.
Bandwidth calculations for control and data traffic include lower-layer transport and network protocols (e.g., UDP and IP), since that's what the resource reservation system would need to know 🧠. The application can also be expected to know which of these protocols are in use. Link level headers are NOT included in the calculation, since the packet gets wrapped in different link level headers as it travels 🚂.
The control traffic should be limited to a small and known fraction of the session bandwidth 🍓. It needs to be small so the main job of the transport protocol, carrying data, isn't impaired 🙈. It needs to be known so the control traffic can be included in the bandwidth spec given to a resource reservation protocol, and so each participant can work out its own share on its own 🧮. The control traffic bandwidth is in addition to the session bandwidth for the data traffic. It is RECOMMENDED that the fraction of the session bandwidth added for RTCP be fixed at 5%. It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to participants that are sending data 🌈. That way, in sessions with lots of receivers but only a few senders, newly joining participants get the CNAME for the sending sites faster 🏃♀️💨. When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the full RTCP bandwidth. The exact values of these constants and the other ones in the interval calculation aren't critical, but all participants in the session MUST use the same values so they all calculate the same interval 🔁. So these constants SHOULD be fixed for a particular profile 📌.
A profile MAY specify that the control traffic bandwidth is a separate parameter of the session, rather than a strict percentage of the session bandwidth 🎯. That lets rate-adaptive apps set an RTCP bandwidth that matches a "typical" data bandwidth, which is lower than the maximum set by the session bandwidth parameter 📉.
The profile MAY go further and split the control traffic bandwidth into two separate session parameters, one for active data senders and one for everyone else. Let's call them S and R 👯. Following the 1/4 recommendation for data senders, the RECOMMENDED default values would be 1.25% for S and 3.75% for R 🍰. When the proportion of senders is greater than S/(S+R) of the participants, the senders get their proportion of the sum of these two parameters. Using two params means reception reports can be turned off completely for a session by setting the RTCP bandwidth for non-data-senders to zero, while the RTCP bandwidth for data senders stays non-zero so sender reports can still go out for inter-media synchronization 🎬. Turning off RTCP reception reports is NOT RECOMMENDED 🙅♀️, because they're needed for the functions listed at the beginning of Section 6, especially reception quality feedback and congestion control 🚨. Still, it may be appropriate for systems running on unidirectional links, or for sessions that don't need feedback on reception quality or receiver liveness and have other ways to avoid congestion 🛤️.
The calculated interval between transmissions of compound RTCP packets SHOULD also have a lower bound 🧱. Without one, you'd get bursts of packets blowing past the allowed bandwidth when the number of participants is small and the traffic isn't smoothed out by the law of large numbers 💥. The bound also stops the report interval from getting too tiny during a transient outage, like a network partition, which would delay adaptation once the partition heals 🩹. At application startup, a delay SHOULD be imposed before the first compound RTCP packet goes out ⏳. That gives time to receive RTCP packets from other participants, so the report interval converges to the right value faster 🏁. This delay MAY be set to half the minimum interval, so the new participant gets noticed sooner 👋. The RECOMMENDED value for a fixed minimum interval is 5 seconds ⭐.
An implementation MAY scale the minimum RTCP interval down to a smaller value that's inversely proportional to the session bandwidth parameter, with these limitations 🫧:
- For multicast sessions, only active data senders MAY use the reduced minimum value to calculate the interval for sending compound RTCP packets.
- For unicast sessions, the reduced value MAY be used by participants that are not active data senders too, and the delay before sending the initial compound RTCP packet MAY be zero.
- For all sessions, the fixed minimum SHOULD be used when calculating the participant timeout interval (see Section 6.3.5), so implementations that don't use the reduced value for sending RTCP packets don't get timed out by other participants too early 🧯.
- The RECOMMENDED value for the reduced minimum in seconds is 360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s 🪄.
The algorithm described in Section 6.3 and Appendix A.7 was designed to meet the goals outlined in this section 🏆. It calculates the interval between sending compound RTCP packets, dividing the allowed control traffic bandwidth among the participants. That gives fast responses in small sessions, where identifying everyone is important, and it still adapts automatically to large sessions 🦋. The algorithm has these characteristics 👑:
- The calculated interval between RTCP packets scales linearly with the number of members in the group. That linear factor is what keeps the total control traffic constant when you add up all the members 🧩.
- The interval between RTCP packets is randomly varied over the range [0.5,1.5] times the calculated interval, to avoid unintended synchronization of all participants [20]. The first RTCP packet sent after joining a session is also delayed by a random variation of half the minimum RTCP interval 🎲.
- A dynamic estimate of the average compound RTCP packet size is calculated, counting all the packets received and sent. That way it adapts automatically to changes in how much control info is carried 📊.
- Since the calculated interval depends on the number of observed group members, there can be weird startup effects when a new user joins an existing session, or when many users join a new session at once 😵💫. These new users start out with wrong estimates of the group membership, so their RTCP transmission interval is too short. That's a big deal if lots of users join at the same time. To deal with it, an algorithm called "timer reconsideration" is used. It's a simple back-off mechanism that makes users hold back RTCP packet transmission while the group sizes are increasing 🙅♀️⏸️.
- When users leave a session, either with a BYE or by timeout, the group membership decreases, so the calculated interval should decrease too. A "reverse reconsideration" algorithm lets members shrink their intervals faster in response to membership decreases 🏃♀️🔙.
- BYE packets get different treatment from other RTCP packets 👋. When a user leaves a group and wants to send a BYE, it may do so before its next scheduled RTCP packet. But BYE transmission follows a back-off algorithm, which avoids floods of BYE packets if a large number of members leave the session at the same time 🌊🛑.
This algorithm may be used for sessions where all participants are allowed to send 📣. In that case, the session bandwidth parameter is the product of the individual sender's bandwidth times the number of participants, and the RTCP bandwidth is 5% of that 🧁.
Details of the algorithm's operation are in the sections that follow 🔍. Appendix A.7 gives an example implementation 🎀.
6.2.1 Maintaining the Number of Session Members ✨
okay so the RTCP interval math needs a guess at how many sites are in the session 🧮. Every new site gets counted when you hear from it, and an entry for each one SHOULD be created in a table indexed by the SSRC or CSRC identifier (see Section 8.2) so you can keep track of them 🦋. New entries MAY be considered not valid until multiple packets carrying the new SSRC have been received (see Appendix A.1), or until an SDES RTCP packet containing a CNAME for that SSRC has been received. Entries MAY be deleted from the table when an RTCP BYE packet with the matching SSRC identifier shows up, except that some straggler data packets might arrive after the BYE and bring the entry back to life 💀. So instead, the entry SHOULD be marked as having received a BYE and then deleted after an appropriate delay.
A participant MAY mark another site inactive, or delete it if it isn't valid yet, when no RTP or RTCP packet has come in for a small number of RTCP report intervals (5 is RECOMMENDED). This gives some robustness against packet loss 🛡️. All sites have to use the same value for this multiplier and calculate roughly the same RTCP report interval for this timeout to work properly. Therefore, this multiplier SHOULD be fixed for a particular profile.
For sessions with a huge number of participants, keeping a table of every SSRC and its state info can get totally impractical 😩. An implementation MAY use SSRC sampling, as described in [21], to cut down on storage. An implementation MAY use any other algorithm with similar performance. The big requirement is that any algorithm considered SHOULD NOT substantially underestimate the group size, although it MAY overestimate. The vibe is accurate, not too low 👑.
6.3 RTCP Packet Send and Receive Rules 💌
These are the rules for how to send an RTCP packet and what to do when one comes in 📬. An implementation that works in a multicast environment or a multipoint unicast environment MUST meet the requirements in Section 6.2. That implementation MAY use the algorithm defined in this section to meet those requirements, or MAY use some other algorithm as long as it gives equivalent or better performance. An implementation that is limited to two-party unicast operation SHOULD still randomize the RTCP transmission interval so multiple instances in the same environment don't accidentally sync up 🌀, but it MAY skip the "timer reconsideration" and "reverse reconsideration" algorithms in Sections 6.3.3, 6.3.6 and 6.3.7.
To run these rules, a session participant must keep track of a few pieces of state 🧠:
tp: the last time an RTCP packet was transmitted;tc: the current time;tn: the next scheduled transmission time of an RTCP packet;pmembers: the estimated number of session members at the timetnwas last recomputed;members: the most current estimate for the number of session members;senders: the most current estimate for the number of senders in the session;rtcp_bw: the target RTCP bandwidth, i.e., the total bandwidth that will be used for RTCP packets by all members of this session, in octets per second. This will be a specified fraction of the "session bandwidth" parameter supplied to the application at startup.we_sent: a flag that is true if the application has sent data since the 2nd previous RTCP report was transmitted.avg_rtcp_size: the average compound RTCP packet size, in octets, over all RTCP packets sent and received by this participant. The size includes lower-layer transport and network protocol headers (e.g., UDP and IP) as explained in Section 6.2.initial: a flag that is true if the application has not yet sent an RTCP packet.
A lot of these rules lean on the "calculated interval" between packet transmissions. That's up next 🕰️.
6.3.1 Computing the RTCP Transmission Interval 🧮
To keep things scalable, the average interval between packets from a session participant should scale with the group size 📈. This interval is called the calculated interval, and it's built by mixing together a bunch of the state we just covered. The calculated interval T is then figured out like this:
- If the number of senders is less than or equal to 25% of the membership (
members), the interval depends on whether the participant is a sender or not (based on the value ofwe_sent). Here's how it splits up:- If the participant is a sender (
we_senttrue), the constant C is set to the average RTCP packet size (avg_rtcp_size) divided by 25% of the RTCP bandwidth (rtcp_bw), and the constant n is set to the number of senders. - If
we_sentis not true, the constant C is set to the average RTCP packet size divided by 75% of the RTCP bandwidth. The constant n is set to the number of receivers (members-senders). - If the number of senders is greater than 25%, senders and receivers get treated together. The constant C is set to the average RTCP packet size divided by the total RTCP bandwidth, and n is set to the total number of members.
- As stated in Section 6.2, an RTP profile MAY specify that the RTCP bandwidth may be explicitly defined by two separate parameters (call them S and R) for those participants which are senders and those which are not. In that case, the 25% fraction becomes
S/(S+R)and the 75% fraction becomesR/(S+R). Note that if R is zero, the percentage of senders is never greater thanS/(S+R), and the implementation must avoid division by zero. Not ideal, so watch out 🙈.
- If the participant is a sender (
- If the participant has not yet sent an RTCP packet (the variable
initialis true), the constantTminis set to 2.5 seconds. Otherwise, it's set to 5 seconds. - The deterministic calculated interval
Tdis set tomax(Tmin, n*C). - The calculated interval
Tis set to a number uniformly distributed between 0.5 and 1.5 times the deterministic calculated interval. - The resulting value of
Tis divided bye-3/2=1.21828to make up for the fact that the timer reconsideration algorithm converges to a value of the RTCP bandwidth below the intended average.
This whole procedure gives an interval that's random but, on average, hands at least 25% of the RTCP bandwidth to senders and the rest to receivers 💅. If the senders make up more than one quarter of the membership, the procedure splits the bandwidth equally among all participants, on average 🫶.
6.3.2 Initialization 🌱
When a participant joins the session, it initializes tp to 0, tc to 0, senders to 0, pmembers to 1, members to 1, we_sent to false, rtcp_bw to the specified fraction of the session bandwidth, initial to true, and avg_rtcp_size to the probable size of the first RTCP packet the application will later construct. The calculated interval T is then computed, and the first packet is scheduled for time tn = T. That means a transmission timer gets set to expire at time T. Note that an application MAY use any desired approach for implementing this timer ⏰.
The participant adds its own SSRC to the member table 🎀.
6.3.3 Receiving an RTP or Non-BYE RTCP Packet 📥
When an RTP or RTCP packet comes in from a participant whose SSRC isn't in the member table, the SSRC gets added to the table. The value for members is updated once that participant has been validated as described in Section 6.2.1. The same processing happens for each CSRC in a validated RTP packet 🔁.
When an RTP packet comes in from a participant whose SSRC isn't in the sender table, the SSRC gets added to the table, and the value for senders is updated.
For each compound RTCP packet received, the value of avg_rtcp_size gets updated like this:
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_sizewhere packet_size is the size of the RTCP packet just received.
6.3.4 Receiving an RTCP BYE Packet 👋
Except for the case described in Section 6.3.7 where an RTCP BYE is about to be transmitted, if the packet that came in is an RTCP BYE, the SSRC gets checked against the member table. If it's there, the entry is removed and the value for members is updated. Then the SSRC gets checked against the sender table. If it's there, that entry is removed and the value for senders is updated.
Furthermore, to make the RTCP transmission rate more responsive to changes in group membership, the following "reverse reconsideration" algorithm SHOULD be executed when a BYE packet comes in that drops members to a value less than pmembers 📉:
- The value for
tnis updated according to the following formula:
tn = tc + (members/pmembers) * (tn - tc)- The value for
tpis updated according to the following formula:
tp = tc - (members/pmembers) * (tc - tp).- The next RTCP packet is rescheduled for transmission at time
tn, which is now earlier. - The value of
pmembersis set equal tomembers.
This algorithm doesn't stop the group size estimate from wrongly dropping to zero for a short while. That can happen from premature timeouts when most participants of a big session leave at once but some stick around 😬. What the algorithm does do is get the estimate back to the correct value faster. That situation is rare enough, and the consequences are harmless enough, that it's only a secondary concern 🤷♀️.
6.3.5 Timing Out an SSRC ⏳
At occasional intervals, the participant MUST check whether any of the other participants have timed out 🕵️♀️. To do this, it computes the deterministic calculated interval Td (without the randomization factor) for a receiver, meaning with we_sent false. Any other session member that hasn't sent an RTP or RTCP packet since time tc - MTd (M is the timeout multiplier, and defaults to 5) has timed out. That means its SSRC gets removed from the member list, and members is updated. A similar check happens on the sender list. Any member on the sender list that hasn't sent an RTP packet since time tc - 2T (within the last two RTCP report intervals) gets removed from the sender list, and senders is updated.
If any members time out, the reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed 🔄.
The participant MUST perform this check at least once per RTCP transmission interval ✔️.
6.3.6 Expiration of Transmission Timer 💥
When the packet transmission timer goes off, the participant does the following:
- The transmission interval
Tis computed as described in Section 6.3.1, including the randomization factor. - If
tp + Tis less than or equal totc, an RTCP packet is transmitted.tpis set totc, then another value forTis calculated as in the previous step andtnis set totc + T. The transmission timer is set to expire again at timetn. Iftp + Tis greater thantc,tnis set totp + T. No RTCP packet is transmitted. The transmission timer is set to expire at timetn. pmembersis set tomembers.
If an RTCP packet is transmitted, the value of initial is set to FALSE. Furthermore, the value of avg_rtcp_size is updated:
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_sizewhere packet_size is the size of the RTCP packet just transmitted.
6.3.7 Transmitting a BYE Packet 👋
Okay so when a participant wants to leave a session, a BYE packet gets sent to tell everyone else what happened 🦋. But if loads of people bounce at once, you'd get a flood of BYE packets, so a participant MUST run the following algorithm if the number of members is more than 50 when they choose to leave. It kinda borrows the members variable and uses it to count BYE packets instead 💅:
- When the participant decides to leave the system,
tpis reset totc, the current time,membersandpmembersare initialized to 1,initialis set to 1,we_sentis set to false,sendersis set to 0, andavg_rtcp_sizeis set to the size of the compound BYE packet. The calculated intervalTis computed. The BYE packet is then scheduled for timetn = tc + T. - Every time a BYE packet from another participant is received,
membersis incremented by 1 regardless of whether that participant exists in the member table or not, and when SSRC sampling is in use, regardless of whether or not the BYE SSRC would be included in the sample.membersis NOT incremented when other RTCP packets or RTP packets are received, but only for BYE packets. Similarly,avg_rtcp_sizeis updated only for received BYE packets.sendersis NOT updated when RTP packets arrive; it remains 0. - Transmission of the BYE packet then follows the rules for transmitting a regular RTCP packet, as above.
This lets BYE packets go out right away while still controlling their total bandwidth usage ✨. In the worst case, RTCP control packets could end up using twice the bandwidth as normal (10%), which is 5% for non-BYE RTCP packets and 5% for BYE 🎀.
A participant that doesn't want to wait for the above mechanism before a BYE can go out MAY leave the group without sending a BYE at all 🫶. The other group members will eventually time them out.
If the group size estimate members is less than 50 when the participant decides to leave, the participant MAY send a BYE packet immediately. Alternatively, the participant MAY choose to run the above BYE backoff algorithm 🧚.
In either case, a participant that never sent an RTP or RTCP packet MUST NOT send a BYE packet when they leave the group 🙈.
6.3.8 Updating we_sent 🌸
The variable we_sent is true if the participant has sent an RTP packet recently, and false otherwise. This is figured out using the same mechanisms used to manage the set of other participants listed in the senders table. If the participant sends an RTP packet when we_sent is false, it adds itself to the sender table and sets we_sent to true. The reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed to possibly reduce the delay before sending an SR packet 💜. Every time another RTP packet is sent, the time of that transmission is kept in the table. The normal sender timeout algorithm is then applied to the participant: if an RTP packet hasn't been transmitted since time tc - 2T, the participant removes itself from the sender table, decrements the sender count, and sets we_sent to false 💀.
6.3.9 Allocation of Source Description Bandwidth 🍓
This spec defines several source description (SDES) items on top of the mandatory CNAME item, like NAME (personal name) and EMAIL (email address). It also gives you a way to define brand new application-specific RTCP packet types 🌈. Applications should be careful about how much control bandwidth they give to this extra info, because it slows down how fast reception reports and CNAME get sent, and that hurts the protocol's performance. It is RECOMMENDED that no more than 20% of the RTCP bandwidth allocated to a single participant be used to carry the additional information. Also, it is not intended that every SDES item gets included in every application. The ones that do get included SHOULD be assigned a fraction of the bandwidth according to their utility. Instead of estimating these fractions dynamically, it is recommended that the percentages be translated statically into report interval counts based on the typical length of an item 🔥.
For example, an application might be designed to send only CNAME, NAME, and EMAIL, and nothing else 💅. NAME might get way higher priority than EMAIL, since NAME is shown all the time in the app's user interface while EMAIL only shows up when someone asks for it. At every RTCP interval, an RR packet and an SDES packet with the CNAME item get sent. For a small session running at the minimum interval, that's every 5 seconds on average. Every third interval (15 seconds), one extra item gets included in the SDES packet. Seven out of eight times that's the NAME item, and every eighth time (2 minutes) it's the EMAIL item 😭.
When multiple applications work together using cross-application binding through a common CNAME for each participant (say, in a multimedia conference with an RTP session for each medium), the additional SDES info MAY be sent in only one RTP session. The other sessions would carry only the CNAME item 🦋. This approach especially should be applied to the multiple sessions of a layered encoding scheme (see Section 2.4) ✨.
6.4 Sender and Receiver Reports 🎀
RTP receivers give reception quality feedback using RTCP report packets, which come in one of two forms depending on whether the receiver is also a sender 👑. The only difference between the sender report (SR) and receiver report (RR) forms, besides the packet type code, is that the sender report includes a 20-byte sender information section for use by active senders. An SR gets issued if a site has sent any data packets during the interval since issuing the last report or the previous one. Otherwise, an RR gets issued 🌸.
Both the SR and RR forms include zero or more reception report blocks, one for each synchronization source this receiver has gotten RTP data packets from since the last report. Reports are not issued for contributing sources listed in the CSRC list. Each reception report block gives statistics about the data received from the particular source named in that block 🧚. Since a maximum of 31 reception report blocks fit in an SR or RR packet, additional RR packets SHOULD be stacked after the initial SR or RR packet as needed to contain the reception reports for all sources heard during the interval since the last report. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without going over the MTU of the network path, then only the subset that fits into one MTU SHOULD be included in each interval. Those subsets SHOULD be selected round-robin across multiple intervals so every source gets reported 💖.
The next sections define the formats of the two reports, how they can be extended in a profile-specific way if an app needs extra feedback info, and how the reports can be used. Details about reception reporting by translators and mixers are in Section 7 🦋.
6.4.1 SR: Sender Report RTCP Packet 💌
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The sender report packet is made up of three sections, possibly followed by a fourth profile-specific extension section if one's defined 🧩. The first section, the header, is 8 octets long. Here's what the fields mean ✨:
version (V): 2 bits Tells you which version of RTP this is. It's the same in RTCP packets as in RTP data packets. The version defined by this spec is two (2) 💜.
padding (P): 1 bit If the padding bit is set, this individual RTCP packet has some extra padding octets at the end. They aren't part of the control info, but they are counted in the length field. The last octet of the padding is a count of how many padding octets should be ignored, including itself (it'll be a multiple of four). Padding might be needed by some encryption algorithms that use fixed block sizes 🔐. In a compound RTCP packet, padding is only required on one individual packet, because the compound packet is encrypted as a whole for the method in Section 9.1. So padding MUST only be added to the last individual packet, and if padding is added to that packet, the padding bit MUST be set only on that packet. This convention helps the header validity checks described in Appendix A.2 and lets you detect packets from some early implementations that incorrectly set the padding bit on the first individual packet and add padding to the last individual packet 🙈.
reception report count (RC): 5 bits The number of reception report blocks in this packet. A value of zero is valid 🍓.
packet type (PT): 8 bits Holds the constant 200 to identify this as an RTCP SR packet 👑.
length: 16 bits 🎀 Okay so this is the length of the RTCP packet in 32-bit words minus one, and that includes the header and any padding. The minus one is giving main character energy 👑 because it makes zero a valid length, which keeps a compound RTCP packet scan from looping forever 🔁. Counting in 32-bit words means there's no separate check for a multiple of 4 ✨
SSRC: 32 bits 🦋 This is the synchronization source identifier for whoever sent this SR packet 💌
Next up is the sender information 💕 It's 20 octets long, shows up in every single sender report packet, and summarizes the data this sender has transmitted 📊 Here's what each field means:
NTP timestamp: 64 bits ⏰ This is the wallclock time (see Section 4) for when the report got sent. Receivers can pair it with the timestamps coming back in reception reports from other receivers to measure the round-trip propagation to those receivers 🏓 Receivers should expect that the accuracy of this timestamp may be way less precise than the NTP timestamp's resolution 🙈 The measurement uncertainty isn't included because it might not even be known 🤷♀️
If a system has no concept of wallclock time but does have some system-specific clock, like "system uptime," a sender MAY use that clock as a reference to calculate relative NTP timestamps. Yes, it's allowed! 🌸 It's important to pick a commonly used clock, because if separate implementations are making the individual streams of a multimedia session, everyone needs to use the same clock so it all lines up 🫶
Heads up, bestie 🚨 Until the year 2036, relative and absolute timestamps differ in the high bit, so (invalid) comparisons will show a huge fake difference. By then, hopefully nobody needs relative timestamps anymore 🙏 And a sender that has no notion of wallclock or elapsed time MAY set the NTP timestamp to zero 🧚
RTP timestamp: 32 bits 🎶 This one matches the same moment as the NTP timestamp, but it's in the same units and has the same random offset as the RTP timestamps in data packets. This correspondence can be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized 🎬 Media-independent receivers can also use it to estimate the nominal RTP clock frequency 🔢 Note that in most cases, this timestamp won't equal the RTP timestamp in any adjacent data packet. Instead, it MUST be calculated from the corresponding NTP timestamp, using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant ⏱️
sender's packet count: 32 bits 📦 This is the total number of RTP data packets the sender has transmitted since it started transmitting, up until this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier 🔄
sender's octet count: 32 bits 🧮 This is the total number of payload octets (so not counting header or padding) sent in RTP data packets since the sender started transmitting, up until this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier 🔄 This field can be used to estimate the average payload data rate 📈
The third section has zero or more reception report blocks 🎁 It depends on how many other sources this sender has heard from since the last report. Each block shares stats on receiving RTP packets from one synchronization source 💅 Receivers SHOULD NOT carry over statistics when a source changes its SSRC identifier because of a collision 🚫 Here's what those stats look like:
SSRC_n (source identifier): 32 bits 🪪 The SSRC identifier of the source this reception report block is about 💜
fraction lost: 8 bits 📉 This is the fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent. It's a fixed point number with the binary point at the left edge of the field, which just means you take the integer part after multiplying the loss fraction by 256 ✨ That fraction is the number of packets lost divided by the number of packets expected, as defined in the next paragraph. There's an implementation in Appendix A.3 if you want to peek 👀 If the loss is negative because of duplicates, the fraction lost is set to zero. Also, a receiver can't tell whether any packets were lost after the last one it received, and there won't be a reception report block issued for a source if every packet from that source sent during the last reporting interval got lost 😭
cumulative number of packets lost: 24 bits 💔 This is the total number of RTP data packets from source SSRC_n lost since the beginning of reception. It's defined as the number of packets expected minus the number of packets actually received, where received includes any that are late or duplicates. So packets that show up late don't count as lost, and the loss can go negative if there are duplicates 🙃 The number of packets expected is the extended last sequence number received (defined next) minus the initial sequence number received. You can calculate it the way Appendix A.3 shows 🧠
extended highest sequence number received: 32 bits 🔝 The low 16 bits hold the highest sequence number received in an RTP data packet from source SSRC_n. The most significant 16 bits extend that sequence number with the matching count of sequence number cycles, which can be kept according to the algorithm in Appendix A.1 🔁 Just a heads up that different receivers in the same session will make different extensions if their start times are really different 🕰️
interarrival jitter: 32 bits 🌊 This is an estimate of the statistical variance of the RTP data packet interarrival time. It's measured in timestamp units and expressed as an unsigned integer. The interarrival jitter J is the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. As the equation below shows, this is the same as the difference in the "relative transit time" for the two packets. The relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at arrival, measured in the same units 🚗
If Si is the RTP timestamp from packet i, and Ri is the arrival time in RTP timestamp units for packet i, then for two packets i and j, D can be written as:
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)The interarrival jitter SHOULD be calculated continuously as each data packet i comes in from source SSRC_n. It uses this difference D for that packet and the previous packet i-1, in order of arrival (not necessarily sequence order), with this formula:
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16Whenever a reception report gets issued, the current value of J is sampled 📸
The jitter calculation MUST conform to the formula specified here, so that profile-independent monitors can make valid interpretations of reports coming from different implementations 🔍 This algorithm is the optimal first-order estimator, and the gain parameter 1/16 gives a good noise reduction ratio while still converging at a reasonable rate [22] 🧪 A sample implementation is in Appendix A.8. See Section 6.4.4 for a discussion of how varying packet duration and delay before transmission affect things 💫
last SR timestamp (LSR): 32 bits ⏳ This is the middle 32 bits out of the 64 in the NTP timestamp (as explained in Section 4) that came in as part of the most recent sender report (SR) packet from source SSRC_n. If no SR has been received yet, the field is set to zero 0️⃣
delay since last SR (DLSR): 32 bits 🕐 This is the delay, in units of 1/65536 seconds, between receiving the last SR packet from source SSRC_n and sending this reception report block. If no SR packet has been received yet from SSRC_n, the DLSR field is set to zero 💤
Let SSRC_r be the receiver issuing this receiver report. Source SSRC_n can work out the round-trip propagation delay to SSRC_r by recording the time A when this reception report block arrives 📬 It calculates the total round-trip time A-LSR using the LSR field, then subtracts DLSR to leave the round-trip propagation delay as (A - LSR - DLSR). Fig. 2 shows this, and times appear in both a hexadecimal representation of the 32-bit fields and the equivalent floating-point decimal representation. Colons mean a 32-bit field is split into a 16-bit integer part and a 16-bit fraction part 🪄
This can be used as a rough measure of distance to cluster receivers, although some links have very asymmetric delays, so don't take it as gospel 🙃
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992005.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
A 0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 ( 5.250 s)
LSR -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x0006:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation6.4.2 RR: Receiver Report RTCP Packet 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |6.4.2 RR: Receiver Report RTCP Packet (the rest of the diagram) 💖
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The RR packet is basically the SR's twin 👯♀️, just with packet type 201. The big difference is that the five words of sender info are gone, which means no NTP and RTP timestamps and no sender's packet and octet counts. Everything else means exactly what it means in SR ✨.
An empty RR (RC = 0) MUST go at the very front of a compound RTCP packet whenever there's no data transmission or reception to report 🫶. No exceptions, bestie 💅.
6.4.3 Extending the Sender and Receiver Reports ✨
A profile SHOULD define profile-specific extensions to the sender report and the receiver report if there's extra info that needs to be reported regularly about the sender or the receivers 🌸. This method SHOULD be used instead of defining a brand-new RTCP packet type, because it's way lighter 🪶. It needs:
- fewer octets in the packet (no RTCP header or SSRC field);
- simpler and faster parsing, because apps running under that profile are programmed to always look for the extension fields in the directly accessible spot after the reception reports 🚀.
The extension is a fourth section at the end of the SR or RR packet, after the reception report blocks (if there are any) 🧚. If the sender needs to include extra sender info, it goes first in the extension section for SR packets. For RR packets, that part isn't there at all 🙈. If info about receivers needs to be included, that data SHOULD be structured as an array of blocks parallel to the existing array of reception report blocks. So the number of blocks is indicated by the RC field 💜.
6.4.4 Analyzing Sender and Receiver Reports 🔍
Reception quality feedback is expected to be useful not just for the sender, but also for other receivers and third-party monitors 👀. The sender can tweak its transmissions based on the feedback. Receivers can figure out whether problems are local, regional, or global. Network managers can use profile-independent monitors that only receive the RTCP packets, not the RTP data packets, to check how their networks handle multicast distribution 🌈.
Cumulative counts show up in both the sender info and the receiver report blocks, so you can calculate differences between any two reports. That lets you measure over both short and long time periods, and it keeps things resilient if a report gets lost 🦋. The difference between the last two reports received can estimate the recent quality of the distribution. The NTP timestamp is included so rates can be calculated from those differences over the interval between two reports. Since that timestamp doesn't depend on the clock rate of the data encoding, you can build encoding- and profile-independent quality monitors 💅.
Here's an example: the packet loss rate over the interval between two reception reports. The difference in the cumulative number of packets lost gives the number lost during that interval. The difference in the extended last sequence numbers received gives the number of packets expected during the interval. The ratio of those two is the packet loss fraction over the interval. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise it may not 🤷♀️. You get the loss rate per second by dividing the loss fraction by the difference in NTP timestamps, in seconds. The number of packets received is the number expected minus the number lost. The number expected can also help you judge how statistically valid any loss estimate is. For example, 1 out of 5 packets lost has way lower significance than 200 out of 1000 📊.
From the sender info, a third-party monitor can calculate the average payload data rate and the average packet rate over an interval, all without receiving the data 🕵️♀️. Dividing one by the other gives the average payload size. If you can assume that packet loss doesn't depend on packet size, then the number of packets a particular receiver gets, times the average payload size (or the corresponding packet size), gives the apparent throughput available to that receiver 🍓.
Cumulative counts let you measure long-term packet loss using differences between reports. The fraction lost field is the short-term version, giving you a measurement from a single report ⭐. This matters more as sessions scale up. Reception state might not be kept for every receiver, or the interval between reports might get so long that only one report was received from a given receiver 🫠.
The interarrival jitter field is a second short-term measure of network congestion 🌊. Packet loss tracks persistent congestion, while jitter tracks transient congestion. Jitter can flag congestion before it turns into packet loss 🚨. The interarrival jitter field is only a snapshot of the jitter at the moment of a report, so it isn't meant to be taken quantitatively. It's meant for comparing across several reports from one receiver over time, or across multiple receivers at the same time (for example, all within one network) 🔁. To make comparisons across receivers work, it's important that the jitter is calculated with the same formula by all receivers 🤝.
Jitter is calculated from the RTP timestamp, which marks the instant the first data in the packet was sampled. So any variation in delay between that sampling instant and when the packet is actually transmitted will affect the calculated jitter 😭. This happens with audio packets of varying duration. It also happens with video encodings, because every packet of one frame carries the same timestamp, but those packets aren't all transmitted at the same time 🎬. That variation in transmission delay does reduce how accurately the jitter measures the network by itself. It's still appropriate to include it, though, because the receiver buffer has to accommodate it 🧸. When jitter is used as a comparative measure, the (constant) component from variation in transmission delay subtracts out, so a change in the network jitter component can be seen, unless that change is relatively small. If the change is small, it's likely inconsequential 🌸.
6.5 SDES: Source Description RTCP Packet 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_1 |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_2 |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+The SDES packet is a three-level structure 🧁: a header, then zero or more chunks, and each chunk is made of items describing the source identified in that chunk. The items each get their own section later on 💖.
version (V), padding (P), length: same as the SR packet (see Section 6.4.1) ✨.
packet type (PT): 8 bits. It holds the constant 202, which identifies this as an RTCP SDES packet 🏷️.
source count (SC): 5 bits. This is how many SSRC/CSRC chunks are in this SDES packet. A value of zero is valid but useless 🙃.
Each chunk is an SSRC/CSRC identifier followed by a list of zero or more items, which carry info about that SSRC/CSRC 🦋. Every chunk starts on a 32-bit boundary. Each item has an 8-bit type field, an 8-bit octet count for the length of the text (not counting this two-octet header), and then the text itself 🌈. The text can be no longer than 255 octets, which fits with the need to keep RTCP bandwidth use in check 🌸.
The text is encoded with UTF-8, as specified in RFC 2279 [5] 🌍. US-ASCII is a subset of that, so it doesn't need any extra encoding. Multi-octet encodings are flagged by setting the most significant bit of a character to one 🔥.
Items are contiguous, meaning items aren't individually padded to a 32-bit boundary 🧩. Text isn't null terminated, because some multi-octet encodings include null octets 🙈. The list of items in each chunk MUST be terminated by one or more null octets, and the first of those is read as an item type of zero, which marks the end of the list 🛑. No length octet follows that null item type octet. But additional null octets MUST be included as needed to pad out to the next 32-bit boundary 💅. This padding is separate from the padding flagged by the P bit in the RTCP header, so keep them apart 🧠. A chunk with zero items (four null octets) is valid but useless 🫠.
End systems send one SDES packet with their own source identifier, which is the same as the SSRC in the fixed RTP header 📮. A mixer sends one SDES packet containing a chunk for each contributing source it's getting SDES info from. If there are more than 31 such sources, it sends multiple complete SDES packets in the format above instead (see Section 7) 🎀.
The SDES items currently defined are covered in the next sections 🌷. Only the CNAME item is mandatory. Some items might only be useful for particular profiles, but all the item types come from one common space. That's so they can be shared and so profile-independent apps stay simple 👑. A profile can define extra items by registering the type numbers with IANA, as described in Section 15 💜.
6.5.1 CNAME: Canonical End-Point Identifier SDES Item ✨
okay so CNAME is the Canonical End-Point Identifier and it's giving main character energy 💖 Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The CNAME identifier has these properties 🌸
- Bestie, the randomly allocated SSRC can change if a conflict gets discovered or if a program restarts, so the CNAME MUST be included to bind the SSRC to an identifier for the source (sender or receiver) that stays constant 🫶
- Like the SSRC, the CNAME SHOULD also be unique among all participants within one RTP session ✨
- To bind together the multiple media tools one participant uses across a set of related RTP sessions, the CNAME SHOULD be fixed for that participant 🦋
- For third-party monitoring, the CNAME SHOULD be suitable for either a program or a person to locate the source 👑
So the CNAME SHOULD be derived algorithmically and not entered manually, when possible. To meet these requirements, the following format SHOULD be used unless a profile specifies an alternate syntax or semantics 💅 The CNAME item SHOULD have the format "user@host", or "host" if a user name is not available, as on single-user systems.
For both formats, "host" is either the fully qualified domain name of the host where the real-time data comes from, formatted according to the rules in RFC 1034 [6], RFC 1035 [7] and Section 2.1 of RFC 1123 [8]. Or it's the standard ASCII representation of the host's numeric address on the interface used for the RTP communication. For IP Version 4, that's "dotted decimal" (a.k.a. dotted quad), and for IP Version 6, addresses are written as groups of hexadecimal digits separated by colons (with variations as detailed in RFC 3513 [23]). Other address types are expected to have ASCII representations that are mutually unique 🧚
The fully qualified domain name is more convenient for humans and may avoid the need to send a NAME item too, but it can be difficult or impossible to get reliably in some operating environments. Apps that might run in those environments SHOULD use the ASCII representation of the address instead 🙈
Examples are "doe@sleepy.example.com", "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system with no user name, you'd get "sleepy.example.com", "192.0.2.89" or "2201:056D::112E:144A:1E24" 🍓
The user name SHOULD be in a form that a program like "finger" or "talk" could use, meaning it's typically the login name rather than the personal name. The host name isn't necessarily the same as the one in the participant's email address 💜
Heads up, though: this syntax won't give unique identifiers for each source if an application lets a user make multiple sources from one host. That kind of app would have to rely on the SSRC to tell sources apart, or its profile would have to specify extra CNAME syntax 💀
If each application makes its CNAME on its own, the CNAMEs may not match up, and matching is what you'd need to bind together multiple media tools belonging to one participant across related RTP sessions. If cross-media binding is required, each tool's CNAME may need to be configured externally with the same value by a coordination tool 🌈
Application writers should know that private network address assignments, like the Net-10 assignment proposed in RFC 1918 [24], can create network addresses that aren't globally unique. That leads to non-unique CNAMEs when hosts with private addresses and no direct IP connectivity to the public Internet have their RTP packets forwarded to the public Internet through an RTP-level translator. (See also RFC 1627 [25].) To handle this, applications MAY provide a way to configure a unique CNAME. But the burden is on the translator to translate CNAMEs from private addresses to public addresses if necessary, so private addresses don't get exposed 🔥
6.5.2 NAME: User Name SDES Item 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This is the real name used to describe the source, like "John Doe, Bit Recycler". It can be in any form the user wants 🫶 For apps like conferencing, this is the most useful form for participant lists, so it might get sent most often out of all the items other than CNAME. Profiles MAY set those priorities 🌸 The NAME value is expected to stay constant at least for the whole session. It SHOULD NOT be relied on to be unique among all participants in the session 🙈
6.5.3 EMAIL: Electronic Mail Address SDES Item 💌
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The email address is formatted according to RFC 2822 [9], for example "John.Doe@example.com". The EMAIL value is expected to stay the same for the duration of a session ✨
6.5.4 PHONE: Phone Number SDES Item 📞
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The phone number SHOULD be formatted with the plus sign replacing the international access code. For example, "+1 908 555 1212" for a number in the United States 🇺🇸
6.5.5 LOC: Geographic User Location SDES Item 📍
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Different apps need different levels of detail here, bestie 🦋 For conference apps, something like "Murray Hill, New Jersey" might be enough, while for an active badge system, something like "Room 2A244, AT&T BL MH" might be the vibe. The degree of detail is left to the implementation and/or user, but the format and content MAY be prescribed by a profile. The LOC value is expected to stay constant for the duration of a session, except for mobile hosts 🌍
6.5.6 TOOL: Application or Tool Name SDES Item 🛠️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length |name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This is a string giving the name and maybe the version of the app making the stream, like "videotool 1.2". It can be super useful for debugging, and it's kind of like the Mailer or Mail-System-Version SMTP headers 🤓 The TOOL value is expected to stay constant for the duration of the session 💜
6.5.7 NOTE: Notice/Status SDES Item 📢
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+These semantics are suggested for this item, but these or other semantics MAY be explicitly defined by a profile. The NOTE item is for transient messages about the source's current state, like "on the phone, can't talk" 📱 Or, during a seminar, it might carry the title of the talk 🎤 It should be used only to carry exceptional information. It SHOULD NOT be included routinely by all participants, because that would slow down how fast reception reports and CNAME get sent, and that would hurt the protocol's performance 😭 Specifically, it SHOULD NOT go in a user's configuration file, or be automatically generated like a quote-of-the-day 🙅♀️
Real talk: the NOTE item is only for when it really matters, or everyone's reports slow to a crawl.
Since the NOTE item might be important to display while it's active, the rate of other non-CNAME items, like NAME, can get reduced so the NOTE item can take up that part of the RTCP bandwidth 🦋 When the transient message goes inactive, the NOTE item SHOULD keep getting sent a few times at the same repetition rate, but with a zero-length string to signal receivers. Receivers SHOULD also consider the NOTE item inactive if it hasn't been received for a small multiple of the repetition rate, or maybe 20-30 RTCP intervals ⏳
6.5.8 PRIV: Private Extensions SDES Item 🔒
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This item is for experimental or app-specific SDES extensions 🧪 It holds a prefix (a length-string pair), followed by the value string that fills the rest of the item and carries the info you actually want. The prefix length field is 8 bits long. The prefix string is a name picked by whoever defines the PRIV item, and it has to be unique compared to other PRIV items that app might receive. The app creator might use the app name plus an extra subtype ID if needed. Or, as an alternative, it's RECOMMENDED that others pick a name based on the entity they represent, then coordinate how that name gets used within that entity 🌸
Heads up: the prefix eats into the item's total length of 255 octets, so the prefix should be kept as short as possible ✂️ This facility and the constrained RTCP bandwidth SHOULD NOT be overloaded. It's not meant to cover all the control communication needs of every app 💅
SDES PRIV prefixes will not be registered by IANA. If some form of the PRIV item turns out to be generally useful, it SHOULD instead get a regular SDES item type registered with IANA, so no prefix is needed. That makes things simpler to use and boosts transmission efficiency 🚀✨
6.6. BYE: Goodbye RTCP Packet 👋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+okay so the BYE packet is literally the "I'm leaving the group chat now" message 💔 It tells everyone that one or more sources are no longer active. Bye bye, sources 🫠
- version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
- packet type (PT): 8 bits Contains the constant 203 to identify this as an RTCP BYE packet.
- source count (SC): 5 bits The number of SSRC/CSRC identifiers included in this BYE packet. A count value of zero is valid, but useless 💀
The rules for when a BYE packet should be sent are specified in Sections 6.3.7 and 8.2. 📖
Now the mixer stuff, which is giving main character energy 👑 If a BYE packet is received by a mixer, the mixer SHOULD forward the BYE packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts down, it SHOULD send a BYE packet listing all contributing sources it handles, as well as its own SSRC identifier. Optionally, the BYE packet MAY include an 8-bit octet count followed by that many octets of text indicating the reason for leaving, e.g., "camera malfunction" or "RTP loop detected" 🎀 The string has the same encoding as that described for SDES.
Padding alert 🧸 If the string fills the packet to the next 32-bit boundary, the string is not null terminated. If not, the BYE packet MUST be padded with null octets to the next 32-bit boundary. This padding is separate from that indicated by the P bit in the RTCP header.
6.7. APP: Application-Defined RTCP Packet 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The APP packet is the experimental playground 🧪 for brand new apps and features, and you don't need to register a packet type value to use it. APP packets with unrecognized names SHOULD be ignored. Once it's been tested and there's a good reason for wider use, it is RECOMMENDED that each APP packet be redefined without the subtype and name fields and registered with IANA using an RTCP packet type. Glow-up arc 💅✨
- version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
- subtype: 5 bits May be used as a subtype to allow a set of APP packets to be defined under one unique name, or for any application-dependent data.
- packet type (PT): 8 bits Contains the constant 204 to identify this as an RTCP APP packet.
- name: 4 octets A name chosen by the person defining the set of APP packets, so it stays unique compared with other APP packets that this application might receive. The application creator might choose to use the application name, and then coordinate the allocation of subtype values to others who want to define new packet types for the application. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity. The name is interpreted as a sequence of four ASCII characters, with uppercase and lowercase characters treated as distinct 🔠
- application-dependent data: variable length Application-dependent data may or may not appear in an APP packet. It is interpreted by the application and not RTP itself. It MUST be a multiple of 32 bits long 🫶
7. RTP Translators and Mixers ✨
In addition to end systems, RTP supports the notion of "translators" and "mixers", which could be considered as "intermediate systems" at the RTP level. Yes, this adds some complexity, but the need for these functions was clearly established by experiments with multicast audio and video applications on the Internet 🌈 The example uses of translators and mixers in Section 2.3 come from firewalls and low bandwidth connections, and both of those are likely to stick around.
7.1. General Description 🦋
An RTP translator/mixer connects two or more transport-level "clouds". Typically, each cloud is defined by a common network and transport protocol (e.g., IP/UDP) plus a multicast address and transport level destination port, or a pair of unicast addresses and ports. (Network-level protocol translators, such as IP version 4 to IP version 6, may be present within a cloud invisibly to RTP.) One system may serve as a translator or mixer for a number of RTP sessions, but each one is considered a logically separate entity 🍓
Now, to avoid creating a loop when a translator or mixer is installed, the following rules MUST be observed 🚨
- Each of the clouds connected by translators and mixers participating in one RTP session either MUST be distinct from all the others in at least one of these parameters (protocol, address, port), or MUST be isolated at the network level from the others.
- A derivative of the first rule is that there MUST NOT be multiple translators or mixers connected in parallel unless, by some arrangement, they partition the set of sources to be forwarded.
Similarly, all RTP end systems that can communicate through one or more RTP translators or mixers share the same SSRC space. That means the SSRC identifiers MUST be unique among all these end systems. Section 8.2 describes the collision resolution algorithm by which SSRC identifiers are kept unique and loops are detected 🔍
There may be many varieties of translators and mixers designed for different purposes and applications. Some examples are adding or removing encryption, changing the encoding of the data or the underlying protocols, or replicating between a multicast address and one or more unicast addresses. The big difference between the two is that a translator passes through the data streams from different sources separately, whereas a mixer combines them to form one new stream 💜
Translator: Forwards RTP packets with their SSRC identifier intact. This makes it possible for receivers to identify individual sources, even though packets from all the sources pass through the same translator and carry the translator's network source address. Some kinds of translators will pass through the data untouched, but others MAY change the encoding of the data and thus the RTP data payload type and timestamp. If multiple data packets are re-encoded into one, or vice versa, a translator MUST assign new sequence numbers to the outgoing packets. Losses in the incoming packet stream may induce corresponding gaps in the outgoing sequence numbers. Receivers cannot detect the presence of a translator unless they know by some other means what payload type or transport address was used by the original source 🫥
Mixer: Receives streams of RTP data packets from one or more sources, possibly changes the data format, combines the streams in some manner, and then forwards the combined stream. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream, so it is the synchronization source. Thus, all data packets forwarded by a mixer MUST be marked with the mixer's own SSRC identifier. In order to preserve the identity of the original sources contributing to the mixed packet, the mixer SHOULD insert their SSRC identifiers into the CSRC identifier list following the fixed RTP header of the packet. A mixer that is also itself a contributing source for some packet SHOULD explicitly include its own SSRC identifier in the CSRC list for that packet 🎧
For some applications, it MAY be acceptable for a mixer not to identify sources in the CSRC list. However, this introduces the danger that loops involving those sources could not be detected 😭
The advantage of a mixer over a translator for applications like audio is that the output bandwidth is limited to that of one source, even when multiple sources are active on the input side. This may be important for low-bandwidth links 🐢 The disadvantage is that receivers on the output side don't have any control over which sources are passed through or muted, unless some mechanism is implemented for remote control of the mixer. The regeneration of synchronization information by mixers also means that receivers can't do inter-media synchronization of the original streams. A multi-media mixer could do it 🙈
[E1] [E6]
| |
E1:17 | E6:15 |
| | E6:15
V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
(M1)-------------><T1>-----------------><T2>-------------->[E7]
^ ^ E4:47 ^ E4:47
E2:1 | E4:47 | | M3:89 (64,45)
| | |
[E2] [E4] M3:89 (64,45) |
| legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer)
| E5:45 <Translator>
|
[E5] source: SSRC (CSRCs)
------------------->Figure 3: Sample RTP network with end systems, mixers and translators 🗺️
A collection of mixers and translators is shown in Fig. 3 to illustrate their effect on SSRC and CSRC identifiers. In the figure, end systems are shown as rectangles (named E), translators as triangles (named T), and mixers as ovals (named M). The notation "M1: 48(1,17)" designates a packet originating from a mixer M1, identified by M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17, copied from the SSRC identifiers of packets from E1 and E2. It's giving organized chaos, but make it make sense 🧚♀️💖
7.2. RTCP Processing in Translators ✨
Okay so besides forwarding the data packets (maybe modified, bestie 👀), translators and mixers MUST also process RTCP packets 💅. A lot of the time they'll take apart the compound RTCP packets that come in from end systems to collect the SDES info and to modify the SR or RR packets. Sending that info back out can get triggered by a packet arriving, or by the translator's or mixer's own RTCP interval timer ⏰.
A translator that doesn't modify the data packets, like one that just copies between a multicast address and a unicast address, MAY simply forward RTCP packets unmodified too 🦋. But a translator that transforms the payload in some way MUST make corresponding transformations in the SR and RR info so it still reflects the characteristics of the data and the reception quality 📊. These translators MUST NOT simply forward RTCP packets, periodt 💀. In general, a translator SHOULD NOT aggregate SR and RR packets from different sources into one packet, since that would make the propagation delay measurements based on the LSR and DLSR fields less accurate 🙈.
- SR sender information: A translator doesn't generate its own sender information. It just forwards the SR packets it gets from one cloud to the others 🔁. The SSRC is left intact, but the sender information MUST be modified if the translation requires it. If a translator changes the data encoding, it MUST change the "sender's byte count" field. If it also combines several data packets into one output packet, it MUST change the "sender's packet count" field. If it changes the timestamp frequency, it MUST change the "RTP timestamp" field in the SR packet 🎀.
- SR/RR reception report blocks: A translator forwards reception reports it gets from one cloud to the others. Note that these flow in the opposite direction to the data, so keep that in mind 🧠. The SSRC is left intact. If a translator combines several data packets into one output packet, and therefore changes the sequence numbers, it MUST make the inverse manipulation for the packet loss fields and the "extended last sequence number" field. This may be complex, not gonna lie 😭. In the extreme case there may be no meaningful way to translate the reception reports, so the translator MAY pass on no reception report at all, or a synthetic report based on its own reception 🫠. The general rule is to do what makes sense for a particular translation ✨.
A translator doesn't require an SSRC identifier of its own, but it MAY choose to allocate one for the purpose of sending reports about what it has received 🧚. These would be sent to all the connected clouds, each one corresponding to the translation of the data stream as sent to that cloud, since reception reports are normally multicast to all participants 📣.
- SDES: Translators typically forward the SDES info they receive from one cloud to the others without any changes, but they MAY, for example, decide to filter non-CNAME SDES info if bandwidth is limited 💸. The CNAMEs MUST be forwarded so that SSRC identifier collision detection can work 🔍. A translator that generates its own RR packets MUST send SDES CNAME info about itself to the same clouds it sends those RR packets to 💜.
- BYE: Translators forward BYE packets unchanged 👋. A translator that is about to stop forwarding packets SHOULD send a BYE packet to each connected cloud containing all the SSRC identifiers that were previously being forwarded to that cloud, including the translator's own SSRC identifier if it sent reports of its own 🥲.
- APP: Translators forward APP packets unchanged 💅.
7.3. RTCP Processing in Mixers 🎧
Since a mixer generates a brand new data stream of its own, it doesn't pass through SR or RR packets at all. Instead it generates new info for both sides 🌈.
- SR sender information: A mixer doesn't pass through sender info from the sources it mixes, because the characteristics of the source streams get lost in the mix 🌀. As a synchronization source, the mixer SHOULD generate its own SR packets with sender info about the mixed data stream, and send them in the same direction as the mixed stream 🎶.
- SR/RR reception report blocks: A mixer generates its own reception reports for sources in each cloud, and sends them out only to that same cloud. It MUST NOT send these reception reports to the other clouds, and it MUST NOT forward reception reports from one cloud to the others, because the sources wouldn't be SSRCs there (only CSRCs) 🙅♀️.
- SDES: Mixers typically forward the SDES info they receive from one cloud to the others without changes, but they MAY, for example, decide to filter non-CNAME SDES info if bandwidth is limited 💸. The CNAMEs MUST be forwarded so SSRC identifier collision detection can work 🔍. (An identifier in a CSRC list generated by a mixer might collide with an SSRC identifier generated by an end system, so this really matters 😤.) A mixer MUST send SDES CNAME info about itself to the same clouds it sends SR or RR packets to 💖.
Since mixers don't forward SR or RR packets, they'll typically be pulling SDES packets out of a compound RTCP packet 🧩. To keep overhead low, chunks from the SDES packets MAY be aggregated into a single SDES packet, which is then stacked on an SR or RR packet originating from the mixer 🥞. A mixer that aggregates SDES packets will use more RTCP bandwidth than an individual source, because the compound packets will be longer. That's totally fine though, since the mixer represents multiple sources 🫶. Similarly, a mixer that passes through SDES packets as they're received will be transmitting RTCP packets at a higher rate than a single source would, and again that's correct, since the packets come from multiple sources 🌸. The RTCP packet rate may be different on each side of the mixer 🪞.
A mixer that does not insert CSRC identifiers MAY also refrain from forwarding SDES CNAMEs. In this case the SSRC identifier spaces in the two clouds are independent 🏝️. As mentioned earlier, this mode of operation creates a danger that loops can't be detected 🌀😱.
- BYE: Mixers MUST forward BYE packets 👋. A mixer that is about to stop forwarding packets SHOULD send a BYE packet to each connected cloud containing all the SSRC identifiers that were previously being forwarded to that cloud, including the mixer's own SSRC identifier if it sent reports of its own 🥹.
- APP: The treatment of APP packets by mixers is application-specific 🤷♀️.
7.4. Cascaded Mixers 🍰
An RTP session can involve a whole collection of mixers and translators, as shown in Fig. 3 🗺️. If two mixers are cascaded, like M2 and M3 in the figure, packets received by a mixer may already have been mixed and may include a CSRC list with multiple identifiers. The second mixer SHOULD build the CSRC list for the outgoing packet using the CSRC identifiers from already-mixed input packets, and the SSRC identifiers from unmixed input packets 🧁. This is shown in the output arc from mixer M3 labeled M3:89(64,45) in the figure 👀. As with mixers that aren't cascaded, if the resulting CSRC list has more than 15 identifiers, the remainder cannot be included 🚫.
8. SSRC Identifier Allocation and Use ✨
The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session 🔐. It's crucial that the number be chosen with care, so participants on the same network, or starting at the same time, aren't likely to pick the same number 😮💨.
It's not enough to use the local network address (like an IPv4 address) for the identifier, because the address may not be unique 🙅♀️. Since RTP translators and mixers let multiple networks with different address spaces interoperate, the allocation patterns for addresses within two spaces might result in a much higher collision rate than random allocation would 📈.
Multiple sources running on one host would also conflict 💥.
It's also not enough to get an SSRC identifier by just calling random() without carefully initializing the state 🙃. An example of how to generate a random identifier is presented in Appendix A.6 📖.
8.1. Probability of Collision 🎲
Since the identifiers are chosen randomly, it's possible that two or more sources will choose the same number 🤞. Collision has the highest probability when all sources are started simultaneously, for example when triggered automatically by some session management event 🚀. If N is the number of sources and L is the length of the identifier (here, 32 bits), the probability that two sources independently pick the same value can be approximated for large N [26] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is roughly 10**-4 📉.
The typical collision probability is much lower than the worst case above 🙌. When one new source joins an RTP session where all the other sources already have unique identifiers, the probability of collision is just the fraction of numbers used out of the space. Again, if N is the number of sources and L is the length of the identifier, the probability of collision is N / 2**L. For N=1000, the probability is roughly 2*10**-7 🌟.
The probability of collision is reduced even further by the chance for a new source to receive packets from other participants before it sends its first packet (either data or control) 👂. If the new source keeps track of the other participants (by SSRC identifier), then before transmitting its first packet it can verify that its identifier doesn't conflict with any that have been received, or else choose again 🔄.
8.2. Collision Resolution and Loop Detection 🛠️
Even though the probability of SSRC identifier collision is low, all RTP implementations MUST be prepared to detect collisions and take the appropriate actions to resolve them 🚨. If a source discovers at any time that another source is using the same SSRC identifier as its own, it MUST send an RTCP BYE packet for the old identifier and choose another random one 😤. (As explained below, this step is taken only once in case of a loop 🔁.) If a receiver discovers that two other sources are colliding, it MAY keep the packets from one and discard the packets from the other, when this can be detected by different source transport addresses or CNAMEs 🕵️♀️. The two sources are expected to resolve the collision so the situation doesn't last 🤝.
Because the random SSRC identifiers are kept globally unique for each RTP session, they can also be used to detect loops that may be introduced by mixers or translators 🌀. A loop causes duplication of data and control information, either unmodified or possibly mixed, as in the following examples:
- A translator may incorrectly forward a packet to the same multicast group from which it received the packet, either directly or through a chain of translators. In that case, the same packet appears several times, originating from different network sources 😵💫.
- Two translators incorrectly set up in parallel, i.e., with the same multicast groups on both sides, would both forward packets from one multicast group to the other. Unidirectional translators would produce two copies, and bidirectional translators would form a loop 🔁💀.
- A mixer can close a loop 🔁 by sending to the same transport destination it receives packets on, either directly or through another mixer or translator. In this case a source might show up both as an SSRC on a data packet and as a CSRC in a mixed data packet 😭
A source may discover that its own packets are being looped, or that packets from another source are being looped (a third-party loop). Both loops and collisions in the random selection of a source identifier result in packets arriving with the same SSRC identifier but a different source transport address. That address might belong to the end system that sent the packet or to an intermediate system 🧚
So if a source changes its source transport address, it MAY also choose a new SSRC identifier so it doesn't get read as a looped source 🦋 (This is not MUST because in some applications of RTP, sources are expected to change addresses during a session, so it's not a must-do.) Also, if a translator restarts and changes the source transport address it forwards on (like the UDP source port number), every one of those packets will look looped to receivers, because the SSRC identifiers were set by the original source and don't change. Keeping the source transport address fixed across restarts avoids this, but either way it gets sorted out after a timeout at the receivers ⏳
Loops or collisions happening on the far side of a translator or mixer can't be spotted with the source transport address if all the copies go through that translator or mixer. Still, collisions can show up when chunks from two RTCP SDES packets have the same SSRC identifier but different CNAMEs 👀
To detect and resolve these conflicts, an RTP implementation MUST include an algorithm similar to the one below, though the implementation MAY choose a different policy for which packets from colliding third-party sources are kept. The algorithm below ignores packets from a new source or loop that collides with an established source. It resolves collisions with the participant's own SSRC identifier by sending an RTCP BYE for the old identifier and picking a new one. But when the collision was caused by a loop of the participant's own packets, the algorithm only picks a new identifier once and then ignores packets from that looping source transport address. This is required to avoid a flood of BYE packets 🙅♀️
This algorithm needs a table indexed by the source identifier, holding the source transport addresses from the first RTP packet and first RTCP packet received with that identifier, plus other state for that source. Two source transport addresses are needed because, for example, the UDP source port numbers can be different on RTP and RTCP packets. It can be assumed that the network address is the same in both source transport addresses 🌸
Each SSRC or CSRC identifier received in an RTP or RTCP packet gets looked up in the source identifier table so the data or control information can be processed. The source transport address from the packet is compared with the matching one in the table to detect a loop or collision if they don't match. For control packets, each element with its own SSRC identifier, like an SDES chunk, needs its own lookup. (The SSRC identifier in a reception report block is an exception, because it identifies a source the reporter heard, and that SSRC is unrelated to the source transport address of the RTCP packet the reporter sent.) If the SSRC or CSRC isn't found, a new entry gets created. Table entries get removed when an RTCP BYE packet arrives with the matching SSRC identifier and a matching source transport address checks out, or after no packets have shown up for a relatively long time (see Section 6.2.1) 🗑️
Note that if two sources on the same host are transmitting with the same source identifier when a receiver starts up, the first RTP packet might come from one source while the first RTCP packet comes from the other. That would tie the wrong RTCP info to the RTP data. It should be rare and harmless enough to ignore 🤷♀️
To track loops of the participant's own data packets, the implementation MUST also keep a separate list of source transport addresses (not identifiers) that have been found to be conflicting. Like the source identifier table, two source transport addresses MUST be kept so conflicting RTP and RTCP packets are tracked separately. The conflicting address list should be short and usually empty. Each element in this list stores the source addresses plus the time the most recent conflicting packet arrived. An element MAY be removed from the list when no conflicting packet has come from that source for a time on the order of 10 RTCP report intervals (see Section 6.2) ⏰
For the algorithm as shown, the participant's own source identifier and state are assumed to be in the source identifier table. The algorithm could be restructured to first do a separate comparison against the participant's own source identifier 💅
if (SSRC or CSRC identifier is not found in the source
identifier table) {
create a new entry storing the data or control source
transport address, the SSRC or CSRC and other state;
}
/* Identifier is found in the table */
else if (table entry was created on receipt of a control packet
and this is the first data packet or vice versa) {
store the source transport address from this packet;
}
else if (source transport address from the packet does not match
the one saved in the table entry for this identifier) {
/* An identifier collision or a loop is indicated */
if (source identifier is not the participant's own) {
/* OPTIONAL error counter step */
if (source identifier is from an RTCP SDES chunk
containing a CNAME item that differs from the CNAME
in the table entry) {
count a third-party collision;
} else {
count a third-party loop;
}
abort processing of data packet or control element;
/* MAY choose a different policy to keep new source */
}
/* A collision or loop of the participant's own packets */
else if (source transport address is found in the list of
conflicting data or control source transport
addresses) {
/* OPTIONAL error counter step */
if (source identifier is not from an RTCP SDES chunk
containing a CNAME item or CNAME is the
participant's own) {
count occurrence of own traffic looped;
}
mark current time in conflicting address list entry;
abort processing of data packet or control element;
}
/* New collision, change SSRC identifier */
else {
log occurrence of a collision;
create a new entry in the conflicting data or control
source transport address list and mark current time;
send an RTCP BYE packet with the old SSRC identifier;
choose a new SSRC identifier;
create a new entry in the source identifier table with
the old SSRC plus the source transport address from
the data or control packet being processed;
}
}In this algorithm, packets from a newly conflicting source address get ignored, and packets from the original source address get kept. If no packets arrive from the original source for an extended period, its table entry times out and the new source can take over. That might happen if the original source detects the collision and moves to a new source identifier. Usually though, an RTCP BYE packet arrives from the original source to delete the state, so there's no need to wait for a timeout 🧹
If the original source address was received through a mixer (learned as a CSRC) and the same source later shows up directly, the receiver may be well advised to switch to the new source address, unless other sources in the mix would be lost. Also, for applications like telephony, where some sources (like mobile entities) may change addresses during an RTP session, the RTP implementation SHOULD modify the collision detection algorithm to accept packets from the new source transport address. To guard against flip-flopping between addresses when a genuine collision happens, the algorithm SHOULD include some means of detecting that case and avoiding the switch 🦋
When a new SSRC identifier is chosen because of a collision, the candidate identifier SHOULD first be looked up in the source identifier table to see if another source already uses it. If it does, another candidate MUST be generated and the process repeated 🔄
A loop of data packets to a multicast destination can cause severe network flooding 🌊 All mixers and translators MUST implement a loop detection algorithm like the one here so they can break loops. That should limit the excess traffic to no more than one duplicate copy of the original traffic, which may let the session continue so the cause of the loop can be found and fixed. But in extreme cases where a mixer or translator doesn't properly break the loop and high traffic levels result, end systems may need to stop transmitting data or control packets entirely. That call may depend on the application. An error condition SHOULD be indicated as appropriate. Transmission MAY be attempted again periodically after a long, random time (on the order of minutes) 💀
8.3 Use with Layered Encodings ✨
For layered encodings sent on separate RTP sessions (see Section 2.4), a single SSRC identifier space SHOULD be used across the sessions of all layers, and the core (base) layer SHOULD be used for SSRC identifier allocation and collision resolution 🍓 When a source discovers it has collided, it sends an RTCP BYE packet on only the base layer, but changes the SSRC identifier to the new value in all layers 🫶
9. Security ✨
Okay bestie, security time 🔐💖. Lower layer protocols may eventually hand us all the security goodies RTP could want: authentication, integrity, and confidentiality 🎀. These services have been specified for IP in [27].
The original audio and video apps for RTP needed confidentiality before IP had any of that, so the confidentiality service in the next section got defined for RTP and RTCP specifically 🦋. It's written down here to lock in what people were already doing 📝. New RTP apps MAY implement this RTP-specific confidentiality service for backward compatibility, and/or they MAY implement alternative security services 💅. The overhead for this confidentiality service is low, so if something better comes along and makes it obsolete, the penalty is minimal 🫶.
Future RTP can also get other services, other implementations of services, and other algorithms 🌈. The big one is SRTP [28], an RTP profile being developed to keep the RTP payload confidential while leaving the RTP header in the clear, so link-level header compression algorithms can still do their thing ✨. It's expected to be the right pick for lots of apps 👑. SRTP is built on AES and is stronger than the service described here 💪. No claim is made that the methods here fit any particular security need 🙈. A profile can say which services and algorithms apps should offer, and it can give guidance on using them properly 📋.
Key distribution and certificates are out of scope for this doc 🗝️.
9.1 Confidentiality 🔒
Confidentiality means only the intended receiver(s) can decode the packets. To everyone else, the packet has no useful info 🤫. Content confidentiality comes from encryption.
When you want to encrypt RTP or RTCP with the method in this section, all the octets going into one lower-layer packet get encrypted as a single unit 🧁. For RTCP, a 32-bit random number, redrawn for each unit, MUST be prepended to the unit before encryption 🎲. For RTP there's no prefix. Instead, the sequence number and timestamp fields start at random offsets 🎲. This is considered a weak initialization vector (IV) because the randomness isn't great 🙃. Plus, if an enemy can manipulate the next field, the SSRC, that's another weakness in the encryption method 😈.
For RTCP, an implementation MAY split the individual RTCP packets in a compound RTCP packet into two separate compound RTCP packets: one encrypted, one sent in the clear 🪄. Like, SDES info might be encrypted while reception reports go in the clear, so third-party monitors who don't have the key can still see them 👀. In this example (see Fig. 4), the SDES info MUST be appended to an RR packet with no reports (plus the random number), so every compound RTCP packet still starts with an SR or RR packet 📦. The SDES CNAME item is required in either the encrypted or unencrypted packet, but not both 🫠. The same SDES info SHOULD NOT be carried in both packets, as this may compromise the encryption 🚨.
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
#: SSRC identifier
Figure 4: Encrypted and non-encrypted RTCP packetsThe receiver confirms that encryption is present and the right key is in use through header or payload validity checks 🕵️♀️. Examples of those checks for RTP and RTCP headers are in Appendices A.1 and A.2 📚.
To match existing implementations of the first RTP spec, RFC 1889, the default algorithm is DES in CBC mode, as described in Section 1.1 of RFC 1423 [29] 🧠. The exception is that padding to a multiple of 8 octets is indicated as described for the P bit in Section 5.1. The IV is zero, because random values come from the RTP header or the random prefix for compound RTCP packets. For details on CBC initialization vectors, see [30] 📖.
Implementations that support this encryption method SHOULD always support DES in CBC mode as the default cipher, to maximize interoperability 🤝. This method was picked because it was shown to be easy and practical in experimental audio and video tools running on the Internet. However, DES has since been found to be too easily broken 💀.
It is RECOMMENDED that stronger algorithms like Triple-DES replace the default 💪. Also, secure CBC mode needs the first block of each packet XORed with a random, independent IV the same size as the cipher's block size 🧩. For RTCP, that's (partially) handled by prepending each packet with a 32-bit random number, independently chosen per packet. For RTP, the timestamp and sequence number start at random values, but consecutive packets won't be independently randomized. It should be noted that the randomness in both cases (RTP and RTCP) is limited 😬. High-security applications SHOULD consider other, more conventional, protection means 🛡️. Other encryption algorithms MAY be specified dynamically for a session by non-RTP means. The SRTP profile [28] based on AES is being developed to handle known plaintext and CBC plaintext manipulation concerns, and it will be the correct choice in the future 👑.
As an alternative to encryption at the IP level or the RTP level (above), profiles MAY define additional payload types for encrypted encodings 🎁. Those encodings MUST specify how padding and other aspects of the encryption are handled. This lets you encrypt only the data and leave the headers in the clear, where that's wanted ✨. It may be especially handy for hardware devices that handle both decryption and decoding 🖥️. It's also valuable for apps that want link-level compression of RTP and lower-layer headers, where payload confidentiality (but not addresses) is enough. Encrypting the headers would rule out compression 🗜️.
9.2 Authentication and Message Integrity 🔑
Authentication and message integrity aren't defined at the RTP level, since they wouldn't be directly doable without a key management infrastructure. Lower layer protocols are expected to provide authentication and integrity instead 🫶.
10. Congestion Control 🚦
Every transport protocol on the Internet has to deal with congestion control somehow [31] 🚗. RTP is no exception. But since RTP data is often inelastic (generated at a fixed or controlled rate), the ways to handle congestion can be pretty different from TCP's 🧐. In one sense, inelasticity lowers the congestion risk, since an RTP stream won't balloon to eat all the bandwidth the way TCP can 🎈. But inelasticity also means the RTP stream can't just cut its load on the network whenever congestion shows up 😩.
RTP gets used for SO many kinds of apps in so many contexts 🌍 that no single congestion control mechanism works for all of them. Therefore, congestion control SHOULD be defined in each RTP profile as appropriate 📝. Some profiles may just need an applicability statement limiting them to environments where congestion is avoided by engineering 🛤️. For other profiles, specific methods like data rate adaptation based on RTCP feedback may be required 📊.
11. RTP over Network and Transport Protocols ✨
okay bestie, this section is all about what RTP needs from whatever network and transport protocol is carrying it 🦋 these rules apply unless a protocol-specific definition outside this spec says otherwise, so keep that in mind 💅
RTP leans on the underlying protocols to keep RTP data and RTCP control streams separate (that's demultiplexing, the sorting-out bit 🧚). For UDP and similar protocols, RTP SHOULD use an even destination port number, and the matching RTCP stream SHOULD use the next higher (odd) destination port number 🌸. If an application takes one port number and derives the RTP and RTCP pair from it, and you hand it an odd number, the application SHOULD swap in the next lower (even) number as the base of the pair 🎀. When the RTP and RTCP destination ports come in as separate explicit parameters (through a signaling protocol or some other means), the application MAY ignore the even/odd and consecutive rules, though an even/odd pair is still encouraged 💖. Just don't let them match. The RTP and RTCP port numbers MUST NOT be the same, because RTP uses the port numbers to demultiplex the RTP data and RTCP control streams 😭.
In a unicast session, both participants need to identify a port pair for receiving RTP and RTCP packets 💜. Both participants MAY use the same port pair. A participant MUST NOT assume that the source port of an incoming RTP or RTCP packet can be used as the destination port for outgoing RTP or RTCP packets 🙈. When RTP data packets are being sent in both directions, each participant's RTCP SR packets MUST be sent to the port that the other participant specified for RTCP reception. SR packets combine sender info for your outgoing data with reception report info for the incoming data 🔥. If a side isn't actively sending data (see Section 6.4), it sends an RTCP RR packet instead ✨.
It is RECOMMENDED that layered encoding applications (see Section 2.4) use a set of contiguous port numbers 🌈. The port numbers MUST be distinct. This is because of a widespread deficiency in existing operating systems that stops the same port being used with multiple multicast addresses, and for unicast there's only one permissible address anyway. So for layer n, the data port is P + 2n and the control port is P + 2n + 1. When IP multicast is used, the addresses MUST also be distinct, since multicast routing and group membership are managed at address granularity. Contiguous multicast addresses can't be assumed, though, because some groups may need different scopes and may therefore come from different address ranges 🦋.
⚠️ The previous paragraph conflicts with the SDP specification, RFC 2327 [15]. That spec says it's illegal to specify both multiple addresses and multiple ports in the same session description, because the association of addresses with ports could be ambiguous. The plan is to relax this restriction in a revision of RFC 2327, so an equal number of addresses and ports can be specified with a one-to-one mapping implied 🙃
RTP data packets have no length field or other delineation, so RTP relies on the underlying protocols to provide a length indication 📏. The maximum length of RTP packets is limited only by the underlying protocols 💫.
If RTP packets are carried in an underlying protocol that gives you a continuous octet stream instead of messages (packets), an encapsulation of the RTP packets MUST be defined to provide a framing mechanism 🧵. Framing is also needed if the underlying protocol may contain padding, so the extent of the RTP payload can't be determined. The framing mechanism isn't defined here, so that's a problem for another day 🫶.
A profile MAY specify a framing method to be used even when RTP is carried in protocols that already provide framing. The point is to carry several RTP packets in one lower-layer protocol data unit, like a single UDP packet 🍓. Carrying several RTP packets in one network or transport packet cuts down on header overhead and may simplify synchronization between different streams ✨.
12. Summary of Protocol Constants 🎀
this section is basically the cheat sheet of all the constants in this spec 📝
The RTP payload type (PT) constants are defined in profiles rather than in this document 🧚. However, the octet of the RTP header that holds the marker bit(s) and payload type MUST avoid the reserved values 200 and 201 (decimal). That's how RTP packets get told apart from the RTCP SR and RR packet types during the header validation procedure in Appendix A.1 💅. With the standard definition of one marker bit and a 7-bit payload type field, as shown in this spec, this restriction means payload types 72 and 73 are reserved 🙈.
12.1 RTCP Packet Types
abbrev. name value
SR sender report 200
RR receiver report 201
SDES source description 202
BYE goodbye 203
APP application-defined 204these type values were picked from the 200-204 range for better header validity checking of RTCP packets compared to RTP packets or other unrelated packets 🔍. When the RTCP packet type field is compared with the corresponding octet of the RTP header, this range means the marker bit is 1 (which it usually isn't in data packets) and the high bit of the standard payload type field is 1 (since static payload types are usually defined in the low half) 🦋. The range also sits some distance from 0 and 255, since all-zeros and all-ones are common data patterns 💜.
Since all compound RTCP packets MUST begin with SR or RR, these codes were chosen as an even/odd pair. That lets the RTCP validity check test the maximum number of bits with mask and value 🧠.
Additional RTCP packet types may be registered through IANA (see Section 15) 🌸.
12.2 SDES Types
abbrev. name value
END end of SDES list 0
CNAME canonical name 1
NAME user name 2
EMAIL user's electronic mail address 3
PHONE user's phone number 4
LOC geographic user location 5
TOOL name of application or tool 6
NOTE notice about the source 7
PRIV private extensions 8Additional SDES types may be registered through IANA (see Section 15) 🎀
13. RTP Profiles and Payload Format Specifications ✨
okay so a complete RTP spec for one specific app needs one or more companion docs, and there are two types of them 💅
RTP has to work for lots of apps with pretty different needs. So the main spec gives you a bunch of choices, and then a profile picks the right ones for a certain environment and class of apps, or defines extensions for it 🦋 An app usually runs under just one profile in a session, so RTP itself has no explicit way to say which profile is in use. A profile for audio and video apps lives in the companion RFC 3551. Profiles are usually titled "RTP Profile for ...".
The second type is a payload format specification 🎀 This one explains how a particular kind of payload, like H.261 encoded video, should be carried in RTP. These are usually titled "RTP Payload Format for XYZ Audio/Video Encoding". Payload formats can be useful under multiple profiles, so they can be defined without being tied to any one profile. The profile docs then handle assigning a default mapping of that format to a payload type value, if one is needed.
Here are the items that have been flagged for possible definition in a profile. This list is not meant to be exhaustive 🌸
- RTP data header: The octet in the RTP data header that contains the marker bit and payload type field MAY be redefined by a profile to suit different requirements, for example with more or fewer marker bits (Section 5.3, p. 18).
- Payload types: Assuming a payload type field is included, the profile will usually define a set of payload formats (e.g., media encodings) and a default static mapping of those formats to payload type values. Some of the payload formats may be defined by reference to separate payload format specifications. For each payload type defined, the profile MUST specify the RTP timestamp clock rate to be used (Section 5.1, p. 14).
- RTP data header additions: Additional fields MAY be appended to the fixed RTP data header if some additional functionality is required across the profile's class of applications, independent of payload type (Section 5.3, p. 18).
- RTP data header extensions: The contents of the first 16 bits of the RTP data header extension structure MUST be defined if use of that mechanism is to be allowed under the profile for implementation-specific extensions (Section 5.3.1, p. 18).
- RTCP packet types: New application-class-specific RTCP packet types MAY be defined and registered with IANA.
- RTCP report interval: A profile SHOULD specify that the values suggested in Section 6.2 for the constants used in the RTCP report interval calculation will be used. Those constants are the RTCP fraction of session bandwidth, the minimum report interval, and the bandwidth split between senders and receivers. A profile MAY specify alternate values if they have been demonstrated to work in a scalable manner.
- SR/RR extension: An extension section MAY be defined for the RTCP SR and RR packets if there is additional information that should be reported regularly about the sender or receivers (Section 6.4.3, p. 42 and 43).
- SDES use: The profile MAY specify the relative priorities for RTCP SDES items to be transmitted or excluded entirely (Section 6.3.9). It can also give an alternate syntax or semantics for the
CNAMEitem (Section 6.5.1), the format of theLOCitem (Section 6.5.5), or the semantics and use of theNOTEitem (Section 6.5.7). New SDES item types can be registered with IANA too. - Security: A profile MAY specify which security services and algorithms should be offered by applications, and MAY provide guidance as to their appropriate use (Section 9, p. 65).
- String-to-key mapping: A profile MAY specify how a user-provided password or pass phrase is mapped into an encryption key.
- Congestion: A profile SHOULD specify the congestion control behavior appropriate for that profile.
- Underlying protocol: Use of a particular underlying network or transport layer protocol to carry RTP packets MAY be required.
- Transport mapping: A mapping of RTP and RTCP to transport-level addresses, e.g., UDP ports, other than the standard mapping defined in Section 11, p. 68 may be specified.
- Encapsulation: An encapsulation of RTP packets may be defined to allow multiple RTP data packets to be carried in one lower-layer packet, or to provide framing over underlying protocols that do not already do so (Section 11, p. 69).
It's not expected that every application will need its own new profile 💖 Within one application class, it's better to extend an existing profile than to make a new one, since that helps apps interoperate, and each one will typically run under only one profile. Simple extensions, like defining more payload type values or RTCP packet types, can be done by registering them through IANA and publishing their descriptions in an addendum to the profile or in a payload format specification.
14. Security Considerations 🙈
okay this section is serious, bestie 😭
RTP has the same security liabilities as the underlying protocols. For example, an impostor can fake source or destination network addresses, or change the header or payload. Inside RTCP, the CNAME and NAME information can be used to impersonate another participant. RTP can also be sent via IP multicast, which gives a sender no direct way to know all the receivers of its data, so there's no real measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication [33]. So using security mechanisms with RTP is important. Section 9 covers those mechanisms.
RTP-level translators or mixers can be used to let RTP traffic reach hosts behind firewalls 🔥 Appropriate firewall security principles and practices should be followed when designing and installing these devices, and when admitting RTP applications for use behind the firewall. Those firewall practices are beyond the scope of this document, so you'll need to look them up elsewhere 🧚
15. IANA Considerations 🌈
extra careful here because numbers matter 💅
Additional RTCP packet types and SDES item types can be registered through the Internet Assigned Numbers Authority (IANA). These number spaces are small, so letting anyone register new values without limits would not be prudent. To make reviewing requests easier, and to promote shared use of new types across multiple applications, requests for new values must be documented in an RFC or in another permanent and readily available reference, such as a product of another cooperative standards body (e.g., ITU-T). Other requests may also be accepted under the advice of a "designated expert." (Contact the IANA for the contact information of the current expert.)
RTP profile specifications SHOULD register a name with IANA in the form RTP/xxx, where xxx is a short abbreviation of the profile title ✨ These names are for higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [15], to use when referring to transport methods.
16. Intellectual Property Rights Statement 📜
this part is all legal stuff, so here's the gist 🫶
The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to apply to the implementation or use of the technology in this document. It also doesn't say whether any license under those rights might or might not be available. Nor does it claim to have tried to identify any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documents can be found in BCP-11. Copies of claims of rights that have been made available for publication, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this spec to use such proprietary rights can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to practice this standard. Send that info to the IETF Executive Director 💜
17. Acknowledgments 🌸
shoutouts time, and every single name deserves one 🥹
This memo is based on discussions within the IETF Audio/Video Transport working group, chaired by Stephen Casner and Colin Perkins. The current protocol has its origins in the Network Voice Protocol and the Packet Video Protocol (Danny Cohen and Randy Cole), and in the protocol implemented by the vat application (Van Jacobson and Steve McCanne). Christian Huitema provided ideas for the random identifier generator. Jonathan Rosenberg did extensive analysis and simulation of the timer reconsideration algorithm. The additions for layered encodings were specified by Michael Speer and Steve McCanne 👑
Appendix A. Algorithms ✨
okay so bestie, this appendix is where we get to the fun part 💻🎀 We're giving you C code examples for some pieces of the RTP sender and receiver algorithms. Just so you know, there could be other ways to do these that are faster on certain setups or have other perks 🦋 These implementation notes are informational only and exist to make the RTP spec easier to understand. They're not the rules themselves 💅
The structs below only work on 32-bit big-endian machines (most significant octet first) 🍓 The bit fields are packed tightly in big-endian bit order with no extra padding, so if you want something portable you'll need to tweak it. Not a dealbreaker, just know it going in 🫶
Here's the header file, rtp.h 🌸
/*
* rtp.h -- RTP header file
*/
#include <sys/types.h>
/*
* The type definitions below are valid for 32-bit architectures and
* may have to be adjusted for 16- or 64-bit architectures.
*/
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef short int16;
/*
* Current protocol version.
*/
#define RTP_VERSION 2
#define RTP_SEQ_MOD (1<<16)
#define RTP_MAX_SDES 255 /* maximum text length for SDES */
typedef enum {
RTCP_SR = 200,
RTCP_RR = 201,
RTCP_SDES = 202,
RTCP_BYE = 203,
RTCP_APP = 204
} rtcp_type_t;
typedef enum {
RTCP_SDES_END = 0,
RTCP_SDES_CNAME = 1,
RTCP_SDES_NAME = 2,
RTCP_SDES_EMAIL = 3,
RTCP_SDES_PHONE = 4,
RTCP_SDES_LOC = 5,
RTCP_SDES_TOOL = 6,
RTCP_SDES_NOTE = 7,
RTCP_SDES_PRIV = 8
} rtcp_sdes_type_t;
/*
* RTP data header
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */
u_int32 ts; /* timestamp */
u_int32 ssrc; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */
} rtp_hdr_t;
/*
* RTCP common header word
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int count:5; /* varies by packet type */
unsigned int pt:8; /* RTCP packet type */
u_int16 length; /* pkt len in words, w/o this word */
} rtcp_common_t;
/*
* Big-endian mask for version, padding bit and packet type pair
*/
#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
/*
* Reception report block
*/
typedef struct {
u_int32 ssrc; /* data source being reported */
unsigned int fraction:8; /* fraction lost since last SR/RR */
int lost:24; /* cumul. no. pkts lost (signed!) */
u_int32 last_seq; /* extended last seq. no. received */
u_int32 jitter; /* interarrival jitter */
u_int32 lsr; /* last SR packet from this source */
u_int32 dlsr; /* delay since last SR packet */
} rtcp_rr_t;
/*
* SDES item
*/
typedef struct {
u_int8 type; /* type of item (rtcp_sdes_type_t) */
u_int8 length; /* length of item (in octets) */
char data[1]; /* text, not null-terminated */
} rtcp_sdes_item_t;
/*
* One RTCP packet
*/
typedef struct {
rtcp_common_t common; /* common header */
union {
/* sender report (SR) */
struct {
u_int32 ssrc; /* sender generating this report */
u_int32 ntp_sec; /* NTP timestamp */
u_int32 ntp_frac;
u_int32 rtp_ts; /* RTP timestamp */
u_int32 psent; /* packets sent */
u_int32 osent; /* octets sent */
rtcp_rr_t rr[1]; /* variable-length list */
} sr;
/* reception report (RR) */
struct {
u_int32 ssrc; /* receiver generating this report */
rtcp_rr_t rr[1]; /* variable-length list */
} rr;
/* source description (SDES) */
struct rtcp_sdes {
u_int32 src; /* first SSRC/CSRC */
rtcp_sdes_item_t item[1]; /* list of SDES items */
} sdes;
/* BYE */
struct {
u_int32 src[1]; /* list of sources */
/* can't express trailing text for reason */
} bye;
} r;
} rtcp_t;
typedef struct rtcp_sdes rtcp_sdes_t;
/*
* Per-source state information
*/
typedef struct {
u_int16 max_seq; /* highest seq. number seen */
u_int32 cycles; /* shifted count of seq. number cycles */
u_int32 base_seq; /* base seq number */
u_int32 bad_seq; /* last 'bad' seq number + 1 */
u_int32 probation; /* sequ. packets till source is valid */
u_int32 received; /* packets received */
u_int32 expected_prior; /* packet expected at last interval */
u_int32 received_prior; /* packet received at last interval */
u_int32 transit; /* relative trans time for prev pkt */
u_int32 jitter; /* estimated jitter */
/* ... */
} source;that's the whole header, and it's giving everything 💖 Next up, we keep going 🧚
A.1 RTP Data Header Validity Checks ✨
okay bestie, an RTP receiver should check the validity of the RTP header on incoming packets 💅 because they might be encrypted, or they might be from some other app that got misaddressed 🙈 Similarly, if encryption using the method in Section 9 is turned on, the header validity check is needed to verify that incoming packets were correctly decrypted. A failed check (like an unknown payload type) doesn't necessarily mean decryption failed though, so don't panic 🫶
Only weak validity checks are possible on an RTP data packet from a source you haven't heard from before:
- The RTP version field must equal 2.
- The payload type must be known, and in particular it must not be equal to SR or RR.
- If the P bit is set, then the last octet of the packet must contain a valid octet count, in particular, less than the total packet length minus the header size.
- The X bit must be zero if the profile does not specify that the header extension mechanism may be used. Otherwise, the extension length field must be less than the total packet size minus the fixed header length and padding.
- The length of the packet must be consistent with CC and payload type (if payloads have a known length).
The last three checks are kinda complex and not always possible, so that leaves only the first two, which total just a few bits 🥺 If the SSRC identifier in the packet is one that has been received before, then the packet is probably valid, and checking whether the sequence number is in the expected range gives you extra validation 🔥 If the SSRC identifier hasn't been seen before, then data packets carrying that identifier may be considered invalid until a small number of them arrive with consecutive sequence numbers. Those invalid packets MAY be discarded, or they MAY be stored and delivered once validation has been achieved, if the resulting delay is acceptable ✨
The routine update_seq shown below makes sure a source is declared valid only after MIN_SEQUENTIAL packets have been received in sequence. It also validates the sequence number seq of a newly received packet and updates the sequence state for that packet's source in the structure that s points to 💖
When a new source is heard for the first time (meaning its SSRC identifier is not in the table, see Section 8.2, and the per-source state gets allocated for it), s->probation is set to the number of sequential packets required before a source is declared valid (parameter MIN_SEQUENTIAL), and the other variables get initialized:
init_seq(s, seq);
s->max_seq = seq - 1;
s->probation = MIN_SEQUENTIAL;A non-zero s->probation marks the source as not yet valid, so its state can be discarded after a short timeout instead of a long one, as discussed in Section 6.2.1 🌸
After a source is considered valid, the sequence number is considered valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more than MAX_MISORDER behind. If the new sequence number is ahead of max_seq modulo the RTP sequence number range (16 bits) but is smaller than max_seq, it has wrapped around, and the (shifted) count of sequence number cycles gets incremented. A value of one is returned to indicate a valid sequence number 🦋
Otherwise, the value zero is returned to indicate the validation failed, and the bad sequence number plus 1 is stored. If the next packet received carries the next higher sequence number, it's considered the valid start of a new packet sequence, presumably caused by an extended dropout or a source restart 😭 Since multiple complete sequence number cycles may have been missed, the packet loss statistics get reset.
Typical values for the parameters are shown, based on a maximum misordering time of 2 seconds at 50 packets/second and a maximum dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a small fraction of the 16-bit sequence number space, so there's a reasonable probability that new sequence numbers after a restart won't fall in the acceptable range for sequence numbers from before the restart 🍓
void init_seq(source *s, u_int16 seq)
{
s->base_seq = seq;
s->max_seq = seq;
s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */
s->cycles = 0;
s->received = 0;
s->received_prior = 0;
s->expected_prior = 0;
/* other initialization */
}
int update_seq(source *s, u_int16 seq)
{
u_int16 udelta = seq - s->max_seq;
const int MAX_DROPOUT = 3000;
const int MAX_MISORDER = 100;
const int MIN_SEQUENTIAL = 2;
/*
* Source is not valid until MIN_SEQUENTIAL packets with
* sequential sequence numbers have been received.
*/
if (s->probation) {
/* packet is in sequence */
if (seq == s->max_seq + 1) {
s->probation--;
s->max_seq = seq;
if (s->probation == 0) {
init_seq(s, seq);
s->received++;
return 1;
}
} else {
s->probation = MIN_SEQUENTIAL - 1;
s->max_seq = seq;
}
return 0;
} else if (udelta < MAX_DROPOUT) {
/* in order, with permissible gap */
if (seq < s->max_seq) {
/*
* Sequence number wrapped - count another 64K cycle.
*/
s->cycles += RTP_SEQ_MOD;
}
s->max_seq = seq;
} else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
/* the sequence number made a very large jump */
if (seq == s->bad_seq) {
/*
* Two sequential packets -- assume that the other side
* restarted without telling us so just re-sync
* (i.e., pretend this was the first packet).
*/
init_seq(s, seq);
}
else {
s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
return 0;
}
} else {
/* duplicate or reordered packet */
}
s->received++;
return 1;
}The validity check can be made stronger by requiring more than two packets in sequence. The downsides are that a larger number of initial packets will be discarded (or delayed in a queue), and that high packet loss rates could prevent validation 😬 However, because the RTCP header validation is relatively strong, if an RTCP packet is received from a source before its data packets, the count could be adjusted so that only two packets are required in sequence 💜 If losing initial data for a few seconds is tolerable, an application MAY choose to discard all data packets from a source until a valid RTCP packet has been received from that source.
Depending on the application and encoding, algorithms may exploit additional knowledge about the payload format for further validation. For payload types where the timestamp increment is the same for all packets, the timestamp values can be predicted from the previous packet received from the same source, using the sequence number difference (assuming no change in payload type) ⭐
A strong "fast-path" check is possible, since with high probability the first four octets in the header of a newly received RTP data packet will be just the same as those of the previous packet from the same SSRC, except that the sequence number will have increased by one 🌈 Similarly, a single-entry cache may be used for faster SSRC lookups in applications where data is typically received from one source at a time 🧚
A.2 RTCP Header Validity Checks
The following checks should be applied to RTCP packets 🎀
- The RTP version field must equal 2.
- The payload type field of the first RTCP packet in a compound packet must be equal to SR or RR.
- The padding bit (P) should be zero for the first packet of a compound RTCP packet, because padding should only be applied, if it is needed, to the last packet.
- The length fields of the individual RTCP packets must add up to the overall length of the compound RTCP packet as received. This is a fairly strong check 👑
The code fragment below performs all of these checks. The packet type is not checked for subsequent packets, since unknown packet types may be present and should be ignored 🫶
u_int32 len; /* length of compound RTCP packet in words */
rtcp_t *r; /* RTCP header */
rtcp_t *end; /* end of compound RTCP packet */
if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
/* something wrong with packet format */
}
end = (rtcp_t *)((u_int32 *)r + len);
do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
while (r < end && r->common.version == 2);
if (r != end) {
/* something wrong with packet format */
}A.3 Determining Number of Packets Expected and Lost
To work out packet loss rates, you need to know how many RTP packets were expected and actually received from each source 📊 That's tracked with per-source state info defined in struct source, referenced via the pointer s in the code below. The number of packets received is simply the count of packets as they arrive, including any late or duplicate packets. The number of packets expected can be computed by the receiver as the difference between the highest sequence number received (s->max_seq) and the first sequence number received (s->base_seq). Since the sequence number is only 16 bits and wraps around, the highest sequence number has to be extended with the (shifted) count of sequence number wraparounds (s->cycles). Both the received packet count and the count of cycles are maintained by the RTP header validity check routine in Appendix A.1 🧮
extended_max = s->cycles + s->max_seq;
expected = extended_max - s->base_seq + 1;The number of packets lost is defined as the number of packets expected, less the number of packets actually received:
lost = expected - s->received;Since this signed number is carried in 24 bits, it should be clamped at 0x7fffff for positive loss or 0x800000 for negative loss, rather than wrapping around 😵💫
The fraction of packets lost during the last reporting interval (since the previous SR or RR packet was sent) is calculated from differences in the expected and received packet counts across the interval, where expected_prior and received_prior are the values saved when the previous reception report was generated 🌸
expected_interval = expected - s->expected_prior;
s->expected_prior = expected;
received_interval = s->received - s->received_prior;
s->received_prior = s->received;
lost_interval = expected_interval - received_interval;
if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
else fraction = (lost_interval << 8) / expected_interval;The resulting fraction is an 8-bit fixed point number with the binary point at the left edge 💖
A.4 Generating RTCP SDES Packets ✨
okay so this function builds one SDES chunk into buffer b 🎀 It takes argc items, which come in as the parallel arrays type, value and length, and when it's done it hands back a pointer to the next free spot inside b 💅
char *rtp_write_sdes(char *b, u_int32 src, int argc,
rtcp_sdes_type_t type[], char *value[],
int length[])
{
rtcp_sdes_t *s = (rtcp_sdes_t *)b;
rtcp_sdes_item_t *rsp;
int i;
int len;
int pad;
/* SSRC header */
s->src = src;
rsp = &s->item[0];
/* SDES items */
for (i = 0; i < argc; i++) {
rsp->type = type[i];
len = length[i];
if (len > RTP_MAX_SDES) {
/* invalid length, may want to take other action */
len = RTP_MAX_SDES;
}
rsp->length = len;
memcpy(rsp->data, value[i], len);
rsp = (rtcp_sdes_item_t *)&rsp->data[len];
}
/* terminate with end marker and pad to next 4-octet boundary */
len = ((char *) rsp) - b;
pad = 4 - (len & 0x3);
b = (char *) rsp;
while (pad--) *b++ = RTCP_SDES_END;
return b;
}A.5 Parsing RTCP SDES Packets 🦋
this one parses an SDES packet 🧚 It calls find_member() to get a pointer to the info for a session member, using the SSRC identifier, and then member_sdes() to store the fresh SDES info for that member. It expects a pointer to the header of the RTCP packet, so make sure you hand it the right spot!
void rtp_read_sdes(rtcp_t *r)
{
int count = r->common.count;
rtcp_sdes_t *sd = &r->r.sdes;
rtcp_sdes_item_t *rsp, *rspn;
rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
((u_int32 *)r + r->common.length + 1);
source *s;
while (--count >= 0) {
rsp = &sd->item[0];
if (rsp >= end) break;
s = find_member(sd->src);
for (; rsp->type; rsp = rspn ) {
rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
if (rspn >= end) {
rsp = rspn;
break;
}
member_sdes(s, rsp->type, rsp->data, rsp->length);
}
sd = (rtcp_sdes_t *)
((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
}
if (count >= 0) {
/* invalid packet format */
}
}A.6 Generating a Random 32-bit Identifier 🎲
okay this is the random number moment 🔥 This subroutine makes a random 32-bit identifier using the MD5 routines from RFC 1321 [32]. Heads up: the system routines might not exist on every operating system, so think of them as hints about what kinds of info you could mix in 💖 Other system calls that could be a good fit are:
getdomainname(),getwd(), orgetrusage().
"Live" video or audio samples are also a great source of randomness ✨ but be careful not to grab from a turned-off microphone or a blinded camera [17] 🙈
Using this or a similar routine is recommended for a few things: seeding the random number generator that produces the RTCP period (as shown in Appendix A.7), setting the initial values for the sequence number and timestamp, and generating SSRC values 🌸 It's pretty CPU-intensive, though, so using it directly to generate RTCP periods is inappropriate, because predictability is not an issue there 💅 Also, this routine gives the same result on repeated calls until the system clock changes, unless you pass different values for the type argument.
/*
* Generate a random 32-bit quantity.
*/
#include <sys/types.h> /* u_long */
#include <sys/time.h> /* gettimeofday() */
#include <unistd.h> /* get..() */
#include <stdio.h> /* printf() */
#include <time.h> /* clock() */
#include <sys/utsname.h> /* uname() */
#include "global.h" /* from RFC 1321 */
#include "md5.h" /* from RFC 1321 */
#define MD_CTX MD5_CTX
#define MDInit MD5Init
#define MDUpdate MD5Update
#define MDFinal MD5Final
static u_long md_32(char *string, int length)
{
MD_CTX context;
union {
char c[16];
u_long x[4];
} digest;
u_long r;
int i;
MDInit (&context);
MDUpdate (&context, string, length);
MDFinal ((unsigned char *)&digest, &context);
r = 0;
for (i = 0; i < 3; i++) {
r ^= digest.x[i];
}
return r;
} /* md_32 */
/*
* Return random unsigned 32-bit quantity. Use 'type' argument if
* you need to generate several different values in close succession.
*/
u_int32 random32(int type)
{
struct {
int type;
struct timeval tv;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
gettimeofday(&s.tv, 0);
uname(&s.name);
s.type = type;
s.cpu = clock();
s.pid = getpid();
s.hid = gethostid();
s.uid = getuid();
s.gid = getgid();
/* also: system uptime */
return md_32((char *)&s, sizeof(s));
} /* random32 */A.7 Computing the RTCP Transmission Interval ✨
okay bestie, this is where we figure out WHEN each participant sends its RTCP reports 🕰️💖 these rules come from Section 6.2, and they're split across a few functions:
rtcp_interval()computes the deterministic calculated interval, in seconds 🧮 (its parameters are defined in Section 6.3)OnExpire()gets called when the RTCP transmission timer expires ⏰OnReceive()gets called whenever an RTCP packet shows up 📬
both OnExpire() and OnReceive() take an event e as an argument. that's the next scheduled event for that participant, which is either an RTCP report or a BYE packet 🎀
we're assuming these helper functions exist:
Schedule(time t, event e)schedules an eventeto occur at timet. when timetarrives,OnExpiregets called witheas an argument 🗓️Reschedule(time t, event e)reschedules a previously scheduled eventefor timet🔁SendRTCPReport(event e)sends an RTCP report 📤SendBYEPacket(event e)sends a BYE packet 👋TypeOfEvent(event e)returnsEVENT_BYEif the event being processed is for a BYE packet to be sent, otherwise it returnsEVENT_REPORT🏷️PacketType(p)returnsPACKET_RTCP_REPORTif packetpis an RTCP report (not BYE),PACKET_BYEif it's a BYE RTCP packet, andPACKET_RTPif it's a regular RTP data packet 📦ReceivedPacketSize()andSentPacketSize()return the size of the referenced packet in octets 📏NewMember(p)returns a 1 if the participant who sent packetpis not currently in the member list, and 0 otherwise. heads up though, this function alone isn't enough for a complete implementation, because each CSRC identifier in an RTP packet and each SSRC in a BYE packet should be processed too 👀NewSender(p)returns a 1 if the participant who sent packetpis not currently in the sender sublist of the member list, and 0 otherwise 🎤AddMember()andRemoveMember()add and remove participants from the member list 🧑🤝🧑AddSender()andRemoveSender()add and remove participants from the sender sublist of the member list 🎙️
ngl, if your implementation lets the RTCP bandwidth fractions for senders and non-senders be explicit parameters instead of the fixed 25% and 75% values, these functions need extending 😭 and the extended rtcp_interval() would need to avoid division by zero if one of those parameters is zero 💀
here's the main event, rtcp_interval() 💅✨
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
double avg_rtcp_size,
int initial)
{
/*
* Minimum average time between RTCP packets from this site (in
* seconds). This time prevents the reports from `clumping' when
* sessions are small and the law of large numbers isn't helping
* to smooth out the traffic. It also keeps the report interval
* from becoming ridiculously small during transient outages like
* a network partition.
*/
double const RTCP_MIN_TIME = 5.;
/*
* Fraction of the RTCP bandwidth to be shared among active
* senders. (This fraction was chosen so that in a typical
* session with one or two active senders, the computed report
* time would be roughly equal to the minimum report time so that
* we don't unnecessarily slow down receiver reports.) The
* receiver fraction must be 1 - the sender fraction.
*/
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
/*
/* To compensate for "timer reconsideration" converging to a
* value below the intended average.
*/
double const COMPENSATION = 2.71828 - 1.5;
double t; /* interval */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* no. of members for computation */
/*
* Very first call at application start-up uses half the min
* delay for quicker notification while still allowing some time
* before reporting for randomization and to learn about other
* sources so the report interval will converge to the correct
* interval more quickly.
*/
if (initial) {
rtcp_min_time /= 2;
}
/*
* Dedicate a fraction of the RTCP bandwidth to senders unless
* the number of senders is large enough that their share is
* more than that fraction.
*/
n = members;
if (senders <= members * RTCP_SENDER_BW_FRACTION) {
if (we_sent) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION;
n = senders;
} else {
rtcp_bw *= RTCP_RCVR_BW_FRACTION;
n -= senders;
}
}
/*
* The effective number of sites times the average packet size is
* the total number of octets sent when each site sends a report.
* Dividing this by the effective bandwidth gives the time
* interval over which those packets must be sent in order to
* meet the bandwidth target, with a minimum enforced. In that
* time interval we send one report so this time is also our
* average time between reports.
*/
t = avg_rtcp_size * n / rtcp_bw;
if (t < rtcp_min_time) t = rtcp_min_time;
/*
* To avoid traffic bursts from unintended synchronization with
* other sites, we then pick our actual next report interval as a
* random number uniformly distributed between 0.5*t and 1.5*t.
*/
t = t * (drand48() + 0.5);
t = t / COMPENSATION;
return t;
}Basically, this function picks a random next-report time that averages out to the bandwidth target, with a minimum floor so reports don't clump 🌸 the first call at startup gets half the minimum delay so you hear from everyone faster 🚀
next up is OnExpire(), the function that decides whether to send a report or a BYE right now, or to push it back 🙈💜
void OnExpire(event e,
int members,
int senders,
double rtcp_bw,
int we_sent,
double *avg_rtcp_size,
int *initial,
time_tp tc,
time_tp *tp,
int *pmembers)
{
/* This function is responsible for deciding whether to send an
* RTCP report or BYE packet now, or to reschedule transmission.
* It is also responsible for updating the pmembers, initial, tp,
* and avg_rtcp_size state variables. This function should be
* called upon expiration of the event timer used by Schedule().
*/
double t; /* Interval */
double tn; /* Next transmit time */
/* In the case of a BYE, we use "timer reconsideration" to
* reschedule the transmission of the BYE if necessary */
if (TypeOfEvent(e) == EVENT_BYE) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendBYEPacket(e);
exit(1);
} else {
Schedule(tn, e);
}
} else if (TypeOfEvent(e) == EVENT_REPORT) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendRTCPReport(e);
*avg_rtcp_size = (1./16.)*SentPacketSize(e) +
(15./16.)*(*avg_rtcp_size);
*tp = tc;
/* We must redraw the interval. Don't reuse the
one computed above, since its not actually
distributed the same, as we are conditioned
on it being small enough to cause a packet to
be sent */
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
Schedule(t+tc,e);
*initial = 0;
} else {
Schedule(tn, e);
}
*pmembers = members;
}
}the BYE branch uses "timer reconsideration" 🔄 so a BYE only goes out once its time has actually come up, and the report branch redraws its interval after sending, because the first draw was conditioned on being small enough to send 🧠✨
last but not least, OnReceive() 📬 which is all about what we do when a packet lands, depending on whether we've left the group and are waiting to send a BYE or an RTCP report 👑
void OnReceive(packet p,
event e,
int *members,
int *pmembers,
int *senders,
double *avg_rtcp_size,
double *tp,
double tc,
double tn)
{
/* What we do depends on whether we have left the group, and are
* waiting to send a BYE (TypeOfEvent(e) == EVENT_BYE) or an RTCP
* report. p represents the packet that was just received. */
if (PacketType(p) == PACKET_RTCP_REPORT) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
} else if (PacketType(p) == PACKET_RTP) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddSender(p);
*senders += 1;
}
} else if (PacketType(p) == PACKET_BYE) {
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
if (TypeOfEvent(e) == EVENT_REPORT) {
if (NewSender(p) == FALSE) {
RemoveSender(p);
*senders -= 1;
}
if (NewMember(p) == FALSE) {
RemoveMember(p);
*members -= 1;
}
if (*members < *pmembers) {
tn = tc +
(((double) *members)/(*pmembers))*(tn - tc);
*tp = tc -
(((double) *members)/(*pmembers))*(tc - *tp);
/* Reschedule the next report for time tn */
Reschedule(tn, e);
*pmembers = *members;
}
} else if (TypeOfEvent(e) == EVENT_BYE) {
*members += 1;
}
}
}so yeah, every packet type gets its own treatment here 🎀 new members and senders get added to the lists, a BYE removes its sender and member and can pull the next report time earlier, and every received packet nudges the average RTCP size 🌈 this is the stuff that keeps the whole session feeling fair and balanced 🫶
A.8 Estimating the Interarrival Jitter ✨
Okay bestie, these code fragments are the actual recipe for the algorithm from Section 6.4.1 🎀. It works out an estimate of the statistical variance of the RTP data interarrival time, and that estimate goes into the interarrival jitter field of reception reports 📊. The inputs are r->ts, the timestamp from the incoming packet, and arrival, the current time in the same units. s points to the state for the source. s->transit holds the relative transit time for the previous packet, and s->jitter holds the estimated jitter. The jitter field in a reception report is measured in timestamp units and stored as an unsigned integer, but the estimate itself lives in a floating point number 🧮. Every time a data packet shows up, the estimate gets updated:
int transit = arrival - r->ts;
int d = transit - s->transit;
s->transit = transit;
if (d < 0) d = -d;
s->jitter += (1./16.) * ((double)d - s->jitter);When a reception report block (which rr points to) is generated for this member, the current jitter estimate gets handed back:
rr->jitter = (u_int32) s->jitter;Or, if you're feeling fancy 💅, the estimate can be kept as an integer that's been scaled up to cut down on round-off error 🔢. The math is the same except for the last line:
s->jitter += d - ((s->jitter + 8) >> 4);In this version, the estimate gets sampled for the reception report like so:
rr->jitter = s->jitter >> 4;Appendix B - Changes from RFC 1889 🦋
Okay so most of this RFC is identical to RFC 1889 💖. There are no changes to the packet formats on the wire, only to the rules and algorithms that govern how the protocol gets used. The biggest glow-up is an enhancement to the scalable timer algorithm for working out when to send RTCP packets ⏰:
- The algorithm for calculating the RTCP transmission interval, which is specified in Sections 6.2 and 6.3 and illustrated in Appendix A.7, got augmented with "reconsideration" 🔁. That keeps transmission from going way over the intended rate when lots of participants join a session at the same time. It also got "reverse reconsideration" to cut down on how often and how long false participant timeouts happen when the number of participants drops fast 📉. Reverse reconsideration is also used to possibly shorten the delay before sending RTCP SR when someone goes from passive receiver to active sender mode 🎬.
- Section 6.3.7 has new rules about when an RTCP BYE packet should be sent, so a flood of packets doesn't happen when many participants leave at once 🚪.
- The requirement to keep state for inactive participants for long enough to span typical network partitions got removed from Section 6.2.1 🙅♀️. In a session where many participants join for a brief moment and never send BYE, that requirement would overestimate the number of participants by a lot 😵. The reconsideration algorithm added in this revision handles the big pile of new participants that shows up when a partition heals 🩹.
It should be noted that these enhancements only have a significant effect when the session has a large number of participants (thousands) and most of them join or leave at the same time. That makes testing on a live network kinda hard 🙈. However, the algorithm was put through a thorough analysis and simulation to verify its performance 🧪. Furthermore, the enhanced algorithm was designed to interoperate with the algorithm in RFC 1889, so the degree of reduction in excess RTCP bandwidth during a step join is proportional to the fraction of participants that implement the enhanced algorithm 📈. The interoperation of the two algorithms has been verified experimentally on live networks 🎉.
Other functional changes were:
- Section 6.2.1 says implementations may store only a sampling of the participants' SSRC identifiers, so they can scale to very large sessions 🌌. The algorithms are specified in RFC 2762 [21].
- In Section 6.2, it's specified that RTCP sender and non-sender bandwidths may be set as separate parameters of the session, instead of a strict percentage of the session bandwidth, and that they may be set to zero 🍓. The requirement that RTCP was mandatory for RTP sessions using IP multicast got relaxed. A clarification was also added, though, that turning off RTCP is NOT RECOMMENDED 🚫.
- In Sections 6.2, 6.3.1 and Appendix A.7, the fraction of participants below which senders get dedicated RTCP bandwidth changes from the fixed 1/4 to a ratio based on the RTCP sender and non-sender bandwidth parameters, when those are given 🧮. The condition that no bandwidth is dedicated to senders when there are no senders was removed, since that's expected to be a transitory state 🫧. It also keeps non-senders from using sender RTCP bandwidth when that isn't intended 🚧.
- Also in Section 6.2, it's specified that the minimum RTCP interval may be scaled to smaller values for high bandwidth sessions, and that the initial RTCP delay may be set to zero for unicast sessions 🏎️.
- Timing out a participant is now based on inactivity for a number of RTCP report intervals, calculated using the receiver RTCP bandwidth fraction, even for active senders 👀.
- Sections 7.2 and 7.3 specify that translators and mixers should send BYE packets for the sources they are no longer forwarding 👋.
- Rule changes for layered encodings are defined in Sections 2.4, 6.3.9, 8.3 and 11. In the last of these, it's noted that the address and port assignment rule conflicts with the SDP specification, RFC 2327 [15], but it's intended that this restriction will be relaxed in a revision of RFC 2327 🧩.
- The convention for using even/odd port pairs for RTP and RTCP in Section 11 got clarified to refer to destination ports 🔌. The requirement to use an even/odd port pair was removed if the two ports are specified explicitly. For unicast RTP sessions, distinct port pairs may be used for the two ends (Sections 3, 7.1 and 11) 💜.
- A new Section 10 was added to explain the requirement for congestion control in applications using RTP 🚦.
- In Section 8.2, the requirement that a new SSRC identifier MUST be chosen whenever the source transport address changes has been relaxed, so a new SSRC identifier MAY be chosen instead 🪪. Correspondingly, it was clarified that an implementation MAY choose to keep packets from the new source address rather than the existing source address when an SSRC collision happens between two other participants, and SHOULD do so for applications like telephony, where some sources (such as mobile entities) may change addresses during an RTP session 📱.
- An indentation bug in the RFC 1889 printing of the pseudo-code for the collision detection and resolution algorithm in Section 8.2 got fixed by translating the syntax to pseudo C language 🛠️. The algorithm was also modified to remove the restriction that both RTP and RTCP must be sent from the same source port number 🫶.
- The description of the padding mechanism for RTCP packets got clarified, and it's specified that padding MUST only be applied to the last packet of a compound RTCP packet 🎁.
- In Section A.1, the initialization of base_seq was corrected to be seq rather than seq - 1, and the text was corrected to say the bad sequence number plus 1 is stored 🔧. The initialization of max_seq and other variables for the algorithm was separated from the text, to make clear that this initialization must be done in addition to calling the init_seq() function. A few words that were lost in RFC 1889 when processing the document from source to output form were restored too 📝.
- Clamping of the number of packets lost in Section A.3 was corrected to use both positive and negative limits ⚖️.
- The specification of the "relative" NTP timestamp in the RTCP SR section now defines these timestamps as based on the most common system-specific clock, such as system uptime, rather than on session elapsed time. Session elapsed time wouldn't match across multiple applications started on the same machine at different times ⏳.
Non-functional changes:
- It's specified that a receiver MUST ignore packets with payload types it does not understand 🙈.
- In Fig. 2, the floating point NTP timestamp value was corrected, some missing leading zeros were added in a hex number, and the UTC timezone was specified 🕰️.
- The inconsequence of NTP timestamps wrapping around in the year 2036 is explained 🗓️.
- The policy for registering RTCP packet types and SDES types was clarified in a new Section 15, IANA Considerations 📋. The suggestion that experimenters register the numbers they need and then unregister the ones that prove unneeded got removed, in favor of using APP and PRIV 🧹. Registration of profile names was also specified 🏷️.
- The reference for the UTF-8 character set was changed from an X/Open Preliminary Specification to RFC 2279 🔤.
- The reference for RFC 1597 was updated to RFC 1918, and the reference for RFC 2543 was updated to RFC 3261 📚.
- The last paragraph of the introduction in RFC 1889, which cautioned implementors to limit deployment in the Internet, got removed because it was deemed no longer relevant 🌐.
- A non-normative note about using RTP with Source-Specific Multicast (SSM) was added in Section 6 🌟.
- The definition of "RTP session" in Section 3 got expanded to acknowledge that a single session may use multiple destination transport addresses (which was always the case for a translator or mixer) 🔀. It also explains that the distinguishing feature of an RTP session is that each one corresponds to a separate SSRC identifier space. A new definition of "multimedia session" was added to reduce confusion about the word "session" 🫠.
- The meaning of "sampling instant" got explained in more detail as part of the definition of the timestamp field of the RTP header in Section 5.1 ⏱️.
- Small clarifications were made in several places, some in response to reader questions 💬. In particular:
- In RFC 1889, the first five words of the second sentence of Section 2.2 were lost in processing the document from source to output form, but they're restored now 🪄.
- A definition for "RTP media type" was added in Section 3, so the explanation of multiplexing RTP sessions in Section 5.2 is clearer about multiplexing multiple media. That section also explains that multiplexing multiple sources of the same medium based on SSRC identifiers may be appropriate, and that it's the norm for multicast sessions 🎶.
- The definition for "non-RTP means" got expanded to include examples of other protocols that count as non-RTP means 🧃.
- The description of the session bandwidth parameter got expanded in Section 6.2, including a clarification that the control traffic bandwidth is in addition to the session bandwidth for the data traffic 🧾.
- The effect of varying packet duration on the jitter calculation got explained in Section 6.4.4 📈.
- The method for terminating and padding a sequence of SDES items got clarified in Section 6.5 🧵.
- ok so IPv6 address examples got added to the SDES CNAME bit in Section 6.5.1 💖, and "example.com" replaced the other example domain names 🌸
- the Security section now formally references IPSEC since it's actually around now 🔐. It also says the confidentiality method here is mostly codifying what people already do ✨. It is RECOMMENDED that stronger encryption algorithms, like Triple-DES, be used instead of the default algorithm, and it notes the AES-based SRTP profile will be the right pick in the future 🔥. A warning got added that the RTP header is a weak initialization vector 💀, and it was noted that payload-only encryption is needed so header compression can work 🦋
- partial encryption of RTCP got clarified 🧩. Specifically, the SDES CNAME only lives in one part when the compound RTCP packet gets split
- it's now clear that only one compound RTCP packet should be sent per reporting interval 📦. If there are too many active sources for the reports to fit in the MTU, pick a subset of sources round-robin over multiple intervals 🔄
- a note in Appendix A.1 says packets may be saved during RTP header validation and delivered once it succeeds 📬
- Section 7.3 explains that a mixer aggregating SDES packets uses more RTCP bandwidth because the packets are longer 📈. A mixer passing through RTCP naturally sends packets at higher than the single source rate. Both behaviors are valid 🙌
- Section 13 clarifies that an RTP application may use multiple profiles, but typically only one in a given session 🎀
- the terms MUST, SHOULD, MAY, etc. are used as defined in RFC 2119 💅
- the bibliography got divided into normative and informative references 📚
References ✨
Normative References
- [1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
- [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
- [5] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC 2279, January 1998.
- [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
- [7] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
- [8] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
- [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Informative References
- [10] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols," in SIGCOMM Symposium on Communications Architectures and Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE Computer Communications Review, Vol. 20(4), September 1990.
- [11] Schulzrinne, H., "Issues in designing a transport protocol for audio and video conferences and other multiparticipant real-time applications." expired Internet Draft, October 1993.
- [12] Comer, D., Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991.
- [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [14] International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003.
- [15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
- [17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
- [18] Bolot, J.-C., Turletti, T. and I. Wakeman, "Scalable Feedback Control for Multicast Video Distribution in the Internet", in SIGCOMM Symposium on Communications Architectures and Protocols, (London, England), pp. 58--67, ACM, August 1994.
- [19] Busse, I., Deffner, B. and H. Schulzrinne, "Dynamic QoS Control of Multimedia Applications Based on RTP", Computer Communications , vol. 19, pp. 49--58, January 1996.
- [20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, September 1993. Also in [34].
- [21] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
- [22] Cadzow, J., Foundations of Digital Signal Processing and Data Analysis New York, New York: Macmillan, 1987.
- [23] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
- [24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
- [25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC 1627, July 1994.
- [26] Feller, W., An Introduction to Probability Theory and its Applications, vol. 1. New York, New York: John Wiley and Sons, third ed., 1968.
- [27] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K. and D. Oran, "Secure Real-time Transport Protocol", Work in Progress, April 2003.
- [29] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III", RFC 1423, February 1993.
- [30] Voydock, V. and S. Kent, "Security Mechanisms in High-Level Network Protocols", ACM Computing Surveys, vol. 15, pp. 135-171, June 1983.
- [31] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
- [32] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [33] Stubblebine, S., "Security Services for Multimedia Conferencing", in 16th National Computer Security Conference, (Baltimore, Maryland), pp. 391--395, September 1993.
- [34] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, vol. 2, pp. 122--136, April 1994.
Authors' Addresses 🫶
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
United States
EMail: schulzrinne@cs.columbia.edu
Stephen L. Casner
Packet Design
3400 Hillview Avenue, Building 3
Palo Alto, CA 94304
United States
EMail: casner@acm.org
Ron Frederick
Blue Coat Systems Inc.
650 Almanor Avenue
Sunnyvale, CA 94085
United States
EMail: ronf@bluecoat.com
Van Jacobson
Packet Design
3400 Hillview Avenue, Building 3
Palo Alto, CA 94304
United States
EMail: van@packetdesign.comFull Copyright Statement 🌈
Copyright (C) The Internet Society (2003). All Rights Reserved.
You're free to copy and hand this document out, and to write derivative works that comment on or explain it or help implement it. You can publish and distribute those, in whole or in part, with no restrictions at all, as long as the copyright notice and this paragraph stay on every copy and derivative. The document itself, though, may not be modified in any way, such as by removing the copyright notice or the references to the Internet Society or other Internet organizations. The one exception is when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed. Translating it into languages other than English is also allowed. 💜
The permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 🔒
This document and the information in it are provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Acknowledgement 👑
Funding for the RFC Editor function is currently provided by the Internet Society. 🎀✨
📦 where this page comes from
- ietf: rfc3550 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms