[要約] RFC 8451は、WebRTC統計APIのためのRTP制御プロトコル（RTCP）拡張レポート（XR）メトリックの選択に関する考慮事項を提供します。このRFCの目的は、WebRTCアプリケーションのパフォーマンス監視とトラブルシューティングのために適切なXRメトリックを選択するためのガイダンスを提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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-Overview]の展開が出現しており、アプリケーションはサービス品質を推定できる必要があります。アプリケーションに十分な情報（メトリックまたは統計）が提供されている場合、メディア品質の向上を試みることができます。 [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 Stats API [W3C.webrtc-stats]は現在、この要件を満たすために、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 Control Protocol Extended Reports（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送信者レポート（SR）および受信者レポート（RR）[RFC3550]は、ローカルおよびリモートメディアストリームの基本的なメトリックを公開します。ただし、これらのメトリックは部分的または限定的な情報しか提供しないため、問題の診断や品質の監視には不十分な場合があります。たとえば、到着が遅れたために失われたパケットと破棄されたパケットを区別すると便利です。マルチメディアの品質にも同じ影響がありますが、問題の特定と診断に役立ちます。 RTPコントロールプロトコル拡張レポート（XR）[RFC3611]およびXRBLOCKワーキンググループで説明されているその他の拡張機能は、RTCP SRおよびRRで報告される基本的なメトリックを補足する、より詳細な統計を提供します。
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 XRまたはその他のシグナリングメカニズムのサポートがない場合、WebRTCアプリケーションはリモートエンドポイントの統計を公開できません。 [WebRTC-RTP-USAGE]はRTCP XRの使用を義務付けておらず、それらの使用はオプションです。 RTCP XRの使用がエンドポイント間で（SDPを介して）正常にネゴシエートされた場合、その後、アプリケーションはローカルとリモートの両方の統計にアクセスできます。または、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 XRのようなRTCP拡張機能は、通常、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 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.
WebRTC getStats()API（[W3C.webrtc]の「統計モデル」を参照）を使用すると、アプリケーションはこの情報を任意の間隔で照会できます。リモートエンドポイントによって報告される統計情報（RTCP SR / RR / XRで伝達される統計など）の場合、これらは次のRTCPレポートが受信されるまで変更されません。ただし、エンドポイントがメディアを送受信している限り、ローカルエンドポイントによって生成された統計にはそのような制限はありません。たとえば、アプリケーションは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では必須ではないため、すべてローカルです。ただし、2つのブラウザー間のネゴシエーションで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.
メトリックは、ネットワーク影響メトリック、アプリケーション影響メトリック、および回復メトリックの3つのカテゴリーに分類されます。ネットワーク影響メトリックは、ネットワーク送信のみの情報を記録する統計です。これらは、ネットワーク問題の診断に役立ちます。アプリケーションインパクトメトリックは主に、ビットレート、フレームレート、ジッタバッファなど、アプリケーションの観点から情報を収集します。リカバリメトリックは、修復メカニズムがどの程度適切に機能するかを示します。たとえば、損失の隠蔽、再送信、転送エラー修正（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 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.
マルチメディアトランスポートでは、異常に受信されたパケットは、失われたパケット、破棄されたパケット、重複したパケットの3つのタイプに分類されます。パケット損失は、ネットワークデバイスの故障、ビットエラーの破損、またはネットワークの輻輳（中間ルーターキューによってドロップされたパケット）が原因である可能性があります。パケットの重複は、送信者が元のパケットを再送信する原因となるネットワーク遅延の結果である可能性があります。破棄されたパケットは、十分に遅延している（おそらく、再生時間を逃した）パケットであり、受信側では役に立たないと見なされます。失われたパケットと破棄されたパケットは、マルチメディアサービスに問題を引き起こします。これは、データの欠落と長い遅延がサービス品質の低下を引き起こす可能性があるためです。たとえば、連続したパケットの大きなブロックの欠落（失われたか破棄された）は音声が途切れる可能性があり、ネットワーク伝送の遅延時間が長いと音声が発生する可能性がありますまたはビデオバッファリング。 RTCP SR / RRは、受信の開始以降に失われたRTPデータパケットの総数をカウントするためのメトリックを定義します。ただし、この統計では、失われたパケットと破棄されたパケットや重複したパケットを区別しません。遅れて到着したパケットは破棄され、失われたとは報告されず、重複したパケットは正常に受信されたパケットと見なされます。したがって、ユーザーが実際に悪いサービス品質を経験している間、多くの重複パケットが受信されるか、パケットが破棄される場合、損失メトリックは誤解を招く可能性があり、メディアトランスポートの品質は統計的な観点からは問題ないように見えます。そのため、そのような場合は、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]のStatistics Summary Report Blockで定義された損失パケットと重複パケットのメトリックは、標準のRTCP SR / RRで伝送される損失の情報を拡張します。失われたパケットと重複したパケットのアカウントを明示的に提供します。パケット損失数は、ネットワークの問題の診断に役立ちます。 [RFC3550]のパケット損失メトリックの累積数ではなく、[RFC3611]のパケット損失メトリックを使用して、損失パケット数を示すことをお勧めします。重複パケットは通常まれであり、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アプリケーションで使用する2つの新しいレポートブロックを定義します。これらのメトリックは、破棄されたパケットをバースト期間に発生する損失パケットと区別し、ネットワークの問題を診断するための詳細情報を提供します。さらに、ブロックはバーストイベントの頻度を報告します。これは、エクスペリエンスの質を評価するのに役立つ情報です。したがって、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アプリケーションは、追加情報の恩恵を受けることができます。破棄後に損失が発生した場合、エンドポイントは2つのランレングスベクトルを相関させて、輻輳関連の損失を特定できる場合があります。たとえば、ルーターキューが過負荷になり、遅延が発生してオーバーフローした場合などです。損失が独立している場合は、ビットエラーの破損を示している可能性があります。 WebRTC Stats 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の場合、破棄されたオクテットメトリックは送受信オクテットのメトリックを補足し、実際のビットレートを計算する正確な方法を提供します。これは、メディアの品質を反映する重要なパラメーターです。 Bytes Discardedメトリックは[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パケットに1つまたは複数のオーディオフレームが含まれる場合があります。一方、ビデオストリームでは、単一のビデオフレームが複数のRTPパケットで送信される場合があります。各パケットのサイズは、基盤となるネットワークの最大転送単位（MTU）によって制限されます。ただし、標準SR / RRからの統計はトランスポート層からの情報のみを収集するため、アプリケーションによって観察された品質を完全に反映していない場合があります。ビデオは通常、2つのフレームタイプ、つまりキーフレームと派生フレームを使用してエンコードされます。キーフレームは通常、空間的に圧縮されるだけです。つまり、他の画像からの予測はありません。導出されたフレームは、時間的に圧縮される、すなわち、復号化のためのキーフレームに依存する。したがって、キーフレームのサイズは派生フレームよりもはるかに大きくなります。これらのキーフレームが失われると、ビデオ品質が大幅に低下します。したがって、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 [RFC4445]のメディア損失率（MLR）を計算するために使用できます。これらのメトリックの定義の詳細は、[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 calculate estimated MOS values. Thus, for those cases, jitter buffer metrics should be considered. The definition of these metrics is provided in [RFC7005].
ジッタバッファのサイズは、ネットワークのエンドツーエンドの遅延とパケット廃棄率にも影響します。バッファサイズが小さすぎると、遅く到着したパケットは再生されずにドロップされます。バッファサイズが大きすぎると、パケットが必要以上に長く保持されるため、会話の品質が低下します。ジッタ品質の測定は、エンドユーザーの会話品質の評価において無視されるべきではありません。最大および公称ジッタバッファなど、ジッタバッファに関連するメトリックを使用して、受信エンドポイントでのジッタバッファの動作を示すことができます。推定MOS値を計算するための入力としてジッターバッファーファクターを使用する場合、エンドユーザーのエクスペリエンスの品質（QoE）を向上させるのに役立ちます。したがって、それらのケースでは、ジッタバッファメトリックを考慮する必要があります。これらのメトリックの定義は、[RFC7005]で提供されています。
This document does not consider concealment metrics [RFC7294] as part of recovery metrics.
このドキュメントでは、隠蔽メトリック[RFC7294]を回復メトリックの一部として考慮していません。
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-USAGE]で指定された推奨事項に従って、特定の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の場合、アプリケーションは追加情報の恩恵を受ける可能性があります。破棄後に損失が発生した場合、エンドポイントは2つのランレングスベクトルを相関させて、輻輳関連の損失を特定できる場合があります。損失が独立している場合は、ビットエラーの破損を示している可能性があります。最後に、エラー耐性メカニズムを使用する場合、エンドポイントは、損失と修復後の実行時間を相関させて、間隔内のどこで損失と修復が発生したかを確認できます。たとえば、連続した損失は単純な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で定義されます。実際には、アプリケーションは、着信（リモート）と発信（ローカル）の両方のメディアストリームの統計識別子をクエリできる必要があります。 SRおよびRRの送受信は必須であるため、SRおよびRRで定義されたメトリックは常に使用可能です。 XRメトリックの場合、それは2つの要因に依存します。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].
名前：packetsSent定義：[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].
名前：packetsReceived定義：[RFC3550]のセクション6.4.1。
Name: bytesReceived Definition: Section 6.4.1 of [RFC3550].
名前：bytesReceived定義：[RFC3550]のセクション6.4.1。
Name: packetsLost Definition: Section 6.4.1 of [RFC3550].
名前：packetsLost定義：[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].
名前：gapLossRate定義：ギャップ中に失われた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].
名前：framesCorrupted定義：部分的に失われたフレームの累積数。 [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.
名前：framesSent定義：送信されたフレームの累積数。
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-USAGE]および[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：A Transport Protocol for Real-Time Applications」、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]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年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）拡張レポート（XR）の修復後の損失RLEレポートブロックタイプ」、RFC 5725、DOI 10.17487 / RFC5725、2月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>.
[RFC6776]クラークA.およびQ.ウー、「ソース記述（SDES）アイテムとRTCP拡張レポート（XR）ブロックを使用した測定IDおよび情報レポート」、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、編、「バースト/ギャップロスメトリックレポート用の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 Control Protocol（RTCP）Extended Report（XR）Block for Discard Count Metric Reporting」、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、編、「バースト/ギャップ破棄メトリックレポート用の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 Control Protocol（RTCP）Extended Report（XR）Blocks for Summary Statistics Metrics Reporting」、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 Control Protocol（RTCP）Extended Report（XR）Block for De-Jitter Buffer Metric Reporting」、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、「RTP Control Protocol（RTCP）Extended Report（XR）for RLE of Discarded Packets」、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 Control Protocol（RTCP）Extended Report（XR）Block for the Bytes Discarded Metrics」、RFC 7243、DOI 10.17487 / RFC7243、5月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>.
[RFC7509] Huang、R。およびV. Singh、「RTP Control Protocol（RTCP）Extended Report（XR）for Post-Repair Loss Count Metrics」、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.1、2016年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、「A Proposed Media Delivery Index（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-Overview] Alverstrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-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-USAGE] Perkins、C.、Westerlund、M.、J。Ott、「Web Real-Time Communication（WebRTC）：Media Transport and Use of RTP」、Work in Progress、draft-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のセキュリティに関する考慮事項」、進行中の作業、draft-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.、Hakansson、S。、およびG. Eriksson、「Web Real-Time Communication Use Cases and Requirements」、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-stats] Alvestrand、H。およびV. Singh、「Identifiers for WebRTC's Statistics API」、W3C Candidate Recommendation、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 Helsinki 00100 Finland
Email: varun@callstats.io
URI: https://www.callstats.io/about
Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China
Rachel Huang hu Aは101ソフトウェアアベニュー、Y Uは地区NaNjing 210012中国を描画
Email: rachel.huang@huawei.com
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
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