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
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
用于平均意见分数（MOS）度量报告的RTP控制协议（RTCP）扩展报告（XR）块
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）块，包括两种新的段类型和相关的会话描述协议（SDP）参数，允许报告平均意见分数（MOS）指标，以在一系列RTP应用中使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
本文件定义了一种新的块类型，以扩充[RFC3611]中定义的块类型，用于一系列RTP应用。
The new block type provides information on media quality using one of several standard metrics (e.g., mean opinion score (MOS)).
新的块类型使用多个标准度量之一（例如，平均意见分数（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].
[RFC3550]中定义了使用RTCP进行报告。RFC 3611定义了使用RTCP扩展报告（XR）进行报告的可扩展结构。本文档定义了一个新的扩展报告块，用于[RFC3550]和[RFC3611]。
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（体验质量）测量算法的任何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
影响实时音频/视频应用程序质量的因素可分为两类。第一类包括特定于传输的因素，如数据包丢失、延迟和抖动（这也会转化为播放缓冲区中的丢失）。第二类因素包括与内容和编解码器相关的因素，如编解码器类型和丢失恢复技术、编码比特率、分组方案和内容特征
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.0到255.996范围内的无符号数，粒度为0.0039。0:16表示范围为0.0到1-1/65536=0.9999847的适当二进制分数，但请注意，在数值范围顶部使用标志值会略微降低此上限。例如，如果16位值0XFFFE和0XFFFF用作“超出范围”和“不可用”条件的标志，则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.
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流范围之外的参数的MOS，例如，信令性能、平均修复时间（MTTR）或可能影响整体用户体验的其他因素。
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流的接收端测量。此度量块的实例按同步源（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.
此度量块依赖于度量信息块中指示报告范围的度量周期。发送方必须在与测量信息块相同的复合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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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度量块，块长度为可变长度。
SSRC of source: 32 bits
源的SSRC：32位
As defined in Section 4.1 of [RFC3611].
如[RFC3611]第4.1节所定义。
Segment i: 32 bits
第一段：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.
本文件中定义了两种段类型：每个SSRC段的单声道音频/视频和每个SSRC段的多声道音频。每个SSRC段的多通道音频用于处理多通道音频流在一个RTP流中承载的情况，而每个SSRC段的单通道音频/视频用于处理每个媒体流由SSRC识别并在单独的RTP流中发送的情况。段的最左边的位确定其类型。如果段的最左端位为零，则为单通道段。如果最左边的位是1，则它是多声道音频段。请注意，同一度量块中不能存在两种线段类型。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Segment Type (S): 1 bit
段类型：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
此字段用于标识此报告块中使用的段类型。零表示每个SSRC段的单通道音频/视频。单通道意味着一个RTP流中只携带一个媒体流。每个SSRC段的单通道音频/视频可用于报告与SSRC标识的媒体流相关联的MOS值。如果有多个媒体流，并且它们希望使用每个SSRC段的单通道音频/视频来报告MOS值，则应在单独的RTP流中携带它们，每个流由不同的SSRC标识。在这种情况下，需要多个MOS度量块
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.
需要在同一RTCP XR数据包中使用每个SSRC段的单通道音频/视频报告每个媒体流对应的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有效负载类型发送单独的报告，并使用相应的测量信息块指示其相关的时间段。
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值，允许MOS分数在整数部分达到127。MOS范围定义为MOS估计算法规范（本文件中的计算算法）的一部分，通常为1-5、0-10或0-100等范围。保留两个值：0xFFFE值表示测量值超出范围，0xFFFF值表示测量值不可用。超出计算算法定义范围的值（两个保留值除外）不得发送，且接收系统必须忽略。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT |CHID | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT |CHID | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Segment Type (S): 1 bit
段类型：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.
此字段用于标识此报告块中使用的段类型。其中一个将其标识为多声道音频段。
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.
如果在一个RTP流中承载多个音频通道，则每个音频通道将被视为独立通道（例如，左通道音频、右通道音频）。此字段用于标识同一媒体流中承载的每个频道。默认通道映射遵循[RFC3551]第4.1节中描述的静态排序规则。然而，有些有效载荷格式使用不同的信道映射，例如，AC-3音频通过RTP[RFC4184]仅遵循[ATSC]中定义的AC-3信道顺序方案。RTP上的增强AC-3音频[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
多媒体应用程序性能的估计MOS定义为包括延迟、丢失、丢弃、抖动和其他可能影响媒体质量的影响。这是一个代表MOS的无符号定点7:6值，允许MOS分数在整数部分达到127。MOS范围定义为MOS估计算法规范的一部分
(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.
（本文档中的计算算法），通常为1-5、0-10或0-100等范围。保留两个值：0x1FFE表示超出范围，0x1FFF表示测量不可用。超出计算算法定义范围的值（两个保留值除外）不得发送，且接收系统必须忽略。
[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]定义了SDP[RFC4566]用于发送XR块使用的信号。然而，可以在没有事先信令的情况下使用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格式”中，语法元素“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)
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>]
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
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必须是唯一的，并且对于流中的每个流或每个通道仅使用一次。
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”引用媒体分辨率相对引用，有三个值“l”、“m”、“h”。（例如，窄带（3.4 kHz）语音和标准清晰度（SD）或低分辨率视频具有“l”分辨率，超宽带（>14 kHz）语音或更高分辨率和高分辨率（HD）或更高分辨率视频具有“h”分辨率，宽带语音（7 kHz）和分辨率介于SD和HD之间的视频具有“m”分辨率）。MOS度量块中报告的MOS可能随MOS参考而变化；例如，窄带、宽带、超宽带编解码器的MOS值占据相同的范围，但应以不同的值报告。对于视频应用，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报价/应答用法适用。在提供/应答上下文中，上述信令可以三种方式使用：
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应答中标记为“RecvoOnly”。不希望收到延期或不理解延期的回答者不应将其包括在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报价中的段扩展标记为“RecvoOnly”，且应答人希望发送，则该扩展必须在SDP应答中标记为“sendonly”。不希望或无法发送分机的应答者不应将其包含在SDP应答中。
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以修改或添加该段扩展的方向限定符。
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.
calgextmap中可能包含“mosref”属性和“MOS类型”属性；如果不存在，“mosref”和“MOS类型”必须在名称属性引用的QoE估计算法中定义（例如，P.1201.1[P.1201.1]表示使用的分辨率较低，而P.1201.2[P.1201.2]表示使用的分辨率较高）或段扩展中携带的有效负载类型（例如，EVRC-WB[RFC5188]表示使用宽带编解码器）。但是，并非所有有效负载类型或MOS算法名称都指示要使用的分辨率和MOS类型。如果回答者收到不支持的带有“mosref”属性值的报价（例如，回答者仅支持“l”并从报价人处收到“h”），则回答者应拒绝报价人提供的mosref属性值。
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范围内的值。被拒绝的答案必须包含一个“mosref”属性，其值为SDP报价的值。
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).
报价或应答中有效范围（包括）内的本地标识符在每个媒体部分不得使用一次以上。会话更新可能会更改正在使用的段扩展的方向限定符。会话更新可以添加或删除段扩展。有效范围内的标识符值不得更改（重新映射）。
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中具有相同标识符的多个段扩展；应答者应最多选择一个具有相同标识符的扩展，并将其重新映射到有效范围内的自由标识符，以使该扩展可用。请注意，第3节中定义的两种管段类型也是唯一的备选方案。
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应答中。
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范围内的标识符；回答者应选择所需的，并将其重新映射到有效范围内的自由标识符。
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
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
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公制”。
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区域主管<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 属性值是否受charset属性约束：不受charset属性约束
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 该属性用途的一段解释：该属性定义了从第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:
本文档创建了一个名为“RTCP XR MOS度量块-多媒体应用程序计算算法”的新注册表，作为“RTP控制协议扩展报告（RTCP XR）块类型注册表”的子注册表。此注册表适用于多媒体会话，其中每种类型的媒体在单独的RTP流中发送，也适用于多声道音频在一个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
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].
除[RFC3611]中所述的安全注意事项外，本文件中提出的新RTCP XR块未引入任何新的安全注意事项。
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度量报告问题的文件中的观点。这些文件的作者如下（按字母顺序排列）：
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>
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.
作者感谢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、，阿尔布雷希特·施瓦兹、汤姆·泰勒、比尔·弗斯泰格、大卫·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]高级电视系统委员会，“数字音频压缩标准（AC-3，E-AC-3）B版”，ATSC文件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：实时应用的传输协议”，STD 64，RFC 35502003年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]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年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：会话描述协议”，RFC4566，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，“在RFCs中编写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]Clark，A.和Q.Wu，“使用源描述（SDES）项和RTCP扩展报告（XR）块的测量标识和信息报告”，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-11998-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.119000年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，“宽带电子模型”，ITU-T建议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.11912年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，“窄带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，“AC-3音频的RTP有效载荷格式”，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）有效载荷格式”，RFC4598，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]Desinini，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 63902011年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节第二段。
* 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节第二段。
* 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).
* 度量说明：与该段关联的RTP流计算算法的本地标识符，范围为1-255（含1-255）。
* 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节，计算算法ID定义。
* Measurement Point(s) with Potential Measurement Domain: See Section 3, second paragraph.
* 具有潜在测量域的测量点：见第3节第二段。
* 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节第二段。
* 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节第二段。
* 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，美国佐治亚州德卢斯280号套房，邮编30097
EMail: alan.d.clark@telchemy.com
EMail: alan.d.clark@telchemy.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区华为软件大道101号秦武210012
EMail: sunseawq@huawei.com
EMail: sunseawq@huawei.com
Roland Schott Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany
罗兰·肖特德国电信海因里希·赫兹大街3-7号达姆施塔特64295德国
EMail: Roland.Schott@telekom.de
EMail: Roland.Schott@telekom.de
Glen Zorn Network Zen 77/440 Soi Phoomjit, Rama IV Road Phra Khanong, Khlong Toie Bangkok 10110 Thailand
泰国曼谷Khlong Toie Phra Khanong Rama IV路Soli Phoomjit 77/440号Glen Zorn Network Zen邮编：10110
Phone: +66 (0) 87 502 4274
EMail: gwz@net-zen.net
Phone: +66 (0) 87 502 4274
EMail: gwz@net-zen.net