idnits 2.17.1 draft-wu-xrblock-rtcp-xr-quality-monitoring-05.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 13, 2011) is 4518 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) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-00 Summary: 1 error (**), 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: June 15, 2012 Telchemy 6 Q. Wu 7 Huawei 8 R. Schott 9 DT 10 G. Zorn 11 Network Zen 12 December 13, 2011 14 RTCP XR Blocks for QoE metric reporting 15 draft-wu-xrblock-rtcp-xr-quality-monitoring-05 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 June 15, 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 segment . . . . . . . . . . . . . . . . 7 68 3.2.2. multi-channel segment . . . . . . . . . . . . . . . . 8 69 3.2.3. multi-view segment . . . . . . . . . . . . . . . . . . 9 70 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 11 73 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 11 74 5.3. Contact information for registrations . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 82 A.1. draft-wu-xrblock-rtcp-xr-quality-monitoring-03 . . . . . . 13 83 A.2. draft-wu-xrblock-rtcp-xr-quality-monitoring-04 . . . . . . 13 84 A.3. draft-wu-xrblock-rtcp-xr-quality-monitoring-05 . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 1.1. QoE Metrics Report Block 91 This draft defines a new block type to augment those defined in 92 [RFC3611], for use in a range of RTP applications. 94 The new block type provides information on multimedia quality using 95 one of several standard metrics. 97 The metrics belong to the class of application level metrics defined 98 in [MONARCH] (work in progress). 100 1.2. RTCP and RTCP XR Reports 102 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 103 defined an extensible structure for reporting using an RTCP Extended 104 Report (XR). This draft defines a new Extended Report block that 105 MUST be used as defined in RFC3550 and RFC3611. 107 1.3. Performance Metrics Framework 109 The Performance Metrics Framework [PMOL] provides guidance on the 110 definition and specification of performance metrics. Metrics 111 described in this draft either reference external definitions or 112 define metrics generally in accordance with the guidelines in [PMOL]. 114 1.4. Applicability 116 The QoE Metrics Report Block can be used in any application of RTP 117 for which QoE measurement algorithms are defined. 119 The factors that affect real-time AV application quality can be split 120 into two categories. The first category consists of transport- 121 dependent factors such as packet loss, delay and jitter (which also 122 translates into losses in the playback buffer). The factors in the 123 second category are application-specific factors that affect real 124 time application (e.g., video) quality and are sensitivity to network 125 errors. These factors can be but not limited to video codec and loss 126 recovery technique, coding bit rate, packetization scheme, and 127 content characteristics. 129 Compared with application-specific factors, the transport-dependent 130 factors sometimes are not sufficient to measure real time data 131 quality, since the ability to analyze the real time data in the 132 application layer provides quantifiable measurements for subscriber 133 Quality of Experience (QoE) that may not be captured in the 134 transmission layers or from the RTP layer down. In a typical 135 scenario, monitoring of the transmission layers can produce 136 statistics suggesting that quality is not an issue, such as the fact 137 that network jitter is not excessive. However, problems may occur in 138 the service layers leading to poor subscriber QoE. Therefore 139 monitoring using only network-level measurements may be insufficient 140 when application layer content quality is required. 142 In order to provide accurate measures of real time application 143 quality when transporting real time contents across a network, the 144 synthentical multimedia quality Metrics is highly required which can 145 be conveyed in the RTCP XR packets[RFC3611] and may have the 146 following three benefits: 148 o Tuning the content encoder algorithm to satisfy real time data 149 quality requirements. 150 o Determining which system techniques to use in a given situation 151 and when to switch from one technique to another as system 152 parameters change. 153 o Verifying the continued correct operation of an existing system. 155 2. Terminology 157 2.1. Standards Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 The terminology used is 165 Numeric formats S X:Y 167 where S indicates a two's complement signed representation, X 168 the number of bits prior to the decimal place and Y the number 169 of bits after the decimal place. 170 Hence 8:8 represents an unsigned number in the range 0.0 to 171 255.996 with a granularity of 0.0039. S7:8 would represent the 172 range -127.996 to +127.996. 0:16 represents a proper binary 173 fraction with range 174 0.0 to 1 - 1/65536 = 0.9999847 175 though note that use of flag values at the top of the numeric 176 range slightly reduces this upper limit. For example, if the 177 16- bit values 0xfffe and 0xffff are used as flags for "over- 178 range" and "unavailable" conditions, a 0:16 quantity has range 179 0.0 to 1 - 3/65536 = 0.9999542 181 3. QoE Metrics Block 183 This block reports the multimedia application performance or quality 184 beyond the information carried in the standard RTCP packet format. 185 Information is recorded about multimedia application QoE metric which 186 provides a measure that is indicative of the user's view of a 187 service. Multimedia application QoE metric is commonly expressed as 188 a MOS ("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 189 5 represents excellent and 1 represents unacceptable. MOS scores are 190 usually obtained using subjective testing or using objective 191 algorithm. However Subjective testing to estimate the multimedia 192 quality may be not suitable for measuring the multimedia quality 193 since the results may vary from test to test. Therefore using 194 objective algorithm to calculate MOS scores is recommended. ITU-T 195 recommendations define the methodologies for assessment of the 196 performance of multimedia stream 197 [G.107][P.564][G.1082][P.NAMS][P.NBAMS] and provides a method to 198 evaluate QoE estimation algorithms and objective model for video and 199 audio. Hence this document recommends vendors and implementers to 200 use these International Telecommunication Union (ITU)-specified 201 methodologies to measure parameters when possible. 203 3.1. Metric Block Structure 205 The report block contents are dependent upon a series of flag bits 206 carried in the first part of the header. Not all parameters need to 207 be reported in each block. Flags indicate which are and which are 208 not reported. The fields corresponding to unreported parameters MUST 209 be present, but are set to zero. The receiver MUST ignore any QoE 210 Metrics Block with a non-zero value in any field flagged as 211 unreported. The encoding of QoE metrics block payload consists of a 212 series of 32 bit units called segments that describe MOS Type, MoS 213 algorithm and MoS value. 215 The QoE Metrics Block has the following format: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | BT=TBD | I | Rsd | block length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | SSRC of source | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Segment 1 | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Segment 2 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 .................. 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Segment n | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 3.2. Definition of Fields in QoE Metrics Block 235 Block type (BT): 8 bits 237 The QoE Metrics Block is identified by the constant . 239 Interval Metric flag (I): 2 bit 241 This field is used to indicate whether the Basic Loss/Discard 242 metrics are Interval or Cumulative metrics, that is, whether the 243 reported values applies to the most recent measurement interval 244 duration between successive metrics reports (I=01) (the Interval 245 Duration) or to the accumulation period characteristic of 246 cumulative measurements (I=00) (the Cumulative Duration) or to the 247 value of a continuously measured or calculated that has been 248 sampled at end of the interval (I=10) (Sampled Value). 250 Rsd.:6 bits 252 This field is reserved for future definition. In the absence of 253 such a definition, the bits in this field MUST be set to zero and 254 MUST be ignored by the receiver. 256 Block Length: 16 bits 258 The length of this report block in 32-bit words, minus one. For 259 the QoE Metrics Block, the block length is variable length. 261 SSRC of source: 32 bits 263 As defined in Section 4.1 of [RFC3611]. 265 Segment i: 32 bits 267 There are three segment types : single stream, multi-channel 268 audio, multi-view . The left two bits of the section determine 269 its type. If the leftmost bit of the section is zero, then it is 270 single stream segment. If the leftmost bit is one and the second 271 bit is zero, then it is multi-channel audio segment, if the 272 leftmost bit is one and the second bit is one, then it is multi- 273 view segment. Note that in these three segement type,any two 274 segement types can not be present in the same metric block. 276 3.2.1. single stream segment 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |0|CAlg | MT | Rsv. | MOS Value | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Segment Type ( S): 1 bit 284 A zero identifies this as a single stream segment. 286 Calculation Algorithm (CALg):3 bits 288 000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice) 289 001 - G.107 [G.107] (Voice) 290 010 - G.107 / ETSI TS 101 329-5 Annex E [G.107],[ ETSI] (Voice) 291 011 - ITU-T P.NAMS [P.NAMS] 292 100 - ITU-T P.NBAMS [P.NBAMS] 293 101~111 - Reserved for future extension. 295 MoS Type (MT): 4 bits 297 This field is used to indicate the MOS type to be reported. The 298 MOS type is defined as follows: 300 0000 MOS-LQ - Listening Quality MoS. 301 0001 MOS-CQ - Conversation Quality MoS. 302 0010 MOS-V - Video Quality MOS. 303 0011 MOS-AV - Audio-Video Quality MOS. 305 0100~1111 - Reserved for future definitions. 307 MoS-LQ measures the quality of audio for listening purposes only 308 while MoS-CQ measures the quality of audio for conversation 309 purpose only. MoS-V and MoS-AV measures the quality of video 310 application or Audio-Video application.Both MoS-LQ and MoS-CQ are 311 commonly used in VoIP applications. MOS-LQ uses either wideband 312 audio codec or narrowband audio codec, or both and does not take 313 into account any of bidirectional effects, such as delay and echo. 314 MOS-CQ uses narrowband codec and takes into account listening 315 quality in each direction, as well as the bidirectional effects. 316 If MoS type is MoS-LQ and MoS-CQ, the MoS value can be calculated 317 based on ITU-T G.107[G.107], ITU-T P.564 [P.564]or ETSI TS 101 318 329-5 [ETSI], if the Mos type is MoS-V or MoS-AV, the Mos value 319 can be calculated based on ITU-T P.NAMS [P.NAMS]or ITU-T P.NBAMS 320 [P.NBAMS]. If new MOS types are defined, they can be added by an 321 update to this document. If the receiver does not understand the 322 MOS type defined in this document it should discard this report. 324 Rsd.:8 bits 326 This field is reserved for future definition. In the absence of 327 such a definition, the bits in this field MUST be set to zero and 328 MUST be ignored by the receiver. 330 MOS Value: 16 bits 332 The estimated mean opinion score for multimedia application 333 quality is defined as including the effects of delay,loss, 334 discard,jitter and other effects that would affect multimedia 335 quality . It is expressed in numeric format 8:8 with the value in 336 the range 0.0 to 255.996. The valid the measured value ranges 337 from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the 338 measured value is over ranged, the value 0xFFFE SHOULD be reported 339 to indicate an over-range measurement. If the measurement is 340 unavailable, the value 0xFFFF SHOULD be reported. Values other 341 than 0xFFFE,0xFFFF and the valid range defined above MUST NOT be 342 sent and MUST be ignored by the receiving system. 344 3.2.2. multi-channel segment 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |1|0|CAlg | MT | CHID | Rsv.| MOS Value | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Segement Type ( S): 1 bit 352 A one identifies this as either a multi-channel section or multi- 353 view segment. 355 Media Type (M): 1bit 357 A zero identifies this as a multi-channel audio section. 359 Calculation Algorithm (CALg):3 bits 361 As defined in Section 4.2.1 of this document. 363 MoS Type (MT): 4 bits 365 As defined in Section 4.2.1 of this document. 367 Sub Stream Identifier (CHID): 4 bits 369 If multiple channels of audio are carried in one RTP stream, each 370 channel of audio will be viewed as a channel(e.g., left channel 371 audio, right channel audio). This field is used to identify each 372 channel that is carried in the same media stream. 374 Rsd.:3 bits 376 This field is reserved for future definition. In the absence of 377 such a definition, the bits in this field MUST be set to zero and 378 MUST be ignored by the receiver. 380 MOS Value: 16 bits 382 As defined in Section 4.2.1 of this document. 384 3.2.3. multi-view segment 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 |1|1|CAlg | MT | SSID | Rsv.| MOS Value | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Segment Type ( S): 1 bit 392 A one identifies this as either a multi-channel section or multi- 393 view segment. 395 Media Type (M): 1bit 397 A one identifies this as a multi-view video segment. 399 Calculation Algorithm (CALg):3 bits 401 As defined in Section 4.2.1 of this document. 403 MoS Type (MT): 4 bits 405 As defined in Section 4.2.1 of this document. 407 Sub Stream Identifier (SSID): 4 bits 409 If multiple views of video are carried in the same RTP stream, 410 each view will be viewed as a sub stream. This field is used to 411 identify each view that is carried in the same media stream. 413 Rsd.:3 bits 415 This field is reserved for future definition. In the absence of 416 such a definition, the bits in this field MUST be set to zero and 417 MUST be ignored by the receiver. 419 MOS Value: 16 bits 421 As defined in Section 4.2.1 of this document. 423 4. SDP Signaling 425 One new parameter is defined for the report block defined in this 426 document to be used with Session Description Protocol (SDP) [RFC4566] 427 using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the 428 following syntax within the "rtcp-xr" attribute [RFC3611]: 430 rtcp-xr-attrib = "a=rtcp-xr:" 431 [xr-format *(SP xr-format)] CRLF 432 xr-format = qoe-metrics 433 qoe-metrics = "multimedia-quality-metrics" 435 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 436 and the full syntax of the "rtcp-xr" attribute. 438 5. IANA Considerations 440 New block types for RTCP XR are subject to IANA registration. For 441 general guidelines on IANA considerations for RTCP XR, refer to 442 [RFC3611]. 444 5.1. New RTCP XR Block Type value 446 This document assigns the block type value NDEL in the IANA "RTCP XR 447 Block Type Registry" to the "QoE Metrics Block". 449 [Note to RFC Editor: please replace SMQ with the IANA provided RTCP 450 XR block type for this block.] 452 5.2. New RTCP XR SDP Parameter 454 This document also registers a new parameter "qoe-metrics" in the 455 "RTCP XR SDP Parameters Registry". 457 5.3. Contact information for registrations 459 The contact information for the registrations is: 461 Qin Wu 462 sunseawq@huawei.com 463 101 Software Avenue, Yuhua District 464 Nanjing, JiangSu 210012 China 466 6. Security Considerations 468 The new RTCP XR report blocks proposed in this document introduces no 469 new security considerations beyond those described in [RFC3611]. 471 7. Authors 473 This draft merges ideas from two different drafts addressing the QoE 474 metric Reporting issue. The authors of these drafts are listed below 475 (in alphabetical order) : 476 Alan Clark < alan.d.clark@telchemy.com > 477 Geoff Hunt < r.geoff.hunt@gmail.com > 478 Martin Kastner < martin.kastner@telchemy.com > 479 Kai Lee < leekai@ctbri.com.cn > 480 Roland Schott < roland.schott@telekom.de > 481 Qin Wu < sunseawq@huawei.com > 482 Glen Zorn < gwz@net-zen.net > 484 8. Acknowledgements 486 The authors would like to thank Alan Clark, Bill Ver Steeg, David R 487 Oran, Ali Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and 488 Yinliang Hu for their valuable comments and suggestions on this 489 document. 491 9. References 493 9.1. Normative References 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 499 Applications", RFC 3550, July 2003. 501 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 502 Protocol Extended Reports (RTCP XR)", RFC 3611, 503 November 2003. 505 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 506 Description Protocol", RFC 4566, July 2006. 508 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 509 Specifications: ABNF", STD 68, RFC 5234, January 2008. 511 9.2. Informative References 513 [ETSI] ETSI, "Quality of Service (QoS) measurement 514 methodologies", ETSI TS 101 329-5 V1.1.1, November 2000. 516 [G.107] ITU-T, "The E Model, a computational model for use in 517 transmission planning", ITU-T Recommendation G.107, 518 April 2009. 520 [G.1082] ITU-T, "Measurement-based methods for improving the 521 robustness of IPTV performance", ITU-T 522 Recommendation G.1082, April 2009. 524 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 525 ID draft-ietf-avtcore-monarch-00, April 2011. 527 [P.564] ITU-T, "Conformance testing for narrowband Voice over IP 528 transmission quality assessment models", ITU-T 529 Recommendation P.564, July 2006. 531 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 532 of performance of Multimedia Streaming", ITU-T 533 Recommendation P.NAMS, November 2009. 535 [P.NBAMS] ITU-T, "non-intrusive bit-stream model for assessment of 536 performance of multimedia streaming", ITU-T 537 Recommendation P.NBAMS, November 2009. 539 [PMOL] Clark, A. and B. Claise, "Framework for Performance Metric 540 Development", ID draft-ietf-pmol-metrics-framework-12, 541 July 2011. 543 Appendix A. Change Log 545 A.1. draft-wu-xrblock-rtcp-xr-quality-monitoring-03 547 The following are the major changes compared to previous version 02: 548 o Remove the tag field. 549 o Define MOS Value field as 32 bits integer value field. 550 o Clear unused references. 551 o Add text to MOS type field for clarification. 552 o Other Editorial changes. 554 A.2. draft-wu-xrblock-rtcp-xr-quality-monitoring-04 556 The following are the major changes compared to previous version 03: 557 o Add Numeric format definition and express the MoS-Value in Numeric 558 format. 559 o Change 32bits MoS Value into 16bits MoS Value. 560 o Add some text to MoS Type definition to clarify the algorithm 561 calculation. 562 o Separate MoS-A into MoS-LQ and MoS-CQ and add some text to clarify 563 the difference between them. 564 o Add one more reference for MoS-LQ and MoS-CQ value calculation. 565 o Other Editorial changes. 567 A.3. draft-wu-xrblock-rtcp-xr-quality-monitoring-05 569 The following are the major changes compared to previous version 04: 570 o Merge this draft with Clack's draft 571 o Define three segment types to distinguish multiple elementary 572 stream carried in the same RTP stream from multiple elementary 573 stream carried in each different RTP stream 575 o Allocate 3 bit for MOS calculation algorithms in each segment. 576 o Allocate or move 4 bit for MOS Type to each segment 577 o Other Editorial changes. 579 Authors' Addresses 581 Geoff Hunt 582 Unaffiliated 584 Email: r.geoff.hunt@gmail.com 586 Alan Clark 587 Telchemy Incorporated 588 2905 Premiere Parkway, Suite 280 589 Duluth, GA 30097 590 USA 592 Email: alan.d.clark@telchemy.com 594 Qin Wu 595 Huawei 596 101 Software Avenue, Yuhua District 597 Nanjing, Jiangsu 210012 598 China 600 Email: sunseawq@huawei.com 602 Roland Schott 603 Deutsche Telekom Laboratories 604 Deutsche-Telekom-Allee 7 605 Darmstadt 64295 606 Germany 608 Email: Roland.Schott@telekom.de 609 Glen Zorn 610 Network Zen 611 77/440 Soi Phoomjit, Rama IV Road 612 Phra Khanong, Khlong Toie 613 Bangkok 10110 614 Thailand 616 Phone: +66 (0) 87 502 4274 617 Email: gwz@net-zen.net