idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-concsec-02.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 == 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 date (October 19, 2012) is 4205 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group A. Clark 3 Internet-Draft Telchemy 4 Intended status: Standards Track G. Zorn 5 Expires: April 22, 2013 Network Zen 6 C. Bi 7 STTRI 8 Q. Wu 9 Huawei 10 October 19, 2012 12 RTP Control Protocol (RTCP) Extended Report (XR) Block for Concealed 13 Seconds metric Reporting 14 draft-ietf-xrblock-rtcp-xr-concsec-02.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 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 5 63 3. Concealment Seconds Block . . . . . . . . . . . . . . . . . . 6 64 3.1. Report Block Structure . . . . . . . . . . . . . . . . . . 6 65 3.2. Definition of Fields in Concealed Seconds Metrics Block . 7 66 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 12 68 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 12 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 13 71 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 13 72 5.3. Contact information for registrations . . . . . . . . . . 13 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 80 A.1. draft-ietf-xrblock-rtcp-xr-concsec-02 . . . . . . . . . . 18 81 A.2. draft-ietf-xrblock-rtcp-xr-concsec-01 . . . . . . . . . . 18 82 A.3. draft-ietf-xrblock-rtcp-xr-concsec-00 . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 1.1. Concealed Seconds Block 89 This draft defines a new block type to augment those defined in 90 [RFC3611], for use primarily in audio applications of RTP. 92 At any instant, the audio output at a receiver may be classified as 93 either 'normal' or 'concealed'. 'Normal' refers to playout of audio 94 payload received from the remote end, and also includes locally 95 generated signals such as announcements, tones and comfort noise. 96 Concealment refers to playout of locally-generated signals used to 97 mask the impact of network impairments such as lost packets or to 98 reduce the audibility of jitter buffer adaptations. 100 Editor's Note: For video application, the output at a receiver 101 should also be classified as either normal or concealed. Should 102 this paragraph be clear about this? 104 The new block type provides metrics for concealment. Specifically, 105 the first metric (Unimpaired Seconds) reports the number of whole 106 seconds occupied only with normal playout of data which the receiver 107 obtained from the sender's stream. The second metric (Concealed 108 Seconds) reports the number of whole seconds during which the 109 receiver played out any locally-generated media data. A third metric 110 (Severely Concealed Seconds (SCS)) reports the number of whole 111 seconds during which the receiver played out locally-generated data 112 for more than SCS Threshold (ms). 114 The metric belongs to the class of transport-related end system 115 metrics defined in [MONARCH]. 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. 137 EDITOR'S NOTE: are there metrics for concealment of transport errors 138 for video? 140 Editor's Note: note that with video it is possible to use RTP based 141 retransmission and also FEC (e.g. COP3) - typically these would only 142 be used with IPTV as this is less delay sensitive than interactive 143 services. 145 2. Terminology 147 2.1. Standards Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 In addition, the following terms are defined: 155 Editor's Note: For Video loss concealment, at least the following 156 four methods are used,i.e., Frame freeze,inter-frame 157 extrapolation, interpolation, Noise insertation, should this 158 section consider giving definition of these four methods for video 159 loss concealment? 161 3. Concealment Seconds Block 163 This sub-block provides a description of potentially audible 164 impairments due to lost and discarded packets at the endpoint, 165 expressed on a time basis analogous to a traditional PSTN T1/E1 166 errored seconds metric. 168 Editor's Note: Should impairment also cover video application? 170 The following metrics are based on successive one second intervals as 171 declared by a local clock. This local clock does NOT need to be 172 synchronized to any external time reference. The starting time of 173 this clock is unspecified. Note that this implies that the same loss 174 pattern could result in slightly different count values, depending on 175 where the losses occur relative to the particular one-second 176 demarcation points. For example, two loss events occurring 50ms 177 apart could result in either one concealed second or two, depending 178 on the particular 1000 ms boundaries used. 180 The seconds in this sub-block are not necessarily calendar seconds. 181 At the tail end of a session, periods of time of less than 1000ms 182 shall be incorporated into these counts if they exceed 500ms and 183 shall be disregarded if they are less than 500ms. 185 3.1. Report Block Structure 187 Concealed Seconds metrics block 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | BT=NCS | I |plc|Rserved| block length=4 | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | SSRC of Source | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Unimpaired Seconds | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Concealed Seconds | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Severely Concealed Seconds | RESERVED | SCS Threshold | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1: Report Block Structure 205 3.2. Definition of Fields in Concealed Seconds Metrics Block 207 Block type (BT): 8 bits 209 A Concealed Seconds Metrics Report Block is identified by the 210 constant NCS. 212 [Note to RFC Editor: please replace NCS with the IANA provided 213 RTCP XR block type for this block.] 215 Interval Metric flag (I): 2 bit 217 This field is used to indicate whether the Concealed Seconds 218 metrics are Sampled, Interval or Cumulative metrics, that is, 219 whether the reported values applies to the most recent measurement 220 interval duration between successive metrics reports (I=10) (the 221 Interval Duration) or to the accumulation period characteristic of 222 cumulative measurements (I=11) (the Cumulative Duration) or is a 223 sampled instantaneous value (I=01) (Sampled Value). 225 Packet Loss Concealment Method (plc): 2 bits 227 This field is used to identify the packet loss concealment method 228 in use at the receiver, according to the following code: 230 bits 014-015 232 0 = silence insertion 234 1 = simple replay, no attenuation 236 2 = simple replay, with attenuation 238 3 = enhanced 240 Other values reserved 242 Editor's Note 1 : In the packet loss concealment 243 methods,"Enhanced" is defines as one new Packet loss 244 Concealment method? However it is not clear what this 245 packet loss concealment method looks like? 247 Editor's Note 2: For Video loss concealment, there are a 248 range of methods used, for example: 250 (i) Frame freeze In this case the impaired video frame 251 is not displayed and the previously displayed frame is 252 hence "frozen" for the duration of the loss event 254 (ii) Inter-frame extrapolation If an area of the video 255 frame is damaged by loss, the same area from the 256 previous frame(s) can be used to estimate what the 257 missing pixels would have been. This can work well in 258 a scene with no motion but can be very noticeable if 259 there is significant movement from one frame to 260 another. Simple decoders may simply re-use the pixels 261 that were in the missing area, more complex decoders 262 may try to use several frames to do a more complex 263 extrapolation. 265 (iii) Interpolation A decoder may use the undamaged 266 pixels in the image to estimate what the missing block 267 of image should have 269 (iv) Noise insertion A decoder may insert random pixel 270 values - which would generally be less noticeable than 271 a blank rectangle in the image. 273 Therefore more text required in the future draft to 274 discuss Techniques for Video Loss Concealment method in 275 this document. 277 Reserved (resv): 4 bits 279 These bits are reserved. They SHOULD be set to zero by senders 280 and MUST be ignored by receivers. 282 Block Length: 16 bits 284 The length of this report block in 32-bit words, minus one. For 285 the Delay block, the block length is equal to 4. 287 SSRC of source: 32 bits 289 As defined in Section 4.1 of [RFC3611]. 291 Unimpaired Seconds: 32 bits 293 A count of the number of unimpaired Seconds that have occurred. 295 An unimpaired Second is defined as a continuous period of 1000ms 296 during which no frame loss or discard due to late arrival has 297 occurred. Every second in a session must be classified as either 298 OK or Concealed. 300 Normal playout of comfort noise or other silence concealment 301 signal during periods of talker silence, if VAD [VAD] is used, 302 shall be counted as unimpaired seconds. 304 Editor's Note: It should be clear that VAD does not apply to 305 video. 307 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 308 SHOULD be reported to indicate an over-range measurement. If the 309 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 310 reported. 312 Concealed Seconds: 32 bits 314 A count of the number of Concealed Seconds that have occurred. 316 A Concealed Second is defined as a continuous period of 1000ms 317 during which any frame loss or discard due to late arrival has 318 occurred. 320 Equivalently, a concealed second is one in which some Loss-type 321 concealment has occurred. Buffer adjustment-type concealment 322 SHALL not cause Concealed Seconds to be incremented, with the 323 following exception. An implementation MAY cause Concealed 324 Seconds to be incremented for 'emergency' buffer adjustments made 325 during talkspurts. 327 Loss-type concealment is reactive insertion or deletion of samples 328 in the audio playout stream due to effective frame loss at the 329 audio decoder. "Effective frame loss" is the event in which a 330 frame of coded audio is simply not present at the audio decoder 331 when required. In this case, substitute audio samples are 332 generally formed, at the decoder or elsewhere, to reduce audible 333 impairment. 335 Buffer Adjustment-type concealment is proactive or controlled 336 insertion or deletion of samples in the audio playout stream due 337 to jitter buffer adaptation, re-sizing or re-centering decisions 338 within the endpoint. 340 Because this insertion is controlled, rather than occurring 341 randomly in response to losses, it is typically less audible than 342 loss-type concealment. For example, jitter buffer adaptation 343 events may be constrained to occur during periods of talker 344 silence, in which case only silence duration is affected, or 345 sophisticated time-stretching methods for insertion/deletion 346 during favorable periods in active speech may be employed. For 347 these reasons, buffer adjustment-type concealment MAY be exempted 348 from inclusion in calculations of Concealed Seconds and Severely 349 Concealed Seconds. 351 Editor's Note: In this document, two kind of concealments are 352 defined: a. Loss-type concealment b. Buffer Adjustment-type 353 concealment Loss-type concealment is applicable to both audio 354 and video. However Buffer Adjustment-type concealment is 355 usually applied to audio. Should this section be clear about 356 this? 358 However, an implementation SHOULD include buffer-type concealment 359 in counts of Concealed Seconds and Severely Concealed Seconds if 360 the event occurs at an 'inopportune' moment, with an emergency or 361 large, immediate adaptation during active speech, or for 362 unsophisticated adaptation during speech without regard for the 363 underlying signal, in which cases the assumption of low-audibility 364 cannot hold. In other words, jitter buffer adaptation events 365 which may be presumed to be audible SHOULD be included in 366 Concealed Seconds and Severely Concealed Seconds counts. 368 Concealment events which cannot be classified as Buffer 369 Adjustment- type MUST be classified as Loss-type. 371 For clarification, the count of Concealed Seconds MUST include the 372 count of Severely Concealed Seconds. 374 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 375 SHOULD be reported to indicate an over-range measurement. If the 376 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 377 reported. 379 Severely Concealed Seconds: 16 bits 381 A count of the number of Severely Concealed Seconds. 383 A Severely Concealed Second is defined as a non-overlapping period 384 of 1000 ms during which the cumulative amount of time that has 385 been subject to frame loss or discard due to late arrival, exceeds 386 the SCS Threshold. 388 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 389 reported to indicate an over-range measurement. If the 390 measurement is unavailable, the value 0xFFFF SHOULD be reported. 392 Reserved: 8 bits 394 These bits are reserved. They SHOULD be set to zero by senders 395 and MUST be ignored by receivers. 397 SCS Threshold: 8 bits 399 The SCS Threshold defines the amount of time corresponding to lost 400 or discarded frames that must occur within a one second period in 401 order for the second to be classified as a Severely Concealed 402 Second. This is expressed in milliseconds and hence can represent 403 a range of 0.1 to 25.5 percent loss or discard. 405 A default threshold of 50ms (5% effective frame loss per second) 406 is suggested. 408 4. SDP Signaling 410 [RFC3611] defines the use of SDP (Session Description Protocol) 411 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 412 without prior signaling. 414 4.1. SDP rtcp-xr-attrib Attribute Extension 416 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 417 in [RFC3611] by providing an additional value of "xr-format" to 418 signal the use of the report block defined in this document. 420 The SDP attribute for the block has an additional optional paremeter, 421 "thresh", used to supply a value for the SCS Threshold parameter. If 422 this parameter is present, the RTP system receiving the SDP SHOULD 423 use this value for the current session. If the parameter is not 424 present, the RTP system SHOULD use a locally configured value. 426 xr-format =/ xr-conc-sec-block 428 xr-conc-sec-block = "conc-sec" ["=" thresh] 430 thresh = 1*DIGIT ; threshold for SCS (ms) 431 DIGIT = 433 4.2. Offer/Answer Usage 435 When SDP is used in offer-answer context, the SDP Offer/Answer usage 436 defined in [RFC3611] applies. 438 5. IANA Considerations 440 New block types for RTCP XR are subject to IANA registration. For 441 general guidelines on IANA considerations for RTCP XR, refer to 442 [RFC3611]. 444 5.1. New RTCP XR Block Type value 446 This document assigns the block type value NJB in the IANA "RTCP XR 447 Block Type Registry" to the "Concealed Seconds Metrics Block". 449 [Note to RFC Editor: please replace NCS with the IANA provided RTCP 450 XR block type for this block.] 452 5.2. New RTCP XR SDP Parameter 454 This document also registers a new parameter "conc-sec" in the "RTCP 455 XR SDP Parameters Registry". 457 5.3. Contact information for registrations 459 The contact information for the registrations is: 461 Alan Clark (alan.d.clark@telchemy.com) 463 2905 Premiere Parkway, Suite 280 464 Duluth, GA 30097 465 USA 467 6. Security Considerations 469 It is believed that this proposed RTCP XR report block introduces no 470 new security considerations beyond those described in [RFC3611]. 471 This block does not provide per-packet statistics so the risk to 472 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 473 does not apply. 475 7. Contributors 477 Geoff Hunt wrote the initial draft of this document. 479 8. Acknowledgements 481 The authors gratefully acknowledge reviews and feedback provided by 482 Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, 483 Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, 484 Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, 485 Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi 486 Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 488 9. References 490 9.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", March 1997. 495 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 496 Applications", RFC 3550, July 2003. 498 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 499 Protocol Extended Reports (RTCP XR)", November 2003. 501 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 502 Description Protocol", July 2006. 504 9.2. Informative References 506 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 507 ID draft-ietf-avtcore-monarch-22, September 2012. 509 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 510 Development", RFC 6390, October 2011. 512 [VAD] "http://en.wikipedia.org/wiki/Voice_activity_detection". 514 Appendix A. Change Log 516 Note to the RFC-Editor: please remove this section prior to 517 publication as an RFC. 519 A.1. draft-ietf-xrblock-rtcp-xr-concsec-02 521 The following are the major changes to previous version : 523 o One typo fixed. 525 o Add one note to highlight these metrics are primarily applicable 526 to audio. 528 A.2. draft-ietf-xrblock-rtcp-xr-concsec-01 530 The following are the major changes to previous version : 532 o Outdated references update. 534 o Add Editor's notes to point out where to require more texts for 535 video loss concealment support 537 o Other Editorial changes. 539 A.3. draft-ietf-xrblock-rtcp-xr-concsec-00 541 The following are the major changes to previous version : 543 o Updated references. 545 o Allocate two bits for interval metric flag and 32 bit for SSRC 547 o Other editorial changes to get in line with MONARCH and MeasID 548 draft. 550 Authors' Addresses 552 Alan Clark 553 Telchemy Incorporated 554 2905 Premiere Parkway, Suite 280 555 Duluth, GA 30097 556 USA 558 Email: alan.d.clark@telchemy.com 560 Glen Zorn 561 Network Zen 562 77/440 Soi Phoomjit, Rama IV Road 563 Phra Khanong, Khlong Toie 564 Bangkok 10110 565 Thailand 567 Phone: +66 (0) 87 502 4274 568 Email: gwz@net-zen.net 570 Claire Bi 571 Shanghai Research Institure of China Telecom Corporation Limited 572 No.1835,South Pudong Road 573 Shanghai 200122 574 China 576 Email: bijy@sttri.com.cn 578 Qin Wu 579 Huawei 580 101 Software Avenue, Yuhua District 581 Nanjing, Jiangsu 210012 582 China 584 Email: sunseawq@huawei.com