idnits 2.17.1 draft-ietf-avt-rtcp-xr-loss-conceal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. 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 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2008) is 5633 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 328, but no explicit reference was found in the text -- No information found for draft-ietf-avt-rtcp-xr-measid - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEASIDENT' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-12) exists of draft-ietf-pmol-metrics-framework-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working G. Hunt 3 Group BT 4 Internet-Draft A. Clark 5 Intended status: Standards Track Telchemy 6 Expires: April 28, 2009 October 25, 2008 8 RTCP XR Report Block for Loss Concealment metric Reporting 9 draft-ietf-avt-rtcp-xr-loss-conceal-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 28, 2009. 36 Abstract 38 This document defines an RTCP XR Report Block that allows the 39 reporting of Loss Concealment metrics primarily for audio 40 applications of RTP. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Loss Concealment Report Block . . . . . . . . . . . . . . 3 46 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 47 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 48 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Loss Concealment Block . . . . . . . . . . . . . . . . . . . . 5 50 2.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 51 2.2. Definition of Fields in Loss Concealment Report Block . . 5 52 3. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 55 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 60 Intellectual Property and Copyright Statements . . . . . . . . . . 15 62 1. Introduction 64 1.1. Loss Concealment Report Block 66 This draft defines a new block type to augment those defined in 67 [RFC3611], for use in a range of RTP applications. 69 At any instant, the audio output at a receiver may be classified as 70 either 'normal' or 'concealed'. 'Normal' refers to playout of audio 71 payload received from the remote end, and also includes locally 72 generated signals such as announcements, tones and comfort noise. 73 Concealment refers to playout of locally-generated signals used to 74 mask the impact of network impairments or to reduce the audibility of 75 jitter buffer adaptations. 77 The new block type provides metrics for actions taken by the receiver 78 to mitigate the effect of packet loss and packet discard. 79 Specifically, the first metric (On-Time Playout Duration) reports the 80 duration of normal playout of data which the receiver obtained from 81 the sender's stream. A second metric (Loss Concealment Duration) 82 reports the total time during which the receiver played out media 83 data which was manufactured locally, because the sender's data for 84 these periods was not available due to packet loss. A similar metric 85 (Buffer Adjustment Concealment Duration) reports the duration of 86 playout of locally-manufactured data replacing data which is 87 unavailable due to adaptation of an adaptive de-jitter buffer. 88 Further metrics (Playout Interrupt Count and Mean Playout Interrupt 89 Size) report the number of times normal playout was interrupted, and 90 the mean duration of these interruptions. 92 Loss Concealment Duration and Buffer Adjustment Concealment Duration 93 are reported separately because buffer adjustment is typically 94 arranged to occur in silence periods so may have very little impact 95 on user experience, whilst loss concealment may occur at any time. 97 The metric belongs to the class of transport-related terminal metrics 98 defined in [MONARCH] (work in progress). 100 Instances of this Metrics Block refer by tag to the separate 101 auxiliary Measurement Identity block [MEASIDENT] which contains 102 information such as the SSRC of the measured stream, and RTP sequence 103 numbers and time intervals indicating the span of the report. 105 1.2. RTCP and RTCP XR Reports 107 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 108 defined an extensible structure for reporting using an RTCP Extended 109 Report (XR). This draft defines a new Extended Report block that 110 MUST be used as defined in [RFC3550] and [RFC3611]. 112 1.3. Performance Metrics Framework 114 The Performance Metrics Framework [PMOLFRAME] provides guidance on 115 the definition and specification of performance metrics. Metrics 116 described in this draft either reference external definitions or 117 define metrics generally in accordance with the guidelines in 118 [PMOLFRAME]. 120 1.4. Applicability 122 This metric is primarily applicable to audio applications of RTP. 123 EDITOR'S NOTE: are there metrics for concealment of transport errors 124 for video? 126 2. Loss Concealment Block 128 2.1. Report Block Structure 130 Loss Concealment metrics block 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | BT=NLC |I| tag |plc|rsv| block length=4 | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | On-time Playout Duration | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Loss Concealment Duration | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Buffer Adjustment Concealment Duration | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Playout Interrupt Count | Mean Playout Interrupt Size | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1: Report Block Structure 147 2.2. Definition of Fields in Loss Concealment Report Block 149 block type (BT): 8 bits 151 A Loss Concealment Metrics Report Block is identified by the 152 constant NLC. 154 [Note to RFC Editor: please replace NLC with the IANA provided RTCP 155 XR block type for this block.] 157 Interval Metric flag (I): 1 bit 159 This field is used to indicate whether the Loss Concealment metric 160 block is an Interval or a Cumulative report, that is, whether the 161 reported values apply to the most recent measurement interval 162 duration between successive metrics reports (I=1) (the Interval 163 Duration) or to the accumulation period characteristic of 164 cumulative measurements (I=0) (the Cumulative Duration). 165 Numerical values for both these intervals are provided in the 166 Measurement Identifier block referenced by the tag field below. 168 Measurement Identifier association (tag): 3 bits 170 This field is used to identify the Measurement Identifier block 171 [MEASIDENT] which describes this measurement. The relevant 172 Measurement Identifier block has the same tag value as the Loss 173 Concealment Metrics block. Note that there may be more than one 174 Measurement Identifier block per RTCP packet. 176 Packet Loss Concealment Method (plc): 2 bits 178 This field is used to identify the packet loss concealment method 179 in use at the receiver, according to the following code: 181 bits 014-015 182 0 = silence insertion 183 1 = simple replay, no attenuation 184 2 = simple replay, with attenuation 185 3 = enhanced 187 Reserved (rsv): 2 bits 189 These bits are reserved. They SHOULD be set to zero by senders 190 and MUST be ignored by receivers. 192 block length: 16 bits 194 The length of this report block in 32-bit words, minus one. For 195 the Loss Concealment Metrics block, the block length is equal to 196 4. 198 On-time Playout Duration (ms): 32 bits 200 'On-time' playout is the uninterrupted, in-sequence playout of 201 valid decoded audio information originating from the remote 202 endpoint. This includes comfort noise during periods of remote 203 talker silence, if VAD is used, and locally generated or 204 regenerated tones and announcements. 206 An equivalent definition is that on-time playout is playout of any 207 signal other than those used for concealment. 209 On-time playout duration MUST include both speech and silence 210 intervals, whether VAD is used or not. This duration is reported 211 in millisecond units. 213 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 214 SHOULD be reported to indicate an over-range measurement. If the 215 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 216 reported. 218 Loss Concealment Duration (ms): 32 bits 219 The duration, in milliseconds, of audio playout corresponding to 220 Loss-type concealment. 222 Loss-type concealment is reactive insertion or deletion of samples 223 in the audio playout stream due to effective frame loss at the 224 audio decoder. "Effective frame loss" is the event in which a 225 frame of coded audio is simply not present at the audio decoder 226 when required. In this case, substitute audio samples are 227 generally formed, at the decoder or elsewhere, to reduce audible 228 impairment. 230 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 231 SHOULD be reported to indicate an over-range measurement. If the 232 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 233 reported. 235 Buffer Adjustment Concealment Duration (ms): 32 bits 237 The duration, in milliseconds, of audio playout corresponding to 238 Buffer Adjustment-type concealment, if known. 240 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 241 SHOULD be reported to indicate an over-range measurement. If the 242 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 243 reported. 245 Buffer Adjustment-type concealment is proactive or controlled 246 insertion or deletion of samples in the audio playout stream due 247 to jitter buffer adaptation, re-sizing or re-centering decisions 248 within the endpoint. 250 Because this insertion is controlled, rather than occurring 251 randomly in response to losses, it is typically less audible than 252 loss-type concealment. For example, jitter buffer adaptation 253 events may be constrained to occur during periods of talker 254 silence, in which case only silence duration is affected, or 255 sophisticated time-stretching methods for insertion/deletion 256 during favorable periods in active speech may be employed. 258 Concealment events which cannot be classified as Buffer 259 Adjustment- type MUST be classified as Loss-type. 261 Playout Interrupt Count: 16 bits 263 The number of interruptions to normal playout which occurred 264 during the reporting period. 266 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 267 reported to indicate an over-range measurement. If the 268 measurement is unavailable, the value 0xFFFF SHOULD be reported. 270 Mean Playout Interrupt Size (ms): 16 bits 272 The mean duration, in ms, of interruptions to normal playout which 273 occurred during the reporting period. 275 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 276 reported to indicate an over-range measurement. If the 277 measurement is unavailable, the value 0xFFFF SHOULD be reported. 279 3. SDP Signaling 281 [RFC3611] defines the use of SDP (Session Description Protocol) 282 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 283 without prior signaling. 285 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 286 in [RFC3611] by providing an additional value of "xr-format" to 287 signal the use of the report block defined in this document. 289 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 291 (defined in [RFC3611]) 293 xr-format = xr-format / xr-conceal-block 295 xr-bgld-block = "xr-conceal" 297 4. IANA Considerations 299 This document creates a new block type within the IANA "RTCP XR Block 300 Type Registry" called the Loss Concealment Metrics Block, and a new 301 parameter xr-conceal within the "RTCP XR SDP Parameters Registry". 303 5. Security Considerations 305 It is believed that this proposed RTCP XR report block introduces no 306 new security considerations beyond those described in [RFC3611]. 307 This block does not provide per-packet statistics so the risk to 308 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 309 does not apply. 311 6. Contributors 313 The authors gratefully acknowledge the comments and contributions 314 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 315 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 316 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 317 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 318 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 320 7. References 322 7.1. Normative References 324 [MEASIDENT] 325 Hunt, G., "RTCP XR Measurement Identifier Block", 326 ID draft-ietf-avt-rtcp-xr-measid-00, August 2008. 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", RFC 2119, BCP 14, March 1997. 331 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 332 Applications", RFC 3550, July 2003. 334 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 335 XR)", RFC 3611, November 2003. 337 [RFC4566] Handley, M., "SDP: Session Description Protocol", 338 RFC 4566, July 2006. 340 7.2. Informative References 342 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 343 ID draft-hunt-avt-monarch-01, August 2008. 345 [PMOLFRAME] 346 Clark, A., "Framework for Performance Metric Development", 347 ID draft-ietf-pmol-metrics-framework-00, July 2008. 349 Authors' Addresses 351 Geoff Hunt 352 BT 353 Orion 1 PP9 354 Adastral Park 355 Martlesham Heath 356 Ipswich, Suffolk IP4 2TH 357 United Kingdom 359 Phone: +44 1473 608325 360 Email: geoff.hunt@bt.com 362 Alan Clark 363 Telchemy Incorporated 364 2905 Premiere Parkway, Suite 280 365 Duluth, GA 30097 366 USA 368 Email: alan.d.clark@telchemy.com 370 Full Copyright Statement 372 Copyright (C) The IETF Trust (2008). 374 This document is subject to the rights, licenses and restrictions 375 contained in BCP 78, and except as set forth therein, the authors 376 retain all their rights. 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 381 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 382 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 383 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Intellectual Property 388 The IETF takes no position regarding the validity or scope of any 389 Intellectual Property Rights or other rights that might be claimed to 390 pertain to the implementation or use of the technology described in 391 this document or the extent to which any license under such rights 392 might or might not be available; nor does it represent that it has 393 made any independent effort to identify any such rights. Information 394 on the procedures with respect to rights in RFC documents can be 395 found in BCP 78 and BCP 79. 397 Copies of IPR disclosures made to the IETF Secretariat and any 398 assurances of licenses to be made available, or the result of an 399 attempt made to obtain a general license or permission for the use of 400 such proprietary rights by implementers or users of this 401 specification can be obtained from the IETF on-line IPR repository at 402 http://www.ietf.org/ipr. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights that may cover technology that may be required to implement 407 this standard. Please address the information to the IETF at 408 ietf-ipr@ietf.org.