[要約] RFC 7266は、RTP制御プロトコル（RTCP）拡張レポート（XR）ブロックのためのMean Opinion Score（MOS）メトリックレポートに関するものです。このRFCの目的は、音声品質の評価を含むMOSメトリックの報告を可能にするためのXRブロックの定義と使用方法を提供することです。
Internet Engineering Task Force (IETF) A. Clark
Request for Comments: 7266 Telchemy
Category: Standards Track Q. Wu
ISSN: 2070-1721 Huawei
R. Schott
Deutsche Telekom
G. Zorn
Network Zen
June 2014
RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting
RTP Control Protocol（RTCP）Extended Report（XR）Blocks for Mean Opinion Score（MOS）Metric Reporting
Abstract
概要
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.
このドキュメントでは、RTPコントロールプロトコル（RTCP）拡張レポート（XR）ブロックを定義します。これには、2つの新しいセグメントタイプと、一連のRTPアプリケーションで使用する平均オピニオンスコア（MOS）メトリックのレポートを可能にする関連セッション記述プロトコル（SDP）パラメータが含まれます。 。
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/rfc7266.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7266で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. MOS Metrics Report Block ...................................3
1.2. RTCP and RTCP XR Reports ...................................3
1.3. Performance Metrics Framework ..............................3
1.4. Applicability ..............................................3
2. Terminology .....................................................4
2.1. Standards Language .........................................4
3. MOS Metrics Block ...............................................5
3.1. Report Block Structure .....................................6
3.2. Definition of Fields in MOS Metrics Block ..................6
3.2.1. Single-Channel Audio/Video per SSRC Segment .........7
3.2.2. Multi-Channel Audio per SSRC Segment ................9
4. SDP Signaling ..................................................10
4.1. SDP "rtcp-xr-attrib" Attribute Extension ..................10
4.2. Offer/Answer Usage ........................................12
5. IANA Considerations ............................................14
5.1. New RTCP XR Block Type Value ..............................14
5.2. New RTCP XR SDP Parameter .................................14
5.3. The SDP "calgextmap" Attribute ............................14
5.4. New Registry of Calculation Algorithms ....................15
6. Security Considerations ........................................16
7. Contributors ...................................................16
8. Acknowledgements ...............................................17
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................18
Appendix A. Metrics Represented Using the RFC 6390 Template .......20
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 media quality using one of several standard metrics (e.g., mean opinion score (MOS)).
新しいブロックタイプは、いくつかの標準的な指標の1つを使用してメディア品質に関する情報を提供します（たとえば、平均オピニオンスコア（MOS））。
The metrics belong to the class of application-level metrics defined in [RFC6792].
メトリックは、[RFC6792]で定義されているアプリケーションレベルのメトリックのクラスに属しています。
The use of RTCP for reporting is defined in [RFC3550]. RFC 3611 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]で定義されています。 RFC 3611は、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 document [RFC6792] provides guidelines for reporting block format using RTCP XR. The XR block type described in this document is in accordance with the guidelines in [RFC6390] and [RFC6792].
パフォーマンスメトリックフレームワーク[RFC6390]は、パフォーマンスメトリックの定義と仕様に関するガイダンスを提供します。 RTPモニタリングアーキテクチャドキュメント[RFC6792]は、RTCP XRを使用してブロック形式を報告するためのガイドラインを提供します。このドキュメントで説明されているXRブロックタイプは、[RFC6390]と[RFC6792]のガイドラインに準拠しています。
The MOS Metrics Report Block can be used in any application of RTP for which QoE (Quality-of-Experience) measurement algorithms are defined.
MOSメトリックレポートブロックは、QoE（Quality-of-Experience）測定アルゴリズムが定義されているRTPの任意のアプリケーションで使用できます。
The factors that affect real-time audio/video application quality can be split into two categories. The first category consists of transport-specific factors such as packet loss, delay, and jitter (which also translates into losses in the playback buffer). The factors in the second category consists of content- and codec-related factors such as codec type and loss recovery technique, coding bit rate, packetization scheme, and content characteristics
リアルタイムのオーディオ/ビデオアプリケーションの品質に影響を与える要因は、2つのカテゴリに分類できます。最初のカテゴリは、パケットの損失、遅延、ジッターなどのトランスポート固有の要素で構成されます（これらは再生バッファーでの損失にもなります）。 2番目のカテゴリの要素は、コーデックタイプと損失回復手法、コーディングビットレート、パケット化スキーム、コンテンツ特性など、コンテンツおよびコーデック関連の要素で構成されます。
Transport-specific factors may be insufficient to infer real-time media quality as codec related parameters and the interaction between transport problems and application-layer protocols can have a substantial effect on observed media quality. Media quality may be measured using algorithms that directly compare input and output media streams, or it may be estimated using algorithms that model the interaction between media quality, protocol, and encoded content. Media quality is commonly expressed in terms of MOS; however, it is also represented by a range of indexes and other scores.
コーデック関連のパラメータや、トランスポートの問題とアプリケーション層プロトコル間の相互作用は、観測されたメディア品質に大きな影響を与える可能性があるため、トランスポート固有の要素では、リアルタイムのメディア品質を推測するには不十分な場合があります。メディア品質は、入力と出力のメディアストリームを直接比較するアルゴリズムを使用して測定することも、メディア品質、プロトコル、およびエンコードされたコンテンツ間の相互作用をモデル化するアルゴリズムを使用して推定することもできます。メディアの品質は一般的にMOSで表されます。ただし、インデックスやその他のスコアの範囲によっても表されます。
The measurement of media quality has a number of applications:
メディア品質の測定には多くの用途があります。
o Detecting problems with media delivery or encoding that is impacting user-perceived quality.
o ユーザーの知覚品質に影響を与えるメディア配信またはエンコーディングの問題を検出します。
o Tuning the content encoder algorithm to satisfy real-time data quality requirements.
o コンテンツエンコーダーアルゴリズムを調整して、リアルタイムのデータ品質要件を満たします。
o Determining which system techniques to use in a given situation and when to switch from one technique to another as system parameters change (for example, as discussed in [G.1082]).
o 特定の状況で使用するシステムテクニックを決定し、システムパラメータの変更に応じて、あるテクニックから別のテクニックに切り替えるタイミングを決定します（たとえば、[G.1082]で説明されています）。
o Prequalifying a network to assess its ability to deliver an acceptable end-user-perceived quality level.
o ネットワークを事前認定して、エンドユーザーが認識できる許容可能な品質レベルを提供する能力を評価します。
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]で説明されているように解釈されます。
Notable terminology used is the following.
使用されている主な用語は次のとおりです。
Numeric formats X:Y
数値フォーマットX：Y
where X the number of bits prior to the decimal place and Y the number of bits after the decimal place.
ここで、Xは小数点以下のビット数、Yは小数点以下のビット数です。
Hence, 8:8 represents an unsigned number in the range 0.0 to 255.996 with a granularity of 0.0039. 0:16 represents a proper binary fraction with range 0.0 to 1 - 1/65536 = 0.9999847, though 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 range 0.0 to 1 - 3/65536 = 0.9999542.
したがって、8：8は0.039の粒度で0.0から255.996の範囲の符号なし数値を表します。 0:16は、範囲が0.0から1-1/65536 = 0.9999847の適切な2進数の小数を表しますが、数値範囲の最上部でフラグ値を使用すると、この上限がわずかに減少します。たとえば、16ビット値0XFFFEおよび0XFFFFが「over-range」および「unavailable」条件のフラグとして使用される場合、0：16数量の範囲は0.0〜1-3/65536 = 0.9999542です。
Calculation Algorithm
計算アルゴリズム
Calculation Algorithm is used in this document to mean the MOS or QoE estimation algorithm.
このドキュメントでは、MOSまたはQoE推定アルゴリズムを意味する計算アルゴリズムを使用しています。
A multimedia application MOS Metric is commonly expressed as a MOS.
The MOS is usually on a scale from 1 to 5, in which 5 represents
excellent and 1 represents unacceptable; however, it can use other
ranges (for example, 0 to 10 ). The term "MOS" originates from
subjective testing and is used to refer to the mean of a number of
individual opinion scores. Therefore, there is a well-understood
relationship between MOS and user experience; hence, the industry
commonly uses MOS as the scale for objective test results.
Subjective tests can be used for measuring live network traffic;
however, the use of objective or algorithmic measurement techniques
allows much larger scale measurements to be made. Within the scope
of this document, mean opinion scores are obtained using objective or
estimation algorithms. ITU-T or ITU-R recommendations (e.g.,
[BS.1387-1], [G.107], [G.107.1], [P.862], [P.862.1], [P.862.2],
[P.863], [P.564], [G.1082], [P.1201.1], [P.1201.2], [P.1202.1],
[P.1202.2]) define methodologies for assessment of the performance of
audio and video streams. Other international and national standards
organizations such as EBU, ETSI, IEC, and IEEE also define QoE
algorithms and methodologies, and the intent of this document is not
to restrict its use to ITU recommendations but to suggest that ITU
recommendations be used where they are defined.
This block reports the media quality in the form of a MOS range (e.g., 1-5, 0-10, or 0-100, as specified by the calculation algorithm); however, it does not report the MOS that includes parameters outside the scope of the RTP stream, for example, signaling performance, mean time to repair (MTTR), or other factors that may affect the overall user experience.
このブロックは、MOS範囲の形式でメディア品質を報告します（例：1-5、0-10、または0-100、計算アルゴリズムで指定）。ただし、RTPストリームの範囲外のパラメーター（シグナリングパフォーマンス、平均修復時間（MTTR）など）や、ユーザーエクスペリエンス全体に影響を与える可能性のあるその他の要因を含むMOSは報告されません。
The MOS Metric reported in this block gives a numerical indication of the perceived quality of the received media stream, which is typically measured at the receiving end of the RTP stream. Instances of this Metrics Block refer by synchronization source (SSRC) to the separate auxiliary Measurement Information block [RFC6776] which describes measurement periods in use (see RFC 6776, Section 4.2).
このブロックで報告されるMOSメトリックは、受信したメディアストリームの知覚品質の数値を示します。これは、通常、RTPストリームの受信側で測定されます。このMetricsブロックのインスタンスは、同期ソース（SSRC）によって、使用中の測定期間を説明する個別の補助測定情報ブロック[RFC6776]を参照します（RFC 6776、セクション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.
このMetricsブロックは、レポートのスパンを示すMeasurement Informationブロックの測定期間に依存しています。送信者は、Measurement Informationブロックと同じ複合RTCPパケットでこのブロックを送信する必要があります。受信者は、測定期間がこのメトリックブロックと同じ複合RTCPパケットで受信されていることを確認する必要があります。そうでない場合、このメトリックブロックは破棄する必要があります。
The MOS Metrics Block has the following format:
MOSメトリックブロックの形式は次のとおりです。
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=29 | I | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Block type (BT): 8 bits
ブロックタイプ（BT）：8ビット
The MOS Metrics Block is identified by the constant 29.
MOSメトリックブロックは、定数29で識別されます。
Interval Metric flag (I): 2 bits
間隔メトリックフラグ（I）：2ビット
This field is used to indicate whether the MOS Metrics are Sampled, Interval, or Cumulative [RFC6792]:
このフィールドは、MOSメトリックがサンプル、間隔、累積のいずれであるかを示すために使用されます[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：累積期間-報告された値は、累積測定に特有の累積期間に適用されます。
I=01: Sampled Value - the reported value is a sampled instantaneous value.
I = 01：サンプル値-報告された値はサンプルの瞬間値です。
I=00: Reserved
I = 00：予約済み
In this document, MOS Metrics MAY be reported for intervals or for the duration of the media stream (cumulative). The value I=01, indicating a sampled value, MUST NOT be sent and MUST be discarded when received.
このドキュメントでは、MOSメトリックは、間隔またはメディアストリームの期間（累積）について報告される場合があります。サンプリングされた値を示す値I = 01は送信してはならず、受信時に破棄する必要があります。
Reserved: 6 bits
予約済み：6ビット
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 (see RFC 6709, Section 4.2).
このフィールドは将来の定義のために予約されています。そのような定義がない場合、このフィールドのビットはゼロに設定され、受信者によって無視される必要があります（RFC 6709、セクション4.2を参照）。
Block Length: 16 bits
ブロック長：16ビット
The length of this report block in 32-bit words, minus one. For the MOS Metrics Block, the block length is variable length.
このレポートブロックの長さ（32ビットワード、マイナス1）。 MOS Metrics Blockの場合、ブロックの長さは可変長です。
SSRC of source: 32 bits
ソースのSSRC：32ビット
As defined in Section 4.1 of [RFC3611].
[RFC3611]のセクション4.1で定義されています。
Segment i: 32 bits
セグメントi：32ビット
There are two segment types defined in this document: single-channel audio/video per SSRC segment and multi-channel audio per SSRC segment. Multi-channel audio per SSRC segment is used to deal with the case where multi-channel audio streams are carried in one RTP stream while a single-channel audio/video per SSRC segment is used to deal with the case where each media stream is identified by SSRC and sent in separate RTP streams. The leftmost bit of the segment determines its type. If the leftmost bit of the segment is zero, then it is a single-channel segment. If the leftmost bit is one, then it is a multi-channel audio segment. Note that two segment types cannot be present in the same metric block.
このドキュメントでは、2つのセグメントタイプが定義されています。SSRCセグメントごとのシングルチャネルオーディオ/ビデオと、SSRCセグメントごとのマルチチャネルオーディオです。 SSRCセグメントごとのマルチチャネルオーディオは、マルチチャネルオーディオストリームが1つのRTPストリームで運ばれる場合の処理に使用され、SSRCセグメントごとのシングルチャネルオーディオ/ビデオは、各メディアストリームが識別される場合の処理に使用されます。 SSRCによって、個別のRTPストリームで送信されます。セグメントの左端のビットがそのタイプを決定します。セグメントの左端のビットがゼロの場合、それは単一チャネルセグメントです。左端のビットが1の場合、それはマルチチャネルオーディオセグメントです。 2つのセグメントタイプを同じメトリックブロックに含めることはできません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Segment Type (S): 1 bit
セグメントタイプ（S）：1ビット
This field is used to identify the segment type used in this report block. A zero identifies this as a single-channel audio/video per SSRC segment. Single channel means there is only one media stream carried in one RTP stream. The single-channel audio/video per SSRC segment can be used to report the MOS value associated with the media stream identified by SSRC. If there are multiple media streams and they want to use the single-channel audio/video per SSRC segment to report the MOS value, they should be carried in the separate RTP streams with each identified by different SSRC. In this case, multiple MOS Metrics Blocks are required to report the MOS value corresponding to each media stream using single-channel audio/video per SSRC segment in the same RTCP XR packet.
このフィールドは、このレポートブロックで使用されるセグメントタイプを識別するために使用されます。ゼロは、これをSSRCセグメントごとの単一チャネルのオーディオ/ビデオとして識別します。単一チャネルとは、1つのRTPストリームで1つのメディアストリームのみが伝送されることを意味します。 SSRCセグメントごとの単一チャネルオーディオ/ビデオを使用して、SSRCによって識別されたメディアストリームに関連付けられたMOS値を報告できます。複数のメディアストリームがあり、SSRCセグメントごとにシングルチャネルのオーディオ/ビデオを使用してMOS値を報告する場合、それらは別々のRTPストリームで伝送され、それぞれが異なるSSRCによって識別されます。この場合、同じRTCP XRパケットのSSRCセグメントごとにシングルチャネルオーディオ/ビデオを使用して各メディアストリームに対応するMOS値を報告するには、複数のMOSメトリックブロックが必要です。
Calculation Algorithm ID (CAID) : 8 bits
計算アルゴリズムID（CAID）：8ビット
The 8-bit CAID is the session specific reference to the calculation algorithm and associated qualifiers indicated in SDP (see Section 4.1) and used to compute the MOS score for this segment.
8ビットCAIDは、SDP（セクション4.1を参照）で示される計算アルゴリズムと関連する修飾子へのセッション固有の参照であり、このセグメントのMOSスコアを計算するために使用されます。
Payload Type (PT): 7 bits
ペイロードタイプ（PT）：7ビット
MOS Metrics reporting depends on the payload format in use. This field identifies the RTP payload type in use during the reporting interval. The binding between RTP payload types and RTP payload formats is configured via a signaling protocol, for example, an SDP offer/answer exchange. If the RTP payload type used is changed during an RTP session, separate reports SHOULD be sent for each RTP payload type, with corresponding measurement information blocks indicating the time period to which they relate.
MOSメトリックレポートは、使用中のペイロード形式によって異なります。このフィールドは、レポート間隔中に使用されているRTPペイロードタイプを識別します。 RTPペイロードタイプとRTPペイロードフォーマット間のバインディングは、SDPオファー/アンサー交換などのシグナリングプロトコルを介して設定されます。使用するRTPペイロードタイプがRTPセッション中に変更された場合、RTPペイロードタイプごとに個別のレポートを送信する必要があります（SHOULD）。対応する測定情報ブロックは、それらが関連する期間を示します。
Note that the use of this Report Block with MPEG Transport streams carried over RTP is undefined as each MPEG Transport stream may use distinct audio or video codecs and the indication of the encoding of these is within the MPEG Transport stream and does not use RTP payloads.
RTPで伝送されるMPEGトランスポートストリームでのこのレポートブロックの使用は未定義であることに注意してください。各MPEGトランスポートストリームは個別のオーディオまたはビデオコーデックを使用する可能性があり、これらのエンコーディングの表示はMPEGトランスポートストリーム内にあり、RTPペイロードを使用しないためです。
MOS Value: 16 bits
MOS値：16ビット
The estimated mean opinion score (MOS) for multimedia application performance is estimated using an algorithm that includes the impact of delay, loss, jitter and other impairments that affect media quality. This is an unsigned fixed-point 7:9 value representing the MOS, allowing the MOS score up to 127 in the integer part. MOS ranges are defined as part of the specification of the MOS estimation algorithm (Calculation Algorithm in this document), and are normally ranges like 1-5, 0-10, or 0-100. Two values are reserved: a value of 0xFFFE indicates that the measurement is out of range and a value of 0xFFFF indicates that the measurement is unavailable. Values outside of the range defined by the Calculation Algorithm, other than the two reserved values, MUST NOT be sent and MUST be ignored by the receiving system.
マルチメディアアプリケーションのパフォーマンスの平均オピニオンスコア（MOS）は、メディア品質に影響を与える遅延、損失、ジッター、およびその他の障害の影響を含むアルゴリズムを使用して推定されます。これは、MOSを表す符号なし固定小数点7：9の値であり、整数部分で127までのMOSスコアを許可します。 MOS範囲は、MOS推定アルゴリズム（このドキュメントの計算アルゴリズム）の仕様の一部として定義されており、通常は1-5、0-10、または0-100のような範囲です。 2つの値が予約されています。値0xFFFEは測定が範囲外であることを示し、値0xFFFFは測定が利用できないことを示します。 2つの予約済みの値以外の、計算アルゴリズムで定義された範囲外の値は送信してはならず（MUST NOT）、受信システムによって無視されなければなりません（MUST）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT |CHID | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Segment Type (S): 1 bit
セグメントタイプ（S）：1ビット
This field is used to identify the segment type used in this report block. A one identifies this as a multi-channel audio segment.
このフィールドは、このレポートブロックで使用されるセグメントタイプを識別するために使用されます。 1つは、これをマルチチャネルオーディオセグメントとして識別します。
Calculation Algorithm ID (CAID) : 8 bits
計算アルゴリズムID（CAID）：8ビット
The 8-bit CAID is the session specific reference to the calculation algorithm and associated qualifiers indicated in SDP (see Section 4.1) and used to compute the MOS score for this segment.
8ビットCAIDは、SDP（セクション4.1を参照）で示される計算アルゴリズムと関連する修飾子へのセッション固有の参照であり、このセグメントのMOSスコアを計算するために使用されます。
Payload Type (PT): 7 bits
ペイロードタイプ（PT）：7ビット
As defined in Section 3.2.1 of this document
このドキュメントのセクション3.2.1で定義されているとおり
Channel Identifier (CHID): 3 bits
チャネル識別子（CHID）：3ビット
If multiple channels of audio are carried in one RTP stream, each channel of audio will be viewed as an independent channel (e.g., left channel audio, right channel audio). This field is used to identify each channel carried in the same media stream. The default channel mapping follows static ordering rule described in Section 4.1 of [RFC3551]. However, there are some payload formats that use different channel mappings, e.g., AC-3 audio over RTP [RFC4184] only follow AC-3 channel order scheme defined in [ATSC]. Enhanced AC-3 audio over RTP [RFC4598] uses a dynamic channel transform mechanism. In order for the appropriate channel mapping to be determined, MOS metrics reports need to be tied to an RTP payload format. The reports should include the payload type of the reported media according to [RFC6792], so that it can be used to determine the appropriate channel mapping.
オーディオの複数のチャネルが1つのRTPストリームで運ばれる場合、オーディオの各チャネルは独立したチャネル（たとえば、左チャネルオーディオ、右チャネルオーディオ）として表示されます。このフィールドは、同じメディアストリームで伝送される各チャネルを識別するために使用されます。デフォルトのチャネルマッピングは、[RFC3551]のセクション4.1で説明されている静的順序付けルールに従います。ただし、異なるチャネルマッピングを使用するペイロード形式がいくつかあります。たとえば、RTPを介したAC-3オーディオ[RFC4184]は、[ATSC]で定義されたAC-3チャネル順序スキームのみに従う。拡張されたAC-3オーディオover RTP [RFC4598]は、動的チャネル変換メカニズムを使用します。適切なチャネルマッピングを決定するには、MOSメトリックレポートをRTPペイロード形式に関連付ける必要があります。レポートには、[RFC6792]に従って、報告されたメディアのペイロードタイプを含める必要があります。これにより、適切なチャネルマッピングを決定するために使用できます。
MOS Value: 13 bits
MOS値：13ビット
The estimated MOS for multimedia application performance is defined as including the effects of delay, loss, discard, jitter and other effects that would affect media quality. This is an unsigned fixed-point 7:6 value representing the MOS, allowing the MOS score up to 127 in the integer part. MOS ranges are defined as part of the specification of the MOS estimation algorithm (Calculation Algorithm in this document), and are normally ranges like 1-5, 0-10, or 0-100. Two values are reserved: a value of 0x1FFE indicates out of range and a value of 0x1FFF indicates that the measurement is unavailable. Values outside of the range defined by the Calculation Algorithm, other than the two reserved values, MUST NOT be sent and MUST be ignored by the receiving system.
マルチメディアアプリケーションのパフォーマンスの推定MOSは、遅延、損失、破棄、ジッターなど、メディア品質に影響を与える影響を含むと定義されています。これは、MOSを表す符号なし固定小数点7：6値であり、整数部分で127までのMOSスコアを許可します。 MOS範囲は、MOS推定アルゴリズム（このドキュメントの計算アルゴリズム）の仕様の一部として定義されており、通常は1-5、0-10、または0-100のような範囲です。 2つの値が予約されています。値0x1FFEは範囲外を示し、値0x1FFFは測定が利用できないことを示します。 2つの予約済みの値以外の、計算アルゴリズムで定義された範囲外の値は送信してはならず（MUST NOT）、受信システムによって無視されなければなりません（MUST）。
[RFC3611] defines the use of SDP [RFC4566] for signaling the use of XR blocks. However, XR blocks MAY be used without prior signaling (see Section 5 of RFC 3611).
[RFC3611]は、XRブロックの使用を通知するためのSDP [RFC4566]の使用を定義しています。ただし、XRブロックは事前のシグナリングなしで使用できます（RFC 3611のセクション5を参照）。
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. Within the "xr-format", the syntax element "calgextmap" is an attribute as defined in [RFC4566] and used to signal the mapping of the local identifier (CAID) in the segment extension defined in Section 3.2 to the calculation algorithm. Specific extension attributes are defined by the specification that defines a specific extension name: there might be several. The ABNF [RFC5234] syntax is as follows.
このセクションでは、[RFC3611]で定義されているSDP [RFC4566]属性「rtcp-xr」を拡張して、このドキュメントで定義されているレポートブロックの使用を通知する「xr-format」の追加の値を提供します。 「xr-format」内の構文要素「calgextmap」は、[RFC4566]で定義されている属性であり、セクション3.2で定義されているセグメント拡張のローカル識別子（CAID）の計算アルゴリズムへのマッピングを通知するために使用されます。特定の拡張属性は、特定の拡張名を定義する仕様によって定義されます。いくつかある場合があります。 ABNF [RFC5234]の構文は次のとおりです。
xr-format =/ xr-mos-block
xr-mos-block = "mos-metric" ["=" calgextmap *("," calgextmap)]
calgextmap = mapentry "=" extensionname [SP extentionattributes]
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
mapentry = "calg:" 1*3DIGIT [ "/" direction ]
; Values in the range 1-255 are valid
; if needed, 0 can be used to indicate that
; an algorithm is rejected
extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564]
/ "G107";ITU-T G.107 [G.107]
/ "G107_1";ITU-T G.107.1 [G.107.1]
/ "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI]
/"JJ201_1 ";TTC JJ201.1 [TTC]
/"P1201_1";ITU-T P.1201.2 [P.1201.1]
/"P1201_2";ITU-T P.1201.2 [P.1201.2]
/"P1202_1";ITU-T P.1202.1 [P.1202.1]
/"P1202_2";ITU-T P.1202.2 [P.1202.2]
/"P.862.2";ITU-T P.862.2 [P.862.2]
/"P.863"; ITU-T P.863 [P.863]
/ non-ws-string
extensionattributes = mosref
/attributes-ext
mosref = "mosref=" ("l"; lower resolution
/"m"; middle resolution
/ "h";higher resolution
/ non-ws-string)
attributes-ext = non-ws-string
SP = <Defined in RFC 5234>
non-ws-string = 1*(%x21-FF)
Each local identifier (CAID) of calculation algorithm used in the segment defined in Section 3.2 is mapped to a string using an attribute of the form:
セクション3.2で定義されたセグメントで使用される計算アルゴリズムの各ローカル識別子（CAID）は、次の形式の属性を使用して文字列にマップされます。
a=calg:<value> [ "/"<direction> ] <name> [<extensionattributes>]
where <name> is a calculation algorithm name, as above, <value> is the local identifier (CAID) of the calculation algorithm associated with the segment defined in this document and is an integer in the valid range, inclusive.
上記のように、<name>は計算アルゴリズム名です。<value>は、このドキュメントで定義されているセグメントに関連付けられている計算アルゴリズムのローカル識別子（CAID）であり、有効な範囲内の整数です。
Example:
a=rtcp-xr:mos-metric=calg:1=G107,calg:2=P1202_1
A usable mapping MUST use IDs in the valid range, and each ID in this range MUST be unique and used only once for each stream or each channel in the stream.
使用可能なマッピングは、有効な範囲のIDを使用する必要があり、この範囲の各IDは一意であり、ストリーム内の各ストリームまたは各チャネルに対して1回だけ使用する必要があります。
The mapping MUST be provided per media stream (in the media-level section(s) of SDP, i.e., after an "m=" line).
マッピングはメディアストリームごとに提供する必要があります（SDPのメディアレベルセクション内、つまり「m =」行の後）。
The syntax element "mosref" is referred to the media resolution relative reference and has three values 'l','m','h'. (e.g., narrowband (3.4 kHz) speech and Standard Definition (SD) or lower resolution video have 'l' resolution, super-wideband (>14 kHz) speech or higher and High Definition (HD) or higher resolution video have 'h' resolution, wideband speech (7 kHz) and video with resolution between SD and HD has 'm' resolution). The MOS reported in the MOS metrics block might vary with the MOS reference; for example, MOS values for narrowband, wideband, super-wideband codecs occupy the same range but SHOULD be reported in different value. For video application, MOS scores for SD resolution, HD resolution video also occupy the same ranges and SHOULD be reported in different value.
構文要素「mosref」は、メディア解像度の相対参照を指し、3つの値「l」、「m」、「h」を持っています。 （例えば、狭帯域（3.4 kHz）スピーチと標準解像度（SD）またはそれ以下の解像度のビデオは「l」解像度、超広帯域（> 14 kHz）以上のスピーチと高精細（HD）またはそれ以上の解像度のビデオは「h」解像度、広帯域音声（7 kHz）、およびSDとHDの間の解像度のビデオには「m」解像度があります。 MOSメトリックブロックで報告されるMOSは、MOSリファレンスによって異なる場合があります。たとえば、ナローバンド、ワイドバンド、スーパーワイドバンドコーデックのMOS値は同じ範囲を占めますが、異なる値で報告する必要があります（SHOULD）。ビデオアプリケーションの場合、SD解像度、HD解像度のビデオのMOSスコアも同じ範囲を占め、異なる値で報告する必要があります。
When SDP is used in offer/answer context, the SDP Offer/Answer usage defined in [RFC3611] applies. In the offer/answer context, the signaling described above might be used in three ways:
SDPがオファー/アンサーコンテキストで使用される場合、[RFC3611]で定義されているSDPオファー/アンサーの使用法が適用されます。オファー/アンサーのコンテキストでは、上記のシグナリングは3つの方法で使用できます。
o asymmetric behavior (segment extensions sent in only one direction),
o 非対称の動作（一方向にのみ送信されるセグメント拡張）、
o the offer of mutually exclusive alternatives, or
o 相互に排他的な代替案の提供、または
o the offer of more segments than can be sent in a single session.
o 単一のセッションで送信できるよりも多くのセグメントのオファー。
A direction attribute MAY be included in a "calgextmap"; without it, the direction implicitly inherits, of course, from the RTCP stream direction.
方向属性は「calgextmap」に含めることができます。それがなければ、方向はもちろん、RTCPストリーム方向から暗黙的に継承されます。
Segment extensions, with their directions, MAY be signaled for an "inactive" stream. An extension direction MUST be compatible with the stream direction. If a segment extension in the SDP offer is marked as "sendonly" and the answerer desires to receive it, the extension MUST be marked as "recvonly" in the SDP answer. An answerer that has no desire to receive the extension or does not understand the extension SHOULD NOT include it in the SDP answer.
セグメント拡張とその方向は、「非アクティブ」ストリームに対して通知される場合があります。拡張方向は、ストリーム方向と互換性がある必要があります。 SDPオファーのセグメント拡張が「sendonly」としてマークされていて、回答者がそれを受信することを希望している場合、SDP応答で拡張が「recvonly」としてマークされている必要があります。エクステンションを受信したくない、またはエクステンションを理解していない回答者は、SDP回答にそれを含めるべきではありません。
If a segment extension is marked as "recvonly" in the SDP offer and the answerer desires to send it, the extension MUST be marked as "sendonly" in the SDP answer. An answerer that has no desire to, or is unable to, send the extension SHOULD NOT include it in the SDP answer.
SDPオファーでセグメント拡張が「recvonly」としてマークされており、回答者がそれを送信することを希望している場合、SDP応答で拡張が「sendonly」としてマークされている必要があります。拡張機能を送信したくない、または拡張機能を送信できない回答者は、SDP回答にそれを含めるべきではありません（SHOULD NOT）。
If a segment extension is offered as "sendrecv", explicitly or implicitly, and asymmetric behavior is desired, the SDP MAY be modified to modify or add direction qualifiers for that segment extension.
セグメント拡張が明示的または暗黙的に「sendrecv」として提供され、非対称の動作が望ましい場合、SDPを変更して、そのセグメント拡張の方向修飾子を変更または追加できます（MAY）。
A "mosref" attribute and "MOS Type" attribute MAY be included in a calgextmap; if not present, the "mosref" and "MOS Type" MUST be as defined in the QoE estimation algorithm referenced by the name attribute (e.g., P.1201.1 [P.1201.1] indicates lower resolution used while P.1201.2 [P.1201.2] indicates higher resolution used) or payload type carried in the segment extension (e.g., EVRC-WB [RFC5188] indicates using Wideband Codec). However, not all payload types or MOS algorithm names indicate resolution to be used and MOS type to be used. If an answerer receives an offer with a "mosref" attribute value it doesn't support (e.g.,the answerer only supports "l" and receives "h" from offerer), the answer SHOULD reject the mosref attribute value offered by the offerer.
「mosref」属性と「MOSタイプ」属性は、calgextmapに含めることができます。存在しない場合、「mosref」と「MOSタイプ」は、名前属性によって参照されるQoE推定アルゴリズムで定義されたとおりでなければなりません（たとえば、P.1201.1 [P.1201.1]は、P.1201.2 [P.1201.2 ]はより高い解像度を使用することを示します）またはセグメント拡張で運ばれるペイロードタイプ（たとえば、EVRC-WB [RFC5188]はワイドバンドコーデックの使用を示します）ただし、すべてのペイロードタイプまたはMOSアルゴリズム名が、使用される解像度と使用されるMOSタイプを示すわけではありません。回答者がサポートしていない「mosref」属性値を持つオファーを受け取った場合（たとえば、回答者は「l」のみをサポートし、オファー者から「h」を受け取った場合）、回答者はオファー者によって提供されたmosref属性値を拒否する必要があります（SHOULD）。
If the answerer wishes to reject a "mosref" attribute offered by the offerer, it sets identifiers associated with segment extensions in the answer to the value in the range 4096-4351. The rejected answer MUST contain a "mosref" attribute whose value is the value of the SDP offer.
回答者が提供者から提供された「mosref」属性を拒否する場合、回答者は、回答のセグメント拡張に関連付けられた識別子を4096〜4351の範囲の値に設定します。拒否された回答には、その値がSDPオファーの値である「mosref」属性が含まれている必要があります。
Local identifiers in the valid range (inclusive) in an offer or answer must not be used more than once per media section. A session update MAY change the direction qualifiers of segment extensions under use. A session update MAY add or remove segment extension(s). Identifier values in the valid range MUST NOT be altered (remapped).
オファーまたはアンサーの有効範囲内（両端を含む）のローカル識別子は、メディアセクションごとに複数回使用しないでください。セッションの更新により、使用中のセグメント拡張の方向修飾子が変更される場合があります。セッションの更新により、セグメント拡張が追加または削除される場合があります。有効な範囲の識別子の値を変更（再マップ）してはなりません（MUST NOT）。
If a party wishes to offer mutually exclusive alternatives, then multiple segment extensions with the same identifier in the (unusable) range 4096-4351 MAY be offered; the answerer SHOULD select at most one of the offered extensions with the same identifier, and remap it to a free identifier in the valid range for that extension to be usable. Note that the two segment types defined in Section 3 are also exclusive alternatives.
当事者が相互に排他的な代替案を提供したい場合、4096〜4351の（使用できない）範囲の同じ識別子を持つ複数のセグメント拡張が提供される場合があります。回答者は、同じ識別子を持つ提供された拡張機能の最大1つを選択し、その拡張機能を使用できるように、有効な範囲の空き識別子に再マッピングする必要があります（SHOULD）。セクション3で定義されている2つのセグメントタイプも排他的な代替手段であることに注意してください。
If more segment extensions are offered in the valid range, the answerer SHOULD choose those that are desired and place the offered identifier value "as is" in the SDP answer.
有効な範囲でより多くのセグメント拡張が提供される場合、回答者は必要な拡張を選択し、提供された識別子の値をSDP回答に「そのまま」配置する必要があります（SHOULD）。
Similarly, if more segment extensions are offered than can be fit in the valid range, identifiers in the range 4096-4351 MAY be offered; the answerer SHOULD choose those that are desired and remap them to a free identifier in the valid range.
同様に、有効範囲に収まらないほど多くのセグメント拡張が提供される場合、4096〜4351の範囲の識別子が提供される場合があります。回答者は、必要なものを選択し、それらを有効な範囲の空き識別子に再マッピングする必要があります（SHOULD）。
Note that the range 4096-4351 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in the future. Segment extensions with an identifier outside the valid range cannot, of course, be used.
これらのネゴシエーション識別子の範囲4096〜4351は、将来的に有効な識別子の範囲を拡張できるように意図的に制限されていることに注意してください。もちろん、有効範囲外の識別子を持つセグメント拡張は使用できません。
Example:
例：
Note - port numbers, RTP profiles, payload IDs and rtpmaps, etc., have all been omitted for brevity.
注-ポート番号、RTPプロファイル、ペイロードID、rtpmapなどはすべて、簡潔にするために省略されています。
The offer:
オファー：
a=rtcp-xr:mos-metric=calg:4906=P1201_l,calg:4906=P1202_l, calg:
4907=G107
The answerer is interested in transmission P.1202.1 on a lower resolution application, but it doesn't support P.1201.1 on a lower resolution application at all. It is interested in transmission G.107. Therefore, it adjusts the declarations:
回答者は、低解像度アプリケーションでのP.1202.1の送信に関心がありますが、低解像度アプリケーションでのP.1201.1はまったくサポートしていません。送信G.107に関心があります。したがって、宣言を調整します。
a=rtcp-xr:mos-metric=calg:1=P1202_l,calg:2=G107
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 29 in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "MOS Metrics Block".
このドキュメントでは、IANAの「RTP制御プロトコル拡張レポート（RTCP XR）ブロックタイプレジストリ」のブロックタイプ値29を「MOSメトリックブロック」に割り当てています。
This document also registers a new parameter "mos-metric" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry".
このドキュメントでは、「RTP制御プロトコル拡張レポート（RTCP XR）セッション記述プロトコル（SDP）パラメータレジストリ」に新しいパラメータ「mos-metric」も登録しています。
This section contains the information required by [RFC4566] for an SDP attribute.
このセクションには、[RFC4566]がSDP属性に必要とする情報が含まれています。
o contact name, email address: RAI Area Directors <rai-ads@tools.ietf.org>
o 連絡先名、メールアドレス：RAI Area Directors <rai-ads@tools.ietf.org>
o attribute name (as it will appear in SDP): calgextmap
o 属性名（SDPに表示されるとおり）：calgextmap
o long-form attribute name in English: calculation algorithm map definition
o 英語の長い形式の属性名：計算アルゴリズムマップの定義
o type of attribute (session level, media level, or both): both
o 属性のタイプ（セッションレベル、メディアレベル、またはその両方）：両方
o whether the attribute value is subject to the charset attribute: not subject to the charset attribute
o 属性値が文字セット属性の影響を受けるかどうか：文字セット属性の影響を受けない
o a one-paragraph explanation of the purpose of the attribute: This attribute defines the mapping from the local identifier (CAID) in the segment extension defined in Section 3.2 into the calculation algorithm name as documented in specifications and appropriately registered.
o 属性の目的に関する1段落の説明：この属性は、セクション3.2で定義されたセグメント拡張のローカル識別子（CAID）から、仕様に記載され、適切に登録された計算アルゴリズム名へのマッピングを定義します。
o a specification of appropriate attribute values for this attribute: see RFC 7266.
o この属性の適切な属性値の仕様：RFC 7266を参照してください。
This document creates a new registry called "RTCP XR MOS Metric block - multimedia application Calculation Algorithm" as a subregistry of the "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry". This registry applies to the multimedia session where each type of medium is sent in a separate RTP stream and also applies to the session where multi-channel audios are carried in one RTP stream. Policies for this new registry are as follows:
このドキュメントでは、「RTP XR MOSメトリックブロック-マルチメディアアプリケーション計算アルゴリズム」と呼ばれる新しいレジストリを「RTP制御プロトコル拡張レポート（RTCP XR）ブロックタイプレジストリ」のサブレジストリとして作成します。このレジストリは、各タイプのメディアが個別のRTPストリームで送信されるマルチメディアセッションに適用され、マルチチャネルオーディオが1つのRTPストリームで伝送されるセッションにも適用されます。この新しいレジストリのポリシーは次のとおりです。
o The information required to support this assignment is an unambiguous definition of the new metric, covering the base measurements and how they are processed to generate the reported metric.
o この割り当てをサポートするために必要な情報は、新しい測定基準の明確な定義であり、基本測定値と、報告された測定基準を生成するためのそれらの処理方法をカバーしています。
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 identified by entry name and mapped to the local identifier (CAID) in the segment extension defined in Section 3.2.
o レジストリのエントリはエントリ名で識別され、セクション3.2で定義されているセグメント拡張のローカル識別子（CAID）にマップされます。
o Registration Template
o 登録テンプレート
The following information must be provided with each registration:
登録ごとに次の情報を提供する必要があります。
* Name: A string uniquely and unambiguously identifying the calculation algorithm for use in protocols.
* 名前：プロトコルで使用する計算アルゴリズムを一意かつ明確に識別する文字列。
* Name Description: A valid Description of the calculation algorithm Name.
* 名前の説明：計算アルゴリズムの名前の有効な説明。
* Reference: The reference that defines the calculation algorithm corresponding to the Name and Name Description.
* 参照：名前と名前の説明に対応する計算アルゴリズムを定義する参照。
* Type: The media type to which the calculation algorithm is applied
* タイプ：計算アルゴリズムが適用されるメディアタイプ
o Initial assignments are as follows:
o 初期割り当ては次のとおりです。
Name Name Description Reference Type
========= ================================ ========== ====
P564 ITU-T P.564 Compliant Algorithm [P.564] voice
G107 ITU-T G.107 [G.107] voice
TS101_329 ETSI TS 101 329-5 Annex E [ETSI] voice
JJ201_1 TTC JJ201.1 [TTC] voice
G107_1 ITU-T G.107.1 [G.107.1] voice
P862 ITU-T P.862 [P.862] voice
P862_2 ITU-T P.862.2 [P.862.2] voice
P863 ITU-T P.863 [P.863] voice
P1201_1 ITU-T P.1201.1 [P.1201.1] multimedia
P1201_2 ITU-T P.1201.2 [P.1201.2] multimedia
P1202_1 ITU-T P.1202.1 [P.1202.1] video
P1202_2 ITU-T P.1202.2 [P.1202.2] video
The new RTCP XR blocks proposed in this document introduce no new security considerations beyond those described in [RFC3611].
このドキュメントで提案されている新しいRTCP XRブロックは、[RFC3611]で説明されているものを超える新しいセキュリティの考慮事項を導入していません。
This document merges ideas from two documents addressing the MOS Metric Reporting issue. The authors of these documents are listed below (in alphabetical order):
このドキュメントは、MOSメトリックレポートの問題に対処する2つのドキュメントからのアイデアをマージします。これらのドキュメントの作成者を以下に示します（アルファベット順）。
Alan Clark <alan.d.clark@telchemy.com>
Geoff Hunt <r.geoff.hunt@gmail.com>
Martin Kastner <martin.kastner@telchemy.com>
Kai Lee <leekai@ctbri.com.cn>
Roland Schott <roland.schott@telekom.de>
Qin Wu <sunseawq@huawei.com>
Glen Zorn <gwz@net-zen.net>
The authors gratefully acknowledge the comments and contributions made 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, Bill Ver Steeg, David R. Oran, Ted Lemon, Benoit Claise, Pete Resnick, Ali Begen, and Hideaki Yamada.
著者は、ブルース・アダムス、フィリップ・アーデン、アミット・アロラ、ボブ・ビスクナー、ケビン・コナー、クラウス・ダーム、ランディ・エティエ、ロニー・イーブン、ジム・フロウエンタール、アルバート・ヒガシ、トム・ホック、シェーン・ホルトハウス、ポール・ジョーンズ、ラジェシュによるコメントと寄稿に感謝しますクマー、キースランツ、モハメドモスタファ、エイミーペンドルトン、コリンパーキンス、マイクラマーリョ、ラビラビラジ、アルブレヒトシュワルツ、トムテイラー、ビルヴェルスティーグ、デビッドR.オラン、テッドレモン、ベノワクレイズ、ピートレズニック、アリベゲン、山田英明。
[ATSC] Advanced Television Systems Committee, Inc., "Digital Audio Compression Standard (AC-3, E-AC-3) Revision B", ATSC Document A/52B, June 2005.
[ATSC] Advanced Television Systems Committee、Inc。、「Digital Audio Compression Standard（AC-3、E-AC-3）Revision B」、ATSC Document A / 52B、2005年6月。
[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月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[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., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、Ed。、および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月。
[BS.1387-1] ITU-R, "Method for objective measurements of perceived audio quality", ITU-R Recommendation BS.1387-1, 1998-2001.
[BS.1387-1] ITU-R、「知覚されるオーディオ品質の客観的測定方法」、ITU-R推奨BS.1387-1、1998-2001。
[ETSI] ETSI, "TIPHON Release 3; Technology Compliance Specification; Part 5: Quality of Service (QoS) measurement methodologies", ETSI TS 101 329-5 V1.1.1, November 2000.
[ETSI] ETSI、「TIPHONリリース3、テクノロジーコンプライアンス仕様、パート5：サービス品質（QoS）測定方法論」、ETSI TS 101 329-5 V1.1.1、2000年11月。
[G.107] ITU-T, "The E Model, a computational model for use in transmission planning", ITU-T Recommendation G.107, February 2014.
[G.107] ITU-T、「Eモデル、伝送計画で使用するための計算モデル」、ITU-T勧告G.107、2014年2月。
[G.107.1] ITU-T, "Wideband E-model", ITU-T Recommendation G.107.1, December 2011.
[G.107.1] ITU-T、「Wideband E-model」、ITU-T Recommendation G.107.1、2011年12月。
[G.1082] ITU-T, "Measurement-based methods for improving the robustness of IPTV performance", ITU-T Recommendation G.1082, April 2009.
[G.1082] ITU-T、「IPTVパフォーマンスの堅牢性を向上させるための測定ベースの方法」、ITU-T勧告G.1082、2009年4月。
[P.1201.1] ITU-T, "Parametric non-intrusive assessment of audiovisual media streaming quality - Lower resolution application area", ITU-T Recommendation P.1201.1, October 2012.
[P.1201.1] ITU-T、「視聴覚メディアストリーミング品質のパラメトリック非侵入型評価-低解像度アプリケーション領域」、ITU-T勧告P.1201.1、2012年10月。
[P.1201.2] ITU-T, "Parametric non-intrusive assessment of audiovisual media streaming quality - Higher resolution application area", ITU-T Recommendation P.1201.2, October 2012.
[P.1201.2] ITU-T、「視聴覚メディアストリーミング品質のパラメトリック非侵入型評価-高解像度アプリケーション領域」、ITU-T勧告P.1201.2、2012年10月。
[P.1202.1] ITU-T, "Parametric non-intrusive bitstream assessment of video media streaming quality - Lower resolution application area", ITU-T Recommendation P.1202.1, October 2012.
[P.1202.1] ITU-T、「ビデオメディアストリーミング品質のパラメトリック非侵入型ビットストリーム評価-低解像度アプリケーション領域」、ITU-T勧告P.1202.1、2012年10月。
[P.1202.2] ITU-T, "Parametric non-intrusive bitstream assessment of video media streaming quality - Higher resolution application area", ITU-T Recommendation P.1202.2, May 2013.
[P.1202.2] ITU-T、「ビデオメディアストリーミング品質のパラメトリック非侵入型ビットストリーム評価-高解像度アプリケーション領域」、ITU-T勧告P.1202.2、2013年5月。
[P.564] ITU-T, "Conformance testing for narrowband Voice over IP transmission quality assessment models", ITU-T Recommendation P.564, November 2007.
[P.564] ITU-T、「狭帯域Voice over IP伝送品質評価モデルの適合性テスト」、ITU-T勧告P.564、2007年11月。
[P.862] ITU-T, "Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs", ITU-T Recommendation P.862, February 2001.
[P.862] ITU-T、「音声品質の知覚評価（PESQ）：狭帯域電話ネットワークと音声コーデックのエンドツーエンドの音声品質評価の客観的方法」、ITU-T勧告P.862、 2001年2月。
[P.862.1] ITU-T, "Mapping function for transforming P.862 raw result scores to MOS-LQO", ITU-T Recommendation P.862.1, November 2003.
[P.862.1] ITU-T、「P.862の未加工結果スコアをMOS-LQOに変換するためのマッピング機能」、ITU-T勧告P.862.1、2003年11月。
[P.862.2] ITU-T, "Wideband extension to Recommendation P.862 for the assessment of wideband telephone networks and speech codecs", ITU-T Recommendation P.862.2, November 2007.
[P.862.2] ITU-T、「ワイドバンド電話ネットワークと音声コーデックの評価のための勧告P.862への広帯域拡張」、ITU-T勧告P.862.2、2007年11月。
[P.863] ITU-T, "Perceptual objective listening quality assessment", ITU-T Recommendation P.863, January 2011.
[P.863] ITU-T、「知覚的客観的リスニング品質評価」、ITU-T勧告P.863、2011年1月。
[RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for AC-3 Audio", RFC 4184, October 2005.
[RFC4184] Link、B.、Hager、T.、J。Flaks、「RTP Payload Format for AC-3 Audio」、RFC 4184、2005年10月。
[RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, July 2006.
[RFC4598]リンク、B。、「拡張AC-3（E-AC-3）オーディオ用のリアルタイム転送プロトコル（RTP）ペイロード形式」、RFC 4598、2006年7月。
[RFC5188] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec", RFC 5188, February 2008.
[RFC5188] Desineni、H。およびQ. Xie、「拡張可変レートワイドバンドコーデック（EVRC-WB）のRTPペイロード形式とEVRC-Bコーデックのメディアサブタイプの更新」、RFC 5188、2008年2月。
[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月。
[RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, November 2012.
[RFC6792] Wu、Q.、Ed。、Hunt、G。、およびP. Arden、「RTPモニタリングフレームワークの使用に関するガイドライン」、RFC 6792、2012年11月。
[TTC] Telecommunication Technology Committee, "A Method for Speech Quality Assessment for IP Telephony", TTC JJ-201.01 (Japan), November 2013, <http://www.ttc.or.jp/jp/document_list/pdf/j/STD/ JJ-201.01v7.pdf>.
[TTC]電気通信技術委員会、「IPテレフォニーの音声品質評価の方法」、TTC JJ-201.01（日本）、2013年11月、<http://www.ttc.or.jp/jp/document_list/pdf/j / STD / JJ-201.01v7.pdf>。
a. MOS Value Metric
a. MOS値メトリック
* Metric Name: MOS in RTP
* メトリック名：RTPのMOS
* Metric Description: The estimated mean opinion score for multimedia application performance of the RTP stream is defined as including the effects of delay, loss, discard, jitter, and others on audio or video quality.
* メトリックの説明：RTPストリームのマルチメディアアプリケーションパフォーマンスの推定平均オピニオンスコアは、オーディオやビデオの品質に対する遅延、損失、破棄、ジッターなどの影響を含むと定義されています。
* Method of Measurement or Calculation: See Section 3.2.1, MOS value definition.
* 測定または計算の方法：セクション3.2.1、MOS値の定義を参照してください。
* Units of Measurement: See Section 3.2.1, MOS value definition.
* 測定単位：セクション3.2.1、MOS値の定義を参照してください。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, second paragraph.
* 潜在的な測定ドメインを持つ測定ポイント：セクション3の2番目の段落を参照してください。
* Measurement Timing: See Section 3, third paragraph for measurement timing and Section 3.1 for Interval Metric flag.
* 測定タイミング：測定タイミングについてはセクション3、3番目の段落、インターバルメトリックフラグについてはセクション3.1を参照してください。
* Use and applications: See Section 1.4.
* 使用とアプリケーション：セクション1.4を参照してください。
* Reporting model: See RFC 3611.
* レポートモデル：RFC 3611を参照してください。
b. Segment Type Metric
b. セグメントタイプメトリック
* Metric Name: Segment Type in RTP
* メトリック名：RTPのセグメントタイプ
* Metric Description: It is used to identify the segment type of RTP stream used in this report block. For more details, see Section 3.2.1, Segment type definition.
* メトリックの説明：このレポートブロックで使用されるRTPストリームのセグメントタイプを識別するために使用されます。詳細については、セクション3.2.1、セグメントタイプの定義を参照してください。
* Method of Measurement or Calculation: See Section 3.2.1, Segment Type definition.
* 測定または計算の方法：セクション3.2.1、セグメントタイプの定義を参照してください。
* Units of Measurement: See Section 3.2.1, Segment Type definition.
* 測定単位：セクション3.2.1、セグメントタイプの定義を参照してください。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, second paragraph.
* 潜在的な測定ドメインを持つ測定ポイント：セクション3の2番目の段落を参照してください。
* Measurement Timing: See Section 3, third paragraph for measurement timing and Section 3.1 for Interval Metric flag.
* 測定タイミング：測定タイミングについてはセクション3、3番目の段落、インターバルメトリックフラグについてはセクション3.1を参照してください。
* Use and applications: See Section 1.4.
* 使用とアプリケーション：セクション1.4を参照してください。
* Reporting model: See RFC 3611.
* レポートモデル：RFC 3611を参照してください。
c. Calculation Algorithm Identifier Metric
c. 計算アルゴリズム識別子メトリック
* Metric Name: RTP Stream Calculation Algorithm Identifier
* メトリック名：RTPストリーム計算アルゴリズム識別子
* Metric Description: It is the local identifier of RTP Stream calculation Algorithm associated with this segment in the range 1-255 (inclusive).
* メトリックの説明：1〜255の範囲でこのセグメントに関連付けられたRTPストリーム計算アルゴリズムのローカル識別子です。
* Method of Measurement or Calculation: See Section 3.2.1, Calculation Algorithm ID definition.
* 測定または計算の方法：セクション3.2.1、計算アルゴリズムIDの定義を参照してください。
* Units of Measurement: See Section 3.2.1, Calg Algorithm ID definition.
* 測定単位：セクション3.2.1、CalgアルゴリズムIDの定義を参照してください。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, second paragraph.
* 潜在的な測定ドメインを持つ測定ポイント：セクション3の2番目の段落を参照してください。
* Measurement Timing: See Section 3, third paragraph for measurement timing and Section 3.1 for Interval Metric flag.
* 測定タイミング：測定タイミングについてはセクション3、3番目の段落、インターバルメトリックフラグについてはセクション3.1を参照してください。
* Use and applications: See Section 1.4.
* 使用とアプリケーション：セクション1.4を参照してください。
* Reporting model: See RFC 3611.
* レポートモデル：RFC 3611を参照してください。
d. Payload Type Metric
d. ペイロードタイプメトリック
* Metric Name: RTP Payload Type
* メトリック名：RTPペイロードタイプ
* Metric Description: It is used to identify the format of the RTP payload. For more details, see Section 3.2.1, payload type definition.
* メトリックの説明：RTPペイロードの形式を識別するために使用されます。詳細については、セクション3.2.1、ペイロードタイプの定義を参照してください。
* Method of Measurement or Calculation: See Section 3.2.1, Payload type definition.
* 測定または計算の方法：セクション3.2.1、ペイロードタイプの定義を参照してください。
* Units of Measurement: See Section 3.2.1, Payload type definition.
* 測定単位：セクション3.2.1、ペイロードタイプの定義を参照してください。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, second paragraph.
* 潜在的な測定ドメインを持つ測定ポイント：セクション3の2番目の段落を参照してください。
* Measurement Timing: See Section 3, third paragraph for measurement timing and Section 3.1 for Interval Metric flag.
* 測定タイミング：測定タイミングについてはセクション3、3番目の段落、インターバルメトリックフラグについてはセクション3.1を参照してください。
* Use and applications: See Section 1.4.
* 使用とアプリケーション：セクション1.4を参照してください。
* Reporting model: See RFC 3611.
* レポートモデル：RFC 3611を参照してください。
e. Channel Identifier Metric
e. チャネル識別子メトリック
* Metric Name: Audio Channel Identifier in RTP
* メトリック名：RTPのオーディオチャネル識別子
* Metric Description: It is used to identify each audio channel carried in the same RTP stream. For more details, see Section 3.2.2, channel identifier definition.
* メトリックの説明：同じRTPストリームで伝送される各オーディオチャネルを識別するために使用されます。詳細については、セクション3.2.2、チャネル識別子の定義を参照してください。
* Method of Measurement or Calculation: See Section 3.2.2, Channel Identifier definition.
* 測定または計算の方法：セクション3.2.2、チャネル識別子の定義を参照してください。
* Units of Measurement: See Section 3.2.2, Channel Identifier definition.
* 測定単位：セクション3.2.2、チャネル識別子の定義を参照してください。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, second paragraph.
* 潜在的な測定ドメインを持つ測定ポイント：セクション3の2番目の段落を参照してください。
* Measurement Timing: See Section 3, third paragraph for measurement timing and Section 3.1 for Interval Metric flag.
* 測定タイミング：測定タイミングについてはセクション3、3番目の段落、インターバルメトリックフラグについてはセクション3.1を参照してください。
* Use and applications: See Section 1.4.
* 使用とアプリケーション：セクション1.4を参照してください。
* Reporting model: See RFC 3611.
* レポートモデル：RFC 3611を参照してください。
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
Roland Schott Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany
Roland Schott Deutsche Telekom Heinrich-Hertz-Strasse 3-7ダルムシュタットドイツ
EMail: Roland.Schott@telekom.de
Glen Zorn Network Zen 77/440 Soi Phoomjit, Rama IV Road Phra Khanong, Khlong Toie Bangkok 10110 Thailand
Glen Zorn Network Zen 77/440 Soi Phoomjit、Rama IV Road Phra Khanong、Khlong Toie Bangkok 10110 Thailand
Phone: +66 (0) 87 502 4274
EMail: gwz@net-zen.net