RFC 3611
RTP Control Protocol Extended Reports (RTCP XR)
RFC 3611: RTP Control Protocol Extended Reports (RTCP XR) 💖
okay bestie, this one is RFC 3611 🎀 It's a Standards Track doc from the Network Working Group, dated November 2003. The editors are T. Friedman, Ed. (Paris 6), R. Caceres, Ed. (IBM Research), and A. Clark, Ed. (Telchemy). Its title block doesn't list anything it obsoletes or updates. The whole thing is about RTP Control Protocol Extended Reports (RTCP XR) and it's giving main character energy 🦋✨
Status of this Memo 📜
so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the distribution of this memo is unlimited, so share it with everyone 💅
Copyright Notice ©️
the legal bit, no cap: Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸
Abstract ✨
okay so this doc defines the Extended Report (XR) packet type for RTCP, and it explains how an app can signal that it's using XR packets when it uses the Session Description Protocol (SDP) 🔥 XR packets are made of report blocks, and there are seven block types defined here, iconic 👑
The whole point of extended reporting is to share info that backs up the six statistics already sitting in the report blocks of RTCP's Sender Report (SR) and Receiver Report (RR) packets 📊 Some apps, like multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, need other and more detailed stats, and that's where XR comes in 🧚 Future block types can also be added later, as long as they follow the framework this document lays out 💜
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 7
2. XR Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7
3. Extended Report Block Framework. . . . . . . . . . . . . . . . 8
4. Extended Report Blocks . . . . . . . . . . . . . . . . . . . . 9
4.1. Loss RLE Report Block. . . . . . . . . . . . . . . . . . 9
4.1.1. Run Length Chunk . . . . . . . . . . . . . . . . 15
4.1.2. Bit Vector Chunk . . . . . . . . . . . . . . . . 15
4.1.3. Terminating Null Chunk . . . . . . . . . . . . . 16
4.2. Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
4.3. Packet Receipt Times Report Block. . . . . . . . . . . . 18
4.4. Receiver Reference Time Report Block . . . . . . . . . . 20
4.5. DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
4.6. Statistics Summary Report Block. . . . . . . . . . . . . 22
4.7. VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
4.7.1. Packet Loss and Discard Metrics. . . . . . . . . 27
4.7.2. Burst Metrics. . . . . . . . . . . . . . . . . . 27
4.7.3. Delay Metrics. . . . . . . . . . . . . . . . . . 30
4.7.4. Signal Related Metrics . . . . . . . . . . . . . 31
4.7.5. Call Quality or Transmission Quality Metrics . . 33
4.7.6. Configuration Parameters . . . . . . . . . . . . 34
4.7.7. Jitter Buffer Parameters . . . . . . . . . . . . 36
5. SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
5.2. Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
5.3. Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
6.1. XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
6.2. RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
6.3. The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
A. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Sequence Number Interpretation . . . . . . . . . . . . . 46
A.2. Example Burst Packet Loss Calculation. . . . . . . . . . 47
Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 551. Introduction 🦋
okay so this doc defines the Extended Report (XR) packet type for RTCP [9], and it explains how an app can signal XR packet use when it uses SDP [4] 💅 XR packets carry info that goes beyond what's already in the reception report blocks of RTCP's sender report (SR) or Receiver Report (RR) packets. This info is useful across RTP profiles, so it doesn't belong in SR or RR profile-specific extensions. Network management info is a great example of this 🌈
The definition is split across the three sections right after the Introduction. Section 2 says an XR packet is an eight octet header followed by a series of components called report blocks. Section 3 defines the common format (or framework), which has a type and a length field and is required for all report blocks. Section 4 defines several specific report block types, and other block types can be defined in future documents whenever they're needed ✨
The report block types in this doc fall into three categories 🍓
- The first category is packet-by-packet reports on received or lost RTP packets.
- The second category conveys reference time info between RTP participants.
- The third category has summary metrics about packet receipts. They're more detailed, or a different type, than what existing RTCP packets carry.
All told, seven report block formats are defined here 👑 Three of them are packet-by-packet block types:
- Loss RLE Report Block (Section 4.1): Run length encoding of reports about the losses and receipts of RTP packets.
- Duplicate RLE Report Block (Section 4.2): Run length encoding of reports about duplicates of received RTP packets.
- Packet Receipt Times Report Block (Section 4.3): A list of reception timestamps of RTP packets.
There are two reference time related block types 🧚
- Receiver Reference Time Report Block (Section 4.4): Receiver-end wallclock timestamps. Together with the DLRR Report Block (below), these let non-senders calculate round-trip times.
- DLRR Report Block (Section 4.5): The delay since the last Receiver Reference Time Report Block was received. An RTP data sender that gets a Receiver Reference Time Report Block can respond with a DLRR Report Block. It's kinda like how RTCP already works: an RTP data receiver that gets a sender's NTP timestamp can respond by filling in the DLSR field of an RTCP reception report block [9, Section 6.3.1] 🫶
And finally, there are two summary metric block types 💜
- Statistics Summary Report Block (Section 4.6): Stats on RTP packet sequence numbers, losses, duplicates, jitter, and TTL or Hop Limit values.
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls 📞
Before we get to the XR packet and report block definitions, this doc gives an applicability statement (Section 1.1) that explains where these report blocks can be used 🎀 It also defines (Section 1.2) the normative use of key words, such as MUST and SHOULD, as they're used in this document. Fully iconic for keeping things precise 🙈
After the report block definitions, the doc explains how apps that use SDP can signal their use (Section 5) 🌸 It wraps up with a discussion of numbering considerations for the Internet Assigned Numbers Authority (IANA) (Section 6), security considerations (Section 7), and appendices with examples of how to implement the algorithms covered in the text 🔥
1.1. Applicability 🦋
okay so XR packets are giving multi-app energy 🌈 they're useful across loads of different applications, which is exactly why they're not defined as profile-specific extensions to RTCP sender or Receiver Reports [9, Section 6.4.3]. 💅 they aren't useful in every single context tho, ngl. the VoIP metrics report block (Section 4.7) is specific to voice apps 📞 though it can be used across a whole bunch of them 🎀
the VoIP metrics report block works for any one-to-one or one-to-many voice app that's specified to use RTP and RTCP 🎧 but conversational metrics (Section 4.7.5), like the R factor (as described by the E Model defined in [3]) and the mean opinion score for conversational quality (MOS-CQ), aren't defined for apps other than simple two party calls 🙅♀️ so in multicast conferencing they should be marked as unavailable 🫶
the packet-by-packet report block types, Loss RLE (Section 4.1), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), were built with network tomography in mind 🕵️♀️ like multicast inference of network characteristics (MINC) [11]. MINC needs detailed packet receipt traces from multicast session receivers so it can figure out the gross structure of the multicast distribution tree 🌳 plus the parameters, such as loss rates and delays, that apply to paths between the branching points of that tree 📉
any real time multicast multimedia app can use the packet-by-packet report block types 🎬 an app like that could run a MINC inference subsystem to get multicast tree topology info 🗺️ one potential use would be spotting high loss regions in the tree and finding the session participants who are well situated to resend lost packets 🔁
detailed packet-by-packet reports don't have to hog disproportionate bandwidth compared to other RTCP packets 🙌 an app can cap their size. there's a mechanism called "thinning" for these report blocks ✂️ it keeps them within a size limit by restricting the number of packets reported upon within any sequence number interval, and the rationale for it and how it's used is described in [13]. also, apps might not need report blocks from every receiver to answer stuff like where in the multicast tree there are paths that exceed a defined loss rate threshold 🔍 smart choices about which receivers send these blocks can cut down the RTCP bandwidth they eat even more 💖
dedicated network monitoring apps might find it appropriate to allow more than 5% of RTP data bandwidth to be used for RTCP packets 📊 that way they get proportionately larger and more detailed report blocks 🧁
the packet-by-packet block types aren't restricted to multicast either 🙅 they could do network tomography similar to MINC but with striped unicast packets instead 🦋 and if it turned out useful, they could also be used for apps limited to two participants 📞
one thing the packet-by-packet reports aren't immediately suited for is data packet acknowledgments as part of a packet retransmission mechanism 🙈 the reason is that the packet accounting technique suggested for these blocks is different from the packet accounting normally used by RTP. the goal is to favor measurement apps, so the data receiver interprets as little as possible and leaves as much interpretation as possible to the participants that receive the report blocks 🧠 for example, a packet with an anomalous SSRC ID or an anomalous sequence number might be excluded by normal RTP accounting, but would be reported upon for network monitoring purposes 🕵️
the Statistics Summary Report Block (Section 4.6) also has network monitoring in mind 📊 it can be used just as well for reporting on unicast and multicast packet reception 💜
the reference time related block types were conceived for receiver-based TCP-friendly multicast congestion control [18] 🚦 by letting data receivers calculate their round trip times to senders, they help the receivers estimate the downstream bandwidth they should request 🧮 note that if every receiver sends Receiver Reference Time Report Blocks (Section 4.4), a sender might potentially send a number of DLRR Report Blocks (Section 4.5) equal to the number of receivers whose RTCP packets have arrived at the sender within its reporting interval 😳 as the number of participants in a multicast session increases, an application should use discretion regarding which participants send these blocks, and how frequently 🫧
XR packets supplement the existing RTCP packets and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6] 🧩 adding XR packets to a session in no way changes the rules governing the calculation of the RTCP reporting interval [9, Section 6.2] 📐 and since XR packets are RTCP packets, they count as such for bandwidth calculations 🧾 so the extra reporting info may tend to increase the average RTCP packet size, and thus the average reporting interval ⏱️ that increase may be limited by limiting the size of XR packets 🎀
the SDP signaling defined for XR packets in this document (Section 5) was designed with three use scenarios in mind 🎯 a Real Time Streaming Protocol (RTSP) controlled streaming app, a one-to-many multicast multimedia app such as a course lecture with enhanced feedback 🎓, and a Session Initiation Protocol (SIP) controlled conversational session involving two parties 📞 apps that employ SDP are free to use additional SDP signaling for cases not covered here 💅 and apps are also free to use signaling mechanisms other than SDP 🦋
1.2. Terminology 📖
so here's the deal with the key words 🔑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliance with this specification.
2. XR Packet Format 🎀
an XR packet is a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks 📦 it's laid out like other RTCP packets when it comes to the essential version, packet type, and length info 🧸 so XR packets are backwards compatible with RTCP receiver implementations that don't recognize them 🫶 those implementations ought to be able to parse past them using the length information 🏃♀️ a padding field and an SSRC field also sit in the same locations they do in other RTCP packets, just for simplicity 💖 here's the format ✨
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|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+version (V): 2 bits— identifies the version of RTP 🔢 this specification applies to RTP version two 💜padding (P): 1 bit— if the padding bit is set, this XR packet contains some additional padding octets at the end 🧱 the semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification 📜reserved: 5 bits— this field is reserved for future definition 🔒 in the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver 🚫packet type (PT): 8 bits— contains the constant 207 to identify this as an RTCP XR packet 🏷️ this value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 6.1 🗂️length: 16 bits— as described for the RTCP Sender Report (SR) packet (see Section 6.4.1 of the RTP specification [9]) ⏰ briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding 📏SSRC: 32 bits— the synchronization source identifier for the originator of this XR packet 🆔report blocks: variable length.— zero or more extended report blocks 🧩 in keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words 🧱
3. Extended Report Block Framework ✨
extended report blocks are stacked, one after the other, at the end of an XR packet 🥞 an individual block's length is a multiple of 4 octets 📐 the XR header's length field describes the total length of the packet, including these extended report blocks 📦
each block has block type and length fields that make parsing easier 🧩 a receiving app can demultiplex the blocks based on their type, and can use the length information to locate each successive block, even when it runs into block types it doesn't recognize 🔍
an extended report block has the following format 👇
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific block contents :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block type (BT): 8 bits— identifies the block format 🪪 seven block types are defined in Section 4 🔢 additional block types may be defined in future specifications 🔮 this field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Section 6.2 🗂️type-specific: 8 bits— the use of these bits is determined by the block type definition 🎛️block length: 16 bits— the length of this report block, including the header, in 32-bit words minus one 📏 if the block type definition permits, zero is an acceptable value, signifying a block that consists of only the BT, type-specific, and block length fields, with a null type-specific block contents field 🫧type-specific block contents: variable length— the use of this field is defined by the particular block type 🧁 subject to the constraint that it MUST be a multiple of 32 bits long 📏 if the block type definition permits, it MAY be zero bits long 🫧
4. Extended Report Blocks ✨
okay so this section gives us seven extended report blocks 💅 They cover reporting on received packet losses and duplicates, packet reception times, receiver reference time info, receiver inter-report delays, detailed reception stats, and VoIP metrics. An implementation SHOULD ignore incoming blocks with types that aren't relevant or that it doesn't recognise 🙈 And any new block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [16], as described in Section 6.2 🎀
4.1. Loss RLE Report Block 🦋
this block type lets you report on each individual packet receipt and loss event, which is so detailed it's giving microscope 🔬 These reports can be used for multicast inference of network characteristics (MINC) [11]. With MINC, you can figure out the topology of the multicast tree that carries a source's RTP packets, plus the loss rates along each link in that tree. Or you can just feed the raw data to a network management application. 🧚
Here's the thing: a Boolean trace of lost and received RTP packets can get really long, so this block lets you compress it with run length encoding 💜 To shrink the block even more, loss event reports can be systematically dropped from the trace. That's called thinning, and we'll get into it below. It's also studied in [13] 🌸
A participant that generates a Loss RLE Report Block should favour accuracy in reporting observed events over interpreting them, whenever that's possible 🫶 Interpretation is left to whoever observes the report blocks. This means accounting for Loss RLE Report Blocks is different from the accounting used for generating the SR and RR packets in the RTP specification [9], in two areas: per-sender accounting and per-packet accounting. 👑
For per-sender accounting, an RTP session participant SHOULD NOT make receiving a threshold minimum number of RTP packets a condition for reporting on the sender of those packets. This is different from the technique in Section 6.2.1 and Appendix A.1 of the RTP specification, which uses a threshold to decide whether a sender counts as valid 🙅♀️
For per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This is different from Appendix A.1 of the RTP specification, which suggests ruling a sequence number valid or invalid based on whether it lines up with the sequence numbers of packets already received 💅
Sender validity and sequence number validity are interpretations of the raw data, and they're justified for things like keeping a stray old packet from an unrelated session from messing with the RTCP transmission interval calculation ✨ On the flip side, a network monitoring application might actually be super interested in those stray packets 👀
One accounting interpretation is still needed: a participant has to decide whether the 16 bit sequence number has rolled over. Usually this is easy. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it's reasonable to assume a rollover happened. But it's also possible the packet is an older one (from 65,535 packets earlier). The sequence numbers could also have rolled over multiple times, forwards or backwards. It gets harder when there are big gaps between sequence numbers, even after accounting for rollover, or when there are long intervals between received packets 😭
The per-packet accounting technique mandated here is that a participant keeps track of the sequence number of the most recently received packet from each sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead of or behind the most recent one, whichever choice puts it closer. If both choices are equally distant (which can only happen when the distance is 32,768), the choice MUST be the one that doesn't require a rollover. Appendix A.1 has an algorithm that implements this technique 🧮
Each block reports on a single RTP data packet source, identified by its SSRC. The receiver supplying the report is identified in the header of the RTCP packet 🎀
The application gets to choose the beginning and ending RTP packet sequence numbers for the trace, and those values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report 🦋
Because of sequence number wraparound, the ending sequence number MAY be less than the beginning sequence number 🔄 And a Loss RLE Report Block MUST NOT be used to report on a range of 65,534 or greater in the sequence number space, because there's no way to identify multiple wraparounds. Not allowed, bestie 🙅♀️
The trace described by a Loss RLE report is a sequence of Boolean values, one for each sequence number in the trace. A value of one means a packet receipt: one or more packets with that sequence number have been received since the most recent wraparound of sequence numbers (or since the beginning of the RTP session, if no wraparound has been judged to have occurred). A value of zero means a packet loss: no packet with that sequence number has been received as of the time of the report. If a packet with a given sequence number is received after a loss was reported for it, a later Loss RLE report MAY report a packet receipt for that sequence number 🌈
The encoding itself is a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk is either a run length, a bit vector, or a null chunk. A run length describes between 1 and 16,383 events that are all the same (all receipts or all losses). A bit vector describes 15 events that can be a mix of receipts and losses. A null chunk describes no events and is used to round the block out to a 32 bit word boundary 🍓
The mapping from a sequence of lost and received packets into chunks isn't necessarily unique 🙈 For example, this trace covers 45 packets, where the 22nd and 24th were lost and the rest were received:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1One way to encode it:
bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunkAnother way to encode it:
run of 21 receipts
bit vector 0101 1111 1111 111
run of 9 receipts
null chunkThe choice of encoding is up to the application 💅 As part of that freedom, applications MAY end a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence was lost:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1This could be encoded as:
run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunkIn this example, the last five bits of the second bit vector describe a part of the sequence number space that goes past the last sequence number in the trace. Those bits have been set to zero 🧸
All bits in a bit vector chunk that describe a part of the sequence number space beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver. Zero them, then ignore them, periodt 💅
A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context. Super specific, but we love a rule 🫶
Caution should be used when sending Loss RLE Report Blocks! Even with run length encoding's compression, they can easily eat up bandwidth out of proportion with normal RTCP packets 💀 That's why the block type includes thinning, a mechanism that lets an application limit report sizes.
Thinning works like this: a thinning value, T, selects a subset of packets in the sequence number space, namely the ones whose sequence numbers are multiples of 2^T. Packet reception and loss reports only apply to those packets. T can range from 0 to 15. If T is zero, every packet in the sequence number space gets reported on. If T is fifteen, then only one in every 32,768 packets gets reported on 🦋
Let's do an example 🧁 Say the trace we just looked at begins at sequence number 13,821 and the last sequence number in the trace is 13,865. If the trace is thinned with T=2, these sequence numbers get reported on: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace looks like this:
1 1 1 1 1 0 1 1 1 1 0This could be encoded as follows:
bit vector 1111 1011 1100 000
null chunkThe last four bits in the bit vector, which stand for sequence numbers 13,868, 13,872, 13,876, and 13,880, go past the trace. They're set to zero and ignored by the receiver 🙈 With thinning, the loss of the 22nd packet goes unreported, because its sequence number, 13,842, isn't a multiple of four. Receipts for all sequence numbers that aren't multiples of four go unreported too. But in this example, thinning still managed to shorten the Loss RLE Report Block by one 32 bit word, which is a major win ✨
The choice of thinning value is left to the application 💜
The Loss RLE Report Block has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means 🌸
- block type (BT): 8 bits. A Loss RLE Report Block is identified by the constant 1.
- rsvd.: 4 bits. This field is reserved for future definition. Until it's defined, the bits in this field MUST be set to zero and MUST be ignored by the receiver. Reserved means hands off, for now 🫶
thinning (T): 4 bits okay so this one is the thinning dial 🎀 It's the amount of thinning done on the sequence number space. Only packets with sequence numbers 0 mod 2^T get reported on by this block. A value of 0 means no thinning, so every packet gets reported on 💅 The max thinning is one packet in every 32,768 (which is literally two packets in each 16-bit sequence space) 😭
block length: 16 bits Defined in Section 3. ✨
SSRC of source: 32 bits This is the SSRC of the RTP data packet source being reported on by this report block 🦋
begin_seq: 16 bits The first sequence number this block reports on 🌸
end_seq: 16 bits The last sequence number this block reports on, plus one. Yes, the plus one is important 🙈
chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null. They're each defined in the sections below 🧚 If the chunk is all zeroes, it's a terminating null chunk. Otherwise, the left most bit decides the type: 0 means run length and 1 means bit vector. Iconic sorting system, honestly 👑
4.1.1. Run Length Chunk
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+chunk type (C): 1 bit A zero identifies this as a run length chunk 💖
run type (R): 1 bit Zero means a run of 0s. One means a run of 1s. Simple, but make it make sense 🍓
run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk, because zeroes in both the run type and run length fields would turn it into a terminating null chunk 😭 Run lengths of 15 or less MAY be described with a run length chunk, even though they could also be described as part of a bit vector chunk. Options are good, bestie 🌈
4.1.2. Bit Vector Chunk
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+chunk type (C): 1 bit A one identifies this as a bit vector chunk ✨
bit vector: 15 bits You read the vector from left to right, going in order of increasing sequence number (with the right allowance for wraparound) 🔥
4.1.3. Terminating Null Chunk
This chunk is all zeroes. Literally just zeros, no cap 🫶
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2. Duplicate RLE Report Block
Okay this block type lets you do per-sequence-number reports on duplicates in a source's RTP packet stream 🦋 That info is useful for network diagnosis, and it's a cute alternative to packet losses as a basis for multicast tree topology inference 🌳
The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation changes, because the info is about packet duplicates instead of packet losses 💅 The trace being encoded still uses zeros and ones, but here a zero means duplicate packets showed up for that sequence number, and a one means no duplicates were received.
Whether a duplicate exists for a given sequence number is decided over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, and then another packet numbered 12,593 shows up later in the reporting period, that counts as a duplicate for that sequence number 👀 The duplicate doesn't have to come right after the first one. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space 🙈
No distinction is made between one duplicate packet and multiple duplicate packets for a given sequence number. Also, since a lost packet has no duplicate, a loss gets encoded as a one in a Duplicate RLE Report Block 🤯
The Duplicate RLE Report Block has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2 🎀
rsvd.: 4 bits This field is reserved for future definition. Until something is defined, the bits in this field MUST be set to zero and MUST be ignored by the receiver 🫶
thinning (T): 4 bits As defined in Section 4.1. Same dial, new block 🧚
block length: 16 bits Defined in Section 3. ✨
SSRC of source: 32 bits As defined in Section 4.1. 💜
begin_seq: 16 bits As defined in Section 4.1. 🌸
end_seq: 16 bits As defined in Section 4.1. 🌸
chunk i: 16 bits As defined in Section 4.1. The chunks work exactly the same way here 💅
4.3. Packet Receipt Times Report Block
This block type lets you do per-sequence-number reports on packet receipt times for a given source's RTP packet stream 🕰️ That info can be used for MINC inference of the topology of the multicast tree that distributes the source's RTP packets, and of the delays along the links in that tree 🌲 It can also measure partial path characteristics and model distributions for packet jitter. Main character data, honestly 👑
Packet receipt times are expressed in the same units as the RTP timestamps of data packets. This way, for each packet, you can figure out both the send time and the receipt time in comparable terms 🦋 Just note that an RTP sender usually starts its time at a value chosen at random, so there's no expectation that the reported send and receipt times will differ by the one-way delay between sender and receiver 🙃 The reported times can still be useful for the purposes mentioned above, though ✨
At least one packet MUST have been received for each sequence number reported upon in this block. If this block type reports receipt times for a series of sequence numbers that includes lost packets, you'll need several blocks 📦 If duplicate packets have been received for a given sequence number, and those packets have different receipt times, any time other than the earliest MUST NOT be reported. This keeps reports consistent with each other 🫶
Times reported in RTP timestamp format take up more bits than loss or duplicate info, and they don't lend themselves to run length encoding 😭 So thinning is encouraged to keep Packet Receipt Times Report Blocks small 🌸
The Packet Receipt Times Report Block has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (begin_seq + 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block type (BT): 8 bits A Packet Receipt Times Report Block is identified by the constant 3 🦋
rsvd.: 4 bits This field is reserved for future definition. Until something is defined, the bits in this field MUST be set to zero and MUST be ignored by the receiver 🫶
thinning (T): 4 bits As defined in Section 4.1. 🧚
block length: 16 bits Defined in Section 3. ✨
SSRC of source: 32 bits As defined in Section 4.1. 💜
begin_seq: 16 bits As defined in Section 4.1. 🌸
end_seq: 16 bits As defined in Section 4.1. 🌸
Packet i receipt time: 32 bits This is the receipt time of the packet with sequence number i at the receiver. The modular arithmetic in the packet format diagram lets sequence numbers roll over 🔄 It's preferable for the time value to be set at the link layer interface, or at least as close as possible to the wire arrival time ⏱️ Units and format match the timestamp in RTP data packets. Here's the twist: RTP data packet timestamps can use nominal values instead of system clock values so they can carry info useful for periodic playout, but receipt times should reflect the actual time as closely as possible 💖 For a session where the RTP timestamp is chosen at random, the first receipt time value SHOULD also be chosen at random, and later timestamps are offset from that value 🎲 On the other hand, if the RTP timestamp is meant to reflect the reference time at the sender, then the receipt time SHOULD be as close as possible to the reference time at the receiver 🌈
4.4. Receiver Reference Time Report Block ✨
okay so this block is giving "timestamps for everyone" 🕰️💖 It extends RTCP's timestamp reporting so that non-senders can send timestamps too, which is literally so iconic. It repeats the NTP timestamp fields from the RTCP Sender Report [9, Sec. 6.3.1]. That means a non-sender can estimate its round trip time (RTT) to other participants, as proposed in [18], by sending this report block and then getting DLRR Report Blocks (see next section) back in reply 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block type (BT): 8 bits 🍓 A Receiver Reference Time Report Block is identified by the constant 4.
reserved: 8 bits 🧚 This field is reserved for future definition. Until that happens, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
block length: 16 bits 🎀 The constant 2, in accordance with the definition of this field in Section 3.
NTP timestamp: 64 bits ⏰ This indicates the wallclock time when this block was sent, so it can be combined with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty is not indicated, as it may not be known. A report block sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero. 🫶
4.5. DLRR Report Block 🌈
this one extends RTCP's delay since the last Sender Report (DLSR) mechanism [9, Sec. 6.3.1] so that non-senders can calculate round trip times too, as proposed in [18]. It's called DLRR, for delay since the last Receiver Report 💅 It can be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver, so that receiver can calculate its round trip time to the respondent. The report is made of one or more 3 word sub-blocks, with one sub-block per Receiver Report ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=5 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+block type (BT): 8 bits 🍓 A DLRR Report Block is identified by the constant 5.
reserved: 8 bits 🧚 This field is reserved for future definition. Until that happens, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
block length: 16 bits 🎀 Defined in Section 3.
last RR timestamp (LRR): 32 bits 🕰️ This is the middle 32 bits out of the 64 in the NTP timestamp (as explained in the previous section). It is received as part of a Receiver Reference Time Report Block from participant SSRC_n. If no such block has been received, the field is set to zero.
delay since last RR (DLRR): 32 bits ⏳ This is the delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Reference Time Report Block from participant SSRC_n and sending this DLRR Report Block. If a Receiver Reference Time Report Block has yet to be received from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LRR using the last RR timestamp (LRR) field, and then subtracts this field to leave the round-trip propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig. 2]. 🔥
4.6. Statistics Summary Report Block 📊
this block reports stats beyond what's in the standard RTCP packet format, but it's not as finely grained as the report blocks we've already covered 🤓 It records info about lost packets, duplicate packets, jitter measurements, and TTL or Hop Limit values. This is so useful for network management, honestly 💜
The contents of the report block depend on a series of flag bits in the first part of the header. Not every parameter has to be reported in each block. The flags show which ones are reported and which aren't. The fields for unreported parameters MUST be present, but they're set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported. Rude to the zeros if you don't ignore them 😭
The Statistics Summary Report Block has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=6 |L|D|J|ToH|rsvd.| block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mean_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block type (BT): 8 bits 🍓 A Statistics Summary Report Block is identified by the constant 6.
loss report flag (L): 1 bit 💔 Bit set to 1 if the lost_packets field contains a report, 0 otherwise.
duplicate report flag (D): 1 bit 👯 Bit set to 1 if the dup_packets field contains a report, 0 otherwise.
jitter flag (J): 1 bit 🌊 Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and dev_jitter fields all contain reports, 0 if none of them do.
TTL or Hop Limit flag (ToH): 2 bits 🦋 This field is set to 0 if none of the fields min_ttl_or_hl, max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports. If the field is non-zero, then all of these fields contain reports. The value 1 signifies that they report on IPv4 TTL values. The value 2 signifies that they report on IPv6 Hop Limit values. The value 3 is undefined and MUST NOT be used. no 3 allowed, bestie 🙅♀️
rsvd.: 3 bits 🧚 This field is reserved for future definition. Until such a definition exists, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
block length: 16 bits 🎀 The constant 9, in accordance with the definition of this field in Section 3.
SSRC of source: 32 bits 🫶 As defined in Section 4.1.
begin_seq: 16 bits 🔢 As defined in Section 4.1.
end_seq: 16 bits 🔢 As defined in Section 4.1.
lost_packets: 32 bits 💀 Number of lost packets in the above sequence number interval.
dup_packets: 32 bits 👯 Number of duplicate packets in the above sequence number interval.
min_jitter: 32 bits 🌸 The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units.
max_jitter: 32 bits 🌸 The maximum relative transit time between two packets in the above sequence number interval.
mean_jitter: 32 bits 🌸 The mean relative transit time between each two packet series in the above sequence number interval, rounded to the nearest value expressible as an RTP timestamp.
dev_jitter: 32 bits 🌸 The standard deviation of the relative transit time between each two packet series in the above sequence number interval.
min_ttl_or_hl: 8 bits 🌙 The minimum TTL or Hop Limit value of data packets in the sequence number range.
max_ttl_or_hl: 8 bits 🌞 The maximum TTL or Hop Limit value of data packets in the sequence number range.
mean_ttl_or_hl: 8 bits ✨ The mean TTL or Hop Limit value of data packets in the sequence number range, rounded to the nearest integer.
dev_ttl_or_hl: 8 bits ✨ The standard deviation of TTL or Hop Limit values of data packets in the sequence number range.
4.7. VoIP Metrics Report Block ✨
okay so the VoIP Metrics Report Block is basically the call-quality report card 📞💖 It gives you metrics for keeping an eye on voice over IP (VoIP) calls, and it covers packet loss and discard numbers, delay numbers, analog-ish levels, and voice quality scores 🎀 The block tracks packets lost on the IP channel separately from packets that actually arrived but got tossed by the receiving jitter buffer. It also gives you the combined total, since both kinds of loss hit call quality equally 🫶
ngl this is so important, because to really judge a VoIP call you need to know how bursty the packet loss is 😭 Following a Gilbert-Elliott model [14], a stretch of time bounded by lost and/or discarded packets with a high rate of losses and/or discards counts as a "burst" [3], and the stretch between two bursts is a "gap" 🦋 Bursts are the moments where the loss rate is high enough that the audio actually sounds bad, and gaps are where only isolated lost packets show up. Those can usually get hidden by packet loss concealment, so they're way less scary 💅
The delay reports cover two things that both add up to the delay the user actually feels: the transit delay between RTP end points, and the processing delay inside the VoIP end system 🧚 Then there are the extra metrics for signal, echo, noise, and distortion levels. The call quality part includes R factors (described by the E Model defined in [6,3]) and mean opinion scores (MOS scores) 👑
Now the big rules, bestie 🙈 Implementations MUST provide values for all the fields defined here. And if a metric is undefined or unknown, the specified default or unknown field value MUST be provided. no skipping, no vibes-based guessing 💀
The block is encoded as seven 32-bit words:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=7 | reserved | block length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal level | noise level | RERL | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R factor | ext. R factor | MOS-LQ | MOS-CQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX config | reserved | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7. 🔥
reserved: 8 bits This field is reserved for future definition. Until someone defines it, the bits in this field MUST be set to zero and MUST be ignored by the receiver 🙈
block length: 16 bits The constant 8, in line with how this field is defined in Section 3.
SSRC of source: 32 bits Same deal as defined in Section 4.1 🌸
The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters.
4.7.1. Packet Loss and Discard Metrics
It is very useful to tell apart packets the network lost and packets that got discarded because of jitter 🦋 Both hurt the voice stream equally, but having separate counts helps you figure out where the quality drop is coming from 🕵️♀️ These fields MUST be populated, and they MUST be set to zero if no packets have been received.
loss rate: 8 bits This is the fraction of RTP data packets from the source that got lost since reception began, written as a fixed point number with the binary point at the left edge of the field 💅 To get it, you take the total number of lost packets (after any error protection such as FEC has been applied) and divide it by the total number of packets expected. Multiply that result by 256, cap the max at 255 so it doesn't overflow, and keep just the integer part. Duplicated and discarded packets do NOT count in this math 🙅♀️ Receivers can't be forced to keep unlimited buffers, so a receiver MAY categorize late-arriving packets as lost. But the lateness that triggers a loss SHOULD be way bigger than the lateness that triggers a discard. that's the vibe 💜
discard rate: 8 bits This is the fraction of RTP data packets from the source that have been discarded since reception began, because they arrived late or early, or because the receiving jitter buffer ran under or overflowed 🌈 It's also a fixed point number with the binary point at the left edge. You get it by dividing the total number of discarded packets (not counting duplicate packet discards) by the total number of packets expected, multiplying by 256, limiting the max to 255 (to avoid overflow), and taking the integer part ✨
4.7.2. Burst Metrics ✨
Okay bestie, so a burst is a stretch where a whole bunch of packets get lost or discarded because they showed up too late 💀. We define it using a value called Gmin. A burst is the longest sequence that:
- (a) starts with a lost or discarded packet,
- (b) doesn't contain any occurrences of Gmin or more consecutively received (and not discarded) packets, and
- (c) ends with a lost or discarded packet.
A gap is basically the chill zone 🌸, a period with low losses and/or discards. Formally, a gap is any of these:
- (a) the period from the start of an RTP session to the receipt time of the last received packet before the first burst,
- (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or
- (c) the period of time between two bursts.
For figuring out whether a lost or discarded packet near the start or end of an RTP session sits in a gap or a burst, we pretend the RTP session is preceded and followed by at least Gmin received packets. We also pretend the time of the report is followed by at least Gmin received packets 🧚.
A gap has a lovely property: any lost or discarded packets inside it must be preceded and followed by at least Gmin packets that were received and not discarded. That gives a maximum loss/discard rate within a gap of 1 / (Gmin + 1) 🎀.
A Gmin value of 16 is RECOMMENDED, because it gives gap characteristics that match good quality (low packet loss rate, with a minimum distance of 16 received packets between lost packets) 💖. That means it nicely separates the good periods from the bad ones ✨.
Here's an example, where a 1 is a received packet, a 0 is a lost packet, and an X is a discarded packet, covering 64 packets:
11110111111111111111111X111X1011110111111111111111111X111111111
|---------gap----------|--burst---|------------gap------------|The burst is the twelve packets marked above, starting at a discarded packet and ending at a lost packet 🥀. The first gap starts at the beginning of the session, and the second gap ends at the time of the report.
If the packet spacing is 10 ms and Gmin is the recommended 16, then the burst duration is 120 ms, the burst density is 0.33, the gap duration is 230 ms + 290 ms = 520 ms, and the gap density is 0.04 📊.
This would turn into these reported values (check the field descriptions below for the real semantics and how they're calculated 👀):
loss rate 12, which corresponds to 5%
discard rate 12, which corresponds to 5%
burst density 84, which corresponds to 33%
gap density 10, which corresponds to 4%
burst duration 120, value in milliseconds
gap duration 520, value in millisecondsburst density: 8 bits Okay, this is the fraction of RTP data packets inside burst periods (since reception began) that were either lost or discarded 🍓. It's a fixed point number with the binary point on the left edge of the field. To get it, you divide the total number of packets lost or discarded (not counting duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiply that by 256, cap the max at 255 so it doesn't overflow, and take the integer part. This field MUST be populated and MUST be set to zero if no packets have been received 🙈.
gap density: 8 bits Same energy as burst density, but for the inter-burst gaps 🌈. It's the fraction of RTP data packets within gaps (since reception began) that were either lost or discarded. It's a fixed point number with the binary point on the left edge. You divide the total number of packets lost or discarded (not counting duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiply by 256, limit the maximum value to 255 (to avoid overflow), and take the integer part. This field MUST be populated and MUST be set to zero if no packets have been received 💅.
burst duration: 16 bits This is the mean duration, in milliseconds, of the burst periods that have happened since reception began ⏱️. Each period's duration comes from the packets that mark its beginning and end. It equals the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values aren't available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero 🦋.
gap duration: 16 bits This is the mean duration, in milliseconds, of the gap periods that have happened since reception began 🌸. Each gap's duration comes from the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It equals the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values aren't available, estimated values MUST be used. For a gap at the very beginning of reception, the sum of the timestamp and duration of the prior burst packet gets replaced by the reception start time. For a gap at the very end of reception, the timestamp of the subsequent burst packet gets replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero 🫶.
4.7.3. Delay Metrics ✨
Okay so, for these definitions, the RTP interface is the line between the RTP instance and the voice application (think FEC, de-interleaving, de-multiplexing, and the jitter buffer) 🎀. For example, delay from RTP payload multiplexing counts as part of the voice application or end-system delay. But delay from multiplexing RTP frames inside a UDP frame counts as part of the RTP reported delay. This split matches how RTCP does its delay measurements, so it's consistent 💜.
round trip delay: 16 bits This is the most recently calculated round trip time between RTP interfaces, in milliseconds 🔥. This value MAY be measured using RTCP, or with the DLRR method defined in Section 4.5 of this document (where you need to convert the units from NTP timestamp values to milliseconds), or with other approaches. If RTCP is used, the reported delay value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (Sender Report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is required in order to calculate round trip delay. A value of 0 is permissible, but this field MUST be populated as soon as a delay estimate is available 👑.
end system delay: 16 bits This is the most recently estimated end system delay, in milliseconds ⭐. End system delay is the sum of the total sample accumulation and encoding delay on the sending side, plus the jitter buffer, decoding, and playout buffer delay on the receiving side 🌷. This delay MAY be estimated or measured. This value SHOULD be provided in all VoIP metrics reports. If an implementation can't provide the data, the value 0 MUST be used 🥹.
Note that you can calculate the one way symmetric VoIP segment delay from the round trip and end system delays. If the round trip delay is denoted RTD, and the end system delays for the two endpoints are ESD(A) and ESD(B), then:
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 24.7.4. Signal Related Metrics 🎤✨
okay so these metrics are all about the non-packet stuff in a VoIP system, aka the audio signal itself 🎧. they help you figure out why a call sounds bad. the values have to be determined for the received audio signal. ngl the info might not be available in every system, but it is strongly recommended that this data SHOULD be provided so people can diagnose problems 💖
signal level: 8 bits
the voice signal relative level is the ratio of the signal level to a 0 dBm0 reference [10], written in decibels as a signed integer in two's complement form. it's only measured for packets containing speech energy 🗣️. the goal isn't a super precise reading, it's a real time hint that the signal might be way too loud or way too quiet 📢
signal level = 10 Log10 ( rms talkspurt power (mW) )a value of 127 means this parameter is unavailable 🙈. typical values should generally sit somewhere in the -15 to -20 dBm range 🌸
noise level: 8 bits
the noise level is the ratio of the silent period background noise level to a 0 dBm0 reference, also written in decibels as a signed integer in two's complement form 🤫
noise level = 10 Log10 ( rms silence power (mW) )a value of 127 means this parameter is unavailable 💀
residual echo return loss (RERL): 8 bits
okay this one is so good 😭. the RERL can be measured directly by the VoIP end system's echo canceller, or estimated by adding the echo return loss (ERL) and echo return loss enhancement (ERLE) values that the echo canceller reports 🔁
RERL(dB) = ERL (dB) + ERLE (dB)for a VoIP gateway, the echo is usually line echo that happens at 2-4 wire conversion points in the network 🛤️. that can be in the 8-12 dB range. a line echo canceler can give an ERLE of 30 dB or more, which can knock it down to 40-50 dB ✨. for an IP phone, it could be acoustic coupling between the handset speaker and microphone, or leftover acoustic echo from speakerphone use. that's more accurately called terminal coupling loss (TCL) 📞. a typical handset gives 40-50 dB of echo loss from acoustic feedback 🎀
examples, because examples are everything 🍓:
- IP gateway connected to a circuit switched network with a 2 wire loop, no echo cancellation. the typical 2-4 wire converter ERL is 12 dB, so
RERL = ERL + ERLE = 12 + 0 = 12 dB. - IP gateway connected to a circuit switched network with a 2 wire loop, with an echo canceler that improves echo by 30 dB. so
RERL = ERL + ERLE = 12 + 30 = 42 dB. - IP phone with a conventional handset. acoustic coupling from the handset speaker to the microphone (terminal coupling loss) is typically 40 dB, so
RERL = TCL = 40 dB.
let's call the local end of the VoIP path A and the remote end B 🫶. if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is:
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)so, to fold echo into a voice quality estimate at the A end of a VoIP connection, it's desirable to send the ERL + ERLE value from B to A using a format such as RTCP XR 🦋
echo info might not be available in every VoIP end system 😤. but echo seriously affects conversational quality, so it is recommended that estimated values for echo return loss and terminal coupling loss be provided (if sensible estimates can reasonably be determined) 🧚
here are typical values for end systems, for guidance 💅:
- IP Phone with handset: typically 45 dB.
- PC softphone or speakerphone: extremely variable, consider reporting "undefined" (127).
- IP gateway with line echo canceller: typically has ERL and ERLE available.
- IP gateway without line echo canceller: frequently a source of echo related problems. consider reporting either a low value (12 dB) or "undefined" (127).
Gmin
see Configuration Parameters (Section 4.7.6, below). 👀
4.7.5. Call Quality or Transmission Quality Metrics 👑
these are the direct measures of call quality or transmission quality 🔥. they bake in the effects of codec type, packet loss, discard, burstiness, delay, etc. they might not be available in every system, but they SHOULD be provided to support problem diagnosis 🙌
R factor: 8 bits
the R factor is a voice quality metric for the part of the call carried over this RTP session 📈. it's an integer from 0 to 100, where 94 means "toll quality" and 50 or less is considered unusable 💀. it includes the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3] 🎀
a value of 127 means the parameter is unavailable. values other than 127 and the valid range above MUST not be sent, and MUST be ignored by the receiving system 🚫
ext. R factor: 8 bits
the external R factor covers the part of the call carried over a network segment outside the RTP segment, like a cellular network 📱. the values are read the same way as the RTP R factor. it also includes the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3], and it relates to the outward voice path from the Voice over IP termination this metrics block applies to 🌈
a value of 127 means unavailable. values other than 127 and the valid range above MUST not be sent, and MUST be ignored by the receiving system 🙅♀️
note that you can estimate an overall R factor from the RTP segment R factor and the external R factor, like this:
R total = RTP R factor + ext. R factor - 94MOS-LQ: 8 bits
the estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, where 5 is excellent and 1 is unacceptable 🎧. it does not include delay, and you can compare it to MOS scores from listening quality (ACR) tests 🧁. it's an integer from 10 to 50, which is MOS x 10. so a value of 35 means an estimated MOS of 3.5 ✨
a value of 127 means unavailable. values other than 127 and the valid range above MUST not be sent, and MUST be ignored by the receiving system 💜
MOS-CQ: 8 bits
the estimated mean opinion score for conversational quality (MOS-CQ) does include delay and other effects that would hurt conversational quality 🗨️. it can be calculated by converting an R factor (from ITU-T G.107 [6] or ETSI TS 101 329-5 [3]) into an estimated MOS using the equation in G.107. it's an integer from 10 to 50, which is MOS x 10, same as MOS-LQ 🫧
a value of 127 means unavailable. values other than 127 and the valid range above MUST not be sent, and MUST be ignored by the receiving system 🥺
4.7.6. Configuration Parameters ⚙️
Gmin: 8 bits
this is the gap threshold 🚧. it's the value this report block uses to decide whether a gap exists. the recommended value of 16 corresponds to a burst period with a minimum density of 6.25% lost or discarded packets, which can cause noticeable call quality degradation 😬. during gap periods, if packet loss or discard happens, each lost or discarded packet is preceded and followed by a run of at least 16 received non-discarded packets. heads up: lost or discarded packets that happen within Gmin packets of a report being generated may get reclassified as part of a burst or gap in later reports 🔄
ETSI TS 101 329-5 [3] has a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach 🧠. it's reproduced in Appendix A.2 of the present document 📖. Gmin MUST not be zero, MUST be provided, and MUST remain constant across VoIP Metrics report blocks for the duration of the RTP session 🔒
receiver configuration byte (RX config): 8 bits
this byte has the following fields 🧩:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+packet loss concealment (PLC): 2 bits
the values are: Standard (11), enhanced (10), disabled (01), unspecified (00) 🎶. when PLC = 11, a simple replay or interpolation algorithm fills in the missing packet 🔁. this is usually good at hiding isolated lost packets at low packet loss rates. when PLC = 10, an enhanced interpolation algorithm is in use, and these are really good at hiding high packet loss rates 🔥. when PLC = 01, silence is inserted in place of lost packets 🤫. when PLC = 00, there's no info about whether PLC is used, although for some codecs this may be inferred 🤷♀️
jitter buffer adaptive (JBA): 2 bits
the values are: Adaptive (11), non-adaptive (10), reserved (01), unknown (00) 🪄. when the jitter buffer is adaptive, its size is dynamically adjusted to handle varying levels of jitter 🌊. when it's non-adaptive, the size stays fixed 🧱. when either adaptive or non-adaptive mode is specified, the jitter buffer size parameters below MUST be specified 📏
jitter buffer rate (JB rate): 4 bits
J = adjustment rate (0-15) 💫. this is the implementation specific adjustment rate of a jitter buffer in adaptive mode. it's defined in terms of the approximate time to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms, like this:
adjustment time = 2 * J * frame size (ms)this parameter is only a guide to how "aggressive" an adaptive jitter buffer is, and it may be estimated 🎯. a value of 0 means the adjustment time is unknown for this implementation 🫠
reserved: 8 bits
this field is reserved for future definition 🔮. until something is defined, the bits in this field MUST be set to zero and MUST be ignored by the receiver 🫧
4.7.7. Jitter Buffer Parameters ✨
Okay bestie, the values in these fields SHOULD be the most recent ones you've got at the moment you report them 💅
jitter buffer nominal delay (JB nominal): 16 bits 🎀 This is the current nominal jitter buffer delay in milliseconds, which is the nominal delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations.
jitter buffer maximum delay (JB maximum): 16 bits 🦋 This is the current maximum jitter buffer delay in milliseconds, which is the delay for the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal size. In adaptive jitter buffer implementations, this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations.
jitter buffer absolute maximum delay (JB abs max): 16 bits 😭 This is the absolute maximum delay in milliseconds that the adaptive jitter buffer can reach under worst case conditions. If this value exceeds 65535 milliseconds, then this field SHALL convey the value 65535. This parameter MUST be provided for adaptive jitter buffer implementations, and its value MUST be set to JB maximum for fixed jitter buffer implementations.
5. SDP Signaling 🧚
This section defines Session Description Protocol (SDP) [4] signaling for XR blocks, which applications that use SDP can take advantage of 🌸. This signaling is defined to be used either by applications that implement the SDP Offer/Answer model [8], or by applications that use SDP to describe media and transport configurations alongside protocols like the Session Announcement Protocol (SAP) [15] or the Real Time Streaming Protocol (RTSP) [17]. There exist other potential signaling methods that are not defined here.
The XR blocks MAY be used without prior signaling. This is consistent with the rules governing other RTCP packet types, as described in [9]. An example in which signaling would not be used is an application that always requires the use of one or more XR blocks. However, for applications that are configured at session initiation, the use of some type of signaling is recommended.
Note that, although the use of SDP signaling for XR blocks may be optional, if used, it MUST be used as defined here. If SDP signaling is used in an environment where XR blocks are only implemented by some fraction of the participants, the ones not implementing the XR blocks will ignore the SDP attribute. 🙈
5.1. The SDP Attribute 💖
This section defines one new SDP attribute "rtcp-xr" that can be used to signal participants in a media session that they should use the specified XR blocks. This attribute can be easily extended in the future with new parameters to cover any new report blocks. 🦋
The RTCP XR blocks SDP attribute is defined below in Augmented Backus-Naur Form (ABNF) [2]. It is both a session and a media level attribute. When specified at session level, it applies to all media level blocks in the session. Any media level specification MUST replace a session level specification, if one is present, for that media block.
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
xr-format = pkt-loss-rle
/ pkt-dup-rle
/ pkt-rcpt-times
/ rcvr-rtt
/ stat-summary
/ voip-metrics
/ format-ext
pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
rcvr-rtt-mode = "all"
/ "sender"
stat-summary = "stat-summary" ["=" stat-flag *("," stat-flag)]
stat-flag = "loss"
/ "dup"
/ "jitt"
/ "TTL"
/ "HL"
voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39
format-ext = non-ws-string
non-ws-string = 1*(%x21-FF)
CRLF = %d13.10The "rtcp-xr" attribute contains zero, one, or more XR block related parameters. Each parameter signals functionality for an XR block, or a group of XR blocks. The attribute is extensible so that parameters can be defined for any future XR block (and a parameter should be defined for every future block). 🌈
Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions. 🤝
Round trip time (RTT) measurement is an example of collaborative functionality. An RTP data packet receiver sends a Receiver Reference Time Report Block (Section 4.4). A participant that receives this block sends a DLRR Report Block (Section 4.5) in response, allowing the receiver to calculate its RTT to that participant. As this example illustrates, collaborative functionality may be implemented by two or more different XR blocks. The collaborative functionality of several XR blocks may be governed by a single "rtcp-xr" parameter. 👑
For the unilateral category, this document defines the following parameters. The parameter names and their corresponding XR formats are as follows:
Parameter name XR block (block type and name)
-------------- ------------------------------------
pkt-loss-rle 1 Loss RLE Report Block
pkt-dup-rle 2 Duplicate RLE Report Block
pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report BlockThe "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters MAY specify an integer value. This value indicates the largest size the whole report block SHOULD have in octets. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size. 🍓
The "stat-summary" parameter contains a list indicating which fields SHOULD be included in the Statistics Summary report blocks that are sent. The list is a comma separated list, containing one or more field indicators. The space character (0x20) SHALL NOT be present within the list. Field indicators represent the flags defined in Section 4.6. The field indicators and their respective flags are as follows:
Indicator Flag
--------- ---------------------------
loss loss report flag (L)
dup duplicate report flag (D)
jitt jitter flag (J)
TTL TTL or Hop Limit flag (ToH)
HL TTL or Hop Limit flag (ToH)For "loss", "dup", and "jitt", the presence of the indicator indicates that the corresponding flag should be set to 1 in the Statistics Summary report blocks that are sent. The presence of "TTL" indicates that the corresponding flag should be set to 1. The presence of "HL" indicates that the corresponding flag should be set to 2. The indicators "TTL" and "HL" MUST NOT be signaled together. 🙅♀️
Blocks in the collaborative category are classified as initiator blocks or response blocks. Signaling SHOULD indicate which participants are required to respond to the initiator block. A party that wishes to receive response blocks from those participants can trigger this by sending an initiator block. 📣
The collaborative category currently consists only of one functionality, namely the RTT measurement mechanism for RTP data receivers. The collective functionality of the Receiver Reference Time Report Block and DLRR Report Block is represented by the rcvr-rtt parameter. This parameter takes as its arguments a mode value and, optionally, a maximum size for the DLRR report block. The mode value "all" indicates that both RTP data senders and data receivers MAY send DLRR blocks, while the mode value "sender" indicates that only active RTP senders MAY send DLRR blocks, i.e., non RTP senders SHALL NOT send DLRR blocks. If a maximum size in octets is included, any DLRR Report Blocks that are sent SHALL NOT exceed the specified size. If size limitations mean that a DLRR Report Block sender cannot report in one block upon all participants from which it has received a Receiver Reference Time Report Block, then it SHOULD report on participants in a round robin fashion across several report intervals. 🔁
The rtcp-xr attribute's parameter list MAY be empty. This is useful in cases in which an application needs to signal that it understands the SDP signaling but does not wish to avail itself of XR functionality. For example, an application in a SIP controlled session could signal that it wishes to stop using all XR blocks by removing all applicable SDP parameters in a re-INVITE message that it sends. If XR blocks are not to be used at all from the beginning of a session, it is RECOMMENDED that the "rtcp-xr" attribute not be supplied at all. 🫶
When the "rtcp-xr" attribute is present, participants SHOULD NOT send XR blocks other than the ones indicated by the parameters. This means that inclusion of a "rtcp-xr" attribute without any parameters tells a participant that it SHOULD NOT send any XR blocks at all. The purpose is to conserve bandwidth. This is especially important when collaborative parameters are applied to a large multicast group: the sending of an initiator block could potentially trigger responses from all participants. There are, however, contexts in which it makes sense to send an XR block in the absence of a parameter signaling its use. For instance, an application might be designed so as to send certain report blocks without negotiation, while using SDP signaling to negotiate the use of other blocks. 💜
5.2. Usage in Offer/Answer 💌
In the Offer/Answer context [8], how you read SDP signaling for XR packets depends on the direction attribute that's signaled: "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute is supplied, then "sendrecv" is assumed. This section only applies to unicast media streams, except where noted. We'll cover the unilateral parameters first, then the collaborative ones. 💅
For "sendonly" and "sendrecv" media stream offers that specify unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send the corresponding XR blocks. For "sendrecv" offers, the answerer MAY include the "rtcp-xr" attribute in its response and specify any unilateral parameters, to ask the offerer to send the matching XR blocks. The offerer SHOULD send these blocks. 🦋
For "recvonly" media stream offers, the offerer's use of the "rtcp-xr" attribute with unilateral parameters shows that the offerer can send the matching XR blocks. If the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD send XR blocks for each specified unilateral parameter that was in its offer. ✨
For multicast media streams, including an "rtcp-xr" attribute with unilateral parameters means that every media recipient SHOULD send the corresponding XR blocks. 🌈
An SDP offer with a collaborative parameter says the offerer can receive the matching initiator and reply with the right responses. For example, an offer that specifies the "rcvr-rtt" parameter means the offerer is ready to receive Receiver Reference Time Report Blocks and to send DLRR Report Blocks. ⭐ A collaborative parameter in an offer means the answerer MAY send the initiator, and once the offerer has received that initiator, the offerer SHOULD send the responses.
There are exceptions to the rule that an offerer of a collaborative parameter should send responses. The collaborative parameter might specify a mode that leaves the offerer out. Or congestion control or maximum transmission unit considerations might work against the offerer's response. 🙈
By including a collaborative parameter in its answer, the answerer shows it can receive initiators and send responses. The offerer MAY then send initiators, and the answerer SHOULD reply to them with responses. Just like with an offer of a collaborative parameter, there are exceptions to the rule that the answerer should reply. 🫶
When making an SDP offer of a collaborative parameter for a multicast media stream, the offerer SHOULD specify which participants are to respond to a received initiator. A participant that is not specified SHOULD NOT send responses, otherwise undue bandwidth might be consumed. The offer tells us that each specified participant SHOULD respond if it receives an initiator, and that a specified participant MAY send an initiator block too. 💜
An SDP answer for a multicast media stream SHOULD include all collaborative parameters that are present in the offer and that the answerer supports. It SHOULD NOT include any collaborative parameter that is absent from the offer. 🎀
If a participant gets an SDP offer and understands the "rtcp-xr" attribute but doesn't want to implement the offered XR functionality, its answer SHOULD include an "rtcp-xr" attribute without parameters. By doing that, the party declares that, at a minimum, it is capable of understanding the signaling. 🧚
5.3. Usage Outside of Offer/Answer 🌸
SDP can also be used outside of the Offer/Answer context, for instance for multimedia sessions announced through the Session Announcement Protocol (SAP) [15], or streamed through the Real Time Streaming Protocol (RTSP) [17]. The signaling model is simpler because the sender doesn't negotiate parameters, but the functionality expected from specifying the "rtcp-xr" attribute is the same as in Offer/Answer. 🍓
When a unilateral parameter is specified for the "rtcp-xr" attribute of a media stream, the receiver of that stream SHOULD send the corresponding XR block. When a collaborative parameter is specified, only the participants indicated by the mode value in that parameter are involved. Each such participant that receives an initiator block SHOULD send the corresponding response block. Each such participant MAY also send initiator blocks. 👑
6. IANA Considerations 🦋
This document defines a new RTCP packet type, the Extended Report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. It also defines a new IANA registry: the registry of RTCP XR Block Types. Inside this new registry, the document sets up an initial set of seven block types and describes how the remaining types are to be allocated. 📋
It also defines a new SDP attribute, "rtcp-xr", within the existing IANA registry of SDP Parameters. It creates another new registry, the registry of RTCP XR SDP Parameters, with an initial set of six parameters, and describes how additional parameters are to be allocated. 🎀
6.1. XR Packet Type 💖
The XR packet type defined by this document is registered with IANA as packet type 207 in the registry of RTP RTCP Control Packet types (PT). ✨
6.2. RTCP XR Block Type Registry 🌈
This document creates an IANA registry called the RTCP XR Block Type Registry to cover the name space of the Extended Report block type (BT) field specified in Section 3. The BT field has eight bits, which gives 256 values. The RTCP XR Block Type Registry is to be managed by IANA according to the Specification Required policy of RFC 2434 [7]. Future specifications SHOULD assign block type values in strict numeric order, following the values assigned in this document:
BT name
-- ----
1 Loss RLE Report Block
2 Duplicate RLE Report Block
3 Packet Receipt Times Report Block
4 Receiver Reference Time Report Block
5 DLRR Report Block
6 Statistics Summary Report Block
7 VoIP Metrics Report BlockThe BT value 255 is reserved for future extensions. 🔒
Future specifications SHOULD avoid the value 0 as well. Doing so makes packet validity checking easier, since an all-zeros field might commonly show up in an ill-formed packet. 🙈
Any registration MUST contain the following information:
- Contact information of the one doing the registration, including at least name, address, and email.
- The format of the block type being registered, consistent with the extended report block format described in Section 3.
- A description of what the block type represents and how it shall be interpreted, detailing this information for each of its fields.
6.3. The "rtcp-xr" SDP Attribute 🧚
The SDP attribute "rtcp-xr" defined by this document is registered with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"):
Attribute name: rtcp-xr
Long form: RTP Control Protocol Extended Report Parameters
Type of name: att-field
Type of attribute: session and media level
Subject to charset: no
Purpose: see Section 5 of this document
Reference: this document
Values: see this document and registrations belowThe attribute has an extensible parameter field, so a registry for these parameters is required. This document creates an IANA registry called the RTCP XR SDP Parameters Registry. It contains the six parameters defined in Section 5.1: "pkt-loss-rle", "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and "recv-rtt". 💜
Additional parameters are to be added to this registry in accordance with the Specification Required policy of RFC 2434 [7]. Any registration MUST contain the following information:
- Contact information of the one doing the registration, including at least name, address, and email.
- An Augmented Backus-Naur Form (ABNF) [2] definition of the parameter, in accordance with the "format-ext" definition of Section 5.1.
- A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer.
7. Security Considerations 🔐
This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports [9, Appendix B] also apply to XR reports. This section details the additional security considerations that apply to the extensions. 🕵️♀️
The extensions introduce heightened confidentiality concerns. 😭 Standard RTCP reports contain a limited number of summary statistics. The information in XR reports is both more detailed and more extensive, covering a larger number of parameters. The per-packet report blocks and the VoIP Metrics Report Block are examples of this.
The per-packet information in Loss RLE, Duplicate RLE, and Packet Receipt Times Report Blocks makes multicast inference of network characteristics (MINC) [11] easier. That kind of inference can reveal the gross topology of a multicast distribution tree, as well as parameters such as loss rates and delays along paths between branching points in that tree. Such information might be considered sensitive by autonomous system administrators. 🌐
The VoIP Metrics Report Block gives information about the quality of ongoing voice calls. Though that information might be carried in an application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. 👀
No new mechanisms in this document ensure confidentiality. Encryption procedures, such as those being suggested for a Secure RTCP (SRTCP) [12] at the time this document was written, can be used by end hosts when confidentiality is a concern. Since RTCP traffic can be encrypted by the end hosts, autonomous systems must be prepared for the fact that certain aspects of their network topology can be revealed. 🛡️
Any encryption or filtering of XR report blocks means losing monitoring information for third parties. For example, a network that sets up a tunnel to encrypt VoIP Report Blocks denies that information to the service providers the tunnel passes through. Those service providers can't then monitor or respond to the quality of the VoIP calls they carry, which could cause problems for the network's users. As a default, XR packets should not be encrypted or filtered. 🙅♀️
The extensions also make certain denial of service attacks easier. That's because the per-packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks make it possible to create RTCP packets much larger than average. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants send large RTCP packets, all participants see their RTCP reporting intervals lengthened, which means they can report less often. To limit the effects of large packets, even without denial of service attacks, applications SHOULD place an upper limit on the size of the XR report blocks they use. The "thinning" techniques described in Section 4.1 let the packet-by-packet report blocks stay within a predefined size limit. 🚨
A. Algorithms ✨
A.1. Sequence Number Interpretation ✨
Okay bestie, this is the algorithm Section 4.1 suggests for keeping track of sequence numbers from one sender 🧚. It's the accounting you need to make Loss RLE Report Blocks work, and it's honestly so clever. 💅
The trick is that it takes 16-bit sequence numbers and stretches them into a 32-bit space. The first packet from a source lands roughly in the middle of that space. Every packet after that gets slotted either just ahead of or just behind the previous one, whichever placement is closer. If it's a tie, it picks the option that doesn't need a rollover in the 16-bit number. Iconic, right? 🦋
// The reference sequence number is an extended sequence number
// that serves as the basis for determining whether a new 16 bit
// sequence number comes earlier or later in the 32 bit sequence
// space.
u_int32 _src_ref_seq;
bool _uninitialized_src_ref_seq;
// Place seq into a 32-bit sequence number space based upon a
// heuristic for its most likely location.
u_int32 extend_seq(const u_int16 seq) {
u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
if(_uninitialized_src_ref_seq) {
// This is the first sequence number received. Place
// it in the middle of the extended sequence number
// space.
_src_ref_seq = seq | 0x80000000u;
_uninitialized_src_ref_seq = false;
extended_seq = _src_ref_seq;
}
else {
// Prior sequence numbers have been received.
// Propose two candidates for the extended sequence
// number: seq_a is without wraparound, seq_b with
// wraparound.
seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
if(_src_ref_seq < seq_a) {
seq_b = seq_a - 0x00010000u;
diff_a = seq_a - _src_ref_seq;
diff_b = _src_ref_seq - seq_b;
}
else {
seq_b = seq_a + 0x00010000u;
diff_a = _src_ref_seq - seq_a;
diff_b = seq_b - _src_ref_seq;
}
// Choose the closer candidate. If they are equally
// close, the choice is somewhat arbitrary: we choose
// the candidate for which no rollover is necessary.
if(diff_a < diff_b) {
extended_seq = seq_a;
}
else {
extended_seq = seq_b;
}
// Set the reference sequence number to be this most
// recently-received sequence number.
_src_ref_seq = extended_seq;
}
// Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given.
return extended_seq;
}A.2. Example Burst Packet Loss Calculation
Here's an algorithm for measuring burst characteristics for the VoIP Metrics Report Block (Section 4.7) 🎀. It's been checked against a working implementation for correctness, and it's taken from ETSI TS 101 329-5 [3]. Important tea: this version wins over any future changes to the ETSI documents. 💅
It's event driven, which makes it super computationally efficient. ⚡
First, the four states:
state 1 = received a packet during a gap
state 2 = received a packet during a burst
state 3 = lost a packet during a burst
state 4 = lost an isolated packet during a gapThe "c" variables are state transition counts. So c14 is the move from state 1 to state 4. You can get one of each pair of transition counts to within 1, which is plenty accurate for this job 🌸.
"pkt" counts the packets received since the last loss or discard. "lost" counts the packets lost inside the current burst. "packet_lost" and "packet_discarded" are Boolean flags that tell you what triggered the call 🍓.
if(packet_lost) {
loss_count++;
}
if(packet_discarded) {
discard_count++;
}
if(!packet_lost && !packet_discarded) {
pkt++;
}
else {
if(pkt >= gmin) {
if(lost == 1) {
c14++;
}
else {
c13++;
}
lost = 1;
c11 += pkt;
}
else {
lost++;
if(pkt == 0) {
c33++;
}
else {
c23++;
c22 += (pkt - 1);
}
}
pkt = 0;
}At each reporting interval, you can work out the burst and gap metrics like this 🦋:
// Calculate additional transition counts.
c31 = c13;
c32 = c23;
ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
// Calculate burst and densities.
p32 = c32 / (c31 + c32 + c33);
if((c22 + c23) < 1) {
p23 = 1;
}
else {
p23 = 1 - c22/(c22 + c23);
}
burst_density = 256 * p23 / (p23 + p32);
gap_density = 256 * c14 / (c11 + c14);
// Calculate burst and gap durations in ms
m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap;
/* calculate loss and discard rates */
loss_rate = 256 * loss_count / ctotal;
discard_rate = 256 * discard_count / ctotal;Intellectual Property Notice
Quick legal vibe check 🙈. The IETF doesn't take a side on whether any intellectual property or other rights claimed around this technology are valid or in scope. It also doesn't say whether licenses for those rights exist or are easy to get, and it doesn't claim it has searched for any such rights. If you want the IETF's procedures for rights in standards-track and standards-related documents, look at BCP 11 [5]. Claims of rights that were filed for publication, promised licenses, or results of attempts to get a general license or permission for implementers or users can all be requested from the IETF Secretariat 💜.
The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard to let them know. Send that info to the IETF Executive Director 📬.
Acknowledgments
Huge shoutout to the people who helped make this happen 🫶. Thank you to Colin Perkins, Steve Casner, and Henning Schulzrinne for their thoughtful guidance 👑. Sue Moon gets a thank-you for helping the authors work together 🌈. Mounir Benzaid gets one too, for pointing out the reporting needs of MLDA ⭐. Dorgham Sisalem and Adam Wolisz pushed us to add MLDA block types, which was iconic of them 🔥. And Jose Rey gave really valuable review on the SDP Signaling section 💖.
Contributors
The authors of this document are:
- Kevin Almeroth, UCSB
- Ramon Caceres, IBM Research
- Alan Clark, Telchemy
- Robert G. Cole, JHU Applied Physics Laboratory
- Nick Duffield, AT&T Labs-Research
- Timur Friedman, Paris 6
- Kaynam Hedayat, Brix Networks
- Kamil Sarac, UT Dallas
- Magnus Westerlund, Ericsson
If you have questions about the individual report blocks, these are the people to ask 🧚:
sec. report block principal contributors
---- ------------ ----------------------
4.1 Loss RLE Report Block Friedman, Caceres, Duffield
4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield
4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield
4.4 Receiver Reference Time Report Block Friedman
4.5 DLRR Report Block Friedman
4.6 Statistics Summary Report Block Almeroth, Sarac
4.7 VoIP Metrics Report Block Clark, Cole, HedayatFor the SDP signaling in this document, the main contact is Magnus Westerlund 💅.
References
Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [3] ETSI, "Quality of Service (QoS) measurement methodologies", ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000.
- [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [5] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
- [6] ITU-T, "The E-Model, a computational model for use in transmission planning", Recommendation G.107, January 2003.
- [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
- [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
- [10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones, December 2000.
Informative References
- [11] Adams, A., Bu, T., Caceres, R., Duffield, N.G., Friedman, T., Horowitz, J., Lo Presti, F., Moon, S.B., Paxson, V. and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior", IEEE Communications Magazine, May 2000.
- [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The Secure Real-time Transport Protocol", Work in Progress.
- [13] Caceres, R., Duffield, N.G. and T. Friedman, "Impromptu measurement infrastructures using RTP", Proc. IEEE Infocom 2002.
- [14] Clark, A.D., "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality", Proc. IP Telephony Workshop 2001.
- [15] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
- [17] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
- [18] Sisalem D. and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000.
Okay bestie, last stop! 🎀 Here are the authors' contact details, so you know exactly who to slide into the DMs (professionally, of course 💅).
Authors' Addresses ✨
Kevin Almeroth 🌸
Kevin Almeroth
Department of Computer Science
University of California
Santa Barbara, CA 93106 USA
EMail: almeroth@cs.ucsb.eduRamon Caceres 🦋
Ramon Caceres
IBM Research
19 Skyline Drive
Hawthorne, NY 10532 USA
EMail: caceres@watson.ibm.comAlan Clark 💜
Alan Clark
Telchemy Incorporated
3360 Martins Farm Road, Suite 200
Suwanee, GA 30024 USA
Phone: +1 770 614 6944
Fax: +1 770 614 3951
EMail: alan@telchemy.comRobert G. Cole 🧚
Robert G. Cole
Johns Hopkins University Applied Physics Laboratory
MP2-S170
11100 Johns Hopkins Road
Laurel, MD 20723-6099 USA
Phone: +1 443 778 6951
EMail: robert.cole@jhuapl.eduNick Duffield 🍓
Nick Duffield
AT&T Labs-Research
180 Park Avenue, P.O. Box 971
Florham Park, NJ 07932-0971 USA
Phone: +1 973 360 8726
Fax: +1 973 360 8050
EMail: duffield@research.att.comTimur Friedman 🌈
Timur Friedman
Universite Pierre et Marie Curie (Paris 6)
Laboratoire LiP6-CNRS
8, rue du Capitaine Scott
75015 PARIS France
Phone: +33 1 44 27 71 06
Fax: +33 1 44 27 74 95
EMail: timur.friedman@lip6.frKaynam Hedayat ⭐
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824 USA
Phone: +1 978 367 5600
Fax: +1 978 367 5700
EMail: khedayat@brixnet.comKamil Sarac 🔥
Kamil Sarac
Department of Computer Science (ES 4.207)
Eric Jonsson School of Engineering & Computer Science
University of Texas at Dallas
Richardson, TX 75083-0688 USA
Phone: +1 972 883 2337
Fax: +1 972 883 2349
EMail: ksarac@utdallas.eduMagnus Westerlund 👑
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm Sweden
Phone: +46 8 404 82 87
Fax: +46 8 757 55 50
EMail: magnus.westerlund@ericsson.comFull Copyright Statement 🎀
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is 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: rfc3611 2003-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms