[要約] RFC 6798は、パケット遅延変動メトリックの報告に使用されるRTP制御プロトコル（RTCP）拡張レポート（XR）ブロックに関するものです。このRFCの目的は、ネットワークのパフォーマンスを評価するためにパケット遅延変動メトリックを提供することです。
Internet Engineering Task Force (IETF) A. Clark
Request for Comments: 6798 Telchemy
Category: Standards Track Q. Wu
ISSN: 2070-1721 Huawei
November 2012
RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting
RTP Control Protocol（RTCP）Extended Report（XR）Block for Packet Delay Variation Metric Reporting
Abstract
概要
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for 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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション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/rfc6798.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6798で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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. Packet Delay Variation Metrics Block .......................3
1.2. RTCP and RTCP XR Reports ...................................3
1.3. Performance Metrics Framework ..............................3
1.4. Applicability ..............................................3
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
2.2. Notations ..................................................4
3. Packet Delay Variation Metrics Block ............................4
3.1. Report Block Structure .....................................5
3.2. Definition of Fields in PDV Metrics Block ..................5
3.3. Guidance on Use of PDV Metrics .............................8
3.4. Examples of Use ............................................9
4. SDP Signaling ...................................................9
5. IANA Considerations ............................................10
5.1. New RTCP XR Block Type Value ..............................10
5.2. New RTCP XR SDP Parameter .................................10
5.3. Contact Information for Registrations .....................11
5.4. New Registry of PDV Types .................................11
6. Security Considerations ........................................11
7. Contributors ...................................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
This document defines a new block type to augment those defined in [RFC3611], for use in a range of RTP applications.
このドキュメントでは、さまざまなRTPアプリケーションで使用するために、[RFC3611]で定義されたものを補強する新しいブロックタイプを定義します。
The new block type provides information on Packet Delay Variation (PDV) using one of several standard metrics, for example, Mean Absolute Packet Delay Variation 2 (MAPDV2) (Clause 6.2.3.2 of [G.1020]) or 2-point PDV (Clause 6.2.4 of [Y.1540]).
新しいブロックタイプは、平均絶対パケット遅延変動2（MAPDV2）（[G.1020]の6.2.3.2項）または2ポイントPDV（ [Y.1540]の6.2.4節）。
The metrics belong to the class of transport metrics defined in [MONARCH].
メトリックは、[MONARCH]で定義されているトランスポートメトリックのクラスに属しています。
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 architectures [MONARCH] provides guidelines for reporting block format using RTCP XR. The XR block described in this document is in accordance with the guidelines in [RFC6390] and [MONARCH].
パフォーマンスメトリックフレームワーク[RFC6390]は、パフォーマンスメトリックの定義と仕様に関するガイダンスを提供します。 RTP監視アーキテクチャ[MONARCH]は、RTCP XRを使用してブロック形式を報告するためのガイドラインを提供します。このドキュメントで説明されているXRブロックは、[RFC6390]および[MONARCH]のガイドラインに準拠しています。
These metrics are applicable to a wide range of RTP applications in which the application streams are sensitive to delay variation [RFC5481]. For example, applications could use the measurements of these metrics to help adjust the size of adaptive jitter buffers to improve performance. Network managers can use these metrics to compare actual delay variation to targets (i.e., a numerical objective or Service Level Agreement) to help ensure the quality of real-time application performance.
これらのメトリックは、アプリケーションストリームが遅延変動の影響を受けやすい幅広いRTPアプリケーションに適用できます[RFC5481]。たとえば、アプリケーションはこれらのメトリックの測定値を使用して、適応ジッターバッファーのサイズを調整し、パフォーマンスを向上させることができます。ネットワーク管理者は、これらのメトリックを使用して、実際の遅延変動をターゲット（数値目標またはサービスレベルアグリーメント）と比較して、リアルタイムのアプリケーションパフォーマンスの品質を確保できます。
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]で説明されているように解釈されます。
This report block makes use of binary fractions. The terminology used is
このレポートブロックは、2進分数を使用します。使用される用語は
Numeric formats S X:Y
数値形式S X：Y
where S indicates a two's complement signed representation, X the number of bits prior to the decimal place, and Y the number of bits after the decimal place.
ここで、Sは2の補数の符号付き表現、Xは小数点以下のビット数、Yは小数点以下のビット数を示します。
Hence, 8:8 represents an unsigned number in the range 0.0 to 255.996 with a granularity of 0.0039. S7:8 represents the range -127.996 to +127.996. 0:16 represents a proper binary fraction with range as follows:
したがって、8：8は0.039の粒度で0.0から255.996の範囲の符号なし数値を表します。 S7：8は-127.996〜+127.996の範囲を表します。 0:16は、次の範囲を持つ適切な2進数の小数を表します。
0.0 to 1 - 1/65536 = 0.9999847
however, note that use of flag values at the top of the numeric range slightly reduces this upper limit. For example, if the 16-bit values 0xfffe and 0xffff are used as flags for "over-range" and "unavailable" conditions, a 0:16 quantity has a range as follows:
ただし、数値範囲の最上部でフラグ値を使用すると、この上限がわずかに減少することに注意してください。たとえば、16ビット値0xfffeおよび0xffffが「over-range」および「unavailable」条件のフラグとして使用されている場合、0：16数量には次のような範囲があります。
0.0 to 1 - 3/65536 = 0.9999542
Metrics in this block report on packet delay variation in the stream arriving at the RTP system. The measurement of these metrics is made at the receiving end of the RTP stream. Instances of this metric block refer by synchronization source (SSRC) to the separate auxiliary Measurement Information Block [RFC6776], which contains measurement intervals. This metric block relies on the measurement interval given by the value of the "Measurement Duration (Interval)" field in the Measurement Information Block to indicate the span of the report and MUST be sent in the same compound RTCP packet as the Measurement Information Block. If the measurement interval is not received for this metric block, this metric block MUST be discarded.
このブロックのメトリックは、RTPシステムに到着するストリームのパケット遅延変動について報告します。これらのメトリックの測定は、RTPストリームの受信側で行われます。このメトリックブロックのインスタンスは、同期ソース（SSRC）によって、測定間隔を含む個別の補助測定情報ブロック[RFC6776]を参照します。このメトリックブロックは、Measurement Information Blockの「Measurement Duration（Interval）」フィールドの値によって指定される測定間隔に依存してレポートのスパンを示し、Measurement Information Blockと同じ複合RTCPパケットで送信する必要があります。このメトリックブロックの測定間隔が受信されない場合、このメトリックブロックを破棄する必要があります。
PDV metrics block:
PDVメトリックブロック：
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=15 | I |pdvtyp |Rsv| block length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pos PDV Threshold/Peak | Pos PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neg PDV Threshold/Peak | Neg PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean PDV | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Report Block Structure
図1：レポートブロックの構造
Block type (BT): 8 bits
ブロックタイプ（BT）：8ビット
A Packet Delay Variation Metrics Block is identified by the constant 15.
パケット遅延変動メトリックブロックは、定数15で識別されます。
Interval Metric flag (I): 2 bit
間隔メトリックフラグ（I）：2ビット
This field is used to indicate whether the Packet Delay Variation metrics are Sampled, Interval, or Cumulative metrics [MONARCH], that is, whether the reported values apply to the most recent measurement interval duration between successive metrics reports (I=10) (the Interval Duration), or they apply to the accumulation period characteristic of cumulative measurements (I=11) (the Cumulative Duration), or they are a sampled instantaneous value (I=01) (Sampled Value). The value I=00 is reserved and MUST NOT be used. If the value I=00 is received, then the XR block MUST be ignored by the receiver.
このフィールドは、パケット遅延変動メトリックがサンプル、間隔、または累積メトリック[MONARCH]であるかどうか、つまり、報告された値が連続するメトリックレポート間の最新の測定間隔期間（I = 10）に適用されるかどうかを示すために使用されます（I = 10）（インターバル期間）、またはそれらは累積測定の累積期間特性に適用されます（I = 11）（累積期間）、またはそれらはサンプリングされた瞬時値（I = 01）（サンプル値）です。値I = 00は予約されており、使用してはなりません。値I = 00が受信された場合、XRブロックは受信者によって無視されなければなりません（MUST）。
Packet Delay Variation Metric Type (pdvtyp): 4 bits
パケット遅延変動メトリックタイプ（pdvtyp）：4ビット
Packet Delay Variation Metric Type is of type enumerated and is interpreted as an unsigned, 4-bit integer. This field is used to identify the Packet Delay Variation Metric Type used in this report block, according to the following code:
パケット遅延変動メトリックタイプは列挙型であり、符号なしの4ビット整数として解釈されます。このフィールドは、次のコードに従って、このレポートブロックで使用されるパケット遅延変動メトリックタイプを識別するために使用されます。
bits 014-011
ビット014-011
0: MAPDV2, Clause 6.2.3.2 of [G.1020],
0：MAPDV2、[G.1020]の6.2.3.2節、
1: 2-point PDV, Clause 6.2.4 of [Y.1540].
1：2点PDV、[Y.1540]の6.2.4節。
Rsv: 2 bits
Rsv：2ビット
This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and ignored by the receiver.
このフィールドは将来の定義のために予約されています。そのような定義がない場合、このフィールドのビットはゼロに設定されなければならず、受信者によって無視されなければなりません。
block length: 16 bits
ブロック長：16ビット
The length of this report block is in 32-bit words, minus one. For the Packet Delay Variation Metrics Block, the block length is equal to 4.
このレポートブロックの長さは、32ビットワードから1を引いたものです。パケット遅延変動メトリックブロックの場合、ブロック長は4です。
SSRC of source: 32 bits
ソースのSSRC：32ビット
This field is as defined in Section 4.1 of [RFC3611].
このフィールドは、[RFC3611]のセクション4.1で定義されています。
Positive PDV Threshold/Peak: 16 bits
正のPDVしきい値/ピーク：16ビット
This field is associated with the Positive PDV percentile and expressed in milliseconds with numeric format S11:4. The term "Positive" represents that the packets are arriving later than the expected time.
このフィールドは正のPDVパーセンタイルに関連付けられ、数値形式S11：4でミリ秒単位で表されます。 「ポジティブ」という用語は、パケットが予想時間より遅れて到着することを表します。
If the measured value is less than -2047.9375 (the value that would be coded as 0x8001), the value 0x8000 SHOULD be reported to indicate an over-range negative measurement. If the measured value is greater than +2047.8125 (the value that would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an over-range positive measurement. If the measurement is unavailable, the value 0x7FFF MUST be reported.
測定値が-2047.9375（0x8001としてコード化される値）より小さい場合、値0x8000は、範囲外の負の測定値を示すように報告する必要があります（SHOULD）。測定値が+2047.8125（0x7FFDとしてコード化される値）より大きい場合、値0x7FFEは、範囲外の正の測定を示すように報告する必要があります（SHOULD）。測定が利用できない場合、値0x7FFFを報告する必要があります。
Positive PDV Percentile: 16 bits
正のPDVパーセンタイル：16ビット
This field indicates the percentages of packets in the RTP stream for which individual packet delays were less than the Positive PDV Threshold. It is expressed in numeric format 8:8 with values from 0 to 100th percentile.
このフィールドは、個々のパケット遅延が正のPDVしきい値未満であったRTPストリーム内のパケットの割合を示します。数値形式8：8で表され、値は0〜100パーセンタイルです。
If the measurement is unavailable, the value 0xFFFF MUST be reported.
測定が利用できない場合、値0xFFFFを報告する必要があります。
Negative PDV Threshold/Peak: 16 bits
負のPDVしきい値/ピーク：16ビット
This field is associated with the Negative PDV percentile and expressed in milliseconds with numeric format S11:4. The term "Negative" represents that the packets are arriving earlier than the expected time.
このフィールドは負のPDVパーセンタイルに関連付けられ、数値形式S11：4でミリ秒単位で表されます。 「否定的」という用語は、パケットが予想時間よりも早く到着することを表します。
If the measured value is more negative than -2047.9375 (the value that would be coded as 0x8001), the value 0x8000 SHOULD be reported to indicate an over-range negative measurement. If the measured value is more positive than +2047.8125 (the value that would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an over-range positive measurement. If the measurement is unavailable, the value 0x7FFF MUST be reported.
測定値が-2047.9375（0x8001としてコード化される値）よりも負の場合、値0x8000は、範囲外の負の測定を示すように報告する必要があります（SHOULD）。測定値が+2047.8125（0x7FFDとしてコード化される値）よりも正である場合、値0x7FFEは、範囲外の正の測定を示すように報告する必要があります（SHOULD）。測定が利用できない場合、値0x7FFFを報告する必要があります。
Negative PDV Percentile: 16 bits
負のPDVパーセンタイル：16ビット
This field indicates the percentages of packets in the RTP stream for which individual packet delays were more than the Negative PDV Threshold. It is expressed in numeric format 8:8 with values from 0 to 100th percentile.
このフィールドは、個々のパケット遅延が負のPDVしきい値を超えたRTPストリーム内のパケットの割合を示します。数値形式8：8で表され、値は0〜100パーセンタイルです。
If the measurement is unavailable, the value 0xFFFF MUST be reported.
測定が利用できない場合、値0xFFFFを報告する必要があります。
If the PDV Type indicated is 2-point PDV and the Positive and Negative PDV percentiles are set to 100.0, then the Positive and Negative Threshold/Peak PDV values are the peak values measured during the reporting interval (which may be from the start of the call for cumulative reports). In this case, the difference between the Positive and Negative Threshold/Peak values defines the range of 2-point PDV.
示されているPDVタイプが2ポイントPDVであり、正および負のPDVパーセンタイルが100.0に設定されている場合、正および負のしきい値/ピークPDV値は、レポート間隔中に測定されたピーク値です（これは、累積的な報告を求める）。この場合、正と負のしきい値/ピーク値の差により、2ポイントPDVの範囲が定義されます。
Mean PDV: 16 bits
平均PDV：16ビット
The mean PDV value of data packets is expressed in milliseconds with Numeric format S11:4 format.
データパケットの平均PDV値は、数値形式S11：4形式でミリ秒単位で表されます。
For MAPDV2, this value is generated according to Clause 6.2.3.2 of [G.1020]. For interval reports, the MAPDV2 value is reset at the start of the interval.
MAPDV2の場合、この値は[G.1020]の6.2.3.2節に従って生成されます。インターバルレポートの場合、MAPDV2値はインターバルの開始時にリセットされます。
For 2-point PDV, the value reported is the mean of per-packet 2-point PDV values. This metric indicates the arrival time of the first media packet of the session with respect to the mean of the arrival times of every packet of the session. A single value of the metric (for a single session) may not be useful by itself, but its average over a number of sessions may be useful in diagnosing media delay at session startup. For example, this might occur if media packets are often delayed behind signaling packets due to head-of-line blocking.
2ポイントPDVの場合、報告される値は、パケットごとの2ポイントPDV値の平均です。このメトリックは、セッションのすべてのパケットの到着時間の平均に対する、セッションの最初のメディアパケットの到着時間を示します。 （単一セッションの）メトリックの単一の値は、それ自体では役に立たない可能性がありますが、セッション数の平均は、セッションの起動時のメディア遅延の診断に役立つ場合があります。たとえば、ヘッドオブラインブロッキングが原因で、メディアパケットがシグナリングパケットの背後で遅延することが多い場合に、これが発生する可能性があります。
If the measured value is more negative than -2047.9375 (the value that would be coded as 0x8001), the value 0x8000 SHOULD be reported to indicate an over-range negative measurement. If the measured value is more positive than +2047.8125 (the value that would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an over-range positive measurement. If the measurement is unavailable, the value 0x7FFF MUST be reported.
測定値が-2047.9375（0x8001としてコード化される値）よりも負の場合、値0x8000は、範囲外の負の測定を示すように報告する必要があります（SHOULD）。測定値が+2047.8125（0x7FFDとしてコード化される値）よりも正である場合、値0x7FFEは、範囲外の正の測定を示すように報告する必要があります（SHOULD）。測定が利用できない場合、値0x7FFFを報告する必要があります。
Reserved: 16 bits
予約済み：16ビット
These bits are reserved for future definition. They MUST be set to zero by the sender and ignored by the receiver.
これらのビットは将来の定義のために予約されています。それらは送信者によってゼロに設定されなければならず、受信者によって無視されなければなりません。
This subsection provides informative guidance on when it might be appropriate to use each of the PDV metric types.
このサブセクションでは、各PDVメトリックタイプを使用するのが適切な場合がある場合の情報ガイダンスを提供します。
MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous (per-packet) delay when compared to the short-term moving average delay. This metric could be useful in determining residual impairment when an RTP end system uses an adaptive de-jitter buffer that tracks the average delay variation, provided that the averaging behavior of the adaptive algorithm is similar to that of the MAPDV2 algorithm.
MAPDV2（[G.1020]の6.2.3.2節）は、短期移動平均遅延と比較した場合の、瞬時（パケットごと）遅延のエンベロープです。このメトリックは、RTPエンドシステムが平均遅延変動を追跡するアダプティブデジッタバッファーを使用する場合に、残留障害を特定するのに役立ちます。ただし、適応アルゴリズムの平均化動作がMAPDV2アルゴリズムの平均化動作と類似している場合に限ります。
2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay variation with respect to a defined reference packet transfer delay. Note that the reference packet is generally selected as the packet with minimum delay based on the most common criterion (see Sections 1 and 5.1 of [RFC5481]). In an RTP context, the two "points" are at the sender (the synchronization source that applies RTP timestamps) and at the receiver. The value of this metric for the packet with index j is identical to the quantity D(i,j) defined in Section 6.4.1 of [RFC3550], and the packet index i should be set equal to the index of the reference packet for the metric in practice. The metric includes the effect of the frequency offsets of clocks in both the sender and receiver end systems, so it is useful mainly in networks where synchronization is distributed. As well as measuring packet delay variation in such networks, it may be used to ensure that synchronization is effective, for example, where the network carries ISDN data traffic over RTP [RFC4040]. The metric is likely to be useful in networks that use fixed de-jitter buffering, because it may be used to determine the length of the required de-jitter buffer, or to determine if network performance has deteriorated such that existing de-jitter buffers are too small to accommodate the observed delay variation.
2ポイントPDV（[Y.1540]の6.2.4節）は、定義された参照パケット転送遅延に対する絶対パケット遅延変動を報告します。参照パケットは通常、最も一般的な基準に基づいて遅延が最小のパケットとして選択されることに注意してください（[RFC5481]のセクション1および5.1を参照）。 RTPコンテキストでは、2つの「ポイント」は送信側（RTPタイムスタンプを適用する同期ソース）と受信側にあります。インデックスjのパケットに対するこのメトリックの値は、[RFC3550]のセクション6.4.1で定義された数量D（i、j）と同じであり、パケットインデックスiは、参照パケットのインデックスと同じに設定する必要があります。実際のメトリック。このメトリックには、送信側と受信側の両方のエンドシステムのクロックの周波数オフセットの影響が含まれるため、主に同期が分散されているネットワークで役立ちます。このようなネットワークのパケット遅延変動を測定するだけでなく、同期が効果的であることを確認するために使用できます。たとえば、ネットワークがRTPを介してISDNデータトラフィックを伝送する場合[RFC4040]。必要なデジッタバッファの長さを決定したり、ネットワークのパフォーマンスが低下して既存のデジッタバッファが存在するかどうかを判断したりできるため、このメトリックは固定デジッタバッファリングを使用するネットワークで役立つ可能性があります。観測された遅延変動に対応するには小さすぎます。
(a) To report MAPDV2 [G.1020]:
（a）MAPDV2 [G.1020]を報告するには：
Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
Threshold = 50.0 (note this implies -50 ms); Neg PDV Percentile
= 98.4; PDV type = 0 (MAPDV2)
causes average MAPDV2 to be reported in the Mean PDV field.
平均MAPDV2がMean PDVフィールドで報告されます。
Note that implementations either may fix the reported percentile and calculate the associated PDV level or may fix a threshold PDV level and calculate the associated percentile. From a practical implementation perspective, it is simpler to use the second of these approaches (except of course in the extreme case of the 100th percentile).
実装では、報告されたパーセンタイルを修正して関連するPDVレベルを計算するか、しきい値PDVレベルを修正して関連するパーセンタイルを計算する場合があります。実際の実装の観点からは、これらのアプローチの2番目を使用する方が簡単です（もちろん、100パーセンタイルの極端な場合を除きます）。
(b) To report 2-point PDV [Y.1540]:
（b）2ポイントPDVを報告するには[Y.1540]：
Pos PDV Threshold = 60 (note this implies +60 ms); Pos PDV
Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile =
0; PDV type = 1 (2-point PDV)
causes 2-point PDV to be reported in the Mean PDV field.
2ポイントのPDVがMean PDVフィールドで報告されます。
2-point PDV, according to [Y.1540] is the difference in delay between the current packet and the referenced packet of the stream. If the sending and receiving clocks are not synchronized, this metric includes the effect of relative timing drift.
[Y.1540]による2ポイントPDVは、ストリームの現在のパケットと参照されるパケットの間の遅延の差です。送信クロックと受信クロックが同期していない場合、このメトリックには相対的なタイミングドリフトの影響が含まれます。
[RFC3611] defines the use of the Session Description Protocol (SDP) [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used without prior signaling.
[RFC3611]は、XRブロックの使用を通知するためのセッション記述プロトコル（SDP）[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.
このセクションでは、[RFC3611]で定義されているSDP [RFC4566]属性「rtcp-xr」を拡張して、このドキュメントで定義されているレポートブロックの使用を通知する「xr-format」の追加値を提供します。
xr-format =/ xr-pdv-block
xr-format = / xr-pdv-block
xr-pdv-block = "pkt-dly-var" [ "," pdvtype ] [ "," nspec "," pspec ]
xr-pdv-block = "pkt-dly-var" ["、" pdvtype] ["、" nspec "、" pspec]
pdvtype = "pdv=" ( "0" ; MAPDV2 ITU-T G.1020
/ "1" ; 2-point PDV ITU-T Y.1540
/ 1*2DIGIT ) ;Value 2~15 are valid and
;reserved for future use
nspec = ("nthr=" fixpoint) ; negative PDV threshold (ms)
/ ("npc=" fixpoint ) ; negative PDV percentile
pspec = ("pthr=" fixpoint) ; positive PDV threshold (ms)
/ ("ppc=" fixpoint) ; positive PDV percentile
fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal
DIGIT = <as defined in Section 3.4 of [RFC5234]>
When SDP is used in offer/answer, a system sending SDP may request a specific type of PDV measurement. In addition, they may state a specific percentile or threshold value and expect to receive the corresponding threshold or percentile metric, respectively. The system receiving the SDP SHOULD send the PDV metrics requested, but if the metric is not available, the system receiving the SDP MUST send the metric block with the flag value indicating that the metric is unavailable.
SDPがオファー/アンサーで使用される場合、SDPを送信するシステムは、特定のタイプのPDV測定を要求する場合があります。さらに、特定のパーセンタイルまたはしきい値を示し、対応するしきい値またはパーセンタイルメトリックをそれぞれ受け取ることを期待する場合もあります。 SDPを受信するシステムは、要求されたPDVメトリックを送信する必要がありますが、メトリックが使用できない場合、SDPを受信するシステムは、メトリックが使用できないことを示すフラグ値を含むメトリックブロックを送信する必要があります。
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 15 in the IANA "RTCP XR Block Type" registry to the "Packet Delay Variation Metrics Block".
このドキュメントでは、IANA「RTCP XR Block Type」レジストリのブロックタイプ値15を「Packet Delay Variation Metrics Block」に割り当てます。
This document also registers a new parameter "pkt-dly-var" in the "RTCP XR SDP Parameters" registry.
このドキュメントでは、「RTCP XR SDPパラメータ」レジストリに新しいパラメータ「pkt-dly-var」も登録しています。
The contact information for the registrations is:
登録の連絡先情報は次のとおりです。
Qin Wu (sunseawq@huawei.com)
Q in W U（@ Huawei.comに行きます）
101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
210012中国江蘇省江蘇省南京京U画区101ソフトウェアアベニュー
This document creates a new registry to be called "RTCP XR PDV block - PDV type" as a sub-registry of the "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry". Policies for this new registry are as follows:
このドキュメントでは、「RTPコントロールプロトコル拡張レポート（RTCP XR）ブロックタイプレジストリ」のサブレジストリとして、「RTCP XR PDVブロック-PDVタイプ」と呼ばれる新しいレジストリを作成します。この新しいレジストリのポリシーは次のとおりです。
o The information required to support an assignment is an unambiguous definition of the new metric, covering the base measurements and how they are processed to generate the reported metric. This should include the units of measurement, how values of the metric are reported in the three 16-bit fields "Pos PDV Threshold/Peak", "Neg PDV Threshold/Peak", and "Mean PDV" within the report block, and how the metric uses the two 16-bit fields "Pos PDV Percentile" and "Neg PDV Percentile".
o 割り当てをサポートするために必要な情報は、新しい測定値の明確な定義であり、基本測定値と、報告された測定値を生成するためのそれらの処理方法をカバーしています。これには、測定単位、メトリックの値が3つの16ビットフィールド「Pos PDV Threshold / Peak」、「Neg PDV Threshold / Peak」、および「Mean PDV」でレポートブロック内に報告される方法、および方法このメトリックは、2つの16ビットフィールド「Pos PDV Percentile」と「Neg PDV Percentile」を使用します。
o The review process for the registry is "Specification Required" as described in Section 4.1 of [RFC5226].
o [RFC5226]のセクション4.1で説明されているように、レジストリのレビュープロセスは「指定が必要」です。
o Entries in the registry are unsigned 4-bit integers. The valid range is 0 to 15 corresponding to the 4-bit field "pdvtyp" in the block. Values are to be recorded in decimal.
o レジストリのエントリは、符号なし4ビット整数です。有効な範囲は0〜15で、ブロック内の4ビットフィールド「pdvtyp」に対応しています。値は10進数で記録されます。
o Initial assignments are as follows:
o 初期割り当ては次のとおりです。
* 0: MAPDV2, Clause 6.2.3.2 of [G.1020],
* 0：MAPDV2、[G.1020]の6.2.3.2節、
* 1: 2-point PDV, Clause 6.2.4 of [Y.1540],
* 1：2点PDV、[Y.1540]の6.2.4節、
* 2-15: Reserved for future use.
* 2-15：将来の使用のために予約されています。
It is believed that this proposed RTCP XR block introduces no new security considerations beyond those described in [RFC3611]. This block does not provide per-packet statistics so the risk to confidentiality documented in Section 7, paragraph 3, of [RFC3611] does not apply.
この提案されたRTCP XRブロックは、[RFC3611]で説明されているものを超える新しいセキュリティ上の考慮事項を導入しないと考えられています。このブロックはパケットごとの統計を提供しないため、[RFC3611]のセクション7、パラグラフ3に記載されている機密性へのリスクは適用されません。
Geoff Hunt wrote the initial version of this document.
Geoff Huntがこのドキュメントの最初のバージョンを書きました。
The authors gratefully acknowledge reviews and feedback provided by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Hideaki Yamada, Jing Zhao, Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn, Shida Schubert, Benoit Claise, Adrian Farrel, and Pete Resnick.
著者は、ブルース・アダムス、フィリップ・アーデン、アミット・アロラ、ボブ・ビスクナー、ケビン・コナー、クラウス・ダーム、ランディ・エティエ、ロニー・イーブン、ジム・フラウエンタール、アルバート・ヒガシ、トム・ホック、シェーン・ホルトハウス、ポール・ジョーンズ、ラジェシュ・クマールによって提供されたレビューとフィードバックに感謝しますキース・ランツ、モハメド・モスタファ、エイミー・ペンドルトン、コリン・パーキンス、マイク・ラマーリョ、ラヴィ・ラビラジ、アルブレヒト・シュワルツ、トム・テイラー、山田英明、ジン・チャオ、ケビン・グロス、コリン・パーキンス、チャールズ・エッケル、グレン・ゾーン、シーダ・シューベルト、ブノワ・クレイスファレル、ピートレズニック。
[G.1020] ITU-T Rec. G. 1020, "Performance parameter definitions for quality of speech and other voiceband applications utilizing IP networks", July 2006.
[G.1020] ITU-T Rec。 G. 1020、「IPネットワークを利用した音声品質およびその他の音声帯域アプリケーションのパフォーマンスパラメータ定義」、2006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T。、カセレス、R。、およびA.クラーク、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
[RFC4040] Kreuter、R。、「64 kbit / s Transparent CallのRTPペイロード形式」、RFC 4040、2005年4月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[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, October 2012.
[RFC6776]クラークA.およびQ.ウー、「ソース記述（SDES）アイテムとRTCP拡張レポート（XR）ブロックを使用した測定IDおよび情報レポート」、RFC 6776、2012年10月。
[Y.1540] ITU-T Rec. Y.1540, "IP packet transfer and availability performance parameters", November 2007.
[Y.1540] ITU-T Rec。 Y.1540、「IPパケット転送と可用性のパフォーマンスパラメータ」、2007年11月。
[MONARCH] Wu, W., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", Work in Progress, September 2012.
[モナーク]呉、W、ハント、G、Pアーデン、「RTP監視フレームワークの使用に関するガイドライン」、作業中、2012年9月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481] Morton、A。およびB. Claise、「Packet Delay Variation Applicability Statement」、RFC 5481、2009年3月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390] Clark、A。およびB. Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、2011年10月。
Authors' Addresses
著者のアドレス
Alan Clark Telchemy Incorporated 2905 Premiere Parkway, Suite 280 Duluth, GA 30097 USA
Alan Clark Telchemy Incorporated 2905 Premiere Parkway、Suite 280 Duluth、GA 30097 USA
EMail: alan.d.clark@telchemy.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQは101ソフトウェアアベニューで、Y Uは地区210012中国江蘇省NaN京を描画します
EMail: sunseawq@huawei.com