idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-qoe-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 67 has weird spacing: '...o/Video per S...' == Line 308 has weird spacing: '...o/Video per S...' -- The document date (May 27, 2013) is 3987 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 929, but not defined == Unused Reference: 'RFC5234' is defined on line 708, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clark 3 Internet-Draft Telchemy 4 Intended status: Standards Track Q. Wu 5 Expires: November 28, 2013 Huawei 6 R. Schott 7 Deutsche Telekom 8 G. Zorn 9 Network Zen 10 May 27, 2013 12 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for QoE Metric 13 Reporting 14 draft-ietf-xrblock-rtcp-xr-qoe-08 16 Abstract 18 This document defines an RTP Control Protocol (RTCP) Extended Report 19 (XR) Block including two new segment types and associated SDP 20 parameters that allow the reporting of QoE metrics for use in a range 21 of RTP applications. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 28, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. QoE Metrics Report Block . . . . . . . . . . . . . . . . . 3 59 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 60 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 61 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 64 3. QoE Metrics Block . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 5 66 3.2. Definition of Fields in QoE Metrics Block . . . . . . . . 6 67 3.2.1. Single Stream Audio/Video per SSRC Segment . . . . . 7 68 3.2.2. Multi-Channel audio per SSRC Segment . . . . . . . . . 8 69 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 9 71 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 11 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 13 74 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 13 75 5.3. Contact information for registrations . . . . . . . . . . 13 76 5.4. New registry of calculation algorithms . . . . . . . . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Appendix A. Example of User Quality of Experience Evaluation 84 for video stream . . . . . . . . . . . . . . . . . . 17 85 Appendix B. Metrics represented using RFC6390 Template . . . . . 18 86 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 20 87 C.1. draft-ietf-xrblock-rtcp-xr-qoe-08 . . . . . . . . . . . . 21 88 C.2. draft-ietf-xrblock-rtcp-xr-qoe-07 . . . . . . . . . . . . 21 89 C.3. draft-ietf-xrblock-rtcp-xr-qoe-06 . . . . . . . . . . . . 21 90 C.4. draft-ietf-xrblock-rtcp-xr-qoe-04 . . . . . . . . . . . . 21 91 C.5. draft-ietf-xrblock-rtcp-xr-qoe-03 . . . . . . . . . . . . 21 92 C.6. draft-ietf-xrblock-rtcp-xr-qoe-02 . . . . . . . . . . . . 21 93 C.7. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 21 94 C.8. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 1.1. QoE Metrics Report Block 101 This document defines a new block type to augment those defined in 102 [RFC3611], for use in a range of RTP applications. 104 The new block type provides information on media quality using one of 105 several standard metrics. 107 The metrics belong to the class of application level metrics defined 108 in [RFC6792]. 110 1.2. RTCP and RTCP XR Reports 112 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 113 defined an extensible structure for reporting using an RTCP Extended 114 Report (XR). This draft defines a new Extended Report block for use 115 with [RFC3550] and [RFC3611]. 117 1.3. Performance Metrics Framework 119 The Performance Metrics Framework [RFC6390] provides guidance on the 120 definition and specification of performance metrics. The RTP 121 Monitoring Architectures [RFC6792] provides guideline for reporting 122 block format using RTCP XR. The XR Block described in this document 123 are in accordance with the guidelines in [RFC6390] and [RFC6792]. 125 1.4. Applicability 127 The QoE Metrics Report Block can be used in any application of RTP 128 for which QoE measurement algorithms are defined. 130 The factors that affect real-time Audio/Video application quality can 131 be split into two categories. The first category consists of 132 transport- dependent factors such as packet loss, delay and jitter 133 (which also translates into losses in the playback buffer). The 134 factors in the second category are application-specific factors that 135 affect real time application (e.g., video) quality and are 136 sensitivity to network errors. These factors can be but not limited 137 to video codec and loss recovery technique, coding bit rate, 138 packetization scheme, and content characteristics. 140 Compared with application-specific factors, the transport-dependent 141 factors sometimes are not sufficient to measure real time media 142 quality, since the ability to analyze the real time media in the 143 application layer provides quantifiable measurements for subscriber 144 Quality of Experience (QoE) that may not be captured in the 145 transmission layers or from the RTP layer down. In a typical 146 scenario, monitoring of the transmission layers can produce 147 statistics suggesting that quality is not an issue, such as the fact 148 that network jitter is not excessive. However, problems may occur in 149 the service layers leading to poor subscriber QoE. Therefore 150 monitoring using only network-level measurements may be insufficient 151 when application layer media quality is required. 153 In order to provide accurate measures of real time media quality when 154 transporting real time media across a network, the QoE Metrics is 155 highly required which can be conveyed in the RTCP XR packets 156 [RFC3611] and may have the following three benefits: 158 o Tuning the content encoder algorithm to satisfy real time data 159 quality requirements. 160 o Determining which system techniques to use in a given situation 161 and when to switch from one technique to another as system 162 parameters change. 163 o Verifying the continued correct operation of an existing system. 165 2. Terminology 167 2.1. Standards Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 The terminology used is 175 Numeric formats S X:Y 177 where S indicates a two's complement signed representation, X 178 the number of bits prior to the decimal place and Y the number 179 of bits after the decimal place. 180 Hence 8:8 represents an unsigned number in the range 0.0 to 181 255.996 with a granularity of 0.0039. S7:8 would represent the 182 range -127.996 to +127.996. 0:16 represents a proper binary 183 fraction with range 184 0.0 to 1 - 1/65536 = 0.9999847 185 though note that use of flag values at the top of the numeric 186 range slightly reduces this upper limit. For example, if the 187 16- bit values 0xfffe and 0xffff are used as flags for "over- 188 range" and "unavailable" conditions, a 0:16 quantity has range 189 0.0 to 1 - 3/65536 = 0.9999542 191 3. QoE Metrics Block 193 Multimedia application QoE metric is commonly expressed as a MOS 194 ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 5 195 represents excellent and 1 represents unacceptable. MOS scores are 196 usually obtained using subjective testing or using objective 197 algorithm. However Subjective testing to estimate the multimedia 198 quality may be not suitable for measuring the multimedia quality 199 since the results may vary from test to test. Therefore using 200 objective algorithm to calculate MOS scores is recommended. ITU-T 201 recommendations define the methodologies for assessment of the 202 performance of multimedia stream 203 [G.107][P.564][G.1082][P.1201.1][P.1201.2][P.1202.1][P.NBAMS-HR] and 204 provides a method to evaluate QoE estimation algorithms and objective 205 model for video and audio. Hence this document recommends vendors 206 and implementers to use these International Telecommunication Union 207 (ITU)-specified methodologies to measure parameters when possible. 209 This block reports the multimedia application performance or media 210 quality beyond the information carried in the standard RTCP packet 211 format. Information is recorded about QoE metric which provides a 212 measure that is indicative of the user's view of a service. The 213 measurement of metrics in this block are usually made at the 214 receiving end of the RTP stream. Instances of this Metrics Block 215 refer by Synchronization source (SSRC) to the separate auxiliary 216 Measurement Information block [RFC6776] which describes measurement 217 periods in use (see RFC6776 section 4.2). 219 This Metrics Block relies on the measurement period in the 220 Measurement Information block indicating the span of the report. 221 Senders MUST send this block in the same compound RTCP packet as the 222 measurement information block. Receivers MUST verify that the 223 measurement period is received in the same compound RTCP packet as 224 this Metrics Block. If not, this Metrics Block MUST be discarded. 226 3.1. Metric Block Structure 228 The report block contents are dependent upon a series of flag bits 229 carried in the first part of the header. Not all parameters need to 230 be reported in each block. Flags indicate which are and which are 231 not reported. The fields corresponding to unreported parameters MUST 232 be present, but are set to zero. The receiver MUST ignore any QoE 233 Metrics Block with a non-zero value in any field flagged as 234 unreported. The encoding of QoE metrics block payload consists of a 235 series of 32 bit units called segments that describe MOS Type, MoS 236 algorithm and MoS value. 238 The QoE Metrics Block has the following format: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | BT=QMB | I | Reserved | Block Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | SSRC of source | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Segment 1 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Segment 2 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 .................. 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Segment n | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 3.2. Definition of Fields in QoE Metrics Block 258 Block type (BT): 8 bits 260 The QoE Metrics Block is identified by the constant . 262 Interval Metric flag (I): 2 bits 264 This field is used to indicate whether the QoE metrics are 265 Sampled, Interval or Cumulative metrics [RFC6792]: 267 I=10: Interval Duration - the reported value applies to the 268 most recent measurement interval duration between successive 269 metrics reports. 270 I=11: Cumulative Duration - the reported value applies to the 271 accumulation period characteristic of cumulative measurements. 272 I=01: Sampled Value - the reported value is a sampled 273 instantaneous value. 275 In this document, the value I=00 is reserved for future use. 276 Senders MUST NOT use the values I=00. If a block is received with 277 I=00, the receiver MUST discard the block. 279 Reserved: 6 bits 281 This field is reserved for future definition. In the absence of 282 such a definition, the bits in this field MUST be set to zero and 283 ignored by the receiver (See RFC6709 section 4.2). 285 Block Length: 16 bits 287 The length of this report block in 32-bit words, minus one. For 288 the QoE Metrics Block, the block length is variable length. 290 SSRC of source: 32 bits 292 As defined in Section 4.1 of [RFC3611]. 294 Segment i: 32 bits 296 There are two segment types defined in this document: single 297 stream Audio/Video per SSRC segment, multi-channel audio per SSRC 298 segment. Multi-channel audio per SSRC segment is used to deal 299 with the case where Multi-channel audios are carried in one RTP 300 stream while single stream Audio/Video per SSRC segment is used to 301 deal with the case where each media stream is identified by SSRC 302 and sent in separate RTP stream. The leftmost bit of the segment 303 determines its type. If the leftmost bit of the segment is zero, 304 then it is single stream segment. If the leftmost bit is one, 305 then it is multi-channel audio segment. Note that two segment 306 types can not be present in the same metric block. 308 3.2.1. Single Stream Audio/Video per SSRC Segment 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |S| CAID | PT | MOS Value | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Segment Type (S): 1 bit 316 This field is used to identify the segment type used in this 317 report block. A zero identifies this as a single stream Audio/ 318 Video per SSRC segment. Single stream means there is only one 319 media stream carried in one RTP stream. The single stream Audio/ 320 Video per SSRC segment can be used to report the MoS value 321 associated with the media stream identified by SSRC. If there are 322 multiple media streams and they want to use the single stream 323 Audio/Video per SSRC segment to report the MOS value, they should 324 be carried in the separate RTP streams with each identified by 325 different SSRC. In this case, multiple QoE Metrics Blocks are 326 required to report the MOS value corresponding to each media 327 stream using single stream Audio/Video per SSRC segment in the 328 same RTCP XR packet. 330 Calg Algorithm ID (CAID) : 8bits 332 The 8-bit CAID is the local identifier of calculation algorithm 333 associated with this segment in the range 1-255 inclusive. 335 Payload Type (PT): 7 bits 337 QoE metrics reporting depends on the payload format in use. This 338 field identifies the format of the RTP payload. For RTP sessions 339 where multiple payload formats can be negotiated or the payload 340 format changes during the mid-session), the value of this field 341 will be used to indicate what payload format was in use for the 342 reporting interval. 344 MOS Value: 16 bits 346 The estimated mean opinion score for multimedia application 347 performance is defined as including the effects of delay,loss, 348 discard,jitter and other effects that would affect media quality. 349 It is expressed in numeric format 8:8 with the value in the range 350 0.0 to 255.996. The valid the measured value ranges from 0.0 to 351 50.0, corresponding to MoS x 10 as for MoS. If the measured value 352 is over ranged, the value 0xFFFE MUST be reported to indicate an 353 over-range measurement. If the measurement is unavailable, the 354 value 0xFFFF MUST be reported. Values other than 0xFFFE,0xFFFF 355 and the valid range defined above MUST NOT be sent and MUST be 356 ignored by the receiving system. 358 3.2.2. Multi-Channel audio per SSRC Segment 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |S| CAID | PT |CHID | MOS Value | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Segment Type (S): 1 bit 366 This field is used to identify the segment type used in this 367 report block. A one identifies this as a multi-channel audio 368 segment. 370 CAlg Algorithm ID (CAID) : 8bits 372 The 8-bit ID is the local identifier of this segment in the range 373 1-255 inclusive. 375 Payload Type (PT): 7 bits 377 As defined in Section 3.2.1 of this document. 379 Channel Identifier (CHID): 3 bits 381 If multiple channels of audio are carried in one RTP stream, each 382 channel of audio will be viewed as a independent channel(e.g., 383 left channel audio, right channel audio). This field is used to 384 identify each channel carried in the same media stream. The 385 default Channel mapping follows static ordering rule described in 386 the section 4.1 of [RFC3551]. However there are some payload 387 formats that use different channel mappings, e.g., AC-3 audio over 388 RTP [RFC4184] only follow AC-3 channel order scheme defined in 389 [ATSC]. Enhanced AC-3 Audio over RTP [RFC4598] uses dynamic 390 channel transform mechanism. In order that the appropriate 391 channel mapping can be determined, QoE reports need to be tied to 392 an RTP payload format, i.e., including the payload type of the 393 reported media according to [RFC6792] and using Payload Type to 394 determine the appropriate channel mapping. 396 MOS Value: 13 bits 398 The estimated mean opinion score for multimedia application 399 performance is defined as including the effects of delay,loss, 400 discard,jitter and other effects that would affect multimedia 401 quality . It is expressed in numeric format 6:7 with the value in 402 the range 0.0 to 63.992. The valid the measured value ranges from 403 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the 404 measured value is over ranged, the value 0x1FFE MUST be reported 405 to indicate an over-range measurement. If the measurement is 406 unavailable, the value 0x1FFF MUST be reported. Values other than 407 0x1FFE,0x1FFF and the valid range defined above MUST NOT be sent 408 and MUST be ignored by the receiving system. 410 4. SDP Signaling 412 [RFC3611] defines the use of SDP (Session Description Protocol) 413 [RFC4566] for signaling the use of XR blocks. However XR blocks MAY 414 be used without prior signaling (see section 5 of RFC3611). 416 4.1. SDP rtcp-xr-attrib Attribute Extension 418 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 419 in [RFC3611] by providing an additional value of "xr-format" to 420 signal the use of the report block defined in this document. Within 421 the "xr-format", the syntax element "extmap" is an attribute as 422 defined in [RFC4566] and used to signal the mapping of the local 423 identifier (CAID) in the segment extension defined in section 3.2 to 424 the calculation algorithm. Specific extensionattributes are defined 425 by the specification that defines a specific extension name; there 426 may be several. 428 xr-format =/ xr-qoe-block 429 xr-qoe-block = "qoe-metrics" ["=" extmap *("," extmap)] 430 extmap = mapentry "=" extensionname [SP extentionattributes] 431 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 432 mapentry = "calg:" 1*5 DIGIT ["/" direction] 433 extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564] 434 / "G107";ITU-T G.107 [G.107] 435 / "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI] 436 /"JJ201_01 ";TTC JJ201.01 [TTC] 437 /"P1201_01";ITU-T P.1201.2 [P.1201.1] 438 /"P1201_02";ITU-T P.1201.2 [P.1201.2] 439 /"P1202_01";ITU-T P.1202.1 [P.1202.1] 440 /"P1202_02";ITU-T P. NBAMS-HR [P.NBAMS-HR] 441 / non-ws-string 442 extentionattributes = mosref 443 /attributes-ext 444 mosref = "mosref=" ("l"; lower resolution 445 / "h";higher resolution 446 / "lh";both lower resolution and 447 ;high resolution are supported 448 / non-ws-string 449 attributes-ext = non-ws-string 450 SP = 451 non-ws-string = 1*(%x21-FF) 453 Each local identifier (CAID)of calculation algorithm used in the 454 segment defined in the section 3.2 is mapped to a string using an 455 attribute of the form: 457 a=extmap: ["/"] [] 459 where is a calculation algorithm name, as above, is 460 the local identifier (CAID)of the calculation algorithm associated 461 with the segment defined in this document and is an integer in the 462 valid range inclusive. 464 Example: 465 a = rtcp-xr:qoe-metrics = calg:1=G107,calg:2=P1202.1 467 A usable mapping MUST use IDs in the valid range, and each ID in this 468 range MUST be unique and used only once for each stream or each 469 channel in the stream. 471 The mapping MUST be provided per media stream (in the media-level 472 section(s) of SDP, i.e., after an "m=" line). 474 The syntax element "mosref" is referred to the media resolution(e.g., 475 Narrowband (3.4kHz) Speech and Standard Definition (SD) Resolution 476 Video with lower resolution, Wideband (7kHz) Speech and High 477 Definition (HD) Resolution Video with higher resolution). MOS scores 478 reported in the QoE block may vary with the MoS reference; For 479 example MOS values for narrowband, wideband codecs occupy the same 480 range but should be reported in different value. For video 481 application, MoS scores for SD resolution, HD resolution video also 482 occupy the same ranges and should be reported in different value. 484 4.2. Offer/Answer Usage 486 When SDP is used in offer-answer context, the SDP Offer/Answer usage 487 defined in [RFC3611] applies. In the offer answer context, the 488 signaling described above may be used in three ways: 490 o asymmetric behavior (segment extensions sent in only one 491 direction), 492 o the offer of mutually exclusive alternatives, or 493 o the offer of more segments than can be sent in a single session. 495 A direction attribute MAY be included in an extmap; without it, the 496 direction implicitly inherits, of course, from the RTCP stream 497 direction. 499 Segment extension, with their directions, may be signaled for an 500 "inactive" stream. It is an error to use an extension direction 501 incompatible with the stream direction (e.g., a "sendonly" attribute 502 for a "recvonly" stream). 504 If an segment extension is offered as "sendrecv", explicitly or 505 implicitly, and asymmetric behavior is desired, the SDP may be 506 modified to modify or add direction qualifiers for that segment 507 extension. 509 A mosref attribute MAY be included in an extmap; without it, the 510 mosref implicitly inherits, of course, from the name attribute (e.g., 511 P.1201.1 [P.1201.1] indicates lower resolution used while P.1201.2 512 [P.1201.2] indicates higher resolution used) or payload type carried 513 in the segment extension (e.g.,EVRC-WB [RFC5188] indicates using 514 Wideband Codec). However not all payload types or MoS algorithm 515 names indicates resolution to be used. 517 If an segment extension is offered as "lh", explicitly, and 518 asymmetric behavior is desired, the SDP may be modified to modify 519 mosref attribute value for that segment extension. 521 If an answerer receives an offer with an mosref attribute value it 522 doesn't support (e.g.,the answerer only supports "l" and receives 523 "h"from offerer), the answer should reject the mosref attribute value 524 offered by the offerer. 526 If the answerer wishes to reject a mosref attribute offered by the 527 offerer, it sets identifiers associated with segment extensions in 528 the answer to the value in the range 4096-4351. The rejected answer 529 MUST contain 'mosref ' attribute whose value is the value of the SDP 530 offer. 532 Local identifiers in the valid range inclusive in an offer or answer 533 must not be used more than once per media section. A session update 534 MAY change the direction qualifiers of segment extensions under use. 535 A session update MAY add or remove segment extension(s). Identifiers 536 values in the valid range MUST NOT be altered (remapped). 538 If a party wishes to offer mutually exclusive alternatives, then 539 multiple segment extensions with the same identifier in the 540 (unusable) range 4096-4351 may be offered; the answerer should select 541 at most one of the offered extensions with the same identifier, and 542 remap it to a free identifier in the valid range, for that extension 543 to be usable. Note that two segment types defined in section 3 are 544 also two exclusive alternatives. 546 If more segment extensions are offered in the valid range, the 547 answerer should choose those that are desired, and place the offered 548 identifier value "as is" in the SDP answer. 550 Similarly, if more segment extensions are offered than can be fit in 551 the valid range, identifiers in the range 4096-4351 may be offered; 552 the answerer should choose those that are desired, and remap them to 553 a free identifier in the valid range. 555 Note that the range 4096-4351 for these negotiation identifiers is 556 deliberately restricted to allow expansion of the range of valid 557 identifiers in future. Segment extensions with an identifier outside 558 the valid range cannot, of course, be used. 560 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 561 all omitted for brevity): 563 The offer: 565 a=rtcp-xr:qoe- 566 metrics=calg:4906=P1201.1l,calg:4906=P1202.1l,calg:4907=G107 568 The answerer is interested in transmission P.1202.1 on lower 569 resolution application, but doesn't support P.1201.1 on lower 570 resolution application at all. It is interested in transmission 571 G.107. It therefore adjusts the declarations: 573 a=rtcp-xr:qoe-metrics=calg:1=P1202.1l, calg:2=G107 575 5. IANA Considerations 577 New block types for RTCP XR are subject to IANA registration. For 578 general guidelines on IANA considerations for RTCP XR, refer to 579 [RFC3611]. 581 5.1. New RTCP XR Block Type value 583 This document assigns the block type value QMB in the IANA "RTCP XR 584 Block Type Registry" to the "QoE Metrics Block". 586 [Note to RFC Editor: please replace QMB with the IANA provided RTCP 587 XR block type for this block.] 589 5.2. New RTCP XR SDP Parameter 591 This document also registers a new parameter "qoe-metrics" in the 592 "RTCP XR SDP Parameters Registry". 594 5.3. Contact information for registrations 596 The contact information for the registrations is: 598 Qin Wu 599 sunseawq@huawei.com 600 101 Software Avenue, Yuhua District 601 Nanjing, JiangSu 210012 China 603 5.4. New registry of calculation algorithms 605 This document creates a new registry to be called "RTCP XR QoE metric 606 block - multimedia application Calculation Algorithm" as a sub- 607 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 608 Block Type Registry". This registry applies to the multimedia 609 session where each type of media are sent in a separate RTP stream 610 and also applies to the session where Multi-channel audios are 611 carried in one RTP stream. Policies for this new registry are as 612 follows: 614 o The information required to support this assignment is an 615 unambiguous definition of the new metric, covering the base 616 measurements and how they are processed to generate the reported 617 metric. 619 o The review process for the registry is "Specification Required" as 620 described in Section 4.1 of [RFC5226]. 622 o Entries in the registry are identified by entry name and mapped to 623 the local identifier (CAID) in the segment extension defined in 624 section 3.2. 626 o Registration Template 628 The following information must be provided with each registration: 629 * Name: A string uniquely and unambiguously identifying the 630 Calculation algorithm for use in protocols. 631 * Name Description: A valid Description of the Calculation 632 algorithm name. 633 * Reference: The reference which defines the calculation 634 algorithm corresponding to the Name and Name Description. 635 * Type: The media type to which the calculation algorithm is 636 applied 638 o Initial assignments are as follows: 640 Name Name Description Reference Type 641 ========= =================================== ========== ==== 642 P564 ITU-T P.564 Compliant Algorithm [P.564] Voice 643 G107 ITU-T G.107 [G.107] Voice 644 TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice 645 JJ201_01 TTC JJ201.01 [TTC] Voice 646 P1201_01 ITU-T P.1201.01 [P.1201.1] Multimedia 647 P1201_02 ITU-T P.1201.02 [P.1201.2] Multimedia 648 P1202_01 ITU-T P.1202.01 [P.1202.01] Video 649 P1202_02 ITU-T P. NBAMS-HR [P. NBAMS-HR] Video 651 6. Security Considerations 653 The new RTCP XR report blocks proposed in this document introduces no 654 new security considerations beyond those described in [RFC3611]. 656 7. Authors 658 This draft merges ideas from two drafts addressing the QoE metric 659 Reporting issue. The authors of these drafts are listed below (in 660 alphabetical order): 662 Alan Clark < alan.d.clark@telchemy.com > 663 Geoff Hunt < r.geoff.hunt@gmail.com > 664 Martin Kastner < martin.kastner@telchemy.com > 665 Kai Lee < leekai@ctbri.com.cn > 666 Roland Schott < roland.schott@telekom.de > 667 Qin Wu < sunseawq@huawei.com > 668 Glen Zorn < gwz@net-zen.net > 670 8. Acknowledgements 672 The authors gratefully acknowledge the comments and contributions 673 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 674 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 675 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 676 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 677 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Bill Ver Steeg, David R 678 Oran, Ali Begen and Hideaki Yamada. 680 9. References 682 9.1. Normative References 684 [ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC 685 Standard: Digital Audio Compression (AC-3), Revision B", 686 ATSC Doc A/52B, June 2005. 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, March 1997. 691 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 692 Applications", RFC 3550, July 2003. 694 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 695 Video Conferences with Minimal Control", RFC 3551, 696 July 2003. 698 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 699 Protocol Extended Reports (RTCP XR)", RFC 3611, 700 November 2003. 702 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 703 Description Protocol", RFC 4566, July 2006. 705 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 706 Section in RFCs", RFC 5226, May 2008. 708 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 709 Specifications: ABNF", STD 68, RFC 5234, January 2008. 711 [RFC6776] Wu, Q., "Measurement Identity and information Reporting 712 using SDES item and XR Block", RFC 6776, October 2012. 714 9.2. Informative References 716 [ETSI] ETSI, "Quality of Service (QoS) measurement 717 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 719 [G.107] ITU-T, "The E Model, a computational model for use in 720 transmission planning", ITU-T Recommendation G.107, 721 April 2009. 723 [G.1082] ITU-T, "Measurement-based methods for improving the 724 robustness of IPTV performance", ITU-T 725 Recommendation G.1082, April 2009. 727 [P.1201.1] 728 ITU-T, "Parametric non-intrusive assessment of audiovisual 729 media streaming quality - lower resolution application 730 area", ITU-T Recommendation P.1201.1, October 2012. 732 [P.1201.2] 733 ITU-T, "Parametric non-intrusive assessment of audiovisual 734 media streaming quality - higher resolution application 735 area", ITU-T Recommendation P.1201.2, October 2012. 737 [P.1202.1] 738 ITU-T, "Parametric non-intrusive bitstream assessment of 739 video media streaming quality - lower resolution 740 application area", ITU-T Recommendation P.1202.1, 741 October 2012. 743 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 744 transmission quality assessment models", ITU-T 745 Recommendation P.564, July 2006. 747 [P.NBAMS-HR] 748 ITU-T, "Parametric non-intrusive bitstream assessment of 749 video media streaming quality - higher resolution 750 application area", ITU-T Recommendation P.NBAMS-HR, 751 October 2012. 753 [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for 754 AC-3 Audio", RFC 4184, October 2005. 756 [RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload 757 Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, 758 July 2006. 760 [RFC5188] Desineni, H. and Q. Xie, "RTP Payload Format for the 761 Enhanced Variable Rate Wideband Codec (EVRC-WB) and the 762 Media Subtype Updates for EVRC-B Codec", RFC 5188, 763 February 2008. 765 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 766 Development", RFC 6390, October 2011. 768 [RFC6792] Wu, Q., "Monitoring Architectures for RTP", RFC 6792, 769 November 2012. 771 [TTC] TTC 201.01 (Japan), "A method for speech quality 772 assessment for Voice over IP". 774 Appendix A. Example of User Quality of Experience Evaluation for video 775 stream 777 To evaluate user quality of experience levels using objective test 778 data, MoS Scores provide a familiar, easily understood numeric 779 representation of video, audio, and overall audiovisual quality. 780 Unlike audio, video is even more sensitive to transport impairments , 781 and even low rates of packet loss can cause severe degradation in 782 perceived quality. However, all occurrences of packet loss do not 783 have an equal impact on perceptual quality, in part because of the 784 way video frames are structured during the encoding process - such as 785 frame properties including frame type, frame structure and 786 quantization parameter (QP), and in part due to subjective factors - 787 such as the degree to which perception is affected by the levels of 788 motion, detail in the video sequence, and decoder characteristic 789 parameters including media resolution,codec type. When a video 790 stream is sent from the media source to RTP receiving end and get 791 monitored. in order to provide accurate evaluation of video quality, 792 one possible QoE evaluation method is having network nodes that 793 implement network management tools in place. They may know frame 794 properties,perception degree, decoder characteristic parameters of 795 this video stream using some out of band means, gather transport 796 impairment information received from the RTP receiving end and use 797 them as MoS calculation input parameters to calculate MoS scores by 798 choosing appropriate MoS calculation algorithm. Such MoS Scores 799 value can be useful for troubleshooting or comparing video quality 800 across different service types. 802 Appendix B. Metrics represented using RFC6390 Template 804 RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC 805 number, when assigned. 807 a. MoS Value Metric 809 * Metric Name: Mos value 811 * Metric Description: The estimated mean opinion score for 812 multimedia application performance is defined as including the 813 effects of delay,loss, discard,jitter and other effects that 814 would affect multimedia quality. 816 * Method of Measurement or Calculation: See section 3.2.1, MoS 817 value definition [RFCXXXX]. 819 * Units of Measurement: See section 3.2.1, MoS value definition 820 [RFCXXXX]. 822 * Measurement Point(s) with Potential Measurement Domain: See 823 section 3, 2nd paragraph [RFCXXXX]. 825 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 826 measurement timing and section 3.1 [RFCXXXX] for Interval 827 Metric flag. 829 * Use and applications: See section 1.4 [RFCXXXX]. 831 * Reporting model: See RFC3611. 833 b. Segment Type Metric 835 * Metric Name: Segment Type 837 * Metric Description: It is used to identify the segment type 838 used in this report block. For more details, see section 839 3.2.1, Segment type definition. 841 * Method of Measurement or Calculation: See section 3.2.1, 842 Segment Type definition [RFCXXXX]. 844 * Units of Measurement: See section 3.2.1, Segment Type 845 definition [RFCXXXX]. 847 * Measurement Point(s) with Potential Measurement Domain: See 848 section 3, 2nd paragraph [RFCXXXX]. 850 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 851 measurement timing and section 3.1 [RFCXXXX] for Interval 852 Metric flag. 854 * Use and applications: See section 1.4 [RFCXXXX]. 856 * Reporting model: See RFC3611. 858 c. Calg Algorithm Identifier Metric 860 * Metric Name: Calg Algorithm Identifier 862 * Metric Description: It is the local identifier of calculation 863 Algorithm associated with this segment in the range 1-255 864 inclusive. 866 * Method of Measurement or Calculation: See section 3.2.1, Calg 867 Algorithm ID definition [RFCXXXX]. 869 * Units of Measurement: See section 3.2.1, Calg Algorithm ID 870 definition[RFCXXXX]. 872 * Measurement Point(s) with Potential Measurement Domain: See 873 section 3, 2nd paragraph [RFCXXXX]. 875 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 876 measurement timing and section 3.1 [RFCXXXX] for Interval 877 Metric flag. 879 * Use and applications: See section 1.4 [RFCXXXX]. 881 * Reporting model: See RFC3611. 883 d. Payload Type Metric 885 * Metric Name: Payload Type 887 * Metric Description: It is used to identify the format of the 888 RTP payload. For more details, see section 3.2.1, payload 889 type definition. 891 * Method of Measurement or Calculation: See section 3.2.1, 892 Payload type definition [RFCXXXX]. 894 * Units of Measurement: See section 3.2.1, payload type 895 definition[RFCXXXX]. 897 * Measurement Point(s) with Potential Measurement Domain: See 898 section 3, 2nd paragraph [RFCXXXX]. 900 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 901 measurement timing and section 3.1 [RFCXXXX] for Interval 902 Metric flag. 904 * Use and applications: See section 1.4 [RFCXXXX]. 906 * Reporting model: See RFC3611. 908 e. Channel Identifier Metric 910 * Metric Name: Payload Type 912 * Metric Description: It is used to identify each channel 913 carried in the same media stream. For more details, see 914 section 3.2.2, channel identifier definition. 916 * Method of Measurement or Calculation: See section 3.2.2, 917 Channel Identifier definition [RFCXXXX]. 919 * Units of Measurement: See section 3.2.2, channel identifier 920 definition[RFCXXXX]. 922 * Measurement Point(s) with Potential Measurement Domain: See 923 section 3, 2nd paragraph [RFCXXXX]. 925 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 926 measurement timing and section 3.1 [RFCXXXX] for Interval 927 Metric flag. 929 * Use and applications: See section 1.4 [RFCXXXX]. 931 * Reporting model: See RFC3611. 933 Appendix C. Change Log 934 C.1. draft-ietf-xrblock-rtcp-xr-qoe-08 936 The following are the major changes compared to previous version: 937 o Remove mostype attribute from SDP extension since it can inferred 938 from payload type. 939 o Clarify mosref attribute usage in the O/A. 941 C.2. draft-ietf-xrblock-rtcp-xr-qoe-07 943 The following are the major changes compared to previous version: 944 o Some editorial changes to get in line with burst gap related 945 draft. 946 o Add an appendix to apply RFC6390 template. 948 C.3. draft-ietf-xrblock-rtcp-xr-qoe-06 950 The following are the major changes compared to previous two 951 versions: 952 o A few Contact information update. 953 o A few Acknowledgement section update. 955 C.4. draft-ietf-xrblock-rtcp-xr-qoe-04 957 The following are the major changes compared to previous version: 958 o Split two references P.NAMS and P.NBAMS into four references. 959 o SDP signaling update. 960 o Add one example to explain User QoE evaluation for video stream 962 C.5. draft-ietf-xrblock-rtcp-xr-qoe-03 964 The following are the major changes compared to previous version: 965 o Add one new reference to support TTC JJ201.01. 966 o Update two references P.NAMS and P.NBAMS. 967 o Other Editorial changes based on comments applied to PDV and Delay 968 drafts. 970 C.6. draft-ietf-xrblock-rtcp-xr-qoe-02 972 The following are the major changes compared to previous version: 973 o Remove leftmost second bit since it is ueeless. 974 o Change 13bits MoS value field into 14 bits to increase MoS 975 precision. 976 o Fix some typo and make some editorial changes. 978 C.7. draft-ietf-xrblock-rtcp-xr-qoe-01 980 The following are the major changes compared to previous version: 982 o Remove layered support from the QoE metric draft. 983 o Allocate 7 bits in the block header for payload type to indicate 984 what type of payload format is in use and add associated 985 definition of payload type. 986 o Clarify using Payload Type to determine the appropriate channel 987 mapping in the definition of Channel Identifier. 989 C.8. draft-ietf-xrblock-rtcp-xr-qoe-00 991 The following are the major changes compared to previous version: 992 o Allocate one more bit in the single stream per SSC segment to get 993 alignment with the other two segment type. 995 Authors' Addresses 997 Alan Clark 998 Telchemy Incorporated 999 2905 Premiere Parkway, Suite 280 1000 Duluth, GA 30097 1001 USA 1003 Email: alan.d.clark@telchemy.com 1005 Qin Wu 1006 Huawei 1007 101 Software Avenue, Yuhua District 1008 Nanjing, Jiangsu 210012 1009 China 1011 Email: sunseawq@huawei.com 1013 Roland Schott 1014 Deutsche Telekom 1015 Heinrich-Hertz-Strasse 3-7 1016 Darmstadt 64295 1017 Germany 1019 Email: Roland.Schott@telekom.de 1020 Glen Zorn 1021 Network Zen 1022 77/440 Soi Phoomjit, Rama IV Road 1023 Phra Khanong, Khlong Toie 1024 Bangkok 10110 1025 Thailand 1027 Phone: +66 (0) 87 502 4274 1028 Email: gwz@net-zen.net