summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7266.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7266.txt')
-rw-r--r--doc/rfc/rfc7266.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7266.txt b/doc/rfc/rfc7266.txt
new file mode 100644
index 0000000..e0b68fc
--- /dev/null
+++ b/doc/rfc/rfc7266.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 1]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+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
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 2]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+1. Introduction
+
+1.1. MOS Metrics Report Block
+
+ This document defines a new block type to augment those defined in
+ [RFC3611], for use in a range of RTP applications.
+
+ The new block type provides information on media quality using one of
+ several standard metrics (e.g., mean opinion score (MOS)).
+
+ The metrics belong to the class of application-level metrics defined
+ in [RFC6792].
+
+1.2. RTCP and RTCP XR Reports
+
+ 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].
+
+1.3. Performance Metrics Framework
+
+ 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].
+
+1.4. Applicability
+
+ The MOS Metrics Report Block can be used in any application of RTP
+ for which QoE (Quality-of-Experience) measurement algorithms are
+ defined.
+
+ 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
+
+
+
+Clark, et al. Standards Track [Page 3]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ 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.
+
+ 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 Tuning the content encoder algorithm to satisfy real-time data
+ quality requirements.
+
+ 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 Prequalifying a network to assess its ability to deliver an
+ acceptable end-user-perceived quality level.
+
+2. Terminology
+
+2.1. Standards Language
+
+ 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].
+
+ Notable terminology used is the following.
+
+ Numeric formats X:Y
+
+ where X the number of bits prior to the decimal place and Y the
+ number of bits after the decimal place.
+
+ 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.
+
+ Calculation Algorithm
+
+ Calculation Algorithm is used in this document to mean the MOS
+ or QoE estimation algorithm.
+
+
+
+Clark, et al. Standards Track [Page 4]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+3. MOS Metrics Block
+
+ 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.
+
+ 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).
+
+ 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.
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 5]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+3.1. Report Block Structure
+
+ The MOS Metrics Block has the following format:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.2. Definition of Fields in MOS Metrics Block
+
+ Block type (BT): 8 bits
+
+ The MOS Metrics Block is identified by the constant 29.
+
+ Interval Metric flag (I): 2 bits
+
+ This field is used to indicate whether the MOS Metrics are
+ Sampled, Interval, or Cumulative [RFC6792]:
+
+ I=10: Interval Duration - the reported value applies to the
+ most recent measurement interval duration between
+ successive metrics reports.
+
+ I=11: Cumulative Duration - the reported value applies to the
+ accumulation period characteristic of cumulative
+ measurements.
+
+ I=01: Sampled Value - the reported value is a sampled
+ instantaneous value.
+
+ I=00: Reserved
+
+ 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.
+
+
+
+Clark, et al. Standards Track [Page 6]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ Reserved: 6 bits
+
+ 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).
+
+ Block Length: 16 bits
+
+ The length of this report block in 32-bit words, minus one. For
+ the MOS Metrics Block, the block length is variable length.
+
+ SSRC of source: 32 bits
+
+ As defined in Section 4.1 of [RFC3611].
+
+ Segment i: 32 bits
+
+ 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.
+
+3.2.1. Single-Channel Audio/Video per SSRC Segment
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |S| CAID | PT | MOS Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Segment Type (S): 1 bit
+
+ 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
+
+
+
+Clark, et al. Standards Track [Page 7]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ 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.
+
+ Calculation Algorithm ID (CAID) : 8 bits
+
+ 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.
+
+ Payload Type (PT): 7 bits
+
+ 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.
+
+ 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.
+
+ MOS Value: 16 bits
+
+ 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.
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 8]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+3.2.2. Multi-Channel Audio per SSRC Segment
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |S| CAID | PT |CHID | MOS Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Segment Type (S): 1 bit
+
+ 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
+
+ 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.
+
+ Payload Type (PT): 7 bits
+
+ As defined in Section 3.2.1 of this document
+
+ Channel Identifier (CHID): 3 bits
+
+ 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.
+
+ MOS Value: 13 bits
+
+ 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
+
+
+
+Clark, et al. Standards Track [Page 9]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ (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.
+
+4. SDP Signaling
+
+ [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).
+
+4.1. SDP "rtcp-xr-attrib" Attribute Extension
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 10]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ 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:
+
+ 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.
+
+ 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.
+
+
+
+
+Clark, et al. Standards Track [Page 11]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ The mapping MUST be provided per media stream (in the media-level
+ section(s) of SDP, i.e., after an "m=" line).
+
+ 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.
+
+4.2. Offer/Answer Usage
+
+ 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:
+
+ o asymmetric behavior (segment extensions sent in only one
+ direction),
+
+ o the offer of mutually exclusive alternatives, or
+
+ o the offer of more segments than can be sent in a single session.
+
+ A direction attribute MAY be included in a "calgextmap"; without it,
+ the direction implicitly inherits, of course, from the RTCP stream
+ direction.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Clark, et al. Standards Track [Page 12]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Clark, et al. Standards Track [Page 13]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ 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.
+
+ Example:
+
+ Note - port numbers, RTP profiles, payload IDs and rtpmaps, etc.,
+ have all been omitted for brevity.
+
+ 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:
+
+ a=rtcp-xr:mos-metric=calg:1=P1202_l,calg:2=G107
+
+5. IANA Considerations
+
+ New block types for RTCP XR are subject to IANA registration. For
+ general guidelines on IANA considerations for RTCP XR, refer to
+ [RFC3611].
+
+5.1. New RTCP XR Block Type Value
+
+ 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".
+
+5.2. New RTCP XR SDP Parameter
+
+ This document also registers a new parameter "mos-metric" in the "RTP
+ Control Protocol Extended Reports (RTCP XR) Session Description
+ Protocol (SDP) Parameters Registry".
+
+5.3. The SDP "calgextmap" Attribute
+
+ This section contains the information required by [RFC4566] for an
+ SDP attribute.
+
+ o contact name, email address: RAI Area Directors
+ <rai-ads@tools.ietf.org>
+
+
+
+
+Clark, et al. Standards Track [Page 14]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ o attribute name (as it will appear in SDP): calgextmap
+
+ o long-form attribute name in English: calculation algorithm map
+ definition
+
+ o type of attribute (session level, media level, or both): both
+
+ o whether the attribute value is subject to the charset attribute:
+ not subject to the charset attribute
+
+ 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 a specification of appropriate attribute values for this
+ attribute: see RFC 7266.
+
+5.4. New Registry of Calculation Algorithms
+
+ 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:
+
+ 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 The review process for the registry is "Specification Required" as
+ described in Section 4.1 of [RFC5226].
+
+ 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 Registration Template
+
+ The following information must be provided with each registration:
+
+ * Name: A string uniquely and unambiguously identifying the
+ calculation algorithm for use in protocols.
+
+
+
+
+Clark, et al. Standards Track [Page 15]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ * 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:
+
+ 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
+
+6. Security Considerations
+
+ The new RTCP XR blocks proposed in this document introduce no new
+ security considerations beyond those described in [RFC3611].
+
+7. Contributors
+
+ This document merges ideas from two documents addressing the MOS
+ Metric Reporting issue. The authors of these documents are listed
+ below (in alphabetical order):
+
+ 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>
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 16]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+8. Acknowledgements
+
+ 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.
+
+9. References
+
+9.1. Normative References
+
+ [ATSC] Advanced Television Systems Committee, Inc., "Digital
+ Audio Compression Standard (AC-3, E-AC-3) Revision B",
+ ATSC Document A/52B, June 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
+ and Video Conferences with Minimal Control", STD 65, RFC
+ 3551, July 2003.
+
+ [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
+ "RTP Control Protocol Extended Reports (RTCP XR)", RFC
+ 3611, November 2003.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234, January
+ 2008.
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 17]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ [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.
+
+9.2. Informative References
+
+ [BS.1387-1] ITU-R, "Method for objective measurements of perceived
+ audio quality", ITU-R Recommendation 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.
+
+ [G.107] ITU-T, "The E Model, a computational model for use in
+ transmission planning", ITU-T Recommendation G.107,
+ February 2014.
+
+ [G.107.1] ITU-T, "Wideband E-model", ITU-T Recommendation G.107.1,
+ December 2011.
+
+ [G.1082] ITU-T, "Measurement-based methods for improving the
+ robustness of IPTV performance", ITU-T Recommendation
+ G.1082, April 2009.
+
+ [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.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.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.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.
+
+
+
+
+
+Clark, et al. Standards Track [Page 18]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ [P.564] ITU-T, "Conformance testing for narrowband Voice over IP
+ transmission quality assessment models", ITU-T
+ Recommendation P.564, November 2007.
+
+ [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.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.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.863] ITU-T, "Perceptual objective listening quality
+ assessment", ITU-T Recommendation P.863, January 2011.
+
+ [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format
+ for AC-3 Audio", RFC 4184, October 2005.
+
+ [RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload
+ Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, July
+ 2006.
+
+ [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.
+
+ [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
+ Performance Metric Development", BCP 170, RFC 6390,
+ October 2011.
+
+ [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
+ of the RTP Monitoring Framework", RFC 6792, November
+ 2012.
+
+ [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>.
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 19]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+Appendix A. Metrics Represented Using the Template from RFC 6390
+
+ a. MOS Value Metric
+
+ * Metric Name: MOS in RTP
+
+ * 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.
+
+ * Method of Measurement or Calculation: See Section 3.2.1, MOS
+ value definition.
+
+ * Units of Measurement: See Section 3.2.1, MOS value definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 3, second paragraph.
+
+ * Measurement Timing: See Section 3, third paragraph for
+ measurement timing and Section 3.1 for Interval Metric flag.
+
+ * Use and applications: See Section 1.4.
+
+ * Reporting model: See RFC 3611.
+
+ b. Segment Type Metric
+
+ * Metric Name: Segment Type in 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.
+
+ * Method of Measurement or Calculation: See Section 3.2.1,
+ Segment Type definition.
+
+ * Units of Measurement: See Section 3.2.1, Segment Type
+ definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 3, second paragraph.
+
+ * Measurement Timing: See Section 3, third paragraph for
+ measurement timing and Section 3.1 for Interval Metric flag.
+
+ * Use and applications: See Section 1.4.
+
+
+
+
+Clark, et al. Standards Track [Page 20]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ * Reporting model: See RFC 3611.
+
+ c. Calculation Algorithm Identifier Metric
+
+ * Metric Name: RTP Stream Calculation Algorithm Identifier
+
+ * Metric Description: It is the local identifier of RTP Stream
+ calculation Algorithm associated with this segment in the range
+ 1-255 (inclusive).
+
+ * Method of Measurement or Calculation: See Section 3.2.1,
+ Calculation Algorithm ID definition.
+
+ * Units of Measurement: See Section 3.2.1, Calg Algorithm ID
+ definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 3, second paragraph.
+
+ * Measurement Timing: See Section 3, third paragraph for
+ measurement timing and Section 3.1 for Interval Metric flag.
+
+ * Use and applications: See Section 1.4.
+
+ * Reporting model: See RFC 3611.
+
+ d. Payload Type Metric
+
+ * Metric Name: RTP Payload Type
+
+ * Metric Description: It is used to identify the format of the
+ RTP payload. For more details, see Section 3.2.1, payload type
+ definition.
+
+ * Method of Measurement or Calculation: See Section 3.2.1,
+ Payload type definition.
+
+ * Units of Measurement: See Section 3.2.1, Payload type
+ definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 3, second paragraph.
+
+ * Measurement Timing: See Section 3, third paragraph for
+ measurement timing and Section 3.1 for Interval Metric flag.
+
+ * Use and applications: See Section 1.4.
+
+
+
+
+Clark, et al. Standards Track [Page 21]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+ * Reporting model: See RFC 3611.
+
+ e. Channel Identifier Metric
+
+ * Metric Name: Audio Channel Identifier in 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.
+
+ * Method of Measurement or Calculation: See Section 3.2.2,
+ Channel Identifier definition.
+
+ * Units of Measurement: See Section 3.2.2, Channel Identifier
+ definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 3, second paragraph.
+
+ * Measurement Timing: See Section 3, third paragraph for
+ measurement timing and Section 3.1 for Interval Metric flag.
+
+ * Use and applications: See Section 1.4.
+
+ * Reporting model: See RFC 3611.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 22]
+
+RFC 7266 RTCP XR MOS Report Blocks June 2014
+
+
+Authors' Addresses
+
+ 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
+
+ EMail: sunseawq@huawei.com
+
+
+ Roland Schott
+ Deutsche Telekom
+ Heinrich-Hertz-Strasse 3-7
+ Darmstadt 64295
+ Germany
+
+ EMail: Roland.Schott@telekom.de
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 23]
+