RFC 7004

RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting

📅 published September 2013, from ietf

RFC 7004: RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting 🎀

Part 1 of 4, so more is coming bestie 💖

Who wrote it: G. Zorn (Network Zen), R. Schott (Deutsche Telekom), Q. Wu, Ed. and R. Huang (Huawei). Source is the Internet Engineering Task Force (IETF), and the ISSN is 2070-1721.

Category: Standards Track. This is an official Internet standard, not just an idea someone floated 🦋

Date: September 2013

Obsoletes / Updates: The title block doesn't list anything it obsoletes or updates, so there's nothing to report there ✨

Abstract ✨

okay so this doc defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks. Their whole job is letting you report loss, duplication, and discard summary statistics across a bunch of different RTP apps 📊 It's giving organized data for your call quality 💅

Status of This Memo 🌸

This is an Internet Standards Track document, so it's officially real 👑

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

For the latest status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7004 🧚

Copyright Notice 🦋

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

Table of Contents 📚

   1. Introduction ....................................................2
      1.1. Summary Statistics Metrics .................................2
      1.2. RTCP and RTCP Extended Reports .............................3
      1.3. Performance Metrics Framework ..............................3
      1.4. Applicability ..............................................3
   2. Terminology .....................................................3
   3. Transport-Related End-System Metrics ............................4
      3.1. Burst/Gap Loss Summary Statistics Block ....................4
           3.1.1. Report Block Structure ..............................5
           3.1.2. Definition of Fields in Loss Summary
                  Statistics Block ....................................5
      3.2. Burst/Gap Discard Summary Statistics Block .................7
           3.2.1. Report Block Structure ..............................8
           3.2.2. Definition of Fields in Burst/Gap Discard
                  Summary Statistics Block ............................8
   4. Application-Level Metrics ......................................10
      4.1. Frame Impairment Statistics Summary Block .................10
           4.1.1. Report Block Structure .............................11
           4.1.2. Definition of Fields in Frame Impairment
                  Statistics Summary Block ...........................11
   5. SDP Signaling ..................................................13
      5.1. SDP rtcp-xr Attribute Extension ...........................13
      5.2. Offer/Answer Usage ........................................13
   6. IANA Considerations ............................................13
      6.1. New RTCP XR Block Type Values .............................13
      6.2. New RTCP XR SDP Parameters ................................14
      6.3. Contact Information for Registrations .....................14
   7. Security Considerations ........................................14
   8. Acknowledgements ...............................................14
   9. References .....................................................14
      9.1. Normative References ......................................14
      9.2. Informative References ....................................15
   Appendix A.  Metrics Represented Using the Template from RFC 6390 .16

1. Introduction ✨

1.1. Summary Statistics Metrics 📊

okay so this doc adds three new block types on top of the ones already in [RFC3611], all for use across a range of RTP apps:

Burst/Gap Loss Summary Statistics Block
Burst/Gap Discard Summary Statistics Block
Frame Impairment Statistics Summary Block

The first two blocks report burst/gap loss and burst/gap discard summary stats, including the packet loss/discard proportion, mean, and variance. They're part of the transport-related end-system metrics class defined in [RFC6792]. These two blocks are meant to be used together with info from the Burst/Gap Loss Metrics Block [RFC6958] or the Burst/Gap Discard Metrics Block [RFC7003], so they depend on those. The metrics in those blocks match the definitions of "burst", "gap", "loss", and "discard" in RTCP XR [RFC3611], which is very consistent of them 💜

The third block is the video one 🎬 It reports detailed stats for each frame type, including how many frames of each type were received, lost, and discarded within the Group of Pictures (GOP). It also includes extra data so you can work out stats like the proportion of each frame type that got hit by packet loss and discard. These metrics count as application-level metrics under [RFC6792].

1.2. RTCP and RTCP Extended Reports 🌈

RTCP reporting is defined in [RFC3550]. [RFC3611] then gave us an extensible structure for reporting, the RTCP Extended Report (XR). This document defines a new Extended Report block that works with both [RFC3550] and [RFC3611] 🧚

1.3. Performance Metrics Framework 🍓

The RTP Monitoring Framework [RFC6792] gives guidelines for reporting block format using RTCP XR. The metrics in this document follow those guidelines, so they're on brand ✨

1.4. Applicability 🌸

These metrics work for a wide range of RTP applications, and they capture transient IP problems that hurt user experience. They can give an accurate read on users' quality of experience, and they can help senders change strategy to deal with the problem 💅

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way RFC 2119 [RFC2119] describes. These are the big capitalized requirement words, so pay attention to them 👀

There's also one more term defined here:

Frame Type

okay so a video frame often gets compressed with different algorithms, and the frame type is how you tell those algorithms apart 🎞️ Two frame types show up in the different video algorithms: the Key frame and Derived frames. A Key frame is coded independently, with no prediction from other pictures, and it serves as a reference frame for predicting other pictures. Derived frames are predictively coded and derived from a Key frame using a prediction algorithm. If there's no video image compression at all, then every frame is a Key frame 🔑

3.1. Burst/Gap Loss Summary Statistics Block 💖

This block extends the packet loss and discard metrics defined in Section 4.7.1 of [RFC3611]. The metrics here are meant to be used the way this section describes, together with info from the Measurement Information Block [RFC6776]. That Measurement Information Block MUST be present in the same RTCP packet as the Burst/Gap Loss Metrics Block [RFC6958]. You also use it alongside the metric "cumulative number of packets lost" from standard RTCP [RFC3550] 🧠

Instances of this metrics block use the synchronization source (SSRC) to point to the separate auxiliary Measurement Information Block [RFC6776], which describes the measurement periods in use (see [RFC6776], Section 4.2). This metrics block relies on the measurement period in the Measurement Information Block to tell it the span of the report. It SHOULD be sent in the same compound RTCP packet as the Measurement Information Block. If the measurement period isn't received in that same compound RTCP packet, then this metrics block MUST be discarded 🙅‍♀️ no exceptions bestie

The metrics in this block cover the stuff relevant to the statistical parameters: Burst Loss Rate, Gap Loss Rate, Burst Duration Mean, and Burst Duration Variance. They're measured at the receiving end of the RTP stream, using the burst/gap loss metrics from [RFC6958] plus other info sent along with this report block 🦋

3.1.1. Report Block Structure 🎀

Here's how the Burst/Gap Loss Summary Statistics Block is laid out:

    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=17    | I | Reserved  |        Block Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SSRC of Source                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Burst Loss Rate        |         Gap Loss Rate         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Burst Duration Mean     |    Burst Duration Variance    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That's the whole first chunk of the spec! 🌈✨ Everything above keeps the exact requirement levels and numbers from the original, so it's ready to build on.

3.1.2. Definition of Fields in Loss Summary Statistics Block ✨

okay bestie, let's go field by field 🎀

Block Type (BT): 8 bits

a Burst/Gap Loss Summary Statistics Block is identified by the constant 17 🦋

Interval Metric flag (I): 2 bits

this one tells you whether the burst/gap loss summary statistics are Sampled, Interval, or Cumulative metrics 💅

I=10: Interval Duration - the value applies to the most recent measurement interval between successive metrics reports 🌸
I=11: Cumulative Duration - the value applies to the accumulation period that cumulative measurements have 💜
I=01: Sampled Value - the value is a sampled instantaneous value ✨

in this document, I=00 is the reserved value and it MUST NOT be used 🙅

Reserved: 6 bits

this field is reserved for future definition. until someone defines it, the bits here MUST be set to zero and ignored by the receiver (see [RFC6709], Section 4.2) 🧚

Block Length: 16 bits

the constant 3, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611] 🎀

SSRC of Source: 32 bits

as defined in Section 4.1 of RFC 3611 [RFC3611] 💖

Burst Loss Rate: 16 bits

this is the fraction of packets lost during bursts since the beginning of reception 😭 It's a fixed point number with the binary point immediately after the left-most bit. To get it, you divide Packets Lost in Bursts by Total Packets Expected in Bursts, multiply that by 32768 (0x8000), and keep only the integer part. The max is 0x8000. As a formula:

integer-part( (Packets Lost in Bursts / Total Packets Expected in Bursts) * 0x8000 )

if the measurement is unavailable, 0xFFFF MUST be reported 🥺

Gap Loss Rate: 16 bits

this one is the fraction of packets lost during gaps since the beginning of reception 🌈 It's also a fixed point number with the binary point immediately after the left-most bit. You take the difference between the number of packets lost and Packets Lost in Bursts, divide that by the difference between Packets Expected and Total Packets Expected in Bursts, multiply by 32768 (0x8000), and keep only the integer part. The max is 0x8000. As a formula:

integer-part ( (number of packets lost - Packets Lost in Bursts)/
(Packets Expected - Total Packets Expected in Bursts) * 0x8000 )

where "number of packets lost" comes from standard RTCP [RFC3550], and Packets Expected is the difference between "extended last sequence number" and "extended first sequence number" (Interval or Cumulative) provided in the Measurement Identity and Information Block [RFC6776] 🔥

if the measurement is unavailable, 0xFFFF MUST be reported 💀

⚠️ if you're calculating this on an Interval basis, you have to take a difference between the current and preceding values of "cumulative number of packets lost" in RTCP. That gives you the "number of packets lost" for the reporting interval. don't skip this, it's giving main character energy 👑

Burst Duration Mean: 16 bits

the mean burst duration is just a quotient 🍓

mean = Sum of Burst Durations / Number of Bursts

where "Sum of Burst Durations" and "Number of Bursts" come from the RTCP XR Burst/Gap Loss Metrics Block [RFC6958] 🦋

if the measurement is unavailable, 0xFFFF MUST be reported ✨

Burst Duration Variance: 16 bits

the variance of the burst duration uses the standard result 💅

var = ( Sum of Squares of Burst Durations - Number of Bursts *
mean^2 ) / (Number of Bursts - 1)

where "Sum of Squares of Burst Durations" and "Number of Bursts" come from the RTCP XR Burst/Gap Loss Metrics Block [RFC6958] 🫶

if the measurement is unavailable, 0xFFFF MUST be reported 🌸

3.2. Burst/Gap Discard Summary Statistics Block 🍓

this block extends the packet loss and discard metrics from Section 4.7.1 of [RFC3611] 🧚 The metrics here are meant to be used as described in this section, together with information from the Measurement Identity Block [RFC6776]. That Measurement Identity Block MUST be present in the same RTCP packet as the Burst/Gap Discard Summary Statistics Block.

these metrics give you info for stats stuff like Burst Discard Rate and Gap Discard Rate 📊 They're measured at the receiving end of the RTP stream, using burst/gap discard metrics defined in [RFC7003], plus other info that gets sent along with this report block 💜

this metrics block uses the synchronization source (SSRC) to point at the separate auxiliary Measurement Information block [RFC6776] that describes the measurement periods in use (see [RFC6776], Section 4.2) 🎀 It relies on the measurement period in the Measurement Information Block to show the span of the report, and it SHOULD be sent in the same compound RTCP packet as that measurement information block. If the measurement period isn't received in the same compound RTCP packet as this metrics block, this metrics block MUST be discarded 🙈

3.2.1. Report Block Structure 🦋

the structure of the Burst/Gap Discard Summary Statistics Block looks like this 👇

    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=18    | I |  Reserved |        Block Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          SSRC of Source                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Burst Discard Rate   |        Gap Discard Rate       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.2. Definition of Fields in Burst/Gap Discard Summary Statistics Block 💖

Block Type (BT): 8 bits

a Burst/Gap Discard Summary Statistics Block is identified by the constant 18 🎀

Interval Metric flag (I): 2 bits

this tells you whether the burst/gap discard summary statistics metrics are Sampled, Interval, or Cumulative 💅

I=10: Interval Duration - the value applies to the most recent measurement interval between successive metrics reports 🌸
I=11: Cumulative Duration - the value applies to the accumulation period that cumulative measurements have 💜
I=01: Sampled Value - the value is a sampled instantaneous value ✨

in this document, I=00 is the reserved value and it MUST NOT be used 🙅

Reserved: 6 bits

this field is reserved for future definition. until someone defines it, the bits here MUST be set to zero and ignored by the receiver (see [RFC6709], Section 4.2) 🧚

Block Length: 16 bits

the constant 2, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611] 🎀

SSRC of Source: 32 bits

as defined in Section 4.1 of RFC3611 [RFC3611] 💖

Burst Discard Rate: 16 bits

this is the fraction of packets discarded during bursts since the beginning of reception, as a fixed point number with the binary point immediately after the left-most bit 😤 You divide Packets Discarded in Bursts by Total Packets Expected in Bursts, multiply by 32768 (0x8000), and keep only the integer part, following this formula:

integer-part( (Packets Discarded in Bursts / Total Packets Expected in Bursts) * 0x8000 )

if the measurement is unavailable, 0xFFFF MUST be reported 🥺

Gap Discard Rate: 16 bits

this is the fraction of packets discarded during gaps since the beginning of reception, as a fixed point number with the binary point immediately after the left-most bit 🌈 You take the difference between the number of packets discarded and Packets Discarded in Bursts, divide that by the difference between Packets Expected and Total Packets Expected in Bursts, multiply by 32768 (0x8000), and keep only the integer part. The max is 0x8000. As a formula:

integer-part( (number of packets discarded - Packets Discarded in
Bursts) /(Packets Expected - Total Packets Expected in Bursts) *
0x8000 )

where "number of packets discarded" comes from the RTCP XR Discard Count Block [RFC7002], filled with the sum of packets discarded due to early arrival (DT=1) and packets discarded due to late arrival (DT=2). Packets Expected is the difference between "extended last sequence number" and "extended first sequence number" (Interval or Cumulative) provided in the Measurement Information Block [RFC6776] 🔥

for the Burst/Gap Discard Summary Statistics Block to be meaningful, 2 instances of the Discard Count Block with DT=1 and DT=2 MUST be included in the same RTCP XR packet as the Burst/Gap Discard Summary Statistics Block 👑

if the measurement is unavailable, 0xFFFF MUST be reported 💀

4. Application-Level Metrics ✨

4.1. Frame Impairment Statistics Summary Block 🎬

this block extends the statistics summary report mechanism from Section 4.6 of [RFC3611] 🦋 It reports which frame types were affected, on top of what the Statistics Summary Report Block RTCP packet from Section 4.6 of [RFC3611] already carries. The info is measured at the receiving end of the RTP stream and records how many frames were received, how many were lost, how many were duplicated, and how many partial frames were lost 📹 This is super useful for network management and video quality monitoring 💜

4.1.1. Report Block Structure 🧚

the structure of the Frame Impairment Statistics Summary Block looks like this 👇

    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=19    |T|   Reserved  |        Block Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of Source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      discarded_frames                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          dup_frames                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      full_lost_frames                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      partial_lost_frames                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.2. Definition of Fields in Frame Impairment Statistics Summary Block

Block Type (BT): 8 bits 💖

The BT is 8 bits and it's always the constant 19. That's how a Frame Impairment Statistics Summary Block announces itself ✨

Frame type indicator (T): 1 bit 🎀

This bit tells you what kind of frame the counts are about. It's 0 if full_lost_frames, partial_lost_frames, dup_frames, and discarded_frames hold Key frame (reference frame) counts, or 1 if they hold Derived frame counts. ngl this one is lowkey crucial. If you're sending both the Key frame and Derivation frame report, they should be sent in the same RTCP compound packet, using two Frame Impairment Statistics Summary Blocks. 🦋

Reserved: 7 bits 🧚

This field is saved for future definition. Until someone defines it, the bits in this field MUST be set to zero and ignored by the receiver (see [RFC6709], Section 4.2). Don't touch these bits, bestie 🙅‍♀️

Block Length: 16 bits 🍓

It's the constant 6, in accordance with how Section 3 of RFC 3611 [RFC3611] defines this field.

SSRC of Source: 32 bits 🌸

This is defined the same way as in Section 4.1 of RFC 3611 [RFC3611]. No need to reinvent the wheel here 💅

begin_seq: 16 bits 🌈

Also defined in Section 4.1 of RFC 3611 [RFC3611]. Same energy, different field.

end_seq: 16 bits 🌈

Again, Section 4.1 of RFC 3611 [RFC3611] has the full story. This is the other end of the sequence number interval.

Number of discarded frames (discarded_frames): 32 bits 🗑️

This is the number of frames discarded in the sequence number interval above.

Number of duplicate frames (dup_frames): 32 bits 👯‍♀️

This is the number of duplicate frames received in the sequence number interval above.

Number of full lost frames (full_lost_frames): 32 bits 💀

Okay, so a frame is either split across multiple packets or carried in just one packet. If the whole frame is lost, or every packet of the frame is lost, that frame counts as one full_lost_frames. You can infer this from the packet(s) that make up the frame. The value is the number of full lost frames in the sequence number interval above. Literally a main character moment for the packets that never showed up 😭

Number of partial lost frames (partial_lost_frames): 32 bits 🫶

When a frame is split across multiple packets and only some of those packets are lost, that frame counts as one partial_lost_frames. You can infer this from the packets that make up the frame. The value is the number of partial lost frames in the sequence number interval above. Iconic for the frames that were almost there 🥹

5. SDP Signaling

RFC 3611 defines how to use SDP (Session Description Protocol) [RFC4566] to signal the use of XR blocks. However, XR blocks MAY be used without prior signaling (see Section 5 of [RFC3611]). So you've got options, bestie ✨

5.1. SDP rtcp-xr Attribute Extension

This section extends the SDP [RFC4566] attribute "rtcp-xr", which is defined in Section 5.1 of [RFC3611]. It adds three new xr-format values so you can signal the report blocks from this document. Here's the ABNF [RFC5234] syntax, periodt 🎀

   xr-format =/ xr-bglss-block
              / xr-bgdss-block
              / xr-fiss-block
   xr-bglss-block = "burst-gap-loss-stat"
   xr-bgdss-block = "burst-gap-discard-stat"
   xr-fiss-block  = "frame-impairment-stat"

5.2. Offer/Answer Usage

When SDP is used in an offer/answer context, the SDP Offer/Answer usage from [RFC3611] for unilateral "rtcp-xr" attribute parameters applies. For the detailed Offer/Answer rules for unilateral parameters, check out Section 5.2 of [RFC3611] 📝

6. IANA Considerations

New block types for RTCP XR need IANA registration. For general IANA guidelines on RTCP XR, go check out RFC 3611 🌸

6.1. New RTCP XR Block Type Values

This document assigns three new block type values in the "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" 🦋

         Name:       BGLSS
         Long Name:  Burst/Gap Loss Summary Statistics Block
         Value       17
         Reference:  Section 3.1

         Name:       BGDSS
         Long Name:  Burst/Gap Discard Summary Statistics Block
         Value       18
         Reference:  Section 3.2
         Name:       FISS
         Long Name:  Frame Impairment Statistics Summary Block
         Value       19
         Reference:  Section 4.1

6.2. New RTCP XR SDP Parameters

This document also registers three new SDP [RFC4566] parameters for the "rtcp-xr" attribute. They go in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry" 🎀

"burst-gap-loss-stat"
"burst-gap-discard-stat"
"frame-impairment-stat"

6.3. Contact Information for Registrations

The contact info for these registrations is:

Qin Wu (sunseawq@huawei.com)
101 Software Avenue, Yuhua District
Nanjing, Jiangsu  210012
China

7. Security Considerations

Okay, this part is serious, bestie 😭 The new RTCP XR blocks in this document do not introduce any new security considerations beyond those described in [RFC3611]. So the security story is the same as RFC 3611's, no plot twists here 🔒

8. Acknowledgements

The authors would like to thank Bill Ver Steeg, David R. Oran, Ali Begen, Colin Perkins, Roni Even, Youqing Yang, Wenxiao Yu, Yinliang Hu, Jing Zhao, Ray van Brandenburg, Claire Bi, Dan Romascanu, Alfred Morton, Jr., Klaas Wierenga, Barry Leiba, Robert Sparks, Ralph Droms, and Benoit Claise for their valuable comments and suggestions on this document 🫶💜

9. References

9.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611, November
              2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC6776]  Clark, A. and Q. Wu, "Measurement Identity and Information
              Reporting Using a Source Description (SDES) Item and an
              RTCP Extended Report (XR) Block", RFC 6776, October 2012.

   [RFC6958]  Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control
              Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
              Loss Metric Reporting", RFC 6958, May 2013.

   [RFC7002]  Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol
              (RTCP) Extended Report (XR) Block for Discard Count Metric
              Reporting", RFC 7002, September 2013.

   [RFC7003]  Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control
              Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
              Discard Metric Reporting", RFC 7003, September 2013.

9.2. Informative References

   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
              Performance Metric Development", BCP 170, RFC 6390,
              October 2011.

   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
              Considerations for Protocol Extensions", RFC 6709,
              September 2012.

   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
              RTP Monitoring Framework", RFC 6792, November 2012.

Appendix A. Metrics Represented Using the Template from RFC 6390 ✨

Okay, this is the metrics catalogue, and it's giving very organized 📋💖 Each metric gets the same template so you can compare them easily. Ten metrics, lettered a through j.

a. Burst Loss Rate Metric 🌧️

Metric Name: RTP Burst Loss Rate
Metric Description: The fraction of packets lost during bursts since the beginning of reception for RTP traffic.
Method of Measurement or Calculation: See Section 3.1.2, Burst Loss Rate definition.
Units of Measurement: See Section 3.1.2, Burst Loss Rate definition.
Measurement Point(s) with Potential Measurement Domain: See Section 3.1, 2nd paragraph.
Measurement Timing: See Section 3.1, 1st paragraph for measurement timing and Section 3.1.2 for Interval Metric flag.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

b. Gap Loss Rate Metric 🕳️

Metric Name: RTP Gap Loss Rate
Metric Description: The fraction of packets lost during gaps since the beginning of reception for RTP traffic.
Method of Measurement or Calculation: See Section 3.1.2, Gap Loss Rate definition.
Units of Measurement: See Section 3.1.2, Gap Loss Rate definition.
Measurement Point(s) with Potential Measurement Domain: See Section 3.1, 2nd paragraph.
Measurement Timing: See Section 3.1, 1st paragraph for measurement timing and Section 3.1.2 for Interval Metric flag.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

c. Burst Duration Mean Metric ⏱️

Metric Name: RTP Burst Duration Mean
Metric Description: The mean duration of the burst periods that have occurred since the beginning of reception for RTP traffic.
Method of Measurement or Calculation: See Section 3.1.2, Burst Loss Rate definition.
Units of Measurement: This metric is expressed in milliseconds.
Measurement Point(s) with Potential Measurement Domain: See Section 3.1, 2nd paragraph.
Measurement Timing: See Section 3.1, 1st paragraph for measurement timing and Section 3.1.2 for Interval Metric flag.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

d. Burst Duration Variance Metric 📈

Metric Name: RTP Burst Duration Variance
Metric Description: The variance duration of the burst periods that have occurred since the beginning of reception for RTP traffic.
Method of Measurement or Calculation: See Section 3.1.2, Burst Duration Variance definition.
Units of Measurement: See Section 3.1.2, Burst Duration Variance definition.
Measurement Point(s) with Potential Measurement Domain: See Section 3.1, 2nd paragraph.
Measurement Timing: See Section 3.1, 1st paragraph for measurement timing and Section 3.1.2 for Interval Metric flag.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

e. Burst Discard Rate Metric 🗑️

Metric Name: RTP Burst Discard Rate
Metric Description: The fraction of packets discarded during bursts since the beginning of reception for RTP traffic.
Method of Measurement or Calculation: See Section 3.2.2, Burst Discard Rate definition.
Units of Measurement: See Section 3.2.2, Burst Discard Rate definition.
Measurement Point(s) with Potential Measurement Domain: See Section 3.2, 2nd paragraph.
Measurement Timing: See Section 3.2, 3rd paragraph for measurement timing and Section 3.1.2 for Interval Metric flag.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

f. Gap Discard Rate Metric 🫧

Metric Name: RTP Gap Discard Rate
Metric Description: The fraction of packets discarded during gaps since the beginning of reception for RTP traffic.
Method of Measurement or Calculation: See Section 3.2.2, Gap Discard Rate definition.
Units of Measurement: See Section 3.2.2, Gap Discard Rate definition.
Measurement Point(s) with Potential Measurement Domain: See Section 3.2, 2nd paragraph.
Measurement Timing: See Section 3.2, 3rd paragraph for measurement timing and Section 3.1.2 for Interval Metric flag.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

g. Number of Discarded Frames Metric 🎞️

Metric Name: Number of discarded frames in RTP
Metric Description: Number of frames discarded in a certain sequence number interval for RTP traffic.
Method of Measurement or Calculation: See Section 4.1.2, Number of discarded frames definition. This metric is directly measured and can be inferred from packet(s) that comprise the frame.
Units of Measurement: This metric is expressed as a 32-bit unsigned integer value.
Measurement Point(s) with Potential Measurement Domain: See Section 4.1, 1st paragraph.
Measurement Timing: See Section 4.1, Number of discarded frames definition. This metric relies on the sequence number interval and RTCP RR packet of [RFC3550] to determine measurement timing.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

h. Number of Duplicate Frames Metric 👯

Metric Name: Number of duplicate frames in RTP
Metric Description: Number of frames duplicated in a certain sequence number interval for RTP traffic.
Method of Measurement or Calculation: See Section 4.1.2, Number of duplicate frames definition. This metric is directly measured and can be inferred from packet(s) that comprise the frame.
Units of Measurement: This metric is expressed as a 32-bit unsigned integer value.
Measurement Point(s) with Potential Measurement Domain: See Section 4.1, 1st paragraph.
Measurement Timing: See Section 4.1, Number of duplicate frames definition. This metric relies on the sequence number interval to determine measurement timing.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

i. Number of Full Lost Frames Metric 💔

Metric Name: Number of full lost frames in RTP
Metric Description: A frame is either split across multiple RTP packets or carried in only one RTP packet. If the whole frame or all the packets of the frame is lost, this frame is regarded as one full_lost_frame.
Method of Measurement or Calculation: See Section 4.1.2, Number of full lost frames definition.
Units of Measurement: This metric is expressed as a 32-bit unsigned integer value.
Measurement Point(s) with Potential Measurement Domain: See Section 4.1, 1st paragraph.
Measurement Timing: See Section 4.1, Number of full lost frames definition. This metric relies on the sequence number interval to determine measurement timing.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

j. Number of Partial Lost Frames Metric 🩹

Metric Name: Number of partial lost frames in RTP
Metric Description: When a frame is split across multiple RTP packets and some RTP packets of the frame are lost, this frame is regarded as one partial_lost_frame.
Method of Measurement or Calculation: See Section 4.1.2, Number of partial lost frames definition.
Units of Measurement: This metric is expressed as a 32-bit unsigned integer value.
Measurement Point(s) with Potential Measurement Domain: See Section 4.1, 1st paragraph.
Measurement Timing: See Section 4.1, Number of partial lost frames definition. This metric relies on the sequence number interval to determine measurement timing.
Use and Applications: See Section 1.4.
Reporting Model: See RFC 3611.

Authors' Addresses 🎀

Meet the squad who wrote this! 🫶

Glen Zorn
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok  10260
Thailand

Phone: +66 (0) 909-201060
EMail: glenzorn@gmail.com


Roland Schott
Deutsche Telekom
Deutsche-Telekom-Allee 7
Darmstadt  64295
Germany

EMail: Roland.Schott@telekom.de


Qin Wu (editor)
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu  210012
China

EMail: sunseawq@huawei.com


Rachel Huang
Huawei
101 Software Avenue, Yuhua District
Nanjing  210012
China

EMail: Rachel@huawei.com

📦 where this page comes from

ietf: rfc7004 2013-09
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms