idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-qoe-00.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 2, 2012) is 4467 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Hunt 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track A. Clark 5 Expires: August 5, 2012 Telchemy 6 Q. Wu 7 Huawei 8 R. Schott 9 DT 10 G. Zorn 11 Network Zen 12 February 2, 2012 14 RTCP XR Blocks for QoE Metric Reporting 15 draft-ietf-xrblock-rtcp-xr-qoe-00 17 Abstract 19 This document defines an RTCP XR Report Block and associated SDP 20 parameters that allow the reporting of QoE metrics for use in a range 21 of RTP applications. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 5, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. QoE Metrics Report Block . . . . . . . . . . . . . . . . . 3 59 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 60 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 61 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 64 3. QoE Metrics Block . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 5 66 3.2. Definition of Fields in QoE Metrics Block . . . . . . . . 6 67 3.2.1. Single Stream per SSRC Segment . . . . . . . . . . . . 7 68 3.2.2. Multi-Layer per SSRC Segment . . . . . . . . . . . . . 9 69 3.2.3. Multi-Channel per SSRC Segment . . . . . . . . . . . . 10 70 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 12 73 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 12 74 5.3. Contact information for registrations . . . . . . . . . . 12 75 5.4. New registry of calculation algorithms for single 76 stream per SSRC segment . . . . . . . . . . . . . . . . . 12 77 5.5. New registry of calculation algorithms for multi-layer 78 per SSRC segment . . . . . . . . . . . . . . . . . . . . . 13 79 5.6. New registry of calculation algorithms for 80 multi-channel per SSRC segment . . . . . . . . . . . . . . 14 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 88 A.1. draft-ietf-xrblock-rtcp-xr-qoe-00 . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 1.1. QoE Metrics Report Block 95 This draft defines a new block type to augment those defined in 96 [RFC3611], for use in a range of RTP applications. 98 The new block type provides information on multimedia quality using 99 one of several standard metrics. 101 The metrics belong to the class of application level metrics defined 102 in [MONARCH] (work in progress). 104 1.2. RTCP and RTCP XR Reports 106 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 107 defined an extensible structure for reporting using an RTCP Extended 108 Report (XR). This draft defines a new Extended Report block that 109 MUST be used as defined in RFC3550 and RFC3611. 111 1.3. Performance Metrics Framework 113 The Performance Metrics Framework [PMOL] provides guidance on the 114 definition and specification of performance metrics. Metrics 115 described in this draft either reference external definitions or 116 define metrics generally in accordance with the guidelines in [PMOL]. 118 1.4. Applicability 120 The QoE Metrics Report Block can be used in any application of RTP 121 for which QoE measurement algorithms are defined. 123 The factors that affect real-time AV application quality can be split 124 into two categories. The first category consists of transport- 125 dependent factors such as packet loss, delay and jitter (which also 126 translates into losses in the playback buffer). The factors in the 127 second category are application-specific factors that affect real 128 time application (e.g., video) quality and are sensitivity to network 129 errors. These factors can be but not limited to video codec and loss 130 recovery technique, coding bit rate, packetization scheme, and 131 content characteristics. 133 Compared with application-specific factors, the transport-dependent 134 factors sometimes are not sufficient to measure real time data 135 quality, since the ability to analyze the real time data in the 136 application layer provides quantifiable measurements for subscriber 137 Quality of Experience (QoE) that may not be captured in the 138 transmission layers or from the RTP layer down. In a typical 139 scenario, monitoring of the transmission layers can produce 140 statistics suggesting that quality is not an issue, such as the fact 141 that network jitter is not excessive. However, problems may occur in 142 the service layers leading to poor subscriber QoE. Therefore 143 monitoring using only network-level measurements may be insufficient 144 when application layer content quality is required. 146 In order to provide accurate measures of real time application 147 quality when transporting real time contents across a network, the 148 synthentical multimedia quality Metrics is highly required which can 149 be conveyed in the RTCP XR packets[RFC3611] and may have the 150 following three benefits: 152 o Tuning the content encoder algorithm to satisfy real time data 153 quality requirements. 154 o Determining which system techniques to use in a given situation 155 and when to switch from one technique to another as system 156 parameters change. 157 o Verifying the continued correct operation of an existing system. 159 2. Terminology 161 2.1. Standards Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 The terminology used is 169 Numeric formats S X:Y 171 where S indicates a two's complement signed representation, X 172 the number of bits prior to the decimal place and Y the number 173 of bits after the decimal place. 174 Hence 8:8 represents an unsigned number in the range 0.0 to 175 255.996 with a granularity of 0.0039. S7:8 would represent the 176 range -127.996 to +127.996. 0:16 represents a proper binary 177 fraction with range 178 0.0 to 1 - 1/65536 = 0.9999847 179 though note that use of flag values at the top of the numeric 180 range slightly reduces this upper limit. For example, if the 181 16- bit values 0xfffe and 0xffff are used as flags for "over- 182 range" and "unavailable" conditions, a 0:16 quantity has range 183 0.0 to 1 - 3/65536 = 0.9999542 185 3. QoE Metrics Block 187 This block reports the multimedia application performance or quality 188 beyond the information carried in the standard RTCP packet format. 189 Information is recorded about multimedia application QoE metric which 190 provides a measure that is indicative of the user's view of a 191 service. Multimedia application QoE metric is commonly expressed as 192 a MOS ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 193 5 represents excellent and 1 represents unacceptable. MOS scores are 194 usually obtained using subjective testing or using objective 195 algorithm. However Subjective testing to estimate the multimedia 196 quality may be not suitable for measuring the multimedia quality 197 since the results may vary from test to test. Therefore using 198 objective algorithm to calculate MOS scores is recommended. ITU-T 199 recommendations define the methodologies for assessment of the 200 performance of multimedia stream 201 [G.107][P.564][G.1082][P.NAMS][P.NBAMS] and provides a method to 202 evaluate QoE estimation algorithms and objective model for video and 203 audio. Hence this document recommends vendors and implementers to 204 use these International Telecommunication Union (ITU)-specified 205 methodologies to measure parameters when possible. 207 3.1. Metric Block Structure 209 The report block contents are dependent upon a series of flag bits 210 carried in the first part of the header. Not all parameters need to 211 be reported in each block. Flags indicate which are and which are 212 not reported. The fields corresponding to unreported parameters MUST 213 be present, but are set to zero. The receiver MUST ignore any QoE 214 Metrics Block with a non-zero value in any field flagged as 215 unreported. The encoding of QoE metrics block payload consists of a 216 series of 32 bit units called segments that describe MOS Type, MoS 217 algorithm and MoS value. 219 The QoE Metrics Block has the following format: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | BT=TBD | I | Rsd | block length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | SSRC of source | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Segment 1 | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Segment 2 | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 .................. 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Segment n | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 3.2. Definition of Fields in QoE Metrics Block 239 Block type (BT): 8 bits 241 The QoE Metrics Block is identified by the constant . 243 Interval Metric flag (I): 2 bit 245 This field is used to indicate whether the Basic Loss/Discard 246 metrics are Interval or Cumulative metrics, that is, whether the 247 reported values applies to the most recent measurement interval 248 duration between successive metrics reports (I=01) (the Interval 249 Duration) or to the accumulation period characteristic of 250 cumulative measurements (I=00) (the Cumulative Duration) or to the 251 value of a continuously measured or calculated that has been 252 sampled at end of the interval (I=10) (Sampled Value). 254 Rsd.:6 bits 256 This field is reserved for future definition. In the absence of 257 such a definition, the bits in this field MUST be set to zero and 258 MUST be ignored by the receiver. 260 Block Length: 16 bits 262 The length of this report block in 32-bit words, minus one. For 263 the QoE Metrics Block, the block length is variable length. 265 SSRC of source: 32 bits 267 As defined in Section 4.1 of [RFC3611]. 269 Segment i: 32 bits 271 There are three segment types : single stream per SSRC segment, 272 multi-channel audio per SSRC segment, multi-layer per SSRC 273 segment. Multi-channel per SSRC segment and multi-layer per SSRC 274 segment are used to deal with the case where multiple elementary 275 streams or components are carried in one RTP stream while single 276 stream per SSRC segment is used to deal with the case where there 277 is no more than one elementary stream or component in one RTP 278 stream. The left two bits of the section determine its type. If 279 the leftmost bit of the segment is zero, then it is single stream 280 segment. If the leftmost bit is one and the second bit is zero, 281 then it is multi-channel audio segment, if the leftmost bit is one 282 and the second bit is one, then it is multi- view segment. Note 283 that in these three segment type,any two segment types can not be 284 present in the same metric block. 286 3.2.1. Single Stream per SSRC Segment 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |0|R| MT |CAlg | Rsv. | MOS Value | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Segment Type ( S): 1 bit 294 A zero identifies this as a single stream segment. Single stream 295 means there is only one elementary stream carried in one RTP 296 stream. The single stream segment can be used to report the MoS 297 value associated with this elementary stream. If there are 298 multiple streams and they want to use the single stream segment to 299 report the MOS value, they should be carried in the separate RTP 300 streams with different SSRC. In this case, multiple QoE Metrics 301 Blocks are required to report the MOS value corresponding to each 302 stream using single stream segment. 304 Reserved (R): 1bit 306 The bit in this field is reserved. It MUST be set to zero and 307 MUST be ignored by the receiver if the leftmost bit of Single 308 Stream Per SSRC Segment is set to 0. 310 MoS Type (MT): 4 bits 312 This field is used to indicate the MOS type to be reported. The 313 MOS type is defined as follows: 315 0000 MOS-LQ - Listening Quality MoS. 316 0001 MOS-CQ - Conversation Quality MoS. 317 0010 MOS-A - Audio Quality MOS. 318 0010 MOS-V - Video Quality MOS. 319 0011 MOS-AV - Audio-Video Quality MOS. 320 0100~1111 - Reserved for future definitions. 322 MoS-LQ measures the quality of audio for listening purposes only 323 while MoS-CQ measures the quality of audio for conversation 324 purpose only. MoS-A,MoS-V and MoS-AV measures the quality of 325 audio application, the quality of video application and Audio- 326 Video application respectively. Both MoS-LQ and MoS-CQ are 327 commonly used in VoIP applications. MOS-LQ uses either wideband 328 audio codec or narrowband audio codec, or both and does not take 329 into account any of bidirectional effects, such as delay and echo. 330 MOS-CQ uses narrowband codec and takes into account listening 331 quality in each direction, as well as the bidirectional effects. 332 G.107 and P.564 and ETSI TS101 329-5 specify three MoS algorithms 333 that are used to estimate speech quality or conversation quality. 334 P.NAMS and P.NBAMS specify two MoS algorithms that are used to 335 estimate multimedia quality including video quality, audio quality 336 and audio-video quality. If MoS type is MoS-LQ and MoS-CQ, the 337 MoS value can be calculated based on ITU-T G.107[G.107], ITU-T 338 P.564 [P.564]or ETSI TS 101 329-5 [ETSI], if the Mos type is MoS-V 339 or MoS-AV, the Mos value can be calculated based on ITU-T P.NAMS 340 [P.NAMS]or ITU-T P.NBAMS [P.NBAMS]. If new MOS types are defined, 341 they can be added by an update to this document. If the receiver 342 does not understand the MOS type defined in this document it 343 should discard this report. If MoS Type does not match the MoS 344 algorithm in the report (e.g., specify a voice MOS algorithm for a 345 video quality MOS), the receiver should also discard this report. 347 Calculation Algorithm (CALg):3 bits 349 000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice) 350 001 - G.107 [G.107] (Voice) 351 010 - ETSI TS 101 329-5 Annex E [ ETSI] (Voice) 352 011 - ITU-T P.NAMS [P.NAMS] (Multimedia) 353 100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia) 354 101~111 - Reserved for future extension. 356 Rsd.:7 bits 358 This field is reserved for future definition. In the absence of 359 such a definition, the bits in this field MUST be set to zero and 360 MUST be ignored by the receiver. 362 MOS Value: 16 bits 364 The estimated mean opinion score for multimedia application 365 quality is defined as including the effects of delay,loss, 366 discard,jitter and other effects that would affect multimedia 367 quality . It is expressed in numeric format 8:8 with the value in 368 the range 0.0 to 255.996. The valid the measured value ranges 369 from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the 370 measured value is over ranged, the value 0xFFFE SHOULD be reported 371 to indicate an over-range measurement. If the measurement is 372 unavailable, the value 0xFFFF SHOULD be reported. Values other 373 than 0xFFFE,0xFFFF and the valid range defined above MUST NOT be 374 sent and MUST be ignored by the receiving system. 376 3.2.2. Multi-Layer per SSRC Segment 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |1|1| MT |CAlg | SSID |Rsv| MOS Value | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Segment Type ( S): 1 bit 384 A one identifies this as either a multi-channel segment or multi- 385 layer segment. 387 Media Type (M): 1bit 389 A one identifies this as a multi-layer video segment. 391 MoS Type (MT): 4 bits 393 As defined in Section 3.2.1 of this document. If the value of 394 this field is not for MoS-V, the receiver using multi-layer 395 segment should discard this invalid segment with the wrong MoS 396 Type. 398 Calculation Algorithm (CALg):3 bits 400 000~010 - Reserved. 401 011 - ITU-T P.NAMS [P.NAMS] (Multimedia). 402 100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia). 403 101~111 - Reserved for future extension. 405 Sub Stream Identifier (SSID): 5 bits 407 If multiple layers of video are carried in the same RTP stream, 408 each layer will be viewed as a sub stream. Specially, If multiple 409 views of video are carried in the same RTP stream, each view will 410 be viewed as a sub stream. This field is used to identify each 411 layer of video that is carried in the same media stream. NAL unit 412 type is one example of such SSID. 414 (Editor's Note: It's not sufficient to simply say that a "NAL unit 415 type is one example", the draft needs to give normative rules for 416 the use of this field) 418 Rsd.:2 bits 420 This field is reserved for future definition. In the absence of 421 such a definition, the bits in this field MUST be set to zero and 422 MUST be ignored by the receiver. 424 MOS Value: 16 bits 426 As defined in Section 3.2.1 of this document. 428 3.2.3. Multi-Channel per SSRC Segment 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |1|0| MT |CAlg | CHID | Rsv.| MOS Value | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Segement Type ( S): 1 bit 436 A one identifies this as either a multi-channel segment or multi- 437 layer segment. 439 Media Type (M): 1bit 441 A zero identifies this as a multi-channel per SSRC segment. 443 MoS Type (MT): 4 bits 445 As defined in Section 3.2.1 of this document. If the value of 446 this field is not for MoS-CQ or MoS-LQ, the receiver using multi- 447 channel segment should discard this invalid segment with the wrong 448 MoS Type. 450 Calculation Algorithm (CALg):3 bits 452 000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice) 453 001 - G.107 [G.107] (Voice) 454 010 - ETSI TS 101 329-5 Annex E, [ ETSI] (Voice) 455 011~100 - Reserved. 456 101~111 - Reserved for future extension. 458 Channel Identifier (CHID): 4 bits 460 This field is used to identify each channel that is carried in the 461 same media stream. If multiple channels of audio are carried in 462 one RTP stream, each channel of audio will be viewed as a 463 independent channel(e.g., left channel audio, right channel 464 audio). Channel mapping follows static ordering rule described in 465 the section 4.1 of [RFC3551]. 467 (Editor's Note: It is not clear that the channel mapping in RFC 468 3551 Section 4.1 is the only one in use) 470 Rsd.:3 bits 472 This field is reserved for future definition. In the absence of 473 such a definition, the bits in this field MUST be set to zero and 474 MUST be ignored by the receiver. 476 MOS Value: 16 bits 478 As defined in Section 3.2.1 of this document. 480 4. SDP Signaling 482 One new parameter is defined for the report block defined in this 483 document to be used with Session Description Protocol (SDP) [RFC4566] 484 using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the 485 following syntax within the "rtcp-xr" attribute [RFC3611]: 487 rtcp-xr-attrib = "a=rtcp-xr:" 488 [xr-format *(SP xr-format)] CRLF 489 xr-format = qoe-metrics 490 qoe-metrics = "multimedia-quality-metrics" 492 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 493 and the full syntax of the "rtcp-xr" attribute. 495 5. IANA Considerations 497 New block types for RTCP XR are subject to IANA registration. For 498 general guidelines on IANA considerations for RTCP XR, refer to 499 [RFC3611]. 501 5.1. New RTCP XR Block Type value 503 This document assigns the block type value NDEL in the IANA "RTCP XR 504 Block Type Registry" to the "QoE Metrics Block". 506 [Note to RFC Editor: please replace SMQ with the IANA provided RTCP 507 XR block type for this block.] 509 5.2. New RTCP XR SDP Parameter 511 This document also registers a new parameter "qoe-metrics" in the 512 "RTCP XR SDP Parameters Registry". 514 5.3. Contact information for registrations 516 The contact information for the registrations is: 518 Qin Wu 519 sunseawq@huawei.com 520 101 Software Avenue, Yuhua District 521 Nanjing, JiangSu 210012 China 523 5.4. New registry of calculation algorithms for single stream per SSRC 524 segment 526 This document creates a new registry for single stream per SSRC 527 segment defined in the section 3.2.1 to be called "RTCP XR QoE metric 528 block - multimedia application Calculation Algorithm" as a sub- 529 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 530 Block Type Registry". This registry applies to the multimedia 531 session where each type of media are sent in a separate RTP stream. 532 Specially this registry also applies to the layered video session 533 where each layer video are sent in a separate RTP stream. Policies 534 for this new registry are as follows: 536 o The information required to support this assignment is an 537 unambiguous definition of the new metric, covering the base 538 measurements and how they are processed to generate the reported 539 metric. This should include the units of measurement, how values 540 of the metric are reported in the one 16-bit fields "MoS Value". 541 o The review process for the registry is "Specification Required" as 542 described in Section 4.1 of [RFC5226]. 543 o Entries in the registry are integers. The valid range is 0 to 7 544 corresponding to the 3-bit field "CAlg" in the block. Values are 545 to be recorded in decimal. 547 o Initial assignments are as follows: 549 1. ITU-T P.564 Compliant Algorithm [P.564] (Voice) 550 2. G.107 [G.107] (Voice) 551 3. ETSI TS 101 329-5 Annex E [ ETSI] (Voice) 552 4. ITU-T P.NAMS [P.NAMS] (Multimedia) 553 5. ITU-T P.NBAMS [P.NBAMS] (Multimedia) 555 5.5. New registry of calculation algorithms for multi-layer per SSRC 556 segment 558 This document creates a new registry for multi-layer per SSRC segment 559 defined in the section 3.2.2 to be called "RTCP XR QoE metric block - 560 layered application Calculation Algorithm" as a sub-registry of the 561 "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" 562 if multi-layer video are carried in the same RTP stream. Policies 563 for this new registry are as follows: 565 o The information required to support this assignment is an 566 unambiguous definition of the new metric, covering the base 567 measurements and how they are processed to generate the reported 568 metric. This should include the units of measurement, how values 569 of the metric are reported in the one 16-bit fields "MoS Value". 570 o The review process for the registry is "Specification Required" as 571 described in Section 4.1 of [RFC5226]. 572 o Entries in the registry are integers. The valid range is 0 to 7 573 corresponding to the 3-bit field "CAlg" in the block. Values are 574 to be recorded in decimal. 575 o Initial assignments are as follows: 577 1. ITU-T P.NAMS [P.NAMS] (Multimedia) 578 2. ITU-T P.NBAMS [P.NBAMS] (Multimedia) 580 5.6. New registry of calculation algorithms for multi-channel per SSRC 581 segment 583 This document creates a new registry for multi-channel per SSRC 584 segment defined in the section 3.2.3 to be called "RTCP XR QoE metric 585 block - multi-channel application Calculation Algorithm" as a sub- 586 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 587 Block Type Registry" if multi-channel voice data are carried in the 588 same RTP stream. Policies for this new registry are as follows: 590 o The information required to support this assignment is an 591 unambiguous definition of the new metric, covering the base 592 measurements and how they are processed to generate the reported 593 metric. This should include the units of measurement, how values 594 of the metric are reported in the one 16-bit fields "MoS Value". 595 o The review process for the registry is "Specification Required" as 596 described in Section 4.1 of [RFC5226]. 597 o Entries in the registry are integers. The valid range is 0 to 7 598 corresponding to the 3-bit field "CAlg" in the block. Values are 599 to be recorded in decimal. 600 o Initial assignments are as follows: 602 1. ITU-T P.564 Compliant Algorithm [P.564] (Voice) 603 2. G.107 [G.107] (Voice) 604 3. ETSI TS 101 329-5 Annex E [ ETSI] (Voice) 606 6. Security Considerations 608 The new RTCP XR report blocks proposed in this document introduces no 609 new security considerations beyond those described in [RFC3611]. 611 7. Authors 613 This draft merges ideas from two different drafts addressing the QoE 614 metric Reporting issue. The authors of these drafts are listed below 615 (in alphabetical order) : 616 Alan Clark < alan.d.clark@telchemy.com > 617 Geoff Hunt < r.geoff.hunt@gmail.com > 618 Martin Kastner < martin.kastner@telchemy.com > 619 Kai Lee < leekai@ctbri.com.cn > 620 Roland Schott < roland.schott@telekom.de > 621 Qin Wu < sunseawq@huawei.com > 622 Glen Zorn < gwz@net-zen.net > 624 8. Acknowledgements 626 The authors would like to thank Alan Clark, Bill Ver Steeg, David R 627 Oran, Ali Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and 628 Yinliang Hu for their valuable comments and suggestions on this 629 document. 631 9. References 633 9.1. Normative References 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", BCP 14, RFC 2119, March 1997. 638 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 639 Applications", RFC 3550, July 2003. 641 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 642 Video Conferences with Minimal Control", RFC 3551, 643 July 2003. 645 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 646 Protocol Extended Reports (RTCP XR)", RFC 3611, 647 November 2003. 649 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 650 Description Protocol", RFC 4566, July 2006. 652 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 653 Section in RFCs", RFC 5226, May 2008. 655 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 656 Specifications: ABNF", STD 68, RFC 5234, January 2008. 658 9.2. Informative References 660 [ETSI] ETSI, "Quality of Service (QoS) measurement 661 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 663 [G.107] ITU-T, "The E Model, a computational model for use in 664 transmission planning", ITU-T Recommendation G.107, 665 April 2009. 667 [G.1082] ITU-T, "Measurement-based methods for improving the 668 robustness of IPTV performance", ITU-T 669 Recommendation G.1082, April 2009. 671 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 672 ID draft-ietf-avtcore-monarch-00, April 2011. 674 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 675 transmission quality assessment models", ITU-T 676 Recommendation P.564, July 2006. 678 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 679 of performance of Multimedia Streaming", ITU-T 680 Recommendation P.NAMS, November 2009. 682 [P.NBAMS] ITU-T, "non-intrusive bit-stream model for assessment of 683 performance of multimedia streaming", ITU-T 684 Recommendation P.NBAMS, November 2009. 686 [PMOL] Clark, A. and B. Claise, "Framework for Performance Metric 687 Development", ID draft-ietf-pmol-metrics-framework-12, 688 July 2011. 690 Appendix A. Change Log 692 A.1. draft-ietf-xrblock-rtcp-xr-qoe-00 694 The following are the major changes compared to previous version: 695 o Allocate one more bit in the single stream per SSC segment to get 696 alignment with the other two segment type. 698 Authors' Addresses 700 Geoff Hunt 701 Unaffiliated 703 Email: r.geoff.hunt@gmail.com 705 Alan Clark 706 Telchemy Incorporated 707 2905 Premiere Parkway, Suite 280 708 Duluth, GA 30097 709 USA 711 Email: alan.d.clark@telchemy.com 712 Qin Wu 713 Huawei 714 101 Software Avenue, Yuhua District 715 Nanjing, Jiangsu 210012 716 China 718 Email: sunseawq@huawei.com 720 Roland Schott 721 Deutsche Telekom Laboratories 722 Deutsche-Telekom-Allee 7 723 Darmstadt 64295 724 Germany 726 Email: Roland.Schott@telekom.de 728 Glen Zorn 729 Network Zen 730 77/440 Soi Phoomjit, Rama IV Road 731 Phra Khanong, Khlong Toie 732 Bangkok 10110 733 Thailand 735 Phone: +66 (0) 87 502 4274 736 Email: gwz@net-zen.net