One document matched: draft-ietf-xrblock-rtcp-xr-qoe-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2250 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2250.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc3357 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3357.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc5216 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY rfc5247 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
<!ENTITY I-D.ietf-avt-rapid-rtp-sync PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rapid-rtp-sync.xml">
<!ENTITY I-D.ietf-pmol-metrics-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pmol-metrics-framework.xml">
<!ENTITY I-D.hunt-avt-monarch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hunt-avt-monarch.xml">
<!ENTITY I-D.ietf-avt-rtp-svc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rtp-svc.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="std" docName="draft-ietf-xrblock-rtcp-xr-qoe-03"
ipr="trust200902">
<front>
<title abbrev="RTCP XR QoE Report Blocks">RTP Control Protocol (RTCP)
Extended Report (XR) Blocks for QoE Metric Reporting</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization abbrev="Telchemy">Telchemy Incorporated</organization>
<address>
<postal>
<street>2905 Premiere Parkway, Suite 280</street>
<city>Duluth</city>
<region>GA</region>
<code>30097</code>
<country>USA</country>
</postal>
<email>alan.d.clark@telchemy.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Roland Schott" initials="R." surname="Schott">
<organization abbrev="DT">Deutsche Telekom Laboratories</organization>
<address>
<postal>
<street>Deutsche-Telekom-Allee 7</street>
<street></street>
<city>Darmstadt</city>
<code>64295</code>
<country>Germany</country>
</postal>
<email>Roland.Schott@telekom.de</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>77/440 Soi Phoomjit, Rama IV Road</street>
<street>Phra Khanong, Khlong Toie</street>
<city>Bangkok</city>
<code>10110</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 87 502 4274</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<date year="2012" />
<abstract>
<t>This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block including two new segment types and associated SDP parameters
that allow the reporting of QoE metrics for use in a range of RTP
applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="QoE Metrics Report Block">
<t>This document defines a new block type to augment those defined in
<xref target="RFC3611"></xref>, for use in a range of RTP
applications. <vspace blankLines="1" />The new block type provides
information on multimedia quality using one of several standard
metrics.<vspace blankLines="1" />The metrics belong to the class of
application level metrics defined in <xref
target="MONARCH"></xref>.</t>
</section>
<section title="RTCP and RTCP XR Reports">
<t>The use of RTCP for reporting is defined in <xref
target="RFC3550"></xref>. <xref target="RFC3611"></xref> defined an
extensible structure for reporting using an RTCP Extended Report (XR).
This draft defines a new Extended Report block for use with <xref
target="RFC3550"></xref> and <xref target="RFC3611"></xref>.</t>
</section>
<section title="Performance Metrics Framework">
<t>The Performance Metrics Framework <xref target="RFC6390"></xref>
provides guidance on the definition and specification of performance
metrics. The RTP Monitoring Architectures <xref
target="MONARCH"></xref> provides guideline for reporting block format
using RTCP XR. The XR Block described in this document are in
accordance with the guidelines in <xref target="RFC6390"></xref> and
<xref target="MONARCH"></xref>.</t>
</section>
<section title="Applicability">
<t>The QoE Metrics Report Block can be used in any application of RTP
for which QoE measurement algorithms are defined.</t>
<t>The factors that affect real-time AV application quality can be
split into two categories. The first category consists of transport-
dependent factors such as packet loss, delay and jitter (which also
translates into losses in the playback buffer). The factors in the
second category are application-specific factors that affect real time
application (e.g., video) quality and are sensitivity to network
errors. These factors can be but not limited to video codec and loss
recovery technique, coding bit rate, packetization scheme, and content
characteristics.</t>
<t>Compared with application-specific factors, the transport-dependent
factors sometimes are not sufficient to measure real time data
quality, since the ability to analyze the real time data in the
application layer provides quantifiable measurements for subscriber
Quality of Experience (QoE) that may not be captured in the
transmission layers or from the RTP layer down. In a typical scenario,
monitoring of the transmission layers can produce statistics
suggesting that quality is not an issue, such as the fact that network
jitter is not excessive. However, problems may occur in the service
layers leading to poor subscriber QoE. Therefore monitoring using only
network-level measurements may be insufficient when application layer
content quality is required.</t>
<t>In order to provide accurate measures of real time application
quality when transporting real time contents across a network, the
synthentical multimedia quality Metrics is highly required which can
be conveyed in the RTCP XR packets[RFC3611] and may have the following
three benefits: <vspace blankLines="1" /><list style="symbols">
<t>Tuning the content encoder algorithm to satisfy real time data
quality requirements.</t>
<t>Determining which system techniques to use in a given situation
and when to switch from one technique to another as system
parameters change.</t>
<t>Verifying the continued correct operation of an existing
system.</t>
</list></t>
</section>
</section>
<section title="Terminology">
<section title="Standards Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>The terminology used is <vspace blankLines="1" /><list>
<t>Numeric formats S X:Y<vspace blankLines="1" /><list>
<t>where S indicates a two's complement signed representation,
X the number of bits prior to the decimal place and Y the
number of bits after the decimal place.</t>
<t>Hence 8:8 represents an unsigned number in the range 0.0 to
255.996 with a granularity of 0.0039. S7:8 would represent the
range -127.996 to +127.996. 0:16 represents a proper binary
fraction with range</t>
<t>0.0 to 1 - 1/65536 = 0.9999847</t>
<t>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</t>
<t>0.0 to 1 - 3/65536 = 0.9999542</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="SMQM" title="QoE Metrics Block">
<t>This block reports the multimedia application performance or quality
beyond the information carried in the standard RTCP packet format.
Information is recorded about multimedia application QoE metric which
provides a measure that is indicative of the user's view of a 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 5 represents
excellent and 1 represents unacceptable. MOS scores are usually obtained
using subjective testing or using objective algorithm. However
Subjective testing to estimate the multimedia quality may be not
suitable for measuring the multimedia quality since the results may vary
from test to test. Therefore using objective algorithm to calculate MOS
scores is recommended. ITU-T recommendations define the methodologies
for assessment of the performance of multimedia stream <xref
target="G.107"></xref><xref target="P.564"></xref><xref
target="G.1082"></xref><xref target="P.1201"></xref><xref
target="P.1202"></xref> and provides a method to evaluate QoE estimation
algorithms and objective model for video and audio. Hence this document
recommends vendors and implementers to use these International
Telecommunication Union (ITU)-specified methodologies to measure
parameters when possible. <vspace blankLines="1" /><list>
<t>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?</t>
</list><vspace blankLines="1" /></t>
<section title="Metric Block Structure">
<t>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 be
reported in each block. Flags indicate which are and which are not
reported. The fields corresponding to unreported parameters MUST 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 unreported. The
encoding of QoE metrics block payload consists of a series of 32 bit
units called segments that describe MOS Type, MoS algorithm and MoS
value.<vspace blankLines="1" /><list>
<t>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.</t>
<t>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.</t>
</list></t>
<t>The QoE Metrics Block has the following format: <figure>
<artwork>
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=QMB | I | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
</section>
<section title="Definition of Fields in QoE Metrics Block">
<t><list style="hanging">
<t hangText="Block type (BT): 8 bits"><vspace blankLines="1" />The
QoE Metrics Block is identified by the constant <QMB>.
<vspace blankLines="1" /></t>
<t hangText="Interval Metric flag (I): 2 bits "><vspace
blankLines="1" />This field is used to indicate whether the QoE
metrics are Interval or Cumulative metrics, that is, whether the
reported values applies to the most recent measurement interval
duration between successive metrics reports (I=10) (the Interval
Duration) or to the accumulation period characteristic of
cumulative measurements (I=11) (the Cumulative Duration) or is a
sampled instantaneous value (I=01) (Sampled Value). <vspace
blankLines="1" /></t>
<t hangText="Reserved.: 6 bits"><vspace blankLines="1" /> 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. <vspace blankLines="1" /></t>
<t hangText="Block Length: 16 bits"><vspace blankLines="1" />The
length of this report block in 32-bit words, minus one. For the
QoE Metrics Block, the block length is variable length.<vspace
blankLines="1" /></t>
<t hangText="SSRC of source: 32 bits"><vspace blankLines="1" /> As
defined in Section 4.1 of <xref target="RFC3611"></xref>. <vspace
blankLines="1" /></t>
<t hangText="Segment i: 32 bits"><vspace blankLines="1" />There
are two segment types defined in this document: single stream per
SSRC segment, multi-channel audio per SSRC segment. Multi-channel
audio per SSRC segment is used to deal with the case where
Multi-channel audios are carried in one RTP stream while 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
stream. The left two bits of the section determine its type. If
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
audio segment. Note that two segment types can not be present in
the same metric block. <vspace blankLines="1" /></t>
</list></t>
<section title="Single Stream per SSRC Segment">
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| MT |CAlg | PT |Rsv. | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<texttable>
<ttcol>Editor's Note: If we add MoS reference concept, we should
give a definition of MoS reference which covers both audio
application and video application.</ttcol>
<ttcol>Editor's Note: Shall we need to support MoS Scaling concept
in the future draft? One point on the list is MoS Scaling concept
is implicitly used within the industry when quoting MOS scores for
codecs and measurements.</ttcol>
</texttable>
<t><list style="hanging">
<t hangText="Segment Type (S): 1 bit"><vspace
blankLines="1" />This field is used to identify the segment type
used in this report block. A zero identifies this as a single
stream segment. Single stream means there is only one media
stream carried in one RTP stream. The single stream segment can
be used to report the MoS value associated with this media
stream identified by SSRC. If there are multiple media streams
and they want to use the single stream per SSRC segment to
report the MOS value, they should be carried in the separate RTP
streams with different SSRC. In this case, multiple QoE Metrics
Blocks are required to report the MOS value corresponding to
each media stream using single stream segment. <vspace
blankLines="1" /></t>
<t hangText="MoS Type (MT): 4 bits"><vspace
blankLines="1" />This field is used to indicate the MOS type to
be reported. The MOS type is defined as follows: <vspace
blankLines="1" /><list>
<t>0000 MOS-LQ - Listening Quality MoS.</t>
<t>0001 MOS-CQ - Conversation Quality MoS.</t>
<t>0010 MOS-A - Audio Quality MOS.</t>
<t>0010 MOS-V - Video Quality MOS.</t>
<t>0011 MOS-AV - Audio-Video Quality MOS.</t>
<t>0100~1111 - Reserved for future definitions.<vspace
blankLines="1" /></t>
</list>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. <vspace blankLines="1" /></t>
<t hangText="Calculation Algorithm (CALg):3 bits"><vspace
blankLines="1" /><list>
<t>000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>
<t>001 - G.107 [G.107] (Voice)</t>
<t>010 - ETSI TS 101 329-5 Annex E [ ETSI] (Voice)</t>
<t>011 - TTC JJ201.01 [TTC] (Voice)</t>
<t>100 - ITU-T P.1201 [P.1201] (Multimedia)</t>
<t>101 - ITU-T P.1202 [P.1202] (Video)</t>
<t>110~111 - Reserved for future extension.<vspace
blankLines="1" /></t>
</list>G.107 and P.564 and ETSI TS101 329-5 specify three
Calculation 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<xref
target="G.107"></xref>, ITU-T P.564 <xref
target="P.564"></xref>or ETSI TS 101 329-5 <xref
target="ETSI"></xref>, if the Mos type is MoS-V or MoS-AV, the
Mos value can be calculated based on ITU-T P.NAMS <xref
target="P.1201"></xref>or ITU-T P.NBAMS <xref
target="P.1202"></xref>. If new MOS types are defined, they can
be added by an update to this document. If the receiver does not
understand the 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.<vspace blankLines="1" /></t>
<t hangText="Payload Type (PT): 7 bits"><vspace
blankLines="1" />QoE metrics reporting depends on the payload
format in use. This field identifies the format of the RTP
payload. For RTP sessions where multiple payload formats can be
negotiated or the payload format changes during the
mid-session), the value of this field will be used to indicate
what payload format was in use for the reporting interval.
<vspace blankLines="1" /></t>
<t hangText="Rsd.:3 bits "><vspace blankLines="1" /> 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. <vspace blankLines="1" /></t>
<t hangText="MOS Value: 14 bits"><vspace blankLines="1" />The
estimated mean opinion score for multimedia application quality
is defined as including the effects of delay,loss,
discard,jitter and other effects that would affect multimedia
quality . It is expressed in numeric format 6:8 with the value
in the range 0.0 to 63.996. 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 0xFFFE SHOULD be
reported to indicate an over-range measurement. If the
measurement is unavailable, the value 0xFFFF SHOULD be reported.
Values other than 0xFFFE,0xFFFF and the valid range defined
above MUST NOT be sent and MUST be ignored by the receiving
system. <vspace blankLines="1" /></t>
</list></t>
</section>
<section title="Multi-Channel audio per SSRC Segment">
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| MT |CAlg | PT |CHID | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Segement Type (S): 1 bit"><vspace blankLines="1" />
This field is used to identify the segment type used in this
report block. A one identifies this as a multi-channel audio
segment.<vspace blankLines="1" /></t>
<t hangText="Media Type (M): 1bit"><vspace blankLines="1" />A
zero identifies this as a multi-channel per SSRC segment.<vspace
blankLines="1" /></t>
<t hangText="MoS Type (MT): 4 bits"><vspace blankLines="1" />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. <vspace blankLines="1" /></t>
<t hangText="Calculation Algorithm (CALg):3 bits"><vspace
blankLines="1" /><list>
<t>000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>
<t>001 - G.107 [G.107] (Voice)</t>
<t>010 - ETSI TS 101 329-5 Annex E, [ ETSI] (Voice)</t>
<t>011 - TTC JJ201.01 [TTC] (Voice)</t>
<t>100~111 - Reserved for future extension.<vspace
blankLines="1" /></t>
</list></t>
<t hangText="Payload Type (PT): 7 bits"><vspace
blankLines="1" />As defined in Section 3.2.1 of this
document.<vspace blankLines="1" /></t>
<t hangText="Channel Identifier (CHID): 3 bits"><vspace
blankLines="1" />If multiple channels of audio are carried in
one RTP stream, each channel of audio will be viewed as a
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 the section 4.1 of <xref
target="RFC3551"></xref>. However there are some payload formats
that use different channel mappings, e.g., AC-3 audio over RTP
<xref target="RFC4184"></xref> only follow AC-3 channel order
scheme defined in <xref target="ATSC"></xref>. Enhanced AC-3
Audio over RTP <xref target="RFC4598"></xref> uses dynamic
channel transform mechanism. In order that the appropriate
channel mapping can be determined, QoE reports need to be tied
to an RTP payload format, i.e., including the payload type of
the reported media according to <xref target="MONARCH"></xref>
and using Payload Type to determine the appropriate channel
mapping. <vspace blankLines="1" /></t>
<t hangText="Rsd.:3 bits "><vspace blankLines="1" /> 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. <vspace blankLines="1" /></t>
<t hangText="MOS Value: 14 bits"><vspace blankLines="1" />As
defined in Section 3.2.1 of this document.<vspace
blankLines="1" /></t>
</list></t>
</section>
</section>
</section>
<section title="SDP Signaling">
<t>One new parameter is defined for the report block defined in this
document to be used with Session Description Protocol (SDP) <xref
target="RFC4566"></xref> using the Augmented Backus-Naur Form (ABNF)
<xref target="RFC5234"></xref>. It has the following syntax within the
"rtcp-xr" attribute <xref target="RFC3611"></xref>: <figure align="left">
<artwork>
xr-format = qoe-metrics
qoe-metrics = "QoE metrics"
</artwork>
</figure> Refer to Section 5.1 of <xref target="RFC3611">RFC
3611</xref> for a detailed description and the full syntax of the
"rtcp-xr" attribute.</t>
</section>
<section title="IANA Considerations">
<t>New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to <xref
target="RFC3611"></xref>.</t>
<section title="New RTCP XR Block Type value">
<t>This document assigns the block type value MMQ in the IANA "RTCP XR
Block Type Registry" to the "QoE Metrics Block".</t>
<t>[Note to RFC Editor: please replace MMQ with the IANA provided RTCP
XR block type for this block.]</t>
</section>
<section title="New RTCP XR SDP Parameter">
<t>This document also registers a new parameter "qoe-metrics" in the
"RTCP XR SDP Parameters Registry".</t>
</section>
<section title="Contact information for registrations">
<t>The contact information for the registrations is: <figure
align="center">
<artwork>
Qin Wu
sunseawq@huawei.com
101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012 China
</artwork>
</figure></t>
</section>
<section title="New registry of calculation algorithms for single stream segment">
<t>This document creates a new registry for single stream per SSRC
segment defined in the section 3.2.1 to be called "RTCP XR QoE metric
block - multimedia application Calculation Algorithm" as a
sub-registry of the "RTP Control Protocol Extended Reports (RTCP XR)
Block Type Registry". This registry applies to the multimedia session
where each type of media are sent in a separate RTP stream. Specially
this registry also applies to the layered video session where each
layer video are sent in a separate RTP stream. Policies for this new
registry are as follows: <vspace blankLines="1" /><list
style="symbols">
<t>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. This should include the units of measurement, how values
of the metric are reported in the one 16-bit fields "MoS
Value".</t>
<t>The review process for the registry is "Specification Required"
as described in Section 4.1 of <xref target="RFC5226"></xref>.</t>
<t>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. <vspace blankLines="1" /></t>
<t>Initial assignments are as follows:<vspace
blankLines="1" /><list style="numbers">
<t>ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>
<t>G.107 [G.107] (Voice)</t>
<t>ETSI TS 101 329-5 Annex E [ ETSI] (Voice)</t>
<t>TTC JJ201.01 [TTC] (Voice)</t>
<t>ITU-T P.1201 [P.1201] (Multimedia)</t>
<t>ITU-T P.1202 [P.1202] (Video)<vspace blankLines="1" /></t>
</list></t>
</list></t>
</section>
<section title="New registry of calculation algorithms for multi-channel audio segment">
<t>This document creates a new registry for multi-channel audio per
SSRC segment defined in the section 3.2.2 to be called "RTCP XR QoE
metric block – multi-channel application Calculation Algorithm" as a
sub-registry of the "RTP Control Protocol Extended Reports (RTCP XR)
Block Type Registry" if multi-channel voice data are carried in the
same RTP stream. Policies for this new registry are as follows:
<vspace blankLines="1" /><list style="symbols">
<t>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. This should include the units of measurement, how values
of the metric are reported in the one 16-bit fields "MoS
Value".</t>
<t>The review process for the registry is "Specification Required"
as described in Section 4.1 of <xref target="RFC5226"></xref>.</t>
<t>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.</t>
<t>Initial assignments are as follows:<vspace
blankLines="1" /><list style="numbers">
<t>ITU-T P.564 Compliant Algorithm [P.564] (Voice)</t>
<t>G.107 [G.107] (Voice)</t>
<t>ETSI TS 101 329-5 Annex E [ETSI] (Voice)</t>
<t>TTC JJ201.01 [TTC] (Voice)<vspace blankLines="1" /></t>
</list></t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>The new RTCP XR report blocks proposed in this document introduces no
new security considerations beyond those described in <xref
target="RFC3611"></xref>.</t>
</section>
<section title="Authors">
<t>This draft merges ideas from two drafts addressing the QoE metric
Reporting issue. The authors of these drafts are listed below (in
alphabetical order): <list>
<t>Alan Clark < alan.d.clark@telchemy.com ></t>
<t>Geoff Hunt < r.geoff.hunt@gmail.com ></t>
<t>Martin Kastner < martin.kastner@telchemy.com ></t>
<t>Kai Lee < leekai@ctbri.com.cn ></t>
<t>Roland Schott < roland.schott@telekom.de ></t>
<t>Qin Wu < sunseawq@huawei.com ></t>
<t>Glen Zorn < gwz@net-zen.net ></t>
</list></t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Bill Ver Steeg, David R Oran, Ali
Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang Hu
for their valuable comments and suggestions on this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3611;
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3550" />
<format type="TXT" />
</reference>
<reference anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal
Control</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization></organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3551" />
<format type="TXT" />
</reference>
&rfc2119;
&rfc4566;
&rfc5234;
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T.,Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
<format target="http://www.rfc-editor.org/rfc/rfc5226.txt" type="TXT" />
</reference>
<reference anchor="ATSC">
<front>
<title>ATSC Standard: Digital Audio Compression (AC-3), Revision
B</title>
<author>
<organization>U.S. Advanced Television Systems Committee
(ATSC)</organization>
</author>
<date month="June" year="2005" />
</front>
<seriesInfo name="ATSC" value="Doc A/52B" />
</reference>
</references>
<references title="Informative References">
<reference anchor="G.1082">
<front>
<title>Measurement-based methods for improving the robustness of
IPTV performance</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="ITU-T Recommendation" value="G.1082" />
</reference>
<reference anchor="P.564">
<front>
<title>Conformance testing for narrowband Voice over IP transmission
quality assessment models</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.564" />
</reference>
<reference anchor="G.107">
<front>
<title>The E Model, a computational model for use in transmission
planning</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="ITU-T Recommendation" value="G.107" />
</reference>
<reference anchor="ETSI">
<front>
<title>Quality of Service (QoS) measurement methodologies</title>
<author>
<organization>ETSI</organization>
</author>
<date month="November" year="2000" />
</front>
<seriesInfo name="ETSI" value="TS 101 329-5 V1.1.1" />
</reference>
<reference anchor="P.1201">
<front>
<title>Parametric non-intrusive assessment of audiovisual media
streaming quality</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.1201" />
</reference>
<reference anchor="P.1202">
<front>
<title>non-intrusive bit-stream model for assessment of performance
of multimedia streaming</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.1202" />
</reference>
<reference anchor="MONARCH">
<front>
<title>Monitoring Architectures for RTP</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="ID" value="draft-ietf-avtcore-monarch-22" />
<format type="TXT" />
</reference>
<reference anchor="TTC">
<front>
<title>A method for speech quality assessment for Voice over
IP</title>
<author>
<organization>TTC 201.01 (Japan)</organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC6390">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="RFC" value="6390" />
</reference>
<reference anchor="RFC4598">
<front>
<title>Real-time Transport Protocol (RTP) Payload Format for
Enhanced AC-3 (E-AC-3) Audio</title>
<author fullname="Brian Link" initials="B." surname="Link">
<organization>Dolby Laboratories</organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4598" />
<format target="http://www.rfc-editor.org/rfc/rfc4598.txt" type="TXT" />
</reference>
<reference anchor="RFC4184">
<front>
<title>RTP Payload Format for AC-3 Audio</title>
<author fullname="Brian Link" initials="B." surname="Link">
<organization>Dolby Laboratories</organization>
</author>
<author fullname="Todd Hager" initials="T." surname="Hager">
<organization>Dolby Laboratories</organization>
</author>
<author fullname="Jason Flaks" initials="J." surname="Flaks">
<organization>Microsoft Corporation</organization>
</author>
<date month="October" year="2005" />
</front>
<seriesInfo name="RFC" value="4184" />
<format octets="" target="http://www.rfc-editor.org/rfc/rfc4184.txt"
type="TXT" />
</reference>
</references>
<section title="Change Log">
<section title="draft-ietf-xrblock-rtcp-xr-qoe-03">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Add one new reference to support TTC JJ201.01.</t>
<t>Update two references P.NAMS and P.NBAMS.</t>
<t>Other Editorial changes based on comments applied to PDV and
Delay drafts.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-02">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Remove leftmost second bit since it is ueeless.</t>
<t>Change 13bits MoS value field into 14 bits to increase MoS
precision.</t>
<t>Fix some typo and make some editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-01">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Remove layered support from the QoE metric draft.</t>
<t>Allocate 7 bits in the block header for payload type to
indicate what type of payload format is in use and add associated
definition of payload type.</t>
<t>Clarify using Payload Type to determine the appropriate channel
mapping in the definition of Channel Identifier.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-00">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Allocate one more bit in the single stream per SSC segment to
get alignment with the other two segment type.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 19:05:53 |