draft-ietf-xrblock-rtcp-xr-qoe-03.txt   draft-ietf-xrblock-rtcp-xr-qoe-04.txt 
Network Working Group A. Clark Network Working Group A. Clark
Internet-Draft Telchemy Internet-Draft Telchemy
Intended status: Standards Track Q. Wu Intended status: Standards Track Q. Wu
Expires: April 21, 2013 Huawei Expires: August 29, 2013 Huawei
R. Schott R. Schott
DT DT
G. Zorn G. Zorn
Network Zen Network Zen
October 18, 2012 February 25, 2013
RTP Control Protocol (RTCP) Extended Report (XR) Blocks for QoE Metric RTP Control Protocol (RTCP) Extended Report (XR) Blocks for QoE Metric
Reporting Reporting
draft-ietf-xrblock-rtcp-xr-qoe-03 draft-ietf-xrblock-rtcp-xr-qoe-04
Abstract Abstract
This document defines an RTP Control Protocol (RTCP) Extended Report This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block including two new segment types and associated SDP (XR) Block including two new segment types and associated SDP
parameters that allow the reporting of QoE metrics for use in a range parameters that allow the reporting of QoE metrics for use in a range
of RTP applications. of RTP applications.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1.1. QoE Metrics Report Block . . . . . . . . . . . . . . . . . 3 1.1. QoE Metrics Report Block . . . . . . . . . . . . . . . . . 3
1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3
1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4
3. QoE Metrics Block . . . . . . . . . . . . . . . . . . . . . . 5 3. QoE Metrics Block . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 5 3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 5
3.2. Definition of Fields in QoE Metrics Block . . . . . . . . 6 3.2. Definition of Fields in QoE Metrics Block . . . . . . . . 6
3.2.1. Single Stream per SSRC Segment . . . . . . . . . . . . 7 3.2.1. Single Stream per SSRC Segment . . . . . . . . . . . . 7
3.2.2. Multi-Channel audio per SSRC Segment . . . . . . . . . 9 3.2.2. Multi-Channel audio per SSRC Segment . . . . . . . . . 8
4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 9
5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 11 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 11
5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.3. Contact information for registrations . . . . . . . . . . 11 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 12
5.4. New registry of calculation algorithms for single 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 13
stream segment . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Contact information for registrations . . . . . . . . . . 13
5.5. New registry of calculation algorithms for 5.4. New registry of calculation algorithms . . . . . . . . . . 13
multi-channel audio segment . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Evaluation Example of User Quality of Experience
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 for video stream . . . . . . . . . . . . . . . . . . 16
A.1. draft-ietf-xrblock-rtcp-xr-qoe-03 . . . . . . . . . . . . 15 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
A.2. draft-ietf-xrblock-rtcp-xr-qoe-02 . . . . . . . . . . . . 15 B.1. draft-ietf-xrblock-rtcp-xr-qoe-04 . . . . . . . . . . . . 17
A.3. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 15 B.2. draft-ietf-xrblock-rtcp-xr-qoe-03 . . . . . . . . . . . . 17
A.4. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 16 B.3. draft-ietf-xrblock-rtcp-xr-qoe-02 . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 B.4. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 17
B.5. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
1.1. QoE Metrics Report Block 1.1. QoE Metrics Report Block
This document defines a new block type to augment those defined in This document defines a new block type to augment those defined in
[RFC3611], for use in a range of RTP applications. [RFC3611], for use in a range of RTP applications.
The new block type provides information on multimedia quality using The new block type provides information on multimedia quality using
one of several standard metrics. one of several standard metrics.
The metrics belong to the class of application level metrics defined The metrics belong to the class of application level metrics defined
in [MONARCH]. in [RFC6792].
1.2. RTCP and RTCP XR Reports 1.2. RTCP and RTCP XR Reports
The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
defined an extensible structure for reporting using an RTCP Extended defined an extensible structure for reporting using an RTCP Extended
Report (XR). This draft defines a new Extended Report block for use Report (XR). This draft defines a new Extended Report block for use
with [RFC3550] and [RFC3611]. with [RFC3550] and [RFC3611].
1.3. Performance Metrics Framework 1.3. Performance Metrics Framework
The Performance Metrics Framework [RFC6390] provides guidance on the The Performance Metrics Framework [RFC6390] provides guidance on the
definition and specification of performance metrics. The RTP definition and specification of performance metrics. The RTP
Monitoring Architectures [MONARCH] provides guideline for reporting Monitoring Architectures [RFC6792] provides guideline for reporting
block format using RTCP XR. The XR Block described in this document block format using RTCP XR. The XR Block described in this document
are in accordance with the guidelines in [RFC6390] and [MONARCH]. are in accordance with the guidelines in [RFC6390] and [RFC6792].
1.4. Applicability 1.4. Applicability
The QoE Metrics Report Block can be used in any application of RTP The QoE Metrics Report Block can be used in any application of RTP
for which QoE measurement algorithms are defined. for which QoE measurement algorithms are defined.
The factors that affect real-time AV application quality can be split The factors that affect real-time AV application quality can be split
into two categories. The first category consists of transport- into two categories. The first category consists of transport-
dependent factors such as packet loss, delay and jitter (which also dependent factors such as packet loss, delay and jitter (which also
translates into losses in the playback buffer). The factors in the translates into losses in the playback buffer). The factors in the
skipping to change at page 5, line 22 skipping to change at page 5, line 22
service. Multimedia application QoE metric is commonly expressed as service. Multimedia application QoE metric is commonly expressed as
a MOS ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which a MOS ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which
5 represents excellent and 1 represents unacceptable. MOS scores are 5 represents excellent and 1 represents unacceptable. MOS scores are
usually obtained using subjective testing or using objective usually obtained using subjective testing or using objective
algorithm. However Subjective testing to estimate the multimedia algorithm. However Subjective testing to estimate the multimedia
quality may be not suitable for measuring the multimedia quality quality may be not suitable for measuring the multimedia quality
since the results may vary from test to test. Therefore using since the results may vary from test to test. Therefore using
objective algorithm to calculate MOS scores is recommended. ITU-T objective algorithm to calculate MOS scores is recommended. ITU-T
recommendations define the methodologies for assessment of the recommendations define the methodologies for assessment of the
performance of multimedia stream performance of multimedia stream
[G.107][P.564][G.1082][P.1201][P.1202] and provides a method to [G.107][P.564][G.1082][P.1201.1][P.1201.2][P.1202.1][P.NBAMS-HR] and
evaluate QoE estimation algorithms and objective model for video and provides a method to evaluate QoE estimation algorithms and objective
audio. Hence this document recommends vendors and implementers to model for video and audio. Hence this document recommends vendors
use these International Telecommunication Union (ITU)-specified and implementers to use these International Telecommunication Union
methodologies to measure parameters when possible. (ITU)-specified methodologies to measure parameters when possible.
Editor's note: P.NAMS and P.NBAMS are replaced with P.1201 and
P.1202. However P.1201 is further splitted into P.1201.1 and
P.1201.2 and P.1202 is futher splitted into P.1202.1 and P.1202.2.
So shall we reference parent document P.1201 and P.1202 or
reference derived documents P.1201.1,P.1201.2, P.1202.1,P.1202.2?
3.1. Metric Block Structure 3.1. Metric Block Structure
The report block contents are dependent upon a series of flag bits The report block contents are dependent upon a series of flag bits
carried in the first part of the header. Not all parameters need to carried in the first part of the header. Not all parameters need to
be reported in each block. Flags indicate which are and which are be reported in each block. Flags indicate which are and which are
not reported. The fields corresponding to unreported parameters MUST not reported. The fields corresponding to unreported parameters MUST
be present, but are set to zero. The receiver MUST ignore any QoE be present, but are set to zero. The receiver MUST ignore any QoE
Metrics Block with a non-zero value in any field flagged as Metrics Block with a non-zero value in any field flagged as
unreported. The encoding of QoE metrics block payload consists of a unreported. The encoding of QoE metrics block payload consists of a
series of 32 bit units called segments that describe MOS Type, MoS series of 32 bit units called segments that describe MOS Type, MoS
algorithm and MoS value. algorithm and MoS value.
Editor's note: MOS values for narrowband, wideband, super wideband
and fullband codecs; these MOS values occupy the same range. For
video application,MoS values for SD resolution, HD resolution
video also occupy the same ranges and hence the QoE block needs to
indicate what the MOS reference is.
Editor's Note: If we add MoS reference concept, 32 bit segment is
not sufficient. Therefore it was suggested to expand 32 bit
segment into 48 bit segment to support MoS reference feature.
The QoE Metrics Block has the following format: The QoE Metrics Block has the following format:
0 1 2 3 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 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=QMB | I | Reserved | Block Length | | BT=QMB | I | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 1 | | Segment 1 |
skipping to change at page 7, line 22 skipping to change at page 7, line 13
As defined in Section 4.1 of [RFC3611]. As defined in Section 4.1 of [RFC3611].
Segment i: 32 bits Segment i: 32 bits
There are two segment types defined in this document: single There are two segment types defined in this document: single
stream per SSRC segment, multi-channel audio per SSRC segment. stream per SSRC segment, multi-channel audio per SSRC segment.
Multi-channel audio per SSRC segment is used to deal with the case Multi-channel audio per SSRC segment is used to deal with the case
where Multi-channel audios are carried in one RTP stream while where Multi-channel audios are carried in one RTP stream while
single stream per SSRC segment is used to deal with the case where single stream per SSRC segment is used to deal with the case where
each media stream is identified by SSRC and sent in separate RTP each media stream is identified by SSRC and sent in separate RTP
stream. The left two bits of the section determine its type. If stream. The leftmost bit of the segment determines its type. If
the leftmost bit of the segment is zero, then it is single stream the leftmost bit of the segment is zero, then it is single stream
segment. If the leftmost bit is one, then it is multi-channel segment. If the leftmost bit is one, then it is multi-channel
audio segment. Note that two segment types can not be present in audio segment. Note that two segment types can not be present in
the same metric block. the same metric block.
3.2.1. Single Stream per SSRC Segment 3.2.1. Single Stream per SSRC Segment
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| MT |CAlg | PT |Rsv. | MOS Value | |S| CAID | PT | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+----------------------------+--------------------------------------+
| Editor's Note: If we add | Editor's Note: Shall we need to |
| MoS reference concept, we | support MoS Scaling concept in the |
| should give a definition | future draft? One point on the list |
| of MoS reference which | is MoS Scaling concept is implicitly |
| covers both audio | used within the industry when |
| application and video | quoting MOS scores for codecs and |
| application. | measurements. |
+----------------------------+--------------------------------------+
Segment Type (S): 1 bit Segment Type (S): 1 bit
This field is used to identify the segment type used in this This field is used to identify the segment type used in this
report block. A zero identifies this as a single stream segment. report block. A zero identifies this as a single stream segment.
Single stream means there is only one media stream carried in one Single stream means there is only one media stream carried in one
RTP stream. The single stream segment can be used to report the RTP stream. The single stream segment can be used to report the
MoS value associated with this media stream identified by SSRC. MoS value associated with the media stream identified by SSRC. If
If there are multiple media streams and they want to use the there are multiple media streams and they want to use the single
single stream per SSRC segment to report the MOS value, they stream per SSRC segment to report the MOS value, they should be
should be carried in the separate RTP streams with different SSRC. carried in the separate RTP streams with each identified by
In this case, multiple QoE Metrics Blocks are required to report different SSRC. In this case, multiple QoE Metrics Blocks are
the MOS value corresponding to each media stream using single required to report the MOS value corresponding to each media
stream segment. stream using single stream segment in the same RTCP XR packet.
MoS Type (MT): 4 bits
This field is used to indicate the MOS type to be reported. The
MOS type is defined as follows:
0000 MOS-LQ - Listening Quality MoS.
0001 MOS-CQ - Conversation Quality MoS.
0010 MOS-A - Audio Quality MOS.
0010 MOS-V - Video Quality MOS.
0011 MOS-AV - Audio-Video Quality MOS.
0100~1111 - Reserved for future definitions.
MoS-LQ measures the quality of audio for listening purposes only
while MoS-CQ measures the quality of audio for conversation
purpose only. MoS-A,MoS-V and MoS-AV measures the quality of
audio application, the quality of video application and Audio-
Video application respectively. Both MoS-LQ and MoS-CQ are
commonly used in VoIP applications. MOS-LQ uses either wideband
audio codec or narrowband audio codec, or both and does not take
into account any of bidirectional effects, such as delay and echo.
MOS-CQ uses narrowband codec and takes into account listening
quality in each direction, as well as the bidirectional effects.
Calculation Algorithm (CALg):3 bits
000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice)
001 - G.107 [G.107] (Voice)
010 - ETSI TS 101 329-5 Annex E [ ETSI] (Voice)
011 - TTC JJ201.01 [TTC] (Voice)
100 - ITU-T P.1201 [P.1201] (Multimedia)
101 - ITU-T P.1202 [P.1202] (Video)
110~111 - Reserved for future extension.
G.107 and P.564 and ETSI TS101 329-5 specify three Calculation Calg Algorithm ID (CAID) : 8bits
algorithms or MoS algorithms that are used to estimate speech
quality or conversation quality. P.NAMS and P.NBAMS specify two
MoS algorithms that are used to estimate multimedia quality
including video quality, audio quality and audio-video quality.
If MoS type is MoS-LQ and MoS-CQ, the MoS value can be calculated
based on ITU-T G.107[G.107], ITU-T P.564 [P.564]or ETSI TS 101
329-5 [ETSI], if the Mos type is MoS-V or MoS-AV, the Mos value
can be calculated based on ITU-T P.NAMS [P.1201]or ITU-T P.NBAMS
[P.1202]. If new MOS types are defined, they can be added by an The 8-bit CAID is the local identifier of calculation algorithm
update to this document. If the receiver does not understand the associated with this segment in the range 1-255 inclusive.
MOS type defined in this document it should discard this report.
If MoS Type does not match the MoS algorithm in the report (e.g.,
specify a voice MOS algorithm for a video quality MOS), the
receiver should also discard this report.
Payload Type (PT): 7 bits Payload Type (PT): 7 bits
QoE metrics reporting depends on the payload format in use. This QoE metrics reporting depends on the payload format in use. This
field identifies the format of the RTP payload. For RTP sessions field identifies the format of the RTP payload. For RTP sessions
where multiple payload formats can be negotiated or the payload where multiple payload formats can be negotiated or the payload
format changes during the mid-session), the value of this field format changes during the mid-session), the value of this field
will be used to indicate what payload format was in use for the will be used to indicate what payload format was in use for the
reporting interval. reporting interval.
Rsd.:3 bits MOS Value: 16 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
MUST be ignored by the receiver.
MOS Value: 14 bits
The estimated mean opinion score for multimedia application The estimated mean opinion score for multimedia application
quality is defined as including the effects of delay,loss, quality is defined as including the effects of delay,loss,
discard,jitter and other effects that would affect multimedia discard,jitter and other effects that would affect multimedia
quality . It is expressed in numeric format 6:8 with the value in quality . It is expressed in numeric format 8:8 with the value in
the range 0.0 to 63.996. The valid the measured value ranges from the range 0.0 to 255.996. The valid the measured value ranges
0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the
measured value is over ranged, the value 0xFFFE SHOULD be reported measured value is over ranged, the value 0xFFFE MUST be reported
to indicate an over-range measurement. If the measurement is to indicate an over-range measurement. If the measurement is
unavailable, the value 0xFFFF SHOULD be reported. Values other unavailable, the value 0xFFFF MUST be reported. Values other than
than 0xFFFE,0xFFFF and the valid range defined above MUST NOT be 0xFFFE,0xFFFF and the valid range defined above MUST NOT be sent
sent and MUST be ignored by the receiving system. and MUST be ignored by the receiving system.
3.2.2. Multi-Channel audio per SSRC Segment 3.2.2. Multi-Channel audio per SSRC Segment
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| MT |CAlg | PT |CHID | MOS Value | |S| CAID | PT |CHID | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Segement Type (S): 1 bit Segement Type (S): 1 bit
This field is used to identify the segment type used in this This field is used to identify the segment type used in this
report block. A one identifies this as a multi-channel audio report block. A one identifies this as a multi-channel audio
segment. segment.
Media Type (M): 1bit CAlg Algorithm ID (CAID) : 8bits
A zero identifies this as a multi-channel per SSRC segment.
MoS Type (MT): 4 bits
As defined in Section 3.2.1 of this document. If the value of
this field is not corresponding to MoS-CQ or MoS-LQ, the receiver
using multi-channel segment should discard this invalid segment
with the wrong MoS Type.
Calculation Algorithm (CALg):3 bits
000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice) The 8-bit ID is the local identifier of this segment in the range
001 - G.107 [G.107] (Voice) 1-255 inclusive.
010 - ETSI TS 101 329-5 Annex E, [ ETSI] (Voice)
011 - TTC JJ201.01 [TTC] (Voice)
100~111 - Reserved for future extension.
Payload Type (PT): 7 bits Payload Type (PT): 7 bits
As defined in Section 3.2.1 of this document. As defined in Section 3.2.1 of this document.
Channel Identifier (CHID): 3 bits Channel Identifier (CHID): 3 bits
If multiple channels of audio are carried in one RTP stream, each If multiple channels of audio are carried in one RTP stream, each
channel of audio will be viewed as a independent channel(e.g., channel of audio will be viewed as a independent channel(e.g.,
left channel audio, right channel audio). This field is used to left channel audio, right channel audio). This field is used to
identify each channel carried in the same media stream. The identify each channel carried in the same media stream. The
default Channel mapping follows static ordering rule described in default Channel mapping follows static ordering rule described in
the section 4.1 of [RFC3551]. However there are some payload the section 4.1 of [RFC3551]. However there are some payload
formats that use different channel mappings, e.g., AC-3 audio over formats that use different channel mappings, e.g., AC-3 audio over
RTP [RFC4184] only follow AC-3 channel order scheme defined in RTP [RFC4184] only follow AC-3 channel order scheme defined in
[ATSC]. Enhanced AC-3 Audio over RTP [RFC4598] uses dynamic [ATSC]. Enhanced AC-3 Audio over RTP [RFC4598] uses dynamic
channel transform mechanism. In order that the appropriate channel transform mechanism. In order that the appropriate
channel mapping can be determined, QoE reports need to be tied to channel mapping can be determined, QoE reports need to be tied to
an RTP payload format, i.e., including the payload type of the an RTP payload format, i.e., including the payload type of the
reported media according to [MONARCH] and using Payload Type to reported media according to [RFC6792] and using Payload Type to
determine the appropriate channel mapping. determine the appropriate channel mapping.
Rsd.:3 bits MOS Value: 13 bits
This field is reserved for future definition. In the absence of The estimated mean opinion score for multimedia application
such a definition, the bits in this field MUST be set to zero and quality is defined as including the effects of delay,loss,
MUST be ignored by the receiver. discard,jitter and other effects that would affect multimedia
quality . It is expressed in numeric format 6:7 with the value in
the range 0.0 to 63.992. The valid the measured value ranges from
0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the
measured value is over ranged, the value 0x1FFE MUST be reported
to indicate an over-range measurement. If the measurement is
unavailable, the value 0x1FFF MUST be reported. Values other than
0x1FFE,0x1FFF and the valid range defined above MUST NOT be sent
and MUST be ignored by the receiving system.
MOS Value: 14 bits 4. SDP Signaling
As defined in Section 3.2.1 of this document. [RFC3611] defines the use of SDP (Session Description Protocol)
[RFC4566] for signaling the use of XR blocks. However XR blocks MAY
be used without prior signaling (see section 5 of RFC3611).
4. SDP Signaling 4.1. SDP rtcp-xr-attrib Attribute Extension
One new parameter is defined for the report block defined in this This section augments the SDP [RFC4566] attribute "rtcp-xr" defined
document to be used with Session Description Protocol (SDP) [RFC4566] in [RFC3611] by providing an additional value of "xr-format" to
using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the signal the use of the report block defined in this document. Within
following syntax within the "rtcp-xr" attribute [RFC3611]: the "xr-format", the syntax element "extmap" 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 extensionattributes are defined
by the specification that defines a specific extension name; there
may be several.
xr-format = qoe-metrics xr-format =/ xr-qoe-block
qoe-metrics = "QoE metrics" xr-qoe-block = "qoe-metrics" ["=" extmap *("," extmap)]
extmap = mapentry "=" extensionname [SP extentionattributes]
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
mapentry = "calg:" 1*5 DIGIT ["/" direction]
extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564]
/ "G107";ITU-T G.107 [G.107]
/ "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI]
/"JJ201_01 ";TTC JJ201.01 [TTC]
/"P1201_01";ITU-T P.1201.2 [P.1201.1]
/"P1201_02";ITU-T P.1201.2 [P.1201.2]
/"P1202_01";ITU-T P.1202.1 [P.1202.1]
/"P1202_02";ITU-T P. NBAMS-HR [P.NBAMS-HR]
/ non-ws-string
extentionattributes = mediatype
/mosreference
/attributes-ext
mediatype = "a" ;voice
/ "v" ;video
/"m" ;multimedia
mosreference = "mosref=" ("0"; lower resolution
/ "1";higher resolution
/ 1*2DIGIT ) ;Value 2~15 are valid and
;reserved for future use
attributes-ext = non-ws-string
SP = <Define in RFC5234>
DIGIT = <as defined in Section 3.4 of [RFC5234]>
non-ws-string = 1*(%x21-FF)
Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description Each local identifier (CAID)of calculation algorithm used in the
and the full syntax of the "rtcp-xr" attribute. segment defined in the section 3.2 is mapped to a string using an
attribute of the form:
a=extmap:<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 = 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.
The mapping MUST be provided per media stream (in the media-level
section(s) of SDP, i.e., after an "m=" line).
Note that the syntax element "mosreference" is referred to the media
resolution(e.g., Narrowband (3.4kHz) Speech and Standard Definition
(SD) Resolution Video with lower resolution, Wideband (7kHz) Speech
and High Definition (HD) Resolution Video with higher resolution).
MOS scores reported in the QoE block may vary with the Mos reference;
For example MOS values for narrowband, 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 may 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 an extmap; without it, the
direction implicitly inherits, of course, from the stream direction.
Segment extension, with their directions, may be signaled for an
"inactive" stream. It is an error to use an extension direction
incompatible with the stream direction (e.g., a "sendonly" attribute
for a "recvonly" stream).
If an segment extension map 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.
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). Identifiers
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 two segment types defined in section 3 are
also two 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.
Note that the range 4096-4351 for these negotiation identifiers is
deliberately restricted to allow expansion of the range of valid
identifiers in future. segment extensions with an identifier outside
the valid range cannot, of course, be used.
Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc.
all omitted for brevity):
The offer:
a=rtcp-xr:qoe-
metrics=calg:4906=P1201.1m,calg:4906=P1202.1v,calg:4907=G107a
The answerer is interested in transmission P.1202.1 only on video,
but doesn't understand P.1202.1 at all. It is interested in
transmission G.107 on audio. It therefore adjusts the declarations:
a=rtcp-xr:qoe-metrics=calg:1=P1202.1v, calg:2=G107a
5. IANA Considerations 5. IANA Considerations
New block types for RTCP XR are subject to IANA registration. For New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to general guidelines on IANA considerations for RTCP XR, refer to
[RFC3611]. [RFC3611].
5.1. New RTCP XR Block Type value 5.1. New RTCP XR Block Type value
This document assigns the block type value MMQ in the IANA "RTCP XR This document assigns the block type value MMQ in the IANA "RTCP XR
skipping to change at page 12, line 5 skipping to change at page 13, line 19
5.3. Contact information for registrations 5.3. Contact information for registrations
The contact information for the registrations is: The contact information for the registrations is:
Qin Wu Qin Wu
sunseawq@huawei.com sunseawq@huawei.com
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012 China Nanjing, JiangSu 210012 China
5.4. New registry of calculation algorithms for single stream segment 5.4. New registry of calculation algorithms
This document creates a new registry for single stream per SSRC This document creates a new registry to be called "RTCP XR QoE metric
segment defined in the section 3.2.1 to be called "RTCP XR QoE metric
block - multimedia application Calculation Algorithm" as a sub- block - multimedia application Calculation Algorithm" as a sub-
registry of the "RTP Control Protocol Extended Reports (RTCP XR) registry of the "RTP Control Protocol Extended Reports (RTCP XR)
Block Type Registry". This registry applies to the multimedia Block Type Registry". This registry applies to the multimedia
session where each type of media are sent in a separate RTP stream. session where each type of media are sent in a separate RTP stream
Specially this registry also applies to the layered video session and also applies to the session where Multi-channel audios are
where each layer video are sent in a separate RTP stream. Policies carried in one RTP stream. Policies for this new registry are as
for this new registry are as follows: follows:
o The information required to support this assignment is an o The information required to support this assignment is an
unambiguous definition of the new metric, covering the base unambiguous definition of the new metric, covering the base
measurements and how they are processed to generate the reported measurements and how they are processed to generate the reported
metric. This should include the units of measurement, how values metric. This should include the units of measurement, how values
of the metric are reported in the one 16-bit fields "MoS Value". of the metric are reported in the one 16-bit fields or 13-bit
fields "MoS Value".
o The review process for the registry is "Specification Required" as o The review process for the registry is "Specification Required" as
described in Section 4.1 of [RFC5226]. described in Section 4.1 of [RFC5226].
o Entries in the registry are integers. The valid range is 0 to 7
corresponding to the 3-bit field "CAlg" in the block. Values are
to be recorded in decimal.
o Initial assignments are as follows: o Entries in the registry are identified by entry name and mapped to
the local identifier (CAID) in the segment extension defined in
1. ITU-T P.564 Compliant Algorithm [P.564] (Voice) section 3.2.
2. G.107 [G.107] (Voice)
3. ETSI TS 101 329-5 Annex E [ ETSI] (Voice)
4. TTC JJ201.01 [TTC] (Voice)
5. ITU-T P.1201 [P.1201] (Multimedia)
6. ITU-T P.1202 [P.1202] (Video)
5.5. New registry of calculation algorithms for multi-channel audio o Registration Template
segment
This document creates a new registry for multi-channel audio per SSRC The following information must be provided with each registration:
segment defined in the section 3.2.2 to be called "RTCP XR QoE metric * Name: A string uniquely and unambiguously identifying the
block - multi-channel application Calculation Algorithm" as a sub- Calculation algorithm for use in protocols.
registry of the "RTP Control Protocol Extended Reports (RTCP XR) * Name Description: A valid Description of the Calculation
Block Type Registry" if multi-channel voice data are carried in the algorithm name.
same RTP stream. Policies for this new registry are as follows:
o The information required to support this assignment is an * Reference: The reference which defines the calculation
unambiguous definition of the new metric, covering the base algorithm corresponding to the Name and Name Description.
measurements and how they are processed to generate the reported * Type: The media type to which the calculation algorithm is
metric. This should include the units of measurement, how values applied
of the metric are reported in the one 16-bit fields "MoS Value".
o The review process for the registry is "Specification Required" as
described in Section 4.1 of [RFC5226].
o Entries in the registry are integers. The valid range is 0 to 7
corresponding to the 3-bit field "CAlg" in the block. Values are
to be recorded in decimal.
o Initial assignments are as follows: o Initial assignments are as follows:
1. ITU-T P.564 Compliant Algorithm [P.564] (Voice) Name Name Description Reference Type
2. G.107 [G.107] (Voice) ========= =================================== ========== ====
3. ETSI TS 101 329-5 Annex E [ETSI] (Voice) P564 ITU-T P.564 Compliant Algorithm [P.564] Voice
4. TTC JJ201.01 [TTC] (Voice) G107 ITU-T G.107 [G.107] Voice
TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice
JJ201_01 TTC JJ201.01 [TTC] Voice
P1201_01 ITU-T P.1201.01 [P.1201.1] Multimedia
P1201_02 ITU-T P.1201.02 [P.1201.2] Multimedia
P1202_01 ITU-T P.1202.01 [P.1202.01] Video
P1202_02 ITU-T P. NBAMS-HR [P. NBAMS-HR] Video
6. Security Considerations 6. Security Considerations
The new RTCP XR report blocks proposed in this document introduces no The new RTCP XR report blocks proposed in this document introduces no
new security considerations beyond those described in [RFC3611]. new security considerations beyond those described in [RFC3611].
7. Authors 7. Authors
This draft merges ideas from two drafts addressing the QoE metric This draft merges ideas from two drafts addressing the QoE metric
Reporting issue. The authors of these drafts are listed below (in Reporting issue. The authors of these drafts are listed below (in
skipping to change at page 14, line 41 skipping to change at page 15, line 46
methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. methodologies", ETSI TS 101 329-5 V1.1.1, November 2000.
[G.107] ITU-T, "The E Model, a computational model for use in [G.107] ITU-T, "The E Model, a computational model for use in
transmission planning", ITU-T Recommendation G.107, transmission planning", ITU-T Recommendation G.107,
April 2009. April 2009.
[G.1082] ITU-T, "Measurement-based methods for improving the [G.1082] ITU-T, "Measurement-based methods for improving the
robustness of IPTV performance", ITU-T robustness of IPTV performance", ITU-T
Recommendation G.1082, April 2009. Recommendation G.1082, April 2009.
[MONARCH] Wu, Q., "Monitoring Architectures for RTP", [P.1201.1]
ID draft-ietf-avtcore-monarch-22, September 2012. 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] ITU-T, "Parametric non-intrusive assessment of audiovisual [P.1201.2]
media streaming quality", ITU-T Recommendation P.1201, ITU-T, "Parametric non-intrusive assessment of audiovisual
October 2012. media streaming quality - higher resolution application
area", ITU-T Recommendation P.1201.2, October 2012.
[P.1202] ITU-T, "non-intrusive bit-stream model for assessment of [P.1202.1]
performance of multimedia streaming", ITU-T ITU-T, "Parametric non-intrusive bitstream assessment of
Recommendation P.1202, October 2012. video media streaming quality - lower resolution
application area", ITU-T Recommendation P.1202.1,
October 2012.
[P.564] ITU-T, "Conformance testing for narrowband Voice over IP [P.564] ITU-T, "Conformance testing for narrowband Voice over IP
transmission quality assessment models", ITU-T transmission quality assessment models", ITU-T
Recommendation P.564, July 2006. Recommendation P.564, July 2006.
[P.NBAMS-HR]
ITU-T, "Parametric non-intrusive bitstream assessment of
video media streaming quality - higher resolution
application area", ITU-T Recommendation P.NBAMS-HR,
October 2012.
[RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for
AC-3 Audio", RFC 4184, October 2005. AC-3 Audio", RFC 4184, October 2005.
[RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload [RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload
Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598,
July 2006. July 2006.
[RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric
Development", RFC 6390, October 2011. Development", RFC 6390, October 2011.
[RFC6792] Wu, Q., "Monitoring Architectures for RTP", RFC 6792,
November 2012.
[TTC] TTC 201.01 (Japan), "A method for speech quality [TTC] TTC 201.01 (Japan), "A method for speech quality
assessment for Voice over IP". assessment for Voice over IP".
Appendix A. Change Log Appendix A. Evaluation Example of User Quality of Experience for video
stream
A.1. draft-ietf-xrblock-rtcp-xr-qoe-03 To evaluate user quality of experience levels using objective test
data. MoS Scores provide a familiar, easily understood numeric
representation of video, audio, and overall audiovisual quality.
Unlike audio, video is even more sensitive to transport impairments
than voice, and even low rates of packet loss can cause severe
degradation in perceived quality. However, all occurrences of packet
loss do not have an equal impact on perceptual quality, in part
because of the way video frames are structured during the encoding
process - such as frame properties including frame type and
quantization parameter (QP), frame structure, and in part due to
subjective factors - such as the degree to which perception is
affected by the levels of motion and detail in the video sequence,
demux/decoder statistics characteristic parameters including jitter
buffer metrics and packet loss concealment metrics. When a video
stream is sent from the media source to RTP receiving end and get
monitored, in order to provide accurate evaluation of video quality,
One possible evaluation method of QoE is the network nodes that
implement network management tools may get frame
properties,perception degree as MoS calculation input parameters from
media source, and demux/decoder statistics characteristic parameters
and transport impairment as other MoS calculation input parameters
from the RTP receiving end and use appropriate MoS calculation
algorithm to calculate MoS scores. Such MoS Scores value can be
useful for troubleshooting or comparing video quality across
different service types.
Appendix B. Change Log
B.1. draft-ietf-xrblock-rtcp-xr-qoe-04
The following are the major changes compared to previous version:
o Split two references P.NAMS and P.NBAMS into four references.
o SDP signaling update.
o Add one example to explain User QoE evaluation for video stream
B.2. draft-ietf-xrblock-rtcp-xr-qoe-03
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Add one new reference to support TTC JJ201.01. o Add one new reference to support TTC JJ201.01.
o Update two references P.NAMS and P.NBAMS. o Update two references P.NAMS and P.NBAMS.
o Other Editorial changes based on comments applied to PDV and Delay o Other Editorial changes based on comments applied to PDV and Delay
drafts. drafts.
A.2. draft-ietf-xrblock-rtcp-xr-qoe-02 B.3. draft-ietf-xrblock-rtcp-xr-qoe-02
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Remove leftmost second bit since it is ueeless. o Remove leftmost second bit since it is ueeless.
o Change 13bits MoS value field into 14 bits to increase MoS o Change 13bits MoS value field into 14 bits to increase MoS
precision. precision.
o Fix some typo and make some editorial changes. o Fix some typo and make some editorial changes.
A.3. draft-ietf-xrblock-rtcp-xr-qoe-01 B.4. draft-ietf-xrblock-rtcp-xr-qoe-01
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Remove layered support from the QoE metric draft. o Remove layered support from the QoE metric draft.
o Allocate 7 bits in the block header for payload type to indicate o Allocate 7 bits in the block header for payload type to indicate
what type of payload format is in use and add associated what type of payload format is in use and add associated
definition of payload type. definition of payload type.
o Clarify using Payload Type to determine the appropriate channel o Clarify using Payload Type to determine the appropriate channel
mapping in the definition of Channel Identifier. mapping in the definition of Channel Identifier.
A.4. draft-ietf-xrblock-rtcp-xr-qoe-00 B.5. draft-ietf-xrblock-rtcp-xr-qoe-00
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Allocate one more bit in the single stream per SSC segment to get o Allocate one more bit in the single stream per SSC segment to get
alignment with the other two segment type. alignment with the other two segment type.
Authors' Addresses Authors' Addresses
Alan Clark Alan Clark
Telchemy Incorporated Telchemy Incorporated
2905 Premiere Parkway, Suite 280 2905 Premiere Parkway, Suite 280
 End of changes. 54 change blocks. 
219 lines changed or deleted 308 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/