summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6843.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6843.txt')
-rw-r--r--doc/rfc/rfc6843.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc6843.txt b/doc/rfc/rfc6843.txt
new file mode 100644
index 0000000..637542e
--- /dev/null
+++ b/doc/rfc/rfc6843.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Clark
+Request for Comments: 6843 Telchemy
+Category: Standards Track K. Gross
+ISSN: 2070-1721 AVA Networks
+ Q. Wu
+ Huawei
+ January 2013
+
+
+ RTP Control Protocol (RTCP) Extended Report (XR)
+ Block for Delay Metric Reporting
+
+Abstract
+
+ This document defines an RTP Control Protocol (RTCP) Extended Report
+ (XR) block that allows the reporting of delay metrics for use in a
+ range of Real-time Transport Protocol (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/rfc6843.
+
+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 6843 RTCP XR Delay January 2013
+
+
+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
+
+ 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
+ supports the reporting of the mean, minimum, and maximum values of
+ the network round-trip delay between RTP interfaces in peer RTP end
+ systems as measured, for example, using the RTCP method described in
+ [RFC3550]. It also supports reporting of the component of the round-
+ trip delay internal to the local RTP system.
+
+ The network metrics belong to the class of transport metrics defined
+ in [RFC6792].
+
+1.2. RTCP and RTCP XR Reports
+
+ The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
+ defined 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].
+
+
+
+
+Clark, et al. Standards Track [Page 2]
+
+RFC 6843 RTCP XR Delay January 2013
+
+
+1.3. Performance Metrics Framework
+
+ The Performance Metrics Framework [RFC6390] provides guidance on the
+ definition and specification of performance metrics. The RTP
+ Monitoring Architectures [RFC6792] provides guidelines for reporting
+ block format using RTCP XR. The metrics block described in this
+ document is in accordance with the guidelines in [RFC6390] and
+ [RFC6792].
+
+1.4. Applicability
+
+ These metrics are applicable to a range of RTP applications in which
+ this report block would be useful, such as multimedia conferencing
+ and streaming audio and video. Knowledge of the round-trip delay and
+ delay characteristics can aid other receivers in sizing their receive
+ buffers and selecting a playout delay. The same information is also
+ valuable to network managers in 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 is made either
+ at the receiving end of the RTP stream or at the sending end of the
+ RTP stream. Instances of this metrics block refer by synchronization
+ source (SSRC) to the separate auxiliary Measurement Information block
+ [RFC6776], which contains measurement periods (see [RFC6776], Section
+ 4.2). This metrics block relies on the measurement period in the
+ Measurement Information block indicating the span of the report and
+ SHOULD be sent in the same compound RTCP packet as the Measurement
+ Information block. If the measurement period is not received in the
+ same compound RTCP packet as this metrics block, this metrics block
+ MUST be discarded.
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 3]
+
+RFC 6843 RTCP XR Delay January 2013
+
+
+3.1. Report Block Structure
+
+ 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
+
+ Block type (BT): 8 bits
+
+ A Delay Report Block is identified by the constant 16.
+
+ Interval Metric flag (I): 2 bit
+
+ This field is used to indicate whether the delay metrics are
+ Sampled, Interval or Cumulative metrics:
+
+ 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.
+
+ I=01: Sampled Value - the reported value is a sampled
+ instantaneous value.
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 4]
+
+RFC 6843 RTCP XR Delay January 2013
+
+
+ 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).
+
+ 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
+
+ The Mean Network Round-Trip Delay is the mean value of the RTP-to-
+ RTP interface round-trip delay over the measurement period,
+ expressed in units of 1/65536 seconds. This value is typically
+ determined using "the NTP timestamp field" in the RTCP sender
+ report (SR) and "the last SR (LSR) field","delay since last SR
+ (DLSR) field" in the RTCP receiver report (RR) (see [RFC3550],
+ Section 6.4.1 and Figure 2). It also can be determined using "the
+ NTP timestamp field" in the RTCP Receiver Reference Time Report
+ Block and "last RR (LRR) field", "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
+
+ The Min Network Round Trip Delay is the minimum value of the RTP-
+ to-RTP interface round-trip delay over the measurement period,
+ expressed in units of 1/65536 seconds. This value is typically
+ determined using the NTP timestamp field in the RTCP SR and LSR
+ field and DLSR field in the RTCP RR. It also can be determined
+ using the NTP timestamp field in the RTCP Receiver Reference Time
+ Report Block and LRR field and DLRR field in the DLRR Report
+ Block.
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 5]
+
+RFC 6843 RTCP XR Delay January 2013
+
+
+ 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 Network Round-Trip Delay is the maximum value of the RTP-
+ to-RTP interface round-trip delay over the measurement period,
+ expressed in units of 1/65536 seconds. This value is typically
+ determined using the NTP timestamp field in the RTCP SR and LSR
+ field and DLSR field in the RTCP RR. It also can be determined
+ using the NTP timestamp field in the RTCP Receiver Reference Time
+ Report Block and 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, 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 of
+ this field 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.
+
+
+
+
+
+Clark, et al. Standards Track [Page 6]
+
+RFC 6843 RTCP XR Delay January 2013
+
+
+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 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
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 7]
+
+RFC 6843 RTCP XR Delay January 2013
+
+
+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.
+
+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.
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 8]
+
+RFC 6843 RTCP XR Delay January 2013
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 9]
+