idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-loss-conceal-01.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 (June 22, 2012) is 4326 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-16 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 C. Bi 3 Internet-Draft STTRI 4 Intended status: Standards Track A. Clark 5 Expires: December 24, 2012 Telchemy 6 G. Hunt 7 Unaffiliated 8 Q. Wu 9 Huawei 10 G. Zorn, Ed. 11 Network Zen 12 June 22, 2012 14 RTCP XR Report Block for Loss Concealment Metric Reporting 15 draft-ietf-xrblock-rtcp-xr-loss-conceal-01.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 24, 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. Standards Language . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Loss Concealment Report Block . . . . . . . . . . . . . . . 3 60 1.3. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 61 1.4. Performance Metrics Framework . . . . . . . . . . . . . . . 4 62 1.5. Applicability . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Loss Concealment Block . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Report Block Structure . . . . . . . . . . . . . . . . . . 4 65 2.2. Definition of Fields in Loss Concealment Report Block . . . 4 66 3. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 8 69 4.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 8 70 4.3. Contact Information for Registrations . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 1.1. Standards Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 1.2. Loss Concealment Report Block 87 This draft defines a new block type to augment those defined in 88 Friedman, et al. [RFC3611] for use in a range of RTP applications. 90 At any instant, the audio output at a receiver may be classified as 91 either 'normal' or 'concealed'. 'Normal' refers to playout of audio 92 payload received from the remote end, and also includes locally 93 generated signals such as announcements, tones and comfort noise. 94 Concealment refers to playout of locally-generated signals used to 95 mask the impact of network impairments or to reduce the audibility of 96 jitter buffer adaptations. 98 The new block type provides metrics for actions taken by the receiver 99 to mitigate the effect of packet loss and packet discard. 100 Specifically, the first metric (On-Time Playout Duration) reports the 101 duration of normal playout of data which the receiver obtained from 102 the sender's stream. A second metric (Loss Concealment Duration) 103 reports the total time during which the receiver played out media 104 data which was manufactured locally, because the sender's data for 105 these periods was not available due to packet loss or discard. A 106 similar metric (Buffer Adjustment Concealment Duration) reports the 107 duration of playout of locally-manufactured data replacing data which 108 is unavailable due to adaptation of an adaptive de-jitter buffer. 109 Further metrics (Playout Interrupt Count and Mean Playout Interrupt 110 Size) report the number of times normal playout was interrupted, and 111 the mean duration of these interruptions. 113 Loss Concealment Duration and Buffer Adjustment Concealment Duration 114 are reported separately because buffer adjustment is typically 115 arranged to occur in silence periods so may have very little impact 116 on user experience, whilst loss concealment may occur at any time. 118 The metric belongs to the class of transport-related terminal metrics 119 defined in Wu, et al. [I-D.ietf-avtcore-monarch]. 121 1.3. RTCP and RTCP XR Reports 123 The use of RTCP for reporting is defined in Schulzrinne, et 124 al. [RFC3550]. Friedman, Cacares & Clark [RFC3611] define an 125 extensible structure for reporting using an RTCP Extended Report 126 (XR). This draft defines a new Extended Report block that MUST be 127 used as defined in RFC 3550 and RFC 3611. 129 1.4. Performance Metrics Framework 131 Clark & Claise [RFC6390] provides guidance on the definition and 132 specification of performance metrics. Wu, et 133 al. [I-D.ietf-avtcore-monarch] provides guidelines for RTCP XR report 134 block formats. The report block defined in this document is in 135 accordance with those guidelines. 137 1.5. Applicability 139 This metric is primarily applicable to audio applications of RTP. 140 EDITOR'S NOTE: are there metrics for concealment of transport errors 141 for video? 143 2. Loss Concealment Block 145 2.1. Report Block Structure 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | BT=NLC | I |plc| rsv. | block length=5 | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | SSRC of Source | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | On-time Playout Duration | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Loss Concealment Duration | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Buffer Adjustment Concealment Duration | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Playout Interrupt Count | Mean Playout Interrupt Size | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: Structure of the Loss Concealment Metrics Block 165 2.2. Definition of Fields in Loss Concealment Report Block 167 Block type (BT): 8 bits 169 A Loss Concealment Metrics Report Block is identified by the 170 constant . 172 [Note to RFC Editor: please replace with the IANA provided 173 RTCP XR block type for this block.] 175 Interval Metric flag (I): 2 bit 177 This field is used to indicate whether the Delay metrics are 178 Sampled, Interval or Cumulative metrics, that is, whether the 179 reported values applies to the most recent measurement interval 180 duration between successive metrics reports (I=10) (the Interval 181 Duration) or to the accumulation period characteristic of 182 cumulative measurements (I=11) (the Cumulative Duration) or is a 183 sampled instantaneous value (I=01) (Sampled Value). 185 Packet Loss Concealment Method (plc): 2 bits 187 This field is used to identify the packet loss concealment method 188 in use at the receiver, according to the following code: 190 bits 014-015 192 0 = silence insertion 194 1 = simple replay, no attenuation 196 2 = simple replay, with attenuation 198 3 = enhanced 200 Other values reserved 202 Reserved (resv): 4 bits 204 These bits are reserved. They SHOULD be set to zero by senders 205 and MUST be ignored by receivers. 207 block length: 16 bits 209 The length of this report block in 32-bit words, minus one. For 210 the Delay block, the block length is equal to 5. 212 SSRC of source: 32 bits 214 As defined in Section 4.1 of RFC 3611. 216 On-time Playout Duration (ms): 32 bits 218 'On-time' playout is the uninterrupted, in-sequence playout of 219 valid decoded audio information originating from the remote 220 endpoint. This includes comfort noise during periods of remote 221 talker silence, if voice activity detection (VAD) is in use, and 222 locally generated or regenerated tones and announcements. 224 An equivalent definition is that on-time playout is playout of any 225 signal other than those used for concealment. 227 On-time playout duration MUST include both speech and silence 228 intervals, whether VAD is used or not. This duration is reported 229 in millisecond units. 231 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 232 SHOULD be reported to indicate an over-range measurement. If the 233 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 234 reported. 236 Loss Concealment Duration (ms): 32 bits 238 The duration, in milliseconds, of audio playout corresponding to 239 Loss-type concealment. 241 Loss-type concealment is reactive insertion or deletion of samples 242 in the audio playout stream due to effective frame loss at the 243 audio decoder. "Effective frame loss" is the event in which a 244 frame of coded audio is simply not present at the audio decoder 245 when required. In this case, substitute audio samples are 246 generally formed, at the decoder or elsewhere, to reduce audible 247 impairment. 249 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 250 SHOULD be reported to indicate an over-range measurement. If the 251 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 252 reported. 254 Buffer Adjustment Concealment Duration (ms): 32 bits 256 The duration, in milliseconds, of audio playout corresponding to 257 Buffer Adjustment-type concealment, if known. 259 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 260 SHOULD be reported to indicate an over-range measurement. If the 261 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 262 reported. 264 Buffer Adjustment-type concealment is proactive or controlled 265 insertion or deletion of samples in the audio playout stream due 266 to jitter buffer adaptation, re-sizing or re-centering decisions 267 within the endpoint. 269 Because this insertion is controlled, rather than occurring 270 randomly in response to losses, it is typically less audible than 271 loss-type concealment. For example, jitter buffer adaptation 272 events may be constrained to occur during periods of talker 273 silence, in which case only silence duration is affected, or 274 sophisticated time-stretching methods for insertion/deletion 275 during favorable periods in active speech may be employed. 277 Concealment events which cannot be classified as Buffer 278 Adjustment- type MUST be classified as Loss-type. 280 Playout Interrupt Count: 16 bits 282 The number of interruptions to normal playout which occurred 283 during the reporting period. 285 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 286 reported to indicate an over-range measurement. If the 287 measurement is unavailable, the value 0xFFFF SHOULD be reported. 289 Mean Playout Interrupt Size (ms): 16 bits 291 The mean duration, in ms, of interruptions to normal playout which 292 occurred during the reporting period. 294 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 295 reported to indicate an over-range measurement. If the 296 measurement is unavailable, the value 0xFFFF SHOULD be reported. 298 3. SDP Signaling 300 The use of the Session Description Protocol (SDP) [RFC4566] for 301 signaling the use of XR blocks is described in RFC 3611. XR blocks 302 MAY be used without prior signaling. 304 This section augments the SDP attribute "rtcp-xr" [RFC3611] by 305 providing an additional value of "xr-format" to signal the use of the 306 report block defined in this document. 308 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 310 (defined in [RFC3611]) 312 xr-format =/ xr-conceal-block 314 xr-conceal-block = "loss-conceal" 316 4. IANA Considerations 318 New block types for RTCP XR are subject to IANA registration. For 319 general guidelines on IANA considerations for RTCP XR, refer to RFC 320 3611. 322 4.1. New RTCP XR Block Type value 324 This document assigns the block type value NJB in the IANA "RTCP XR 325 Block Type Registry" to the "Loss Concealment Metrics Block". 327 [Note to RFC Editor: please replace with the RTCP XR block type 328 assigned by IANA for this block.] 330 4.2. New RTCP XR SDP Parameter 332 This document also registers a new parameter "loss-conceal" in the 333 "RTCP XR SDP Parameters Registry". 335 4.3. Contact Information for Registrations 337 The contact information for the registrations is: 339 Alan Clark (alan.d.clark@telchemy.com) 341 2905 Premiere Parkway, Suite 280 342 Duluth, GA 30097 343 USA 345 5. Security Considerations 347 It is believed that this proposed RTCP XR report block introduces no 348 new security considerations beyond those described in RFC 3611. This 349 block does not provide per-packet statistics so the risk to 350 confidentiality documented in Section 7, paragraph 3 of RFC 3611 does 351 not apply. 353 6. Acknowledgements 355 The authors gratefully acknowledge the comments and suggestions made 356 by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, 357 Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, 358 Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, 359 Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi 360 Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 362 7. References 364 7.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs 367 to Indicate Requirement Levels", BCP 14, 368 RFC 2119, March 1997. 370 [RFC3550] Schulzrinne, H., Casner, S., Frederick, 371 R., and V. Jacobson, "RTP: A Transport 372 Protocol for Real-Time Applications", 373 STD 64, RFC 3550, July 2003. 375 [RFC3611] Friedman, T., Caceres, R., and A. Clark, 376 "RTP Control Protocol Extended Reports 377 (RTCP XR)", RFC 3611, November 2003. 379 [RFC4566] Handley, M., Jacobson, V., and C. 380 Perkins, "SDP: Session Description 381 Protocol", RFC 4566, July 2006. 383 7.2. Informative References 385 [I-D.ietf-avtcore-monarch] Wu, W., Hunt, G., and P. Arden, 386 "Guidelines for Use of the RTP Monitoring 387 Framework", draft-ietf-avtcore-monarch-16 388 (work in progress), June 2012. 390 [RFC6390] Clark, A. and B. Claise, "Guidelines for 391 Considering New Performance Metric 392 Development", BCP 170, RFC 6390, 393 October 2011. 395 Authors' Addresses 397 Claire Bi 398 Shanghai Research Institure of China Telecom Corporation Limited 399 No.1835,South Pudong Road 400 Shanghai 200122 401 China 403 EMail: bijy@sttri.com.cn 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 Geoff Hunt 414 Unaffiliated 416 EMail: r.geoff.hunt@gmail.com 418 Qin Wu 419 Huawei 420 101 Software Avenue, Yuhua District 421 Nanjing, Jiangsu 210012 422 China 424 EMail: sunseawq@huawei.com 426 Glen Zorn (editor) 427 Network Zen 428 227/358 Thanon Sanphawut 429 Bang Na, Bangkok 10260 430 Thailand 432 Phone: +66 (0) 90 920 1060 433 EMail: glenzorn@gmail.com