idnits 2.17.00 (12 Aug 2021) /tmp/idnits40063/draft-wu-xrblock-rtcp-xr-quality-monitoring-08.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 (December 31, 2011) is 3787 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: draft-ietf-avtcore-monarch has been published as RFC 6792 == Outdated reference: draft-ietf-pmol-metrics-framework has been published as RFC 6390 Summary: 2 errors (**), 0 flaws (~~), 3 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: July 3, 2012 Telchemy 6 Q. Wu 7 Huawei 8 R. Schott 9 DT 10 G. Zorn 11 Network Zen 12 December 31, 2011 14 RTCP XR Blocks for QoE metric reporting 15 draft-wu-xrblock-rtcp-xr-quality-monitoring-08 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 July 3, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . 13 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 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-wu-xrblock-rtcp-xr-quality-monitoring-03 . . . . . . 16 89 A.2. draft-wu-xrblock-rtcp-xr-quality-monitoring-04 . . . . . . 16 90 A.3. draft-wu-xrblock-rtcp-xr-quality-monitoring-05 . . . . . . 16 91 A.4. draft-wu-xrblock-rtcp-xr-quality-monitoring-06 . . . . . . 17 92 A.5. draft-wu-xrblock-rtcp-xr-quality-monitoring-07 . . . . . . 17 93 A.6. draft-wu-xrblock-rtcp-xr-quality-monitoring-08 . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 1.1. QoE Metrics Report Block 100 This draft defines a new block type to augment those defined in 101 [RFC3611], for use in a range of RTP applications. 103 The new block type provides information on multimedia quality using 104 one of several standard metrics. 106 The metrics belong to the class of application level metrics defined 107 in [MONARCH] (work in progress). 109 1.2. RTCP and RTCP XR Reports 111 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 112 defined an extensible structure for reporting using an RTCP Extended 113 Report (XR). This draft defines a new Extended Report block that 114 MUST be used as defined in RFC3550 and RFC3611. 116 1.3. Performance Metrics Framework 118 The Performance Metrics Framework [PMOL] provides guidance on the 119 definition and specification of performance metrics. Metrics 120 described in this draft either reference external definitions or 121 define metrics generally in accordance with the guidelines in [PMOL]. 123 1.4. Applicability 125 The QoE Metrics Report Block can be used in any application of RTP 126 for which QoE measurement algorithms are defined. 128 The factors that affect real-time AV application quality can be split 129 into two categories. The first category consists of transport- 130 dependent factors such as packet loss, delay and jitter (which also 131 translates into losses in the playback buffer). The factors in the 132 second category are application-specific factors that affect real 133 time application (e.g., video) quality and are sensitivity to network 134 errors. These factors can be but not limited to video codec and loss 135 recovery technique, coding bit rate, packetization scheme, and 136 content characteristics. 138 Compared with application-specific factors, the transport-dependent 139 factors sometimes are not sufficient to measure real time data 140 quality, since the ability to analyze the real time data in the 141 application layer provides quantifiable measurements for subscriber 142 Quality of Experience (QoE) that may not be captured in the 143 transmission layers or from the RTP layer down. In a typical 144 scenario, monitoring of the transmission layers can produce 145 statistics suggesting that quality is not an issue, such as the fact 146 that network jitter is not excessive. However, problems may occur in 147 the service layers leading to poor subscriber QoE. Therefore 148 monitoring using only network-level measurements may be insufficient 149 when application layer content quality is required. 151 In order to provide accurate measures of real time application 152 quality when transporting real time contents across a network, the 153 synthentical multimedia quality Metrics is highly required which can 154 be conveyed in the RTCP XR packets[RFC3611] and may have the 155 following three benefits: 157 o Tuning the content encoder algorithm to satisfy real time data 158 quality requirements. 159 o Determining which system techniques to use in a given situation 160 and when to switch from one technique to another as system 161 parameters change. 162 o Verifying the continued correct operation of an existing system. 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 S X:Y 176 where S indicates a two's complement signed representation, X 177 the number of bits prior to the decimal place and Y the number 178 of bits after the decimal place. 179 Hence 8:8 represents an unsigned number in the range 0.0 to 180 255.996 with a granularity of 0.0039. S7:8 would represent the 181 range -127.996 to +127.996. 0:16 represents a proper binary 182 fraction with range 183 0.0 to 1 - 1/65536 = 0.9999847 184 though note that use of flag values at the top of the numeric 185 range slightly reduces this upper limit. For example, if the 186 16- bit values 0xfffe and 0xffff are used as flags for "over- 187 range" and "unavailable" conditions, a 0:16 quantity has range 188 0.0 to 1 - 3/65536 = 0.9999542 190 3. QoE Metrics Block 192 This block reports the multimedia application performance or quality 193 beyond the information carried in the standard RTCP packet format. 194 Information is recorded about multimedia application QoE metric which 195 provides a measure that is indicative of the user's view of a 196 service. Multimedia application QoE metric is commonly expressed as 197 a MOS ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 198 5 represents excellent and 1 represents unacceptable. MOS scores are 199 usually obtained using subjective testing or using objective 200 algorithm. However Subjective testing to estimate the multimedia 201 quality may be not suitable for measuring the multimedia quality 202 since the results may vary from test to test. Therefore using 203 objective algorithm to calculate MOS scores is recommended. ITU-T 204 recommendations define the methodologies for assessment of the 205 performance of multimedia stream 206 [G.107][P.564][G.1082][P.NAMS][P.NBAMS] and provides a method to 207 evaluate QoE estimation algorithms and objective model for video and 208 audio. Hence this document recommends vendors and implementers to 209 use these International Telecommunication Union (ITU)-specified 210 methodologies to measure parameters when possible. 212 3.1. Metric Block Structure 214 The report block contents are dependent upon a series of flag bits 215 carried in the first part of the header. Not all parameters need to 216 be reported in each block. Flags indicate which are and which are 217 not reported. The fields corresponding to unreported parameters MUST 218 be present, but are set to zero. The receiver MUST ignore any QoE 219 Metrics Block with a non-zero value in any field flagged as 220 unreported. The encoding of QoE metrics block payload consists of a 221 series of 32 bit units called segments that describe MOS Type, MoS 222 algorithm and MoS value. 224 The QoE Metrics Block has the following format: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | BT=TBD | I | Rsd | block length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | SSRC of source | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Segment 1 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Segment 2 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 .................. 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Segment n | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 3.2. Definition of Fields in QoE Metrics Block 244 Block type (BT): 8 bits 246 The QoE Metrics Block is identified by the constant . 248 Interval Metric flag (I): 2 bit 250 This field is used to indicate whether the Basic Loss/Discard 251 metrics are Interval or Cumulative metrics, that is, whether the 252 reported values applies to the most recent measurement interval 253 duration between successive metrics reports (I=01) (the Interval 254 Duration) or to the accumulation period characteristic of 255 cumulative measurements (I=00) (the Cumulative Duration) or to the 256 value of a continuously measured or calculated that has been 257 sampled at end of the interval (I=10) (Sampled Value). 259 Rsd.:6 bits 261 This field is reserved for future definition. In the absence of 262 such a definition, the bits in this field MUST be set to zero and 263 MUST be ignored by the receiver. 265 Block Length: 16 bits 267 The length of this report block in 32-bit words, minus one. For 268 the QoE Metrics Block, the block length is variable length. 270 SSRC of source: 32 bits 272 As defined in Section 4.1 of [RFC3611]. 274 Segment i: 32 bits 276 There are three segment types : single stream per SSRC segment, 277 multi-channel audio per SSRC segment, multi-layer per SSRC 278 segment. Multi-channel per SSRC segment and multi-layer per SSRC 279 segment are used to deal with the case where multiple elementary 280 streams or components are carried in one RTP stream while single 281 stream per SSRC segment is used to deal with the case where there 282 is no more than one elementary stream or component in one RTP 283 stream. The left two bits of the section determine its type. If 284 the leftmost bit of the segment is zero, then it is single stream 285 segment. If the leftmost bit is one and the second bit is zero, 286 then it is multi-channel audio segment, if the leftmost bit is one 287 and the second bit is one, then it is multi- view segment. Note 288 that in these three segment type,any two segment types can not be 289 present in the same metric block. 291 3.2.1. Single Stream per SSRC Segment 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |0| MT |CAlg | Rsv. | MOS Value | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Segment Type ( S): 1 bit 299 A zero identifies this as a single stream segment. Single stream 300 means there is only one elementary stream carried in one RTP 301 stream. The single stream segment can be used to report the MoS 302 value associated with this elementary stream. If there are 303 multiple streams and they want to use the single stream segment to 304 report the MOS value, they should be carried in the separate RTP 305 streams with different SSRC. In this case, multiple QoE Metrics 306 Blocks are required to report the MOS value corresponding to each 307 stream using single stream segment. 309 MoS Type (MT): 4 bits 311 This field is used to indicate the MOS type to be reported. The 312 MOS type is defined as follows: 314 0000 MOS-LQ - Listening Quality MoS. 315 0001 MOS-CQ - Conversation Quality MoS. 316 0010 MOS-A - Audio Quality MOS. 317 0010 MOS-V - Video Quality MOS. 318 0011 MOS-AV - Audio-Video Quality MOS. 319 0100~1111 - Reserved for future definitions. 321 MoS-LQ measures the quality of audio for listening purposes only 322 while MoS-CQ measures the quality of audio for conversation 323 purpose only. MoS-A,MoS-V and MoS-AV measures the quality of 324 audio application, the quality of video application and Audio- 325 Video application respectively. Both MoS-LQ and MoS-CQ are 326 commonly used in VoIP applications. MOS-LQ uses either wideband 327 audio codec or narrowband audio codec, or both and does not take 328 into account any of bidirectional effects, such as delay and echo. 329 MOS-CQ uses narrowband codec and takes into account listening 330 quality in each direction, as well as the bidirectional effects. 331 G.107 and P.564 and ETSI TS101 329-5 specify three MoS algorithms 332 that are used to estimate speech quality or conversation quality. 333 P.NAMS and P.NBAMS specify two MoS algorithms that are used to 334 estimate multimedia quality including video quality, audio quality 335 and audio-video quality. If MoS type is MoS-LQ and MoS-CQ, the 336 MoS value can be calculated based on ITU-T G.107[G.107], ITU-T 337 P.564 [P.564]or ETSI TS 101 329-5 [ETSI], if the Mos type is MoS-V 338 or MoS-AV, the Mos value can be calculated based on ITU-T P.NAMS 339 [P.NAMS]or ITU-T P.NBAMS [P.NBAMS]. If new MOS types are defined, 340 they can be added by an update to this document. If the receiver 341 does not understand the MOS type defined in this document it 342 should discard this report. If MoS Type does not match the MoS 343 algorithm in the report (e.g., specify a voice MOS algorithm for a 344 video quality MOS), the receiver should also discard this report. 346 Calculation Algorithm (CALg):3 bits 348 000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice) 349 001 - G.107 [G.107] (Voice) 350 010 - ETSI TS 101 329-5 Annex E [ ETSI] (Voice) 351 011 - ITU-T P.NAMS [P.NAMS] (Multimedia) 352 100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia) 353 101~111 - Reserved for future extension. 355 Rsd.:8 bits 357 This field is reserved for future definition. In the absence of 358 such a definition, the bits in this field MUST be set to zero and 359 MUST be ignored by the receiver. 361 MOS Value: 16 bits 363 The estimated mean opinion score for multimedia application 364 quality is defined as including the effects of delay,loss, 365 discard,jitter and other effects that would affect multimedia 366 quality . It is expressed in numeric format 8:8 with the value in 367 the range 0.0 to 255.996. The valid the measured value ranges 368 from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the 369 measured value is over ranged, the value 0xFFFE SHOULD be reported 370 to indicate an over-range measurement. If the measurement is 371 unavailable, the value 0xFFFF SHOULD be reported. Values other 372 than 0xFFFE,0xFFFF and the valid range defined above MUST NOT be 373 sent and MUST be ignored by the receiving system. 375 3.2.2. Multi-Layer per SSRC Segment 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |1|1| MT |CAlg | SSID |Rsv| MOS Value | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Segment Type ( S): 1 bit 383 A one identifies this as either a multi-channel segment or multi- 384 layer segment. 386 Media Type (M): 1bit 388 A one identifies this as a multi-layer video segment. 390 MoS Type (MT): 4 bits 392 As defined in Section 3.2.1 of this document. If the value of 393 this field is not for MoS-V, the receiver using multi-layer 394 segment should discard this invalid segment with the wrong MoS 395 Type. 397 Calculation Algorithm (CALg):3 bits 399 000~010 - Reserved. 400 011 - ITU-T P.NAMS [P.NAMS] (Multimedia). 401 100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia). 402 101~111 - Reserved for future extension. 404 Sub Stream Identifier (SSID): 5 bits 406 If multiple layers of video are carried in the same RTP stream, 407 each layer will be viewed as a sub stream. Specially, If multiple 408 views of video are carried in the same RTP stream, each view will 409 be viewed as a sub stream. This field is used to identify each 410 layer of video that is carried in the same media stream. NAL unit 411 type is one example of such SSID. 413 (Editor's Note: It's not sufficient to simply say that a "NAL unit 414 type is one example", the draft needs to give normative rules for 415 the use of this field) 417 Rsd.:2 bits 419 This field is reserved for future definition. In the absence of 420 such a definition, the bits in this field MUST be set to zero and 421 MUST be ignored by the receiver. 423 MOS Value: 16 bits 425 As defined in Section 3.2.1 of this document. 427 3.2.3. Multi-Channel per SSRC Segment 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |1|0| MT |CAlg | CHID | Rsv.| MOS Value | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Segement Type ( S): 1 bit 435 A one identifies this as either a multi-channel segment or multi- 436 layer segment. 438 Media Type (M): 1bit 440 A zero identifies this as a multi-channel per SSRC segment. 442 MoS Type (MT): 4 bits 444 As defined in Section 3.2.1 of this document. If the value of 445 this field is not for MoS-CQ or MoS-LQ, the receiver using multi- 446 channel segment should discard this invalid segment with the wrong 447 MoS Type. 449 Calculation Algorithm (CALg):3 bits 451 000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice) 452 001 - G.107 [G.107] (Voice) 453 010 - ETSI TS 101 329-5 Annex E, [ ETSI] (Voice) 454 011~100 - Reserved. 455 101~111 - Reserved for future extension. 457 Channel Identifier (CHID): 4 bits 459 This field is used to identify each channel that is carried in the 460 same media stream. If multiple channels of audio are carried in 461 one RTP stream, each channel of audio will be viewed as a 462 independent channel(e.g., left channel audio, right channel 463 audio). Channel mapping follows static ordering rule described in 464 the section 4.1 of [RFC3551]. 466 (Editor's Note: It is not clear that the channel mapping in RFC 467 3551 Section 4.1 is the only one in use) 469 Rsd.:3 bits 471 This field is reserved for future definition. In the absence of 472 such a definition, the bits in this field MUST be set to zero and 473 MUST be ignored by the receiver. 475 MOS Value: 16 bits 477 As defined in Section 3.2.1 of this document. 479 4. SDP Signaling 481 One new parameter is defined for the report block defined in this 482 document to be used with Session Description Protocol (SDP) [RFC4566] 483 using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the 484 following syntax within the "rtcp-xr" attribute [RFC3611]: 486 rtcp-xr-attrib = "a=rtcp-xr:" 487 [xr-format *(SP xr-format)] CRLF 488 xr-format = qoe-metrics 489 qoe-metrics = "multimedia-quality-metrics" 491 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 492 and the full syntax of the "rtcp-xr" attribute. 494 5. IANA Considerations 496 New block types for RTCP XR are subject to IANA registration. For 497 general guidelines on IANA considerations for RTCP XR, refer to 498 [RFC3611]. 500 5.1. New RTCP XR Block Type value 502 This document assigns the block type value NDEL in the IANA "RTCP XR 503 Block Type Registry" to the "QoE Metrics Block". 505 [Note to RFC Editor: please replace SMQ with the IANA provided RTCP 506 XR block type for this block.] 508 5.2. New RTCP XR SDP Parameter 510 This document also registers a new parameter "qoe-metrics" in the 511 "RTCP XR SDP Parameters Registry". 513 5.3. Contact information for registrations 515 The contact information for the registrations is: 517 Qin Wu 518 sunseawq@huawei.com 519 101 Software Avenue, Yuhua District 520 Nanjing, JiangSu 210012 China 522 5.4. New registry of calculation algorithms for single stream per SSRC 523 segment 525 This document creates a new registry for single stream per SSRC 526 segment defined in the section 3.2.1 to be called "RTCP XR QoE metric 527 block - multimedia application Calculation Algorithm" as a sub- 528 registry of the "RTP Control Protocol Extended Reports (RTCP XR) 529 Block Type Registry". This registry applies to the multimedia 530 session where each type of media are sent in a separate RTP stream. 531 Specially this registry also applies to the layered video session 532 where each layer video are sent in a separate RTP stream. Policies 533 for this new registry are as follows: 535 o The information required to support this assignment is an 536 unambiguous definition of the new metric, covering the base 537 measurements and how they are processed to generate the reported 538 metric. This should include the units of measurement, how values 539 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-wu-xrblock-rtcp-xr-quality-monitoring-03 694 The following are the major changes compared to previous version 02: 695 o Remove the tag field. 696 o Define MOS Value field as 32 bits integer value field. 697 o Clear unused references. 698 o Add text to MOS type field for clarification. 699 o Other Editorial changes. 701 A.2. draft-wu-xrblock-rtcp-xr-quality-monitoring-04 703 The following are the major changes compared to previous version 03: 704 o Add Numeric format definition and express the MoS-Value in Numeric 705 format. 706 o Change 32bits MoS Value into 16bits MoS Value. 707 o Add some text to MoS Type definition to clarify the algorithm 708 calculation. 709 o Separate MoS-A into MoS-LQ and MoS-CQ and add some text to clarify 710 the difference between them. 711 o Add one more reference for MoS-LQ and MoS-CQ value calculation. 712 o Other Editorial changes. 714 A.3. draft-wu-xrblock-rtcp-xr-quality-monitoring-05 716 The following are the major changes compared to previous version 04: 717 o Merge this draft with Clack's draft 718 o Define three segment types to distinguish multiple elementary 719 stream carried in the same RTP stream from multiple elementary 720 stream carried in each different RTP stream 721 o Allocate 3 bit for MOS calculation algorithms in each segment. 722 o Allocate or move 4 bit for MOS Type to each segment 723 o Other Editorial changes. 725 A.4. draft-wu-xrblock-rtcp-xr-quality-monitoring-06 727 The following are the major changes compared to previous version 05: 728 o Specify how sub-streams are identified. 729 o Change multi-view segment into multi-layer segment. 730 o Move MoS Type field before Calg field. 731 o Provide guidance on how new calculation algorithms can be 732 registered 733 o Define the channel mapping algorithm for multi-channel segment 735 A.5. draft-wu-xrblock-rtcp-xr-quality-monitoring-07 737 The following are the major changes compared to previous version 05: 738 o Add MoS-A as one new MoS Type to distinguish from MoS-LQ and 739 MoS-CQ. 740 o Add guidance on which algorithm is appropriate for which MOS type. 741 o Add restriction on MOS Type and algorithm choice to multi-layer 742 segment and multi-channel segment. 743 o Other editorial changes. 745 A.6. draft-wu-xrblock-rtcp-xr-quality-monitoring-08 747 The following are the major changes compared to previous version 07: 748 o Define registries for each segment type rather than various 749 applications. 750 o Add cross references to each registry. 751 o Typo fixed for section number. 753 Authors' Addresses 755 Geoff Hunt 756 Unaffiliated 758 Email: r.geoff.hunt@gmail.com 760 Alan Clark 761 Telchemy Incorporated 762 2905 Premiere Parkway, Suite 280 763 Duluth, GA 30097 764 USA 766 Email: alan.d.clark@telchemy.com 767 Qin Wu 768 Huawei 769 101 Software Avenue, Yuhua District 770 Nanjing, Jiangsu 210012 771 China 773 Email: sunseawq@huawei.com 775 Roland Schott 776 Deutsche Telekom Laboratories 777 Deutsche-Telekom-Allee 7 778 Darmstadt 64295 779 Germany 781 Email: Roland.Schott@telekom.de 783 Glen Zorn 784 Network Zen 785 77/440 Soi Phoomjit, Rama IV Road 786 Phra Khanong, Khlong Toie 787 Bangkok 10110 788 Thailand 790 Phone: +66 (0) 87 502 4274 791 Email: gwz@net-zen.net