doc: Add RFC documents

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]
+