idnits 2.17.1 draft-ietf-avt-rtcp-xr-concsec-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 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 414. 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). == 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 (defined in Section 3.6) 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 (October 25, 2008) is 5652 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 334, 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 (==), 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 Concealed Seconds metric Reporting 9 draft-ietf-avt-rtcp-xr-concsec-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 Concealed Seconds metrics primarily for audio 40 applications of RTP. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Concealed Seconds Block . . . . . . . . . . . . . . . . . 3 46 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 47 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 48 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Concealed Seconds Metrics Block . . . . . . . . . . . . . . . 5 50 2.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 51 2.2. Definition of Fields in Concealed Seconds Metrics 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. Concealed Seconds Block 66 This draft defines a new block type to augment those defined in 67 [RFC3611], for use primarily in audio applications of RTP. 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 concealment. Specifically, 78 the first metric (Unimpaired Seconds) reports the number of whole 79 seconds occupied only with normal playout of data which the receiver 80 obtained from the sender's stream. The second metric (Concealed 81 Seconds) reports the number of whole seconds during which the 82 receiver played out any locally-generated media data. A third metric 83 (Severely Concealed Seconds) reports the number of whole seconds 84 during which the receiver played out locally-generated data for more 85 than SCS Threshold (ms). 87 The metric belongs to the class of transport-related terminal metrics 88 defined in [MONARCH] (work in progress). 90 Instances of this Metrics Block refer by tag to the separate 91 auxiliary Measurement Identity block [MEASIDENT] which contains 92 information such as the SSRC of the measured stream, and RTP sequence 93 numbers and time intervals indicating the span of the report. 95 1.2. RTCP and RTCP XR Reports 97 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 98 defined an extensible structure for reporting using an RTCP Extended 99 Report (XR). This draft defines a new Extended Report block that 100 MUST be used as defined in [RFC3550] and [RFC3611]. 102 1.3. Performance Metrics Framework 104 The Performance Metrics Framework [PMOLFRAME] provides guidance on 105 the definition and specification of performance metrics. Metrics 106 described in this draft either reference external definitions or 107 define metrics generally in accordance with the guidelines in 108 [PMOLFRAME]. 110 1.4. Applicability 112 This metric is primarily applicable to audio applications of RTP. 113 EDITOR'S NOTE: are there metrics for concealment of transport errors 114 for video? 116 2. Concealed Seconds Metrics Block 118 This sub-block provides a description of potentially audible 119 impairments due to lost and discarded packets at the endpoint, 120 expressed on a time basis analogous to a traditional PSTN T1/E1 121 errored seconds metric. 123 The following metrics are based on successive one second intervals as 124 declared by a local clock. This local clock does NOT need to be 125 synchronized to any external time reference. The starting time of 126 this clock is unspecified. Note that this implies that the same loss 127 pattern could result in slightly different count values, depending on 128 where the losses occur relative to the particular one-second 129 demarcation points. For example, two loss events occurring 50ms 130 apart could result in either one concealed second or two, depending 131 on the particular 1000 ms boundaries used. 133 The seconds in this sub-block are not necessarily calendar seconds. 134 At the tail end of a call, periods of time of less than 1000ms shall 135 be incorporated into these counts if they exceed 500ms and shall be 136 disregarded if they are less than 500ms. 138 2.1. Report Block Structure 140 Concealed seconds metrics block 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | BT=NCS |I| tag |plc|rsv| block length = 3 | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Unimpaired Seconds | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Concealed Seconds | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Severely Concealed Seconds | RESERVED | SCS Threshold | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1: Report Block Structure 155 2.2. Definition of Fields in Concealed Seconds Metrics Block 157 block type (BT): 8 bits 159 A Concealed Seconds Metrics Report Block is identified by the 160 constant NCS. 162 [Note to RFC Editor: please replace NCS with the IANA provided RTCP 163 XR block type for this block.] 164 Interval Metric flag (I): 1 bit 166 This field is used to indicate whether the Concealed Seconds 167 metric block is an Interval or a Cumulative report, that is, 168 whether the reported values apply to the most recent measurement 169 interval duration between successive metrics reports (I=1) (the 170 Interval Duration) or to the accumulation period characteristic of 171 cumulative measurements (I=0) (the Cumulative Duration). 172 Numerical values for both these intervals are provided in the 173 Measurement Identifier block referenced by the tag field below. 175 Measurement Identifier association (tag): 3 bits 177 This field is used to identify the Measurement Identifier block 178 [MEASIDENT] which describes this measurement. The relevant 179 Measurement Identifier block has the same tag value as the 180 Concealed Seconds Metrics block. Note that there may be more than 181 one Measurement Identifier block per RTCP packet. 183 Packet Loss Concealment Method (plc): 2 bits 185 This field is used to identify the packet loss concealment method 186 in use at the receiver, according to the following code: 188 bits 0-3 189 0 = silence insertion 190 1 = simple replay, no attenuation 191 2 = simple replay, with attenuation 192 3 = enhanced 193 Other values reserved 195 Reserved (rsv): 2 bits 197 These bits are reserved. They SHOULD be set to zero by senders 198 and MUST be ignored by receivers. 200 block length: 16 bits 202 The length of this report block in 32-bit words, minus one. For 203 the Concealed Seconds block, the block length is equal to 3. 205 Unimpaired Seconds: 32 bits 207 A count of the number of unimpaired Seconds that have occurred. 209 An unimpaired Second is defined as a continuous period of 1000ms 210 during which no frame loss or discard due to late arrival has 211 occurred. Every second in a call must be classified as either OK 212 or Concealed. 214 Normal playout of comfort noise or other silence concealment 215 signal during periods of talker silence, if VAD is used, shall be 216 counted as unimpaired seconds. 218 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 219 SHOULD be reported to indicate an over-range measurement. If the 220 measurement is unavailable, the value 0xFFFFFFFF SHOULD be 221 reported. 223 Concealed Seconds: 32 bits 225 A count of the number of Concealed Seconds that have occurred. 227 A Concealed Second is defined as a continuous period of 1000ms 228 during which any frame loss or discard due to late arrival has 229 occurred. 231 Equivalently, a concealed second is one in which some Loss-type 232 concealment (defined in Section 3.6) has occurred. Buffer 233 adjustment-type concealment SHALL not cause Concealed Seconds to 234 be incremented, with the following exception. An implementation 235 MAY cause Concealed Seconds to be incremented for 'emergency' 236 buffer adjustments made during talkspurts. 238 For clarification, the count of Concealed Seconds MUST include the 239 count of Severely Concealed 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. The duration, in milliseconds, of audio playout 245 corresponding to Loss-type concealment. 247 Severely Concealed Seconds: 16 bits 249 A count of the number of Severely Concealed Seconds. 251 A Severely Concealed Second is defined as a non-overlapping period 252 of 1000 ms during which the cumulative amount of time that has 253 been subject to frame loss or discard due to late arrival, exceeds 254 the SCS Threshold. 256 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 257 reported to indicate an over-range measurement. If the 258 measurement is unavailable, the value 0xFFFF SHOULD be reported. 260 RESERVED: 8 bits 262 These bits are reserved. They SHOULD be set to zero by senders 263 and MUST be ignored by receivers. 265 SCS Threshold: 8 bits 267 The SCS Threshold defines the amount of time corresponding to lost 268 or discarded frames that must occur within a one second period in 269 order for the second to be classified as a Severely Concealed 270 Second. This is expressed in milliseconds and hence can represent 271 a range of 0.1 to 25.5 percent loss or discard. 273 A default threshold of 50ms (5% effective frame loss per second) 274 is suggested. 276 3. SDP Signaling 278 [RFC3611] defines the use of SDP (Session Description Protocol) 279 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 280 without prior signaling. 282 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 283 in [RFC3611] by providing an additional value of "xr-format" to 284 signal the use of the report block defined in this document. 286 The SDP attribute for the block has an additional optional paremeter, 287 "thresh", used to supply a value for the SCS Threshold parameter. If 288 this parameter is present, the RTP system receiving the SDP SHOULD 289 use this value for the current session. If the parameter is not 290 present, the RTP system SHOULD use a locally configured value. 292 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 294 (defined in [RFC3611]) 296 xr-format = xr-format / xr-conc-sec-block 298 xr-conc-sec-block = "xr-concsec" ["=" thresh] 300 thresh = 1*DIGIT ; threshold for SCS (ms) 301 DIGIT = %x30-39 303 4. IANA Considerations 305 This document creates a new block type within the IANA "RTCP XR Block 306 Type Registry" called the Concealed Seconds Metrics Block, and a new 307 parameter xr-concsec within the "RTCP XR SDP Parameters Registry". 309 5. Security Considerations 311 It is believed that this proposed RTCP XR report block introduces no 312 new security considerations beyond those described in [RFC3611]. 313 This block does not provide per-packet statistics so the risk to 314 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 315 does not apply. 317 6. Contributors 319 The authors gratefully acknowledge the comments and contributions 320 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 321 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 322 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 323 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 324 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 326 7. References 328 7.1. Normative References 330 [MEASIDENT] 331 Hunt, G., "RTCP XR Measurement Identifier Block", 332 ID draft-ietf-avt-rtcp-xr-measid-00, August 2008. 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", RFC 2119, BCP 14, March 1997. 337 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 338 Applications", RFC 3550, July 2003. 340 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 341 XR)", RFC 3611, November 2003. 343 [RFC4566] Handley, M., "SDP: Session Description Protocol", 344 RFC 4566, July 2006. 346 7.2. Informative References 348 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 349 ID draft-hunt-avt-monarch-01, August 2008. 351 [PMOLFRAME] 352 Clark, A., "Framework for Performance Metric Development", 353 ID draft-ietf-pmol-metrics-framework-00, July 2008. 355 Authors' Addresses 357 Geoff Hunt 358 BT 359 Orion 1 PP9 360 Adastral Park 361 Martlesham Heath 362 Ipswich, Suffolk IP4 2TH 363 United Kingdom 365 Phone: +44 1473 608325 366 Email: geoff.hunt@bt.com 368 Alan Clark 369 Telchemy Incorporated 370 2905 Premiere Parkway, Suite 280 371 Duluth, GA 30097 372 USA 374 Email: alan.d.clark@telchemy.com 376 Full Copyright Statement 378 Copyright (C) The IETF Trust (2008). 380 This document is subject to the rights, licenses and restrictions 381 contained in BCP 78, and except as set forth therein, the authors 382 retain all their rights. 384 This document and the information contained herein are provided on an 385 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 386 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 387 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 388 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 389 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 390 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 392 Intellectual Property 394 The IETF takes no position regarding the validity or scope of any 395 Intellectual Property Rights or other rights that might be claimed to 396 pertain to the implementation or use of the technology described in 397 this document or the extent to which any license under such rights 398 might or might not be available; nor does it represent that it has 399 made any independent effort to identify any such rights. Information 400 on the procedures with respect to rights in RFC documents can be 401 found in BCP 78 and BCP 79. 403 Copies of IPR disclosures made to the IETF Secretariat and any 404 assurances of licenses to be made available, or the result of an 405 attempt made to obtain a general license or permission for the use of 406 such proprietary rights by implementers or users of this 407 specification can be obtained from the IETF on-line IPR repository at 408 http://www.ietf.org/ipr. 410 The IETF invites any interested party to bring to its attention any 411 copyrights, patents or patent applications, or other proprietary 412 rights that may cover technology that may be required to implement 413 this standard. Please address the information to the IETF at 414 ietf-ipr@ietf.org.