idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-qoe-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2014) is 3710 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 971, but not defined == Unused Reference: 'RFC5234' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'G.1082' is defined on line 777, 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: August 31, 2014 Huawei 6 R. Schott 7 Deutsche Telekom 8 G. Zorn 9 Network Zen 10 February 27, 2014 12 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric 13 Reporting 14 draft-ietf-xrblock-rtcp-xr-qoe-17 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 mean opinion score (MOS) 21 Metrics for use in a range of RTP applications. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 31, 2014. 40 Copyright Notice 42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Report 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 11 71 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 13 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 15 74 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 15 75 5.3. The SDP calgextmap Attribute . . . . . . . . . . . . . . . 15 76 5.4. New registry of calculation algorithms . . . . . . . . . . 16 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 83 Appendix A. Metrics represented using RFC6390 Template . . . . . 20 84 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 85 B.1. draft-ietf-xrblock-rtcp-xr-qoe-15 . . . . . . . . . . . . 23 86 B.2. draft-ietf-xrblock-rtcp-xr-qoe-14 . . . . . . . . . . . . 23 87 B.3. draft-ietf-xrblock-rtcp-xr-qoe-10 . . . . . . . . . . . . 23 88 B.4. draft-ietf-xrblock-rtcp-xr-qoe-09 . . . . . . . . . . . . 23 89 B.5. draft-ietf-xrblock-rtcp-xr-qoe-08 . . . . . . . . . . . . 23 90 B.6. draft-ietf-xrblock-rtcp-xr-qoe-07 . . . . . . . . . . . . 24 91 B.7. draft-ietf-xrblock-rtcp-xr-qoe-06 . . . . . . . . . . . . 24 92 B.8. draft-ietf-xrblock-rtcp-xr-qoe-04 . . . . . . . . . . . . 24 93 B.9. draft-ietf-xrblock-rtcp-xr-qoe-03 . . . . . . . . . . . . 24 94 B.10. draft-ietf-xrblock-rtcp-xr-qoe-02 . . . . . . . . . . . . 24 95 B.11. draft-ietf-xrblock-rtcp-xr-qoe-01 . . . . . . . . . . . . 24 96 B.12. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 25 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 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 (Quality of Experience) measurement algorithms are 132 defined. 134 The factors that affect real-time audio/video application quality can 135 be split into two categories. The first category consists of 136 transport-specific factors such as packet loss, delay and jitter 137 (which also translates into losses in the playback buffer). The 138 factors in the second category consists of content and codec related 139 factors such as codec type and loss recovery technique, coding bit 140 rate, packetization scheme, and content characteristics 142 Transport-specific factors may be insufficient to infer real time 143 media quality as codec related parameters and the interaction between 144 transport problems and application layer protocols can have a 145 substantial effect on observed media quality. Media quality may be 146 measured using algorithm that directly compare input and output media 147 streams, or may be estimated using algorithms that model the 148 interaction between media quality, protocol and encoded content. 149 Media quality is commonly expressed in terms of Mean Opinion Score 150 (MOS) however is also represented by a range of indexes and other 151 scores. 153 The measurement of media quality has a number of applications: 154 o Detecting problems with media delivery or encoding that is 155 impacting user perceived quality. 156 o Tuning the content encoder algorithm to satisfy real time data 157 quality requirements. 158 o Determining which system techniques to use in a given situation 159 and when to switch from one technique to another as system 160 parameters change (for example as discussed in [P.1082]). 161 o Pre-qualifying a network to assess its ability to deliver an 162 acceptable end-user perceived quality level. 164 2. Terminology 166 2.1. Standards Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 The terminology used is 174 Numeric formats X:Y 176 where X the number of bits prior to the decimal place and Y the 177 number 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. 0:16 represents a proper 180 binary fraction with range 181 0.0 to 1 - 1/65536 = 0.9999847 182 though note that use of flag values at the top of the numeric 183 range slightly reduces this upper limit. For example, if the 184 16- bit values 0xfffe and 0xffff are used as flags for "over- 185 range" and "unavailable" conditions, a 0:16 quantity has range 186 0.0 to 1 - 3/65536 = 0.9999542 188 3. MoS Metrics Block 190 Multimedia application MOS Metric is commonly expressed as a MOS 191 ("Mean Opinion Score"), MOS is usually on a scale from 1 to 5, in 192 which 5 represents excellent and 1 represents unacceptable however 193 can use other ranges (for example 0 to 10 ) . The term "MOS score" 194 originates from subjective testing, and is used to refer to the Mean 195 of a number of individual Opinion Scores. There is therefore a well 196 understood relationship between MOS and user experience, hence the 197 industry commonly uses MOS as the scale for objective test results. 198 Subjective tests can be used for measuring live network traffic 199 however the use of objective or algorithmic measurement techniques 200 allows much larger scale measurements to be made. Within the scope 201 of this document, MOS scores are obtained using objective or 202 estimation algorithms. ITU-T or ITU-R recommendations (e.g., 203 [BS.1387-1],[G.107],[G.107.1],[P.862],[P.862.1],[P.862.2],[P.863],[P. 204 564],[G.1082],[P.1201.1],[P.1201.2],[P.1202.1],[P.1202.2]) define 205 methodologies for assessment of the performance of audio and video 206 streams. Other international and national standards organizations 207 such as EBU, ETSI, IEC and IEEE also define QoE algorithms and 208 methodologies, and the intent of this document is not to restrict its 209 use to ITU recommendations but to suggest that ITU recommendations be 210 used where they are defined. 212 This block reports the media quality in the form of a MOS range 213 (e.g., 1-5, 0-10, or 0-100, as specified by the calculation 214 algorithm) however does not report the MoS score that include 215 parameters outside the scope of the RTP stream, for example signaling 216 performance, mean time to repair (MTTR) or other factors that may 217 affect the overall user experience. 219 The MOS Metric reported in this block gives a numerical indication of 220 the perceived quality of the received media stream, which is 221 typically measured at the receiving end of the RTP stream. Instances 222 of this Metrics Block refer by Synchronization source (SSRC) to the 223 separate auxiliary Measurement Information block [RFC6776] which 224 describes measurement periods in use (see RFC6776 section 4.2). 226 This Metrics Block relies on the measurement period in the 227 Measurement Information block indicating the span of the report. 228 Senders MUST send this block in the same compound RTCP packet as the 229 measurement information block. Receivers MUST verify that the 230 measurement period is received in the same compound RTCP packet as 231 this Metrics Block. If not, this Metrics Block MUST be discarded. 233 3.1. Report Block Structure 235 The MOS Metrics Block has the following format: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | BT=MMB | I | Reserved | Block Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | SSRC of source | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Segment 1 | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Segment 2 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 .................. 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Segment n | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 3.2. Definition of Fields in MoS Metrics Block 255 Block type (BT): 8 bits 257 The MOS Metrics Block is identified by the constant . 259 Interval Metric flag (I): 2 bits 261 This field is used to indicate whether the MOS Metrics are 262 Sampled, Interval or Cumulative [RFC6792]: 264 I=10: Interval Duration - the reported value applies to the 265 most recent measurement interval duration between successive 266 metrics reports. 267 I=11: Cumulative Duration - the reported value applies to the 268 accumulation period characteristic of cumulative measurements. 269 I=01: Sampled Value - the reported value is a sampled 270 instantaneous value. 271 I=00: Reserved 273 In this document, MOS Metrics MAY be reported for intervals or for 274 the duration of the media stream (cumulative). The value I=01, 275 indicating a sampled value, MUST NOT be sent, and MUST be 276 discarded when received. 278 Reserved: 6 bits 280 This field is reserved for future definition. In the absence of 281 such a definition, the bits in this field MUST be set to zero and 282 ignored by the receiver (See RFC6709 section 4.2). 284 Block Length: 16 bits 286 The length of this report block in 32-bit words, minus one. For 287 the MOS Metrics Block, the block length is variable length. 289 SSRC of source: 32 bits 291 As defined in Section 4.1 of [RFC3611]. 293 Segment i: 32 bits 295 There are two segment types defined in this document: single 296 stream Audio/Video per SSRC segment, multi-channel audio per SSRC 297 segment. Multi-channel audio per SSRC segment is used to deal 298 with the case where Multi-channel audios are carried in one RTP 299 stream while single channel Audio/Video per SSRC segment is used 300 to deal with the case where each media stream is identified by 301 SSRC and sent in separate RTP stream. The leftmost bit of the 302 segment determines its type. If the leftmost bit of the segment 303 is zero, then it is single channel segment. If the leftmost bit 304 is one, then it is multi-channel audio segment. Note that two 305 segment types can not be present in the same metric block. 307 3.2.1. Single Channel audio/video per SSRC Segment 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |S| CAID | PT | MOS Value | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Segment Type (S): 1 bit 315 This field is used to identify the segment type used in this 316 report block. A zero identifies this as a single channel Audio/ 317 Video per SSRC segment. Single channel means there is only one 318 media stream carried in one RTP stream. The single channel Audio/ 319 Video per SSRC segment can be used to report the MOS value 320 associated with the media stream identified by SSRC. If there are 321 multiple media streams and they want to use the single channel 322 Audio/Video per SSRC segment to report the MOS value, they should 323 be carried in the separate RTP streams with each identified by 324 different SSRC. In this case, multiple MOS Metrics Blocks are 325 required to report the MOS value corresponding to each media 326 stream using single channel Audio/Video per SSRC segment in the 327 same RTCP XR packet. 329 Calculation Algorithm ID (CAID) : 8 bits 331 The 8-bit CAID is the session specific reference to the 332 calculation algorithm and associated qualifiers indicated in SDP 333 (see Section 4.1) and used to compute the MOS score for this 334 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 (MOS) 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 This is a unsigned fixed-point 7:9 value representing the MOS, 359 allowing the MOS score up to 127 in the integer part. MOS ranges 360 are defined as part of the specification of the MOS estimation 361 algorithm (Calculation Algorithm in this document), and are 362 normally ranges like 1-5, 0-10, or 0-100. Two values are 363 reserved: A value of 0xFFFE indicates out of range and a value of 364 0xFFFF indicates that the measurement is unavailable. Values 365 outside of the range defined by the Calculation Algorithm, other 366 than the two reserved values, MUST NOT be sent and MUST be ignored 367 by the receiving system. 369 3.2.2. Multi-Channel audio per SSRC Segment 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |S| CAID | PT |CHID | MOS Value | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Segment Type (S): 1 bit 377 This field is used to identify the segment type used in this 378 report block. A one identifies this as a multi-channel audio 379 segment. 381 Calculation Algorithm ID (CAID) : 8 bits 383 The 8-bit CAID is the session specific reference to the 384 calculation algorithm and associated qualifiers indicated in SDP 385 (see Section 4.1) and used to compute the MOS score for this 386 segment. 388 Payload Type (PT): 7 bits 390 As defined in Section 3.2.1 of this document 392 Channel Identifier (CHID): 3 bits 394 If multiple channels of audio are carried in one RTP stream, each 395 channel of audio will be viewed as a independent channel(e.g., 396 left channel audio, right channel audio). This field is used to 397 identify each channel carried in the same media stream. The 398 default Channel mapping follows static ordering rule described in 399 the section 4.1 of [RFC3551]. However there are some payload 400 formats that use different channel mappings, e.g., AC-3 audio over 401 RTP [RFC4184] only follow AC-3 channel order scheme defined in 402 [ATSC]. Enhanced AC-3 Audio over RTP [RFC4598] uses dynamic 403 channel transform mechanism. In order that the appropriate 404 channel mapping can be determined, MOS metrics reports need to be 405 tied to an RTP payload format, i.e., including the payload type of 406 the reported media according to [RFC6792] and using Payload Type 407 to determine the appropriate channel mapping. 409 MOS Value: 13 bits 411 The estimated Mean Opinion Score (MOS) for multimedia application 412 performance is defined as including the effects of delay, loss, 413 discard, jitter and other effects that would affect media quality. 414 This is a unsigned fixed-point 7:6 value representing the MOS, 415 allowing the MOS score up to 127 in the integer part. MOS ranges 416 are defined as part of the specification of the MOS estimation 417 algorithm (Calculation Algorithm in this document), and are 418 normally ranges like 1-5, 0-10, or 0-100. Two values are 419 reserved: A value of 0x1FFE indicates out of range and a value of 420 0x1FFF indicates that the measurement is unavailable. Values 421 outside of the range defined by the Calculation Algorithm, other 422 than the two reserved values, MUST NOT be sent and MUST be ignored 423 by the receiving system. 425 4. SDP Signaling 427 [RFC3611]defines the use of SDP (Session Description Protocol) 428 [RFC4566] for signaling the use of XR blocks. However XR blocks MAY 429 be used without prior signaling (see section 5 of RFC3611). 431 4.1. SDP rtcp-xr-attrib Attribute Extension 433 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 434 in [RFC3611] by providing an additional value of "xr-format" to 435 signal the use of the report block defined in this document. Within 436 the "xr-format", the syntax element "calgextmap" is an attribute as 437 defined in [RFC4566] and used to signal the mapping of the local 438 identifier (CAID) in the segment extension defined in section 3.2 to 439 the calculation algorithm. Specific extensionattributes are defined 440 by the specification that defines a specific extension name; there 441 might be several. 443 xr-format =/ xr-mos-block 444 xr-mos-block = "mos-metric" ["=" calgextmap *("," calgextmap)] 445 calgextmap = mapentry "=" extensionname [SP extentionattributes] 446 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 447 mapentry = "calg:" 1*3 DIGIT ["/" direction] 448 ; Values in the range 1-255 are valid 449 ; if needed, 0 can be used to indicate that 450 ; an algorithm is rejected 451 extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564] 452 / "G107";ITU-T G.107 [G.107] 453 / "G107_1";ITU-T G.107.1 [G.107.1] 454 / "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI] 455 /"JJ201_1 ";TTC JJ201.1 [TTC] 456 /"P1201_1";ITU-T P.1201.2 [P.1201.1] 457 /"P1201_2";ITU-T P.1201.2 [P.1201.2] 458 /"P1202_1";ITU-T P.1202.1 [P.1202.1] 459 /"P1202_2";ITU-T P.1202.2 [P.1202.2] 460 /"P.862.2";ITU-T P.862.2 [P.862.2] 461 /"P.863"; ITU-T P.863 [P.863] 462 / non-ws-string 463 extensionattributes = mosref 464 /attributes-ext 465 mosref = "mosref=" ("l"; lower resolution 466 /"m"; middle resolution 467 / "h";higher resolution 468 / non-ws-string) 469 attributes-ext = non-ws-string 470 SP = 471 non-ws-string = 1*(%x21-FF) 473 Each local identifier (CAID)of calculation algorithm used in the 474 segment defined in the section 3.2 is mapped to a string using an 475 attribute of the form: 477 a=calg: ["/"] [] 479 where is a calculation algorithm name, as above, is 480 the local identifier (CAID)of the calculation algorithm associated 481 with the segment defined in this document and is an integer in the 482 valid range inclusive. 484 Example: 485 a=rtcp-xr:mos-metric=calg:1=G107,calg:2=P1202_1 487 A usable mapping MUST use IDs in the valid range, and each ID in this 488 range MUST be unique and used only once for each stream or each 489 channel in the stream. 491 The mapping MUST be provided per media stream (in the media-level 492 section(s) of SDP, i.e., after an "m=" line). 494 The syntax element "mosref" is referred to the media resolution 495 relative reference and has three valules 'l','m','h'.(e.g., 496 Narrowband (3.4kHz) Speech and Standard Definition (SD) or lower 497 Resolution Video have 'l' resolution, Super Wideband (>14kHz) Speech 498 or higher and High Definition (HD) or higher Resolution Video have 499 'h' Resolution, Wideband speech(7khz) and Video with resolution 500 between SD and HD has 'm' resolution). The MOS score reported in the 501 MOS metrics block might vary with the MOS reference; For example, MOS 502 values for narrowband, wideband, super wideband codecs occupy the 503 same range but SHOULD be reported in different value. For video 504 application, MOS scores for SD resolution, HD resolution video also 505 occupy the same ranges and SHOULD be reported in different value. 507 4.2. Offer/Answer Usage 509 When SDP is used in offer-answer context, the SDP Offer/Answer usage 510 defined in [RFC3611] applies. In the offer answer context, the 511 signaling described above might be used in three ways: 513 o asymmetric behavior (segment extensions sent in only one 514 direction), 515 o the offer of mutually exclusive alternatives, or 516 o the offer of more segments than can be sent in a single session. 518 A direction attribute MAY be included in a calgextmap; without it, 519 the direction implicitly inherits, of course, from the RTCP stream 520 direction. 522 Segment extensions, with their directions, MAY be signaled for an 523 "inactive" stream. An extension direction MUST be compatible with 524 the stream direction. If a segment extension in the SDP offer is 525 marked as "sendonly" and the answerer desires to receive it, the 526 extension MUST be marked as "recvonly" in the SDP answer. An 527 answerer that has no desire to receive the extension or does not 528 understand the extension SHOULD NOT include it in the SDP answer. 530 If a segment extension is marked as "recvonly" in the SDP offer and 531 the answerer desires to send it, the extension MUST be marked as 532 "sendonly" in the SDP answer. An answerer that has no desire to, or 533 is unable to, send the extension SHOULD NOT include it in the SDP 534 answer. 536 If a segment extension is offered as "sendrecv", explicitly or 537 implicitly, and asymmetric behavior is desired, the SDP MAY be 538 modified to modify or add direction qualifiers for that segment 539 extension. 541 A mosref attribute and MOS type attribute MAY be included in an 542 calgextmap; without it, the mosref and most type attribute implicitly 543 inherits, of course, from the name attribute (e.g., P.1201.1 544 [P.1201.1] indicates lower resolution used while P.1201.2 [P.1201.2] 545 indicates higher resolution used) or payload type carried in the 546 segment extension (e.g.,EVRC-WB [RFC5188] indicates using Wideband 547 Codec). However not all payload types or MOS algorithm names 548 indicate resolution to be used and MOS type to be used. If an 549 answerer receives an offer with an mosref attribute value it doesn't 550 support (e.g.,the answerer only supports "l" and receives "h"from 551 offerer), the answer SHOULD reject the mosref attribute value offered 552 by the offerer. 554 If the answerer wishes to reject a mosref attribute offered by the 555 offerer, it sets identifiers associated with segment extensions in 556 the answer to the value in the range 4096-4351. The rejected answer 557 MUST contain 'mosref ' attribute whose value is the value of the SDP 558 offer. 560 Local identifiers in the valid range inclusive in an offer or answer 561 must not be used more than once per media section. A session update 562 MAY change the direction qualifiers of segment extensions under use. 563 A session update MAY add or remove segment extension(s). Identifiers 564 values in the valid range MUST NOT be altered (remapped). 566 If a party wishes to offer mutually exclusive alternatives, then 567 multiple segment extensions with the same identifier in the 568 (unusable) range 4096-4351 MAY be offered; the answerer SHOULD select 569 at most one of the offered extensions with the same identifier, and 570 remap it to a free identifier in the valid range, for that extension 571 to be usable. Note that two segment types defined in section 3 are 572 also two exclusive alternatives. 574 If more segment extensions are offered in the valid range, the 575 answerer SHOULD choose those that are desired, and place the offered 576 identifier value "as is" in the SDP answer. 578 Similarly, if more segment extensions are offered than can be fit in 579 the valid range, identifiers in the range 4096-4351 MAY be offered; 580 the answerer SHOULD choose those that are desired, and remap them to 581 a free identifier in the valid range. 583 Note that the range 4096-4351 for these negotiation identifiers is 584 deliberately restricted to allow expansion of the range of valid 585 identifiers in future. Segment extensions with an identifier outside 586 the valid range cannot, of course, be used. 588 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 589 all omitted for brevity): 591 The offer: 593 a=rtcp-xr:mos-metric=calg:4906=P1201_l,calg:4906=P1202_l, calg: 594 4907=G107 596 The answerer is interested in transmission P.1202.1 on lower 597 resolution application, but doesn't support P.1201.1 on lower 598 resolution application at all. It is interested in transmission 599 G.107. It therefore adjusts the declarations: 601 a=rtcp-xr:mos-metric=calg:1=P1202_l,calg:2=G107 603 5. IANA Considerations 605 New block types for RTCP XR are subject to IANA registration. For 606 general guidelines on IANA considerations for RTCP XR, refer to 607 [RFC3611]. 609 5.1. New RTCP XR Block Type value 611 This document assigns the block type value MMB in the IANA " RTP 612 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 613 the "MOS Metrics Block". 615 [Note to RFC Editor: please replace MMB with the IANA provided RTCP 616 XR block type for this block.] 618 5.2. New RTCP XR SDP Parameter 620 This document also registers a new parameter "mos-metric" in the " 621 RTP Control Protocol Extended Reports (RTCP XR) Session Description 622 Protocol (SDP) Parameters Registry". 624 5.3. The SDP calgextmap Attribute 626 This section contains the information required by [RFC4566] for an 627 SDP attribute. 628 o contact name, email address: RAI Area Directors 629 630 o attribute name (as it will appear in SDP): calgextmap 631 o long-form attribute name in English: calculation algorithm map 632 definition 634 o type of attribute (session level, media level, or both): both 635 o whether the attribute value is subject to the charset attribute: 636 not subject to the charset attribute 637 o a one-paragraph explanation of the purpose of the attribute: This 638 attribute defines the mapping from the local identifier (CAID) in 639 the segment extension defined in section 3.2 into the calculation 640 algorithm name as documented in specifications and appropriately 641 registered. 642 o a specification of appropriate attribute values for this 643 attribute: see RFC xxxx. 645 5.4. New registry of calculation algorithms 647 This document creates a new registry to be called "RTCP XR MOS Metric 648 block - multimedia application Calculation Algorithm" as a sub- 649 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 650 Block Type Registry". This registry applies to the multimedia 651 session where each type of media are sent in a separate RTP stream 652 and also applies to the session where Multi-channel audios are 653 carried in one RTP stream. Policies for this new registry are as 654 follows: 656 o The information required to support this assignment is an 657 unambiguous definition of the new metric, covering the base 658 measurements and how they are processed to generate the reported 659 metric. 661 o The review process for the registry is "Specification Required" as 662 described in Section 4.1 of [RFC5226]. 664 o Entries in the registry are identified by entry name and mapped to 665 the local identifier (CAID) in the segment extension defined in 666 section 3.2. 668 o Registration Template 670 The following information must be provided with each registration: 671 * Name: A string uniquely and unambiguously identifying the 672 Calculation algorithm for use in protocols. 673 * Name Description: A valid Description of the Calculation 674 algorithm name. 675 * Reference: The reference which defines the calculation 676 algorithm corresponding to the Name and Name Description. 677 * Type: The media type to which the calculation algorithm is 678 applied 680 o Initial assignments are as follows: 682 Name Name Description Reference Type 683 ========= =================================== ========== ==== 684 P564 ITU-T P.564 Compliant Algorithm [P.564] Voice 685 G107 ITU-T G.107 [G.107] Voice 686 TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice 687 JJ201_1 TTC JJ201.1 [TTC] Voice 688 G107_1 ITU-T G.107.1 [G.107.1] Voice 689 P862 ITU-T P.862 [P.862] Voice 690 P862_2 ITU-T P.862.2 [P.862.2] Voice 691 P863 ITU-T P.863 [P.863] Voice 692 P1201_1 ITU-T P.1201.1 [P.1201.1] Multimedia 693 P1201_2 ITU-T P.1201.2 [P.1201.2] Multimedia 694 P1202_1 ITU-T P.1202.1 [P.1202.1] Video 695 P1202_2 ITU-T P.1202.2 [P.1202.2] Video 697 6. Security Considerations 699 The new RTCP XR report blocks proposed in this document introduces no 700 new security considerations beyond those described in [RFC3611]. 702 7. Authors 704 This draft merges ideas from two drafts addressing the MOS Metric 705 Reporting issue. The authors of these drafts are listed below (in 706 alphabetical order): 708 Alan Clark < alan.d.clark@telchemy.com > 709 Geoff Hunt < r.geoff.hunt@gmail.com > 710 Martin Kastner < martin.kastner@telchemy.com > 711 Qin Wu < sunseawq@huawei.com > 712 Roland Schott < roland.schott@telekom.de > 713 Glen Zorn < gwz@net-zen.net > 714 Kai Lee < leekai@ctbri.com.cn > 716 8. Acknowledgements 718 The authors gratefully acknowledge the comments and contributions 719 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 720 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 721 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 722 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 723 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Bill Ver Steeg, David R 724 Oran, Ted Lemon,Benoit Claise, Pete Resnick, Ali Begen and Hideaki 725 Yamada. 727 9. References 729 9.1. Normative References 731 [ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC 732 Standard: Digital Audio Compression (AC-3), Revision B", 733 ATSC Doc A/52B, June 2005. 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, March 1997. 738 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 739 Applications", RFC 3550, July 2003. 741 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 742 Video Conferences with Minimal Control", RFC 3551, 743 July 2003. 745 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 746 Protocol Extended Reports (RTCP XR)", RFC 3611, 747 November 2003. 749 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 750 Description Protocol", RFC 4566, July 2006. 752 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 753 Section in RFCs", RFC 5226, May 2008. 755 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 756 Specifications: ABNF", STD 68, RFC 5234, January 2008. 758 [RFC6776] Wu, Q., "Measurement Identity and information Reporting 759 using SDES item and XR Block", RFC 6776, October 2012. 761 9.2. Informative References 763 [BS.1387-1] 764 ITU-R, "Method for objective measurements of perceived 765 audio quality", ITU-R Recommendation BS.1387-1, 2001. 767 [ETSI] ETSI, "Quality of Service (QoS) measurement 768 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 770 [G.107] ITU-T, "The E Model, a computational model for use in 771 transmission planning", ITU-T Recommendation G.107, 772 April 2009. 774 [G.107.1] ITU-T, "Wideband E-model", ITU-T Recommendation G.107.1, 775 December 2011. 777 [G.1082] ITU-T, "Measurement-based methods for improving the 778 robustness of IPTV performance", ITU-T 779 Recommendation G.1082, April 2009. 781 [P.1201.1] 782 ITU-T, "Parametric non-intrusive assessment of audiovisual 783 media streaming quality - lower resolution application 784 area", ITU-T Recommendation P.1201.1, October 2012. 786 [P.1201.2] 787 ITU-T, "Parametric non-intrusive assessment of audiovisual 788 media streaming quality - higher resolution application 789 area", ITU-T Recommendation P.1201.2, October 2012. 791 [P.1202.1] 792 ITU-T, "Parametric non-intrusive bitstream assessment of 793 video media streaming quality - lower resolution 794 application area", ITU-T Recommendation P.1202.1, 795 October 2012. 797 [P.1202.2] 798 ITU-T, "Parametric non-intrusive bitstream assessment of 799 video media streaming quality - higher resolution 800 application area", ITU-T Recommendation P.1202.2, 801 May 2013. 803 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 804 transmission quality assessment models", ITU-T 805 Recommendation P.564, July 2006. 807 [P.862] ITU-T, "Perceptual evaluation of speech quality (PESQ): An 808 objective method for end-to-end speech quality assessment 809 of narrow-band telephone networks and speech codecs", 810 ITU-T Recommendation P.862, Febuary 2001. 812 [P.862.1] ITU-T, "Mapping function for transforming P.862 raw result 813 scores to MOS-LQO", ITU-T Recommendation P.862.1, 814 November 2003. 816 [P.862.2] ITU-T, "Wideband extension to Recommendation P.862 for the 817 assessment of wideband telephone networks and speech 818 codecs", ITU-T Recommendation P.862.2, November 2007. 820 [P.863] ITU-T, "Perceptual objective listening quality 821 assessment", ITU-T Recommendation P.863, January 2011. 823 [RFC4184] Link, B., Hager, T., and J. Flaks, "RTP Payload Format for 824 AC-3 Audio", RFC 4184, October 2005. 826 [RFC4598] Link, B., "Real-time Transport Protocol (RTP) Payload 827 Format for Enhanced AC-3 (E-AC-3) Audio", RFC 4598, 828 July 2006. 830 [RFC5188] Desineni, H. and Q. Xie, "RTP Payload Format for the 831 Enhanced Variable Rate Wideband Codec (EVRC-WB) and the 832 Media Subtype Updates for EVRC-B Codec", RFC 5188, 833 February 2008. 835 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 836 Development", RFC 6390, October 2011. 838 [RFC6792] Wu, Q., "Monitoring Architectures for RTP", RFC 6792, 839 November 2012. 841 [TTC] TTC 201.01 (Japan), "A method for speech quality 842 assessment for Voice over IP". 844 Appendix A. Metrics represented using RFC6390 Template 846 RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC 847 number, when assigned. 849 a. MOS Value Metric 851 * Metric Name: MOS in RTP 853 * Metric Description: The estimated Mean Opinion Score for 854 multimedia application performance of RTP stream is defined as 855 including the effects of delay,loss, discard,jitter and other 856 effects that would affect audio or video quality. 858 * Method of Measurement or Calculation: See section 3.2.1, MOS 859 value definition [RFCXXXX]. 861 * Units of Measurement: See section 3.2.1, MOS value definition 862 [RFCXXXX]. 864 * Measurement Point(s) with Potential Measurement Domain: See 865 section 3, 2nd paragraph [RFCXXXX]. 867 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 868 measurement timing and section 3.1 [RFCXXXX] for Interval 869 Metric flag. 871 * Use and applications: See section 1.4 [RFCXXXX]. 873 * Reporting model: See RFC3611. 875 b. Segment Type Metric 877 * Metric Name: Segment Type in RTP 879 * Metric Description: It is used to identify the segment type of 880 RTP stream used in this report block. For more details, see 881 section 3.2.1, Segment type definition. 883 * Method of Measurement or Calculation: See section 3.2.1, 884 Segment Type definition [RFCXXXX]. 886 * Units of Measurement: See section 3.2.1, Segment Type 887 definition [RFCXXXX]. 889 * Measurement Point(s) with Potential Measurement Domain: See 890 section 3, 2nd paragraph [RFCXXXX]. 892 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 893 measurement timing and section 3.1 [RFCXXXX] for Interval 894 Metric flag. 896 * Use and applications: See section 1.4 [RFCXXXX]. 898 * Reporting model: See RFC3611. 900 c. Calculation Algorithm Identifier Metric 902 * Metric Name: RTP Stream Calculation Algorithm Identifier 904 * Metric Description: It is the local identifier of RTP Stream 905 calculation Algorithm associated with this segment in the 906 range 1-255 inclusive. 908 * Method of Measurement or Calculation: See section 3.2.1, 909 Calculation Algorithm ID definition [RFCXXXX]. 911 * Units of Measurement: See section 3.2.1, Calg Algorithm ID 912 definition[RFCXXXX]. 914 * Measurement Point(s) with Potential Measurement Domain: See 915 section 3, 2nd paragraph [RFCXXXX]. 917 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 918 measurement timing and section 3.1 [RFCXXXX] for Interval 919 Metric flag. 921 * Use and applications: See section 1.4 [RFCXXXX]. 923 * Reporting model: See RFC3611. 925 d. Payload Type Metric 927 * Metric Name: RTP Payload Type 929 * Metric Description: It is used to identify the format of the 930 RTP payload. For more details, see section 3.2.1, payload 931 type definition. 933 * Method of Measurement or Calculation: See section 3.2.1, 934 Payload type definition [RFCXXXX]. 936 * Units of Measurement: See section 3.2.1, payload type 937 definition[RFCXXXX]. 939 * Measurement Point(s) with Potential Measurement Domain: See 940 section 3, 2nd paragraph [RFCXXXX]. 942 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 943 measurement timing and section 3.1 [RFCXXXX] for Interval 944 Metric flag. 946 * Use and applications: See section 1.4 [RFCXXXX]. 948 * Reporting model: See RFC3611. 950 e. Channel Identifier Metric 952 * Metric Name: Audio Channel Identifier in RTP 954 * Metric Description: It is used to identify each audio channel 955 carried in the same RTP stream. For more details, see section 956 3.2.2, channel identifier definition. 958 * Method of Measurement or Calculation: See section 3.2.2, 959 Channel Identifier definition [RFCXXXX]. 961 * Units of Measurement: See section 3.2.2, channel identifier 962 definition[RFCXXXX]. 964 * Measurement Point(s) with Potential Measurement Domain: See 965 section 3, 2nd paragraph [RFCXXXX]. 967 * Measurement Timing: See section 3, 3rd paragraph [RFCXXXX] for 968 measurement timing and section 3.1 [RFCXXXX] for Interval 969 Metric flag. 971 * Use and applications: See section 1.4 [RFCXXXX]. 973 * Reporting model: See RFC3611. 975 Appendix B. Change Log 977 B.1. draft-ietf-xrblock-rtcp-xr-qoe-15 979 The following are the major changes compared to previous version: 980 o Some Editorial Changes. 982 B.2. draft-ietf-xrblock-rtcp-xr-qoe-14 984 The following are the major changes compared to previous version: 985 o Add some texts to address IESG review comments. 987 B.3. draft-ietf-xrblock-rtcp-xr-qoe-10 989 The following are the major changes compared to previous version: 990 o Replace QoE metrics with MoS metrics. 992 B.4. draft-ietf-xrblock-rtcp-xr-qoe-09 994 The following are the major changes compared to previous version: 995 o Address comments recieved from WGLC, PM-DIR Review and SDP review. 996 o Change an existing SDP attribute 'extmap' to new SDP attribute 997 'calgextmap' and add new SDP attribute registry. 998 o Add Reference to G.107.1, P.862.1, P.862.2 and P.863 for new 999 calculation algorithms. 1000 o Add MoS type attribute to distinguish different MoS type. 1001 o Other Editorial changes. 1003 B.5. draft-ietf-xrblock-rtcp-xr-qoe-08 1005 The following are the major changes compared to previous version: 1007 o Remove mostype attribute from SDP extension since it can inferred 1008 from payload type. 1009 o Clarify mosref attribute usage in the O/A. 1011 B.6. draft-ietf-xrblock-rtcp-xr-qoe-07 1013 The following are the major changes compared to previous version: 1014 o Some editorial changes to get in line with burst gap related 1015 draft. 1016 o Add an appendix to apply RFC6390 template. 1018 B.7. draft-ietf-xrblock-rtcp-xr-qoe-06 1020 The following are the major changes compared to previous two 1021 versions: 1022 o A few Contact information update. 1023 o A few Acknowledgement section update. 1025 B.8. draft-ietf-xrblock-rtcp-xr-qoe-04 1027 The following are the major changes compared to previous version: 1028 o Split two references P.NAMS and P.NBAMS into four references. 1029 o SDP signaling update. 1030 o Add one example to explain User QoE evaluation for video stream 1032 B.9. draft-ietf-xrblock-rtcp-xr-qoe-03 1034 The following are the major changes compared to previous version: 1035 o Add one new reference to support TTC JJ201.01. 1036 o Update two references P.NAMS and P.NBAMS. 1037 o Other Editorial changes based on comments applied to PDV and Delay 1038 drafts. 1040 B.10. draft-ietf-xrblock-rtcp-xr-qoe-02 1042 The following are the major changes compared to previous version: 1043 o Remove leftmost second bit since it is ueeless. 1044 o Change 13bits MoS value field into 14 bits to increase MoS 1045 precision. 1046 o Fix some typo and make some editorial changes. 1048 B.11. draft-ietf-xrblock-rtcp-xr-qoe-01 1050 The following are the major changes compared to previous version: 1051 o Remove layered support from the QoE Metric draft. 1052 o Allocate 7 bits in the block header for payload type to indicate 1053 what type of payload format is in use and add associated 1054 definition of payload type. 1056 o Clarify using Payload Type to determine the appropriate channel 1057 mapping in the definition of Channel Identifier. 1059 B.12. draft-ietf-xrblock-rtcp-xr-qoe-00 1061 The following are the major changes compared to previous version: 1062 o Allocate one more bit in the single channel per SSC segment to get 1063 alignment with the other two segment type. 1065 Authors' Addresses 1067 Alan Clark 1068 Telchemy Incorporated 1069 2905 Premiere Parkway, Suite 280 1070 Duluth, GA 30097 1071 USA 1073 Email: alan.d.clark@telchemy.com 1075 Qin Wu 1076 Huawei 1077 101 Software Avenue, Yuhua District 1078 Nanjing, Jiangsu 210012 1079 China 1081 Email: sunseawq@huawei.com 1083 Roland Schott 1084 Deutsche Telekom 1085 Heinrich-Hertz-Strasse 3-7 1086 Darmstadt 64295 1087 Germany 1089 Email: Roland.Schott@telekom.de 1090 Glen Zorn 1091 Network Zen 1092 77/440 Soi Phoomjit, Rama IV Road 1093 Phra Khanong, Khlong Toie 1094 Bangkok 10110 1095 Thailand 1097 Phone: +66 (0) 87 502 4274 1098 Email: gwz@net-zen.net