[要約] RFC 8015は、RTP制御プロトコル（RTCP）拡張レポート（XR）ブロックに関するもので、バースト/ギャップの破棄メトリックの独立した報告を可能にします。このRFCの目的は、ネットワークの品質を評価するための正確なデータを提供することです。
Internet Engineering Task Force (IETF) V. Singh
Request for Comments: 8015 callstats.io
Category: Standards Track C. Perkins
ISSN: 2070-1721 University of Glasgow
A. Clark
Telchemy
R. Huang
Huawei
November 2016
RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics
バースト/ギャップ破棄メトリックの独立したレポートのためのRTP制御プロトコル（RTCP）拡張レポート（XR）ブロック
Abstract
概要
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications.
このドキュメントでは、RTP制御プロトコル（RTCP）拡張レポート（XR）ブロックを定義して、一連のRTPアプリケーションで使用するためのバースト/ギャップ損失メトリックとは無関係に、バースト/ギャップ廃棄メトリックをレポートできるようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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 http://www.rfc-editor.org/info/rfc8015.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8015で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Independent Burst/Gap Discard Metrics Block . . . . . . . 3
1.2. RTCP and RTCP Extended Reports . . . . . . . . . . . . . 4
1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Independent Burst/Gap Discard Metrics Block . . . . . . . . . 5
3.1. Report Block Structure . . . . . . . . . . . . . . . . . 6
3.2. Definition of Fields in the Independent Burst/Gap Discard
Metrics Block . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Derived Metrics Based on the Reported Metrics . . . . . . 8
4. Considerations for Voice-over-IP Applications . . . . . . . . 9
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. SDP rtcp-xr Attribute Extension . . . . . . . . . . . . . 9
5.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . 10
6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 10
6.3. Contact Information for Registrations . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Metrics Represented Using the Template from RFC 6390 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
This document defines a new block type that extends the metrics defined in [RFC7003]. The new block type reports the proportion of packets discarded in a burst by the de-jitter buffer at the receiver. The number of packets discarded depends on the de-jitter buffer algorithm implemented by the endpoint.
このドキュメントは、[RFC7003]で定義されたメトリックを拡張する新しいブロックタイプを定義します。新しいブロックタイプは、レシーバのデジッタバッファによってバーストで破棄されたパケットの割合を報告します。廃棄されるパケットの数は、エンドポイントによって実装されるデジッタバッファアルゴリズムによって異なります。
The new report block defined in this document is different from the one defined in [RFC7003]. The metrics in [RFC7003] depend on the metrics in the burst/gap loss metric defined in [RFC6958]. Consequently, an endpoint that sends a Burst/Gap Discard Metrics Block [RFC7003] also needs to send a Burst/Gap Loss Metrics Block [RFC6958]. The combined usage is useful when an endpoint observes correlated packet losses and discard. However, when the burst of packet losses and discards do not occur simultaneously, the application could prefer to send a concise report block that just reports the burst/gap of discarded packets. The report block in this document provides the complete information and does not require additional report blocks. That is, this block reports the total number of packets discarded, the total burst duration, and the total number of bursts. All of these metrics are missing in [RFC7003].
このドキュメントで定義されている新しいレポートブロックは、[RFC7003]で定義されているものとは異なります。 [RFC7003]のメトリックは、[RFC6958]で定義されたバースト/ギャップロスメトリックのメトリックに依存します。したがって、バースト/ギャップ破棄メトリックブロック[RFC7003]を送信するエンドポイントも、バースト/ギャップ損失メトリックブロック[RFC6958]を送信する必要があります。組み合わせた使用法は、エンドポイントが相関するパケット損失を観察して破棄する場合に役立ちます。ただし、パケット損失と廃棄のバーストが同時に発生しない場合、アプリケーションは、廃棄されたパケットのバースト/ギャップをレポートするだけの簡潔なレポートブロックを送信することを選択できます。このドキュメントのレポートブロックは完全な情報を提供し、追加のレポートブロックを必要としません。つまり、このブロックは、破棄されたパケットの総数、合計バースト期間、およびバーストの総数を報告します。これらのメトリックはすべて[RFC7003]にありません。
This block provides information on transient network issues. Burst/ gap metrics are typically used in cumulative reports; however, they can also be used in interval reports (see the Interval Metric flag in Section 3.2). The variation in the number of packet discards in a burst affects the user experience. Based on the metrics reported in the block, the sending endpoint can change the packetization interval, vary the bitrate, etc. The report can additionally be used for diagnostics [RFC6792]. The metric belongs to the class of transport-related end-system metrics defined in [RFC6792].
このブロックは、一時的なネットワークの問題に関する情報を提供します。バースト/ギャップメトリックは通常、累積レポートで使用されます。ただし、間隔レポートでも使用できます（セクション3.2の間隔メトリックフラグを参照）。バーストでのパケット廃棄数の変動は、ユーザーエクスペリエンスに影響します。ブロックで報告されたメトリックに基づいて、送信側エンドポイントはパケット化間隔を変更したり、ビットレートを変更したりできます。レポートはさらに診断[RFC6792]に使用できます。このメトリックは、[RFC6792]で定義されているトランスポート関連のエンドシステムメトリックのクラスに属しています。
The definitions of "burst", "gap", "loss", and "discard" are consistent with the definitions in [RFC3611]. To accommodate a range of de-jitter buffer algorithms and packet discard logic that can be used by implementers, the method used to distinguish between bursts and gaps uses an equivalent method to that defined in Section 4.7.2 of [RFC3611]. Note that reporting the specific de-jitter buffer algorithm and/or the packet discard logic is out of the scope of this document.
「バースト」、「ギャップ」、「損失」、および「廃棄」の定義は、[RFC3611]の定義と一致しています。実装者が使用できるさまざまなデジッタバッファアルゴリズムとパケット破棄ロジックに対応するために、バーストとギャップを区別するために使用される方法は、[RFC3611]のセクション4.7.2で定義されているものと同等の方法を使用します。特定のデジッタバッファアルゴリズムまたはパケット廃棄ロジック、あるいはその両方を報告することは、このドキュメントの範囲外であることに注意してください。
The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] defined an extensible structure for reporting using an RTCP Extended Report (XR). This document defines a new Extended Report block for use with [RFC3550] and [RFC3611].
レポートのためのRTCPの使用は、[RFC3550]で定義されています。 [RFC3611]は、RTCP拡張レポート（XR）を使用してレポートするための拡張可能な構造を定義しました。このドキュメントは、[RFC3550]と[RFC3611]で使用するための新しいExtended Reportブロックを定義します。
The Performance Metrics Framework [RFC6390] provides guidance on the definition and specification of performance metrics. The RTP Monitoring Framework [RFC6792] provides guidelines for reporting the block format using RTCP XR. The metrics block described in this document is in accordance with the guidelines in [RFC6390] and [RFC6792].
パフォーマンスメトリックフレームワーク[RFC6390]は、パフォーマンスメトリックの定義と仕様に関するガイダンスを提供します。 RTP監視フレームワーク[RFC6792]は、RTCP XRを使用してブロック形式を報告するためのガイドラインを提供します。このドキュメントで説明されているメトリックブロックは、[RFC6390]および[RFC6792]のガイドラインに準拠しています。
These metrics are applicable to a range of RTP applications that contain de-jitter buffers at the receiver to smooth variation in packet-arrival time and don't use stream repair means, e.g., Forward Error Correction (FEC) [FLEX_FEC] and/or retransmission [RFC4588].
これらのメトリックは、パケット到着時間の変動を平滑化するためにレシーバーにデジッタバッファーを含み、ストリーム修復手段を使用しない一連のRTPアプリケーションに適用できます。たとえば、Forward Error Correction（FEC）[FLEX_FEC]および/または再送信[RFC4588]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In addition, the following terms are defined:
さらに、次の用語が定義されています。
Received, Lost, and Discarded
受け取り、紛失、破棄
A packet is regarded as "lost" if it fails to arrive within an implementation-specific time window. A packet that arrives within this time window but is too early to be played out, too late to be played out, or thrown away before playout due to packet duplication or redundancy is be recorded as "discarded". A packet SHALL NOT be regarded as "discarded" if it arrives within this time window but is dropped during decoding by some higher-layer decoder, e.g., due to a decoding error. Each packet is classified as one of "received" (or "OK"), "discarded", or "lost". The metric "cumulative number of packets lost" defined in [RFC3550] reports a count of packets lost from the media stream (single synchronization source (SSRC) within a single RTP session). Similarly, the metric "number of packets discarded" defined in [RFC7002] reports a count of packets discarded from the media stream (single SSRC within a single RTP session) arriving at the receiver. Another metric, defined in [RFC5725], is available to report on packets that are not recovered by any repair techniques that are in use. Note that the term "discard" defined here builds on the "discard" definition in [RFC3611] but extends the concept to take into account packet duplication and reports different types of discard counts [RFC7002].
パケットは、実装固有の時間枠内に到着しない場合、「失われた」と見なされます。この時間枠内に到着したが、再生するには早すぎる、再生が遅すぎる、またはパケットの重複または冗長性のために再生前に破棄されたパケットは、「破棄」として記録されます。パケットは、この時間枠内に到着した場合、「破棄された」と見なされるべきではありませんが、たとえば、デコードエラーのために、一部の上位レイヤーデコーダーによってデコード中にドロップされます。各パケットは、「受信」（または「OK」）、「廃棄」、または「紛失」のいずれかに分類されます。 [RFC3550]で定義されているメトリック「失われたパケットの累積数」は、メディアストリーム（単一のRTPセッション内の単一の同期ソース（SSRC））から失われたパケットの数を報告します。同様に、[RFC7002]で定義されているメトリック「破棄されたパケット数」は、受信機に到着したメディアストリーム（単一のRTPセッション内の単一のSSRC）から破棄されたパケットの数を報告します。 [RFC5725]で定義されている別のメトリックは、使用中の修復技術によって回復されなかったパケットについて報告するために使用できます。ここで定義されている「破棄」という用語は、[RFC3611]の「破棄」定義に基づいていますが、概念を拡張してパケットの重複を考慮し、さまざまな種類の破棄カウント[RFC7002]を報告します。
Bursts and Gaps
バーストとギャップ
The terms "burst" and "gap" are used in a manner consistent with that of RTCP XR [RFC3611]. RTCP XR views an RTP stream as being divided into bursts, which are periods during which the discard rate is high enough to cause noticeable quality degradation (generally a discard rate over 5 percent), and gaps, which are periods during which discarded packets are infrequent, and hence quality is generally acceptable.
「バースト」および「ギャップ」という用語は、RTCP XR [RFC3611]と同じ方法で使用されます。 RTCP XRは、RTPストリームをバーストに分割するものと見なします。バーストは、廃棄率が顕著に品質低下を引き起こすのに十分なほど高い期間（通常は廃棄率が5％を超える）と、廃棄されるパケットがまれにしか発生しない期間です。 、したがって、品質は一般的に許容可能です。
Metrics in this block report on burst/gap discard in the stream arriving at the RTP system. Measurements of these metrics are made at the receiving end of the RTP stream. Instances of this metrics block use the synchronization source (SSRC) to refer to the separate auxiliary Measurement Information Block [RFC6776], which describes measurement periods in use (see [RFC6776], Section 4.2).
このブロックのメトリックは、RTPシステムに到着するストリームのバースト/ギャップ破棄について報告します。これらのメトリックの測定は、RTPストリームの受信側で行われます。このメトリクスブロックのインスタンスは、同期ソース（SSRC）を使用して、使用中の測定期間を説明する個別の補助測定情報ブロック[RFC6776]を参照します（[RFC6776]、セクション4.2を参照）。
This metrics block relies on the measurement period in the Measurement Information Block indicating the span of the report. Senders MUST send this block in the same compound RTCP packet as the Measurement Information Block. Receivers MUST verify that the measurement period is received in the same compound RTCP packet as this metrics block. If not, this metrics block MUST be discarded.
このメトリックブロックは、レポートのスパンを示すMeasurement Information Blockの測定期間に依存しています。送信者は、測定情報ブロックと同じ複合RTCPパケットでこのブロックを送信する必要があります。受信者は、測定期間がこのメトリックブロックと同じ複合RTCPパケットで受信されていることを確認する必要があります。そうでない場合、このメトリックブロックは破棄する必要があります。
The structure of the Independent Burst/Gap Discard Metrics Block is as follows.
Independent Burst / Gap Discard Metricsブロックの構造は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=35 | I | resv | Block Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold | Sum of Burst Durations (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packets Discarded in Bursts | Number of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bursts | Total Packets Expected in Bursts |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Report Block Structure
図1：レポートブロックの構造
3.2. Definition of Fields in the Independent Burst/Gap Discard Metrics Block
3.2. Independent Burst / Gap Discard Metricsブロックのフィールドの定義
Block Type (BT): 8 bits
ブロックタイプ（BT）：8ビット
An Independent Burst/Gap Discard Metrics Block is identified by the constant 35.
Independent Burst / Gap Discard Metricsブロックは、定数35で識別されます。
Interval Metric flag (I): 2 bits
間隔メトリックフラグ（I）：2ビット
This field is used to indicate whether the burst/gap discard metrics are Sampled, Interval, or Cumulative metrics [RFC6792]:
このフィールドは、バースト/ギャップ破棄メトリックが、サンプル、間隔、または累積メトリックであるかどうかを示すために使用されます[RFC6792]：
I=10: Interval Duration - the reported value applies to the most recent measurement interval duration between successive metrics reports.
I = 10：インターバル期間-報告された値は、連続するメトリックレポート間の最新の測定インターバル期間に適用されます。
I=11: Cumulative Duration - the reported value applies to the accumulation period characteristic of cumulative measurements.
I = 11：累積期間-報告された値は、累積測定に特有の累積期間に適用されます。
In this document, burst/gap discard metrics can only be measured over definite intervals and cannot be sampled. Also, the value I=00 is reserved for future use. Senders MUST NOT use the values I=00 or I=01. If a block is received with I=00 or I=01, the receiver MUST discard the block.
このドキュメントでは、バースト/ギャップ破棄メトリックは一定の間隔でのみ測定でき、サンプリングできません。また、値I = 00は将来の使用のために予約されています。送信者は、I = 00またはI = 01の値を使用してはなりません。 I = 00またはI = 01でブロックを受信した場合、受信者はブロックを破棄する必要があります。
Reserved (resv): 6 bits
予約済み（resv）：6ビット
These bits are reserved. They MUST be set to zero by senders and ignored by receivers (see [RFC6709], Section 4.2).
これらのビットは予約されています。送信者はゼロに設定し、受信者は無視する必要があります（[RFC6709]、セクション4.2を参照）。
Block Length: 16 bits
ブロック長：16ビット
The length of this report block in 32-bit words, minus one. For the Independent Burst/Gap Discard Metrics Block, the block length is equal to 5. The block MUST be discarded if the block length is set to a different value.
このレポートブロックの長さ（32ビットワード、マイナス1）。 Independent Burst / Gap Discard Metricsブロックの場合、ブロック長は5です。ブロック長が別の値に設定されている場合、ブロックを破棄する必要があります。
SSRC of Source: 32 bits
ソースのSSRC：32ビット
As defined in Section 4 of [RFC3611].
[RFC3611]のセクション4で定義されています。
Threshold: 8 bits
しきい値：8ビット
The Threshold is equivalent to Gmin in [RFC3611], i.e., the number of successive packets that have to be received prior to, and following, a discarded packet in order for that discarded packet to be regarded as part of a gap. Note that the Threshold is set in accordance with the Gmin calculation defined in Section 4.7.2 of [RFC3611].
しきい値は、[RFC3611]のGminに相当します。つまり、破棄されたパケットをギャップの一部と見なすために、破棄されたパケットの前後に受信する必要がある連続したパケットの数です。しきい値は、[RFC3611]のセクション4.7.2で定義されているGmin計算に従って設定されることに注意してください。
Sum of Burst Durations (ms): 24 bits
バースト期間の合計（ms）：24ビット
The total duration of bursts of discarded packets in the period of the report (Interval or Cumulative).
レポート期間中の破棄されたパケットのバーストの合計期間（間隔または累積）。
The measured value is an unsigned value. If the measured value exceeds 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an over-range measurement. If the measurement is unavailable, the value 0xFFFFFF MUST be reported.
測定値は符号なしの値です。測定値が0xFFFFFDを超える場合、値0xFFFFFEを報告して範囲外の測定を示す必要があります。測定が利用できない場合、値0xFFFFFFを報告する必要があります。
Packets Discarded in Bursts: 24 bits
バーストで破棄されるパケット：24ビット
The total number of packets discarded during discard bursts, as defined in Section 3.2 of [RFC7002].
[RFC7002]のセクション3.2で定義されている、破棄バースト中に破棄されたパケットの総数。
Number of Bursts: 16 bits
バースト数：16ビット
The number of discard bursts in the period of the report (Interval or Cumulative).
レポート期間中の破棄バーストの数（間隔または累積）。
The measured value is an unsigned value. If the measured value exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an over-range measurement. If the measurement is unavailable, the value 0xFFFF MUST be reported.
測定値は符号なしの値です。測定値が0xFFFDを超える場合、値0xFFFEを報告して範囲外の測定を示す必要があります。測定が利用できない場合、値0xFFFFを報告する必要があります。
Total Packets Expected in Bursts: 24 bits
バーストで予想される総パケット数：24ビット
The total number of packets expected during the discard bursts (that is, the sum of received packets and lost packets). The metric is defined in [RFC7003].
廃棄バースト中に予想されるパケットの総数（つまり、受信パケットと損失パケットの合計）。メトリックは[RFC7003]で定義されています。
Discard Count: 32 bits
廃棄カウント：32ビット
Number of packets discarded over the period (Interval or Cumulative) covered by this report, as defined in Section 3.2 of [RFC7002].
[RFC7002]のセクション3.2で定義されている、このレポートの対象となる期間（間隔または累積）で破棄されたパケットの数。
The metrics described here are intended to be used in conjunction with information from the Measurement Information Block [RFC6776].
ここで説明するメトリックは、Measurement Information Block [RFC6776]からの情報と組み合わせて使用することを目的としています。
These metrics provide the following information relevant to statistical parameters (depending on cumulative of interval measures), for example:
これらのメトリックは、たとえば、統計的パラメータに関連する次の情報を提供します（間隔測定の累積に依存）。
o The average discarded burst size, which can be calculated by dividing the metric "Packets Discarded in Bursts" by the "Number of Bursts".
o メトリックの「バーストで破棄されたパケット」を「バーストの数」で除算することで計算できる平均破棄バーストサイズ。
o The average burst duration, which can be calculated by dividing the metric "Sum of Burst Durations (ms)" by the "Number of Bursts".
o メトリック「バースト継続時間の合計（ms）」を「バースト数」で除算して計算できる平均バースト継続時間。
This metrics block is applicable to a broad range of RTP applications. Where the metric is used with a Voice-over-IP (VoIP) application and the stream repair means is not available, the following considerations apply.
このメトリックブロックは、幅広いRTPアプリケーションに適用できます。メトリックがVoice-over-IP（VoIP）アプリケーションで使用され、ストリーム修復手段が利用できない場合は、次の考慮事項が適用されます。
RTCP XR views a call as being divided into bursts, which are periods during which the discard rate is high enough to cause noticeable call quality degradation (generally a discard rate over 5 percent) and gaps, which are periods during which discarded packets are infrequent, and hence call quality is generally acceptable.
RTCP XRは、コールをバーストに分割するものと見なします。バーストは、廃棄率が十分に高く、顕著な通話品質の低下を引き起こします（通常、廃棄率は5％を超えます）。ギャップは、廃棄されるパケットの頻度が低い期間です。したがって、通話品質は一般的に許容範囲です。
If voice activity detection is used, the burst/gap duration is determined as if silence packets had been sent, i.e., a period of silence in excess of Gmin packets will terminate a burst condition.
音声アクティビティ検出が使用される場合、バースト/ギャップ期間は、無音パケットが送信されたかのように決定されます。つまり、Gminパケットを超える無音期間により、バースト状態が終了します。
The RECOMMENDED value for the threshold Gmin in [RFC3611] results in a burst being a period of time during which the call quality is degraded to a similar extent to a typical pulse code modulation (PCM) severely errored second.
[RFC3611]のしきい値Gminの推奨値により、バーストは、通常のパルスコード変調（PCM）の深刻なエラーが発生した秒と同じ程度に通話品質が低下する期間になります。
[RFC3611] defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of XR blocks. XR blocks can be used without prior signaling.
[RFC3611]は、XRブロックの使用を通知するためのSDP（Session Description Protocol）[RFC4566]の使用を定義しています。 XRブロックは、事前のシグナリングなしで使用できます。
This section augments the SDP [RFC4566] attribute "rtcp-xr" defined in [RFC3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document. The ABNF [RFC5234] syntax is as follows.
このセクションでは、[RFC3611]で定義されているSDP [RFC4566]属性「rtcp-xr」を拡張して、このドキュメントで定義されているレポートブロックの使用を通知する「xr-format」の追加の値を提供します。 ABNF [RFC5234]の構文は次のとおりです。
xr-format =/ xr-ind-bgd-block
xr-format = / xr-ind-bgd-block
xr-ind-bgd-block = "ind-burst-gap-discard"
xr-ind-bgd-block = "ind-burst-gap-discard"
When SDP is used in Offer/Answer context, the SDP Offer/Answer usage defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters applies. For detailed usage in Offer/Answer for unilateral parameters, refer to Section 5.2 of [RFC3611].
SDPがオファー/アンサーコンテキストで使用される場合、片側の「rtcp-xr」属性パラメーターに対して[RFC3611]で定義されたSDPオファー/アンサー使用法が適用されます。片側パラメーターのオファー/アンサーでの使用法の詳細については、[RFC3611]のセクション5.2を参照してください。
New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, refer to [RFC3611].
RTCP XRの新しいブロックタイプは、IANA登録の対象です。 RTCP XRに関するIANAの考慮事項に関する一般的なガイドラインについては、[RFC3611]を参照してください。
This document assigns the block type value 35 in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "Independent Burst/Gap Discard Metrics Block".
このドキュメントでは、IANA「RTP Control Protocol Extended Reports（RTCP XR）Block Type Registry」のブロックタイプ値35を「Independent Burst / Gap Discard Metrics Block」に割り当てています。
This document also registers a new parameter "ind-burst-gap-discard" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry".
このドキュメントでは、「RTP制御プロトコル拡張レポート（RTCP XR）セッション記述プロトコル（SDP）パラメータレジストリ」に新しいパラメータ「ind-burst-gap-discard」も登録しています。
The contact information for the registrations is:
登録の連絡先情報は次のとおりです。
ART Area Directors <art-ads@ietf.org>
This block does not provide per-packet statistics, so the risk to confidentiality documented in Section 7, paragraph 3 of [RFC3611] does not apply. However, the gap indicated within this block could be used to detect the timing of other events on the path between the sender and receiver. For example, a competing multimedia stream might cause a discard burst for the duration of the stream, allowing the receiver of this block to know when the competing stream was active. This risk is not a significant threat since the only information leaked is the timing of the discard, not the cause.
このブロックはパケットごとの統計を提供しないため、[RFC3611]のセクション7、パラグラフ3に記載されている機密性へのリスクは適用されません。ただし、このブロック内に示されているギャップは、送信側と受信側の間のパス上の他のイベントのタイミングを検出するために使用できます。たとえば、競合するマルチメディアストリームにより、ストリームの期間中に破棄バーストが発生し、このブロックの受信者が競合するストリームがいつアクティブであったかを知ることができます。流出する情報は破棄のタイミングであり、原因ではないため、このリスクは重大な脅威ではありません。
Where this is a concern, the implementation SHOULD apply encryption and authentication to this report block. For example, this can be achieved by using the Audio-Visual Profile with Feedback (AVPF) profile together with the Secure RTP profile, as defined in [RFC3711]; an appropriate combination of those two profiles ("SAVPF") is specified in [RFC5124]. Besides this, it is believed that this RTCP XR block introduces no new security considerations beyond those described in [RFC3611].
これが懸念される場合、実装はこのレポートブロックに暗号化と認証を適用する必要があります（SHOULD）。たとえば、これは、[RFC3711]で定義されているように、Secure RTPプロファイルとともにフィードバック付きのAVプロファイル（AVPF）プロファイルを使用することで実現できます。これら2つのプロファイルの適切な組み合わせ（「SAVPF」）は、[RFC5124]で指定されています。これに加えて、このRTCP XRブロックは、[RFC3611]で説明されているものを超える新しいセキュリティの考慮事項を導入しないと考えられています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[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, <http://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月、 <http://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, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[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, <http://www.rfc-editor.org/info/rfc5725>.
[RFC5725] Begen、A.、Hsu、D。、およびM. Lague、「RTP制御プロトコル（RTCP）拡張レポート（XTCP）の修復後の損失RLEレポートブロックタイプ」、RFC 5725、DOI 10.17487 / RFC5725、2月2010、<http://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, <http://www.rfc-editor.org/info/rfc6776>.
[RFC6776]クラークA.およびQ.ウー、「ソース記述（SDES）アイテムとRTCP拡張レポート（XR）ブロックを使用した測定IDおよび情報レポート」、RFC 6776、DOI 10.17487 / RFC6776、2012年10月、<http ：//www.rfc-editor.org/info/rfc6776>。
[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, <http://www.rfc-editor.org/info/rfc7003>.
[RFC7003] Clark、A.、Huang、R。、およびQ. Wu、編、「バースト/ギャップ破棄メトリックレポート用のRTP制御プロトコル（RTCP）拡張レポート（XR）ブロック」、RFC 7003、DOI 10.17487 / RFC7003 、2013年9月、<http://www.rfc-editor.org/info/rfc7003>。
[FLEX_FEC] Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", Work in Progress, draft-ietf-payload-flexible-fec-scheme-03, October 2016.
[FLEX_FEC] Singh、V.、Begen、A.、Zanaty、M。、およびG. Mandyam、「柔軟な前方誤り訂正（FEC）のRTPペイロード形式」、作業中、draft-ietf-payload-flexible-fec -scheme-03、2016年10月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<http：/ /www.rfc-editor.org/info/rfc4588>。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.
[RFC6390]クラークA.およびB.クレイズ、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、DOI 10.17487 / RFC6390、2011年10月、<http://www.rfc-editor.org/info / rfc6390>。
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709] Carpenter、B.、Aboba、B.、Ed。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、DOI 10.17487 / RFC6709、2012年9月、<http：//www.rfc-editor .org / info / rfc6709>。
[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, <http://www.rfc-editor.org/info/rfc6792>.
[RFC6792] Wu、Q.、Ed。、Hunt、G。、およびP. Arden、「RTPモニタリングフレームワークの使用に関するガイドライン」、RFC 6792、DOI 10.17487 / RFC6792、2012年11月、<http：// 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, <http://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月、<http://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, <http://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月、< http://www.rfc-editor.org/info/rfc7002>。
a. Threshold Metric
a. しきい値メトリック
* Defined in item a of Appendix A of [RFC7003].
* [RFC7003]の付録Aの項目aで定義されています。
b. Sum of Burst Durations (ms)
b. バースト期間の合計（ミリ秒）
* Metric Name: Sum of Burst Durations with Discarded RTP Packets.
* メトリック名：RTPパケットが破棄されたバースト期間の合計。
* Metric Description: The total duration of bursts of discarded RTP packets in the period of the report.
* メトリックの説明：レポート期間中に破棄されたRTPパケットのバーストの合計期間。
* Method of Measurement or Calculation: See Section 3.2, Sum of Burst Durations definition.
* 測定または計算の方法：セクション3.2、バースト期間の合計の定義を参照してください。
* Units of Measurement: See Section 3.2, Sum of Burst Durations definition.
* 測定単位：セクション3.2、バースト期間の合計の定義を参照してください。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, first paragraph.
* 潜在的な測定ドメインを持つ測定ポイント：セクション3の最初の段落を参照してください。
* Measurement Timing: See Section 3, second paragraph for measurement timing and Section 3.2 for Interval Metric flag.
* 測定タイミング：測定タイミングについてはセクション3の2番目の段落、インターバルメトリックフラグについてはセクション3.2を参照してください。
* Use and Applications: See Section 1.4.
* 使用およびアプリケーション：セクション1.4を参照してください。
* Reporting Model: See [RFC3611].
* レポートモデル：[RFC3611]を参照してください。
c. Packets Discarded in Bursts Metric
c. バーストメトリックで破棄されたパケット
* Defined in item b of Appendix A of [RFC7003].
* [RFC7003]の付録Aの項目bで定義されています。
d. Number of Bursts
d. バースト数
* Metric Name: Number of discard bursts in RTP.
* メトリック名：RTPの破棄バーストの数。
* Metric Description: The total number of bursts with discarded RTP packets in the period of the report.
* メトリックの説明：レポート期間中にRTPパケットが破棄されたバーストの総数。
* Method of Measurement or Calculation: See Section 3.2, Number of Bursts definition.
* 測定または計算の方法：セクション3.2、バースト数の定義を参照してください。
* Units of Measurement: See Section 3.2 for the Number of Bursts definition.
* 測定単位：バースト数の定義については、セクション3.2を参照してください。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, first paragraph.
* 潜在的な測定ドメインを持つ測定ポイント：セクション3の最初の段落を参照してください。
* Measurement Timing: See Section 3, second paragraph for measurement timing and Section 3.2 for Interval Metric flag.
* 測定タイミング：測定タイミングについてはセクション3の2番目の段落、インターバルメトリックフラグについてはセクション3.2を参照してください。
* Use and Applications: See Section 1.4.
* 使用およびアプリケーション：セクション1.4を参照してください。
* Reporting Model: See [RFC3611].
* レポートモデル：[RFC3611]を参照してください。
e. Total Packets Expected in Bursts Metric
e. バーストメトリックで予想される合計パケット
* Defined in item c of Appendix A of [RFC7003].
* [RFC7003]の付録Aの項目cで定義されています。
f. Discard Count
f. 廃棄数
* Defined in Appendix A of [RFC7002].
* [RFC7002]の付録Aで定義されています。
Acknowledgments
謝辞
The authors would like to thank Ben Campbell, Stephen Farrell, Paul Kyzivat, Shucheng LIU, Jan Novak, and Dan Romascanu for providing valuable feedback on this document.
このドキュメントに関する貴重なフィードバックを提供してくれたベンキャンベル、スティーブンファレル、ポールキジバット、シュチェンLIU、ヤンノバク、ダンロマスカヌに感謝します。
Contributors
貢献者
Qin Wu, Rachel Huang, and Alan Clark wrote RFC 7003, which this document extends.
Qin Wu、Rachel Huang、およびAlan ClarkがRFC 7003を作成し、このドキュメントが拡張されました。
Authors' Addresses
著者のアドレス
Varun Singh CALLSTATS I/O Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland
Varun Singh CALLSTATS I / O Oy Runeberginkatu 4c A 4ヘルシンキ00100フィンランド
Email: varun@callstats.io
URI: https://www.callstats.io/about
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
コリン・パーキンスグラスゴー大学コンピューティングサイエンススクールグラスゴーG12 8QQイギリス
Email: csp@csperkins.org
Alan Clark Telchemy Incorporated 2905 Premiere Parkway, Suite 280 Duluth, GA 30097 United States of America
Alan Clark Telchemy Incorporated 2905 Premiere Parkway、Suite 280 Duluth、GA 30097アメリカ合衆国
Email: alan.d.clark@telchemy.com
Rachel Huang Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Rachel Huang hu A is Technologies co。、Ltd. 101ソフトウェアアベニュー、Y U塗装区NaN京、江蘇210012中国
Email: Rachel@huawei.com