Telchemy Incorporated

2905 Premiere Parkway, Suite 280 Duluth GA 30097 USA alan.d.clark@telchemy.com

AVA Networks

kevin.gross@avanw.com

Huawei

101 Software Avenue, Yuhua District Nanjing Jiangsu 210012 China sunseawq@huawei.com

Real-time Applications and Infrastructure Area Audio/Video Transport Working Group Real Time Control Protocol 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.

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

The use of RTCP for reporting is defined in . defined an extensible structure for reporting using an RTCP Extended Report (XR). This document defines a new Extended Report block for use with and .

The Performance Metrics Framework provides guidance on the definition and specification of performance metrics. The RTP Monitoring Architectures provides guidelines for reporting block format using RTCP XR. The metrics block described in this document is in accordance with the guidelines in and .

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.

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.

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 , which contains measurement periods (see , 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.

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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A Delay Report Block is identified by the constant 16. 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. These bits are reserved. They MUST be set to zero by senders and ignored by receivers (see , Section 4.2). The length of this report block in 32-bit words, minus one. For the delay block, the block length is equal to 6. As defined in Section 4.1 of . 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 , 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 , 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. 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. 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. 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. 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 , 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.

defines the use of SDP (Session Description Protocol) for signaling the use of XR blocks. XR blocks MAY be used without prior signaling.

This section augments the SDP attribute "rtcp-xr" defined in 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"

When SDP is used in offer/answer context, the SDP Offer/Answer usage defined in applies.

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

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

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

The contact information for the registrations is: Qin Wu (sunseawq@huawei.com) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China

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

Geoff Hunt wrote the initial version of this document.

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.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK] The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK] This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice. This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]