idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-qoe-11.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 306 has weird spacing: '...o/video per S...' -- The document date (September 6, 2013) is 3886 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 976, but not defined == Unused Reference: 'RFC5234' is defined on line 736, 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: March 10, 2014 Huawei 6 R. Schott 7 Deutsche Telekom 8 G. Zorn 9 Network Zen 10 September 6, 2013 12 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MoS Metric 13 Reporting 14 draft-ietf-xrblock-rtcp-xr-qoe-11 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 MoS 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 March 10, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. MoS Metrics Report Block . . . . . . . . . . . . . . . . . 4 59 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 4 60 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 61 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 5 64 3. MoS Metrics Block . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 6 66 3.2. Definition of Fields in MoS Metrics Block . . . . . . . . 7 67 3.2.1. Single Channel audio/video per SSRC Segment . . . . . 8 68 3.2.2. Multi-Channel audio per SSRC Segment . . . . . . . . . 9 69 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 10 71 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 12 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 14 74 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 14 75 5.3. The SDP calgextmap Attribute . . . . . . . . . . . . . . . 14 76 5.4. New registry of calculation algorithms . . . . . . . . . . 15 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Example of User Quality of Experience Evaluation 84 for video stream . . . . . . . . . . . . . . . . . . 19 85 Appendix B. Metrics represented using RFC6390 Template . . . . . 20 86 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22 87 C.1. draft-ietf-xrblock-rtcp-xr-qoe-10 . . . . . . . . . . . . 22 88 C.2. draft-ietf-xrblock-rtcp-xr-qoe-09 . . . . . . . . . . . . 23 89 C.3. draft-ietf-xrblock-rtcp-xr-qoe-08 . . . . . . . . . . . . 23 90 C.4. draft-ietf-xrblock-rtcp-xr-qoe-07 . . . . . . . . . . . . 23 91 C.5. draft-ietf-xrblock-rtcp-xr-qoe-06 . . . . . . . . . . . . 23 92 C.6. draft-ietf-xrblock-rtcp-xr-qoe-04 . . . . . . . . . . . . 23 93 C.7. draft-ietf-xrblock-rtcp-xr-qoe-03 . . . . . . . . . . . . 23 94 C.8. draft-ietf-xrblock-rtcp-xr-qoe-02 . . . . . . . . . . . . 24 95 C.9. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 24 96 C.10. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 99 1. Introduction 101 1.1. MoS Metrics Report Block 103 This document defines a new block type to augment those defined in 104 [RFC3611], for use in a range of RTP applications. 106 The new block type provides information on media quality using one of 107 several standard metrics (i.e.,Mean Opinion Score(MoS)). 109 The metrics belong to the class of application level metrics defined 110 in [RFC6792]. 112 1.2. RTCP and RTCP XR Reports 114 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 115 defined an extensible structure for reporting using an RTCP Extended 116 Report (XR). This document defines a new Extended Report block for 117 use with [RFC3550] and [RFC3611]. 119 1.3. Performance Metrics Framework 121 The Performance Metrics Framework [RFC6390] provides guidance on the 122 definition and specification of performance metrics. The RTP 123 Monitoring Architectures [RFC6792] provides guidelines for reporting 124 block format using RTCP XR. The XR block type described in this 125 document are in accordance with the guidelines in [RFC6390] and 126 [RFC6792]. 128 1.4. Applicability 130 The MoS Metrics Report Block can be used in any application of RTP 131 for which QoE measurement algorithms are defined. 133 The factors that affect real-time audio/video application quality can 134 be split into two categories. The first category consists of 135 transport-specific factors such as packet loss, delay and jitter 136 (which also translates into losses in the playback buffer). The 137 factors in the second category are application-specific factors that 138 affect real time application (e.g., video) quality. These factors 139 can be but are not limited to video codec and loss recovery 140 technique, coding bit rate, packetization scheme, and content 141 characteristics. 143 Compared with application-specific factors, the transport-specific 144 factors sometimes are not sufficient to measure real time media 145 quality, since the ability to analyze the real time media in the 146 application layer provides quantifiable measurements for end user 147 Quality of Experience (QoE) that may not be captured in the 148 transmission layers or from the RTP layer down. In a typical 149 scenario, monitoring of the transmission layers can produce 150 statistics suggesting that quality is not an issue, such as the fact 151 that network jitter is not excessive. However, problems may occur in 152 the service layers leading to poor subscriber QoE. Therefore 153 monitoring using only network-level measurements may be insufficient 154 when application layer media quality is required. 156 In order to provide accurate measures of real time media quality when 157 transporting real time media across a network, the QoE 158 Metrics(e.g.,MoS Metrics) are highly recommended which can be 159 conveyed in the RTCP XR packets [RFC3611] and may have the following 160 three benefits: 162 o Tuning the content encoder algorithm to satisfy real time data 163 quality requirements. 164 o Determining which system techniques to use in a given situation 165 and when to switch from one technique to another as system 166 parameters change. 167 o Verifying the continued correct operation of an existing system. 169 2. Terminology 171 2.1. Standards Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 The terminology used is 179 Numeric formats S X:Y 181 where S indicates a two's complement signed representation, X 182 the number of bits prior to the decimal place and Y the number 183 of bits after the decimal place. 184 Hence 8:8 represents an unsigned number in the range 0.0 to 185 255.996 with a granularity of 0.0039. S7:8 would represent the 186 range -127.996 to +127.996. 0:16 represents a proper binary 187 fraction with range 188 0.0 to 1 - 1/65536 = 0.9999847 189 though note that use of flag values at the top of the numeric 190 range slightly reduces this upper limit. For example, if the 191 16- bit values 0xfffe and 0xffff are used as flags for "over- 192 range" and "unavailable" conditions, a 0:16 quantity has range 193 0.0 to 1 - 3/65536 = 0.9999542 195 3. MoS Metrics Block 197 Multimedia application MoS Metric is commonly expressed as a MOS 198 ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 5 199 represents excellent and 1 represents unacceptable. MOS scores are 200 usually obtained using subjective testing or using objective 201 algorithm. However Subjective testing to estimate the multimedia 202 quality may be not suitable for measuring the multimedia quality 203 since the results may vary from test to test. Therefore using 204 objective algorithm to calculate MOS scores is RECOMMENDED. ITU-T 205 recommendations (e.g., [G.107][G.107.1][P.862][P.862.1][P.862.2] 207 [P.863][P.564][G.1082][P.1201.1][P.1201.2][P.1202.1][P.1202.2]) 208 define the methodologies for assessment of the performance of 209 multimedia stream and provides a method to evaluate QoE estimation 210 algorithms and objective model for video and audio. Hence this 211 document recommends vendors and implementers to use these 212 International Telecommunication Union (ITU)-specified methodologies 213 to measure parameters when possible. 215 This block reports the multimedia application performance or media 216 quality beyond the information carried in the standard RTCP packet 217 format. Information is recorded about MoS Metric which provides a 218 measure that gives a numerical indication of the perceived quality of 219 the media received. The measurement of metrics in this block are 220 usually made at the receiving end of the RTP stream. Instances of 221 this Metrics Block refer by Synchronization source (SSRC) to the 222 separate auxiliary Measurement Information block [RFC6776] which 223 describes measurement periods in use (see RFC6776 section 4.2). 225 This Metrics Block relies on the measurement period in the 226 Measurement Information block indicating the span of the report. 227 Senders MUST send this block in the same compound RTCP packet as the 228 measurement information block. Receivers MUST verify that the 229 measurement period is received in the same compound RTCP packet as 230 this Metrics Block. If not, this Metrics Block MUST be discarded. 232 3.1. Metric Block Structure 234 The MoS Metrics Block has the following format: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | BT=MMB | I | Reserved | Block Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | SSRC of source | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Segment 1 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Segment 2 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 .................. 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Segment n | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 3.2. Definition of Fields in MoS Metrics Block 254 Block type (BT): 8 bits 256 The MoS Metrics Block is identified by the constant . 258 Interval Metric flag (I): 2 bits 260 This field is used to indicate whether the MoS Metrics are 261 Sampled, Interval or Cumulative metrics [RFC6792]: 263 I=10: Interval Duration - the reported value applies to the 264 most recent measurement interval duration between successive 265 metrics reports. 266 I=11: Cumulative Duration - the reported value applies to the 267 accumulation period characteristic of cumulative measurements. 268 I=01: Sampled Value - the reported value is a sampled 269 instantaneous value. 271 In this document, MoS Metrics can only be measured at each 272 interval duration, and cannot be sampled or cumulated. Also the 273 value I=00 is reserved for future use. Senders MUST NOT use the 274 values I=00 or I=01 or I=11. If a block is received with I=00 or 275 I=01 or I=11, the receiver MUST discard the block. 277 Reserved: 6 bits 279 This field is reserved for future definition. In the absence of 280 such a definition, the bits in this field MUST be set to zero and 281 ignored by the receiver (See RFC6709 section 4.2). 283 Block Length: 16 bits 285 The length of this report block in 32-bit words, minus one. For 286 the MoS Metrics Block, the block length is variable length. 288 SSRC of source: 32 bits 290 As defined in Section 4.1 of [RFC3611]. 292 Segment i: 32 bits 294 There are two segment types defined in this document: single 295 stream Audio/Video per SSRC segment, multi-channel audio per SSRC 296 segment. Multi-channel audio per SSRC segment is used to deal 297 with the case where Multi-channel audios are carried in one RTP 298 stream while single channel Audio/Video per SSRC segment is used 299 to deal with the case where each media stream is identified by 300 SSRC and sent in separate RTP stream. The leftmost bit of the 301 segment determines its type. If the leftmost bit of the segment 302 is zero, then it is single channel segment. If the leftmost bit 303 is one, then it is multi-channel audio segment. Note that two 304 segment types can not be present in the same metric block. 306 3.2.1. Single Channel audio/video per SSRC Segment 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |S| CAID | PT | MOS Value | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Segment Type (S): 1 bit 314 This field is used to identify the segment type used in this 315 report block. A zero identifies this as a single channel Audio/ 316 Video per SSRC segment. Single channel means there is only one 317 media stream carried in one RTP stream. The single channel Audio/ 318 Video per SSRC segment can be used to report the MoS value 319 associated with the media stream identified by SSRC. If there are 320 multiple media streams and they want to use the single channel 321 Audio/Video per SSRC segment to report the MOS value, they should 322 be carried in the separate RTP streams with each identified by 323 different SSRC. In this case, multiple MoS Metrics Blocks are 324 required to report the MOS value corresponding to each media 325 stream using single channel Audio/Video per SSRC segment in the 326 same RTCP XR packet. 328 Calg Algorithm ID (CAID) : 8bits 330 The 8-bit CAID is the local identifier of calculation algorithm 331 associated with this segment in the range 1-255 inclusive. 333 Payload Type (PT): 7 bits 335 MoS Metrics reporting depends on the payload format in use. This 336 field identifies the RTP payload type in use during the reporting 337 interval. The binding between RTP payload types and RTP payload 338 formats is configured via a signalling protocol, for example an 339 SDP offer/answer exchange. If the RTP payload type used is 340 changed during an RTP session, separate reports SHOULD be sent for 341 each RTP payload type, with corresponding measurement information 342 blocks indicating the time period to which they relate. 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, MoS metrics reports need to be 392 tied to an RTP payload format, i.e., including the payload type of 393 the reported media according to [RFC6792] and using Payload Type 394 to 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 "calgextmap" 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 might be several. 428 xr-format =/ xr-mos-block 429 xr-mos-block = "mos-metrics" ["=" extmap *("," calgextmap)] 430 calgextmap = mapentry "=" extensionname [SP extentionattributes] 431 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 432 mapentry = "calg:" 1*5 DIGIT ["/" direction] 433 ;Values other than 4095~4351 are valid 434 extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564] 435 / "G107";ITU-T G.107 [G.107] 436 / "G107_1";ITU-T G.107.1 [G.107.1] 437 / "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI] 438 /"JJ201_1 ";TTC JJ201.1 [TTC] 439 /"P1201_1";ITU-T P.1201.2 [P.1201.1] 440 /"P1201_2";ITU-T P.1201.2 [P.1201.2] 441 /"P1202_1";ITU-T P.1202.1 [P.1202.1] 442 /"P1202_2";ITU-T P.1202.2 [P.1202.2] 443 /"P.862.2";ITU-T P.862.2 [P.862.2] 444 /"P.863"; ITU-T P.863 [P.863] 445 / non-ws-string 446 extentionattributes = mosref 447 /attributes-ext 448 mosref = "mosref=" ("l"; lower resolution 449 /"m"; middle resolution 450 / "h";higher resolution 451 / non-ws-string) 452 mostype = "mostype=" ("e"; Estimated MoS [P.800.1] 453 /"s";subjective MoS [P.800.1] 454 /"o";objective MoS [P.800.1] 455 /non-ws-string) 456 attributes-ext = non-ws-string 457 SP = 458 non-ws-string = 1*(%x21-FF) 460 Each local identifier (CAID)of calculation algorithm used in the 461 segment defined in the section 3.2 is mapped to a string using an 462 attribute of the form: 464 a=calgextmap: ["/"] [] 466 where is a calculation algorithm name, as above, is 467 the local identifier (CAID)of the calculation algorithm associated 468 with the segment defined in this document and is an integer in the 469 valid range inclusive. 471 Example: 472 a=rtcp-xr:mos-metrics=calg:1=G107,calg:2=P1202_1 474 A usable mapping MUST use IDs in the valid range, and each ID in this 475 range MUST be unique and used only once for each stream or each 476 channel in the stream. 478 The mapping MUST be provided per media stream (in the media-level 479 section(s) of SDP, i.e., after an "m=" line). 481 The syntax element "mosref" is referred to the media resolution 482 relative reference and has three valules 'l','m','h'.(e.g., 483 Narrowband (3.4kHz) Speech and StandardDefinition (SD) or lower 484 Resolution Video have 'l' resolution, Super Wideband (>14kHz) Speech 485 or higher and High Definition (HD) or higher Resolution Video have 486 'h' Resolution, Wideband speech(7khz) and Video with resolution 487 between SD and HD has 'm' resolution). MOS scores reported in the 488 mos metrics block might vary with the MoS reference; For example, MOS 489 values for narrowband, wideband,super wideband codecs occupy the same 490 range but SHOULD be reported in different value. For video 491 application, MoS scores for SD resolution, HD resolution video also 492 occupy the same ranges and SHOULD be reported in different value. 494 4.2. Offer/Answer Usage 496 When SDP is used in offer-answer context, the SDP Offer/Answer usage 497 defined in [RFC3611] applies. In the offer answer context, the 498 signaling described above might be used in three ways: 500 o asymmetric behavior (segment extensions sent in only one 501 direction), 502 o the offer of mutually exclusive alternatives, or 503 o the offer of more segments than can be sent in a single session. 505 A direction attribute MAY be included in a calgextmap; without it, 506 the direction implicitly inherits, of course, from the RTCP stream 507 direction. 509 Segment extension, with their directions, MAY be signaled for an 510 "inactive" stream. It is an error to use an extension direction 511 incompatible with the stream direction (e.g., a "sendonly" attribute 512 for a "recvonly" stream). 514 If an segment extension is offered as "sendrecv", explicitly or 515 implicitly, and asymmetric behavior is desired, the SDP MAY be 516 modified to modify or add direction qualifiers for that segment 517 extension. 519 A mosref attribute and mos type attribute MAY be included in an 520 calgextmap; without it, the mosref and most type attribute implicitly 521 inherits, of course, from the name attribute (e.g., P.1201.1 522 [P.1201.1] indicates lower resolution used while P.1201.2 [P.1201.2] 523 indicates higher resolution used) or payload type carried in the 524 segment extension (e.g.,EVRC-WB [RFC5188] indicates using Wideband 525 Codec). However not all payload types or MoS algorithm names 526 indicate resolution to be used and mos type to be used. 528 If an answerer receives an offer with an mosref attribute value it 529 doesn't support (e.g.,the answerer only supports "l" and receives 530 "h"from offerer), the answer SHOULD reject the mosref attribute value 531 offered by the offerer. 533 If the answerer wishes to reject a mosref attribute offered by the 534 offerer, it sets identifiers associated with segment extensions in 535 the answer to the value in the range 4096-4351. The rejected answer 536 MUST contain 'mosref ' attribute whose value is the value of the SDP 537 offer. 539 Local identifiers in the valid range inclusive in an offer or answer 540 must not be used more than once per media section. A session update 541 MAY change the direction qualifiers of segment extensions under use. 542 A session update MAY add or remove segment extension(s). Identifiers 543 values in the valid range MUST NOT be altered (remapped). 545 If a party wishes to offer mutually exclusive alternatives, then 546 multiple segment extensions with the same identifier in the 547 (unusable) range 4096-4351 MAY be offered; the answerer SHOULD select 548 at most one of the offered extensions with the same identifier, and 549 remap it to a free identifier in the valid range, for that extension 550 to be usable. Note that two segment types defined in section 3 are 551 also two exclusive alternatives. 553 If more segment extensions are offered in the valid range, the 554 answerer SHOULD choose those that are desired, and place the offered 555 identifier value "as is" in the SDP answer. 557 Similarly, if more segment extensions are offered than can be fit in 558 the valid range, identifiers in the range 4096-4351 MAY be offered; 559 the answerer SHOULD choose those that are desired, and remap them to 560 a free identifier in the valid range. 562 Note that the range 4096-4351 for these negotiation identifiers is 563 deliberately restricted to allow expansion of the range of valid 564 identifiers in future. Segment extensions with an identifier outside 565 the valid range cannot, of course, be used. 567 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 568 all omitted for brevity): 570 The offer: 572 a=rtcp-xr:mos- 573 metrics=calg:4906=P1201_l,calg:4906=P1202_l,calg:4907=G107 575 The answerer is interested in transmission P.1202.1 on lower 576 resolution application, but doesn't support P.1201.1 on lower 577 resolution application at all. It is interested in transmission 578 G.107. It therefore adjusts the declarations: 580 a=rtcp-xr:mos-metrics=calg:1=P1202_l,calg:2=G107 582 5. IANA Considerations 584 New block types for RTCP XR are subject to IANA registration. For 585 general guidelines on IANA considerations for RTCP XR, refer to 586 [RFC3611]. 588 5.1. New RTCP XR Block Type value 590 This document assigns the block type value MMB in the IANA " RTP 591 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 592 the "MoS Metrics Block". 594 [Note to RFC Editor: please replace MMB with the IANA provided RTCP 595 XR block type for this block.] 597 5.2. New RTCP XR SDP Parameter 599 This document also registers a new parameter "mos-metrics" in the " 600 RTP Control Protocol Extended Reports (RTCP XR) Session Description 601 Protocol (SDP) Parameters Registry". 603 5.3. The SDP calgextmap Attribute 605 This section contains the information required by [RFC4566] for an 606 SDP attribute. 607 o contact name, email address: 609 Qin Wu 610 sunseawq@huawei.com 612 o attribute name (as it will appear in SDP): calgextmap 613 o long-form attribute name in English: calculation algorithm map 614 definition 615 o type of attribute (session level, media level, or both): both 616 o whether the attribute value is subject to the charset attribute: 617 not subject to the charset attribute 618 o a one-paragraph explanation of the purpose of the attribute: This 619 attribute defines the mapping from the local identifier (CAID) in 620 the segment extension defined in section 3.2 into the calculation 621 algorithm name as documented in specifications and appropriately 622 registered. 623 o a specification of appropriate attribute values for this 624 attribute: see RFC xxxx. 626 5.4. New registry of calculation algorithms 628 This document creates a new registry to be called "RTCP XR MoS Metric 629 block - multimedia application Calculation Algorithm" as a sub- 630 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 631 Block Type Registry". This registry applies to the multimedia 632 session where each type of media are sent in a separate RTP stream 633 and also applies to the session where Multi-channel audios are 634 carried in one RTP stream. Policies for this new registry are as 635 follows: 637 o The information required to support this assignment is an 638 unambiguous definition of the new metric, covering the base 639 measurements and how they are processed to generate the reported 640 metric. 642 o The review process for the registry is "Specification Required" as 643 described in Section 4.1 of [RFC5226]. 645 o Entries in the registry are identified by entry name and mapped to 646 the local identifier (CAID) in the segment extension defined in 647 section 3.2. 649 o Registration Template 651 The following information must be provided with each registration: 652 * Name: A string uniquely and unambiguously identifying the 653 Calculation algorithm for use in protocols. 654 * Name Description: A valid Description of the Calculation 655 algorithm name. 656 * Reference: The reference which defines the calculation 657 algorithm corresponding to the Name and Name Description. 659 * Type: The media type to which the calculation algorithm is 660 applied 662 o Initial assignments are as follows: 664 Name Name Description Reference Type 665 ========= =================================== ========== ==== 666 P564 ITU-T P.564 Compliant Algorithm [P.564] Voice 667 G107 ITU-T G.107 [G.107] Voice 668 TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice 669 JJ201_1 TTC JJ201.1 [TTC] Voice 670 G107_1 ITU-T G.107.1 [G.107.1] Voice 671 P862 ITU-T P.862 [P.862] Voice 672 P862_2 ITU-T P.862.2 [P.862.2] Voice 673 P863 ITU-T P.863 [P.863] Voice 674 P1201_1 ITU-T P.1201.1 [P.1201.1] Multimedia 675 P1201_2 ITU-T P.1201.2 [P.1201.2] Multimedia 676 P1202_1 ITU-T P.1202.1 [P.1202.1] Video 677 P1202_2 ITU-T P.1202.2 [P.1202.2] Video 679 6. Security Considerations 681 The new RTCP XR report blocks proposed in this document introduces no 682 new security considerations beyond those described in [RFC3611]. 684 7. Authors 686 This draft merges ideas from two drafts addressing the MoS Metric 687 Reporting issue. The authors of these drafts are listed below (in 688 alphabetical order): 690 Alan Clark < alan.d.clark@telchemy.com > 691 Geoff Hunt < r.geoff.hunt@gmail.com > 692 Martin Kastner < martin.kastner@telchemy.com > 693 Kai Lee < leekai@ctbri.com.cn > 694 Roland Schott < roland.schott@telekom.de > 695 Qin Wu < sunseawq@huawei.com > 696 Glen Zorn < gwz@net-zen.net > 698 8. Acknowledgements 700 The authors gratefully acknowledge the comments and contributions 701 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 702 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 703 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 704 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 705 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Bill Ver Steeg, David R 706 Oran, Ali Begen and Hideaki Yamada. 708 9. References 710 9.1. Normative References 712 [ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC 713 Standard: Digital Audio Compression (AC-3), Revision B", 714 ATSC Doc A/52B, June 2005. 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 720 Applications", RFC 3550, July 2003. 722 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 723 Video Conferences with Minimal Control", RFC 3551, 724 July 2003. 726 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 727 Protocol Extended Reports (RTCP XR)", RFC 3611, 728 November 2003. 730 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 731 Description Protocol", RFC 4566, July 2006. 733 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 734 Section in RFCs", RFC 5226, May 2008. 736 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 737 Specifications: ABNF", STD 68, RFC 5234, January 2008. 739 [RFC6776] Wu, Q., "Measurement Identity and information Reporting 740 using SDES item and XR Block", RFC 6776, October 2012. 742 9.2. Informative References 744 [ETSI] ETSI, "Quality of Service (QoS) measurement 745 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 747 [G.107] ITU-T, "The E Model, a computational model for use in 748 transmission planning", ITU-T Recommendation G.107, 749 April 2009. 751 [G.107.1] ITU-T, "Wideband E-model", ITU-T Recommendation G.107.1, 752 December 2011. 754 [G.1082] ITU-T, "Measurement-based methods for improving the 755 robustness of IPTV performance", ITU-T 756 Recommendation G.1082, April 2009. 758 [P.1201.1] 759 ITU-T, "Parametric non-intrusive assessment of audiovisual 760 media streaming quality - lower resolution application 761 area", ITU-T Recommendation P.1201.1, October 2012. 763 [P.1201.2] 764 ITU-T, "Parametric non-intrusive assessment of audiovisual 765 media streaming quality - higher resolution application 766 area", ITU-T Recommendation P.1201.2, October 2012. 768 [P.1202.1] 769 ITU-T, "Parametric non-intrusive bitstream assessment of 770 video media streaming quality - lower resolution 771 application area", ITU-T Recommendation P.1202.1, 772 October 2012. 774 [P.1202.2] 775 ITU-T, "Parametric non-intrusive bitstream assessment of 776 video media streaming quality - higher resolution 777 application area", ITU-T Recommendation P.1202.2, 778 May 2013. 780 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 781 transmission quality assessment models", ITU-T 782 Recommendation P.564, July 2006. 784 [P.862] ITU-T, "Perceptual evaluation of speech quality (PESQ): An 785 objective method for end-to-end speech quality assessment 786 of narrow-band telephone networks and speech codecs", 787 ITU-T Recommendation P.862, Febuary 2001. 789 [P.862.1] ITU-T, "Mapping function for transforming P.862 raw result 790 scores to MOS-LQO", ITU-T Recommendation P.862.1, 791 November 2003. 793 [P.862.2] ITU-T, "Wideband extension to Recommendation P.862 for the 794 assessment of wideband telephone networks and speech 795 codecs", ITU-T Recommendation P.862.2, November 2007. 797 [P.863] ITU-T, "Perceptual objective listening quality 798 assessment", ITU-T Recommendation P.863, January 2011. 800 [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for 801 AC-3 Audio", RFC 4184, October 2005. 803 [RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload 804 Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, 805 July 2006. 807 [RFC5188] Desineni, H. and Q. Xie, "RTP Payload Format for the 808 Enhanced Variable Rate Wideband Codec (EVRC-WB) and the 809 Media Subtype Updates for EVRC-B Codec", RFC 5188, 810 February 2008. 812 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 813 Development", RFC 6390, October 2011. 815 [RFC6792] Wu, Q., "Monitoring Architectures for RTP", RFC 6792, 816 November 2012. 818 [TTC] TTC 201.01 (Japan), "A method for speech quality 819 assessment for Voice over IP". 821 Appendix A. Example of User Quality of Experience Evaluation for video 822 stream 824 To evaluate user quality of experience levels using objective test 825 data, MoS Scores provide a familiar, easily understood numeric 826 representation of video, audio, and overall audiovisual quality. 827 Unlike audio, video is even more sensitive to transport impairments , 828 and even low rates of packet loss can cause severe degradation in 829 perceived quality. However, all occurrences of packet loss do not 830 have an equal impact on perceptual quality, in part because of the 831 way video frames are structured during the encoding process - such as 832 frame properties including frame type, frame structure and 833 quantization parameter (QP), and in part due to subjective factors - 834 such as the degree to which perception is affected by the levels of 835 motion, detail in the video sequence, and decoder characteristic 836 parameters including media resolution,codec type. When a video 837 stream is sent from the media source to RTP receiving end and get 838 monitored. in order to provide accurate evaluation of video quality, 839 one possible QoE evaluation method is having network nodes that 840 implement network management tools in place. They may know frame 841 properties,perception degree, decoder characteristic parameters of 842 this video stream using some out of band means, gather transport 843 impairment information received from the RTP receiving end and use 844 them as MoS calculation input parameters to calculate MoS scores by 845 choosing appropriate MoS calculation algorithm. Such MoS Scores 846 value can be useful for troubleshooting or comparing video quality 847 across different service types. 849 Appendix B. Metrics represented using RFC6390 Template 851 RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC 852 number, when assigned. 854 a. MoS Value Metric 856 * Metric Name: MoS 858 * Metric Description: The estimated mean opinion score for 859 multimedia application performance is defined as including the 860 effects of delay,loss, discard,jitter and other effects that 861 would affect multimedia quality. 863 * Method of Measurement or Calculation: See section 3.2.1, MoS 864 value definition [RFCXXXX]. 866 * Units of Measurement: See section 3.2.1, MoS value definition 867 [RFCXXXX]. 869 * Measurement Point(s) with Potential Measurement Domain: See 870 section 3, 2nd paragraph [RFCXXXX]. 872 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 873 measurement timing and section 3.1 [RFCXXXX] for Interval 874 Metric flag. 876 * Use and applications: See section 1.4 [RFCXXXX]. 878 * Reporting model: See RFC3611. 880 b. Segment Type Metric 882 * Metric Name: Segment Type 884 * Metric Description: It is used to identify the segment type 885 used in this report block. For more details, see section 886 3.2.1, Segment type definition. 888 * Method of Measurement or Calculation: See section 3.2.1, 889 Segment Type definition [RFCXXXX]. 891 * Units of Measurement: See section 3.2.1, Segment Type 892 definition [RFCXXXX]. 894 * Measurement Point(s) with Potential Measurement Domain: See 895 section 3, 2nd paragraph [RFCXXXX]. 897 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 898 measurement timing and section 3.1 [RFCXXXX] for Interval 899 Metric flag. 901 * Use and applications: See section 1.4 [RFCXXXX]. 903 * Reporting model: See RFC3611. 905 c. Calg Algorithm Identifier Metric 907 * Metric Name: Calg Algorithm Identifier 909 * Metric Description: It is the local identifier of calculation 910 Algorithm associated with this segment in the range 1-255 911 inclusive. 913 * Method of Measurement or Calculation: See section 3.2.1, Calg 914 Algorithm ID definition [RFCXXXX]. 916 * Units of Measurement: See section 3.2.1, Calg Algorithm ID 917 definition[RFCXXXX]. 919 * Measurement Point(s) with Potential Measurement Domain: See 920 section 3, 2nd paragraph [RFCXXXX]. 922 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 923 measurement timing and section 3.1 [RFCXXXX] for Interval 924 Metric flag. 926 * Use and applications: See section 1.4 [RFCXXXX]. 928 * Reporting model: See RFC3611. 930 d. Payload Type Metric 932 * Metric Name: Payload Type 934 * Metric Description: It is used to identify the format of the 935 RTP payload. For more details, see section 3.2.1, payload 936 type definition. 938 * Method of Measurement or Calculation: See section 3.2.1, 939 Payload type definition [RFCXXXX]. 941 * Units of Measurement: See section 3.2.1, payload type 942 definition[RFCXXXX]. 944 * Measurement Point(s) with Potential Measurement Domain: See 945 section 3, 2nd paragraph [RFCXXXX]. 947 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 948 measurement timing and section 3.1 [RFCXXXX] for Interval 949 Metric flag. 951 * Use and applications: See section 1.4 [RFCXXXX]. 953 * Reporting model: See RFC3611. 955 e. Channel Identifier Metric 957 * Metric Name: Payload Type 959 * Metric Description: It is used to identify each channel 960 carried in the same media stream. For more details, see 961 section 3.2.2, channel identifier definition. 963 * Method of Measurement or Calculation: See section 3.2.2, 964 Channel Identifier definition [RFCXXXX]. 966 * Units of Measurement: See section 3.2.2, channel identifier 967 definition[RFCXXXX]. 969 * Measurement Point(s) with Potential Measurement Domain: See 970 section 3, 2nd paragraph [RFCXXXX]. 972 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 973 measurement timing and section 3.1 [RFCXXXX] for Interval 974 Metric flag. 976 * Use and applications: See section 1.4 [RFCXXXX]. 978 * Reporting model: See RFC3611. 980 Appendix C. Change Log 982 C.1. draft-ietf-xrblock-rtcp-xr-qoe-10 984 The following are the major changes compared to previous version: 986 o Replace QoE metrics with MoS metrics. 988 C.2. draft-ietf-xrblock-rtcp-xr-qoe-09 990 The following are the major changes compared to previous version: 991 o Address comments recieved from WGLC, PM-DIR Review and SDP review. 992 o Change an existing SDP attribute 'extmap' to new SDP attribute 993 'calgextmap' and add new SDP attribute registry. 994 o Add Reference to G.107.1, P.862.1, P.862.2 and P.863 for new 995 calculation algorithms. 996 o Add MoS type attribute to distinguish different MoS type. 997 o Other Editorial changes. 999 C.3. draft-ietf-xrblock-rtcp-xr-qoe-08 1001 The following are the major changes compared to previous version: 1002 o Remove mostype attribute from SDP extension since it can inferred 1003 from payload type. 1004 o Clarify mosref attribute usage in the O/A. 1006 C.4. draft-ietf-xrblock-rtcp-xr-qoe-07 1008 The following are the major changes compared to previous version: 1009 o Some editorial changes to get in line with burst gap related 1010 draft. 1011 o Add an appendix to apply RFC6390 template. 1013 C.5. draft-ietf-xrblock-rtcp-xr-qoe-06 1015 The following are the major changes compared to previous two 1016 versions: 1017 o A few Contact information update. 1018 o A few Acknowledgement section update. 1020 C.6. draft-ietf-xrblock-rtcp-xr-qoe-04 1022 The following are the major changes compared to previous version: 1023 o Split two references P.NAMS and P.NBAMS into four references. 1024 o SDP signaling update. 1025 o Add one example to explain User QoE evaluation for video stream 1027 C.7. draft-ietf-xrblock-rtcp-xr-qoe-03 1029 The following are the major changes compared to previous version: 1030 o Add one new reference to support TTC JJ201.01. 1031 o Update two references P.NAMS and P.NBAMS. 1033 o Other Editorial changes based on comments applied to PDV and Delay 1034 drafts. 1036 C.8. draft-ietf-xrblock-rtcp-xr-qoe-02 1038 The following are the major changes compared to previous version: 1039 o Remove leftmost second bit since it is ueeless. 1040 o Change 13bits MoS value field into 14 bits to increase MoS 1041 precision. 1042 o Fix some typo and make some editorial changes. 1044 C.9. draft-ietf-xrblock-rtcp-xr-qoe-01 1046 The following are the major changes compared to previous version: 1047 o Remove layered support from the QoE Metric draft. 1048 o Allocate 7 bits in the block header for payload type to indicate 1049 what type of payload format is in use and add associated 1050 definition of payload type. 1051 o Clarify using Payload Type to determine the appropriate channel 1052 mapping in the definition of Channel Identifier. 1054 C.10. draft-ietf-xrblock-rtcp-xr-qoe-00 1056 The following are the major changes compared to previous version: 1057 o Allocate one more bit in the single channel per SSC segment to get 1058 alignment with the other two segment type. 1060 Authors' Addresses 1062 Alan Clark 1063 Telchemy Incorporated 1064 2905 Premiere Parkway, Suite 280 1065 Duluth, GA 30097 1066 USA 1068 Email: alan.d.clark@telchemy.com 1070 Qin Wu 1071 Huawei 1072 101 Software Avenue, Yuhua District 1073 Nanjing, Jiangsu 210012 1074 China 1076 Email: sunseawq@huawei.com 1077 Roland Schott 1078 Deutsche Telekom 1079 Heinrich-Hertz-Strasse 3-7 1080 Darmstadt 64295 1081 Germany 1083 Email: Roland.Schott@telekom.de 1085 Glen Zorn 1086 Network Zen 1087 77/440 Soi Phoomjit, Rama IV Road 1088 Phra Khanong, Khlong Toie 1089 Bangkok 10110 1090 Thailand 1092 Phone: +66 (0) 87 502 4274 1093 Email: gwz@net-zen.net