idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-qoe-06.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 -- The document date (February 25, 2013) is 4070 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) == Unused Reference: 'RFC5234' is defined on line 665, 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 (~~), 2 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: August 29, 2013 Huawei 6 R. Schott 7 Deutsche Telekom 8 G. Zorn 9 Network Zen 10 February 25, 2013 12 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for QoE Metric 13 Reporting 14 draft-ietf-xrblock-rtcp-xr-qoe-06 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 August 29, 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 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 . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Appendix A. Evaluation Example of User Quality of Experience 84 for video stream . . . . . . . . . . . . . . . . . . 16 85 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 86 B.1. draft-ietf-xrblock-rtcp-xr-qoe-06 . . . . . . . . . . . . 17 87 B.2. draft-ietf-xrblock-rtcp-xr-qoe-04 . . . . . . . . . . . . 17 88 B.3. draft-ietf-xrblock-rtcp-xr-qoe-03 . . . . . . . . . . . . 17 89 B.4. draft-ietf-xrblock-rtcp-xr-qoe-02 . . . . . . . . . . . . 18 90 B.5. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 18 91 B.6. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 1.1. QoE Metrics Report Block 98 This document defines a new block type to augment those defined in 99 [RFC3611], for use in a range of RTP applications. 101 The new block type provides information on multimedia quality using 102 one of several standard metrics. 104 The metrics belong to the class of application level metrics defined 105 in [RFC6792]. 107 1.2. RTCP and RTCP XR Reports 109 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 110 defined an extensible structure for reporting using an RTCP Extended 111 Report (XR). This draft defines a new Extended Report block for use 112 with [RFC3550] and [RFC3611]. 114 1.3. Performance Metrics Framework 116 The Performance Metrics Framework [RFC6390] provides guidance on the 117 definition and specification of performance metrics. The RTP 118 Monitoring Architectures [RFC6792] provides guideline for reporting 119 block format using RTCP XR. The XR Block described in this document 120 are in accordance with the guidelines in [RFC6390] and [RFC6792]. 122 1.4. Applicability 124 The QoE Metrics Report Block can be used in any application of RTP 125 for which QoE measurement algorithms are defined. 127 The factors that affect real-time AV application quality can be split 128 into two categories. The first category consists of transport- 129 dependent factors such as packet loss, delay and jitter (which also 130 translates into losses in the playback buffer). The factors in the 131 second category are application-specific factors that affect real 132 time application (e.g., video) quality and are sensitivity to network 133 errors. These factors can be but not limited to video codec and loss 134 recovery technique, coding bit rate, packetization scheme, and 135 content characteristics. 137 Compared with application-specific factors, the transport-dependent 138 factors sometimes are not sufficient to measure real time data 139 quality, since the ability to analyze the real time data in the 140 application layer provides quantifiable measurements for subscriber 141 Quality of Experience (QoE) that may not be captured in the 142 transmission layers or from the RTP layer down. In a typical 143 scenario, monitoring of the transmission layers can produce 144 statistics suggesting that quality is not an issue, such as the fact 145 that network jitter is not excessive. However, problems may occur in 146 the service layers leading to poor subscriber QoE. Therefore 147 monitoring using only network-level measurements may be insufficient 148 when application layer content quality is required. 150 In order to provide accurate measures of real time application 151 quality when transporting real time contents across a network, the 152 synthentical multimedia quality Metrics is highly required which can 153 be conveyed in the RTCP XR packets[RFC3611] and may have the 154 following three benefits: 156 o Tuning the content encoder algorithm to satisfy real time data 157 quality requirements. 158 o Determining which system techniques to use in a given situation 159 and when to switch from one technique to another as system 160 parameters change. 161 o Verifying the continued correct operation of an existing system. 163 2. Terminology 165 2.1. Standards Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 The terminology used is 173 Numeric formats S X:Y 175 where S indicates a two's complement signed representation, X 176 the number of bits prior to the decimal place and Y the number 177 of bits after the decimal place. 178 Hence 8:8 represents an unsigned number in the range 0.0 to 179 255.996 with a granularity of 0.0039. S7:8 would represent the 180 range -127.996 to +127.996. 0:16 represents a proper binary 181 fraction with range 182 0.0 to 1 - 1/65536 = 0.9999847 183 though note that use of flag values at the top of the numeric 184 range slightly reduces this upper limit. For example, if the 185 16- bit values 0xfffe and 0xffff are used as flags for "over- 186 range" and "unavailable" conditions, a 0:16 quantity has range 187 0.0 to 1 - 3/65536 = 0.9999542 189 3. QoE Metrics Block 191 This block reports the multimedia application performance or quality 192 beyond the information carried in the standard RTCP packet format. 193 Information is recorded about multimedia application QoE metric which 194 provides a measure that is indicative of the user's view of a 195 service. Multimedia application QoE metric is commonly expressed as 196 a MOS ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 197 5 represents excellent and 1 represents unacceptable. MOS scores are 198 usually obtained using subjective testing or using objective 199 algorithm. However Subjective testing to estimate the multimedia 200 quality may be not suitable for measuring the multimedia quality 201 since the results may vary from test to test. Therefore using 202 objective algorithm to calculate MOS scores is recommended. ITU-T 203 recommendations define the methodologies for assessment of the 204 performance of multimedia stream 205 [G.107][P.564][G.1082][P.1201.1][P.1201.2][P.1202.1][P.NBAMS-HR] and 206 provides a method to evaluate QoE estimation algorithms and objective 207 model for video and audio. Hence this document recommends vendors 208 and implementers to use these International Telecommunication Union 209 (ITU)-specified methodologies to measure parameters when possible. 211 3.1. Metric Block Structure 213 The report block contents are dependent upon a series of flag bits 214 carried in the first part of the header. Not all parameters need to 215 be reported in each block. Flags indicate which are and which are 216 not reported. The fields corresponding to unreported parameters MUST 217 be present, but are set to zero. The receiver MUST ignore any QoE 218 Metrics Block with a non-zero value in any field flagged as 219 unreported. The encoding of QoE metrics block payload consists of a 220 series of 32 bit units called segments that describe MOS Type, MoS 221 algorithm and MoS value. 223 The QoE Metrics Block has the following format: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | BT=QMB | I | Reserved | Block Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | SSRC of source | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Segment 1 | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Segment 2 | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 .................. 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Segment n | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 3.2. Definition of Fields in QoE Metrics Block 243 Block type (BT): 8 bits 245 The QoE Metrics Block is identified by the constant . 247 Interval Metric flag (I): 2 bits 249 This field is used to indicate whether the QoE metrics are 250 Interval or Cumulative metrics, that is, whether the reported 251 values applies to the most recent measurement interval duration 252 between successive metrics reports (I=10) (the Interval Duration) 253 or to the accumulation period characteristic of cumulative 254 measurements (I=11) (the Cumulative Duration) or is a sampled 255 instantaneous value (I=01) (Sampled Value). 257 Reserved.: 6 bits 259 This field is reserved for future definition. In the absence of 260 such a definition, the bits in this field MUST be set to zero and 261 MUST be ignored by the receiver. 263 Block Length: 16 bits 265 The length of this report block in 32-bit words, minus one. For 266 the QoE Metrics Block, the block length is variable length. 268 SSRC of source: 32 bits 270 As defined in Section 4.1 of [RFC3611]. 272 Segment i: 32 bits 274 There are two segment types defined in this document: single 275 stream per SSRC segment, multi-channel audio per SSRC segment. 276 Multi-channel audio per SSRC segment is used to deal with the case 277 where Multi-channel audios are carried in one RTP stream while 278 single stream per SSRC segment is used to deal with the case where 279 each media stream is identified by SSRC and sent in separate RTP 280 stream. The leftmost bit of the segment determines its type. If 281 the leftmost bit of the segment is zero, then it is single stream 282 segment. If the leftmost bit is one, then it is multi-channel 283 audio segment. Note that two segment types can not be present in 284 the same metric block. 286 3.2.1. Single Stream per SSRC Segment 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |S| CAID | PT | MOS Value | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Segment Type (S): 1 bit 294 This field is used to identify the segment type used in this 295 report block. A zero identifies this as a single stream segment. 296 Single stream means there is only one media stream carried in one 297 RTP stream. The single stream segment can be used to report the 298 MoS value associated with the media stream identified by SSRC. If 299 there are multiple media streams and they want to use the single 300 stream per SSRC segment to report the MOS value, they should be 301 carried in the separate RTP streams with each identified by 302 different SSRC. In this case, multiple QoE Metrics Blocks are 303 required to report the MOS value corresponding to each media 304 stream using single stream segment in the same RTCP XR packet. 306 Calg Algorithm ID (CAID) : 8bits 308 The 8-bit CAID is the local identifier of calculation algorithm 309 associated with this segment in the range 1-255 inclusive. 311 Payload Type (PT): 7 bits 313 QoE metrics reporting depends on the payload format in use. This 314 field identifies the format of the RTP payload. For RTP sessions 315 where multiple payload formats can be negotiated or the payload 316 format changes during the mid-session), the value of this field 317 will be used to indicate what payload format was in use for the 318 reporting interval. 320 MOS Value: 16 bits 322 The estimated mean opinion score for multimedia application 323 quality is defined as including the effects of delay,loss, 324 discard,jitter and other effects that would affect multimedia 325 quality . It is expressed in numeric format 8:8 with the value in 326 the range 0.0 to 255.996. The valid the measured value ranges 327 from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the 328 measured value is over ranged, the value 0xFFFE MUST be reported 329 to indicate an over-range measurement. If the measurement is 330 unavailable, the value 0xFFFF MUST be reported. Values other than 331 0xFFFE,0xFFFF and the valid range defined above MUST NOT be sent 332 and MUST be ignored by the receiving system. 334 3.2.2. Multi-Channel audio per SSRC Segment 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |S| CAID | PT |CHID | MOS Value | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Segement Type (S): 1 bit 342 This field is used to identify the segment type used in this 343 report block. A one identifies this as a multi-channel audio 344 segment. 346 CAlg Algorithm ID (CAID) : 8bits 348 The 8-bit ID is the local identifier of this segment in the range 349 1-255 inclusive. 351 Payload Type (PT): 7 bits 353 As defined in Section 3.2.1 of this document. 355 Channel Identifier (CHID): 3 bits 357 If multiple channels of audio are carried in one RTP stream, each 358 channel of audio will be viewed as a independent channel(e.g., 359 left channel audio, right channel audio). This field is used to 360 identify each channel carried in the same media stream. The 361 default Channel mapping follows static ordering rule described in 362 the section 4.1 of [RFC3551]. However there are some payload 363 formats that use different channel mappings, e.g., AC-3 audio over 364 RTP [RFC4184] only follow AC-3 channel order scheme defined in 365 [ATSC]. Enhanced AC-3 Audio over RTP [RFC4598] uses dynamic 366 channel transform mechanism. In order that the appropriate 367 channel mapping can be determined, QoE reports need to be tied to 368 an RTP payload format, i.e., including the payload type of the 369 reported media according to [RFC6792] and using Payload Type to 370 determine the appropriate channel mapping. 372 MOS Value: 13 bits 374 The estimated mean opinion score for multimedia application 375 quality is defined as including the effects of delay,loss, 376 discard,jitter and other effects that would affect multimedia 377 quality . It is expressed in numeric format 6:7 with the value in 378 the range 0.0 to 63.992. The valid the measured value ranges from 379 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the 380 measured value is over ranged, the value 0x1FFE MUST be reported 381 to indicate an over-range measurement. If the measurement is 382 unavailable, the value 0x1FFF MUST be reported. Values other than 383 0x1FFE,0x1FFF and the valid range defined above MUST NOT be sent 384 and MUST be ignored by the receiving system. 386 4. SDP Signaling 388 [RFC3611] defines the use of SDP (Session Description Protocol) 389 [RFC4566] for signaling the use of XR blocks. However XR blocks MAY 390 be used without prior signaling (see section 5 of RFC3611). 392 4.1. SDP rtcp-xr-attrib Attribute Extension 394 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 395 in [RFC3611] by providing an additional value of "xr-format" to 396 signal the use of the report block defined in this document. Within 397 the "xr-format", the syntax element "extmap" is an attribute as 398 defined in [RFC4566] and used to signal the mapping of the local 399 identifier (CAID) in the segment extension defined in section 3.2 to 400 the calculation algorithm. Specific extensionattributes are defined 401 by the specification that defines a specific extension name; there 402 may be several. 404 xr-format =/ xr-qoe-block 405 xr-qoe-block = "qoe-metrics" ["=" extmap *("," extmap)] 406 extmap = mapentry "=" extensionname [SP extentionattributes] 407 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 408 mapentry = "calg:" 1*5 DIGIT ["/" direction] 409 extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564] 410 / "G107";ITU-T G.107 [G.107] 411 / "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI] 412 /"JJ201_01 ";TTC JJ201.01 [TTC] 413 /"P1201_01";ITU-T P.1201.2 [P.1201.1] 414 /"P1201_02";ITU-T P.1201.2 [P.1201.2] 415 /"P1202_01";ITU-T P.1202.1 [P.1202.1] 416 /"P1202_02";ITU-T P. NBAMS-HR [P.NBAMS-HR] 417 / non-ws-string 418 extentionattributes = mediatype 419 /mosreference 420 /attributes-ext 421 mediatype = "a" ;voice 422 / "v" ;video 423 /"m" ;multimedia 424 mosreference = "mosref=" ("0"; lower resolution 425 / "1";higher resolution 426 / 1*2DIGIT ) ;Value 2~15 are valid and 427 ;reserved for future use 428 attributes-ext = non-ws-string 429 SP = 430 DIGIT = 431 non-ws-string = 1*(%x21-FF) 433 Each local identifier (CAID)of calculation algorithm used in the 434 segment defined in the section 3.2 is mapped to a string using an 435 attribute of the form: 437 a=extmap: ["/"] 439 where is a calculation algorithm name, as above, is 440 the local identifier (CAID)of the calculation algorithm associated 441 with the segment defined in this document and is an integer in the 442 valid range inclusive. 444 Example: 445 a = calg:1=G107,calg:2=P1202.1 447 A usable mapping MUST use IDs in the valid range, and each ID in this 448 range MUST be unique and used only once for each stream or each 449 channel in the stream. 451 The mapping MUST be provided per media stream (in the media-level 452 section(s) of SDP, i.e., after an "m=" line). 454 Note that the syntax element "mosreference" is referred to the media 455 resolution(e.g., Narrowband (3.4kHz) Speech and Standard Definition 456 (SD) Resolution Video with lower resolution, Wideband (7kHz) Speech 457 and High Definition (HD) Resolution Video with higher resolution). 458 MOS scores reported in the QoE block may vary with the Mos reference; 459 For example MOS values for narrowband, wideband codecs occupy the 460 same range but should be reported in different value. For video 461 application,MoS scores for SD resolution, HD resolution video also 462 occupy the same ranges and should be reported in different value. 464 4.2. Offer/Answer Usage 466 When SDP is used in offer-answer context, the SDP Offer/Answer usage 467 defined in [RFC3611] applies. In the offer answer context, the 468 signaling described above may be used in three ways: 470 o asymmetric behavior (segment extensions sent in only one 471 direction), 472 o the offer of mutually exclusive alternatives, or 473 o the offer of more segments than can be sent in a single session. 475 A direction attribute MAY be included in an extmap; without it, the 476 direction implicitly inherits, of course, from the stream direction. 478 Segment extension, with their directions, may be signaled for an 479 "inactive" stream. It is an error to use an extension direction 480 incompatible with the stream direction (e.g., a "sendonly" attribute 481 for a "recvonly" stream). 483 If an segment extension map is offered as "sendrecv", explicitly or 484 implicitly, and asymmetric behavior is desired, the SDP may be 485 modified to modify or add direction qualifiers for that segment 486 extension. 488 Local identifiers in the valid range inclusive in an offer or answer 489 must not be used more than once per media section. A session update 490 MAY change the direction qualifiers of segment extensions under use. 491 A session update MAY add or remove segment extension(s). Identifiers 492 values in the valid range MUST NOT be altered (remapped). 494 If a party wishes to offer mutually exclusive alternatives, then 495 multiple segment extensions with the same identifier in the 496 (unusable) range 4096-4351 may be offered; the answerer should select 497 at most one of the offered extensions with the same identifier, and 498 remap it to a free identifier in the valid range, for that extension 499 to be usable. Note that two segment types defined in section 3 are 500 also two exclusive alternatives. 502 If more segment extensions are offered in the valid range, the 503 answerer should choose those that are desired, and place the offered 504 identifier value "as is" in the SDP answer. 506 Similarly, if more segment extensions are offered than can be fit in 507 the valid range, identifiers in the range 4096-4351 may be offered; 508 the answerer should choose those that are desired, and remap them to 509 a free identifier in the valid range. 511 Note that the range 4096-4351 for these negotiation identifiers is 512 deliberately restricted to allow expansion of the range of valid 513 identifiers in future. segment extensions with an identifier outside 514 the valid range cannot, of course, be used. 516 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 517 all omitted for brevity): 519 The offer: 521 a=rtcp-xr:qoe- 522 metrics=calg:4906=P1201.1m,calg:4906=P1202.1v,calg:4907=G107a 524 The answerer is interested in transmission P.1202.1 only on video, 525 but doesn't understand P.1202.1 at all. It is interested in 526 transmission G.107 on audio. It therefore adjusts the declarations: 528 a=rtcp-xr:qoe-metrics=calg:1=P1202.1v, calg:2=G107a 530 5. IANA Considerations 532 New block types for RTCP XR are subject to IANA registration. For 533 general guidelines on IANA considerations for RTCP XR, refer to 534 [RFC3611]. 536 5.1. New RTCP XR Block Type value 538 This document assigns the block type value MMQ in the IANA "RTCP XR 539 Block Type Registry" to the "QoE Metrics Block". 541 [Note to RFC Editor: please replace MMQ with the IANA provided RTCP 542 XR block type for this block.] 544 5.2. New RTCP XR SDP Parameter 546 This document also registers a new parameter "qoe-metrics" in the 547 "RTCP XR SDP Parameters Registry". 549 5.3. Contact information for registrations 551 The contact information for the registrations is: 553 Qin Wu 554 sunseawq@huawei.com 555 101 Software Avenue, Yuhua District 556 Nanjing, JiangSu 210012 China 558 5.4. New registry of calculation algorithms 560 This document creates a new registry to be called "RTCP XR QoE metric 561 block - multimedia application Calculation Algorithm" as a sub- 562 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 563 Block Type Registry". This registry applies to the multimedia 564 session where each type of media are sent in a separate RTP stream 565 and also applies to the session where Multi-channel audios are 566 carried in one RTP stream. Policies for this new registry are as 567 follows: 569 o The information required to support this assignment is an 570 unambiguous definition of the new metric, covering the base 571 measurements and how they are processed to generate the reported 572 metric. This should include the units of measurement, how values 573 of the metric are reported in the one 16-bit fields or 13-bit 574 fields "MoS Value". 576 o The review process for the registry is "Specification Required" as 577 described in Section 4.1 of [RFC5226]. 579 o Entries in the registry are identified by entry name and mapped to 580 the local identifier (CAID) in the segment extension defined in 581 section 3.2. 583 o Registration Template 585 The following information must be provided with each registration: 586 * Name: A string uniquely and unambiguously identifying the 587 Calculation algorithm for use in protocols. 588 * Name Description: A valid Description of the Calculation 589 algorithm name. 591 * Reference: The reference which defines the calculation 592 algorithm corresponding to the Name and Name Description. 593 * Type: The media type to which the calculation algorithm is 594 applied 596 o Initial assignments are as follows: 598 Name Name Description Reference Type 599 ========= =================================== ========== ==== 600 P564 ITU-T P.564 Compliant Algorithm [P.564] Voice 601 G107 ITU-T G.107 [G.107] Voice 602 TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice 603 JJ201_01 TTC JJ201.01 [TTC] Voice 604 P1201_01 ITU-T P.1201.01 [P.1201.1] Multimedia 605 P1201_02 ITU-T P.1201.02 [P.1201.2] Multimedia 606 P1202_01 ITU-T P.1202.01 [P.1202.01] Video 607 P1202_02 ITU-T P. NBAMS-HR [P. NBAMS-HR] Video 609 6. Security Considerations 611 The new RTCP XR report blocks proposed in this document introduces no 612 new security considerations beyond those described in [RFC3611]. 614 7. Authors 616 This draft merges ideas from two drafts addressing the QoE metric 617 Reporting issue. The authors of these drafts are listed below (in 618 alphabetical order): 619 Alan Clark < alan.d.clark@telchemy.com > 620 Geoff Hunt < r.geoff.hunt@gmail.com > 621 Martin Kastner < martin.kastner@telchemy.com > 622 Kai Lee < leekai@ctbri.com.cn > 623 Roland Schott < roland.schott@telekom.de > 624 Qin Wu < sunseawq@huawei.com > 625 Glen Zorn < gwz@net-zen.net > 627 8. Acknowledgements 629 The authors gratefully acknowledge the comments and contributions 630 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 631 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 632 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 633 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 634 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Bill Ver Steeg, David R 635 Oran, Ali Begen and Hideaki Yamada. 637 9. References 639 9.1. Normative References 641 [ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC 642 Standard: Digital Audio Compression (AC-3), Revision B", 643 ATSC Doc A/52B, June 2005. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 649 Applications", RFC 3550, July 2003. 651 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 652 Video Conferences with Minimal Control", RFC 3551, 653 July 2003. 655 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 656 Protocol Extended Reports (RTCP XR)", RFC 3611, 657 November 2003. 659 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 660 Description Protocol", RFC 4566, July 2006. 662 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 663 Section in RFCs", RFC 5226, May 2008. 665 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 666 Specifications: ABNF", STD 68, RFC 5234, January 2008. 668 9.2. Informative References 670 [ETSI] ETSI, "Quality of Service (QoS) measurement 671 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 673 [G.107] ITU-T, "The E Model, a computational model for use in 674 transmission planning", ITU-T Recommendation G.107, 675 April 2009. 677 [G.1082] ITU-T, "Measurement-based methods for improving the 678 robustness of IPTV performance", ITU-T 679 Recommendation G.1082, April 2009. 681 [P.1201.1] 682 ITU-T, "Parametric non-intrusive assessment of audiovisual 683 media streaming quality - lower resolution application 684 area", ITU-T Recommendation P.1201.1, October 2012. 686 [P.1201.2] 687 ITU-T, "Parametric non-intrusive assessment of audiovisual 688 media streaming quality - higher resolution application 689 area", ITU-T Recommendation P.1201.2, October 2012. 691 [P.1202.1] 692 ITU-T, "Parametric non-intrusive bitstream assessment of 693 video media streaming quality - lower resolution 694 application area", ITU-T Recommendation P.1202.1, 695 October 2012. 697 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 698 transmission quality assessment models", ITU-T 699 Recommendation P.564, July 2006. 701 [P.NBAMS-HR] 702 ITU-T, "Parametric non-intrusive bitstream assessment of 703 video media streaming quality - higher resolution 704 application area", ITU-T Recommendation P.NBAMS-HR, 705 October 2012. 707 [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for 708 AC-3 Audio", RFC 4184, October 2005. 710 [RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload 711 Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, 712 July 2006. 714 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 715 Development", RFC 6390, October 2011. 717 [RFC6792] Wu, Q., "Monitoring Architectures for RTP", RFC 6792, 718 November 2012. 720 [TTC] TTC 201.01 (Japan), "A method for speech quality 721 assessment for Voice over IP". 723 Appendix A. Evaluation Example of User Quality of Experience for video 724 stream 726 To evaluate user quality of experience levels using objective test 727 data. MoS Scores provide a familiar, easily understood numeric 728 representation of video, audio, and overall audiovisual quality. 729 Unlike audio, video is even more sensitive to transport impairments 730 than voice, and even low rates of packet loss can cause severe 731 degradation in perceived quality. However, all occurrences of packet 732 loss do not have an equal impact on perceptual quality, in part 733 because of the way video frames are structured during the encoding 734 process - such as frame properties including frame type and 735 quantization parameter (QP), frame structure, and in part due to 736 subjective factors - such as the degree to which perception is 737 affected by the levels of motion and detail in the video sequence, 738 demux/decoder statistics characteristic parameters including packet 739 loss concealment metrics,jitter buffer metrics and/or Frame loss rate 740 parameter. Note that Frame loss rate can be derived When a video 741 stream is sent from the media source to RTP receiving end and get 742 monitored, in order to provide accurate evaluation of video quality, 743 One possible evaluation method of QoE is the network nodes that 744 implement network management tools may get frame 745 properties,perception degree as MoS calculation input parameters from 746 media source, and demux/decoder statistics characteristic parameters 747 and transport impairment as other MoS calculation input parameters 748 from the RTP receiving end and use appropriate MoS calculation 749 algorithm to calculate MoS scores. Such MoS Scores value can be 750 useful for troubleshooting or comparing video quality across 751 different service types. 753 Appendix B. Change Log 755 B.1. draft-ietf-xrblock-rtcp-xr-qoe-06 757 The following are the major changes compared to previous two 758 versions: 759 o A few Contact information update. 760 o A few Acknowledgement section update. 762 B.2. draft-ietf-xrblock-rtcp-xr-qoe-04 764 The following are the major changes compared to previous version: 765 o Split two references P.NAMS and P.NBAMS into four references. 766 o SDP signaling update. 767 o Add one example to explain User QoE evaluation for video stream 769 B.3. draft-ietf-xrblock-rtcp-xr-qoe-03 771 The following are the major changes compared to previous version: 772 o Add one new reference to support TTC JJ201.01. 773 o Update two references P.NAMS and P.NBAMS. 774 o Other Editorial changes based on comments applied to PDV and Delay 775 drafts. 777 B.4. draft-ietf-xrblock-rtcp-xr-qoe-02 779 The following are the major changes compared to previous version: 780 o Remove leftmost second bit since it is ueeless. 781 o Change 13bits MoS value field into 14 bits to increase MoS 782 precision. 783 o Fix some typo and make some editorial changes. 785 B.5. draft-ietf-xrblock-rtcp-xr-qoe-01 787 The following are the major changes compared to previous version: 788 o Remove layered support from the QoE metric draft. 789 o Allocate 7 bits in the block header for payload type to indicate 790 what type of payload format is in use and add associated 791 definition of payload type. 792 o Clarify using Payload Type to determine the appropriate channel 793 mapping in the definition of Channel Identifier. 795 B.6. draft-ietf-xrblock-rtcp-xr-qoe-00 797 The following are the major changes compared to previous version: 798 o Allocate one more bit in the single stream per SSC segment to get 799 alignment with the other two segment type. 801 Authors' Addresses 803 Alan Clark 804 Telchemy Incorporated 805 2905 Premiere Parkway, Suite 280 806 Duluth, GA 30097 807 USA 809 Email: alan.d.clark@telchemy.com 811 Qin Wu 812 Huawei 813 101 Software Avenue, Yuhua District 814 Nanjing, Jiangsu 210012 815 China 817 Email: sunseawq@huawei.com 818 Roland Schott 819 Deutsche Telekom 820 Heinrich-Hertz-Strasse 3-7 821 Darmstadt 64295 822 Germany 824 Email: Roland.Schott@telekom.de 826 Glen Zorn 827 Network Zen 828 77/440 Soi Phoomjit, Rama IV Road 829 Phra Khanong, Khlong Toie 830 Bangkok 10110 831 Thailand 833 Phone: +66 (0) 87 502 4274 834 Email: gwz@net-zen.net