idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-qoe-13.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 (January 9, 2014) is 3758 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 955, but not defined == Unused Reference: 'RFC5234' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'G.1082' is defined on line 761, 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 (~~), 4 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: July 11, 2014 Huawei 6 R. Schott 7 Deutsche Telekom 8 G. Zorn 9 Network Zen 10 January 9, 2014 12 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric 13 Reporting 14 draft-ietf-xrblock-rtcp-xr-qoe-13 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/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 11, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. MOS Metrics Report Block . . . . . . . . . . . . . . . . . 4 58 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 4 59 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 60 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 5 63 3. MOS Metrics Block . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 6 65 3.2. Definition of Fields in MOS Metrics Block . . . . . . . . 7 66 3.2.1. Single Channel audio/video per SSRC Segment . . . . . 8 67 3.2.2. Multi-Channel audio per SSRC Segment . . . . . . . . . 9 68 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 10 70 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 12 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 14 73 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 14 74 5.3. The SDP calgextmap Attribute . . . . . . . . . . . . . . . 14 75 5.4. New registry of calculation algorithms . . . . . . . . . . 15 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Appendix A. Metrics represented using RFC6390 Template . . . . . 20 83 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 84 B.1. draft-ietf-xrblock-rtcp-xr-qoe-10 . . . . . . . . . . . . 22 85 B.2. draft-ietf-xrblock-rtcp-xr-qoe-09 . . . . . . . . . . . . 23 86 B.3. draft-ietf-xrblock-rtcp-xr-qoe-08 . . . . . . . . . . . . 23 87 B.4. draft-ietf-xrblock-rtcp-xr-qoe-07 . . . . . . . . . . . . 23 88 B.5. draft-ietf-xrblock-rtcp-xr-qoe-06 . . . . . . . . . . . . 23 89 B.6. draft-ietf-xrblock-rtcp-xr-qoe-04 . . . . . . . . . . . . 23 90 B.7. draft-ietf-xrblock-rtcp-xr-qoe-03 . . . . . . . . . . . . 23 91 B.8. draft-ietf-xrblock-rtcp-xr-qoe-02 . . . . . . . . . . . . 24 92 B.9. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 24 93 C.9. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 24 94 B.10. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction 99 1.1. MOS 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 (i.e. Mean Opinion Score(MOS)). 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 document defines a new Extended Report block for 115 use 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 guidelines for reporting 122 block format using RTCP XR. The XR block type described in this 123 document are in accordance with the guidelines in [RFC6390] and 124 [RFC6792]. 126 1.4. Applicability 128 The MOS Metrics Report Block can be used in any application of RTP 129 for which QoE (Quality of Experience) measurement algorithms are 130 defined. 132 The factors that affect real-time audio/video application quality can 133 be split into two categories. The first category consists of 134 transport-specific factors such as packet loss, delay and jitter 135 (which also translates into losses in the playback buffer). The 136 factors in the second category consists of content and codec related 137 factors such as codec type and loss recovery technique, coding bit 138 rate, packetization scheme, and content characteristics 140 Transport-specific factors may be insufficient to infer real time 141 media quality as codec related parameters and the interaction 142 between transport problems and application layer protocols can 143 have a substantial effect on observed media quality. Media quality 144 may be measured using algorithm that directly compare input and 145 output media streams, or may be estimated using algorithms that 146 model the interaction between media quality, protocol and encoded 147 content. Media quality is commonly expressed in terms of Mean 148 Opinion Scores (MOS) however is also represented by a range of 149 indexes and other scores. 151 The measurement of media quality has a number of applications: 153 o Detecting problems with media delivery or encoding that is 154 impacting user perceived quality. 155 o Tuning the content encoder algorithm to satisfy real time data 156 quality requirements. 157 o Determining which system techniques to use in a given situation 158 and when to switch from one technique to another as system 159 parameters change (for example as discussed in [P.1082]). 160 o Pre-qualifying a network to assess its ability to deliver an 161 acceptable end-user perceived quality level. 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. MOS Metrics Block 191 Multimedia application MOS Metric is commonly expressed as a MOS 192 ("Mean Opinion Score"), MOS is usually on a scale from 1 to 5, in 193 which 5 represents excellent and 1 represents unacceptable however 194 can use other ranges (for example 1 to 11). The term "MOS score" 195 originates from subjective testing, and is used to refer to the 196 Mean of a number of individual Opinion Scores. There is therefore 197 a well understood relationship between MOS and user experience, 198 hence the industry commonly uses MOS as the scale for objective 199 test results. Subjective tests can be used for measuring live 200 network traffic however the use of objective or algorithmic 201 measurement techniques allows much large scale measurements to 202 be made. Within the scope of this document, MOS scores are 203 obtained using objective or estimation algorithms. 204 ITU-T or ITU-R recommendations (e.g., [BS.1387-1], [G.107], 205 [G.107.1], [P.862], [P.862.1], [P.862.2], [P.863], [P.564], 206 [P.1201.1], [P.1201.2], [P.1202.1], [P.1202.2]) define 207 methodologies for assessment of the performance of audio and 208 video streams. Other international and national standards 209 organizations such as EBU, ETSI, IEC and IEEE also define 210 QoE algorithms and methodologies, and the intent of this document 211 is not to restrict its use to ITU recommendations but to suggest 212 that ITU recommendations be used where they are defined. 214 This block reports media quality in the form of a 1-5 MOS range 215 however does not report QoE scores that include parameters 216 outside the scope of the RTP stream, for example signaling 217 performance, MTTR or other factors that may affect the overall 218 user experience. 220 The MOS Metric reported in this block gives a numerical indication 221 of the perceived quality of the received media stream, which is 222 typically measured at the receiving end of the RTP stream. 223 Instances of this Metrics Block refer by Synchronization source 224 (SSRC) to the separate auxiliary Measurement Information block 225 [RFC6776] which describes measurement periods in use (see RFC6776 226 section 4.2). 228 This Metrics Block relies on the measurement period in the 229 Measurement Information block indicating the span of the report. 230 Senders MUST send this block in the same compound RTCP packet as the 231 measurement information block. Receivers MUST verify that the 232 measurement period is received in the same compound RTCP packet as 233 this Metrics Block. If not, this Metrics Block MUST be discarded. 235 3.1. Metric Block Structure 237 The MOS Metrics Block has the following format: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | BT=MMB | I | Reserved | Block Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | SSRC of source | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Segment 1 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Segment 2 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 .................. 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Segment n | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 3.2. Definition of Fields in MOS Metrics Block 257 Block type (BT): 8 bits 259 The MOS Metrics Block is identified by the constant . 261 Interval Metric flag (I): 2 bits 263 This field is used to indicate whether the MOS Metrics are 264 Sampled, Interval or Cumulative [RFC6792]: 266 I=10: Interval Duration - the reported value applies to the 267 most recent measurement interval duration between successive 268 metrics reports. 269 I=11: Cumulative Duration - the reported value applies to the 270 accumulation period characteristic of cumulative measurements. 271 I=01: Sampled Value - the reported value is a sampled 272 instantaneous value. 273 I=00: Reserved 275 In this document, MOS Metrics MAY be reported for intervals or 276 for the duration of the media stream (cumulative) however it 277 is not recommended that sampled values are used. 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 MOS 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 channel Audio/Video per SSRC segment is used 301 to deal with the case where each media stream is identified by 302 SSRC and sent in separate RTP stream. The leftmost bit of the 303 segment determines its type. If the leftmost bit of the segment 304 is zero, then it is single channel segment. If the leftmost bit 305 is one, then it is multi-channel audio segment. Note that two 306 segment types can not be present in the same metric block. 308 3.2.1. Single Channel 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 channel Audio/ 318 Video per SSRC segment. Single channel means there is only one 319 media stream carried in one RTP stream. The single channel 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 channel 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 MOS Metrics Blocks are 326 required to report the MOS value corresponding to each media 327 stream using single channel Audio/Video per SSRC segment in the 328 same RTCP XR packet. 330 Calculation Algorithm ID (CAID) : 8 bits 332 The 8-bit CAID is the session specific reference to the 333 calculation algorithm and associated qualifiers indicated in SDP 334 (see Section 4.1) and used to compute QoE scores for this segment 336 Payload Type (PT): 7 bits 338 MOS Metrics reporting depends on the payload format in use. This 339 field identifies the RTP payload type in use during the reporting 340 interval. The binding between RTP payload types and RTP payload 341 formats is configured via a signalling protocol, for example an 342 SDP offer/answer exchange. If the RTP payload type used is 343 changed during an RTP session, separate reports SHOULD be sent for 344 each RTP payload type, with corresponding measurement information 345 blocks indicating the time period to which they relate. 347 Note that the use of this Report Block with MPEG Transport streams 348 carried over RTP is undefined as each MPEG Transport stream may 349 use distinct audio or video codecs and the indication of the 350 encoding of these is within the MPEG Transport stream and does not 351 use RTP payloads. 353 MOS Value: 16 bits 355 The estimated Mean Opinion Score for multimedia application 356 performance is defined as including the effects of delay,loss, 357 discard, jitter and other effects that would affect media quality. 358 A 1-5 MOS score is multiplied by 10 and then represented in the 359 8:8 format. If the measured value is over range, the value 360 0xFFFE MUST be reported. If the measurement is unavailable, the 361 value 0xFFFF MUST be reported. Values other than 0xFFFE, 0xFFFF 362 and the valid range defined above MUST NOT be sent and MUST be 363 ignored by the receiving system. 365 3.2.2. Multi-Channel audio per SSRC Segment 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |S| CAID | PT |CHID | MOS Value | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Segment Type (S): 1 bit 373 This field is used to identify the segment type used in this 374 report block. A one identifies this as a multi-channel audio 375 segment. 377 Calculation Algorithm ID (CAID) : 8 bits 379 The 8-bit CAID is the session specific reference to the 380 calculation algorithm and associated qualifiers indicated in SDP 381 (see Section 4.1) and used to compute QoE scores for this segment 383 Payload Type (PT): 7 bits 385 As defined in Section 3.2.1 of this document. 387 Channel Identifier (CHID): 3 bits 389 If multiple channels of audio are carried in one RTP stream, each 390 channel of audio will be viewed as a independent channel(e.g., 391 left channel audio, right channel audio). This field is used to 392 identify each channel carried in the same media stream. The 393 default Channel mapping follows static ordering rule described in 394 the section 4.1 of [RFC3551]. However there are some payload 395 formats that use different channel mappings, e.g., AC-3 audio over 396 RTP [RFC4184] only follow AC-3 channel order scheme defined in 397 [ATSC]. Enhanced AC-3 Audio over RTP [RFC4598] uses dynamic 398 channel transform mechanism. In order that the appropriate 399 channel mapping can be determined, MOS metrics reports need to be 400 tied to an RTP payload format, i.e., including the payload type of 401 the reported media according to [RFC6792] and using Payload Type 402 to determine the appropriate channel mapping. 404 MOS Value: 13 bits 406 The estimated Mean Opinion Score for multimedia application 407 performance includes the effects of delay,loss, discard, jitter 408 and other effects that would affect multimedia quality. 409 The estimated MOS value is multiplied by 10 and expressed in 410 6:7 format. If the measured value is over range, the value 411 0x1FFE MUST be reported to indicate an over-range measurement. 412 If the measurement is unavailable, the value 0x1FFF MUST be 413 reported. Values other than 0x1FFE, 0x1FFF and the valid range 414 defined above MUST NOT be sent and MUST be ignored by the 415 receiving system. 417 4. SDP Signaling 419 [RFC3611] defines the use of SDP (Session Description Protocol) 420 [RFC4566] for signaling the use of XR blocks. However XR blocks MAY 421 be used without prior signaling (see section 5 of RFC3611). 423 4.1. SDP rtcp-xr-attrib Attribute Extension 425 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 426 in [RFC3611] by providing an additional value of "xr-format" to 427 signal the use of the report block defined in this document. Within 428 the "xr-format", the syntax element "calgextmap" is an attribute as 429 defined in [RFC4566] and used to signal the mapping of the local 430 identifier (CAID) in the segment extension defined in section 3.2 to 431 the calculation algorithm. Specific extensionattributes are defined 432 by the specification that defines a specific extension name; there 433 might be several. 435 xr-format =/ xr-mos-block 436 xr-mos-block = "mos-metrics" ["=" extmap *("," calgextmap)] 437 calgextmap = mapentry "=" extensionname [SP extentionattributes] 438 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 439 mapentry = "calg:" 1*3 DIGIT ["/" direction] 440 ; Values in the range 1-255 are valid 441 ; if needed, 0 can be used to indicate that 442 ; an algorithm is rejected 443 extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564] 444 / "G107";ITU-T G.107 [G.107] 445 / "G107_1";ITU-T G.107.1 [G.107.1] 446 / "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI] 447 /"JJ201_1 ";TTC JJ201.1 [TTC] 448 /"P1201_1";ITU-T P.1201.2 [P.1201.1] 449 /"P1201_2";ITU-T P.1201.2 [P.1201.2] 450 /"P1202_1";ITU-T P.1202.1 [P.1202.1] 451 /"P1202_2";ITU-T P.1202.2 [P.1202.2] 452 /"P.862.2";ITU-T P.862.2 [P.862.2] 453 /"P.863"; ITU-T P.863 [P.863] 454 / non-ws-string 455 extensionattributes = mosref 456 /attributes-ext 457 mosref = "mosref=" ("l"; lower resolution 458 /"m"; middle resolution 459 / "h";higher resolution 460 / non-ws-string) 461 attributes-ext = non-ws-string 462 SP = 463 non-ws-string = 1*(%x21-FF) 465 Each local identifier (CAID)of calculation algorithm used in the 466 segment defined in the section 3.2 is mapped to a string using an 467 attribute of the form: 469 a=calgextmap: ["/"] [] 471 where is a calculation algorithm name, as above, is 472 the local identifier (CAID)of the calculation algorithm associated 473 with the segment defined in this document and is an integer in the 474 valid range inclusive. 476 Example: 477 a=rtcp-xr:mos-metrics=calg:1=G107,calg:2=P1202_1 479 A usable mapping MUST use IDs in the valid range, and each ID in this 480 range MUST be unique and used only once for each stream or each 481 channel in the stream. 483 The mapping MUST be provided per media stream (in the media-level 484 section(s) of SDP, i.e., after an "m=" line). 486 The syntax element "mosref" is referred to the media resolution 487 relative reference and has three valules 'l','m','h'.(e.g., 488 Narrowband (3.4kHz) Speech and StandardDefinition (SD) or lower 489 Resolution Video have 'l' resolution, Super Wideband (>14kHz) Speech 490 or higher and High Definition (HD) or higher Resolution Video have 491 'h' Resolution, Wideband speech(7khz) and Video with resolution 492 between SD and HD has 'm' resolution). MOS scores reported in the 493 mos metrics block might vary with the MOS reference; For example, MOS 494 values for narrowband, wideband, super wideband codecs occupy the 495 same range but SHOULD be reported in different value. For video 496 application, MOS scores for SD resolution, HD resolution video also 497 occupy the same ranges and SHOULD be reported in different value. 499 4.2. Offer/Answer Usage 501 When SDP is used in offer-answer context, the SDP Offer/Answer 502 usage defined in [RFC3611] applies. In the offer answer 503 context, the signaling described above might be used in 504 three ways: 506 o asymmetric behavior (segment extensions sent in only one 507 direction), 508 o the offer of mutually exclusive alternatives, or 509 o the offer of more segments than can be sent in a single session. 511 A direction attribute MAY be included in a calgextmap; without it, 512 the direction implicitly inherits, of course, from the RTCP stream 513 direction. 515 Segment extensions, with their directions, MAY be signaled for an 516 "inactive" stream. It is an error to use an extension direction 517 incompatible with the stream direction (e.g., a "sendonly" attribute 518 for a "recvonly" stream). 520 If an segment extension is offered as "sendrecv", explicitly or 521 implicitly, and asymmetric behavior is desired, the SDP MAY be 522 modified to modify or add direction qualifiers for that segment 523 extension. 525 A mosref attribute and mos type attribute MAY be included in an 526 calgextmap; without it, the mosref and most type attribute implicitly 527 inherits, of course, from the name attribute (e.g., P.1201.1 528 [P.1201.1] indicates lower resolution used while P.1201.2 [P.1201.2] 529 indicates higher resolution used) or payload type carried in the 530 segment extension (e.g.,EVRC-WB [RFC5188] indicates using Wideband 531 Codec). However not all payload types or MOS algorithm names 532 indicate resolution to be used and mos type to be used. 534 If an answerer receives an offer with an mosref attribute value it 535 doesn't support (e.g.,the answerer only supports "l" and receives 536 "h"from offerer), the answer SHOULD reject the mosref attribute value 537 offered by the offerer. 539 If the answerer wishes to reject a mosref attribute offered by the 540 offerer, it sets identifiers associated with segment extensions in 541 the answer to the value in the range 4096-4351. The rejected answer 542 MUST contain 'mosref ' attribute whose value is the value of the SDP 543 offer. 545 Local identifiers in the valid range inclusive in an offer or answer 546 must not be used more than once per media section. A session update 547 MAY change the direction qualifiers of segment extensions under use. 548 A session update MAY add or remove segment extension(s). Identifiers 549 values in the valid range MUST NOT be altered (remapped). 551 If a party wishes to offer mutually exclusive alternatives, then 552 multiple segment extensions with the same identifier in the 553 (unusable) range 4096-4351 MAY be offered; the answerer SHOULD select 554 at most one of the offered extensions with the same identifier, and 555 remap it to a free identifier in the valid range, for that extension 556 to be usable. Note that two segment types defined in section 3 are 557 also two exclusive alternatives. 559 If more segment extensions are offered in the valid range, the 560 answerer SHOULD choose those that are desired, and place the offered 561 identifier value "as is" in the SDP answer. 563 Similarly, if more segment extensions are offered than can be fit in 564 the valid range, identifiers in the range 4096-4351 MAY be offered; 565 the answerer SHOULD choose those that are desired, and remap them to 566 a free identifier in the valid range. 568 Note that the range 4096-4351 for these negotiation identifiers is 569 deliberately restricted to allow expansion of the range of valid 570 identifiers in future. Segment extensions with an identifier outside 571 the valid range cannot, of course, be used. 573 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 574 all omitted for brevity): 576 The offer: 578 a=rtcp-xr:mos-metrics=calg:4906=P1201_l,calg:4906=P1202_l, 579 calg:4907=G107 581 The answerer is interested in transmission P.1202.1 on lower 582 resolution application, but doesn't support P.1201.1 on lower 583 resolution application at all. It is interested in transmission 584 G.107. It therefore adjusts the declarations: 586 a=rtcp-xr:mos-metrics=calg:1=P1202_l,calg:2=G107 588 5. IANA Considerations 590 New block types for RTCP XR are subject to IANA registration. For 591 general guidelines on IANA considerations for RTCP XR, refer to 592 [RFC3611]. 594 5.1. New RTCP XR Block Type value 596 This document assigns the block type value MMB in the IANA " RTP 597 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 598 the "MOS Metrics Block". 600 [Note to RFC Editor: please replace MMB with the IANA provided RTCP 601 XR block type for this block.] 603 5.2. New RTCP XR SDP Parameter 605 This document also registers a new parameter "mos-metrics" in the " 606 RTP Control Protocol Extended Reports (RTCP XR) Session Description 607 Protocol (SDP) Parameters Registry". 609 5.3. The SDP calgextmap Attribute 611 This section contains the information required by [RFC4566] for an 612 SDP attribute. 613 o contact name, email address: 615 Qin Wu 616 sunseawq@huawei.com 618 o attribute name (as it will appear in SDP): calgextmap 619 o long-form attribute name in English: calculation algorithm map 620 definition 621 o type of attribute (session level, media level, or both): both 622 o whether the attribute value is subject to the charset attribute: 623 not subject to the charset attribute 624 o a one-paragraph explanation of the purpose of the attribute: This 625 attribute defines the mapping from the local identifier (CAID) in 626 the segment extension defined in section 3.2 into the calculation 627 algorithm name as documented in specifications and appropriately 628 registered. 629 o a specification of appropriate attribute values for this 630 attribute: see RFC xxxx. 632 5.4. New registry of calculation algorithms 633 This document creates a new registry to be called "RTCP XR MOS Metric 634 block - multimedia application Calculation Algorithm" as a sub- 635 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 636 Block Type Registry". This registry applies to the multimedia 637 session where each type of media are sent in a separate RTP stream 638 and also applies to the session where Multi-channel audios are 639 carried in one RTP stream. Policies for this new registry are as 640 follows: 642 o The information required to support this assignment is an 643 unambiguous definition of the new metric, covering the base 644 measurements and how they are processed to generate the reported 645 metric. 647 o The review process for the registry is "Specification Required" as 648 described in Section 4.1 of [RFC5226]. 650 o Entries in the registry are identified by entry name and mapped to 651 the local identifier (CAID) in the segment extension defined in 652 section 3.2. 654 o Registration Template 656 The following information must be provided with each registration: 657 * Name: A string uniquely and unambiguously identifying the 658 Calculation algorithm for use in protocols. 659 * Name Description: A valid Description of the Calculation 660 algorithm name. 661 * Reference: The reference which defines the calculation 662 algorithm corresponding to the Name and Name Description. 664 * Type: The media type to which the calculation algorithm is 665 applied 667 o Initial assignments are as follows: 669 Name Name Description Reference Type 670 ========= =================================== ========== ==== 671 P564 ITU-T P.564 Compliant Algorithm [P.564] Voice 672 G107 ITU-T G.107 [G.107] Voice 673 TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice 674 JJ201_1 TTC JJ201.1 [TTC] Voice 675 G107_1 ITU-T G.107.1 [G.107.1] Voice 676 P862 ITU-T P.862 [P.862] Voice 677 P862_2 ITU-T P.862.2 [P.862.2] Voice 678 P863 ITU-T P.863 [P.863] Voice 679 P1201_1 ITU-T P.1201.1 [P.1201.1] Multimedia 680 P1201_2 ITU-T P.1201.2 [P.1201.2] Multimedia 681 P1202_1 ITU-T P.1202.1 [P.1202.1] Video 682 P1202_2 ITU-T P.1202.2 [P.1202.2] Video 683 6. Security Considerations 685 The new RTCP XR report blocks proposed in this document introduces no 686 new security considerations beyond those described in [RFC3611]. 688 7. Authors 690 This draft merges ideas from two drafts addressing the MOS Metric 691 Reporting issue. The authors of these drafts are listed below (in 692 alphabetical order): 694 Alan Clark < alan.d.clark@telchemy.com > 695 Geoff Hunt < r.geoff.hunt@gmail.com > 696 Martin Kastner < martin.kastner@telchemy.com > 697 Kai Lee < leekai@ctbri.com.cn > 698 Roland Schott < roland.schott@telekom.de > 699 Qin Wu < sunseawq@huawei.com > 700 Glen Zorn < gwz@net-zen.net > 702 8. Acknowledgements 704 The authors gratefully acknowledge the comments and contributions 705 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 706 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 707 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 708 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 709 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Bill Ver Steeg, David R 710 Oran, Ali Begen and Hideaki Yamada. 712 9. References 714 9.1. Normative References 716 [ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC 717 Standard: Digital Audio Compression (AC-3), Revision B", 718 ATSC Doc A/52B, June 2005. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 724 Applications", RFC 3550, July 2003. 726 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 727 Video Conferences with Minimal Control", RFC 3551, 728 July 2003. 730 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 731 Protocol Extended Reports (RTCP XR)", RFC 3611, 732 November 2003. 734 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 735 Description Protocol", RFC 4566, July 2006. 737 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 738 Section in RFCs", RFC 5226, May 2008. 740 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 741 Specifications: ABNF", STD 68, RFC 5234, January 2008. 743 [RFC6776] Wu, Q., "Measurement Identity and information Reporting 744 using SDES item and XR Block", RFC 6776, October 2012. 746 9.2. Informative References 748 [BS.1387] ITU-R, "Method for objective measurements of perceived 749 audio quality], ITU-R Recommendation BS.1387-1, 2001 751 [ETSI] ETSI, "Quality of Service (QoS) measurement 752 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 754 [G.107] ITU-T, "The E Model, a computational model for use in 755 transmission planning", ITU-T Recommendation G.107, 756 April 2009. 758 [G.107.1] ITU-T, "Wideband E-model", ITU-T Recommendation G.107.1, 759 December 2011. 761 [G.1082] ITU-T, "Measurement-based methods for improving the 762 robustness of IPTV performance", ITU-T 763 Recommendation G.1082, April 2009. 765 [P.1201.1] 766 ITU-T, "Parametric non-intrusive assessment of audiovisual 767 media streaming quality - lower resolution application 768 area", ITU-T Recommendation P.1201.1, October 2012. 770 [P.1201.2] 771 ITU-T, "Parametric non-intrusive assessment of audiovisual 772 media streaming quality - higher resolution application 773 area", ITU-T Recommendation P.1201.2, October 2012. 775 [P.1202.1] 776 ITU-T, "Parametric non-intrusive bitstream assessment of 777 video media streaming quality - lower resolution 778 application area", ITU-T Recommendation P.1202.1, 779 October 2012. 781 [P.1202.2] 782 ITU-T, "Parametric non-intrusive bitstream assessment of 783 video media streaming quality - higher resolution 784 application area", ITU-T Recommendation P.1202.2, 785 May 2013. 787 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 788 transmission quality assessment models", ITU-T 789 Recommendation P.564, July 2006. 791 [P.862] ITU-T, "Perceptual evaluation of speech quality (PESQ): An 792 objective method for end-to-end speech quality assessment 793 of narrow-band telephone networks and speech codecs", 794 ITU-T Recommendation P.862, Febuary 2001. 796 [P.862.1] ITU-T, "Mapping function for transforming P.862 raw result 797 scores to MOS-LQO", ITU-T Recommendation P.862.1, 798 November 2003. 800 [P.862.2] ITU-T, "Wideband extension to Recommendation P.862 for the 801 assessment of wideband telephone networks and speech 802 codecs", ITU-T Recommendation P.862.2, November 2007. 804 [P.863] ITU-T, "Perceptual objective listening quality 805 assessment", ITU-T Recommendation P.863, January 2011. 807 [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for 808 AC-3 Audio", RFC 4184, October 2005. 810 [RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload 811 Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, 812 July 2006. 814 [RFC5188] Desineni, H. and Q. Xie, "RTP Payload Format for the 815 Enhanced Variable Rate Wideband Codec (EVRC-WB) and the 816 Media Subtype Updates for EVRC-B Codec", RFC 5188, 817 February 2008. 819 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 820 Development", RFC 6390, October 2011. 822 [RFC6792] Wu, Q., "Monitoring Architectures for RTP", RFC 6792, 823 November 2012. 825 [TTC] TTC 201.01 (Japan), "A method for speech quality 826 assessment for Voice over IP". 828 Appendix A. Metrics represented using RFC6390 Template 830 RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC 831 number, when assigned. 833 a. MOS Value Metric 835 * Metric Name: MOS 837 * Metric Description: The estimated Mean Opinion Score for 838 multimedia application performance is defined as including the 839 effects of delay,loss, discard,jitter and other effects that 840 would affect audio or video quality. 842 * Method of Measurement or Calculation: See section 3.2.1, MOS 843 value definition [RFCXXXX]. 845 * Units of Measurement: See section 3.2.1, MOS value definition 846 [RFCXXXX]. 848 * Measurement Point(s) with Potential Measurement Domain: See 849 section 3, 2nd paragraph [RFCXXXX]. 851 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 852 measurement timing and section 3.1 [RFCXXXX] for Interval 853 Metric flag. 855 * Use and applications: See section 1.4 [RFCXXXX]. 857 * Reporting model: See RFC3611. 859 b. Segment Type Metric 861 * Metric Name: Segment Type 863 * Metric Description: It is used to identify the segment type 864 used in this report block. For more details, see section 865 3.2.1, Segment type definition. 867 * Method of Measurement or Calculation: See section 3.2.1, 868 Segment Type definition [RFCXXXX]. 870 * Units of Measurement: See section 3.2.1, Segment Type 871 definition [RFCXXXX]. 873 * Measurement Point(s) with Potential Measurement Domain: See 874 section 3, 2nd paragraph [RFCXXXX]. 876 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 877 measurement timing and section 3.1 [RFCXXXX] for Interval 878 Metric flag. 880 * Use and applications: See section 1.4 [RFCXXXX]. 882 * Reporting model: See RFC3611. 884 c. Calculation Algorithm Identifier Metric 886 * Metric Name: Calculation Algorithm Identifier 888 * Metric Description: It is the local identifier of calculation 889 Algorithm associated with this segment in the range 1-255 890 inclusive. 892 * Method of Measurement or Calculation: See section 3.2.1, 893 Calculation Algorithm ID definition [RFCXXXX]. 895 * Units of Measurement: See section 3.2.1, Calg Algorithm ID 896 definition[RFCXXXX]. 898 * Measurement Point(s) with Potential Measurement Domain: See 899 section 3, 2nd paragraph [RFCXXXX]. 901 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 902 measurement timing and section 3.1 [RFCXXXX] for Interval 903 Metric flag. 905 * Use and applications: See section 1.4 [RFCXXXX]. 907 * Reporting model: See RFC3611. 909 d. Payload Type Metric 911 * Metric Name: Payload Type 913 * Metric Description: It is used to identify the format of the 914 RTP payload. For more details, see section 3.2.1, payload 915 type definition. 917 * Method of Measurement or Calculation: See section 3.2.1, 918 Payload type definition [RFCXXXX]. 920 * Units of Measurement: See section 3.2.1, payload type 921 definition[RFCXXXX]. 923 * Measurement Point(s) with Potential Measurement Domain: See 924 section 3, 2nd paragraph [RFCXXXX]. 926 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 927 measurement timing and section 3.1 [RFCXXXX] for Interval 928 Metric flag. 930 * Use and applications: See section 1.4 [RFCXXXX]. 932 * Reporting model: See RFC3611. 934 e. Channel Identifier Metric 936 * Metric Name: Payload Type 938 * Metric Description: It is used to identify each channel 939 carried in the same media stream. For more details, see 940 section 3.2.2, channel identifier definition. 942 * Method of Measurement or Calculation: See section 3.2.2, 943 Channel Identifier definition [RFCXXXX]. 945 * Units of Measurement: See section 3.2.2, channel identifier 946 definition[RFCXXXX]. 948 * Measurement Point(s) with Potential Measurement Domain: See 949 section 3, 2nd paragraph [RFCXXXX]. 951 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 952 measurement timing and section 3.1 [RFCXXXX] for Interval 953 Metric flag. 955 * Use and applications: See section 1.4 [RFCXXXX]. 957 * Reporting model: See RFC3611. 959 Appendix B. Change Log 961 B.1. draft-ietf-xrblock-rtcp-xr-qoe-13 963 o Incorporated comments from Gen Art review 964 o Amended SDP description in 4.1 965 o Overall clean up 967 B.2. draft-ietf-xrblock-rtcp-xr-qoe-10 969 The following are the major changes compared to previous version: 971 o Replace QoE metrics with MOS metrics. 973 B.3. draft-ietf-xrblock-rtcp-xr-qoe-09 975 The following are the major changes compared to previous version: 976 o Address comments recieved from WGLC, PM-DIR Review and SDP review. 977 o Change an existing SDP attribute 'extmap' to new SDP attribute 978 'calgextmap' and add new SDP attribute registry. 979 o Add Reference to G.107.1, P.862.1, P.862.2 and P.863 for new 980 calculation algorithms. 981 o Add MOS type attribute to distinguish different MOS type. 982 o Other Editorial changes. 984 B.4. draft-ietf-xrblock-rtcp-xr-qoe-08 986 The following are the major changes compared to previous version: 987 o Remove mostype attribute from SDP extension since it can inferred 988 from payload type. 989 o Clarify mosref attribute usage in the O/A. 991 B.5. draft-ietf-xrblock-rtcp-xr-qoe-07 993 The following are the major changes compared to previous version: 994 o Some editorial changes to get in line with burst gap related 995 draft. 996 o Add an appendix to apply RFC6390 template. 998 B.6. draft-ietf-xrblock-rtcp-xr-qoe-06 1000 The following are the major changes compared to previous two 1001 versions: 1002 o A few Contact information update. 1003 o A few Acknowledgement section update. 1005 B.7. draft-ietf-xrblock-rtcp-xr-qoe-04 1007 The following are the major changes compared to previous version: 1008 o Split two references P.NAMS and P.NBAMS into four references. 1009 o SDP signaling update. 1010 o Add one example to explain User QoE evaluation for video stream 1012 B.8. draft-ietf-xrblock-rtcp-xr-qoe-03 1014 The following are the major changes compared to previous version: 1015 o Add one new reference to support TTC JJ201.01. 1016 o Update two references P.NAMS and P.NBAMS. 1017 o Other Editorial changes based on comments applied to PDV and Delay 1018 drafts. 1020 B.9. draft-ietf-xrblock-rtcp-xr-qoe-02 1022 The following are the major changes compared to previous version: 1023 o Remove leftmost second bit since it is ueeless. 1024 o Change 13bits MOS value field into 14 bits to increase MOS 1025 precision. 1026 o Fix some typo and make some editorial changes. 1028 B.10. draft-ietf-xrblock-rtcp-xr-qoe-01 1030 The following are the major changes compared to previous version: 1031 o Remove layered support from the QoE Metric draft. 1032 o Allocate 7 bits in the block header for payload type to indicate 1033 what type of payload format is in use and add associated 1034 definition of payload type. 1035 o Clarify using Payload Type to determine the appropriate channel 1036 mapping in the definition of Channel Identifier. 1038 B.11. draft-ietf-xrblock-rtcp-xr-qoe-00 1040 The following are the major changes compared to previous version: 1041 o Allocate one more bit in the single channel per SSC segment to get 1042 alignment with the other two segment type. 1044 Authors' Addresses 1046 Alan Clark 1047 Telchemy Incorporated 1048 2905 Premiere Parkway, Suite 280 1049 Duluth, GA 30097 1050 USA 1052 Email: alan.d.clark@telchemy.com 1054 Qin Wu 1055 Huawei 1056 101 Software Avenue, Yuhua District 1057 Nanjing, Jiangsu 210012 1058 China 1060 Email: sunseawq@huawei.com 1062 Roland Schott 1063 Deutsche Telekom 1064 Heinrich-Hertz-Strasse 3-7 1065 Darmstadt 64295 1066 Germany 1068 Email: Roland.Schott@telekom.de 1070 Glen Zorn 1071 Network Zen 1072 77/440 Soi Phoomjit, Rama IV Road 1073 Phra Khanong, Khlong Toie 1074 Bangkok 10110 1075 Thailand 1077 Phone: +66 (0) 87 502 4274 1078 Email: gwz@net-zen.net