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
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
为WebRTC统计API选择RTP控制协议（RTCP）扩展报告（XR）指标的注意事项
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.
本文档描述了与Web实时通信（WebRTC）中的媒体流相关的监视功能。它提供了RTP控制协议（RTCP）发送方报告（SR）、接收方报告（RR）和扩展报告（XR）度量的列表，在某些不同的环境中，RTP实现可能需要支持这些度量。它列出了WebRTC统计API的一组标识符。这些标识符是一组与多媒体流传输相关的RTCP SR、RR和XR度量。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8451.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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:
Web实时通信（WebRTC）[WebRTC概述]部署正在兴起，应用程序需要能够估计服务质量。如果向应用程序提供了足够的信息（指标或统计数据），它可以尝试提高媒体质量。[RFC7478]规定了统计要求：
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.
F38浏览器必须能够收集与同行之间的音频和视频传输相关的统计数据，以评估体验质量。
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.
WebRTC统计API[W3C.WebRTC统计]目前列出了RTCP发送方报告和接收方报告（SR/RR）[RFC3550]中报告的指标，以满足此要求。然而，RTCP SR/RR的基本指标不足以进行精确的质量监控或诊断潜在问题。
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].
诸如“RTP控制协议扩展报告（RTCP XR）”[RFC3611]等标准以及XRBLOCK工作组中标准化的其他扩展，例如突发/间隙损失度量报告[RFC6958]和突发/间隙丢弃度量报告[RFC7003]，用于收集和报告RTP端点设备的性能指标，这些指标可用于提供端到端服务可见性，并测量各种RTP服务中的交付质量。这些指标能够补充[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.
在本文档中，我们提供了为WebRTC getStats（）API[W3C.WebRTC]选择其他RTP指标的基本原理。本文档中提出的所有标识符建议由WebRTC端点实现。如果端点未实现相应的RTCP报告，则可以选择不公开标识符。本文档仅考虑RTP层度量。其他指标（如IP层指标）超出范围。
In addition to the terminology from [RFC3550], [RFC3611], and [RFC7478], this document uses the following term.
除[RFC3550]、[RFC3611]和[RFC7478]中的术语外，本文件使用以下术语。
ReportGroup: It is a set of metrics identified by a common synchronization source (SSRC).
ReportGroup：它是由公共同步源（SSRC）标识的一组度量。
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.
RTCP发送方报告（SRs）和接收方报告（RRs）[RFC3550]公开了本地和远程媒体流的基本指标。然而，这些指标仅提供部分或有限的信息，这可能不足以诊断问题或监控质量。例如，区分丢失的数据包和由于延迟到达而丢弃的数据包可能是有用的。尽管它们对多媒体质量有相同的影响，但它有助于识别和诊断问题。RTP控制协议扩展报告（XRs）[RFC3611]和XRBLOCK工作组中讨论的其他扩展提供了更详细的统计数据，补充了RTCP SR和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.
WebRTC应用程序通过查询getStats（）API[W3C.WebRTC]从浏览器中提取统计信息。浏览器可以轻松报告局部变量，即与传出和传入RTP媒体流相关的统计信息。但是，如果没有RTCP XRs或其他一些信令机制的支持，WebRTC应用程序无法公开远程端点的统计信息。[WebRTC RTP用法]不强制使用任何RTCP XR，其用法是可选的。如果在端点之间（通过SDP）成功协商使用RTCP XRs，则应用程序可以访问本地和远程统计信息。或者，一旦WebRTC应用程序获得本地信息，它可以将信息报告给应用程序服务器或第三方监控系统，后者为应用程序开发人员提供质量评估或诊断服务。端点之间或监视服务器与端点之间的统计信息交换不在本文档的范围内。
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].
RTCP扩展（如RTCP XR）通常与RTCP SR/RR共享相同的时间间隔，即它们与RTCP SR/RR一起作为复合数据包发送。或者，如果RTCP XR使用不同的测量间隔，则使用相同测量间隔的所有XR组合在一起，并且在[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
当使用WebRTC getStats（）API（请参阅[W3C.WebRTC]中的“统计模型”）时，应用程序可以任意间隔查询此信息。对于远程端点报告的统计信息，例如RTCP SR/RR/XR中传输的统计信息，在收到下一个RTCP报告之前，这些统计信息不会更改。但是，只要端点正在发送和接收媒体，本地端点生成的统计信息就没有此类限制。例如，一个
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.
应用程序可以选择每隔1秒轮询堆栈以获取统计信息。在这种情况下，底层本地堆栈将返回本地统计信息的当前快照（用于传入和传出媒体流）。但是，它可能返回与以前相同的远程统计信息，因为在过去1秒内可能没有收到新的RTCP报告。当轮询间隔短于平均RTCP报告间隔时，可能会发生这种情况。
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.
由于以下指标都是在RTCP XR中定义的，而在WebRTC中没有强制要求，因此它们都是本地的。但是，如果两个浏览器之间的协商支持RTCP XR，则也可以远程生成以下指标，并通过RTCP XR数据包发送到本地端点（生成媒体）。
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.
这些指标分为以下三类：网络影响指标、应用程序影响指标和恢复指标。网络影响度量是仅为网络传输记录信息的统计数据。它们对于网络问题诊断非常有用。应用程序影响度量主要从应用程序的角度收集信息，例如，比特率、帧速率或抖动缓冲区。恢复度量反映修复机制的执行情况，例如丢失隐藏、重传或前向纠错（FEC）。所有3种类型的度量对于WebRTC实现中的服务质量评估都很有用。WebRTC应用程序可以使用这些指标计算其服务的估计平均意见评分（MOS）[ITU-T_P.800.1]值或媒体交付指数（MDI）[RFC4445]。
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
在多媒体传输中，异常接收的数据包分为3种类型：丢失的、丢弃的和重复的数据包。数据包丢失可能由网络设备故障、位错误损坏或网络拥塞（中间路由器队列丢弃的数据包）引起。重复数据包可能是导致发送方重新传输原始数据包的网络延迟的结果。丢弃的数据包是延迟足够长的数据包（可能错过了播放时间），并且被接收器认为是无用的。丢失和丢弃的数据包会导致多媒体服务出现问题，因为丢失数据和长时间延迟可能会导致服务质量下降，例如，丢失大块连续数据包（丢失或丢弃）可能会导致音频断断续续，而长时间的网络传输延迟可能会导致音频或视频缓冲。RTCP SR/RR定义了计算RTP数据包总数的指标
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.
从接待开始就丢失了。但是，此统计数据不能区分丢失的数据包与丢弃的数据包和重复的数据包。延迟到达的数据包将被丢弃，并且不会报告为丢失，重复的数据包将被视为正常接收的数据包。因此，如果接收到许多重复的分组或丢弃分组，则丢失度量可能是误导性的，这使得媒体传输的质量从统计角度来看似乎是正常的，而用户实际上正在经历糟糕的服务质量。因此，在这种情况下，除了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.
[RFC3611]的统计摘要报告块中定义的丢失数据包和重复数据包的度量扩展了标准RTCP SR/RR中的丢失信息。它们明确说明了丢失和重复的数据包。丢失数据包计数对于网络问题诊断非常有用。最好使用[RFC3611]的丢包度量来指示丢包计数，而不是[RFC3550]的累计丢包数度量。重复数据包通常很少，对QoS评估几乎没有影响。因此，它可能不适合在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.
使用丢失度量而不考虑丢弃度量可能会导致不准确的质量评估，因为在现代IP网络中，由于抖动导致的数据包丢弃通常比数据包丢失更普遍。[RFC7002]中指定的丢弃度量统计由于抖动而丢弃的数据包数。它增加了标准RTCP SR/RR中指定的损失统计指标。对于那些具有抖动缓冲区的WebRTC服务，需要进行精确的质量评估和精确的故障排除，此指标可作为RTCP SR/RR指标的补充。
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.
RTCP SR/RR定义了关于丢失统计信息的粗略度量：这些度量信息都是关于每次呼叫的统计信息，不够详细，无法捕捉某些损伤（如突发性数据包丢失）的暂时性。即使平均分组丢失率较低，丢失的分组也可能发生在短的密集时段，导致短时间的质量下降。对于低丢包率，突发导致的体验质量低于非突发，而对于高丢包率，反之亦然。因此，获取突发间隔信息对于质量评估和缺陷定位非常有帮助。如果WebRTC应用程序需要评估服务质量，则突发间隔度量比RTCP SR/RR提供更准确的信息。
[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.
[RFC3611]在VoIP报告块中引入突发间隔度量。这些度量记录突发和间隔周期的密度和持续时间，这有助于隔离网络问题，因为突发对应于数据包丢失/丢弃率高到足以导致音频或视频质量明显下降的时间段。[RFC7003]和[RFC6958]中还介绍了与突发间隔相关的指标，它们定义了两个新的报告块，用于[RFC3611]中所述范围以外的RTP应用程序。这些度量将丢弃的数据包与突发期间发生的丢失数据包区分开来，并为诊断网络问题提供更多信息。此外，该块报告突发事件的频率，这是用于评估体验质量的有用信息。因此，如果WebRTC应用程序需要进行质量评估，并观察质量下降的时间和原因，则应考虑这些指标。
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.
运行长度编码使用位向量对数据包的信息进行编码。向量中的每一位表示一个分组；根据信号度量，它定义数据包是否丢失、复制、丢弃或修复。端点通常使用游程编码将间隔中每个数据包的状态准确地传达给另一个端点。[RFC3611]和[RFC7097]分别定义丢失和重复数据包以及丢弃数据包的运行长度编码。
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.
WebRTC应用程序可以从附加信息中获益。如果丢失发生在丢弃之后，端点可能能够关联两个运行长度向量以识别与拥塞相关的丢失，例如，路由器队列过载导致延迟，然后溢出。如果损失是独立的，则可能表示误码损坏。对于WebRTC统计API[W3C.WebRTC Stats]，由于涉及大量数据和计算，因此不建议使用这些类型的度量。
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.
度量报告在间隔内丢弃的数据包的累积大小。它是对丢弃的数据包数量的补充。应用程序测量发送的八位字节和接收的八位字节，分别计算发送速率和接收速率。应用程序可以通过从接收的八位字节中减去丢弃的八位字节来计算特定间隔内的实际比特率。
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].
对于WebRTC，丢弃的八位字节度量补充了发送和接收的八位字节的度量，并提供了计算实际比特率的准确方法，这是反映媒体质量的一个重要参数。[RFC7243]中定义了丢弃字节的度量。
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.
RTP对于不同的负载类型有不同的帧机制。对于音频流，单个RTP分组可以包含一个或多个音频帧。另一方面，在视频流中，单个视频帧可以在多个RTP分组中传输。每个数据包的大小受底层网络的最大传输单元（MTU）的限制。然而，来自标准SR/RR的统计数据仅收集传输层的信息，因此它们可能无法完全反映应用程序观察到的质量。视频通常使用两种帧类型进行编码，即关键帧和派生帧。关键帧通常仅在空间上压缩，即，没有来自其他图片的预测。导出的帧被临时压缩，即，取决于用于解码的关键帧。因此，关键帧的大小比派生帧大得多。丢失这些关键帧会导致视频质量大幅降低。因此，在WebRTC实现中考虑这种应用层信息是合理的，它影响发送者策略以减轻问题或需要准确地评估用户的体验质量。
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.
此类别中的度量包括：丢弃的关键帧数、丢失的关键帧数、丢弃的派生帧数和丢失的派生帧数。这些指标可用于计算MDI的介质丢失率（MLR）[RFC4445]。[RFC7003]中描述了这些指标定义的详细信息。此外，该度量还提供渲染帧速率，这是质量估计的一个重要参数。
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
抖动缓冲区的大小会影响网络上的端到端延迟以及数据包丢弃率。当缓冲区大小太小时，延迟到达的数据包不会播放出来并被丢弃，而当缓冲区大小太大时，数据包被保留的时间过长，从而降低会话质量。在评估最终用户对会话质量的感知时，不应忽略抖动缓冲区的测量。与抖动缓冲区相关的度量，例如最大和标称抖动缓冲区，可用于显示抖动缓冲区在接收端点的行为。当抖动缓冲因子用作输入时，它们有助于提供更好的最终用户体验质量（QoE）
calculate estimated MOS values. Thus, for those cases, jitter buffer metrics should be considered. The definition of these metrics is provided in [RFC7005].
计算估计的MOS值。因此，对于这些情况，应该考虑抖动缓冲度量。[RFC7005]中提供了这些指标的定义。
This document does not consider concealment metrics [RFC7294] as part of recovery metrics.
该文档不考虑隐藏度量[RCF794]作为恢复度量的一部分。
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.
Web应用程序可以按照[WebRTC RTP用法]中指定的建议支持某些RTP错误恢复机制。对于这些使用修复机制的web应用程序，提供有关其修复机制性能的一些统计信息有助于提供更准确的质量评估。
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.
[RFC7509]中定义的未修复数据包计数和修复的丢失计数向监控应用程序或发送端点提供错误恢复机制的恢复信息。端点可以使用这些度量来确定修复数据包与丢失数据包的比率。包括修复后数据包计数指标有助于应用程序评估所应用修复机制的有效性。
[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.
[RFC5725]定义修复后数据包的运行长度编码。当使用错误恢复机制时，端点可以将损失运行长度与该度量相关联，以确定在该时间间隔内损失和修复发生的位置。这为恢复机制评估提供了比第5.3.1节更准确的信息。但是，当支持RTCP XR度量时，不建议使用运行长度编码的度量，因为每个数据包的信息会产生大量数据，在这种情况下不需要这些数据。
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.
对于WebRTC，应用程序可能会从附加信息中受益。如果丢失发生在丢弃之后，端点可能能够关联两个运行长度向量以识别与拥塞相关的丢失，例如，路由器队列过载导致延迟，然后溢出。如果损失是独立的，则可能表示误码损坏。最后，当使用错误恢复机制时，端点可以关联损失和修复后运行长度，以确定损失和修复在间隔中发生的位置。例如，连续损失很可能无法通过简单的FEC方案修复。
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.
本文档描述了WebRTC中与RTP介质相关的指标和相应标识符列表。这组标识符是在与同步源（SSRC）相对应的ReportGroup上定义的。实际上，应用程序需要能够查询传入（远程）和传出（本地）媒体流上的统计标识符。由于发送和接收SRs和RRs是强制性的，所以SRs和RRs中定义的指标始终可用。对于XR度量，它取决于两个因素：1）是否在端点处测量，2）是否由端点在XR块中报告。如果指标仅由端点测量而未报告，则指标将仅适用于传入（远程）媒体流。或者，如果在XR块中也报告了相应的度量，则它将可用于传入（远程）和传出（本地）媒体流。
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).
对于远程统计，时间戳表示来自传入SR、RR或XR数据包的时间戳。相反，对于本地统计，它指的是本地时钟生成的当前时间戳（通常是POSIX时间戳，即自1970年1月1日起的毫秒）。
As per [RFC3550], the octets metrics represent the payload size (i.e., not including the header or padding).
根据[RFC3550]，八位字节度量表示有效负载大小（即，不包括标头或填充）。
Name: packetsSent Definition: Section 6.4.1 of [RFC3550].
名称：包装件定义：[RFC3550]第6.4.1节。
Name: bytesSent Definition: Section 6.4.1 of [RFC3550].
名称：bytesSent定义：[RFC3550]第6.4.1节。
Name: packetsReceived Definition: Section 6.4.1 of [RFC3550].
名称：包装接收定义：第6.4.1节[RFC3550]。
Name: bytesReceived Definition: Section 6.4.1 of [RFC3550].
名称：bytesReceived定义：[RFC3550]第6.4.1节。
Name: packetsLost Definition: Section 6.4.1 of [RFC3550].
名称：包装成本定义：[RFC3550]第6.4.1节。
Name: jitter Definition: Section 6.4.1 of [RFC3550].
名称：抖动定义：[RFC3550]第6.4.1节。
Name: fractionLost Definition: Section 6.4.1 of [RFC3550].
名称：fractionLost定义：[RFC3550]第6.4.1节。
Name: packetsDiscarded Definition: The cumulative number of RTP packets discarded due to late or early arrival; see item a of Appendix A of [RFC7002].
名称：packetsDiscarded定义：由于延迟或提前到达而丢弃的RTP数据包的累计数量；见[RFC7002]附录a中的a项。
Name: bytesDiscarded Definition: The cumulative number of octets discarded due to late or early arrival; see Appendix A of [RFC7243].
名称：bytesDiscarded定义：由于延迟或提前到达而丢弃的八位字节的累计数量；参见[RFC7243]的附录A。
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.
名称：packetsRepaired定义：应用错误恢复机制后修复的丢失RTP数据包的累计数量；见[RFC7509]附录A第b项。为了澄清，该值是丢失数据包的累积数量的上限。
Name: burstPacketsLost Definition: The cumulative number of RTP packets lost during loss bursts; see item c of Appendix A of [RFC6958].
名称：burstPacketsLost定义：在丢失突发期间丢失的RTP数据包的累计数量；见[RFC6958]附录A第c项。
Name: burstLossCount Definition: The cumulative number of bursts of lost RTP packets; see item d of Appendix A of [RFC6958].
名称：burstLossCount定义：丢失RTP数据包的累计突发数；见[RFC6958]附录A第d项。
Name: burstPacketsDiscarded Definition: The cumulative number of RTP packets discarded during discard bursts; see item b of Appendix A of [RFC7003].
名称：burstPacketsDiscarded定义：丢弃突发期间丢弃的RTP数据包的累计数量；见[RFC7003]附录A第b项。
Name: burstDiscardCount Definition: The cumulative number of bursts of discarded RTP packets; see item e of Appendix A of [RFC8015].
名称：burstDiscardCount定义：丢弃RTP数据包的累计突发数；见[RFC8015]附录A第e项。
[RFC3611] recommends a Gmin (threshold) value of 16 for classifying packet loss or discard burst.
[RFC3611]建议将Gmin（阈值）值设为16，用于分组丢失或丢弃突发。
Name: burstLossRate Definition: The fraction of RTP packets lost during bursts; see item a of Appendix A of [RFC7004].
名称：burstLossRate定义：突发过程中RTP数据包丢失的分数；参见[RFC7004]附录a中的a项。
Name: gapLossRate Definition: The fraction of RTP packets lost during gaps; see item b of Appendix A of [RFC7004].
名称：gaplosrate定义：在间隔期间丢失的RTP数据包的分数；见[RFC7004]附录A第b项。
Name: burstDiscardRate Definition: The fraction of RTP packets discarded during bursts; see item e of Appendix A of [RFC7004].
名称：burstDiscardRate定义：突发期间丢弃的RTP数据包的分数；见[RFC7004]附录A第e项。
Name: gapDiscardRate Definition: The fraction of RTP packets discarded during gaps; see item f of Appendix A of [RFC7004].
名称：gapDiscardRate定义：间隙期间丢弃的RTP数据包的分数；参见[RFC7004]附录A中的f项。
Name: framesLost Definition: The cumulative number of full frames lost; see item i of Appendix A of [RFC7004].
名称：framesLost定义：丢失的完整帧的累计数量；见[RFC7004]附录A第i项。
Name: framesCorrupted Definition: The cumulative number of frames partially lost; see item j of Appendix A of [RFC7004].
名称：FrameScorFramed定义：部分丢失的累积帧数；见[RFC7004]附录A第j项。
Name: framesDropped Definition: The cumulative number of full frames discarded; see item g of Appendix A of [RFC7004].
名称：framesDropped定义：丢弃的完整帧的累计数量；见[RFC7004]附录A第g项。
Name: framesSent Definition: The cumulative number of frames sent.
名称：帧发送定义：发送的帧的累积数量。
Name: framesReceived Definition: The cumulative number of partial or full frames received.
名称：framesReceived定义：接收的部分或完整帧的累积数量。
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).
在起草本文件时，此处定义的指标已添加到W3C WebRTC规范中。未来添加新指标的过程是在W3C WebRTC规范的存储库上创建问题或请求(https://github.com/w3c/webrtc-stats).
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].
本文档重点列出了相应RTCP报告扩展中定义的RTCP XR度量，不会产生[RFC3611]和[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.
WebRTC应用程序中使用的RTP的总体安全注意事项在[WebRTC RTP用法]和[WebRTC Sec]中进行了说明，这也适用于本备忘录。
This document has no IANA actions.
本文档没有IANA操作。
[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>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<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>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<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>.
[RFC5725]Begen，A.，Hsu，D.，和M.Lague，“RTP控制协议（RTCP）扩展报告（XRs）的修复后损失RLE报告块类型”，RFC 5725，DOI 10.17487/RFC5725，2010年2月<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>.
[RFC6776]Clark，A.和Q.Wu，“使用源描述（SDES）项和RTCP扩展报告（XR）块的测量标识和信息报告”，RFC 6776，DOI 10.17487/RFC6776，2012年10月<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>.
[RFC6792]Wu，Q.，Ed.，Hunt，G.，和P.Arden，“RTP监测框架的使用指南”，RFC 6792，DOI 10.17487/RFC6792，2012年11月<https://www.rfc-editor.org/info/rfc6792>.
[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>.
[RFC6958]Clark，A.，Zhang，S.，Zhao，J.，和Q.Wu，Ed.，“用于突发/间隙损失度量报告的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 6958，DOI 10.17487/RFC6958，2013年5月<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>.
[RFC7002]Clark，A.，Zorn，G.和Q.Wu，“用于丢弃计数度量报告的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 7002，DOI 10.17487/RFC7002，2013年9月<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>.
[RFC7003]Clark，A.，Huang，R.，和Q.Wu，Ed.，“用于突发/间隙丢弃度量报告的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 7003，DOI 10.17487/RFC7003，2013年9月<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>.
[RFC7004]Zorn，G.，Schott，R.，Wu，Q.，Ed.，和R.Huang，“用于汇总统计指标报告的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 7004，DOI 10.17487/RFC7004，2013年9月<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>.
[RFC7005]Clark，A.，Singh，V.和Q.Wu，“用于去抖动缓冲区度量报告的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 7005，DOI 10.17487/RFC7005，2013年9月<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>.
[RFC7097]Ott，J.，Singh，V.，Ed.，和I.Curcio，“丢弃数据包RLE的RTP控制协议（RTCP）扩展报告（XR）”，RFC 7097，DOI 10.17487/RFC7097，2014年1月<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>.
[RFC7243]Singh，V.，Ed.，Ott，J.，和I.Curcio，“用于丢弃字节度量的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 7243，DOI 10.17487/RFC7243，2014年5月<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>.
[RFC7509]Huang，R.和V.Singh，“修复后损失计数指标的RTP控制协议（RTCP）扩展报告（XR）”，RFC 7509，DOI 10.17487/RFC7509，2015年5月<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>.
[RFC8015]Singh，V.，Perkins，C.，Clark，A.，和R.Huang，“用于独立报告突发/间隙丢弃度量的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 8015，DOI 10.17487/RFC8015，2016年11月<http://www.rfc-editor.org/info/rfc8015>.
[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>.
[ITU-T_P.800.1]ITU-T，“平均意见得分（MOS）术语”，ITU-T P.800.120016年7月<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>.
[RFC4445]Welch，J.和J.Clark，“建议的媒体交付指数（MDI）”，RFC 4445，DOI 10.17487/RFC4445，2006年4月<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概述]Alverstrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-rtcweb-Overview-19，2017年11月。
[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 RTP使用]Perkins，C.，Westerlund，M.，和J.Ott，“网络实时通信（WebRTC）：媒体传输和RTP的使用”，正在进行的工作，草稿-ietf-rtcweb-RTP-USAGE-26，2016年3月。
[WebRTC-Sec] Rescorla, E., "Security Considerations for WebRTC", Work in Progress, draft-ietf-rtcweb-security-10, January 2018.
[WebRTC Sec]Rescorla，E.，“WebRTC的安全注意事项”，正在进行的工作，草稿-ietf-rtcweb-Security-10，2018年1月。
[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>.
[RFC7294]Clark，A.，Zorn，G.，Bi，C.，和Q.Wu，“用于音频应用上隐藏度量报告的RTP控制协议（RTCP）扩展报告（XR）块”，RFC 7294，DOI 10.17487/RFC7294，2014年7月<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>.
[RFC7478]Holmberg，C.，Hakanson，S.，和G.Eriksson，“网络实时通信用例和需求”，RFC 7478，DOI 10.17487/RFC7478，2015年3月<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/>.
[W3C.webrtc]Bergkvist，A.，Burnett，C.，Jennings，C.，Narayanan，A.，Aboba，B.，Brandstetter，T.，和J.Bruaroey，“webrtc 1.0：浏览器之间的实时通信”，W3C候选推荐，2018年6月<https://www.w3.org/TR/2018/CR-webrtc-20180621/>. 最新版本可于<https://www.w3.org/TR/webrtc/>.
[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/>.
[W3C.webrtc统计]Alvestrand，H.和V.Singh，“webrtc统计API的标识符”，W3C候选推荐，2018年7月<https://www.w3.org/TR/2018/CR-webrtc-stats-20180703/>. 最新版本可于<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.
作者要感谢Bernard Aboba、Harald Alvestrand、Al Morton、Colin Perkins和Shida Schubert对本文件早期草案提出的宝贵意见和建议。
Authors' Addresses
作者地址
Varun Singh CALLSTATS I/O Oy Annankatu 31-33 C 42 Helsinki 00100 Finland
Varun Singh CALLSTATS I/O Oy Annankatu 31-33 C 42赫尔辛基00100芬兰
Email: varun@callstats.io
URI: https://www.callstats.io/about
Email: varun@callstats.io
URI: https://www.callstats.io/about
Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China
中国南京市雨花区华为软件大道101号，邮编：210012
Email: rachel.huang@huawei.com
Email: rachel.huang@huawei.com
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Roni甚至华为14 David Hamelech特拉维夫64953以色列
Email: roni.even@huawei.com
Email: roni.even@huawei.com
Dan Romascanu
丹·罗马斯卡努
Email: dromasca@gmail.com
Email: dromasca@gmail.com
Lingli Deng China Mobile
凌厉邓中国移动
Email: denglingli@chinamobile.com
Email: denglingli@chinamobile.com