RFC 6843

RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting

📅 published January 2013, from ietf

RFC 6843 ✨ Title Block

  • RFC number: 6843 🎀
  • Title: RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting
  • Authors: A. Clark (Telchemy), K. Gross (AVA Networks), Q. Wu (Huawei) 👯
  • Category: Standards Track
  • Stream: Internet Engineering Task Force (IETF)
  • ISSN: 2070-1721
  • Date: January 2013
  • Obsoletes / Updates: the title block doesn't list any RFCs this one obsoletes or updates 🧚

Abstract 🦋

okay so this doc defines an RTP Control Protocol (RTCP) Extended Report (XR) block that lets you report delay metrics for a bunch of Real-time Transport Protocol (RTP) apps. it's giving useful 💅

Status of This Memo 📜

This is an Internet Standards Track document. ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741. 💖

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6843. 🔗

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

This document 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 date this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. ⚖️

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Packet Delay Metrics Block .................................2
   1.2. RTCP and RTCP XR Reports ...................................2
   1.3. Performance Metrics Framework ..............................3
   1.4. Applicability ..............................................3
2. Terminology .....................................................3
   2.1. Standards Language .........................................3
3. Delay Block .....................................................3
   3.1. Report Block Structure .....................................4
   3.2. Definition of Fields in Delay Metrics Report Block .........4
4. SDP Signaling ...................................................6
   4.1. SDP rtcp-xr-attrib Attribute Extension .....................7
   4.2. Offer/Answer Usage .........................................7
5. IANA Considerations .............................................7
   5.1. New RTCP XR Block Type Value ...............................7
   5.2. New RTCP XR SDP Parameter ..................................7
   5.3. Contact Information for Registrations ......................7
6. Security Considerations .........................................8
7. Contributors ....................................................8
8. Acknowledgments .................................................8
9. References ......................................................8
   9.1. Normative References .......................................8
   9.2. Informative References .....................................9

1. Introduction ✨

1.1. Packet Delay Metrics Block 🕰️

okay so this document defines a brand new block type that goes alongside the ones from [RFC3611], and it's made for a whole bunch of RTP apps. The new block supports reporting the mean, minimum, and maximum values of the network round-trip delay between RTP interfaces on peer RTP end systems. You could measure that with the RTCP method from [RFC3550], for example. It also reports the part of the round-trip delay that happens inside the local RTP system. 💅

The network metrics belong to the class of transport metrics defined in [RFC6792]. 🧚

1.2. RTCP and RTCP XR Reports 📮

RTCP reporting is defined in [RFC3550]. [RFC3611] came along and gave us an extensible structure for reporting with an RTCP Extended Report (XR). This document adds a new Extended Report block for use with [RFC3550] and [RFC3611]. 🎀

1.3. Performance Metrics Framework 📏

The Performance Metrics Framework [RFC6390] gives guidance on defining and specifying performance metrics. The RTP Monitoring Architectures [RFC6792] gives guidelines for the report block format when you're using RTCP XR. The metrics block in this document follows the guidelines in [RFC6390] and [RFC6792], so it's all consistent and iykyk 🤓

1.4. Applicability 🌍

These metrics work for a range of RTP apps where this report block would be useful, like multimedia conferencing and streaming audio and video. Knowing the round-trip delay and the delay characteristics can help other receivers size their receive buffers and pick a playout delay. Network managers find the same info super valuable when they're troubleshooting network and user experience issues. 🔥

2. Terminology 📖

2.1. Standards Language 🗣️

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 RFC 2119 [RFC2119]. 💜

3. Delay Block 🌈

Metrics in this block report on packet delay in the stream arriving at the RTP system. The measurement of these metrics happens either at the receiving end of the RTP stream or at the sending end of it. Instances of this metrics block refer, by synchronization source (SSRC), to the separate auxiliary Measurement Information block [RFC6776], which holds the measurement periods (see [RFC6776], Section 4.2). This metrics block relies on the measurement period in the Measurement Information block to show the span of the report, so it SHOULD be sent in the same compound RTCP packet as the Measurement Information block. If the measurement period doesn't arrive in the same compound RTCP packet as this metrics block, this metrics block MUST be discarded. 🙈

3.1. Report Block Structure 🧩

Here's the delay metrics block:

     0               1               2               3
     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    BT=16      | I |   resv.   |      block length = 6         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           SSRC of Source                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Mean Network Round-Trip Delay                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Min Network Round-Trip Delay                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Max Network Round-Trip Delay                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               End System Delay - Seconds (bit 0-31)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              End System Delay - Fraction (bit 0-31)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Report Block Structure 📊

3.2. Definition of Fields in Delay Metrics Report Block 🎀

Okay bestie, this is where the actual bits live 🤓💖 Every field gets its own little moment.

Block type (BT): 8 bits

A Delay Report Block is identified by the constant 16. 🦋

Interval Metric flag (I): 2 bit

This field tells you whether the delay metrics are Sampled, Interval, or Cumulative. Three possible vibes:

  • I=10: Interval Duration. The value applies to the most recent measurement interval duration 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. 📸

Reserved (resv): 6 bits

These bits are reserved. They MUST be set to zero by senders and ignored by receivers (see [RFC6709], Section 4.2). Don't touch them, babe 🙅‍♀️💅

block length: 16 bits

The length of this report block in 32-bit words, minus one. For the delay block, the block length is equal to 6. 🧮

SSRC of source: 32 bits

As defined in Section 4.1 of [RFC3611]. 🔗

Mean Network Round-Trip Delay: 32 bits

Okay, this one is the mean value of the RTP-to-RTP interface round-trip delay over the measurement period, expressed in units of 1/65536 seconds. ✨ It's typically figured out using "the NTP timestamp field" in the RTCP sender report (SR), plus "the last SR (LSR) field" and "delay since last SR (DLSR) field" in the RTCP receiver report (RR). Check out [RFC3550], Section 6.4.1 and Figure 2 for the full picture. It can also be determined using "the NTP timestamp field" in the RTCP Receiver Reference Time Report Block, plus "last RR (LRR) field" and "delay since last RR (DLRR) field" in the DLRR Report Block (see [RFC3611], Section 4.5). 📊

If only one measurement of Round-Trip Delay is available for the time span of the report (i.e., the measurement period), whether Interval or Cumulative, this single value SHOULD be reported as the mean value. 🫶

If the measurement is unavailable, the value of this field with all bits set to 1 MUST be reported. 🚨

Min Network Round-Trip Delay: 32 bits

This is the minimum value of the RTP-to-RTP interface round-trip delay over the measurement period, expressed in units of 1/65536 seconds. 🌸 Typically it's determined using the NTP timestamp field in the RTCP SR, plus the LSR field and DLSR field in the RTCP RR. It can also be determined using the NTP timestamp field in the RTCP Receiver Reference Time Report Block, plus the LRR field and DLRR field in the DLRR Report Block.

If only one measurement of Round Trip Delay is available for the time span of the report (i.e., the measurement period), whether Interval or Cumulative, this single value SHOULD be reported as the minimum value. 🌱

If the measurement is unavailable, the value of this field with all bits set to 1 MUST be reported. 🚨

Max Network Round-Trip Delay: 32 bits

The max one! This is the maximum value of the RTP-to-RTP interface round-trip delay over the measurement period, expressed in units of 1/65536 seconds. 🔥 It's typically determined using the NTP timestamp field in the RTCP SR, plus the LSR field and DLSR field in the RTCP RR. It can also be determined using the NTP timestamp field in the RTCP Receiver Reference Time Report Block, plus the LRR field and DLRR field in the DLRR Report Block.

If only one measurement of Round-Trip Delay is available for the time span of the report (i.e., the measurement period), whether Interval or Cumulative, this single value SHOULD be reported as the maximum value. 👑

If the measurement is unavailable, the value of this field with all bits set to 1 MUST be reported. 🚨

End System Delay: 64 bits

The End System Delay is the internal round-trip delay within the reporting endpoint. It's calculated using the nominal value of the jitter buffer delay plus the accumulation/encoding and decoding/playout delay associated with the codec being used. 🧚 The value is represented using a 64-bit NTP-format timestamp as defined in [RFC5905], which is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. 🤯

If the measurement is unavailable, the value of this field with all bits set to 1 MUST be reported. 🚨

4. SDP Signaling ✨

[RFC3611] defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used without prior signaling. So you can just vibe without announcing it 💅

4.1. SDP rtcp-xr-attrib Attribute Extension

This section augments the SDP [RFC4566] attribute "rtcp-xr" defined in [RFC3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document. 🎀

xr-format =/ xr-delay-block

xr-delay-block ="delay"

4.2. Offer/Answer Usage

When SDP is used in an offer/answer context, the SDP Offer/Answer usage defined in [RFC3611] applies. 🫧

5. IANA Considerations 🗂️

New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, refer to [RFC3611]. 📋

5.1. New RTCP XR Block Type Value

This document assigns the block type value 16 in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "Delay Metrics Block". 🦋

5.2. New RTCP XR SDP Parameter

This document also registers a new parameter "delay" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters" registry. 🌈

5.3. Contact Information for Registrations

The contact information for the registrations is:

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

6. Security Considerations 🔐

It is believed that this proposed RTCP XR report block introduces no new security considerations beyond those described in [RFC3611]. This block does not provide per-packet statistics, so the risk to confidentiality documented in Section 7, paragraph 3, of [RFC3611] does not apply. 🔐

7. Contributors 🫶

Geoff Hunt wrote the initial version of this document. 💜

8. Acknowledgments 🙏

The authors gratefully acknowledge the comments and contributions made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada, Jing Zhao, Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn, Shida Schubert, Barry Leiba, Sean Turner, Robert Sparks, Benoit Claise, and Stephen Farrell. Everyone who helped, you are all iconic 👑✨

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.

[RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
           Time Protocol Version 4: Protocol and Algorithms
           Specification", RFC 5905, June 2010.

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

9.2. Informative References

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

[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.

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

Authors' Addresses 💌

Alan Clark
Telchemy Incorporated
2905 Premiere Parkway, Suite 280
Duluth, GA  30097
USA

EMail: alan.d.clark@telchemy.com


Kevin Gross
AVA Networks

EMail: kevin.gross@avanw.com


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

EMail: sunseawq@huawei.com
📦 where this page comes from