idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-concsec-03.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 (October 22, 2012) is 4204 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track Q. Wu 5 Expires: April 25, 2013 Huawei 6 A. Clark 7 Telchemy 8 C. Bi 9 STTRI 10 October 22, 2012 12 RTP Control Protocol (RTCP) Extended Report (XR) Block for Concealed 13 Seconds Metric Reporting 14 draft-ietf-xrblock-rtcp-xr-concsec-03.txt 16 Abstract 18 This document defines an RTP Control Protocol(RTCP) Extended Report 19 (XR) Block that allows the reporting of Concealed Seconds metrics, 20 primarily for audio applications of RTP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Concealed Seconds Block . . . . . . . . . . . . . . . . . 3 58 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 59 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 60 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Concealment Seconds Block . . . . . . . . . . . . . . . . . . 4 64 3.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 65 3.2. Definition of Fields in Concealed Seconds Metrics Block . 5 66 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 9 68 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 10 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 10 71 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 10 72 5.3. Contact information for registrations . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 1.1. Concealed Seconds Block 85 This draft defines a new block type to augment those defined in 86 [RFC3611], for use primarily in audio applications of RTP. 88 At any instant, the audio output at a receiver may be classified as 89 either 'normal' or 'concealed'. 'Normal' refers to playout of audio 90 payload received from the remote end, and also includes locally 91 generated signals such as announcements, tones and comfort noise. 92 'Concealed' refers to playout of locally-generated signals used to 93 mask the impact of network impairments such as lost packets or to 94 reduce the audibility of jitter buffer adaptations. 95 Editor's Note: For video applications, the output at a receiver 96 should also be classified as either normal or concealed. Should 97 this paragraph be clear about this? 99 The new block type provides metrics for concealment. Specifically, 100 the first metric (Unimpaired Seconds) reports the number of whole 101 seconds occupied only with normal playout of data which the receiver 102 obtained from the sender's stream. The second metric (Concealed 103 Seconds) reports the number of whole seconds during which the 104 receiver played out any locally-generated media data. A third metric 105 (Severely Concealed Seconds (SCS)) reports the number of whole 106 seconds during which the receiver played out locally-generated data 107 for longer than SCS Threshold milliseconds. 109 The metric belongs to the class of transport-related end system 110 metrics defined in Wu, Hunt & Arden [I-D.ietf-avtcore-monarch]. 112 1.2. RTCP and RTCP XR Reports 114 The use of RTCP for reporting is defined in Schulzrinne et al. 115 [RFC3550]. Freidman, et al. [RFC3611] defines an extensible 116 structure for reporting using an RTCP Extended Report (XR). This 117 draft defines a new Extended Report block that MUST be used as 118 specified in RFC 3550 and RFC 3611. 120 1.3. Performance Metrics Framework 122 The Performance Metrics Framework [RFC6390] provides guidance on the 123 definition and specification of performance metrics. The RTP 124 Monitoring Architecture [I-D.ietf-avtcore-monarch] provides 125 guidelines for formatting RTCP XR blocks. The Metrics Block 126 described in this document are in accordance with the guidelines in 127 [RFC6390] and [I-D.ietf-avtcore-monarch]. 129 1.4. Applicability 131 This metric is primarily applicable to audio applications of RTP. 133 EDITOR'S NOTE: are there metrics for concealment of transport errors 134 for video? 136 Editor's Note: note that with video it is possible to use RTP based 137 retransmission and also FEC (e.g. COP3) - typically these would only 138 be used with IPTV as this is less delay sensitive than interactive 139 services. 141 2. Terminology 143 2.1. Standards Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 In addition, the following terms are defined: 151 Editor's Note: For Video loss concealment, at least the following 152 four methods are used,i.e., Frame freeze,inter-frame 153 extrapolation, interpolation, Noise insertation, should this 154 section consider giving definition of these four methods for video 155 loss concealment? 157 3. Concealment Seconds Block 159 This block provides a description of potentially audible impairments 160 due to lost and discarded packets at the endpoint, expressed on a 161 time basis analogous to a traditional PSTN T1/E1 errored seconds 162 metric. 163 Editor's Note: Should impairment also cover video application? 165 The following metrics are based on successive one second intervals as 166 declared by a local clock. This local clock does NOT need to be 167 synchronized to any external time reference. The starting time of 168 this clock is unspecified. Note that this implies that the same loss 169 pattern could result in slightly different count values, depending on 170 where the losses occur relative to the particular one-second 171 demarcation points. For example, two loss events occurring 50ms 172 apart could result in either one concealed second or two, depending 173 on the particular 1000 ms boundaries used. 175 The seconds in this sub-block are not necessarily calendar seconds. 176 At the tail end of a session, periods of time of less than 1000ms 177 shall be incorporated into these counts if they exceed 500ms and 178 shall be disregarded if they are less than 500ms. 180 3.1. Report Block Structure 182 Concealed Seconds Metrics Block 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | BT=NCS | I |plc|Rserved| block length=4 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | SSRC of Source | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Unimpaired Seconds | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Concealed Seconds | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Severely Concealed Seconds | RESERVED | SCS Threshold | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: Report Block Structure 200 3.2. Definition of Fields in Concealed Seconds Metrics Block 202 Block type (BT): 8 bits 204 A Concealed Seconds Metrics Report Block is identified by the 205 constant . 207 [Note to RFC Editor: please replace with the IANA provided 208 RTCP XR block type for this block.] 210 Interval Metric flag (I): 2 bit 212 This field is used to indicate whether the Concealed Seconds 213 metrics are Sampled, Interval or Cumulative metrics, that is, 214 whether the reported values applies to the most recent measurement 215 interval duration between successive metrics reports (I=10) (the 216 Interval Duration) or to the accumulation period characteristic of 217 cumulative measurements (I=11) (the Cumulative Duration) or is a 218 sampled instantaneous value (I=01) (Sampled Value). 220 Packet Loss Concealment Method (plc): 2 bits 222 This field is used to identify the packet loss concealment method 223 in use at the receiver, according to the following code: 224 bits 014-015 225 0 = silence insertion 226 1 = simple replay, no attenuation 227 2 = simple replay, with attenuation 228 3 = enhanced 229 Other values reserved 230 Editor's Note 1 : In the packet loss concealment 231 methods,"Enhanced" is defines as one new Packet loss 232 Concealment method? However it is not clear what this 233 packet loss concealment method looks like? 234 Editor's Note 2: For Video loss concealment, there are a 235 range of methods used, for example: 236 (i) Frame freeze In this case the impaired video frame 237 is not displayed and the previously displayed frame is 238 hence "frozen" for the duration of the loss event 239 (ii) Inter-frame extrapolation If an area of the video 240 frame is damaged by loss, the same area from the 241 previous frame(s) can be used to estimate what the 242 missing pixels would have been. This can work well in 243 a scene with no motion but can be very noticeable if 244 there is significant movement from one frame to 245 another. Simple decoders may simply re-use the pixels 246 that were in the missing area, more complex decoders 247 may try to use several frames to do a more complex 248 extrapolation. 249 (iii) Interpolation A decoder may use the undamaged 250 pixels in the image to estimate what the missing block 251 of image should have 252 (iv) Noise insertion A decoder may insert random pixel 253 values - which would generally be less noticeable than 254 a blank rectangle in the image. 255 Therefore more text required in the future draft to 256 discuss Techniques for Video Loss Concealment method in 257 this document. 259 Reserved (resv): 4 bits 261 These bits are reserved. They SHOULD be set to zero by senders 262 and MUST be ignored by receivers. 264 Block Length: 16 bits 266 The length of this report block in 32-bit words, minus one. For 267 the Delay block, the block length is equal to 4. 269 SSRC of source: 32 bits 271 As defined in Section 4.1 of RFC 3611. 273 Unimpaired Seconds: 32 bits 275 A count of the number of unimpaired Seconds that have occurred. 277 An unimpaired Second is defined as a continuous period of 1000ms 278 during which no frame loss or discard due to late arrival has 279 occurred. Every second in a session must be classified as either 280 OK or Concealed. 282 If voice activity detection [VAD] is used, normal playout of 283 comfort noise or other silence concealment signals during periods 284 of talker silence SHALL be counted as unimpaired seconds. 285 Editor's Note: It should be clear that voice activity detection 286 does not apply to video. 287 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 288 SHOULD be reported to indicate an over-range measurement. If the 289 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 290 reported. 292 Concealed Seconds: 32 bits 294 A count of the number of Concealed Seconds that have occurred. 296 A Concealed Second is defined as a continuous period of 1000ms 297 during which any frame loss or discard due to late arrival has 298 occurred. 300 Equivalently, a concealed second is one in which some Loss-type 301 concealment has occurred. Buffer adjustment-type concealment 302 SHALL NOT cause Concealed Seconds to be incremented, with the 303 following exception. An implementation MAY cause Concealed 304 Seconds to be incremented for 'emergency' buffer adjustments made 305 during talkspurts. 307 Loss-type concealment is reactive insertion or deletion of samples 308 in the audio playout stream due to effective frame loss at the 309 audio decoder. "Effective frame loss" is the event in which a 310 frame of coded audio is simply not present at the audio decoder 311 when required. In this case, substitute audio samples are 312 generally formed, at the decoder or elsewhere, to reduce audible 313 impairment. 315 Buffer Adjustment-type concealment is proactive or controlled 316 insertion or deletion of samples in the audio playout stream due 317 to jitter buffer adaptation, re-sizing or re-centering decisions 318 within the endpoint. 320 Because this insertion is controlled, rather than occurring 321 randomly in response to losses, it is typically less audible than 322 loss-type concealment. For example, jitter buffer adaptation 323 events may be constrained to occur during periods of talker 324 silence, in which case only silence duration is affected, or 325 sophisticated time-stretching methods for insertion/deletion 326 during favorable periods in active speech may be employed. For 327 these reasons, buffer adjustment-type concealment MAY be exempted 328 from inclusion in calculations of Concealed Seconds and Severely 329 Concealed Seconds. 330 Editor's Note: In this document, two kind of concealments are 331 defined: a. Loss-type concealment b. Buffer Adjustment-type 332 concealment Loss-type concealment is applicable to both audio 333 and video. However Buffer Adjustment-type concealment is 334 usually applied to audio. Should this section be clear about 335 this? 337 However, an implementation SHOULD include buffer-type concealment 338 in counts of Concealed Seconds and Severely Concealed Seconds if 339 the event occurs at an 'inopportune' moment, with an emergency or 340 large, immediate adaptation during active speech, or for 341 unsophisticated adaptation during speech without regard for the 342 underlying signal, in which cases the assumption of low-audibility 343 cannot hold. In other words, jitter buffer adaptation events 344 which may be presumed to be audible SHOULD be included in 345 Concealed Seconds and Severely Concealed Seconds counts. 346 Concealment events which cannot be classified as Buffer 347 Adjustment- type MUST be classified as Loss-type. 348 For clarification, the count of Concealed Seconds MUST include the 349 count of Severely Concealed Seconds. 350 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 351 SHOULD be reported to indicate an over-range measurement. If the 352 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 353 reported. 355 Severely Concealed Seconds: 16 bits 357 A count of the number of Severely Concealed Seconds. 359 A Severely Concealed Second is defined as a non-overlapping period 360 of 1000 ms during which the cumulative amount of time that has 361 been subject to frame loss or discard due to late arrival, exceeds 362 the SCS Threshold. 364 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 365 reported to indicate an over-range measurement. If the 366 measurement is unavailable, the value 0xFFFF SHOULD be reported. 368 Reserved: 8 bits 370 These bits are reserved. They SHOULD be set to zero by senders 371 and MUST be ignored by receivers. 373 SCS Threshold: 8 bits 375 The SCS Threshold defines the amount of time corresponding to lost 376 or discarded frames that must occur within a one second period in 377 order for the second to be classified as a Severely Concealed 378 Second. This is expressed in milliseconds and hence can represent 379 a range of 0.1 to 25.5 percent loss or discard. 381 A default threshold of 50ms (5% effective frame loss per second) 382 is suggested. 384 4. SDP Signaling 386 RFC 3611 defines the use of Session Description Protocol (SDP, 387 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 388 without prior signaling. 390 4.1. SDP rtcp-xr-attrib Attribute Extension 392 This section augments the SDP attribute "rtcp-xr" defined in Section 393 5.1 of RFC 3611 by providing an additional value of "xr-format" to 394 signal the use of the report block defined in this document. 396 The SDP attribute for the block has an additional optional paremeter, 397 "thresh", used to supply a value for the SCS Threshold parameter. If 398 this parameter is present, the RTP system receiving the SDP SHOULD 399 use this value for the current session. If the parameter is not 400 present, the RTP system SHOULD use a locally configured value. 402 xr-format =/ xr-conc-sec-block 404 xr-conc-sec-block = "conc-sec" ["=" thresh] 406 thresh = 1*DIGIT ; threshold for SCS (ms) 407 DIGIT = 409 4.2. Offer/Answer Usage 411 When SDP is used in offer-answer context, the SDP Offer/Answer usage 412 defined in Section 5.2 of RFC 3611 applies. 414 5. IANA Considerations 416 New block types for RTCP XR are subject to IANA registration. For 417 general guidelines on IANA considerations for RTCP XR, refer to 418 Section 6 of RFC 3611. 420 5.1. New RTCP XR Block Type value 422 This document assigns the block type value in the IANA "RTCP XR 423 Block Type Registry" to the "Concealed Seconds Metrics Block". 425 [Note to RFC Editor: please replace with the IANA provided RTCP 426 XR block type for this block.] 428 5.2. New RTCP XR SDP Parameter 430 This document also registers a new parameter "conc-sec" in the "RTCP 431 XR SDP Parameters Registry". 433 5.3. Contact information for registrations 435 The contact information for the registrations is: 437 Alan Clark (alan.d.clark@telchemy.com) 439 2905 Premiere Parkway, Suite 280 440 Duluth, GA 30097 441 USA 443 6. Security Considerations 445 It is believed that this proposed RTCP XR report block introduces no 446 new security considerations beyond those described in RFC 3611. This 447 block does not provide per-packet statistics so the risk to 448 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 449 does not apply. 451 7. Contributors 453 Geoff Hunt wrote the initial draft of this document. 455 8. Acknowledgements 457 The authors gratefully acknowledge reviews and feedback provided by 458 Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, 459 Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, 460 Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, 461 Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi 462 Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 464 9. References 466 9.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 472 Jacobson, "RTP: A Transport Protocol for Real-Time 473 Applications", STD 64, RFC 3550, July 2003. 475 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 476 Protocol Extended Reports (RTCP XR)", RFC 3611, 477 November 2003. 479 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 480 Description Protocol", RFC 4566, July 2006. 482 9.2. Informative References 484 [I-D.ietf-avtcore-monarch] 485 Wu, W., Hunt, G., and P. Arden, "Guidelines for Use of the 486 RTP Monitoring Framework", draft-ietf-avtcore-monarch-22 487 (work in progress), September 2012. 489 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 490 Performance Metric Development", BCP 170, RFC 6390, 491 October 2011. 493 [VAD] "http://en.wikipedia.org/wiki/Voice_activity_detection". 495 Authors' Addresses 497 Glen Zorn 498 Network Zen 499 227/358 Thanon Sanphawut 500 Bang Na, Bangkok 10260 501 Thailand 503 Phone: +66 (0) 909-0201060 504 Email: glenzorn@gmail.com 506 Qin Wu 507 Huawei 508 101 Software Avenue, Yuhua District 509 Nanjing, Jiangsu 210012 510 China 512 Email: sunseawq@huawei.com 514 Alan Clark 515 Telchemy Incorporated 516 2905 Premiere Parkway, Suite 280 517 Duluth, GA 30097 518 USA 520 Email: alan.d.clark@telchemy.com 522 Claire Bi 523 Shanghai Research Institure of China Telecom Corporation Limited 524 No.1835,South Pudong Road 525 Shanghai 200122 526 China 528 Email: bijy@sttri.com.cn