doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc8451.txt b/doc/rfc/rfc8451.txt
new file mode 100644
index 0000000..04241f3
--- /dev/null
+++ b/doc/rfc/rfc8451.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          V. Singh
+Request for Comments: 8451                                  callstats.io
+Category: Informational                                         R. Huang
+ISSN: 2070-1721                                                  R. Even
+                                                                  Huawei
+                                                            D. Romascanu
+                                                              Individual
+                                                                 L. Deng
+                                                            China Mobile
+                                                          September 2018
+
+
+        Considerations for Selecting RTP Control Protocol (RTCP)
+       Extended Report (XR) Metrics for the WebRTC Statistics API
+
+Abstract
+
+   This document describes monitoring features related to media streams
+   in Web real-time communication (WebRTC).  It provides a list of RTP
+   Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and
+   Extended Report (XR) metrics, which may need to be supported by RTP
+   implementations in some diverse environments.  It lists a set of
+   identifiers for the WebRTC's statistics API.  These identifiers are a
+   set of RTCP SR, RR, and XR metrics related to the transport of
+   multimedia flows.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8451.
+
+
+
+
+
+
+
+
+
+
+Singh, et al.                 Informational                     [Page 1]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 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
+   (https://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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et al.                 Informational                     [Page 2]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terminology .....................................................4
+   3. RTP Statistics in WebRTC Implementations ........................5
+   4. Considerations for Impact of Measurement Interval ...............5
+   5. Candidate Metrics ...............................................6
+      5.1. Network Impact Metrics .....................................6
+           5.1.1. Loss and Discard Packet Count Metric ................6
+           5.1.2. Burst/Gap Pattern Metrics for Loss and Discard ......7
+           5.1.3. Run-Length Encoded Metrics for Loss and Discard .....8
+      5.2. Application Impact Metrics .................................8
+           5.2.1. Discarded Octets Metric .............................8
+           5.2.2. Frame Impairment Summary Metrics ....................9
+           5.2.3. Jitter Buffer Metrics ...............................9
+      5.3. Recovery Metrics ..........................................10
+           5.3.1. Post-Repair Packet Count Metrics ...................10
+           5.3.2. Run-Length Encoded Metric for Post-Repair ..........10
+   6. Identifiers from Sender, Receiver, and Extended Report Blocks ..11
+      6.1. Cumulative Number of Packets and Octets Sent ..............11
+      6.2. Cumulative Number of Packets and Octets Received ..........11
+      6.3. Cumulative Number of Packets Lost .........................11
+      6.4. Interval Packet Loss and Jitter ...........................12
+      6.5. Cumulative Number of Packets and Octets Discarded .........12
+      6.6. Cumulative Number of Packets Repaired .....................12
+      6.7. Burst Packet Loss and Burst Discards ......................12
+      6.8. Burst/Gap Rates ...........................................13
+      6.9. Frame Impairment Metrics ..................................13
+   7. Adding New Metrics to WebRTC Statistics API ....................13
+   8. Security Considerations ........................................14
+   9. IANA Considerations ............................................14
+   10. References ....................................................14
+      10.1. Normative References .....................................14
+      10.2. Informative References ...................................16
+   Acknowledgements ..................................................17
+   Authors' Addresses ................................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et al.                 Informational                     [Page 3]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+1.  Introduction
+
+   Web real-time communication (WebRTC) [WebRTC-Overview] deployments
+   are emerging, and applications need to be able to estimate the
+   service quality.  If sufficient information (metrics or statistics)
+   is provided to the application, it can attempt to improve the media
+   quality.  [RFC7478] specifies a requirement for statistics:
+
+   F38   The browser must be able to collect statistics, related to the
+         transport of audio and video between peers, needed to estimate
+         quality of experience.
+
+   The WebRTC Stats API [W3C.webrtc-stats] currently lists metrics
+   reported in the RTCP Sender Report and Receiver Report (SR/RR)
+   [RFC3550] to fulfill this requirement.  However, the basic metrics
+   from RTCP SR/RR are not sufficient for precise quality monitoring or
+   diagnosing potential issues.
+
+   Standards such as "RTP Control Protocol Extended Reports (RTCP XR)"
+   [RFC3611] as well as other extensions standardized in the XRBLOCK
+   Working Group, e.g., burst/gap loss metric reporting [RFC6958] and
+   burst/gap discard metric reporting [RFC7003], have been produced for
+   the purpose of collecting and reporting performance metrics from RTP
+   endpoint devices that can be used to have end-to-end service
+   visibility and to measure the delivery quality in various RTP
+   services.  These metrics are able to complement those in [RFC3550].
+
+   In this document, we provide rationale for choosing additional RTP
+   metrics for the WebRTC getStats() API [W3C.webrtc].  All identifiers
+   proposed in this document are recommended to be implemented by an
+   WebRTC endpoint.  An endpoint may choose not to expose an identifier
+   if it does not implement the corresponding RTCP Report.  This
+   document only considers RTP-layer metrics.  Other metrics, e.g.,
+   IP-layer metrics, are out of scope.
+
+2.  Terminology
+
+   In addition to the terminology from [RFC3550], [RFC3611], and
+   [RFC7478], this document uses the following term.
+
+   ReportGroup: It is a set of metrics identified by a common
+      synchronization source (SSRC).
+
+
+
+
+
+
+
+
+
+Singh, et al.                 Informational                     [Page 4]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+3.  RTP Statistics in WebRTC Implementations
+
+   The RTCP Sender Reports (SRs) and Receiver Reports (RRs) [RFC3550]
+   expose the basic metrics for the local and remote media streams.
+   However, these metrics provide only partial or limited information,
+   which may not be sufficient for diagnosing problems or monitoring
+   quality.  For example, it may be useful to distinguish between
+   packets lost and packets discarded due to late arrival.  Even though
+   they have the same impact on the multimedia quality, it helps in
+   identifying and diagnosing problems.  RTP Control Protocol Extended
+   Reports (XRs) [RFC3611] and other extensions discussed in the XRBLOCK
+   Working Group provide more detailed statistics, which complement the
+   basic metrics reported in the RTCP SR and RRs.
+
+   The WebRTC application extracts statistics from the browser by
+   querying the getStats() API [W3C.webrtc].  The browser can easily
+   report the local variables, i.e., the statistics related to the
+   outgoing and incoming RTP media streams.  However, without the
+   support of RTCP XRs or some other signaling mechanism, the WebRTC
+   application cannot expose the remote endpoints' statistics.
+   [WebRTC-RTP-USAGE] does not mandate the use of any RTCP XRs, and
+   their usage is optional.  If the use of RTCP XRs is successfully
+   negotiated between endpoints (via SDP), thereafter the application
+   has access to both local and remote statistics.  Alternatively, once
+   the WebRTC application gets the local information, it can report the
+   information to an application server or a third-party monitoring
+   system, which provides quality estimates or diagnostic services for
+   application developers.  The exchange of statistics between endpoints
+   or between a monitoring server and an endpoint is outside the scope
+   of this document.
+
+4.  Considerations for Impact of Measurement Interval
+
+   RTCP extensions like RTCP XR usually share the same timing interval
+   with the RTCP SR/RR, i.e., they are sent as compound packets,
+   together with the RTCP SR/RR.  Alternatively, if the RTCP XR uses a
+   different measurement interval, all XRs using the same measurement
+   interval are compounded together, and the measurement interval is
+   indicated in a specific measurement information block defined in
+   [RFC6776].
+
+   When using WebRTC getStats() APIs (see "Statistics Model" in
+   [W3C.webrtc]), the applications can query this information at
+   arbitrary intervals.  For the statistics reported by the remote
+   endpoint, e.g., those conveyed in an RTCP SR/RR/XR, these will not
+   change until the next RTCP report is received.  However, statistics
+   generated by the local endpoint have no such restrictions as long as
+   the endpoint is sending and receiving media.  For example, an
+
+
+
+Singh, et al.                 Informational                     [Page 5]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+   application may choose to poll the stack for statistics every 1
+   second.  In that case, the underlying stack local will return the
+   current snapshot of the local statistics (for incoming and outgoing
+   media streams).  However, it may return the same remote statistics as
+   previously, because no new RTCP reports may have been received in the
+   past 1 second.  This can occur when the polling interval is shorter
+   than the average RTCP reporting interval.
+
+5.  Candidate Metrics
+
+   Since the following metrics are all defined in RTCP XR, which is not
+   mandated in WebRTC, all of them are local.  However, if RTCP XR is
+   supported by negotiation between two browsers, the following metrics
+   can also be generated remotely and be sent to the local endpoint
+   (that generated the media) via RTCP XR packets.
+
+   The metrics are classified into 3 categories as follows: network
+   impact metrics, application impact metrics, and recovery metrics.
+   Network impact metrics are the statistics recording the information
+   only for network transmission.  They are useful for network problem
+   diagnosis.  Application impact metrics mainly collect the information
+   from the viewpoint of the application, e.g., bit rate, frame rate, or
+   jitter buffers.  Recovery metrics reflect how well the repair
+   mechanisms perform, e.g., loss concealment, retransmission, or
+   Forward Error Correction (FEC).  All 3 types of metrics are useful
+   for quality estimations of services in WebRTC implementations.
+   WebRTC applications can use these metrics to calculate the estimated
+   Mean Opinion Score (MOS) [ITU-T_P.800.1] values or Media Delivery
+   Index (MDI) [RFC4445] for their services.
+
+5.1.  Network Impact Metrics
+
+5.1.1.  Loss and Discard Packet Count Metric
+
+   In multimedia transport, packets that are received abnormally are
+   classified into 3 types: lost, discarded, and duplicate packets.
+   Packet loss may be caused by network device breakdown, bit-error
+   corruption, or network congestion (packets dropped by an intermediate
+   router queue).  Duplicate packets may be a result of network delays
+   that cause the sender to retransmit the original packets.  Discarded
+   packets are packets that have been delayed long enough (perhaps they
+   missed the playout time) and are considered useless by the receiver.
+   Lost and discarded packets cause problems for multimedia services, as
+   missing data and long delays can cause degradation in service
+   quality, e.g., missing large blocks of contiguous packets (lost or
+   discarded) may cause choppy audio, and long network transmission
+   delay time may cause audio or video buffering.  The RTCP SR/RR
+   defines a metric for counting the total number of RTP data packets
+
+
+
+Singh, et al.                 Informational                     [Page 6]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+   that have been lost since the beginning of reception.  However, this
+   statistic does not distinguish lost packets from discarded and
+   duplicate packets.  Packets that arrive late will be discarded and
+   are not reported as lost, and duplicate packets will be regarded as a
+   normally received packet.  Hence, the loss metric can be misleading
+   if many duplicate packets are received or packets are discarded,
+   which causes the quality of the media transport to appear okay from a
+   statistical point of view, while the users are actually experiencing
+   bad service quality.  So, in such cases, it is better to use more
+   accurate metrics in addition to those defined in RTCP SR/RR.
+
+   The metrics for lost packets and duplicated packets defined in the
+   Statistics Summary Report Block of [RFC3611] extend the information
+   of loss carried in standard RTCP SR/RR.  They explicitly give an
+   account of lost and duplicated packets.  Lost packet counts are
+   useful for network problem diagnosis.  It is better to use the packet
+   loss metrics of [RFC3611] to indicate the lost packet count instead
+   of the cumulative number of packets lost metric of [RFC3550].
+   Duplicated packets are usually rare and have little effect on QoS
+   evaluation.  So it may not be suitable for use in WebRTC.
+
+   Using loss metrics without considering discard metrics may result in
+   inaccurate quality evaluation, as packet discard due to jitter is
+   often more prevalent than packet loss in modern IP networks.  The
+   discarded metric specified in [RFC7002] counts the number of packets
+   discarded due to jitter.  It augments the loss statistics metrics
+   specified in standard RTCP SR/RR.  For those WebRTC services with
+   jitter buffers requiring precise quality evaluation and accurate
+   troubleshooting, this metric is useful as a complement to the metrics
+   of RTCP SR/RR.
+
+5.1.2.  Burst/Gap Pattern Metrics for Loss and Discard
+
+   RTCP SR/RR defines coarse metrics regarding loss statistics: the
+   metrics are all about per-call statistics and are not detailed enough
+   to capture the transitory nature of some impairments like bursty
+   packet loss.  Even if the average packet loss rate is low, the lost
+   packets may occur during short dense periods, resulting in short
+   periods of degraded quality.  Bursts cause lower quality experience
+   than the non-bursts for low packet loss rates, whereas for high
+   packet loss rates, the converse is true.  So capturing burst gap
+   information is very helpful for quality evaluation and locating
+   impairments.  If the WebRTC application needs to evaluate the service
+   quality, burst gap metrics provide more accurate information than
+   RTCP SR/RR.
+
+
+
+
+
+
+Singh, et al.                 Informational                     [Page 7]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+   [RFC3611] introduces burst gap metrics in the VoIP Report Block.
+   These metrics record the density and duration of burst and gap
+   periods, which are helpful in isolating network problems since bursts
+   correspond to periods of time during which the packet loss/discard
+   rate is high enough to produce noticeable degradation in audio or
+   video quality.  Metrics related to the burst gap are also introduced
+   in [RFC7003] and [RFC6958], which define two new report blocks for
+   use in a range of RTP applications beyond those described in
+   [RFC3611].  These metrics distinguish discarded packets from loss
+   packets that occur in the burst period and provide more information
+   for diagnosing network problems.  Additionally, the block reports the
+   frequency of burst events, which is useful information for evaluating
+   the quality of experience.  Hence, if WebRTC applications need to do
+   quality evaluation and observe when and why quality degrades, these
+   metrics should be considered.
+
+5.1.3.  Run-Length Encoded Metrics for Loss and Discard
+
+   Run-length encoding uses a bit vector to encode information about the
+   packet.  Each bit in the vector represents a packet; depending on the
+   signaled metric, it defines if the packet was lost, duplicated,
+   discarded, or repaired.  An endpoint typically uses the run-length
+   encoding to accurately communicate the status of each packet in the
+   interval to the other endpoint.  [RFC3611] and [RFC7097] define run-
+   length encoding for lost and duplicate packets, and discarded
+   packets, respectively.
+
+   The WebRTC application could benefit from the additional information.
+   If losses occur after discards, an endpoint may be able to correlate
+   the two run length vectors to identify congestion-related losses,
+   e.g., a router queue became overloaded causing delays and then
+   overflowed.  If the losses are independent, it may indicate bit-error
+   corruption.  For the WebRTC Stats API [W3C.webrtc-stats], these types
+   of metrics are not recommended for use due to the large amount of
+   data and the computation involved.
+
+5.2.  Application Impact Metrics
+
+5.2.1.  Discarded Octets Metric
+
+   The metric reports the cumulative size of the packets discarded in
+   the interval.  It is complementary to the number of discarded
+   packets.  An application measures sent octets and received octets to
+   calculate the sending rate and receiving rate, respectively.  The
+   application can calculate the actual bit rate in a particular
+   interval by subtracting the discarded octets from the received
+   octets.
+
+
+
+
+Singh, et al.                 Informational                     [Page 8]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+   For WebRTC, the discarded octets metric supplements the metrics on
+   sent and received octets and provides an accurate method for
+   calculating the actual bit rate, which is an important parameter to
+   reflect the quality of the media.  The Bytes Discarded metric is
+   defined in [RFC7243].
+
+5.2.2.  Frame Impairment Summary Metrics
+
+   RTP has different framing mechanisms for different payload types.
+   For audio streams, a single RTP packet may contain one or multiple
+   audio frames.  On the other hand, in video streams, a single video
+   frame may be transmitted in multiple RTP packets.  The size of each
+   packet is limited by the Maximum Transmission Unit (MTU) of the
+   underlying network.  However, the statistics from standard SR/RR only
+   collect information from the transport layer, so they may not fully
+   reflect the quality observed by the application.  Video is typically
+   encoded using two frame types, i.e., key frames and derived frames.
+   Key frames are normally just spatially compressed, i.e., without
+   prediction from other pictures.  The derived frames are temporally
+   compressed, i.e., depend on the key frame for decoding.  Hence, key
+   frames are much larger in size than derived frames.  The loss of
+   these key frames results in a substantial reduction in video quality.
+   Thus, it is reasonable to consider this application-layer information
+   in WebRTC implementations, which influence sender strategies to
+   mitigate the problem or require the accurate assessment of users'
+   quality of experience.
+
+   The metrics in this category include: number of discarded key frames,
+   number of lost key frames, number of discarded derived frames, and
+   number of lost derived frames.  These metrics can be used to
+   calculate the Media Loss Rate (MLR) of the MDI [RFC4445].  Details of
+   the definition of these metrics are described in [RFC7003].
+   Additionally, the metric provides the rendered frame rate, an
+   important parameter for quality estimation.
+
+5.2.3.  Jitter Buffer Metrics
+
+   The size of the jitter buffer affects the end-to-end delay on the
+   network and also the packet discard rate.  When the buffer size is
+   too small, late-arriving packets are not played out and are dropped,
+   while when the buffer size is too large, packets are held longer than
+   necessary and consequently reduce conversational quality.
+   Measurement of jitter buffer should not be ignored in the evaluation
+   of end-user perception of conversational quality.  Metrics related to
+   the jitter buffer, such as maximum and nominal jitter buffer, could
+   be used to show how the jitter buffer behaves at the receiving
+   endpoint.  They are useful for providing better end-user quality of
+   experience (QoE) when jitter buffer factors are used as inputs to
+
+
+
+Singh, et al.                 Informational                     [Page 9]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+   calculate estimated MOS values.  Thus, for those cases, jitter buffer
+   metrics should be considered.  The definition of these metrics is
+   provided in [RFC7005].
+
+5.3.  Recovery Metrics
+
+   This document does not consider concealment metrics [RFC7294] as part
+   of recovery metrics.
+
+5.3.1.  Post-Repair Packet Count Metrics
+
+   Web applications can support certain RTP error-resilience mechanisms
+   following the recommendations specified in [WebRTC-RTP-USAGE].  For
+   these web applications using repair mechanisms, providing some
+   statistics about the performance of their repair mechanisms could
+   help provide a more accurate quality evaluation.
+
+   The unrepaired packet count and repaired loss count defined in
+   [RFC7509] provide the recovery information of the error-resilience
+   mechanisms to the monitoring application or the sending endpoint.
+   The endpoint can use these metrics to ascertain the ratio of repaired
+   packets to lost packets.  Including post-repair packet count metrics
+   helps the application evaluate the effectiveness of the applied
+   repair mechanisms.
+
+5.3.2.  Run-Length Encoded Metric for Post-Repair
+
+   [RFC5725] defines run-length encoding for post-repair packets.  When
+   using error-resilience mechanisms, the endpoint can correlate the
+   loss run length with this metric to ascertain where the losses and
+   repairs occurred in the interval.  This provides more accurate
+   information for recovery mechanisms evaluation than those in Section
+   5.3.1.  However, when RTCP XR metrics are supported, using run-length
+   encoded metrics is not suggested because the per-packet information
+   yields an enormous amount of data that is not required in this case.
+
+   For WebRTC, the application may benefit from the additional
+   information.  If losses occur after discards, an endpoint may be able
+   to correlate the two run-length vectors to identify congestion-
+   related losses, e.g., a router queue became overloaded causing delays
+   and then overflowed.  If the losses are independent, it may indicate
+   bit-error corruption.  Lastly, when using error-resilience
+   mechanisms, the endpoint can correlate the loss and post-repair run
+   lengths to ascertain where the losses and repairs occurred in the
+   interval.  For example, consecutive losses are likely not to be
+   repaired by a simple FEC scheme.
+
+
+
+
+
+Singh, et al.                 Informational                    [Page 10]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+6.  Identifiers from Sender, Receiver, and Extended Report Blocks
+
+   This document describes a list of metrics and corresponding
+   identifiers relevant to RTP media in WebRTC.  This group of
+   identifiers are defined on a ReportGroup corresponding to a
+   synchronization source (SSRC).  In practice, the application needs to
+   be able to query the statistic identifiers on both an incoming
+   (remote) and outgoing (local) media stream.  Since sending and
+   receiving SRs and RRs are mandatory, the metrics defined in the SRs
+   and RRs are always available.  For XR metrics, it depends on two
+   factors: 1) if it is measured at the endpoint and 2) if it is
+   reported by the endpoint in an XR block.  If a metric is only
+   measured by the endpoint and not reported, the metrics will only be
+   available for the incoming (remote) media stream.  Alternatively, if
+   the corresponding metric is also reported in an XR block, it will be
+   available for both the incoming (remote) and outgoing (local) media
+   stream.
+
+   For a remote statistic, the timestamp represents the timestamp from
+   an incoming SR, RR, or XR packet.  Conversely, for a local statistic,
+   it refers to the current timestamp generated by the local clock
+   (typically the POSIX timestamp, i.e., milliseconds since January 1,
+   1970).
+
+   As per [RFC3550], the octets metrics represent the payload size
+   (i.e., not including the header or padding).
+
+6.1.  Cumulative Number of Packets and Octets Sent
+
+   Name: packetsSent
+   Definition: Section 6.4.1 of [RFC3550].
+
+   Name: bytesSent
+   Definition: Section 6.4.1 of [RFC3550].
+
+6.2.  Cumulative Number of Packets and Octets Received
+
+   Name: packetsReceived
+   Definition: Section 6.4.1 of [RFC3550].
+
+   Name: bytesReceived
+   Definition: Section 6.4.1 of [RFC3550].
+
+6.3.  Cumulative Number of Packets Lost
+
+   Name: packetsLost
+   Definition: Section 6.4.1 of [RFC3550].
+
+
+
+
+Singh, et al.                 Informational                    [Page 11]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+6.4.  Interval Packet Loss and Jitter
+
+   Name: jitter
+   Definition: Section 6.4.1 of [RFC3550].
+
+   Name: fractionLost
+   Definition: Section 6.4.1 of [RFC3550].
+
+6.5.  Cumulative Number of Packets and Octets Discarded
+
+   Name: packetsDiscarded
+   Definition: The cumulative number of RTP packets discarded due to
+      late or early arrival; see item a of Appendix A of [RFC7002].
+
+   Name: bytesDiscarded
+   Definition: The cumulative number of octets discarded due to late or
+      early arrival; see Appendix A of [RFC7243].
+
+6.6.  Cumulative Number of Packets Repaired
+
+   Name: packetsRepaired
+   Definition: The cumulative number of lost RTP packets repaired after
+      applying a error-resilience mechanism; see item b of Appendix A of
+      [RFC7509].  To clarify, the value is the upper bound on the
+      cumulative number of lost packets.
+
+6.7.  Burst Packet Loss and Burst Discards
+
+   Name: burstPacketsLost
+   Definition: The cumulative number of RTP packets lost during loss
+      bursts; see item c of Appendix A of [RFC6958].
+
+   Name: burstLossCount
+   Definition: The cumulative number of bursts of lost RTP packets; see
+      item d of Appendix A of [RFC6958].
+
+   Name: burstPacketsDiscarded
+   Definition: The cumulative number of RTP packets discarded during
+      discard bursts; see item b of Appendix A of [RFC7003].
+
+   Name: burstDiscardCount
+   Definition: The cumulative number of bursts of discarded RTP packets;
+      see item e of Appendix A of [RFC8015].
+
+   [RFC3611] recommends a Gmin (threshold) value of 16 for classifying
+   packet loss or discard burst.
+
+
+
+
+
+Singh, et al.                 Informational                    [Page 12]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+6.8.  Burst/Gap Rates
+
+   Name: burstLossRate
+   Definition: The fraction of RTP packets lost during bursts; see
+      item a of Appendix A of [RFC7004].
+
+   Name: gapLossRate
+   Definition: The fraction of RTP packets lost during gaps; see item b
+      of Appendix A of [RFC7004].
+
+   Name: burstDiscardRate
+   Definition: The fraction of RTP packets discarded during bursts; see
+      item e of Appendix A of [RFC7004].
+
+   Name: gapDiscardRate
+   Definition: The fraction of RTP packets discarded during gaps; see
+      item f of Appendix A of [RFC7004].
+
+6.9.  Frame Impairment Metrics
+
+   Name: framesLost
+   Definition: The cumulative number of full frames lost; see item i of
+      Appendix A of [RFC7004].
+
+   Name: framesCorrupted
+   Definition: The cumulative number of frames partially lost; see
+      item j of Appendix A of [RFC7004].
+
+   Name: framesDropped
+   Definition: The cumulative number of full frames discarded; see
+      item g of Appendix A of [RFC7004].
+
+   Name: framesSent
+   Definition: The cumulative number of frames sent.
+
+   Name: framesReceived
+   Definition: The cumulative number of partial or full frames received.
+
+7.  Adding New Metrics to WebRTC Statistics API
+
+   While this document was being drafted, the metrics defined herein
+   were added to the W3C WebRTC specification.  The process to add new
+   metrics in the future is to create an issue or pull request on the
+   repository of the W3C WebRTC specification
+   (https://github.com/w3c/webrtc-stats).
+
+
+
+
+
+
+Singh, et al.                 Informational                    [Page 13]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+8.  Security Considerations
+
+   This document focuses on listing the RTCP XR metrics defined in the
+   corresponding RTCP reporting extensions and does not give rise to any
+   security vulnerabilities beyond those described in [RFC3611] and
+   [RFC6792].
+
+   The overall security considerations for RTP used in WebRTC
+   applications is described in [WebRTC-RTP-USAGE] and [WebRTC-Sec],
+   which also apply to this memo.
+
+9.  IANA Considerations
+
+   This document has no IANA actions.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+              July 2003, <https://www.rfc-editor.org/info/rfc3550>.
+
+   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
+              "RTP Control Protocol Extended Reports (RTCP XR)",
+              RFC 3611, DOI 10.17487/RFC3611, November 2003,
+              <https://www.rfc-editor.org/info/rfc3611>.
+
+   [RFC5725]  Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
+              Report Block Type for RTP Control Protocol (RTCP) Extended
+              Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February
+              2010, <https://www.rfc-editor.org/info/rfc5725>.
+
+   [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,
+              DOI 10.17487/RFC6776, October 2012,
+              <https://www.rfc-editor.org/info/rfc6776>.
+
+   [RFC6792]  Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
+              of the RTP Monitoring Framework", RFC 6792,
+              DOI 10.17487/RFC6792, November 2012,
+              <https://www.rfc-editor.org/info/rfc6792>.
+
+
+
+
+
+
+
+Singh, et al.                 Informational                    [Page 14]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+   [RFC6958]  Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP
+              Control Protocol (RTCP) Extended Report (XR) Block for
+              Burst/Gap Loss Metric Reporting", RFC 6958,
+              DOI 10.17487/RFC6958, May 2013,
+              <https://www.rfc-editor.org/info/rfc6958>.
+
+   [RFC7002]  Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol
+              (RTCP) Extended Report (XR) Block for Discard Count Metric
+              Reporting", RFC 7002, DOI 10.17487/RFC7002, September
+              2013, <https://www.rfc-editor.org/info/rfc7002>.
+
+   [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, DOI 10.17487/RFC7003,
+              September 2013, <https://www.rfc-editor.org/info/rfc7003>.
+
+   [RFC7004]  Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP
+              Control Protocol (RTCP) Extended Report (XR) Blocks for
+              Summary Statistics Metrics Reporting", RFC 7004,
+              DOI 10.17487/RFC7004, September 2013,
+              <https://www.rfc-editor.org/info/rfc7004>.
+
+   [RFC7005]  Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol
+              (RTCP) Extended Report (XR) Block for De-Jitter Buffer
+              Metric Reporting", RFC 7005, DOI 10.17487/RFC7005,
+              September 2013, <http://www.rfc-editor.org/info/rfc7005>.
+
+   [RFC7097]  Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control
+              Protocol (RTCP) Extended Report (XR) for RLE of Discarded
+              Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014,
+              <http://www.rfc-editor.org/info/rfc7097>.
+
+   [RFC7243]  Singh, V., Ed., Ott, J., and I. Curcio, "RTP Control
+              Protocol (RTCP) Extended Report (XR) Block for the Bytes
+              Discarded Metric", RFC 7243, DOI 10.17487/RFC7243, May
+              2014, <http://www.rfc-editor.org/info/rfc7243>.
+
+   [RFC7509]  Huang, R. and V. Singh, "RTP Control Protocol (RTCP)
+              Extended Report (XR) for Post-Repair Loss Count Metrics",
+              RFC 7509, DOI 10.17487/RFC7509, May 2015,
+              <http://www.rfc-editor.org/info/rfc7509>.
+
+   [RFC8015]  Singh, V., Perkins, C., Clark, A., and R. Huang, "RTP
+              Control Protocol (RTCP) Extended Report (XR) Block for
+              Independent Reporting of Burst/Gap Discard Metrics",
+              RFC 8015, DOI 10.17487/RFC8015, November 2016,
+              <http://www.rfc-editor.org/info/rfc8015>.
+
+
+
+
+Singh, et al.                 Informational                    [Page 15]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+10.2.  Informative References
+
+   [ITU-T_P.800.1]
+              ITU-T, "Mean Opinion Score (MOS) terminology", ITU-T
+              P.800.1, July 2016,
+              <https://www.itu.int/rec/T-REC-P.800.1-201607-I>.
+
+   [RFC4445]  Welch, J. and J. Clark, "A Proposed Media Delivery Index
+              (MDI)", RFC 4445, DOI 10.17487/RFC4445, April 2006,
+              <https://www.rfc-editor.org/info/rfc4445>.
+
+   [WebRTC-Overview]
+              Alverstrand, H., "Overview: Real Time Protocols for
+              Browser-based Applications", Work in Progress,
+              draft-ietf-rtcweb-overview-19, November 2017.
+
+   [WebRTC-RTP-USAGE]
+              Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
+              Communication (WebRTC): Media Transport and Use of RTP",
+              Work in Progress, draft-ietf-rtcweb-rtp-usage-26, March
+              2016.
+
+   [WebRTC-Sec]
+              Rescorla, E., "Security Considerations for WebRTC", Work
+              in Progress, draft-ietf-rtcweb-security-10, January 2018.
+
+   [RFC7294]  Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control
+              Protocol (RTCP) Extended Report (XR) Blocks for
+              Concealment Metrics Reporting on Audio Applications",
+              RFC 7294, DOI 10.17487/RFC7294, July 2014,
+              <https://www.rfc-editor.org/info/rfc7294>.
+
+   [RFC7478]  Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
+              Time Communication Use Cases and Requirements", RFC 7478,
+              DOI 10.17487/RFC7478, March 2015,
+              <https://www.rfc-editor.org/info/rfc7478>.
+
+   [W3C.webrtc]
+              Bergkvist, A., Burnett, C., Jennings, C., Narayanan, A.,
+              Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0:
+              Real-time Communication Between Browsers", W3C Candidate
+              Recommendation, June 2018,
+              <https://www.w3.org/TR/2018/CR-webrtc-20180621/>.
+              Latest version available at
+              <https://www.w3.org/TR/webrtc/>.
+
+
+
+
+
+
+Singh, et al.                 Informational                    [Page 16]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+   [W3C.webrtc-stats]
+              Alvestrand, H. and V. Singh, "Identifiers for WebRTC's
+              Statistics API", W3C Candidate Recommendation, July 2018,
+              <https://www.w3.org/TR/2018/CR-webrtc-stats-20180703/>.
+              Latest version available at
+              <https://www.w3.org/TR/webrtc-stats/>.
+
+Acknowledgements
+
+   The authors would like to thank Bernard Aboba, Harald Alvestrand, Al
+   Morton, Colin Perkins, and Shida Schubert for their valuable comments
+   and suggestions on earlier draft versions of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et al.                 Informational                    [Page 17]
+
+RFC 8451               RTCP XR Metrics for WebRTC         September 2018
+
+
+Authors' Addresses
+
+   Varun Singh
+   CALLSTATS I/O Oy
+   Annankatu 31-33 C 42
+   Helsinki  00100
+   Finland
+
+   Email: varun@callstats.io
+   URI:   https://www.callstats.io/about
+
+
+   Rachel Huang
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing  210012
+   China
+
+   Email: rachel.huang@huawei.com
+
+
+   Roni Even
+   Huawei
+   14 David Hamelech
+   Tel Aviv  64953
+   Israel
+
+   Email: roni.even@huawei.com
+
+
+   Dan Romascanu
+
+   Email: dromasca@gmail.com
+
+
+   Lingli Deng
+   China Mobile
+
+   Email: denglingli@chinamobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et al.                 Informational                    [Page 18]
+