idnits 2.17.1 draft-ietf-avt-rtcp-xr-concsec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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). == 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 'SHALL not' in this paragraph: Equivalently, a concealed second is one in which some Loss-type concealment has occurred. Buffer adjustment-type concealment SHALL not cause Concealed Seconds to be incremented, with the following exception. An implementation MAY cause Concealed Seconds to be incremented for 'emergency' buffer adjustments made during talkspurts. -- 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 (February 25, 2009) is 5532 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 430, 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 (~~), 5 warnings (==), 4 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: August 29, 2009 February 25, 2009 8 RTCP XR Report Block for Concealed Seconds metric Reporting 9 draft-ietf-avt-rtcp-xr-concsec-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines an RTCP XR Report Block that allows the 48 reporting of Concealed Seconds metrics primarily for audio 49 applications of RTP. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Concealed Seconds Block . . . . . . . . . . . . . . . . . 3 55 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 56 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 57 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Concealed Seconds Metrics Block . . . . . . . . . . . . . . . 5 59 2.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 60 2.2. Definition of Fields in Concealed Seconds Metrics Block . 5 61 3. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 4.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 11 64 4.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 11 65 4.3. Contact information for registrations . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7. Changes from previous version . . . . . . . . . . . . . . . . 14 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 1.1. Concealed Seconds Block 78 This draft defines a new block type to augment those defined in 79 [RFC3611], for use primarily in audio applications of RTP. 81 At any instant, the audio output at a receiver may be classified as 82 either 'normal' or 'concealed'. 'Normal' refers to playout of audio 83 payload received from the remote end, and also includes locally 84 generated signals such as announcements, tones and comfort noise. 85 Concealment refers to playout of locally-generated signals used to 86 mask the impact of network impairments such as lost packets or to 87 reduce the audibility of jitter buffer adaptations. 89 The new block type provides metrics for concealment. Specifically, 90 the first metric (Unimpaired Seconds) reports the number of whole 91 seconds occupied only with normal playout of data which the receiver 92 obtained from the sender's stream. The second metric (Concealed 93 Seconds) reports the number of whole seconds during which the 94 receiver played out any locally-generated media data. A third metric 95 (Severely Concealed Seconds) reports the number of whole seconds 96 during which the receiver played out locally-generated data for more 97 than SCS Threshold (ms). 99 The metric belongs to the class of transport-related terminal metrics 100 defined in [MONARCH] (work in progress). 102 Instances of this Metrics Block refer by tag to the separate 103 auxiliary Measurement Identity block [MEASIDENT] which contains 104 information such as the SSRC of the measured stream, and RTP sequence 105 numbers and time intervals indicating the span of the report. 107 1.2. RTCP and RTCP XR Reports 109 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 110 defined an extensible structure for reporting using an RTCP Extended 111 Report (XR). This draft defines a new Extended Report block that 112 MUST be used as defined in [RFC3550] and [RFC3611]. 114 1.3. Performance Metrics Framework 116 The Performance Metrics Framework [PMOLFRAME] provides guidance on 117 the definition and specification of performance metrics. Metrics 118 described in this draft either reference external definitions or 119 define metrics generally in accordance with the guidelines in 120 [PMOLFRAME]. 122 1.4. Applicability 124 This metric is primarily applicable to audio applications of RTP. 125 The reason for this restriction is that, for many video codecs, 126 packet data may contain occasional complete reference pictures, and 127 otherwise consists of data specifying picture changes relative to a 128 complete reference picture. Loss of an RTP video media packet could 129 degrade the user experience for a variable amount of time between the 130 time of loss and the next complete reference picture. In contrast, 131 in the audio case the degradation almost always persists for a 132 predictable period of time from the loss of the packet, which might 133 be simply the duration of the audio data encoded in the lost packet. 134 However if a useful Concealed Seconds metric can be defined for an 135 RTP video application, either in general or for a specific type of 136 video codec, the Concealed Seconds and Severely Concealed Seconds 137 metrics and the metric block type defined here MAY be used. 139 2. Concealed Seconds Metrics Block 141 This sub-block provides a description of potentially audible 142 impairments due to lost and discarded packets at the endpoint, 143 expressed on a time basis analogous to a traditional PSTN T1/E1 144 errored seconds metric. 146 The following metrics are based on successive one second intervals as 147 declared by a local clock. This local clock does NOT need to be 148 synchronized to any external time reference. The starting time of 149 this clock is unspecified. Note that this implies that the same loss 150 pattern could result in slightly different count values, depending on 151 where the losses occur relative to the particular one-second 152 demarcation points. For example, two loss events occurring 50ms 153 apart could result in either one concealed second or two, depending 154 on the particular 1000 ms boundaries used. 156 The seconds in this sub-block are not necessarily calendar seconds. 157 At the tail end of a call, periods of time of less than 1000ms shall 158 be incorporated into these counts if they exceed 500ms and shall be 159 disregarded if they are less than 500ms. 161 2.1. Report Block Structure 163 Concealed seconds metrics block 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | BT=NCS |I| tag |plc|rsv| block length = 3 | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Unimpaired Seconds | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Concealed Seconds | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Severely Concealed Seconds | RESERVED | SCS Threshold | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 1: Report Block Structure 178 2.2. Definition of Fields in Concealed Seconds Metrics Block 180 block type (BT): 8 bits 182 A Concealed Seconds Metrics Report Block is identified by the 183 constant NCS. 185 [Note to RFC Editor: please replace NCS with the IANA provided RTCP 186 XR block type for this block.] 187 Interval Metric flag (I): 1 bit 189 This field is used to indicate whether the Concealed Seconds 190 metric block is an Interval or a Cumulative report, that is, 191 whether the reported values apply to the most recent measurement 192 interval duration between successive metrics reports (I=1) (the 193 Interval Duration) or to the accumulation period characteristic of 194 cumulative measurements (I=0) (the Cumulative Duration). 195 Numerical values for both these intervals are provided in the 196 Measurement Identifier block referenced by the tag field below. 198 Measurement Identifier association (tag): 3 bits 200 This field is used to identify the Measurement Identifier block 201 [MEASIDENT] which describes this measurement. The relevant 202 Measurement Identifier block has the same tag value as the 203 Concealed Seconds Metrics block. Note that there may be more than 204 one Measurement Identifier block per RTCP packet. 206 Packet Loss Concealment Method (plc): 2 bits 208 This field is used to identify the packet loss concealment method 209 in use at the receiver, according to the following code: 211 bits 0-3 212 0 = silence insertion 213 1 = simple replay, no attenuation 214 2 = simple replay, with attenuation 215 3 = enhanced 216 Other values reserved 218 Reserved (rsv): 2 bits 220 These bits are reserved. They SHOULD be set to zero by senders 221 and MUST be ignored by receivers. 223 block length: 16 bits 225 The length of this report block in 32-bit words, minus one. For 226 the Concealed Seconds block, the block length is equal to 3. 228 Unimpaired Seconds: 32 bits 230 A count of the number of unimpaired Seconds that have occurred. 232 An unimpaired Second is defined as a continuous period of 1000ms 233 during which no frame loss or discard due to late arrival has 234 occurred. Every second in a call must be classified as either OK 235 or Concealed. 237 Normal playout of comfort noise or other silence concealment 238 signal during periods of talker silence, if VAD is used, shall be 239 counted as unimpaired seconds. 241 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 242 SHOULD be reported to indicate an over-range measurement. If the 243 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 244 reported. 246 Concealed Seconds: 32 bits 248 A count of the number of Concealed Seconds that have occurred. 250 A Concealed Second is defined as a continuous period of 1000ms 251 during which any frame loss or discard due to late arrival has 252 occurred. 254 Equivalently, a concealed second is one in which some Loss-type 255 concealment has occurred. Buffer adjustment-type concealment 256 SHALL not cause Concealed Seconds to be incremented, with the 257 following exception. An implementation MAY cause Concealed 258 Seconds to be incremented for 'emergency' buffer adjustments made 259 during talkspurts. 261 Loss-type concealment is reactive insertion or deletion of samples 262 in the audio playout stream due to effective frame loss at the 263 audio decoder. "Effective frame loss" is the event in which a 264 frame of coded audio is simply not present at the audio decoder 265 when required. In this case, substitute audio samples are 266 generally formed, at the decoder or elsewhere, to reduce audible 267 impairment. 269 Buffer Adjustment-type concealment is proactive or controlled 270 insertion or deletion of samples in the audio playout stream due 271 to jitter buffer adaptation, re-sizing or re-centering decisions 272 within the endpoint. 274 Because this insertion is controlled, rather than occurring 275 randomly in response to losses, it is typically less audible than 276 loss-type concealment. For example, jitter buffer adaptation 277 events may be constrained to occur during periods of talker 278 silence, in which case only silence duration is affected, or 279 sophisticated time-stretching methods for insertion/deletion 280 during favorable periods in active speech may be employed. For 281 these reasons, buffer adjustment-type concealment MAY be exempted 282 from inclusion in calculations of Concealed Seconds and Severely 283 Concealed Seconds. 285 However, an implementation SHOULD include buffer-type concealment 286 in counts of Concealed Seconds and Severely Concealed Seconds if 287 the event occurs at an 'inopportune' moment, with an emergency or 288 large, immediate adaptation during active speech, or for 289 unsophisticated adaptation during speech without regard for the 290 underlying signal, in which cases the assumption of low-audibility 291 cannot hold. In other words, jitter buffer adaptation events 292 which may be presumed to be audible SHOULD be included in 293 Concealed Seconds and Severely Concealed Seconds counts. 295 Concealment events which cannot be classified as Buffer 296 Adjustment- type MUST be classified as Loss-type. 298 For clarification, the count of Concealed Seconds MUST include the 299 count of Severely Concealed Seconds. 301 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 302 SHOULD be reported to indicate an over-range measurement. If the 303 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 304 reported. 306 Severely Concealed Seconds: 16 bits 308 A count of the number of Severely Concealed Seconds. 310 A Severely Concealed Second is defined as a non-overlapping period 311 of 1000 ms during which the cumulative amount of time that has 312 been subject to frame loss or discard due to late arrival, exceeds 313 the SCS Threshold. 315 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 316 reported to indicate an over-range measurement. If the 317 measurement is unavailable, the value 0xFFFF SHOULD be reported. 319 RESERVED: 8 bits 321 These bits are reserved. They SHOULD be set to zero by senders 322 and MUST be ignored by receivers. 324 SCS Threshold: 8 bits 325 The SCS Threshold defines the amount of time corresponding to lost 326 or discarded frames that must occur within a one second period in 327 order for the second to be classified as a Severely Concealed 328 Second. This is expressed in milliseconds and hence can represent 329 a range of 0.1 to 25.5 percent loss or discard. 331 A default threshold of 50ms (5% effective frame loss per second) 332 is suggested. 334 3. SDP Signaling 336 [RFC3611] defines the use of SDP (Session Description Protocol) 337 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 338 without prior signaling. 340 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 341 in [RFC3611] by providing an additional value of "xr-format" to 342 signal the use of the report block defined in this document. 344 The SDP attribute for the block has an additional optional paremeter, 345 "thresh", used to supply a value for the SCS Threshold parameter. If 346 this parameter is present, the RTP system receiving the SDP SHOULD 347 use this value for the current session. If the parameter is not 348 present, the RTP system SHOULD use a locally configured value. 350 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 352 (defined in [RFC3611]) 354 xr-format = xr-format / xr-conc-sec-block 356 xr-conc-sec-block = "conc-sec" ["=" thresh] 358 thresh = 1*DIGIT ; threshold for SCS (ms) 359 DIGIT = %x30-39 361 4. IANA Considerations 363 New block types for RTCP XR are subject to IANA registration. For 364 general guidelines on IANA considerations for RTCP XR, refer to 365 [RFC3611]. 367 4.1. New RTCP XR Block Type value 369 This document assigns the block type value NCS in the IANA "RTCP XR 370 Block Type Registry" to the "Concealed Seconds Metrics Block". 372 [Note to RFC Editor: please replace NCS with the IANA provided RTCP 373 XR block type for this block.] 375 4.2. New RTCP XR SDP Parameter 377 This document also registers a new parameter "conc-sec" in the "RTCP 378 XR SDP Parameters Registry". 380 4.3. Contact information for registrations 382 The contact information for the registrations is: 384 Geoff Hunt (geoff.hunt@bt.com) 386 Orion 2 PP3, Adastral Park, Martlesham Heath, Ipswich IP5 3RE, United 387 Kingdom 389 5. Security Considerations 391 It is believed that this proposed RTCP XR report block introduces no 392 new security considerations beyond those described in [RFC3611]. 393 This block does not provide per-packet statistics so the risk to 394 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 395 does not apply. 397 6. Contributors 399 The authors gratefully acknowledge the comments and contributions 400 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 401 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 402 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 403 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 404 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 406 7. Changes from previous version 408 Intro: Added "such as lost packets" as example to clarify concealment 409 in Intro, and text in Section 2.2, to meet Roni Even's request for a 410 definition of concealment (post 5-Dec-2008) 412 Intro, Applicability: Removed editor's note about metrics for 413 concealment in video. Added text based on Roni Even's and Randall 414 Jessup's posts of 5-Dec-2008 and 19-Dec-2008, explaining difficulty 415 of applying Concealed Seconds to video but stating that metric MAY be 416 used for video if a useful Concealed Seconds metric may be defined. 418 Extended and clarified IANA considerations section. 420 Changed SDP tag for block to "conc-sec". 422 8. References 424 8.1. Normative References 426 [MEASIDENT] 427 Hunt, G., "RTCP XR Measurement Identifier Block", 428 ID draft-ietf-avt-rtcp-xr-measid-01, February 2009. 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", RFC 2119, BCP 14, March 1997. 433 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 434 Applications", RFC 3550, July 2003. 436 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 437 XR)", RFC 3611, November 2003. 439 [RFC4566] Handley, M., "SDP: Session Description Protocol", 440 RFC 4566, July 2006. 442 8.2. Informative References 444 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 445 ID draft-hunt-avt-monarch-01, August 2008. 447 [PMOLFRAME] 448 Clark, A., "Framework for Performance Metric Development", 449 ID draft-ietf-pmol-metrics-framework-00, July 2008. 451 Authors' Addresses 453 Geoff Hunt 454 BT 455 Orion 2 PP3 456 Adastral Park 457 Martlesham Heath 458 Ipswich, Suffolk IP5 3RE 459 United Kingdom 461 Phone: +44 1473 651704 462 Email: geoff.hunt@bt.com 464 Alan Clark 465 Telchemy Incorporated 466 2905 Premiere Parkway, Suite 280 467 Duluth, GA 30097 468 USA 470 Email: alan.d.clark@telchemy.com