idnits 2.17.1 draft-ietf-avt-rtcphr-03.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1706. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 == Line 1577 has weird spacing: '... stream packe...' == Line 1578 has weird spacing: '...ication syste...' == Line 1623 has weird spacing: '...ability perfo...' == 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 (February 25, 2008) is 5905 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: 'G.1020AnnexA' is defined on line 1571, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1583, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working A. Clark 3 Group Telchemy Incorporated 4 Internet-Draft G. Hunt 5 Expires: August 23, 2008 BT 6 A. Pendleton 7 Nortel 8 R. Kumar 9 K. Connor 10 Cisco Systems 11 February 25, 2008 13 RTCP HR - High Resolution VoIP Metrics Report Blocks 14 draft-ietf-avt-rtcphr-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 23, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document defines extensions to the RTCP XR extended report 48 packet type blocks to support Voice over IP (VoIP) monitoring for 49 services that require higher resolution or more detailed metrics than 50 those supported by RFC3611. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1. Cumulative and Interval Metrics . . . . . . . . . . . . . 6 57 2.2. Bursts, Gaps, and Concealed Seconds . . . . . . . . . . . 6 58 2.3. Numeric formats . . . . . . . . . . . . . . . . . . . . . 6 59 3. High Resolution VoIP Metrics Report Block . . . . . . . . . . 8 60 3.1. Block Description . . . . . . . . . . . . . . . . . . . . 8 61 3.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 3.2.1. Block type . . . . . . . . . . . . . . . . . . . . . . 10 63 3.2.2. Map field . . . . . . . . . . . . . . . . . . . . . . 10 64 3.2.3. Block Length . . . . . . . . . . . . . . . . . . . . . 11 65 3.2.4. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.2.5. Duration . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.3. Basic Loss/ Discard Metrics . . . . . . . . . . . . . . . 11 68 3.3.1. Loss Proportion . . . . . . . . . . . . . . . . . . . 12 69 3.3.2. Discard Proportion . . . . . . . . . . . . . . . . . . 12 70 3.3.3. Number of frames expected . . . . . . . . . . . . . . 12 71 3.4. Burst/Gap metrics sub-block . . . . . . . . . . . . . . . 12 72 3.4.1. Threshold . . . . . . . . . . . . . . . . . . . . . . 13 73 3.4.2. Burst Duration (ms) . . . . . . . . . . . . . . . . . 13 74 3.4.3. Gap Duration (ms) . . . . . . . . . . . . . . . . . . 13 75 3.4.4. Burst Loss/Discard Proportion . . . . . . . . . . . . 13 76 3.4.5. Gap Loss/Discard Proportion . . . . . . . . . . . . . 14 77 3.5. Playout Metrics sub-block . . . . . . . . . . . . . . . . 14 78 3.5.1. On-time Playout Duration . . . . . . . . . . . . . . . 14 79 3.5.2. On-time Active Speech Playout Duration . . . . . . . . 15 80 3.5.3. Loss Concealment Duration . . . . . . . . . . . . . . 15 81 3.5.4. Buffer Adjustment Concealment Duration (optional) . . 15 82 3.6. Concealed Seconds metrics sub-block . . . . . . . . . . . 16 83 3.6.1. Unimpaired Seconds . . . . . . . . . . . . . . . . . . 17 84 3.6.2. Concealed Seconds . . . . . . . . . . . . . . . . . . 17 85 3.6.3. Severely Concealed Seconds . . . . . . . . . . . . . . 17 86 3.6.4. SCS Threshold . . . . . . . . . . . . . . . . . . . . 18 87 3.7. Delay and Packet Delay Variation (PDV) metrics 88 sub-block . . . . . . . . . . . . . . . . . . . . . . . . 18 89 3.7.1. Network Round Trip Delay (ms) . . . . . . . . . . . . 18 90 3.7.2. End System Delay (ms) . . . . . . . . . . . . . . . . 18 91 3.7.3. External Delay (ms) . . . . . . . . . . . . . . . . . 18 92 3.7.4. PDV/Jitter Metrics . . . . . . . . . . . . . . . . . . 19 93 3.7.5. PDV Type . . . . . . . . . . . . . . . . . . . . . . . 21 94 3.7.6. Jitter Buffer / PLC Configuration . . . . . . . . . . 22 95 3.7.7. Jitter Buffer Size parameters . . . . . . . . . . . . 22 96 3.8. Call Quality Metrics sub-block . . . . . . . . . . . . . . 22 97 3.8.1. Listening and Conversation Quality R Factors - 98 R-LQ, R-CQ . . . . . . . . . . . . . . . . . . . . . . 22 99 3.8.2. Listening and Conversation Quality MOS - MOS-LQ, 100 MOS-CQ . . . . . . . . . . . . . . . . . . . . . . . . 22 101 3.8.3. R-LQ Ext In and Out . . . . . . . . . . . . . . . . . 23 102 3.8.4. RFC3550 RTP Payload Type . . . . . . . . . . . . . . . 24 103 3.8.5. Media Type . . . . . . . . . . . . . . . . . . . . . . 24 104 3.8.6. Received Signal and Noise Levels - IP side . . . . . . 24 105 3.8.7. Received Signal and Noise Levels - External . . . . . 24 106 3.8.8. Local and Remote Residual Echo Return Loss . . . . . . 25 107 3.8.9. Metric Status . . . . . . . . . . . . . . . . . . . . 25 108 4. RTCP HR Configuration Block . . . . . . . . . . . . . . . . . 28 109 4.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 4.1.1. Block type . . . . . . . . . . . . . . . . . . . . . . 28 111 4.1.2. Map field . . . . . . . . . . . . . . . . . . . . . . 29 112 4.1.3. Block Length . . . . . . . . . . . . . . . . . . . . . 29 113 4.1.4. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 4.2. Correlation Tag . . . . . . . . . . . . . . . . . . . . . 29 115 4.3. Algorithm descriptor . . . . . . . . . . . . . . . . . . . 30 116 5. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . . 32 117 5.1. The SDP Attributes . . . . . . . . . . . . . . . . . . . . 32 118 5.2. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 34 119 5.3. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 35 120 6. Practical Applications . . . . . . . . . . . . . . . . . . . . 36 121 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 36 122 6.2. Supplementary Services: Call Hold and Transfer . . . . . . 36 123 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 36 124 6.2.2. Supplementary Service: Call Transfer . . . . . . . . . 36 125 6.2.3. Supplementary Service: Call Hold . . . . . . . . . . . 37 126 6.3. Bitrate efficiency improvements: VAD/Silence 127 Suppression based on Voice Activity Detection (VAD) 128 Elimination . . . . . . . . . . . . . . . . . . . . . . . 37 129 6.4. Endpoint configuration changes mid-call . . . . . . . . . 37 130 6.4.1. Changes due to mid-call transitions between 131 different voice codec types . . . . . . . . . . . . . 37 132 6.4.2. Changes due to mid-call transitions from VoIP to 133 RTP-based VBDoIP . . . . . . . . . . . . . . . . . . . 37 134 6.4.3. Changes due to mid-call transitions from VoIP to 135 non-RTP -based VBDoIP . . . . . . . . . . . . . . . . 38 136 6.5. SSRC changes mid-call . . . . . . . . . . . . . . . . . . 38 137 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 138 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 139 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 140 10. Informative References . . . . . . . . . . . . . . . . . . . . 42 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 142 Intellectual Property and Copyright Statements . . . . . . . . . . 45 144 1. Introduction 146 This draft defines several new block types to augment those defined 147 in [RFC3611] for use in Quality of Service reporting for Voice over 148 IP. The new block types support the reporting of metrics to a higher 149 resolution to support certain applications, for example carrier 150 backbone networks. 152 For certain types of VoIP service it is desirable to report VoIP 153 performance metrics to a higher resolution than provided in the 154 [RFC3611] VoIP Metrics block or [RFC3550] Receiver Reports. The 155 report blocks described in this section provide both interval based 156 and cumulative metrics with a higher resolution than that provided in 157 the [RFC3611] VoIP metrics report block. 159 The new block types defined in this draft are the High Resolution 160 VoIP Metrics Report Block, and the High Resolution VoIP Metrics 161 Configuration Block. 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119. 167 2. Definitions 169 2.1. Cumulative and Interval Metrics 171 Cumulative metrics relate to the entire duration of the call to the 172 point at which metrics are determined and reported, and are typically 173 used to report call quality. Cumulative metrics generally result in 174 a lower volume of data that may need to be stored, as each report 175 supersedes earlier reports. 177 Interval metrics relate to the period since the last Interval report. 178 Interval data may be easier to correlate with specific network events 179 for which timing is known, and may also be used as a basis for 180 threshold crossing alerts. 182 Note that interval metrics for the start and end of calls may be 183 unreliable due to factors such as irregular start and end interval 184 length and the difficulty in knowing when packet transmission started 185 and ended. 187 2.2. Bursts, Gaps, and Concealed Seconds 189 The terms Burst and Gap are used in a manner consistent with that of 190 RTCP XR [RFC3611]. RTCP XR views a call as being divided into 191 bursts, which are periods during which the combined packet loss and 192 discard rate is high enough to cause noticeable call quality 193 degradation (generally over 5 percent loss/discard rate), and gaps, 194 which are periods during which lost or discarded packets are 195 infrequent and hence call quality is generally acceptable. 197 The recommended value for Gmin in [RFC3611] results in a Burst being 198 a period of time during which the call quality is degraded to a 199 similar extent to a typical PCM Severely Errored Second. 201 The term Concealed Seconds defines a count of seconds during which 202 some proportion of the media stream was lost through packet loss and 203 discard. The term Severely Concealed Seconds defines a count of 204 seconds during which the proportion of the media stream lost through 205 packet loss and discardeds a specified threshold. 207 2.3. Numeric formats 209 This report block makes use of binary fractions. The terminology 210 used is 212 S X:Y 214 where S indicates a two's complement signed representation, X the 215 number of bits prior to the decimal place and Y the number of bits 216 after the decimal place. 218 Hence 8:8 represents an unsigned number in the range 0.0 to 255.996 219 with a granularity of 0.0039. S7:8 would represent the range 220 -128.000 to +127.996. 222 3. High Resolution VoIP Metrics Report Block 224 3.1. Block Description 226 This block comprises a header and a series of sub-blocks. The Map 227 field in the header defines which sub-blocks are present. 229 Header sub-block 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | BT=N | Map | block length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | SSRC of source | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Duration | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Basic Loss/Discard Metrics sub-block 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Loss Proportion | Discard Proportion | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Number of frames expected | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Burst/Gap metrics sub-block 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Threshold | Burst Duration (ms) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Gap Duration (ms) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Burst Loss/Disc Proportion | Gap Loss/Disc Proportion | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Playout metrics sub-block 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | On-time Playout Duration | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | On-time Active Speech Playout Duration | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Loss Concealment Duration | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Buffer Adjustment Concealment Duration | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Concealed Seconds metrics sub-block 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Unimpaired Seconds | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Concealed Seconds | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Severely Concealed Seconds | RESERVED | SCS Threshold | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Delay and PDV metrics sub-block 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Network Round Trip Delay | End System Delay | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | External Delay | Mean PDV | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Pos Threshold/Peak PDV | Pos PDV Percentile | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Neg Threshold/Peak PDV | Neg PDV Percentile | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | PDV Type | JB/PLC config | JB nominal | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | JB maximum | JB abs max | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | JB high water mark | JB low water mark | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Call Quality metrics sub-block 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | R-LQ | R-CQ | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | MOS-LQ | MOS-CQ | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | R-LQ Ext In | R-LQ Ext Out |RFC3550 Payload| Media Type | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | RxSigLev (IP) |RxNoiseLev (IP)| Local RERL | Remote RERL | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | RxSigLev (Ext)|RxNoiseLev(Ext)| Metric Status | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 3.2. Header 318 Implementations MUST send the Header block within each High 319 Resolution Metrics report. 321 3.2.1. Block type 323 Three High Resolution VoIP Metrics blocks are defined 325 mmm = HR Metrics- Cumulative 327 mmm+1 = HR Metrics- Interval 329 mmm+2 = HR Metrics- Alert 331 The time interval associated with these report blocks is left to the 332 implementation. Spacing of RTCP reports should be in accordance with 333 RFC3550. The specific timing of RTCP HR reports may be determined in 334 response to an internally derived alert such as a threshold violation 335 however the interval between RTCP HR reports must not be less than 336 the minimum determined according to RFC3550. 338 Note that interval data may be derived by subtracting successive 339 cumulative reports, which provides increased tolerance to potential 340 loss of RTCP reports. 342 3.2.2. Map field 344 A Map field indicates the optional sub-blocks present in this report. 345 A 1 indicates that the sub-block is present, and a 0 that the block 346 is absent. If present, the sub-blocks must be in the sequence 347 defined in this document. The bits have the following definitions: 349 0 Burst/Gap Metrics block 351 1 Playout Metrics block 353 2 Concealed Seconds Metrics block 355 3 Call Quality Metrics 357 4-7 Reserved, set to 0 359 3.2.3. Block Length 361 The block length indicates the length of this report in 32 bit words 362 and includes the header. 364 3.2.4. SSRC 366 The SSRC of the stream to which this report relates. The value of 367 this field shall follow the rules defined in RFC3550 with regard to 368 the forwarding of RTP and RTCP messages. 370 3.2.5. Duration 372 The duration of time for which this report applies expressed in 373 milliseconds. For cumulative reports this would be the call 374 duration. For interval reports this would be the duration of the 375 interval. 377 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 378 be reported to indicate an over-range measurement. If the 379 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 381 3.3. Basic Loss/ Discard Metrics 383 The Basic Loss/Discard Metrics sub-block MUST be present. 385 This block reports the proportion of frames lost by the network and 386 the proportion of frames discarded due to jitter. 388 For sample-based codecs such as G.711, a frame shall be defined as an 389 RTP frame. For endpoints that incorporate jitter buffers capable of 390 fractional frame discard the proportion of frames discarded MAY be 391 determined on the basis of the proportion of samples discarded. If 392 Voice Activity Detection is used then the proportion of frames lost 393 and discarded shall be determined based on transmitted packets, i.e. 394 frames that contained silence and were not transmitted shall not be 395 considered. 397 A frame shall be regarded as lost if it fails to arrive within an 398 implementation-specific time window. A frame that arrives within 399 this time window but is too early or late to be played out shall be 400 regarded as discarded. A frame shall be classified as one of 401 received (or OK), discarded or lost. 403 The Loss and Discard metrics are determined after the effects of FEC, 404 redundancy [RFC2198] or other similar process. 406 3.3.1. Loss Proportion 408 Proportion of frames lost within the network expressed as a binary 409 fraction in 0:16 format. Duplicate frames shall be disregarded. 411 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 412 reported to indicate an over-range measurement. If the measurement 413 is unavailable, the value 0xFFFF SHOULD be reported. 415 3.3.2. Discard Proportion 417 Proportion of voice frames received but discarded due to late or 418 early arrival, expressed as a binary fraction in 0:16 format. 420 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 421 reported to indicate an over-range measurement. If the measurement 422 is unavailable, the value 0xFFFF SHOULD be reported. 424 3.3.3. Number of frames expected 426 A count of the number of frames expected, estimated if necessary. If 427 no frames have been received then this count shall be set to zero. 429 If the number expected exceeds 0xFFFFFFFD, the value 0xFFFFFFFE 430 SHOULD be reported to indicate an over-range measurement. If the 431 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 433 3.4. Burst/Gap metrics sub-block 435 The Burst/Gap metrics sub-block MAY be present and if present MUST be 436 indicated in the Map field. 438 This block provides information on transient IP problems and is able 439 to represent the combined effect of packet loss and packet discard. 440 Burst/Gap metrics are typically used in Cumulative reports however 441 MAY be used in Interval reports. 443 The definition of Burst and Gap is consistent with that defined in 444 the [RFC3611] VoIP Metrics block, with the clarification that Loss 445 and Discard are defined in terms of frames (as described in 446 Section 3.3 above). To accomodate the range of jitter buffer 447 algorithms and packet discard logic that may be used by implementors, 448 the method used to distinguish between bursts and gaps may be an 449 equivalent method to that defined in RFC3611. The method used SHOULD 450 produce the same result as that defined in RFC3611 for conditions of 451 burst packet loss, but MAY produce different results for conditions 452 of time varying jitter. 454 If Voice Activity Detection is used the Burst and Gap Duration shall 455 be determined as if silence frames had been sent, i.e. a period of 456 silence in excess of Gmin frames MUST terminate a burst condition. 458 The Burst/Gap Metrics sub-block contains the following elements. 460 3.4.1. Threshold 462 The Threshold is equivalent to Gmin in RFC3611, i.e. the number of 463 successive frames that must be received and not discarded prior to 464 and following a lost or discarded frame in order for this lost or 465 discarded frame to be regarded as part of a gap. 467 3.4.2. Burst Duration (ms) 469 The average duration of a burst of lost and discarded frames. 471 If the measured value exceeds 0xFFFFFD, the value 0xFFFFFE SHOULD be 472 reported to indicate an over-range measurement. If the measurement 473 is unavailable, the value 0xFFFFFF SHOULD be reported. 475 3.4.3. Gap Duration (ms) 477 The average duration of periods between bursts. 479 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 480 be reported to indicate an over-range measurement. If the 481 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 483 3.4.4. Burst Loss/Discard Proportion 485 The proportion of Lost and Discarded frames during Bursts expressed 486 as a binary fraction expressed in 0:16 format. 488 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 489 reported to indicate an over-range measurement. If the measurement 490 is unavailable, the value 0xFFFF SHOULD be reported. 492 3.4.5. Gap Loss/Discard Proportion 494 The proportion of Lost and Discarded frames during Gaps expressed as 495 a binary fraction expressed in 0:16 format. 497 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 498 reported to indicate an over-range measurement. If the measurement 499 is unavailable, the value 0xFFFF SHOULD be reported. 501 3.5. Playout Metrics sub-block 503 The Playout Duration metrics sub-block MAY be present and if present 504 MUST be indicated in the Map field. 506 At any instant, the audio output at a receiver may be classified as 507 either 'normal' or 'concealed'. 'Normal' refers to playout of audio 508 payload received from the remote end, and also includes locally 509 generated signals such as announcements, tones and comfort noise. 510 Concealment refers to playout of locally-generated signals used to 511 mask the impact of network impairments or to reduce the audibility of 512 jitter buffer adaptations. 514 This sub-block accounts for the source of the output audio, in 515 millisecond units. The on-time and active speech playout durations 516 allow calculation of the voice activity fraction. The on-time, and 517 concealment durations allow calculation of concealment ratios. This 518 sub-block distinguishes between reactive (due to effective packet 519 loss) and proactive (due to buffer adaptation) concealment. 521 3.5.1. On-time Playout Duration 523 'On-time' playout is the uninterrupted, in-sequence playout of valid 524 decoded audio information originating from the remote endpoint. This 525 includes comfort noise during periods of remote talker silence, if 526 VAD is used, and locally generated or regenerated tones and 527 announcements. 529 An equivalent definition is that on-time playout is playout of any 530 signal other than those used for concealment. 532 On-time playout duration MUST include both speech and silence 533 intervals, whether VAD is used or not. This duration is reported in 534 millisecond units. 536 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 537 be reported to indicate an over-range measurement. If the 538 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 540 3.5.2. On-time Active Speech Playout Duration 542 The duration, in milliseconds, of the on-time playout duration 543 corresponding to playout of active speech signals, if known. 545 In the absence of silence suppression, on-time active speech playout 546 equals on-time playout (Section 3.5.1). 548 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 549 be reported to indicate an over-range measurement. If the 550 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 552 3.5.3. Loss Concealment Duration 554 The duration, in milliseconds, of audio playout corresponding to 555 Loss-type concealment. 557 Loss-type concealment is reactive insertion or deletion of samples in 558 the audio playout stream due to effective frame loss at the audio 559 decoder. "Effective frame loss" is the event in which a frame of 560 coded audio is simply not present at the audio decoder when required. 561 In this case, substitute audio samples are generally formed, at the 562 decoder or elsewhere, to reduce audible impairment. 564 Only loss-type concealment is necessary to form Concealed and 565 Severely Concealed Seconds counts, in Section 3.6. 567 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 568 be reported to indicate an over-range measurement. If the 569 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 571 3.5.4. Buffer Adjustment Concealment Duration (optional) 573 The duration, in milliseconds, of audio playout corresponding to 574 Buffer Adjustment-type concealment, if known. 576 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 577 be reported to indicate an over-range measurement. If the 578 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 580 Buffer Adjustment-type concealment is proactive or controlled 581 insertion or deletion of samples in the audio playout stream due to 582 jitter buffer adaptation, re-sizing or re-centering decisions within 583 the endpoint. 585 Because this insertion is controlled, rather than occurring randomly 586 in response to losses, it is typically less audible than loss-type 587 concealment (Section 3.5.3). For example, jitter buffer adaptation 588 events may be constrained to occur during periods of talker silence, 589 in which case only silence duration is affected, or sophisticated 590 time-stretching methods for insertion/deletion during favorable 591 periods in active speech may be employed. For these reasons, buffer 592 adjustment-type concealment MAY be exempted from inclusion in 593 calculations of Concealed Seconds and Severely Concealed Seconds. 595 However, an implementation SHOULD include buffer-type concealment in 596 counts of Concealed Seconds and Severely Concealed Seconds if the 597 event occurs at an 'inopportune' moment, with an emergency or large, 598 immediate adaptation during active speech, or for unsophisticated 599 adaptation during speech without regard for the underlying signal, in 600 which cases the assumption of low-audibility cannot hold. In other 601 words, jitter buffer adaptation events which may be presumed to be 602 audible SHOULD be included in Concealed Seconds and Severely 603 Concealed Seconds counts. 605 Concealment events which cannot be classified as Buffer Adjustment- 606 type MUST be classified as Loss-type. 608 3.6. Concealed Seconds metrics sub-block 610 The Concealed Seconds metrics sub-block MAY be present and if present 611 MUST be indicated in the Map field. 613 This sub-block provides a description of potentially audible 614 impairments due to lost and discarded packets at the endpoint, 615 expressed on a time basis analogous to a traditional PSTN T1/E1 616 errored seconds metric. 618 The following metrics are based on successive one second intervals as 619 declared by a local clock. This local clock does NOT need to be 620 synchronized to any external time reference. The starting time of 621 this clock is unspecified. Note that this implies that the same loss 622 pattern could result in slightly different count values, depending on 623 where the losses occur relative to the particular one-second 624 demarcation points. For example, two loss events occurring 50ms 625 apart could result in either one concealed second or two, depending 626 on the particular 1000 ms boundaries used. 628 The seconds in this sub-block are not necessarily calendar seconds. 629 At the tail end of a call, periods of time of less than 1000ms shall 630 be incorporated into these counts if they exceed 500ms and shall be 631 disregarded if they are less than 500ms. 633 3.6.1. Unimpaired Seconds 635 A count of the number of unimpaired Seconds that have occurred. 637 An unimpaired Second is defined as a continuous period of 1000ms 638 during which no frame loss or discard due to late arrival has 639 occurred. Every second in a call must be classified as either OK or 640 Concealed. 642 Normal playout of comfort noise or other silence concealment signal 643 during periods of talker silence, if VAD is used, shall be counted as 644 unimpaired seconds. 646 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 647 be reported to indicate an over-range measurement. If the 648 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 650 3.6.2. Concealed Seconds 652 A count of the number of Concealed Seconds that have occurred. 654 A Concealed Second is defined as a continuous period of 1000ms during 655 which any frame loss or discard due to late arrival has occurred. 657 Equivalently, a concealed second is one in which some Loss-type 658 concealment (defined in Section 3.6) has occurred. Buffer 659 adjustment-type concealment SHALL not cause Concealed Seconds to be 660 incremented, with the following exception. An implementation MAY 661 cause Concealed Seconds to be incremented for 'emergency' buffer 662 adjustments made during talkspurts. 664 For clarification, the count of Concealed Seconds MUST include the 665 count of Severely Concealed Seconds. 667 If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD 668 be reported to indicate an over-range measurement. If the 669 measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported. 671 3.6.3. Severely Concealed Seconds 673 A count of the number of Severely Concealed Seconds. 675 A Severely Concealed Second is defined as a non-overlapping period of 676 1000 ms during which the cumulative amount of time that has been 677 subject to frame loss or discard due to late arrival, exceeds the SCS 678 Threshold. 680 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 681 reported to indicate an over-range measurement. If the measurement 682 is unavailable, the value 0xFFFF SHOULD be reported. 684 3.6.4. SCS Threshold 686 The SCS Threshold defines the amount of time corresponding to lost or 687 discarded frames that must occur within a one second period in order 688 for the second to be classified as a Severely Concealed Second. This 689 is expressed in milliseconds and hence can represent a range of 0.1 690 to 25.5 percent loss or discard. 692 A default threshold of 50ms (5% effective frame loss per second) is 693 suggested. 695 3.7. Delay and Packet Delay Variation (PDV) metrics sub-block 697 The Delay and PDV metrics sub-block MUST be present. This sub-block 698 contains a number of parameters related to overall delay (latency), 699 delay variation and the current jitter buffer configuration. 701 3.7.1. Network Round Trip Delay (ms) 703 The Network Round Trip Delay is the most recently measured value of 704 the RTP-to-RTP interface round trip delay, typically determined using 705 RTCP SR/RR. 707 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 708 reported to indicate an over-range measurement. If the measurement 709 is unavailable, the value 0xFFFF SHOULD be reported. 711 3.7.2. End System Delay (ms) 713 The End System Delay is the internal round trip delay within the 714 reporting endpoint, calculated using the nominal value of the jitter 715 buffer delay plus the accumulation/ encoding and decoding / playout 716 delay associated with the codec being used. 718 If the measured or estimated value exceeds 0xFFFD, the value 0xFFFE 719 SHOULD be reported to indicate an over-range measurement. If the 720 measurement is unavailable, the value 0xFFFF SHOULD be reported. 722 3.7.3. External Delay (ms) 724 The External Network Delay parameter indicates external network round 725 trip delay through cellular, satellite or other types of network with 726 significant delay impact, if known. 728 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 729 reported to indicate an over-range measurement. If the measurement 730 is unavailable, the value 0xFFFF SHOULD be reported. 732 If the external network is IP based then this parameter is typically 733 determined using RTCP SR/RR. If the external network delay is known 734 and does not vary materially then this value may be provisioned. 736 Where there is any ambiguity in assigning a delay contribution to one 737 of the three metrics of Network Round Trip Delay, End System Delay, 738 and External Delay, the following guidance is provided. The 739 objective is that the sum of the three metrics SHOULD approximate as 740 closely as possible to the sum of the delays "mouth to ear". Each 741 significant source of delay SHOULD be counted in one, and only one, 742 of the three metrics. 744 For slow links where packet serialisation delays are significant, 745 delays should be referenced to the same point within the packet for 746 both send and receive interfaces, e.g. the delay should be measured 747 from the time at which the first bit of a packet leaves the send 748 interface, to the time at which the first bit of a packet arrives at 749 the receive interface. Definitions of delay which use different 750 reference points on the packet at different interfaces, e.g. "first 751 bit sent to last bit received", are likely to lead to errors from 752 double-counting the serialisation delay when adding contributions. 754 3.7.4. PDV/Jitter Metrics 756 Jitter metrics defined are: 758 3.7.4.1. Mean PDV 760 For MAPDV this value is generated according to ITU-T G.1020. For 761 interval reports the MAPDV value is reset at the start of the 762 interval. 764 For PPDV the value reported is the value of J(i) calculated according 765 to RFC3550 at the time the report is generated. 767 (16 bit, S11:4 format) expressed in milliseconds 769 If the measured value is more negative than -2047.9375 (the value 770 which would be coded as 0x8001), the value 0x8000 SHOULD be reported 771 to indicate an over-range negative measurement. If the measured 772 value is more positive than +2047.8125 (the value which would be 773 coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an 774 over-range positive measurement. If the measurement is unavailable, 775 the value 0x7FFF SHOULD be reported. 777 3.7.4.2. Positive Threshold/Peak PDV 779 The PDV associated with the Positive PDV percentile (16 bit, S11:4 780 format) expressed in milliseconds. The term Positive is associated 781 with packets arriving later than the expected time. 783 If the measured value is more negative than -2047.9375 (the value 784 which would be coded as 0x8001), the value 0x8000 SHOULD be reported 785 to indicate an over-range negative measurement. If the measured 786 value is more positive than +2047.8125 (the value which would be 787 coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an 788 over-range positive measurement. If the measurement is unavailable, 789 the value 0x7FFF SHOULD be reported. 791 3.7.4.3. Negative Threshold/Peak PDV 793 The PDV associated with the Negative PDV percentile (16 bit, S11:4 794 format) expressed in milliseconds. The term Negative is associated 795 with packets arriving earlier than the expected time. 797 If the measured value is more negative than -2047.9375 (the value 798 which would be coded as 0x8001), the value 0x8000 SHOULD be reported 799 to indicate an over-range negative measurement. If the measured 800 value is more positive than +2047.8125 (the value which would be 801 coded as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an 802 over-range positive measurement. If the measurement is unavailable, 803 the value 0x7FFF SHOULD be reported. 805 3.7.4.4. Positive PDV Percentile 807 The percentage of packets on the call for which individual packet 808 delays were less than the Positive Threshold PDV expressed in 8:8 809 format. 811 If the measurement is unavailable, the value 0xFFFF SHOULD be 812 reported. 814 3.7.4.5. Negative PDV Percentile 816 The percentage of packets on the call for which individual packet 817 delays were more than the Negative Threshold PDV expressed in 8:8 818 format. 820 If the measurement is unavailable, the value 0xFFFF SHOULD be 821 reported. 823 If the PDV Type indicated is IPDV and the Positive and Negative PDV 824 Percentiles are set to 100.0 then the Positive and Negative 825 Threshold/Peak PDV values are the peak values measured during the 826 reporting interval (which may be from the start of the call for 827 cumulative reports). In this case, the difference between the 828 Positive and Negative Threshold/Peak values defines the range of 829 IPDV. 831 3.7.5. PDV Type 833 Indicates the type of algorithm used to calculate PDV: 835 0: PPDV according to [RFC3550], 837 1: MAPDV according to [G.1020], 839 2: IPDV according to [Y.1540] 841 Other values reserved 843 For example:- 845 (a) To report PPDV (RFC3550): 847 Threshold PDV = FFFF (Undefined); PDV Percentile = FFFF (Undefined); 848 PDV type = 0 (PPDV) 850 causes PPDV to be reported in the Mean PDV field. 852 (b) To report MAPDV (G.1020): 854 Pos Threshold PDV = 50.0; Pos PDV Percentile = 95.3; Neg Threshold 855 PDV = 50.0 (note - implies -50ms); Neg PDV Percentile = 98.4; PDV 856 type = 1 (MAPDV) 858 causes average MAPDV to be reported in the Mean PDV field. 860 Note that implementations may either fix the reported percentile and 861 calculate the associated PDV level OR may fix a threshold PDV level 862 and calculate the associated percentile. From a practical 863 implementation perspective it is simpler to use the second of these 864 approaches (except of course in the extreme case of a 100% 865 percentile). 867 IPDV, according to Y.1540 is the difference in delay between the i-th 868 packet and the first packet of the stream. If the sending and 869 receiving clocks are not synchronized, this metric includes the 870 effect of relative timing drift. 872 3.7.6. Jitter Buffer / PLC Configuration 874 Indicates the configuration of the jitter buffer and the type of PLC 875 algorithm in use. 877 bits 0-3 878 0 = silence insertion 879 1 = simple replay, no attenuation 880 2 = simple replay, with attenuation 881 3 = enhanced 882 Other values reserved 884 bits 4-7 885 0 = Fixed jitter buffer 886 1 = Adaptive jitter buffer 887 Other values reserved 889 3.7.7. Jitter Buffer Size parameters 891 Current nominal, maximum and absolute maximum jitter buffer size 892 expressed in milliseconds, as defined in [RFC3611]. 894 3.8. Call Quality Metrics sub-block 896 The Call Quality Metrics sub-block MAY be present and if present MUST 897 be indicated in the Header Map field. This sub-block reports call 898 quality metrics and estimates of signal, noise and echo levels. 900 Signal, noise and echo metrics should be long term averages and 901 should not be instantaneous values. 903 3.8.1. Listening and Conversation Quality R Factors - R-LQ, R-CQ 905 Expresses listening and conversational quality in terms of R factor, 906 a 0-120 scaled parameter in 8:8 format. The algorithm used to 907 calculate R factor MAY be defined in the RTCP HR Configuration block 908 (see Section 4). 910 If the measurement is unavailable, the value 0xFFFF SHOULD be 911 reported. 913 3.8.2. Listening and Conversation Quality MOS - MOS-LQ, MOS-CQ 915 Expresses listening and conversational quality in terms of MOS, a 1-5 916 scaled parameter in 8:8 format. The algorithm used to calculate MOS 917 MAY be defined in the RTCP HR Configuration block. 919 Note that R factors and MOS scores may be defined for both narrow and 920 wide-band VoIP calls. R Factors are continuous for narrow and 921 wideband, hence the R factor for a wideband call may be higher than 922 that for a narrowband call. MOS scores are scaled relative to 923 reference conditions and hence both narrow and wideband MOS occupy 924 the same 1-5 scale; this can lead to a wideband MOS being lower than 925 a narrowband MOS even though the listening quality may be higher. 927 If the measurement is unavailable, the value 0xFFFF SHOULD be 928 reported. 930 3.8.3. R-LQ Ext In and Out 932 These parameters provide call quality information for external 933 networks - for example an external PCM or cellular network - or for a 934 reporting call quality from the "other" side of a transcoding device 935 or mixer - for example a conference bridge. 937 R-LQ Ext In - measured by this endpoint for incoming connection on 938 "other" side of this endpoint. A 0-120 scaled parameter in 7:1 939 format. If the measurement is unavailable, the value 0xFF SHOULD be 940 reported. 942 R-LQ Ext Out - copied from RTCP XR message received from remote 943 endpoint on "other" side of this endpoint A 0-120 scaled parameter in 944 7:1 format. If the measurement is unavailable, the value 0xFF SHOULD 945 be reported. 947 e.g. Phone A <---> Bridge <----> Phone B 949 In XR message from Bridge to Phone A:- 951 - R-LQ = quality for PhoneA ----> Bridge path 953 - R-LQ-ExtIn = quality for Bridge <---- Phone B path 955 - R-LQ-ExtOut = quality for Bridge -----> Phone B path 957 This allows PhoneA to assess 959 (i) received quality from the combination of 961 R-LQ measured at A and R-LQ-ExtIn reported by the Bridge to A 963 (ii) remote endpoint quality from the combination of 965 R-LQ reported by the Bridge and R-LQ-ExtOut reported by the Bridge 967 3.8.4. RFC3550 RTP Payload Type 969 The RTP Payload type field - as per RFC3551 and 970 http://www.iana.org/assignments/rtp-parameters. Where payload type 971 is dynamically assigned, the correlation tag mechanism (Section 4.2) 972 may be used to find signalling-layer information which binds the 973 Payload Type to a specific codec. 975 3.8.5. Media Type 977 Media type - 978 0 = No media present 979 1 = Narrowband audio 980 2 = Wideband audio 982 3.8.6. Received Signal and Noise Levels - IP side 984 The received signal level during talkspurts and the noise level 985 expressed in dBm0, for the decoded packet stream. Expressed in S7 986 format. 988 If the measured value is more negative than -127 dBm0 (the value 989 which would be coded as 0x81), the value 0x8000 SHOULD be reported to 990 indicate an over-range negative measurement. If the measured value 991 is more positive than +125 dBm0 (the value which would be coded as 992 0x7D), the value 0x7E SHOULD be reported to indicate an over-range 993 positive measurement. If the measurement is unavailable, the value 994 0x7F SHOULD be reported. Either over-range is extremely unlikely for 995 such a power measurement. 997 3.8.7. Received Signal and Noise Levels - External 999 The received signal level during talkspurts and the noise level 1000 expressed in dBm0, for the PCM side of a gateway, audio input from a 1001 handset or decoded packet stream for an IP-to-IP gateway. Expressed 1002 in S7 format. 1004 If the measured value is more negative than -127 dBm0 (the value 1005 which would be coded as 0x81), the value 0x8000 SHOULD be reported to 1006 indicate an over-range negative measurement. If the measured value 1007 is more positive than +125 dBm0 (the value which would be coded as 1008 0x7D), the value 0x7E SHOULD be reported to indicate an over-range 1009 positive measurement. If the measurement is unavailable, the value 1010 0x7F SHOULD be reported. Either over-range is extremely unlikely for 1011 such a power measurement. 1013 3.8.8. Local and Remote Residual Echo Return Loss 1015 The Local and Remote Residual Echo Return Loss (RERL) expressed in 1016 dB. The Local RERL is the echo level that would be reflected into 1017 the IP path due to line echo on the circuit switched element side of 1018 this IP endpoint if a gateway or acoustic echo if a handset or 1019 wireless terminal. Expressed in S7 format. 1021 The Remote RERL is the echo level that would be reflected into the 1022 remote IP endpoint from the network "behind" it, and would typically 1023 be measured at and reported from the remote endpoint. This value is 1024 included as it may be used in calculating the R-CQ and MOS-CQ values 1025 expressed in this report block. Expressed in S7 format. 1027 If the measured RERL value is more negative than -127 dB (the value 1028 which would be coded as 0x81), the value 0x8000 SHOULD be reported to 1029 indicate an over-range negative measurement. If the measured value 1030 is more positive than +125 dB (the value which would be coded as 1031 0x7D), the value 0x7E SHOULD be reported to indicate an over-range 1032 positive measurement. If the measurement is unavailable, the value 1033 0x7F SHOULD be reported. Either over-range is extremely unlikely for 1034 such a power ratio measurement. 1036 3.8.9. Metric Status 1038 Indicates the source of parameter values used in call quality 1039 calculation: 1041 Bit Description Source 1043 0-1 Local IP side Signal/Noise Levels measured on the incoming 1044 decoded VoIP stream to this endpoint 1046 00 = assumed 1047 01 = measured for this call 1048 10 = measured across multiple calls on this port 1049 11 = measured across multiple ports 1051 2-3 Remote IP side Signal/Noise Levels reported by the remote 1052 IP endpoint through RTCP XR or equivalent 1054 00 = assumed 1055 01 = measured for this call 1056 10 = measured across multiple calls on this port 1057 11 = measured across multiple ports 1059 4-5 Local Trunk side Signal/Noise Levels measured on the 1060 incoming PCM, Audio or non-IP side of this endpoint 1062 00 = assumed 1063 01 = measured for this call 1064 10 = measured across multiple calls on this port 1065 11 = measured across multiple ports 1067 6-7 Local Echo level measured in the incoming line/ trunk/ 1068 handset direction at this endpoint after the effects of echo 1069 cancellation 1071 00 = assumed 1072 01 = measured for this call 1073 10 = measured across multiple calls on this port 1074 11 = measured across multiple ports 1076 8 Remote Echo level measured in the incoming line/ trunk/ 1077 handset direction at the remote endpoint after the effects of 1078 echo cancellation and reported to this endpoint via RTCP XR 1079 or equivalent. 1081 0 = assumed 1082 1 = reported from remote endpoint 1084 9-15 Reserved 1086 For example, if this endpoint is "C" in the diagram below then the 1087 following definitions would apply. 1089 Endpoint B <-----RTP-------> Gateway C <-----PCM-------> D 1090 "Remote" "Local" "Trunk/PCM/External" 1092 Reporting endpoint is "C" 1094 Local IP side signal/noise metrics relate to signal/noise levels from 1095 decoded RTP packets received by C from B 1097 Remote IP side signal/noise metrics relate to signal/noise levels 1098 from decoded RTP packets received by B from C, and reported by B to C 1099 through RTCP XR or RTCP HR VoIP Metrics blocks 1101 Local Trunk side signal/noise metrics relate to signal/noise levels 1102 from the PCM signal received by C from D 1103 Local Echo level relates to the proportion of the signal passing from 1104 B to C to D that is reflected back to C at some point between C and D 1105 or on the far side of D. This would typically be electrical echo or 1106 acoustic echo. 1108 Remote Echo level relates to the proportion of the signal passing 1109 from D to C to B that is reflected back to B at some point between B 1110 and the user. This echo level is typically measured at B and 1111 reported to C via RTCP XR or RTCP HR VoIP Metrics blocks. 1113 4. RTCP HR Configuration Block 1115 This block type provides a flexible means to describe the algorithms 1116 used for call quality calculation and other data. This block need 1117 only be exchanged occasionally, for example sent once at the start of 1118 a call. 1120 Header sub-block 1121 0 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | BT=N | Map | block length | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | SSRC of source | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 Correlation Tag sub-block 1130 0 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Tag Type | Tag length | Correlation Tag... | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | ... Correlation Tag | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 Algorithm sub-block 1139 0 1 2 3 1140 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 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Alg type | Descriptor len| Algorithm descriptor... | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | ... Algorithm descriptor | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 4.1. Header 1149 Implementations MUST send the Header block within each RTCP HR 1150 Configuration report. 1152 4.1.1. Block type 1154 One RTCP HR Configuration block is defined 1156 mmm+3 = RTCP HR Configuration Block 1158 The time interval associated with these report blocks is left to the 1159 implementation. Spacing of RTCP reports should be in accordance with 1160 RFC3550 however the specific timing of RTCP HR reports may be 1161 determined in response to an internally derived alert such as a 1162 threshold crossing. 1164 4.1.2. Map field 1166 A Map field indicates the optional sub-blocks present in this report. 1167 A '1' indicates that the sub-block is present, and a '0' that the 1168 block is absent. If present, the sub-blocks must be in the sequence 1169 defined in this document. The bits have the following definitions: 1171 0 Correlation Tag 1172 1 Algorithm Descriptor 1 1173 2 Algorithm Descriptor 2 1174 3 Algorithm Descriptor 3 1175 4 Algorithm Descriptor 4 1176 5-7 Reserved, set to '0' 1178 4.1.3. Block Length 1180 The block length indicates the length of this report in 32 bit words 1181 and includes the header and any extension octets. 1183 4.1.4. SSRC 1185 The SSRC of the stream to which this report relates. 1187 4.2. Correlation Tag 1189 The Correlation Tag sub-block MAY be present and if present MUST be 1190 indicated in the map field. This tag facilitates the correlation of 1191 the high resolution VoIP metrics report blocks with other call- 1192 related data, session-related data or endpoint data. 1194 An example use case is for an endpoint to convey its version of a 1195 call identifier or a global call identifier via this tag. A flow 1196 measurement tool (sniffer) that is not call-aware can then forward 1197 the RTCP-HR reports along with this correlation tag to network 1198 management. Network management can then use this tag to correlate 1199 this report with other diagnostic information such as call detail 1200 records. 1202 The Tag Type indicates the use of the correlation tag. The following 1203 values are defined: 1205 0: IMS Charging Identity (ICID) subfield of the P-Charging-Vector 1206 header specified in [RFC3455]. 1208 1: Globally unique ID as specified in ITU-T H.225.0 (Table 20/ 1209 H.225.0) [H.225.0]. 1211 2: Conference Identifier, per ITU-T H.225.0 (Table 20/H.225.0 1212 [H.225.0]). 1214 3: SIP Call-ID as defined in [RFC3261]. 1216 4: PacketCable Billing Call ID (BCID) [PKTMMS]. 1218 5: Text string using the US-ASCII character set [ASCII]. 1220 6: Octet string. 1222 7-255: Future growth. 1224 Although the intent of this RFC is to list all currently known values 1225 of usable correlation tags, it is possible that new values may be 1226 defined in the future. An IANA registry of correlation tags is 1227 recommended. 1229 The tag length indicates the overall length of the sub-block in 32 1230 bit words and includes the tag type and length fields. 1232 4.3. Algorithm descriptor 1234 The Algorithm Type sub-block MAY be present and if present MUST be 1235 indicated in the map field 1237 The Algorithm Type is a bit field which indicates which algorithm is 1238 being described. The bits are defined as:- 1240 Bit 0: MOS-LQ Algorithm 1241 Bit 1: MOS-CQ Algorithm 1242 Bit 2: R-LQ Algorithm 1243 Bit 3: R-CQ Algorithm 1244 Bit 4-7: Reserved and set to '0' 1246 The descriptor length gives the overall length of the descriptor in 1247 32 bit words and includes the algorithm descriptor and length fields. 1249 The algorithm descriptor is a text field that contains the 1250 description or name of the algorithm. If the algorithm name is 1251 shorter than the length of the field then the trailing octets must be 1252 set to 0x00. 1254 For example, an implementation may report: 1256 Algorithm descriptor = 0xF0 - R and MOS algorithms 1257 Descriptor length = 3 - 3 words 1258 Descriptor = "P.564" 0x00 - description 1260 Call quality estimation algorithms may be defined for listening or 1261 conversational quality MOS or R factor. 1263 5. SDP Signalling 1265 This section defines Session Description Protocol (SDP) [RFC4566] 1266 signalling for RTCP HR that can be employed by applications that 1267 utilize SDP. The approach follows the design pattern established for 1268 RTCP XR in [RFC3611], with modifications arising from the use in RTCP 1269 HR of multiple sub-blocks of a single RTCP XR block, rather than the 1270 multiple top-level RTCP XR blocks as used in RTCP XR. This SDP 1271 signalling is defined to be used either by applications that 1272 implement the SDP Offer/Answer model [RFC3264] or by applications 1273 that use SDP to describe media and transport configurations in 1274 connection with such protocols as the Session Announcement Protocol 1275 (SAP) [RFC2974] or the Real Time Streaming Protocol (RTSP) [RFC2326]. 1276 There exist other potential signalling methods that are not defined 1277 here. RTCP HR blocks MAY be used without prior signalling. This is 1278 consistent with the rules governing other RTCP packet types, as 1279 described in [RFC3550]. An example in which signalling would not be 1280 used is an application that always requires the use of RTCP HR. 1281 However, for applications that are configured at session initiation, 1282 the use of some type of signalling is recommended. 1284 Note that, although the use of SDP signalling for RTCP HR may be 1285 optional, if used, it MUST be used as defined here. If SDP 1286 signalling is used in an environment where RTCP HR is only 1287 implemented by some fraction of the participants, the ones not 1288 implementing RTCP HR will ignore the SDP attribute. 1290 5.1. The SDP Attributes 1292 This section defines two new SDP attributes "rtcp-hr-span" and "rtcp- 1293 hr-subblk" that can be used to signal participants in a media session 1294 how they should use RTCP HR. 1296 The two SDP attributes are defined below in Augmented Backus-Naur 1297 Form (ABNF) [RFC5234]. They are both session and media level 1298 attributes. When specified at session level, they apply to all media 1299 level blocks in the session. Any media level specification MUST 1300 replace a session level specification, if one is present, for that 1301 media block. 1303 rtcp-hr-span-attrib = "a=rtcp-hr-span:" 1304 [hr-span-format *(SP hr-span-format)] CRLF 1305 hr-span-format = "cumulative" 1306 / "interval" 1307 / "alert" 1309 rtcp-hr-subblk-attrib = "a=rtcp-hr-subblk:" hr-subblk-formats 1310 hr-subblk-formats = [hr-subblk-format *(SP hr-subblk-format)] CRLF 1311 hr-subblk-format = loss 1312 / burst-gap 1313 / playout 1314 / conceal 1315 / delay 1316 / quality 1318 loss = "loss" 1319 burst-gap = "burst-gap" 1320 playout = "playout" 1321 conceal = "conceal" ["=" thresh] 1322 delay = "delay" [ "," pdvtype ] [ "," nspec "," pspec ] 1323 quality = "quality" 1325 thresh = 1*DIGIT ; threshold for SCS (ms) 1326 pdvtype = "pdv=" 0 ; ppdv RFC 3550 1327 / 1 ; mapdv ITU-T G.1020 1328 / 2 ; ipdv ITU-T Y.1540 1329 nspec = "nthr=" fixpoint ; negative threshold PDV (ms) 1330 / "npc=" fixpoint ; negative PDV percentile 1331 pspec = "pthr=" fixpoint ; positive threshold PDV (ms) 1332 / "ppc=" fixpoint ; positive PDV percentile 1334 fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal 1335 DIGIT = %x30-39 1336 CRLF = %d13.10 1338 The Header sub-block is mandatory in an RTCP HR report block, and 1339 hence does not appear as a possible value for "hr-subblk-format". 1340 The Basic Loss/Delay sub-block is also mandatory. However if SDP 1341 requests that an RTCP HR report block should be sent, then the value 1342 "loss" MUST be present in the attribute list of hr-subblk-format, in 1343 order to avoid potential ambiguity in the meaning of an empty list. 1344 The Delay and Packet Delay Variation (PDV) Metrics sub-block is also 1345 mandatory, but it requires parameters to control its behaviour. If 1346 SDP requests that an RTCP HR report block should be sent, the value 1347 "delay" MUST appear in the list of hr-subblk-format, together with 1348 its parameters. 1350 The "rtcp-hr-subblk" attributes parameter list MAY be empty. This is 1351 useful in cases in which an application needs to signal that it 1352 understands the SDP signalling but does not wish to avail itself of 1353 RTCP HR functionality. For example, an application in a SIP 1354 controlled session could signal that it wishes to stop using all HR 1355 subblocks by removing all applicable SDP parameters in a re-INVITE 1356 message that it sends. If HR subblocks are not to be used at all 1357 from the beginning of a session, it is RECOMMENDED that none of the 1358 "rtcp-hr" attributes be supplied. 1360 When the "rtcp-hr-subblk" attribute is present but not populated with 1361 any parameters, even those for mandatory sub-blocks ("loss", 1362 "delay"), participants SHOULD NOT send any RTCP HR information. This 1363 means that inclusion of an "rtcp-hr-subblk" attribute without any 1364 parameters tells a participant that it SHOULD NOT send any optional 1365 RTCP HR subblocks at all. The purpose is to conserve bandwidth. 1366 There are, however, contexts in which it makes sense to send an RTCP 1367 HR block in the absence of a parameter signalling its use. For 1368 instance, an application might be designed so as to send certain 1369 report blocks without negotiation, while using SDP signalling to 1370 negotiate the use of other blocks. 1372 When the "rtcp-hr-subblk" attribute is present and populated with at 1373 least the parameters for mandatory sub-blocks ("loss" and "delay") 1374 participants SHOULD send mandatory sub- blocks but SHOULD NOT send 1375 optional RTCP HR subblocks other than the ones indicated by the 1376 parameters. 1378 5.2. Usage in Offer/Answer 1380 In the Offer/Answer context [RFC3264], the interpretation of SDP 1381 signalling for RTCP HR packets depends upon the direction attribute 1382 that is signaled: "recvonly", "sendrecv", or "sendonly" [RFC4566]. 1383 If no direction attribute is supplied, then "sendrecv" is assumed. 1384 This section applies only to unicast media streams, except where 1385 noted. 1387 For "sendonly" and "sendrecv" media stream offers, the answerer 1388 SHOULD send the corresponding RTCP HR subblocks. For "sendrecv" 1389 offers, the answerer MAY include the attributes in its response, and 1390 specify any parameters in order to request that the offerer send the 1391 corresponding XR blocks. The offerer SHOULD send these blocks. For 1392 "recvonly" media stream offers, the offerer's use of the "rtcp-hr-" 1393 attributes indicates that the offerer is capable of sending the 1394 corresponding RTCP HR sub-blocks. If the answerer responds with the 1395 set of two "rtcp-hr-" attributes, the offerer SHOULD send RTCP HR 1396 subblocks. For multicast media streams, the inclusion of "rtcp-hr-" 1397 attributes means that every media recipient SHOULD send the 1398 corresponding HR sub-blocks. If a participant receives an SDP offer 1399 and understands the "rtcp-hr-" attributes but does not wish to 1400 implement RTCP HR functionality offered, its answer SHOULD include 1401 "rtcp-hr-" attributes without parameters. By doing so, the party 1402 declares that, at a minimum, it is capable of understanding the 1403 signalling. 1405 5.3. Usage Outside of Offer/Answer 1407 SDP can be employed outside of the Offer/Answer context, for instance 1408 for multimedia sessions that are announced through the Session 1409 Announcement Protocol (SAP) [RFC2974], or streamed through the Real 1410 Time Streaming Protocol (RTSP) [RFC2326]. The signalling model is 1411 simpler, as the sender does not negotiate parameters, but the 1412 functionality expected from specifying the "rtcp-hr-" attributes is 1413 the same as in Offer/Answer. 1415 When a parameter is specified for the "rtcp-hr-subblk" attribute 1416 associated with a media stream, the receiver of that stream SHOULD 1417 send the corresponding RTCP HR block. 1419 6. Practical Applications 1421 6.1. Overview 1423 The objective of this section is to identify a number of cases in 1424 which there could potentially be some ambiguity in the application of 1425 the report blocks defined above or some exceptions to the defined 1426 operation of the metrics. 1428 6.2. Supplementary Services: Call Hold and Transfer 1430 6.2.1. General 1432 Supplementary services are under control of call/session control 1433 protocols like SIP. Such signalling protocols are acting also as 1434 "non-RTP means" (definition see clause 3 of [RFC3550]) in such 1435 service scenarios. 1437 The "northbound" served user instance for RTCP HR data is typically 1438 "co-located" to the served user instance of the call/session control 1439 protocol controlling the supplementary service. This allows to 1440 correlate in principle supplementary service control events with RTCP 1441 HR measurements in such network elements (like a SIP UA, SIP proxy, 1442 application server, etc.). 1444 Thus, the correlation between RTP/RTCP session control and 1445 supplementary service control allows basically the minimization of 1446 potential ambiguity. 1448 Below sub-clause providing some additional notes dependent on 1449 specific supplementary services. 1451 6.2.2. Supplementary Service: Call Transfer 1453 A successful call transfer means that an initial call between A and B 1454 is transferred to a call between C and B. This means that the RTP end 1455 system A is "replaced" by RTP end system C, accompanied by all 1456 correspondent changes in a RTP/RTCP endpoint (e.g., SSRC for A 1457 "replaced" by SSRC for B). 1459 In the scope of RTCP HR, it is therefore recommended to consider the 1460 two call phases (1st phase: call A-B, 2nd phase: call C-B) as 1461 separate measurement phases. Separate measurement phases could be 1462 e.g. based on interval metrics and the derivation of call phase- 1463 individual cumulative metrics by the "northbound" served user 1464 instance of RTCP HR, or by "resetting" the cumulative metrics in each 1465 call phase. 1467 6.2.3. Supplementary Service: Call Hold 1469 Call hold enables the served (holding) user A to put user B (with 1470 whom user A has an active call) into a hold condition (held user) and 1471 subsequently to retrieve that user again. During this hold 1472 condition, user B may be provided with media on hold (MoH). The 1473 served (holding) user A may perform other actions while user B is 1474 being held, e.g. consulting with another user C. 1476 In the scope of RTCP HR, it is recommended to consider the different 1477 call phases firstly as separate measurement phases (see also 8.2.2). 1479 6.3. Bitrate efficiency improvements: VAD/Silence Suppression based on 1480 Voice Activity Detection (VAD) Elimination 1482 A VoIP call is either enabled or disabled for silence suppression. 1483 This is typically a call-individual configuration parameter, 1484 negotiated during call establishment phase, and not changed anymore 1485 during the remaining call phase. 1487 An enabled silence suppression mode is basically affecting almost all 1488 high resolution VoIP metrics. 1490 The "northbound" served user instance of RTCP HR may require access 1491 to the information, whether silence suppression was enabled or 1492 disabled for that call, in order to indicate that mode of operation 1493 in the VoIP measurement data. 1495 6.4. Endpoint configuration changes mid-call 1497 An endpoint relates to an RTP end system, which can be either a) 1498 located in VoIP user/terminal equipment (e.g. SIP UA), or b) located 1499 in VoIP gateway equipment (e.g. PSTN-to-RTP H.248 media gateway), or 1500 c) located in VoIP media server equipment. 1502 6.4.1. Changes due to mid-call transitions between different voice 1503 codec types 1505 Voice codec type changes are reflected in RTP payload type changes, 1506 which are visible in the Call Quality metrics sub-block 1507 (Section 3.8.4). 1509 6.4.2. Changes due to mid-call transitions from VoIP to RTP-based 1510 VBDoIP 1512 There might be mid-call transitions from VoIP to dedicated modes of 1513 operation for voiceband data services support in case that at least 1514 one RTP end system is located in type (b) equipment. Mode 1515 transitions should be again reflected in RTP payload type changes in 1516 case of RTP-based VBD transport (e.g. like ITU-T Rec. V.152 [V.152] 1517 for VBDoIP). 1519 Details are for further study. 1521 6.4.3. Changes due to mid-call transitions from VoIP to non-RTP -based 1522 VBDoIP 1524 UDPTL/UDP based realtime facsimile according ITU-T Rec. T.38 is an 1525 example for RTP-less transport of facsimile/modem signals. Any mid- 1526 call transition to T.38 would inherently terminated the RTP/RTCP 1527 session, thus the measurement phase. 1529 Details are for further study. 1531 6.5. SSRC changes mid-call 1533 An SSRC change may be e.g. the consequence of a mid-call transport 1534 address change. 1536 Details are for further study. 1538 7. IANA Considerations 1540 This document defines a series of new RTCP Extended Report (XR) block 1541 types within the existing Internet Assigned Numbers Authority (IANA) 1542 registry of RTP RTCP XR block types. In addition, this document 1543 defines the need for an IANA registry of correlation tag types 1544 (Section 4.3) 1546 8. Security Considerations 1548 RTCP reports can contain sensitive information since they can provide 1549 information about the nature and duration of a session established 1550 between two endpoints. As a result, any third party wishing to 1551 obtain this information should be properly authenticated and the 1552 information transferred securely. 1554 9. Contributors 1556 The authors gratefully acknowledge the comments and contributions 1557 made by Jim Frauenthal, Mike Ramalho, Paul Jones, Claus Dahm, Bob 1558 Biskner, Mohamed Mostafa, Tom Hock, Albert Higashi, Shane Holthaus, 1559 Amit Arora, Bruce Adams, Albrecht Schwarz, Keith Lantz, Randy Ethier, 1560 Philip Arden, Ravi Raviraj and Hideaki Yamada. 1562 10. Informative References 1564 [ASCII] ANSI, "Coded Character Set--7-Bit American Standard Code 1565 for Information Interchange, ANSI X3.4-1986", 1986. 1567 [G.1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter 1568 definitions for quality of speech and other voiceband 1569 applications utilizing IP networks", November 2003. 1571 [G.1020AnnexA] 1572 ITU-T, "Amendment 1 to ITU-T Rec G.1020 Annex A, VoIP 1573 Gateway specific reference points and performance 1574 parameters", May 2004. 1576 [H.225.0] ITU-T, "ITU-T Rec. H.225.0, Call signalling protocols and 1577 media stream packetization for packet-based multimedia 1578 communication systems", July 2003. 1580 [PKTMMS] PacketCable(TM), "PacketCable(TM) Multimedia 1581 Specification, PKT-SP-MM-I02-040930", September 2004. 1583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1584 Requirement Levels", RFC 2119, BCP 14, March 1997. 1586 [RFC2198] Perkins, C., "RTP Payload for Redundant Audio Data", 1587 RFC 2198, September 1997. 1589 [RFC2326] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", 1590 RFC 2326, April 1998. 1592 [RFC2974] Handley, M., "Session Announcement Protocol", RFC 2974, 1593 October 2000. 1595 [RFC3261] Rosenberg, J., "SIP: Session Initiation Protocol", 1596 RFC 3261, June 2002. 1598 [RFC3264] Rosenberg, J., "An Offer/Answer Model with the Session 1599 Description Protocol (SDP)", RFC 3264, June 2002. 1601 [RFC3455] Garcia-Martin, M., "Private Header (P-Header) Extensions 1602 to the Session Initiation Protocol (SIP) for the 3rd- 1603 Generation Partnership Project (3GPP)", RFC 3455, 1604 January 2003. 1606 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 1607 Applications", RFC 3550, July 2003. 1609 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 1610 XR)", RFC 3611, November 2003. 1612 [RFC4566] Handley, M., "SDP: Session Description Protocol", 1613 RFC 4566, July 2006. 1615 [RFC5234] Crocker, D., "Augmented BNF for Syntax Specifications: 1616 ABNF", RFC 5234, STD 68, January 2008. 1618 [V.152] ITU-T, "ITU-T Rec. V.152, Procedures for supporting voice- 1619 band data over IP networks", January 2005. 1621 [Y.1540] ITU-T, "ITU-T Rec. Y.1540, Internet protocol data 1622 communication service -- IP packet transfer and 1623 availability performance parameters", December 2002. 1625 Authors' Addresses 1627 Alan Clark 1628 Telchemy Incorporated 1629 2905 Premiere Parkway, Suite 280 1630 Adastral Park 1631 Martlesham Heath 1632 Duluth, GA 30097 1634 Email: alan@telchemy.com 1636 Geoff Hunt 1637 BT 1638 Orion 1 PP9 1639 Adastral Park 1640 Martlesham Heath 1641 Ipswich, Suffolk IP5 3RE 1642 United Kingdom 1644 Phone: +44 1473 608325 1645 Email: geoff.hunt@bt.com 1647 Amy Pendleton 1648 Nortel 1649 2380 Performance Drive 1650 Richardson, TX 75081 1652 Email: aspen@nortel.com 1654 Rajesh Kumar 1655 Cisco Systems 1656 170 West Tasman Drive 1657 San Jose, CA 95134 1659 Email: rkumar@cisco.com 1661 Kevin Connor 1662 Cisco Systems 1663 5590 Whitehorn Way 1664 Blaine, WA 98230 1666 Email: kconnor@cisco.com 1668 Full Copyright Statement 1670 Copyright (C) The IETF Trust (2008). 1672 This document is subject to the rights, licenses and restrictions 1673 contained in BCP 78, and except as set forth therein, the authors 1674 retain all their rights. 1676 This document and the information contained herein are provided on an 1677 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1678 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1679 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1680 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1681 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1682 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1684 Intellectual Property 1686 The IETF takes no position regarding the validity or scope of any 1687 Intellectual Property Rights or other rights that might be claimed to 1688 pertain to the implementation or use of the technology described in 1689 this document or the extent to which any license under such rights 1690 might or might not be available; nor does it represent that it has 1691 made any independent effort to identify any such rights. Information 1692 on the procedures with respect to rights in RFC documents can be 1693 found in BCP 78 and BCP 79. 1695 Copies of IPR disclosures made to the IETF Secretariat and any 1696 assurances of licenses to be made available, or the result of an 1697 attempt made to obtain a general license or permission for the use of 1698 such proprietary rights by implementers or users of this 1699 specification can be obtained from the IETF on-line IPR repository at 1700 http://www.ietf.org/ipr. 1702 The IETF invites any interested party to bring to its attention any 1703 copyrights, patents or patent applications, or other proprietary 1704 rights that may cover technology that may be required to implement 1705 this standard. Please address the information to the IETF at 1706 ietf-ipr@ietf.org. 1708 Acknowledgment 1710 Funding for the RFC Editor function is provided by the IETF 1711 Administrative Support Activity (IASA).