summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7005.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7005.txt')
-rw-r--r--doc/rfc/rfc7005.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc7005.txt b/doc/rfc/rfc7005.txt
new file mode 100644
index 0000000..953feb2
--- /dev/null
+++ b/doc/rfc/rfc7005.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Clark
+Request for Comments: 7005 Telchemy
+Category: Standards Track V. Singh
+ISSN: 2070-1721 Aalto University
+ Q. Wu
+ Huawei
+ September 2013
+
+
+ RTP Control Protocol (RTCP) Extended Report (XR) Block
+ for De-Jitter Buffer Metric Reporting
+
+Abstract
+
+ This document defines an RTP Control Protocol (RTCP) Extended Report
+ (XR) block that allows the reporting of de-jitter buffer metrics for
+ a range of RTP applications.
+
+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 has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7005.
+
+Copyright Notice
+
+ 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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Clark, et al. Standards Track [Page 1]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. De-Jitter Buffer Metrics Block . . . . . . . . . . . . . . 3
+ 1.2. RTCP and RTCP Extended Reports . . . . . . . . . . . . . . 3
+ 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3
+ 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Standards Language . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. De-Jitter Buffer Operation . . . . . . . . . . . . . . . . . . 4
+ 3.1. Idealized De-Jitter Buffer . . . . . . . . . . . . . . . . 4
+ 3.2. Fixed De-Jitter Buffer . . . . . . . . . . . . . . . . . . 5
+ 3.3. Adaptive De-Jitter Buffer . . . . . . . . . . . . . . . . 5
+ 4. De-Jitter Buffer Metrics Block . . . . . . . . . . . . . . . . 6
+ 4.1. Report Block Structure . . . . . . . . . . . . . . . . . . 6
+ 4.2. Definition of Fields in De-Jitter Buffer Metrics Block . . 6
+ 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 9
+ 5.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 9
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . . 9
+ 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 10
+ 6.3. Contact Information for Registrations . . . . . . . . . . 10
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
+ Appendix A. Metrics Represented Using the Template from
+ RFC 6390 . . . . . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 2]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+1. Introduction
+
+1.1. De-Jitter Buffer Metrics Block
+
+ This document defines a new block type to augment those defined in
+ [RFC3611] for use in a range of RTP applications.
+
+ The new block type provides information on de-jitter buffer
+ configuration and performance.
+
+ The metric belongs to the class of transport-related end-system
+ metrics defined in [RFC6792].
+
+ Instances of this metrics block refer by synchronization source
+ (SSRC) to the separate auxiliary Measurement Information Block
+ [RFC6776], which contains information such as the SSRC of the
+ measured stream, and RTP sequence numbers and time intervals
+ indicating the span of the report.
+
+1.2. RTCP and RTCP Extended Reports
+
+ The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
+ defines an extensible structure for reporting using an RTCP Extended
+ Report (XR). This document defines a new Extended Report block for
+ use with [RFC3550] and [RFC3611].
+
+1.3. Performance Metrics Framework
+
+ "Guidelines for Considering New Performance Metric Development"
+ [RFC6390] provides guidance on the definition and specification of
+ performance metrics. "Guidelines for Use of the RTP Monitoring
+ Framework" [RFC6792] provides guidance on the reporting block format
+ using RTCP XR. Metrics described in this document are in accordance
+ with the guidelines in [RFC6390]and [RFC6792].
+
+1.4. Applicability
+
+ Real-time applications employ a de-jitter buffer [RFC5481] to absorb
+ jitter introduced on the path from source to destination. These
+ metrics are used to report how the de-jitter buffer at the receiving
+ end of the RTP stream behaves as a result of jitter in the network;
+ they are applicable to a range of RTP applications.
+
+ These metrics correspond to terminal-related factors that affect
+ real-time application quality and are useful for providing a better
+ end-user quality of experience (QoE) when these terminal-related
+ factors are used as inputs to calculate QoE metrics [QMB].
+
+
+
+
+Clark, et al. Standards Track [Page 3]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+2. 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. De-Jitter Buffer Operation
+
+ A de-jitter buffer is required to absorb delay variation in the
+ network delivery of media packets. A de-jitter buffer works by
+ holding media data for a period of time after it is received and
+ before it is played out. Packets that arrive early are held in the
+ de-jitter buffer longer. If packets arrive too early, they may be
+ discarded if there is no available de-jitter buffer space. If
+ packets are delayed excessively by the network, they may be discarded
+ if they miss their playout time.
+
+ The de-jitter buffer can be considered a time window with the early
+ edge aligned with the delay corresponding to the earliest arriving
+ packet and the late edge representing the maximum permissible delay
+ before a late arriving packet would be discarded. The delay applied
+ to packets that arrive on time or at their expected arrival time is
+ known as the nominal delay, and this is equivalent to the time
+ difference/buffer size difference between the insertion point of the
+ on-time packets and the point at which the packets are read out.
+
+ The reference for the expected arrival time may be, for example, the
+ first packet in the session or the running average delay. If all
+ packets arrived at their expected arrival time, then every packet
+ would be held in the de-jitter buffer exactly the nominal delay.
+
+ The de-jitter buffer maximum delay is the delay that is applied to
+ the earliest arriving packet that is not discarded and corresponds to
+ the early edge of the de-jitter buffer time window.
+
+3.1. Idealized De-Jitter Buffer
+
+ In practice, de-jitter buffer implementations vary considerably;
+ however, they should behave in a manner conceptually consistent with
+ an idealized de-jitter buffer, which is described as follows:
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 4]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+ (i) Receive the first packet and delay playout by D ms. Keep the
+ RTP timestamp (TS) and receive time as a reference.
+
+ RTP TS[1]
+
+ receive time[1]
+
+ Assume that both are normalized in ticks (there are 10,000
+ ticks in a millisecond).
+
+ (ii) Receive the next packet.
+
+ (iii) Calculate r = RTP TS[n] - RTP TS[1] and t = receive time[n] -
+ receive time[1]. If r == t, then the packet arrived on time.
+ If r < t, then the packet arrived late, and if r > t, then the
+ packet arrived early.
+
+ (iv) Delay playout of packet by D + (r-t).
+
+ (v) Go back to (ii).
+
+ Note that this idealized implementation assumes that the sender's RTP
+ clock is synchronized to the clock in the receiver, which is used to
+ timestamp packet arrivals. If there is no such inherent
+ synchronization, the system may need to use an adaptive de-jitter
+ buffer or other techniques to ensure reliable reception.
+
+3.2. Fixed De-Jitter Buffer
+
+ A fixed de-jitter buffer lacks provision to track the condition of
+ the network and has a fixed size, and packets leaving the de-jitter
+ buffer have a constant delay. For fixed de-jitter buffer
+ implementation, the nominal delay is set to a constant value
+ corresponding to the packets that arrive at their expected arrival
+ time, while the maximum delay is set to a constant value
+ corresponding to the fixed size of the de-jitter buffer.
+
+3.3. Adaptive De-Jitter Buffer
+
+ An adaptive de-jitter buffer can adapt to the change in the network's
+ delay and has variable size or variable delay. It allows the nominal
+ delay to be set to a low value initially to minimize user perceived
+ delay; however, it can automatically extend the late edge (and
+ possibly also retract the early edge) of a buffer window if a
+ significant proportion of the packets are arriving late (and hence
+ being discarded).
+
+
+
+
+
+Clark, et al. Standards Track [Page 5]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+4. De-Jitter Buffer Metrics Block
+
+ This block describes the configuration and operating parameters of
+ the de-jitter buffer in the receiver of the RTP end system or RTP
+ mixer that sends the report. Instances of this metrics block use the
+ SSRC to refer 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 interval in the Measurement Information Block indicating
+ the span of the report and MUST be sent in the same compound RTCP
+ packet as the Measurement Information Block. If the measurement
+ interval is not received in the same compound RTCP packet as this
+ metrics block, this metrics block MUST be discarded.
+
+4.1. Report Block Structure
+
+ De-Jitter Buffer (DJB) Metrics Block
+
+ 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=23 | I |C| resv | Block Length=3 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSRC of Source |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DJB nominal | DJB maximum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DJB high-water mark | DJB low-water mark |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Report Block Structure
+
+4.2. Definition of Fields in De-Jitter Buffer Metrics Block
+
+ Block Type (BT): 8 bits
+
+ A De-Jitter Buffer Metrics Report Block is identified by the
+ constant 23.
+
+ Interval Metric flag (I): 2 bits
+
+ This field is used to indicate whether the de-jitter buffer
+ metrics are Sampled, Interval, or Cumulative metrics:
+
+ I=01: Sampled Value - the reported value is a sampled
+ instantaneous value.
+
+
+
+
+
+Clark, et al. Standards Track [Page 6]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+ I=10: Interval Duration - the reported value applies to the
+ most recent measurement interval duration between successive
+ metrics reports.
+
+ I=11: Cumulative Duration - the reported value applies to the
+ accumulation period characteristic of cumulative measurements.
+
+ In this document, de-jitter buffer metrics can only be sampled and
+ cannot be measured over definite intervals. Also, the value I=00
+ is reserved for future use. Senders MUST NOT use the values I=00,
+ I=10, or I=11. If a block is received with I=00, I=10, or I=11,
+ the receiver MUST discard the block.
+
+ Jitter Buffer Configuration (C): 1 bit
+
+ This field is used to identify the de-jitter buffer method in use
+ at the receiver, according to the following code:
+
+ 0 = Fixed de-jitter buffer
+
+ 1 = Adaptive de-jitter buffer
+
+ Reserved (resv): 5 bits
+
+ These bits are reserved. They MUST be set to zero by senders and
+ ignored by receivers (see [RFC6709], Section 4.2).
+
+ Block Length: 16 bits
+
+ The length of this report block in 32-bit words, minus one, in
+ accordance with the definition in [RFC3611]. This field MUST be
+ set to 3 to match the fixed length of the report block.
+
+ SSRC of Source: 32 bits
+
+ As defined in Section 4.1 of [RFC3611].
+
+ De-jitter buffer nominal delay (DJB nominal): 16 bits
+
+ This is the current nominal de-jitter buffer delay (in
+ milliseconds) that corresponds to the nominal de-jitter buffer
+ delay for packets that arrive exactly on time. It is calculated
+ based on the time spent in the de-jitter buffer for the packet
+ that arrives exactly on time. This parameter MUST be provided for
+ both fixed and adaptive de-jitter buffer implementations.
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 7]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+ The measured value is an unsigned value. If the measured value
+ exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an
+ over-range measurement. If the measurement is unavailable, the
+ value 0xFFFF MUST be reported.
+
+ De-jitter buffer maximum delay (DJB maximum): 16 bits
+
+ This is the current maximum de-jitter buffer delay (in
+ milliseconds) that corresponds to the earliest arriving packet
+ that would not be discarded. It is calculated based on the time
+ spent in the de-jitter buffer for the earliest arriving packet.
+ In simple queue implementations, this may correspond to the size
+ of the de-jitter buffer. In adaptive de-jitter buffer
+ implementations, this value may vary dynamically. This parameter
+ MUST be provided for both fixed and adaptive de-jitter buffer
+ implementations.
+
+ The measured value is an unsigned value. If the measured value
+ exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an
+ over-range measurement. If the measurement is unavailable, the
+ value 0xFFFF MUST be reported.
+
+ De-jitter buffer high-water mark (DJB high-water mark): 16 bits
+
+ This is the highest value of the de-jitter buffer nominal delay
+ (in milliseconds) that occurred at any time during the reporting
+ interval. This parameter MUST be provided for adaptive de-jitter
+ buffer implementations, and its value MUST be set to DJB maximum
+ for fixed de-jitter buffer implementations.
+
+ The measured value is an unsigned value. If the measured value
+ exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an
+ over-range measurement. If the measurement is unavailable, the
+ value 0xFFFF MUST be reported.
+
+ De-jitter buffer low-water mark (DJB low-water mark): 16 bits
+
+ This is the lowest value of the de-jitter buffer nominal delay (in
+ milliseconds) that occurred at any time during the reporting
+ interval. This parameter MUST be provided for adaptive de-jitter
+ buffer implementations, and its value MUST be set to DJB maximum
+ for fixed de-jitter buffer implementations.
+
+ The measured value is an unsigned value. If the measured value
+ exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an
+ over-range measurement. If the measurement is unavailable, the
+ value 0xFFFF MUST be reported.
+
+
+
+
+Clark, et al. Standards Track [Page 8]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+5. SDP Signaling
+
+ [RFC3611] defines the use of the Session Description Protocol (SDP)
+ [RFC4566] for signaling the use of XR blocks. However, XR blocks MAY
+ be used without prior signaling (see Section 5 of RFC 3611).
+
+5.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-djb-block
+
+ xr-djb-block = "de-jitter-buffer"
+
+5.2. Offer/Answer Usage
+
+ When SDP is used in Offer/Answer context [RFC3264], the SDP Offer/
+ Answer usage defined in [RFC3611] for unilateral "rtcp-xr" attribute
+ parameters applies. For detailed usage of Offer/Answer for
+ unilateral parameters, refer to Section 5.2 of [RFC3611].
+
+6. 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].
+
+6.1. New RTCP XR Block Type Value
+
+ This document assigns the block type value 23 in the IANA "RTP
+ Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
+ the "De-Jitter Buffer Metrics Block".
+
+6.2. New RTCP XR SDP Parameter
+
+ This document also registers a new parameter "de-jitter-buffer" in
+ the "RTP Control Protocol Extended Reports (RTCP XR) Session
+ Description Protocol (SDP) Parameters Registry".
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 9]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+6.3. Contact Information for Registrations
+
+ The contact information for registrations is:
+
+ Qin Wu (sunseawq@huawei.com)
+ 101 Software Avenue, Yuhua District
+ Nanjing, Jiangsu 210012
+ China
+
+7. Security Considerations
+
+ It is believed that this RTCP XR 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.
+
+8. Contributors
+
+ Geoff Hunt wrote the initial draft of this document.
+
+9. Acknowledgments
+
+ The authors gratefully acknowledge reviews and feedback provided by
+ Bruce Adams, Philip Arden, Amit Arora, Claire Bi, Bob Biskner, Benoit
+ Claise, Kevin Connor, Claus Dahm, Spencer Dawkins, Randy Ethier, Roni
+ Even, Jim Frauenthal, Kevin Gross, Albert Higashi, Tom Hock, Shane
+ Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy
+ Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Dan Romascanu,
+ Albrecht Schwarz, Tom Taylor, Hideaki Yamada, and Glen Zorn.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+ with Session Description Protocol (SDP)", RFC 3264,
+ June 2002.
+
+ [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.
+
+
+
+Clark, et al. Standards Track [Page 10]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [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.
+
+10.2. Informative References
+
+ [QMB] Clark, A., "RTP Control Protocol (RTCP) Extended Report
+ (XR) Blocks for QoE Metric Reporting", Work in Progress,
+ May 2013.
+
+ [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
+ Applicability Statement", RFC 5481, March 2009.
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 11]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+Appendix A. Metrics Represented Using the Template from RFC 6390
+
+ a. De-Jitter Buffer Nominal Delay Metric
+
+ * Metric Name: De-jitter buffer nominal delay in RTP
+
+ * Metric Description: The "expected arrival time" is the time
+ that an RTP packet would arrive if there was no delay
+ variation. The delay applied to packets that arrive at their
+ expected time is known as the Nominal Delay.
+
+ * Method of Measurement or Calculation: See Section 4.2,
+ de-jitter buffer nominal delay definition.
+
+ * Units of Measurement: See Section 4.2, de-jitter buffer
+ nominal delay definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 4.
+
+ * Measurement Timing: See Section 4 for measurement timing and
+ Section 4.2 for Interval Metric flag.
+
+ * Use and Applications: See Section 1.4.
+
+ * Reporting Model: See RFC 3611.
+
+ b. De-Jitter Buffer Maximum Delay Metric
+
+ * Metric Name: De-jitter buffer maximum delay in RTP.
+
+ * Metric Description: It is the current maximum de-jitter buffer
+ delay for RTP traffic that corresponds to the earliest
+ arriving packet that would not be discarded.
+
+ * Method of Measurement or Calculation: See Section 4.2,
+ de-jitter buffer maximum delay definition and Section 3, the
+ last paragraph.
+
+ * Units of Measurement: See Section 4.2, de-jitter buffer
+ maximum delay definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 4.
+
+ * Measurement Timing: See Section 4 for measurement timing and
+ Section 4.2 for Interval Metric flag.
+
+
+
+
+Clark, et al. Standards Track [Page 12]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+ * Use and Applications: See Section 1.4.
+
+ * Reporting Model: See RFC 3611.
+
+ c. De-Jitter Buffer High-Water Mark Metric
+
+ * Metric Name: De-jitter buffer high-water mark in RTP.
+
+ * Metric Description: It is the highest value of the de-jitter
+ buffer nominal delay for RTP traffic which occurred at any
+ time during the reporting interval.
+
+ * Method of Measurement or Calculation: See Section 4.2,
+ de-jitter buffer high-water mark definition.
+
+ * Units of Measurement: See Section 4.2, de-jitter buffer
+ nominal delay definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 4.
+
+ * Measurement Timing: See Section 4 for measurement timing and
+ Section 4.2 for Interval Metric flag.
+
+ * Use and Applications: See Section 1.4.
+
+ * Reporting Model: See RFC 3611.
+
+ d. De-Jitter Buffer Low-Water Mark Metric
+
+ * Metric Name: De-jitter buffer low-water mark in RTP.
+
+ * Metric Description: It is the lowest value of the de-jitter
+ buffer nominal delay (for RTP traffic) that occurred at any
+ time during the reporting interval.
+
+ * Method of Measurement or Calculation: See Section 4.2,
+ de-jitter buffer low-water mark definition.
+
+ * Units of Measurement: See Section 4.2, de-jitter buffer low
+ water mark definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 4, 1st paragraph.
+
+ * Measurement Timing: See Section 4 for measurement timing and
+ Section 4.2 for Interval Metric flag.
+
+
+
+
+Clark, et al. Standards Track [Page 13]
+
+RFC 7005 RTCP XR Jitter Buffer September 2013
+
+
+ * Use and Applications: See Section 1.4.
+
+ * Reporting Model: See RFC 3611.
+
+Authors' Addresses
+
+ Alan Clark
+ Telchemy Incorporated
+ 2905 Premiere Parkway, Suite 280
+ Duluth, GA 30097
+ USA
+
+ EMail: alan.d.clark@telchemy.com
+
+
+ Varun Singh
+ Aalto University
+ School of Electrical Engineering
+ Otakaari 5 A
+ Espoo, FIN 02150
+ Finland
+
+ EMail: varun@comnet.tkk.fi
+
+
+ Qin Wu
+ Huawei
+ 101 Software Avenue, Yuhua District
+ Nanjing, Jiangsu 210012
+ China
+
+ EMail: sunseawq@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 14]
+