draft-ietf-xrblock-rtcp-xr-qoe-10.txt   draft-ietf-xrblock-rtcp-xr-qoe-11.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: December 26, 2013 Huawei Expires: March 10, 2014 Huawei
R. Schott R. Schott
Deutsche Telekom Deutsche Telekom
G. Zorn G. Zorn
Network Zen Network Zen
June 24, 2013 September 6, 2013
RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MoS Metric RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MoS Metric
Reporting Reporting
draft-ietf-xrblock-rtcp-xr-qoe-10 draft-ietf-xrblock-rtcp-xr-qoe-11
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 MoS Metrics for use in a range parameters that allow the reporting of MoS 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 December 26, 2013. This Internet-Draft will expire on March 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. MoS Metrics Report Block . . . . . . . . . . . . . . . . . 4 1.1. MoS Metrics Report Block . . . . . . . . . . . . . . . . . 4
1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 4 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 4
1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 5 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 5
3. MoS Metrics Block . . . . . . . . . . . . . . . . . . . . . . 6 3. MoS Metrics Block . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 6 3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 6
3.2. Definition of Fields in MoS Metrics Block . . . . . . . . 7 3.2. Definition of Fields in MoS Metrics Block . . . . . . . . 7
3.2.1. Single Stream audio/video per SSRC Segment . . . . . 8 3.2.1. Single Channel audio/video per SSRC Segment . . . . . 8
3.2.2. Multi-Channel audio per SSRC Segment . . . . . . . . . 9 3.2.2. Multi-Channel audio per SSRC Segment . . . . . . . . . 9
4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 11 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 10
4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 12 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 14 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 14
5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 14 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 14
5.3. The SDP calgextmap Attribute . . . . . . . . . . . . . . . 14 5.3. The SDP calgextmap Attribute . . . . . . . . . . . . . . . 14
5.4. New registry of calculation algorithms . . . . . . . . . . 15 5.4. New registry of calculation algorithms . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 6, line 45 skipping to change at page 6, line 45
This Metrics Block relies on the measurement period in the This Metrics Block relies on the measurement period in the
Measurement Information block indicating the span of the report. Measurement Information block indicating the span of the report.
Senders MUST send this block in the same compound RTCP packet as the Senders MUST send this block in the same compound RTCP packet as the
measurement information block. Receivers MUST verify that the measurement information block. Receivers MUST verify that the
measurement period is received in the same compound RTCP packet as measurement period is received in the same compound RTCP packet as
this Metrics Block. If not, this Metrics Block MUST be discarded. this Metrics Block. If not, this Metrics Block MUST be discarded.
3.1. Metric Block Structure 3.1. Metric Block Structure
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, and MUST be set to zero. The receiver MUST ignore any
MoS Metrics Block with a non-zero value in any field flagged as
unreported. The encoding of MoS Metrics block payload consists of a
series of 32 bit units called segments that describe payload Type,
MoS algorithm and MoS value.
The MoS Metrics Block has the following format: The MoS 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=MMB | I | Reserved | Block Length | | BT=MMB | I | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 1 | | Segment 1 |
skipping to change at page 7, line 46 skipping to change at page 7, line 40
Sampled, Interval or Cumulative metrics [RFC6792]: Sampled, Interval or Cumulative metrics [RFC6792]:
I=10: Interval Duration - the reported value applies to the I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between successive most recent measurement interval duration between successive
metrics reports. metrics reports.
I=11: Cumulative Duration - the reported value applies to the I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative measurements. accumulation period characteristic of cumulative measurements.
I=01: Sampled Value - the reported value is a sampled I=01: Sampled Value - the reported value is a sampled
instantaneous value. instantaneous value.
In this document, the value I=00 is reserved for future use. In this document, MoS Metrics can only be measured at each
Senders MUST NOT use the values I=00. If a block is received with interval duration, and cannot be sampled or cumulated. Also the
I=00, the receiver MUST discard the block. value I=00 is reserved for future use. Senders MUST NOT use the
values I=00 or I=01 or I=11. If a block is received with I=00 or
I=01 or I=11, the receiver MUST discard the block.
Reserved: 6 bits Reserved: 6 bits
This field is reserved for future definition. In the absence of 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 such a definition, the bits in this field MUST be set to zero and
ignored by the receiver (See RFC6709 section 4.2). ignored by the receiver (See RFC6709 section 4.2).
Block Length: 16 bits Block Length: 16 bits
The length of this report block in 32-bit words, minus one. For The length of this report block in 32-bit words, minus one. For
skipping to change at page 8, line 26 skipping to change at page 8, line 20
SSRC of source: 32 bits SSRC of source: 32 bits
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 Audio/Video per SSRC segment, multi-channel audio per SSRC stream Audio/Video per SSRC segment, multi-channel audio per SSRC
segment. Multi-channel audio per SSRC segment is used to deal segment. Multi-channel audio per SSRC segment is used to deal
with the case where Multi-channel audios are carried in one RTP with the case where Multi-channel audios are carried in one RTP
stream while single stream Audio/Video per SSRC segment is used to stream while single channel Audio/Video per SSRC segment is used
deal with the case where each media stream is identified by SSRC to deal with the case where each media stream is identified by
and sent in separate RTP stream. The leftmost bit of the segment SSRC and sent in separate RTP stream. The leftmost bit of the
determines its type. If the leftmost bit of the segment is zero, segment determines its type. If the leftmost bit of the segment
then it is single stream segment. If the leftmost bit is one, is zero, then it is single channel segment. If the leftmost bit
then it is multi-channel audio segment. Note that two segment is one, then it is multi-channel audio segment. Note that two
types can not be present in the same metric block. segment types can not be present in the same metric block.
3.2.1. Single Stream audio/video per SSRC Segment 3.2.1. Single Channel audio/video per SSRC Segment
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT | MOS Value | |S| CAID | PT | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Audio/ report block. A zero identifies this as a single channel Audio/
Video per SSRC segment. Single stream means there is only one Video per SSRC segment. Single channel means there is only one
media stream carried in one RTP stream. The single stream Audio/ media stream carried in one RTP stream. The single channel Audio/
Video per SSRC segment can be used to report the MoS value Video per SSRC segment can be used to report the MoS value
associated with the media stream identified by SSRC. If there are associated with the media stream identified by SSRC. If there are
multiple media streams and they want to use the single stream multiple media streams and they want to use the single channel
Audio/Video per SSRC segment to report the MOS value, they should Audio/Video per SSRC segment to report the MOS value, they should
be carried in the separate RTP streams with each identified by be carried in the separate RTP streams with each identified by
different SSRC. In this case, multiple MoS Metrics Blocks are different SSRC. In this case, multiple MoS Metrics Blocks are
required to report the MOS value corresponding to each media required to report the MOS value corresponding to each media
stream using single stream Audio/Video per SSRC segment in the stream using single channel Audio/Video per SSRC segment in the
same RTCP XR packet. same RTCP XR packet.
Calg Algorithm ID (CAID) : 8bits Calg Algorithm ID (CAID) : 8bits
The 8-bit CAID is the local identifier of calculation algorithm The 8-bit CAID is the local identifier of calculation algorithm
associated with this segment in the range 1-255 inclusive. associated with this segment in the range 1-255 inclusive.
Payload Type (PT): 7 bits Payload Type (PT): 7 bits
MoS Metrics reporting depends on the payload format in use. This MoS Metrics reporting depends on the payload format in use. This
field identifies the format of the RTP payload. For RTP sessions field identifies the RTP payload type in use during the reporting
where multiple payload formats can be negotiated or the payload interval. The binding between RTP payload types and RTP payload
format changes during the mid-session), the value of this field formats is configured via a signalling protocol, for example an
will be used to indicate what payload format was in use for the SDP offer/answer exchange. If the RTP payload type used is
reporting interval. changed during an RTP session, separate reports SHOULD be sent for
each RTP payload type, with corresponding measurement information
blocks indicating the time period to which they relate.
MOS Value: 16 bits MOS Value: 16 bits
The estimated mean opinion score for multimedia application The estimated mean opinion score for multimedia application
performance is defined as including the effects of delay,loss, performance is defined as including the effects of delay,loss,
discard,jitter and other effects that would affect media quality. discard,jitter and other effects that would affect media quality.
It is expressed in numeric format 8:8 with the value in the range It is expressed in numeric format 8:8 with the value in the range
0.0 to 255.996. The valid the measured value ranges from 0.0 to 0.0 to 255.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 50.0, corresponding to MoS x 10 as for MoS. If the measured value
is over ranged, the value 0xFFFE MUST be reported to indicate an is over ranged, the value 0xFFFE MUST be reported to indicate an
skipping to change at page 11, line 22 skipping to change at page 11, line 16
identifier (CAID) in the segment extension defined in section 3.2 to identifier (CAID) in the segment extension defined in section 3.2 to
the calculation algorithm. Specific extensionattributes are defined the calculation algorithm. Specific extensionattributes are defined
by the specification that defines a specific extension name; there by the specification that defines a specific extension name; there
might be several. might be several.
xr-format =/ xr-mos-block xr-format =/ xr-mos-block
xr-mos-block = "mos-metrics" ["=" extmap *("," calgextmap)] xr-mos-block = "mos-metrics" ["=" extmap *("," calgextmap)]
calgextmap = mapentry "=" extensionname [SP extentionattributes] calgextmap = mapentry "=" extensionname [SP extentionattributes]
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
mapentry = "calg:" 1*5 DIGIT ["/" direction] mapentry = "calg:" 1*5 DIGIT ["/" direction]
;Values other than 4095~4351 are valid
extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564] extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564]
/ "G107";ITU-T G.107 [G.107] / "G107";ITU-T G.107 [G.107]
/ "G107_1";ITU-T G.107.1 [G.107.1] / "G107_1";ITU-T G.107.1 [G.107.1]
/ "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI] / "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI]
/"JJ201_1 ";TTC JJ201.1 [TTC] /"JJ201_1 ";TTC JJ201.1 [TTC]
/"P1201_1";ITU-T P.1201.2 [P.1201.1] /"P1201_1";ITU-T P.1201.2 [P.1201.1]
/"P1201_2";ITU-T P.1201.2 [P.1201.2] /"P1201_2";ITU-T P.1201.2 [P.1201.2]
/"P1202_1";ITU-T P.1202.1 [P.1202.1] /"P1202_1";ITU-T P.1202.1 [P.1202.1]
/"P1202_2";ITU-T P.1202.2 [P.1202.2] /"P1202_2";ITU-T P.1202.2 [P.1202.2]
/"P.862.2";ITU-T P.862.2 [P.862.2] /"P.862.2";ITU-T P.862.2 [P.862.2]
skipping to change at page 12, line 20 skipping to change at page 12, line 17
a=rtcp-xr:mos-metrics=calg:1=G107,calg:2=P1202_1 a=rtcp-xr:mos-metrics=calg:1=G107,calg:2=P1202_1
A usable mapping MUST use IDs in the valid range, and each ID in this 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 range MUST be unique and used only once for each stream or each
channel in the stream. channel in the stream.
The mapping MUST be provided per media stream (in the media-level The mapping MUST be provided per media stream (in the media-level
section(s) of SDP, i.e., after an "m=" line). section(s) of SDP, i.e., after an "m=" line).
The syntax element "mosref" is referred to the media resolution The syntax element "mosref" is referred to the media resolution
relative reference (e.g., Narrowband (3.4kHz) Speech and Standard relative reference and has three valules 'l','m','h'.(e.g.,
Definition (SD) Resolution Video with lower resolution, Wideband Narrowband (3.4kHz) Speech and StandardDefinition (SD) or lower
(7kHz) Speech and High Definition (HD) Resolution Video with higher Resolution Video have 'l' resolution, Super Wideband (>14kHz) Speech
resolution). MOS scores reported in the mos metrics block might vary or higher and High Definition (HD) or higher Resolution Video have
with the MoS reference; For example, MOS values for narrowband, 'h' Resolution, Wideband speech(7khz) and Video with resolution
wideband codecs occupy the same range but SHOULD be reported in between SD and HD has 'm' resolution). MOS scores reported in the
different value. For video application, MoS scores for SD mos metrics block might vary with the MoS reference; For example, MOS
resolution, HD resolution video also occupy the same ranges and values for narrowband, wideband,super wideband codecs occupy the same
SHOULD be reported in different value. 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 4.2. Offer/Answer Usage
When SDP is used in offer-answer context, the SDP 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 defined in [RFC3611] applies. In the offer answer context, the
signaling described above might be used in three ways: signaling described above might be used in three ways:
o asymmetric behavior (segment extensions sent in only one o asymmetric behavior (segment extensions sent in only one
direction), direction),
o the offer of mutually exclusive alternatives, or o the offer of mutually exclusive alternatives, or
skipping to change at page 24, line 29 skipping to change at page 24, line 29
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.
C.10. draft-ietf-xrblock-rtcp-xr-qoe-00 C.10. 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 channel 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
Duluth, GA 30097 Duluth, GA 30097
USA USA
 End of changes. 17 change blocks. 
47 lines changed or deleted 44 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/