idnits 2.17.1 draft-wu-avt-rtcp-xr-quality-monitoring-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. -- The document date (October 13, 2010) is 4944 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) == Unused Reference: 'RFC2250' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-fecframe-interleaved-fec-scheme' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-fecframe-raptor' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'IEEE' is defined on line 956, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-avt-rapid-rtp-sync-12 == Outdated reference: A later version (-27) exists of draft-ietf-avt-rtp-svc-23 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-raptor-02 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track G. Zorn 5 Expires: April 16, 2011 Network Zen 6 R. Schott 7 Deutsche Telekom Laboratories 8 October 13, 2010 10 RTP Control Protocol Extended Reports (RTCP XR) Report Blocks for Real- 11 time Video Quality Monitoring 12 draft-wu-avt-rtcp-xr-quality-monitoring-04 14 Abstract 16 This document defines a set of RTP Control Protocol Extended Reports 17 (RTCP XR) Report Blocks and associated SDP parameters allowing the 18 report of video quality metrics, primarily for video applications of 19 RTP. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 16, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Transport Layer Metrics . . . . . . . . . . . . . . . . . . . 5 61 4.1. RTP Flows Initial Synchronization Delay Report Block . . . 6 62 4.2. RTP Flow General Synchronization Offset Metrics Block . . 7 63 4.3. Layered Streams Statistics Metrics Block . . . . . . . . . 8 64 5. Application Layer Metrics . . . . . . . . . . . . . . . . . . 9 65 5.1. RTP Streams Statistics Summary Report Block . . . . . . . 9 66 5.2. Video Stream Loss and Discard Metrics Block . . . . . . . 11 67 5.3. Video Stream Burst Metrics Block . . . . . . . . . . . . . 13 68 5.4. Synthetical Multimedia Quality Metrics Block . . . . . . . 15 69 6. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 17 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 78 1. Introduction 80 Along with the wide deployment of broadband access and the 81 development of new IPTV services (e.g., broadcast video, video on 82 demand), there is increasing interest in monitoring and managing 83 networks and applications that deliver real-time applications over 84 IP, to ensure that all end users obtain acceptable video/audio 85 quality. The main drives come from operators, since offering 86 performance monitoring capability can help diagnose network 87 impairments, facilitate in root cause analysis and aid in verifying 88 compliance with service level agreements (SLAs) between Internet 89 Service Providers (ISPs) and content providers. 91 The factors that affect real-time application quality can be split 92 into two categories. The first category consists of transport- 93 dependent factors such as packet loss, delay and jitter (which also 94 translates into losses in the playback buffer). The factors in the 95 second category are application-specific factors that affect video 96 quality and are sensitivity to network errors. These factors can be 97 but not limited to video codec and loss recovery technique, coding 98 bit rate, packetization scheme, and content characteristics. 100 Compared with application-specific factors, the transport-dependent 101 factors sometimes are not sufficient to measure video quality, since 102 the ability to analyze the video in the application layer provides 103 quantifiable measurements for subscriber Quality of Experience (QoE) 104 that may not be captured in the transmission layers or from the RTP 105 layer down. In a typical scenario, monitoring of the transmission 106 layers can produce statistics suggesting that quality is not an 107 issue, such as the fact that network jitter is not excessive. 108 However, problems may occur in the service layers leading to poor 109 subscriber QoE. Therefore monitoring using only network-level 110 measurements may be insufficient when application layer video quality 111 is required. 113 In order to provide accurate measures of video quality for operators 114 when transporting video across a network, the video quality Metrics 115 is highly required which can be conveyed in the RTCP XR 116 packets[RFC3611] and may have the following three benefits: 118 * Tuning the video encoder algorithm to satisfy video quality 119 requirements 120 * Determining which system techniques to use in a given situation 121 and when to switch from one technique to another as system 122 parameters change 123 * Verifying the continued correct operation of an existing system 125 RFC 3611 [RFC3611] defines seven report block formats for network 126 management and quality monitoring. However, there are no block types 127 specifically designed for conveying video quality metrics. This 128 document focuses on specifying new report block types used to convey 129 video-specific quality metrics. 131 The report block types defined in this document fall into two 132 categories. The first category consists of general information 133 regarding transmission quality, to be generated and processed by the 134 RTP transport. The report blocks in the second category convey 135 metrics above transport that affect video quality and are sensitivity 136 to network errors. 138 Seven report block formats are defined by this document. Of these, 139 three are transport layer metrics: 141 * RTP Flows Initial Synchronization Delay Report Block 142 * Audio-Video Playout Offset Report Block 143 * Layered Streams Statistics Metrics Block 145 The other four are application layer metrics: 147 * Video Statistics Summary Report Block 148 * Video Stream Loss and Discard Metrics Block 149 * Video Stream Burst Metrics Block 150 * Synthetical Multimedia Quality Metrics Block 152 2. Terminology 154 2.1. Standards Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 In addition, the following terms are defined: 162 Layered Component Packet 164 a RTP packet using layered codecs containing the specified layered 165 component, e.g., encoded stream at the base layer or at the 166 enhancement layer. 168 Picture Type 170 Picture types used in the different video algorithms compose of 171 the key-frame and the Derivation frame. Key-frame is also called 172 as reference frame and used as a reference for predicting other 173 pictures. It is coded without prediction from other pictures. 174 The Derivation frame is derived from Key-frame using prediction 175 from the reference frame. 177 2.2. Acronyms 179 SSRC 180 Synchronization Source [RFC3550] 182 TS 183 Transport Stream [ISO-IEC.13818-1.2007] 185 3. Applicability 187 All the report blocks defined in this document could be used by 188 dedicated network monitoring applications. As specified in RFC 3611 189 [RFC3611], for such an application it might be appropriate to allow 190 more than 5% of RTP data bandwidth to be used for RTCP packets, thus 191 allowing proportionately larger and more detailed report blocks. 193 The Flows General Synchronization Offset Block Section 4.2 has been 194 defined for various multimedia applications. Such applications can 195 use this report block to monitor offset between two RTP streams 196 synchronization to ensure satisfactory QoE. Tighter tolerances than 197 typically used have been recommended for such applications. 199 The Flows Synchronization Delay Report Block has been defined 200 primarily for layered or multi-description video coding applications. 201 When joining a layered video session in such an application, a 202 receiver may not synchronize playout across the multimedia session 203 until RTCP SR packets have been received on all of the component RTP 204 sessions. This report block can be used to ensure synchronization 205 between different media layers for the same multimedia session. 207 The Video Stream Loss and Discard Metrics Report Block, Video Stream 208 Burst Metrics report Block, Video Statistics Summary Report Block and 209 Layered Video Statistics Metrics Block can be applied to any real 210 time video application, while Synthetical Multimedia Quality Metrics 211 Report Block can be used in any real-time AV application . 213 4. Transport Layer Metrics 214 4.1. RTP Flows Initial Synchronization Delay Report Block 216 This block reports the initial synchronization delay between RTP 217 sessions of the same media stream sent using Multi-Session 218 Transmission [I-D.ietf-avt-rtp-svc] or the initial synchronization 219 delay betwen RTP session of the different media types 220 [I-D.ietf-avt-rapid-rtp-sync], which is beyond the information 221 carried in the standard RTCP packet format. Information is recorded 222 about session bandwidth and synchronization delay. 224 The RTP Flows Intial Synchronization Delay Report Block has the 225 following format: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | BT=TBD | Reserved | Block length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | SSRC of Sender | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Initial Synchronization Delay | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Block type (BT): 8 bits 238 The Statistics Summary Report Block is identified by the constant 239 . 241 Reserved: 8 bits 242 This field is reserved for future definition. In the absence of 243 such a definition, the bits in this field MUST be set to zero and 244 MUST be ignored by the receiver. 246 Block length: 16 bits 247 The constant 3, in accordance with the definition of this field in 248 Section 3 of RFC 3611 [RFC3611]. 250 SSRC of Sender: 32 bits 251 The SSRC of the RTP data packet source being reported upon by this 252 report block. (Section 4.1 of [RFC3611]). 254 Initial Synchronization Delay: 32 bits 255 The average delay, expressed in units of 1/65536 seconds, between 256 the RTCP packets received on all of the components RTP sessions 257 and the beginning of session [I-D.ietf-avt-rapid-rtp-sync]. The 258 value is calculated as follows: 260 The average time, expressed in units of 1/65536 seconds, taken 261 to receive the first RTCP packet in the RTP session with the 262 longest RTCP reporting interval [I-D.ietf-avt-rapid-rtp-sync] 264 4.2. RTP Flow General Synchronization Offset Metrics Block 266 In an RTP multimedia session, there can be an arbitrary number of 267 streams, with the same RTCP CNAME. This block reports the general 268 Synchronization offset requirements of these RTP streams beyond the 269 information carried in the standard RTCP packet format. Information 270 is recorded about the synchronization offset time of each RTP stream 271 relative to the reference RTP stream with the same CNAME and General 272 Synchronisation Offset of zero.. The RTP Flow General 273 Synchronization Offset Report Block has the following format: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | BT=TBD |I| Reserved | Block length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | SSRC of source | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | General Synchronization Offset | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Block type (BT): 8 bits 286 The Statistics Summary Report Block is identified by the constant 287 . 289 Interval Metric flag (I): 1 bit 291 This field is used to indicate whether the Audio-Video 292 synchronization metrics are Interval or Cumulative metrics, that 293 is, whether the reported values applies to the most recent 294 measurement interval duration between successive metrics reports 295 (I=1) (the Interval Duration) or to the accumulation period 296 characteristic of cumulative measurements (I=0) (the Cumulative 297 Duration). 299 Reserved: 8 bits 300 This field is reserved for future definition. In the absence of 301 such a definition, the bits in this field MUST be set to zero and 302 MUST be ignored by the receiver. 304 Block length: 16 bits 305 The constant 2, in accordance with the definition of this field in 306 Section 3 of RFC 3611 [RFC3611]. 308 SSRC of source: 32 bits 309 As defined in Section 4.1 of RFC 3611 [RFC3611]. 311 General synchronization offset: 32 bits 312 This field indicates the synchronization offset time of one RTP 313 stream in milliseconds relative to the reference RTP stream with 314 the same CNAME and General Synchronisation Offset of zero 315 [I-D.ietf-avt-rapid-rtp-sync] This value is calculated based on 316 the interarrival time between arbitray RTP packet and the 317 reference RTP packet with the same CNAME , and timestamps of this 318 arbitray RTP packet and the reference RTP packet with the same 319 CNAME. 321 4.3. Layered Streams Statistics Metrics Block 323 This block reports layered streams statistics beyond the information 324 carried in the Statistics Summary Report Block RTCP packet specified 325 in the section 4.6 of RFC 3611 [RFC3611]. Information is recorded 326 about lost layered component packets, duplicated layered component 327 packets. Such information can be useful for network management and 328 video quality monitoring. 330 The report block contents are dependent upon a series of flag bits 331 carried in the first part of the header. Not all parameters need to 332 be reported in each block. Flags indicate which parameters are 333 reported and which are not. The fields corresponding to unreported 334 parameters MUST be present, but are set to zero. The receiver MUST 335 ignore any Layered Streams Statistics Metrics Block with a non-zero 336 value in any field flagged as unreported. 338 The Layered Stream Statistics metrics Block has the following format: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | BT=TBD |T| rsd. | block length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | SSRC of source | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | begin_seq | end_seq | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Lost_Layered Component Packets | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Dup Layered Component_Packets | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Block type (BT): 8 bits 355 The Layered stream Statistics Metrics Block is identified by the 356 constant . 358 Layer Type flag (T): 1 bits 359 This field is used to indicate the Layer Type of layered video to 360 be reported. LT is set to 0 if the loss_component_packet field 361 and dup_component packet contain the base layer packet in layered 362 codecs,e.g, SVC in [I-D.ietf-avt-rtp-svc], 1 if the loss_component 363 packet field and dup_component packet contain enhancement layer 364 packet in layered codec. 366 Rsd.: 3 bits 367 This field is reserved for future definition. In the absence of 368 such a definition, the bits in this field MUST be set to zero and 369 MUST be ignored by the receiver. 371 Block length: 16 bits 372 The constant 3, in accordance with the definition of this field in 373 Section 3 of RFC 3611 [RFC3611]. 375 SSRC of source: 32 bits 376 As defined in Section 4.1 of RFC 3611 [RFC3611]. 378 begin_seq: 16 bits 379 As defined in Section 4.1 of RFC 3611 [RFC3611]. 381 end_seq: 16 bits 382 As defined in Section 4.1 of RFC 3611 [RFC3611]. 384 Lost_Layered Component Packets: 32 bits 385 Number of lost_component packets in the above sequence number 386 interval. 388 Dup_Layered Component Packets: 32 bits 389 Number of dup_component packets in the above sequence number 390 interval. 392 5. Application Layer Metrics 394 5.1. RTP Streams Statistics Summary Report Block 396 This block reports statistics beyond the information carried in the 397 Statistics Summary Report Block RTCP packet specified in the section 398 4.6 of RFC 3611 [RFC3611]. Information is recorded about lost frame 399 packets, duplicated frame packets, lost layered component packets, 400 duplicated layered component packets. Such information can be useful 401 for network management and video quality monitoring. 403 The report block contents are dependent upon a series of flag bits 404 carried in the first part of the header. Not all parameters need to 405 be reported in each block. Flags indicate which parameters are 406 reported and which are not. The fields corresponding to unreported 407 parameters MUST be present, but are set to zero. The receiver MUST 408 ignore any Video Statistics Summary Report Block with a non-zero 409 value in any field flagged as unreported. 411 The RTP Streams Statistics Summary Report Block has the following 412 format: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | BT=TBD |T|P| rsd. | block length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | SSRC of source | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | begin_seq | end_seq | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | lost_frames | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | dup frames | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | lost_partial frame packets | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | dup partial frame_packets | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Block type (BT): 8 bits 433 The Video Statistics Summary Report Block is identified by the 434 constant . 436 Picture type indicator (T): 1 bits 437 Picture types used in the different video algorithms compose of 438 key-frame and derivation frame. This field is used to indicate 439 the frame type to be reported. Bits set to 0 if the lost_frames 440 field or dup_frames field contain a key_frame report or reference 441 frame report, 1 if the lost_frames field and dup_frames field 442 contain other derivation frame report. 444 P: 1 bit 445 Bit set to 1 if the lost_partial frame packets field or the 446 dup_partial_frame packets field contains a report, 0 otherwise. 448 Rsd.: 3 bits 449 This field is reserved for future definition. In the absence of 450 such a definition, the bits in this field MUST be set to zero and 451 MUST be ignored by the receiver. 453 Block length: 16 bits 454 The constant 5, in accordance with the definition of this field in 455 Section 3 of RFC 3611 [RFC3611]. 457 SSRC of source: 32 bits 458 As defined in Section 4.1 of RFC 3611 [RFC3611]. 460 begin_seq: 16 bits 461 As defined in Section 4.1 of RFC 3611 [RFC3611]. 463 end_seq: 16 bits 464 As defined in Section 4.1 of RFC 3611 [RFC3611]. 466 lost_frames: 32 bits 467 Number of lost_frames in the above sequence number interval. 469 dup_frames: 32 bits 470 Number of dup_frames in the above sequence number interval. 472 lost_partial frame packets: 32 bits 473 Number of lost_partial frame packets in the above sequence number 474 interval. 476 dup_partial frame packets: 32 bits 477 Number of dup_partial frame packets in the above sequence number 478 interval. 480 5.2. Video Stream Loss and Discard Metrics Block 482 This block reports Loss and Discard metrics statistics beyond the 483 information carried in the standard RTCP packet format. The block 484 reports separately on packets lost on the IP channel, and those that 485 have been received but then discarded by the receiving jitter buffer. 487 It is very useful to distinguish between packets lost by the network 488 and those discarded due to jitter. Both have equal effect on the 489 quality of the video stream, however, having separate counts helps 490 identify the source of quality degradation. These fields MUST be 491 populated, and MUST be set to zero if no packets have been received. 493 Implementations MUST provide values for all the fields defined here. 494 For certain metrics, if the value is undefined or unknown, then the 495 specified default or unknown field value MUST be provided. 497 The block is encoded as six 32-bit words: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | BT=TBD |T | reserved | block length | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | SSRC of source | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Loss rate | Discard rate | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 block type (BT): 8 bits 510 A Video Stream Metrics Report Block is identified by the constant 511 . 513 Picture type indicator (T): 1 bits 514 Picture types used in the different video algorithms compose of 515 key-frame and derivation frame. This field is used to indicate 516 the picture type to be reported. Bits set to 0 if the Loss rate 517 field and discard rate field contain a Key_frame report or 518 reference frame report, 1 if the Loss rate field and discard rate 519 field contain other derivation frame reports. 521 reserved: 6 bits 522 This field is reserved for future definition. In the absence of 523 such a definition, the bits in this field MUST be set to zero and 524 MUST be ignored by the receiver. 526 block length: 16 bits 527 The constant 1, in accordance with the definition of this field in 528 Section 3 of RFC 3611 [RFC3611]. 530 SSRC of source: 32 bits 531 The SSRC of the RTP data packet source being reported upon by this 532 report block. in accordance with the definition of this field in 533 Section 3 of RFC 3611 [RFC3611]. 534 Loss rate: 8 bits 535 The fraction of RTP data packets from the source lost since the 536 beginning of reception, expressed as a fixed point number with the 537 binary point at the left edge of the field. This value is 538 calculated by dividing the total number of lost packets containing 539 specified frame (e.g., Key frame) (after the effects of applying 540 any error protection such as FEC) by the total number of packets 541 expected, multiplying the result of the division by 256, limiting 542 the maximum value to 255 (to avoid overflow), and taking the 543 integer part. The numbers of duplicated packets and discarded 544 packets do not enter into this calculation. Since receivers 545 cannot be required to maintain unlimited buffers, a receiver MAY 546 categorize late-arriving packets as lost. The degree of lateness 547 that triggers a loss SHOULD be significantly greater than that 548 which triggers a discard. 550 Discard rate: 8 bits 551 The fraction of RTP data packets from the source that have been 552 discarded since the beginning of reception, due to late or early 553 arrival, under-run or overflow at the receiving jitter buffer. 554 This value is expressed as a fixed point number with the binary 555 point at the left edge of the field. It is calculated by dividing 556 the total number of discarded packets containing specified frame 557 (e.g., Key Frame) (excluding duplicate packet discards) by the 558 total number of packets expected, multiplying the result of the 559 division by 256, limiting the maximum value to 255 (to avoid 560 overflow), and taking the integer part. 562 5.3. Video Stream Burst Metrics Block 564 This block reports Burst metrics statistics beyond the information 565 carried in the standard RTCP packet format. It reports on the 566 combined effect of losses and discards, as both have equal effect on 567 video quality. 569 In order to properly assess the quality of a video stream, it is 570 desirable to consider the degree of burstiness of packet loss RFC 571 3357 [RFC3357]. Following the one-way loss pattern sample metrics 572 discussed in [RFC3357], a measure of the spacing between consecutive 573 network packet loss or error events, is a "loss distance". The loss 574 distance metric captures the spacing between the loss periods. The 575 duration of a loss or error event (e.g. and how many packets are lost 576 in that duration) is a "loss period", the loss period metric captures 577 the frequency and length (burstiness) of loss once it starts. Delay 578 reports include the transit delay between RTP end points and the end 579 system processing delays, both of which contribute to the user 580 perceived delay. 582 Implementations MUST provide values for all the fields defined here. 583 For certain metrics, if the value is undefined or unknown, then the 584 specified default or unknown field value MUST be provided. 586 The block is encoded as six 32-bit words: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | BT=TBD | Reserved | block length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | SSRC of source | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Loss Distance | Loss Period | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Max Loss Duration | Reserved. | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 block type (BT): 8 bits 601 A Video Stream Metrics Report Block is identified by the constant 602 . 604 reserved: 8 bits 605 This field is reserved for future definition. In the absence of 606 such a definition, the bits in this field MUST be set to zero and 607 MUST be ignored by the receiver. 609 block length: 16 bits 610 The constant 2, in accordance with the definition of this field in 611 Section 3 of RFC 3611 [RFC3611]. 613 SSRC of source: 32 bits 614 The SSRC of the RTP data packet source being reported upon by this 615 report block. in accordance with the definition of this field in 616 Section 3 of RFC 3611 [RFC3611]. 618 Loss Distance: 16 bits 619 The mean duration, expressed in milliseconds, of the loss 620 intervals that have occurred since the beginning of reception 621 [DSLF]. The duration of each loss distance is calculated based 622 upon the frames that mark the beginning and end of that period. 623 It is equal to the timestamp of the end frame, plus the duration 624 of the end frame, minus the timestamp of the beginning frame. If 625 the actual values are not available, estimated values MUST be 626 used. If there have been no burst periods, the burst duration 627 value MUST be zero. 629 Loss Period: 16 bits 630 The mean duration, expressed in milliseconds, of the burst loss 631 periods that have occurred since the beginning of reception 632 [DSLF]. The duration of each period is calculated based upon the 633 frame that marks the end of the prior burst loss and the frame 634 that marks the beginning of the subsequent burst loss. It is 635 equal to the timestamp of the subsequent burst frame, minus the 636 timestamp of the prior burst packet, plus the duration of the 637 prior burst packet. If the actual values are not available, 638 estimated values MUST be used. In the case of a gap that occurs 639 at the beginning of reception, the sum of the timestamp of the 640 prior burst packet and the duration of the prior burst packet are 641 replaced by the reception start time. In the case of a gap that 642 occurs at the end of reception, the timestamp of the subsequent 643 burst packet is replaced by the reception end time. If there have 644 been no gap periods, the gap duration value MUST be zero. 646 Max Loss Duration of a single error: 16 bits 647 The maximum loss duration, expressed in milliseconds, of the loss 648 periods that have occurred since the beginning of reception. The 649 recommended max loss duration is specified as less than 16 ms in 650 [DSLF], which provides a balance between interleaver depth 651 protection from xDSL errors induced by impulse noise, delay added 652 to other applications and video service QoE requirements to reduce 653 visible impairments. 655 Reserved: 16 bits 656 All bits SHALL be set to 0 by the sender and SHALL be ignored on 657 reception. 659 block length: 16 bits 660 The constant 2, in accordance with the definition of this field in 661 Section 3 of RFC 3611 [RFC3611]. 663 5.4. Synthetical Multimedia Quality Metrics Block 665 This block reports the multimedia quality metrics beyond the 666 information carried in the standard RTCP packet format. Information 667 is recorded about Video MOS, Audio MOS, Audio Video MOS, Video 668 Service Transmission Quality [G.1082][P.NAMS]. 670 The report block contents are dependent upon a series of flag bits 671 carried in the first part of the header. Not all parameters need to 672 be reported in each block. Flags indicate which are and which are 673 not reported. The fields corresponding to unreported parameters MUST 674 be present, but are set to zero. The receiver MUST ignore any 675 Perceptual Quality Metrics Block with a non-zero value in any field 676 flagged as unreported. 678 The Synthetical Multimedia Quality Metrics Block has the following 679 format: 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | BT=TBD |I|V|A|M|T|Rsd. | block length | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | SSRC of source | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | MOS-V | MOS-A | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | MOS-AV | VSTQ | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Block type (BT): 8 bits 694 The Perceptual Quality Metrics Block is identified by the constant 695 . 697 Interval Metric flag (I): 1 bit 698 This field is used to indicate whether the Basic Loss/Discard 699 metrics are Interval or Cumulative metrics, that is, whether the 700 reported values applies to the most recent measurement interval 701 duration between successive metrics reports (I=1) (the Interval 702 Duration) or to the accumulation period characteristic of 703 cumulative measurements (I=0) (the Cumulative Duration). 705 MOS-V flag (V): 1 bit 706 Bit set to 1 if the MOS-V field and MOS-AV field contain a report, 707 0 otherwise. 709 MOS-A flag (A): 1 bit 710 Bit set to 1 if the MOS-A field contain a report, 0 otherwise. 712 MOS-AV flag (M): 1 bit 713 Bit set to 1 if the MOS-AV field contain a report, 0 otherwise. 715 Video Service Transmission Quality flag (T): 1 bit 716 Bit set to 1 if the VSTQ field contains a report, 0 otherwise. 718 Rsd.: 3 bits 719 This field is reserved for future definition. In the absence of 720 such a definition, the bits in this field MUST be set to zero and 721 MUST be ignored by the receiver. 723 SSRC of source: 32 bits 724 As defined in Section 4.1 of [RFC3611]. 726 MOS-V: 16 bits 727 The estimated mean opinion score for video quality (MOS-V) is a 728 video quality metric on a scale from 1 to 5, in which 5 represents 729 excellent and 1 represents unacceptable [G.1082][P.NAMS]. This 730 metric is defined as not including the effects of audio 731 impairments and can be compared to MOS scores obtained from video 732 quality tests. It is expressed as an integer in the range 10 to 733 50, corresponding to MOS x 10. For example, a value of 35 would 734 correspond to an estimated MOS score of 3.5. 736 A value of 127 indicates that this parameter is unavailable. 737 Values other than 127 and the valid range defined above MUST NOT 738 be sent and MUST be ignored by the receiving system. 740 MOS-A: 16 bits 741 The estimated mean opinion score for Audio quality (MOS-A) is 742 defined as including the effects of delay and other effects that 743 would affect Audio-Video quality [RFC3611]. It is expressed as an 744 integer in the range 10 to 50, corresponding to MOS x 10, as for 745 MOS-A. 747 A value of 127 indicates that this parameter is unavailable. 748 Values other than 127 and the valid range defined above MUST not 749 be sent and MUST be ignored by the receiving system. 751 MOS-AV: 16 bits 753 The estimated mean opinion score for Audio-Video quality (MOS-AV) 754 is defined as including the effects of delay and other effects 755 that would affect Audio-Video quality [G.1082][P.NAMS]. It is 756 expressed as an integer in the range 10 to 50, corresponding to 757 MOS x 10, as for MOS-AV. A value of 127 indicates that this 758 parameter is unavailable. Values other than 127 and the valid 759 range defined above MUST NOT be sent and MUST be ignored by the 760 receiving system. 762 VSTQ: 16 bits 763 Video Service Transmission Quality (TBC) . 765 6. SDP Signaling 767 Six new parameters are defined for the six report blocks defined in 768 this document to be used with Session Description Protocol (SDP) 769 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 770 They have the following syntax within the "rtcp-xr" attribute 771 [RFC3611]: 773 rtcp-xr-attrib = "a=rtcp-xr:" 774 [xr-format *(SP xr-format)] CRLF 776 xr-format = RTP-flows-syn 777 / audio-video-ofset 778 / multimedia-quality-metrics 779 / video-stream-loss-metrics 780 / video-stream-burst-metrics 781 / video-stat-summary 782 / layered-video-stat-metrics 784 RTP-flows-syn = "RTP-flows-syn" 785 ["=" max-size] 786 max-size = 1*DIGIT ; maximum block size in octets 788 audio-video-ofset = "audio-video-ofset" 789 ["=" max-size] 790 max-size = 1*DIGIT ; maximum block size in octets 792 video-stream-burst-metrics = "video-stream-burst-metrics" 793 ["=" max-size] 794 max-size = 1*DIGIT ; maximum block size in octets 796 video-stream-loss-metrics = "video-stream-loss-metrics" 797 ["=" stat-flag *("," stat-flag)] 798 stat-flag = "key Frame loss and duplication" 799 / "derivation Frame loss and duplication" 801 video-stat-summary = "video-stat-summary" 802 ["=" stat-flag *("," stat-flag)] 803 stat-flag = "key Frame loss and duplication" 804 / "derivation Frame loss and duplication" 806 layered-stream-stat-metrics = "layered-stream-stat-metrics" 807 ["=" stat-flag *("," stat-flag)] 808 stat-flag = "base layer packet" 809 / "enhancment layer packet" 811 multimedia-quality-metrics = "multimedia-quality-metrics" 812 ["=" stat-flag *("," stat-flag)] 813 stat-flag = "Interval Metric" 814 / "MOS-V" 815 / "MOS-A" 816 / "MOS-AV" 817 / "VSTQ" 819 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 820 and the full syntax of the "rtcp-xr" attribute. 822 7. IANA Considerations 824 New report block types for RTCP XR are subject to IANA registration. 825 For general guidelines on IANA allocations for RTCP XR, refer to 826 Section 6.2 of [RFC3611]. 828 This document assigns six new block type values in the RTCP XR Block 829 Type Registry: 831 Name: RFISD 832 Long Name: RTP Flows Initial Synchronization Delay 833 Value 834 Reference: Section 4.1 836 Name: AVPO 837 Long Name: Audio-Video Playout Offset 838 Value 839 Reference: Section 4.2 841 Name: VSS 842 Long Name: Video Statistics Summary 843 Value 844 Reference: Section 5.1 846 Name: LSSM 847 Value 848 Long Name: Layered Stream Statistics Metrics 849 Reference: Section 4.3 851 Name: VSLDM 852 Long Name: Video Stream Loss and Discard Metrics 853 Value 854 Reference: Section 5.2 856 Name: VSBM 857 Long Name: Video Stream Burst Metrics 858 Value 859 Reference: Section 5.3 861 Name: SMQM 862 Long Name: Synthetical Multimedia Quality Metric 863 Value 864 Reference: Section 5.4 866 This document also registers seven SDP [RFC4566] parameters for the 867 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 869 * "RTP-flows-syn" 870 * "audio-video-ofset" 871 * "multimedia-quality-metrics" 872 * "video-stream-loss-metrics" 873 * "video-stream-burst-metrics" 874 * "video-stat-summary" 875 * "layered-stream-stat-metrics" 877 The contact information for the registrations is: 879 Qin Wu 880 sunseawq@huawei.com 881 101 Software Avenue, Yuhua District 882 Nanjing, JiangSu 210012 China 884 8. Security Considerations 886 TBC 888 9. Acknowledgements 890 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 891 Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang 892 Hu for their valuable comments and suggestions on this document. 894 10. References 896 10.1. Normative References 898 [I-D.ietf-avt-rapid-rtp-sync] 899 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 900 Flows", draft-ietf-avt-rapid-rtp-sync-12 (work in 901 progress), July 2010. 903 [I-D.ietf-avt-rtp-svc] 904 Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 905 "RTP Payload Format for Scalable Video Coding", 906 draft-ietf-avt-rtp-svc-23 (work in progress), 907 October 2010. 909 [ISO-IEC.13818-1.2007] 910 International Organization for Standardization, 911 "Information technology - Generic coding of moving 912 pictures and associated audio information: Systems", 913 ISO International Standard 13818-1, October 2007. 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, March 1997. 918 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 919 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 920 January 1998. 922 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 923 Jacobson, "RTP: A Transport Protocol for Real-Time 924 Applications", STD 64, RFC 3550, July 2003. 926 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 927 Protocol Extended Reports (RTCP XR)", RFC 3611, 928 November 2003. 930 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 931 Description Protocol", RFC 4566, July 2006. 933 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 934 Specifications: ABNF", STD 68, RFC 5234, January 2008. 936 10.2. Informative References 938 [DSLF] Rahrer, T., Ed., Fiandra, Ed., and Wright, Ed., "Triple- 939 play Services Quality of Experience (QoE) Requirements", 940 DSL Forum Technical Report TR-126, December 2006. 942 [G.1082] ITU-T, "Measurement-based methods for improving the 943 robustness of IPTV performance", ITU-T 944 Recommendation G.1082, April 2009. 946 [I-D.ietf-fecframe-interleaved-fec-scheme] 947 Begen, A., "RTP Payload Format for 1-D Interleaved Parity 948 FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work 949 in progress), January 2010. 951 [I-D.ietf-fecframe-raptor] 952 Waston, M., "Raptor FEC Schemes for FECFRAME", 953 draft-ietf-fecframe-raptor-02 (work in progress), 954 March 2010. 956 [IEEE] IEEE, "Human Perception of Jitter and Media 957 Synchronization", IEEE Journal on Selected Areas in 958 Communications Vol. 14, No. 1, January 1996. 960 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 961 of performance of Multimedia Streaming", ITU-T 962 Recommendation P.NAMS, November 2009. 964 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 965 Metrics", RFC 3357, August 2002. 967 Authors' Addresses 969 Qin Wu 970 Huawei 971 101 Software Avenue, Yuhua District 972 Nanjing, Jiangsu 210012 973 China 975 Email: sunseawq@huawei.com 977 Glen Zorn 978 Network Zen 979 77/440 Soi Phoomjit, Rama IV Road 980 Phra Khanong, Khlong Toie 981 Bangkok 10110 982 Thailand 984 Phone: +66 (0) 87 502 4274 985 Email: gwz@net-zen.net 987 Roland Schott 988 Deutsche Telekom Laboratories 989 Deutsche-Telekom-Allee 7 990 Darmstadt 64295 991 Germany 993 Email: Roland.Schott@telekom.de