idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-loss-conceal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 12, 2012) is 4336 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: 'RFC2119' is defined on line 364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group G. Hunt 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track A. Clark 5 Expires: December 14, 2012 Telchemy 6 G. Zorn 7 Network Zen 8 C. Bi 9 STTRI 10 Q. Wu 11 Huawei 12 June 12, 2012 14 RTCP XR Report Block for Loss Concealment metric Reporting 15 draft-ietf-xrblock-rtcp-xr-loss-conceal-00.txt 17 Abstract 19 This document defines an RTCP XR Report Block that allows the 20 reporting of Loss Concealment metrics primarily for audio 21 applications of RTP. 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 December 14, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Loss Concealment Report Block . . . . . . . . . . . . . . 3 59 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 60 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 61 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Loss Concealment Block . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 64 2.2. Definition of Fields in Loss Concealment Report Block . . 5 65 3. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 10 68 4.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 10 69 4.3. Contact information for registrations . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 76 A.1. draft-ietf-xrblock-rtcp-xr-loss-conceal-00 . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 1.1. Loss Concealment Report Block 83 This draft defines a new block type to augment those defined in 84 [RFC3611], for use in a range of RTP applications. 86 At any instant, the audio output at a receiver may be classified as 87 either 'normal' or 'concealed'. 'Normal' refers to playout of audio 88 payload received from the remote end, and also includes locally 89 generated signals such as announcements, tones and comfort noise. 90 Concealment refers to playout of locally-generated signals used to 91 mask the impact of network impairments or to reduce the audibility of 92 jitter buffer adaptations. 94 The new block type provides metrics for actions taken by the receiver 95 to mitigate the effect of packet loss and packet discard. 96 Specifically, the first metric (On-Time Playout Duration) reports the 97 duration of normal playout of data which the receiver obtained from 98 the sender's stream. A second metric (Loss Concealment Duration) 99 reports the total time during which the receiver played out media 100 data which was manufactured locally, because the sender's data for 101 these periods was not available due to packet loss or discard. A 102 similar metric (Buffer Adjustment Concealment Duration) reports the 103 duration of playout of locally-manufactured data replacing data which 104 is unavailable due to adaptation of an adaptive de-jitter buffer. 105 Further metrics (Playout Interrupt Count and Mean Playout Interrupt 106 Size) report the number of times normal playout was interrupted, and 107 the mean duration of these interruptions. 109 Loss Concealment Duration and Buffer Adjustment Concealment Duration 110 are reported separately because buffer adjustment is typically 111 arranged to occur in silence periods so may have very little impact 112 on user experience, whilst loss concealment may occur at any time. 114 The metric belongs to the class of transport-related terminal metrics 115 defined in [MONARCH] (work in progress). 117 1.2. RTCP and RTCP XR Reports 119 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 120 defined an extensible structure for reporting using an RTCP Extended 121 Report (XR). This draft defines a new Extended Report block that 122 MUST be used as defined in [RFC3550] and [RFC3611]. 124 1.3. Performance Metrics Framework 126 The Performance Metrics Framework [RFC6390] provides guidance on the 127 definition and specification of performance metrics. The RTP 128 Monitoring Architectures [MONARCH] provides guideline for reporting 129 block format using RTCP XR. The Metrics Block described in this 130 document are in accordance with the guidelines in [RFC6390] and 131 [MONARCH]. 133 1.4. Applicability 135 This metric is primarily applicable to audio applications of RTP. 136 EDITOR'S NOTE: are there metrics for concealment of transport errors 137 for video? 139 2. Loss Concealment Block 141 2.1. Report Block Structure 143 Loss Concealment metrics block 145 0 1 2 3 146 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | BT=NLC | I |plc| rsv. | block length=5 | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | SSRC of Source | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | On-time Playout Duration | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Loss Concealment Duration | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Buffer Adjustment Concealment Duration | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Playout Interrupt Count | Mean Playout Interrupt Size | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Report Block Structure 163 2.2. Definition of Fields in Loss Concealment Report Block 165 Block type (BT): 8 bits 167 A Loss Concealment Metrics Report Block is identified by the 168 constant NLC. 170 [Note to RFC Editor: please replace NLC with the IANA provided 171 RTCP XR block type for this block.] 173 Interval Metric flag (I): 2 bit 175 This field is used to indicate whether the Delay metrics are 176 Sampled, Interval or Cumulative metrics, that is, whether the 177 reported values applies to the most recent measurement interval 178 duration between successive metrics reports (I=10) (the Interval 179 Duration) or to the accumulation period characteristic of 180 cumulative measurements (I=11) (the Cumulative Duration) or is a 181 sampled instantaneous value (I=01) (Sampled Value). 183 Packet Loss Concealment Method (plc): 2 bits 185 This field is used to identify the packet loss concealment method 186 in use at the receiver, according to the following code: 188 bits 014-015 190 0 = silence insertion 192 1 = simple replay, no attenuation 194 2 = simple replay, with attenuation 196 3 = enhanced 198 Other values reserved 200 Reserved (resv): 4 bits 202 These bits are reserved. They SHOULD be set to zero by senders 203 and MUST be ignored by receivers. 205 block length: 16 bits 207 The length of this report block in 32-bit words, minus one. For 208 the Delay block, the block length is equal to 5. 210 SSRC of source: 32 bits 212 As defined in Section 4.1 of [RFC3611]. 214 On-time Playout Duration (ms): 32 bits 216 'On-time' playout is the uninterrupted, in-sequence playout of 217 valid decoded audio information originating from the remote 218 endpoint. This includes comfort noise during periods of remote 219 talker silence, if VAD is used, and locally generated or 220 regenerated tones and announcements. 222 An equivalent definition is that on-time playout is playout of any 223 signal other than those used for concealment. 225 On-time playout duration MUST include both speech and silence 226 intervals, whether VAD is used or not. This duration is reported 227 in millisecond units. 229 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 230 SHOULD be reported to indicate an over-range measurement. If the 231 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 232 reported. 234 Loss Concealment Duration (ms): 32 bits 236 The duration, in milliseconds, of audio playout corresponding to 237 Loss-type concealment. 239 Loss-type concealment is reactive insertion or deletion of samples 240 in the audio playout stream due to effective frame loss at the 241 audio decoder. "Effective frame loss" is the event in which a 242 frame of coded audio is simply not present at the audio decoder 243 when required. In this case, substitute audio samples are 244 generally formed, at the decoder or elsewhere, to reduce audible 245 impairment. 247 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 248 SHOULD be reported to indicate an over-range measurement. If the 249 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 250 reported. 252 Buffer Adjustment Concealment Duration (ms): 32 bits 254 The duration, in milliseconds, of audio playout corresponding to 255 Buffer Adjustment-type concealment, if known. 257 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 258 SHOULD be reported to indicate an over-range measurement. If the 259 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 260 reported. 262 Buffer Adjustment-type concealment is proactive or controlled 263 insertion or deletion of samples in the audio playout stream due 264 to jitter buffer adaptation, re-sizing or re-centering decisions 265 within the endpoint. 267 Because this insertion is controlled, rather than occurring 268 randomly in response to losses, it is typically less audible than 269 loss-type concealment. For example, jitter buffer adaptation 270 events may be constrained to occur during periods of talker 271 silence, in which case only silence duration is affected, or 272 sophisticated time-stretching methods for insertion/deletion 273 during favorable periods in active speech may be employed. 275 Concealment events which cannot be classified as Buffer 276 Adjustment- type MUST be classified as Loss-type. 278 Playout Interrupt Count: 16 bits 280 The number of interruptions to normal playout which occurred 281 during the reporting period. 283 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 284 reported to indicate an over-range measurement. If the 285 measurement is unavailable, the value 0xFFFF SHOULD be reported. 287 Mean Playout Interrupt Size (ms): 16 bits 289 The mean duration, in ms, of interruptions to normal playout which 290 occurred during the reporting period. 292 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 293 reported to indicate an over-range measurement. If the 294 measurement is unavailable, the value 0xFFFF SHOULD be reported. 296 3. SDP Signaling 298 [RFC3611] defines the use of SDP (Session Description Protocol) 299 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 300 without prior signaling. 302 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 303 in [RFC3611] by providing an additional value of "xr-format" to 304 signal the use of the report block defined in this document. 306 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 308 (defined in [RFC3611]) 310 xr-format =/ xr-conceal-block 312 xr-conceal-block = "loss-conceal" 314 4. IANA Considerations 316 New block types for RTCP XR are subject to IANA registration. For 317 general guidelines on IANA considerations for RTCP XR, refer to 318 [RFC3611]. 320 4.1. New RTCP XR Block Type value 322 This document assigns the block type value NJB in the IANA "RTCP XR 323 Block Type Registry" to the "Loss Concealment Metrics Block". 325 [Note to RFC Editor: please replace NLC with the IANA provided RTCP 326 XR block type for this block.] 328 4.2. New RTCP XR SDP Parameter 330 This document also registers a new parameter "loss-conceal" in the 331 "RTCP XR SDP Parameters Registry". 333 4.3. Contact information for registrations 335 The contact information for the registrations is: 337 Alan Clark (alan.d.clark@telchemy.com) 339 2905 Premiere Parkway, Suite 280 340 Duluth, GA 30097 341 USA 343 5. Security Considerations 345 It is believed that this proposed RTCP XR report block introduces no 346 new security considerations beyond those described in [RFC3611]. 347 This block does not provide per-packet statistics so the risk to 348 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 349 does not apply. 351 6. Acknowledgements 353 The authors gratefully acknowledge the comments and contributions 354 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 355 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 356 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 357 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 358 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 360 7. References 362 7.1. Normative References 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", March 1997. 367 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 368 Applications", RFC 3550, July 2003. 370 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 371 Protocol Extended Reports (RTCP XR)", November 2003. 373 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 374 Description Protocol", July 2006. 376 7.2. Informative References 378 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 379 ID draft-ietf-avtcore-monarch-04, August 2011. 381 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 382 Development", RFC 6390, October 2011. 384 Appendix A. Change Log 386 Note to the RFC-Editor: please remove this section prior to 387 publication as an RFC. 389 A.1. draft-ietf-xrblock-rtcp-xr-loss-conceal-00 391 The following are the major changes to previous version : 393 o Changed BNF for SDP following Christian Groves' and Tom Taylor's 394 comments (4th and 5th May 2009). 396 o Updated references. 398 Authors' Addresses 400 Geoff Hunt 401 Unaffiliated 403 Email: r.geoff.hunt@gmail.com 405 Alan Clark 406 Telchemy Incorporated 407 2905 Premiere Parkway, Suite 280 408 Duluth, GA 30097 409 USA 411 Email: alan.d.clark@telchemy.com 413 Glen Zorn 414 Network Zen 415 77/440 Soi Phoomjit, Rama IV Road 416 Phra Khanong, Khlong Toie 417 Bangkok 10110 418 Thailand 420 Phone: +66 (0) 87 502 4274 421 Email: gwz@net-zen.net 423 Claire Bi 424 Shanghai Research Institure of China Telecom Corporation Limited 425 No.1835,South Pudong Road 426 Shanghai 200122 427 China 429 Email: bijy@sttri.com.cn 431 Qin Wu 432 Huawei 433 101 Software Avenue, Yuhua District 434 Nanjing, Jiangsu 210012 435 China 437 Email: sunseawq@huawei.com