idnits 2.17.1 draft-ietf-avt-rtcp-xr-siglevel-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 26, 2008) is 5654 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: '9' is defined on line 400, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (ref. '4') (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- No information found for draft-ietf-pmol-perf-metrics-framework - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AVT Working Group Alan Clark 2 Internet Draft Telchemy 3 Geoff Hunt 4 BT 6 Intended status: Standards Track October 26, 2008 7 Expires: April 28, 2008 9 RTCP XR Report Block for Signal Level Metrics Reporting 10 draft-ietf-avt-rtcp-xr-siglevel-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on April 28, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document defines an RTCP XR Report Block that allows the 45 reporting of metrics related to signal levels for use in voice, 46 audio and video services. 48 Terminology 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 50 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 51 "OPTIONAL" in this document are to be interpreted as described in 52 RFC 2119 [1]. 54 Clark & Hunt [Page 1] 55 RTCP XR Signal Level Metrics October 2008 57 1. Introduction 59 1.1. Signal Level Report Block 61 This draft defines a new block types to augment those defined 62 in RFC3611 for use in reporting the level of signal/ decoded 63 payload related metrics. Signal level metrics include, for 64 example, signal level, background noise level and echo level. 66 These metrics are useful when determing, for example: 68 (a) if there is a problem with the input to an encoder being 69 set to an excessively high or low level 71 (b) if the input to the encoder is faulty (e.g. disconnected) 73 (c) if the source signal is excessively noisy 75 (d) if there is a significant level of echo that would be 76 disruptive during an IP telephone call or audio conference 78 1.2. RTCP and RTCP XR Reports 80 The use of RTCP for reporting is defined in RFC3550 [2]. 81 RFC3611 [3] defined an extensible structure for reporting using 82 an RTCP Extended Report (XR). This draft defines 83 a new Extended Report block that MUST be used as defined in 84 RFC3550 and RFC3611. 86 1.3 Performance Metrics Framework 88 The Performance Metrics Framework [n] provides guidance on the 89 definition and specification of performance metrics. Metrics 90 described in this draft either reference external definitions 91 or define metrics generally in accordance with the guidelines 92 in [4]. 94 1.4 Applicability 96 This memo applies to any application of RTP in which there is 97 an audio or speech component. 99 2. Definitions 101 2.1 Signal Level 103 The "signal" is defined as the active "talkspurts" within 104 an interactive voice stream or the whole of a unidirectional 105 audio or video stream. "Noise" is the additive background 106 noise level, which can be measured either during silence 107 periods between periods of audio/ voice activity or 109 Clark & Hunt [Page 2] 110 RTCP XR Signal Level Metrics October 2008 112 otherwise extracted from the signal. 114 2.1 Mean Signal Level 116 Mean Signal Level is defined as the mean power level of the 117 signal, expressed in dBm. In telephony applications the 118 power level is typically expressed with reference to a zero 119 reference point in dBm0. 121 2.2 Peak Signal Level 123 Peak signal Level is defined as the peak power level of the 124 signal, expressed in dBm. 126 2.3 Noise Level 128 Noise Level is defined as the power level of the additive or 129 silent period noise expressed in dBm. In telephony applications 130 the noise level is typically expressed with reference to a zero 131 reference point in dBm0. 133 2.4 Echo Level 135 2.5 Channel 137 Certain types of encoder (for example stereo audio codecs) 138 incorporate multiple audio or video channels into a single encoded 139 stream which is then packetized and carried in RTP or MPEG 140 Transport. Within the scope of this memo, the term "channel" 141 applies to this definition only - if multiple audio or video 142 streams are carried either in separate RTP sessions (identified 143 by an SSRC) or MPEG Transport program streams (identified by a 144 PID) then the Measurement Identifier block MUST be used to 145 identify the stream to which metrics apply. 147 3. Signal Level Metrics Block 149 3.1 Report Block Structure 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | BT=N |C|T|T|T| | block length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |s s s s|c c c c c c|m m|d d|b b| Level | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 ............ 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |s s s s|c c c c c c|m m|d d|b b| Level | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 ssss = Reported signal level metric type 165 Clark & Hunt [Page 3] 166 RTCP XR Signal Level Metrics October 2008 168 0000 - active signal level 169 0001 - overall signal level 170 0010 - noise level 171 0011 - echo return loss 172 0100 - residual echo return loss (ACOM) 173 0101 - Y signal level 174 0110 - Cb signal level 175 0111 - Cr signal level 176 - other values reserved 178 cccccc = channel number 179 000000 - 011111 Channel number range 180 100000 - 111111 reserved 182 mm = measured or default value 183 00 - sampled value 184 01 - average value 185 10 - default or configured value 186 11 - reserved 188 dd = direction 189 00 - Received signal (this RTP session) 190 01 - Received signal (external) 191 10 - Transmitted signal (this RTP session) 192 11 - Transmitted signal (external) 194 bb = metric scaling 195 00 - dBm0 196 01 - dBm 197 10 - dBov 198 11 - reserved 200 3.2 Definition of Fields in Signal Level Metric Report Block 202 block type (BT): 8 bits 204 A Signal Level Report Block is identified by the constant 205 SLMT. 207 [Note to RFC Editor: please replace SLMT with the IANA provided RTCP 208 XR block type for this block.] 210 Interval Metric flag (I): 1 bit 212 This field is used to indicate whether the Basic Loss/Discard 213 metrics are Interval or Cumulative metrics, that is, whether the 214 reported values applies to the most recent measurement interval 215 duration between successive metrics reports (I=1) (the Interval 216 Duration) or to the accumulation period characteristic of 217 cumulative measurements (I=0) (the Cumulative Duration). 218 Numerical values for both these intervals are provided in the 220 Clark & Hunt [Page 4] 221 RTCP XR Signal Level Metrics October 2008 223 Measurement Identifier block referenced by the tag field below. 225 Measurement Identifier association (tag): 3 bits 227 This field is used to identify the Measurement Identifier block 228 which describes this measurement. The relevant Measurement 229 Identifier block has the same tag value as the Basic Loss/Discard 230 block. Note that there may be more than one Measurement 231 Identifier block per RTCP packet. 233 Block length: 16 bits 235 The length if this report block in 32-bit words minus one. 237 Signal level metrics words 239 A Signal Level Metrics report block may contain one or more 240 sets of signal level metrics, each contained in a single 241 32 bit word. 243 Reported signal level metric type 245 The signal level metric type may have the following values: 247 0000 - active signal level 248 This indicates that the reported metric is the signal 249 level during active periods, for example talkspurts 250 during speech 252 0001 - overall signal level 253 This indicates that the reported metric is the signal 254 level measured for the reporting interval, with no 255 distinction made between active signal and silent 256 periods. This would be more appropriate for an 257 audio or video signal. 259 0010 - noise level 260 This indicates that the reported metric is the noise 261 level, which could for example be measured during 262 periods of low signal activity. 264 0011 - echo return loss 265 This indicates that the reported metric is the 266 uncanceled echo return loss. 268 0100 - residual echo return loss (ACOM) 269 This indicates that the reported metric is the 270 echo return loss measured after echo cancellation. 272 0101 - Y signal level 273 This indicates that the reported metric is the level 274 of the Y or Luminance component of a video signal. 276 Clark & Hunt [Page 5] 277 RTCP XR Signal Level Metrics October 2008 279 0110 - Cb signal level 280 This indicates that the reported metric is the level 281 of the Cb chrominance component of a video signal. 283 0111 - Cr signal level 284 This indicates that the reported metric is the level 285 of the Cr chrominance component of a video signal. 287 Channel number 289 The number associated with a channel within the audio, 290 speech or video signal. For example, this could be 291 used to indicate one of the two channels of a stereo 292 audio signal. 294 Measured or default value 296 This field indicates that the reported value is either an 297 sampled value, an average over the measurement interval or 298 a default or configured value. 300 Direction 302 The Direction field indicates whether the metric refers to 303 the received or transmitted signal, and whether the value 304 has been measured for "this" RTP session (i.e. the session 305 to which the RTCP reports relate) or are "external" to the 306 RTP session. 308 Metric scaling 310 The Metric Scaling field indicates the scaling or reference 311 used for the metric. 313 00 - dBm0 - dB with reference to a milliwatt at 314 the zero reference point. 315 01 - dBm - dB with reference to a milliwatt. 316 10 - dBov - dB with reference to the overflow or maximum 317 level that can be represented within a 318 digital system. 319 11 - reserved 321 Level 323 The value of the metric in signed 8:8 scaled signed integer 324 representation. This permits a range of +/- 127.996 dB to 325 be reported. Measurement methodologies are defined in 326 references [5][6][7][8]. 328 4. SDP Signaling 330 RFC3611 [3] defines the use of SDP (Session Description Protocol) 332 Clark & Hunt [Page 6] 333 RTCP XR Signal Level Metrics October 2008 335 [4] for signaling the use of XR blocks. XR blocks MAY be used 336 without prior signaling. 338 This section augments the SDP [4] attribute "rtcp-xr" defined in 339 RFC3611[3] by providing a "xr-format" to signal the use of the 340 report block defined in this document. 342 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 343 CRLF (defined in RFC3611) 345 xr-format = xr-format / 346 siglev-metrics 348 siglev-metrics = "siglev-metrics" [EQUAL word] 349 DIGIT = %x30-39 350 format-ext = non-ws-string 351 non-ws-string = 1*(%x21-FF) 352 CRLF = %d13.10 354 5. IANA Considerations 356 This document creates a new block type within the IANA "RTCP XR Block 357 Type Registry" called the QoE Metrics, and a new [new-xrblock] 358 parameter within the "RTCP XR SDP Parameters Registry". 360 6. Security Considerations 362 RTCP reports can contain sensitive information since they can provide 363 information about the nature and duration of a session established 364 between two or more endpoints. 366 7. Contributors 368 8. References 370 Normative 372 [1] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 376 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 377 RFC 3550, July 2003. 379 [3] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol 380 Extended Reports (RTCP XR)", RFC 3611, November 2003. 382 [4] Handley, M. and V. Jacobson, "SDP: Session Description 383 Protocol", RFC 4566, July 2006. 385 Clark & Hunt [Page 7] 386 RTCP XR Signal Level Metrics October 2008 388 [5] ITU-T Recommendation G.168 "Digital Network Echo Cancellers" 390 [6] ITU-T Recommendation P.56 "Objective Measurement of Active 391 Speech Level" 393 [7] ITU-T Recommendation P.561 "In-Service, Non-Intrusive Measurement 394 Device - Voice Service Measurements" 396 [8] ITU-R BS.2054 "Audio levels and loudness" 398 Informative 400 [9] Clark, A. "Framework for Performance Metric Development 401 draft-ietf-pmol-perf-metrics-framework-00.txt 403 Author's Addresses 405 Alan Clark 406 Telchemy Incorporated 407 2905 Premiere Parkway, Suite 280 408 Duluth, GA 30097 409 USA 411 Email: alan.d.clark@telchemy.com 413 Geoff Hunt 414 BT 415 Orion 1 PP9 416 Adastral Park 417 Martlesham Heath 418 Ipswich, Suffolk IP4 2TH 419 United Kingdom 421 Email: geoff.hunt@bt.com 423 Intellectual Property Statement 425 The IETF takes no position regarding the validity or scope of any 426 Intellectual Property Rights or other rights that might be claimed to 427 pertain to the implementation or use of the technology described in 428 this document or the extent to which any license under such rights 429 might or might not be available; nor does it represent that it has 430 made any independent effort to identify any such rights. Information 431 on the procedures with respect to rights in RFC documents can be 432 found in BCP 78 and BCP 79. 434 Clark & Hunt [Page 8] 435 RTCP XR Signal Level Metrics October 2008 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org. 450 Disclaimer of Validity 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 455 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 456 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 457 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Copyright Statement 462 Copyright (C) The IETF Trust (2008). 464 This document is subject to the rights, licenses and restrictions 465 contained in BCP 78, and except as set forth therein, the authors 466 retain all their rights. 468 Acknowledgment 470 Funding for the RFC Editor function is currently provided by the 471 Internet Society. 473 Clark & Hunt [Page 9]