idnits 2.17.1 draft-ietf-avt-rtcp-report-extns-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. == 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 'MUST not' in this paragraph: A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. == 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 'MUST not' in this paragraph: A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. == 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 'MUST not' in this paragraph: A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. == 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 'MUST not' in this paragraph: A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. == 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 'MUST not' in this paragraph: Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or discard occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as being part of a burst or gap in later reports. ETSI TS 101 329-5 [3] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero and MUST be provided and MUST remain constant across VoIP Metrics report blocks for the duration of the RTP session. -- 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 (19 May 2003) is 7641 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Section 6' on line 270 -- Looks like a reference, but probably isn't: 'Appendix B' on line 1999 == Unused Reference: '5' is defined on line 2392, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2028 (ref. '5') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1889 (ref. '9') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-09) exists of draft-ietf-avt-srtp-05 -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '17') (Obsoleted by RFC 7826) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 19 May 2003 3 Internet Engineering Task Force Expires: 19 November 2003 4 Audio/Video Transport Working Group 6 Timur Friedman, Paris 6 7 Ramon Caceres, ShieldIP 8 Alan Clark, Telchemy 9 Editors 11 RTP Control Protocol Extended Reports (RTCP XR) 13 draft-ietf-avt-rtcp-report-extns-06.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 10 of RFC2026. 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/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document defines the Extended Report (XR) packet type for the 43 RTP Control Protocol (RTCP), and defines how the use of XR packets 44 can be signaled by an application if it employs the Session 45 Description Protocol (SDP). XR packets are composed of report 46 blocks, and seven block types are defined here. The purpose of the 47 extended reporting format is to convey information that supplements 48 the six statistics that are contained in the report blocks used by 49 RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some 50 applications, such as multicast inference of network characteristics 51 (MINC) or voice over IP (VoIP) monitoring, require other and more 52 detailed statistics. In addition to the block types defined here, 53 additional block types may be defined in the future by adhering to 54 the framework that this document provides. 56 Table of Contents 58 1. Introduction .............................................. 3 59 1.1 Applicability ............................................. 4 60 1.2 Terminology ............................................... 7 61 2. XR Packet Format .......................................... 7 62 3. Extended Report Block Framework ........................... 8 63 4. Extended Report Blocks .................................... 9 64 4.1 Loss RLE Report Block ..................................... 9 65 4.1.1 Run Length Chunk .......................................... 15 66 4.1.2 Bit Vector Chunk .......................................... 15 67 4.1.3 Terminating Null Chunk .................................... 15 68 4.2 Duplicate RLE Report Block ................................ 16 69 4.3 Packet Receipt Times Report Block ......................... 17 70 4.4 Receiver Reference Time Report Block ...................... 20 71 4.5 DLRR Report Block ......................................... 21 72 4.6 Statistics Summary Report Block ........................... 22 73 4.7 VoIP Metrics Report Block ................................. 25 74 4.7.1 Packet Loss and Discard Metrics ........................... 26 75 4.7.2 Burst Metrics ............................................. 27 76 4.7.3 Delay Metrics ............................................. 30 77 4.7.4 Signal Related Metrics .................................... 30 78 4.7.5 Call Quality or Transmission Quality Metrics .............. 33 79 4.7.6 Configuration Parameters .................................. 34 80 4.7.7 Jitter Buffer Parameters .................................. 35 81 5. SDP Signaling ............................................. 36 82 5.1 The SDP Attribute ......................................... 37 83 5.2 Usage in Offer/Answer ..................................... 40 84 5.3 Usage Outside of Offer/Answer ............................. 41 85 6. IANA Considerations ....................................... 42 86 6.1 XR Packet Type ............................................ 42 87 6.2 RTCP XR Block Type Registry ............................... 42 88 6.3 The "rtcp-xr" SDP Attribute ............................... 43 89 7. Security Considerations ................................... 44 90 A. Algorithms ................................................ 45 91 A.1 Sequence Number Interpretation ............................ 45 92 A.2 Example Burst Packet Loss Calculation ..................... 46 93 Intellectual Property ..................................... 48 94 Full Copyright Statement .................................. 49 95 Acknowledgments ........................................... 49 96 Contributors .............................................. 50 97 Authors' Addresses ........................................ 50 98 References ................................................ 52 99 Normative References ...................................... 52 100 Non-Normative References .................................. 53 102 1. Introduction 104 This document defines the Extended Report (XR) packet type for the 105 RTP Control Protocol (RTCP) [9], and defines how the use of XR 106 packets can be signaled by an application if it employs the Session 107 Description Protocol (SDP) [4]. XR packets convey information beyond 108 that already contained in the reception report blocks of RTCP's 109 sender report (SR) or Receiver Report (RR) packets. The information 110 is of use across RTP profiles, and so is not appropriately carried in 111 SR or RR profile-specific extensions. Information used for network 112 management falls into this category, for instance. 114 The definition is broken out over the three sections that follow the 115 Introduction. Section 2 defines the XR packet as consisting of an 116 eight octet header followed by a series of components called report 117 blocks. Section 3 defines the common format, or framework, 118 consisting of a type and a length field, required for all report 119 blocks. Section 4 defines several specific report block types. 120 Other block types can be defined in future documents as the need 121 arises. 123 The report block types defined in this document fall into three 124 categories. The first category consists of packet-by-packet reports 125 on received or lost RTP packets. Reports in the second category 126 convey reference time information between RTP participants. In the 127 third category, reports convey metrics relating to packet receipts, 128 that are summary in nature but that are more detailed, or of a 129 different type, than that conveyed in existing RTCP packets. 131 All told, seven report block formats are defined by this document. 132 Of these, three are packet-by-packet block types: 134 - Loss RLE Report Block (Section 4.1): Run length encoding of reports 135 concerning the losses and receipts of RTP packets. 137 - Duplicate RLE Report Block (Section 4.2): Run length encoding of 138 reports concerning duplicates of received RTP packets. 140 - Packet Receipt Times Report Block (Section 4.3): A list of 141 reception timestamps of RTP packets. 143 There are two reference time related block types: 145 - Receiver Reference Time Report Block (Section 4.4): Receiver-end 146 wallclock timestamps. Together with the DLRR Report Block mentioned 147 next, these allow non-senders to calculate round-trip times. 149 - DLRR Report Block (Section 4.5): The delay since the last Receiver 150 Reference Time Report Block was received. An RTP data sender that 151 receives a Receiver Reference Time Report Block can respond with a 152 DLRR Report Block, in much the same way as, in the mechanism already 153 defined for RTCP [9, Section 6.3.1], an RTP data receiver that 154 receives a sender's NTP timestamp can respond by filling in the DLSR 155 field of an RTCP reception report block. 157 Finally, this document defines two summary metric block types: 159 - Statistics Summary Report Block (Section 4.6): Statistics on RTP 160 packet sequence numbers, losses, duplicates, jitter, and TTL or Hop 161 Limit values. 163 - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring 164 Voice over IP (VoIP) calls. 166 Before proceeding to the XR packet and report block definitions, this 167 document provides an applicability statement (Section 1.1) that 168 describes the contexts in which these report blocks can be used. It 169 also defines (Section 1.2) the normative use of key words, such as 170 MUST and SHOULD, as they are employed in this document. 172 Following the definitions of the various report blocks, this document 173 describes how applications that employ SDP can signal their use 174 (Section 5). The document concludes with a discussion (Section 6) of 175 numbering considerations for the Internet Assigned Numbers Authority 176 (IANA), of security considerations (Section 7), and with appendices 177 that provide examples of how to implement algorithms discussed in the 178 text. 180 1.1 Applicability 182 The XR packets are useful across multiple applications, and for that 183 reason are not defined as profile-specific extensions to RTCP sender 184 or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of 185 use in all contexts. In particular, the VoIP metrics report block 186 (Section 4.7) is specific to voice applications, though it can be 187 employed over a wide variety of such applications. 189 The VoIP metrics report block can be applied to any one-to-one or 190 one-to-many voice application for which the use of RTP and RTCP is 191 specified. The use of conversational metrics (Section 4.7.5), 192 including the R factor (as described by the E Model defined in [3]) 193 and the mean opinion score for conversational quality (MOS-CQ), in 194 applications other than simple two party calls is not defined, and 195 hence these metrics should be identified as unavailable in multicast 196 conferencing applications. 198 The packet-by-packet report block types, Loss RLE (Section 4.1), 199 Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), 200 have been defined with network tomography applications, such as 201 multicast inference of network characteristics (MINC) [11], in mind. 202 MINC requires detailed packet receipt traces from multicast session 203 receivers in order to infer the gross structure of the multicast 204 distribution tree and the parameters, such as loss rates and delays, 205 that apply to paths between the branching points of that tree. 207 Any real time multicast multimedia application can use the packet-by- 208 packet report block types. Such an application could employ a MINC 209 inference subsystem that would provide it with multicast tree 210 topology information. One potential use of such a subsystem would be 211 for the identification of high loss regions in the multicast tree and 212 the identification of multicast session participants well situated to 213 provide retransmissions of lost packets. 215 Detailed packet-by-packet reports do not necessarily have to consume 216 disproportionate bandwidth with respect to other RTCP packets. An 217 application can cap the size of these blocks. A mechanism called 218 "thinning" is provided for these report blocks, and can be used to 219 ensure that they adhere to a size limit by restricting the number of 220 packets reported upon within any sequence number interval. The 221 rationale for, and use of this mechanism is described in [13]. 222 Furthermore, applications might not require report blocks from all 223 receivers in order to answer such important questions as where in the 224 multicast tree there are paths that exceed a defined loss rate 225 threshold. Intelligent decisions regarding which receivers send 226 these report blocks can further restrict the portion of RTCP 227 bandwidth that they consume. 229 The packet-by-packet report blocks can also be used by dedicated 230 network monitoring applications. For such an application, it might 231 be appropriate to allow more than 5% of RTP data bandwidth to be used 232 for RTCP packets, thus allowing proportionately larger and more 233 detailed report blocks. 235 Nothing in the packet-by-packet block types restricts their use to 236 multicast applications. In particular, they could be used for 237 network tomography similar to MINC, but using striped unicast 238 packets. In addition, if it were found useful, they could be used 239 for applications limited to two participants. 241 One use to which the packet-by-packet reports are not immediately 242 suited is for data packet acknowledgments as part of a packet 243 retransmission mechanism. The reason is that the packet accounting 244 technique suggested for these blocks differs from the packet 245 accounting normally employed by RTP. In order to favor measurement 246 applications, an effort is made to interpret as little as possible at 247 the data receiver, and leave the interpretation as much as possible 248 to participants that receive the report blocks. Thus, for example, a 249 packet with an anomalous SSRC ID or an anomalous sequence number 250 might be excluded by normal RTP accounting, but would be reported 251 upon for network monitoring purposes. 253 The Statistics Summary Report Block (Section 4.6) has also been 254 defined with network monitoring in mind. This block type can be used 255 equally well for reporting on unicast and multicast packet reception. 257 The reference time related block types were conceived for receiver- 258 based TCP-friendly multicast congestion control [18]. By allowing 259 data receivers to calculate their round trip times to senders, they 260 help the receivers estimate the downstream bandwidth they should 261 request. Note that if every receiver is to send Receiver Reference 262 Time Report Blocks (Section 4.4), a sender might potentially send a 263 number of DLRR Report Blocks (Section 4.5) equal to the number of 264 receivers whose RTCP packets have arrived at the sender within its 265 reporting interval. As the number of participants in a multicast 266 session increases, an application should use discretion regarding 267 which participants send these blocks, and how frequently. 269 XR packets supplement the existing RTCP packets, and may be stacked 270 with other RTCP packets to form compound RTCP packets [9, Section 6]. 271 The introduction of XR packets into a session in no way changes the 272 rules governing the calculation of the RTCP reporting interval [9, 273 Section 6.2]. As XR packets are RTCP packets, they count as such for 274 bandwidth calculations. As a result, the addition of extended 275 reporting information may tend to increase the average RTCP packet 276 size, and thus the average reporting interval. This increase may be 277 limited by limiting the size of XR packets. 279 The SDP signaling defined for XR packets in this document (Section 5) 280 was done so with three use scenarios in mind: a Real Time Streaming 281 Protocol (RTSP) controlled streaming application, a one-to-many 282 multicast multimedia application such as a course lecture with 283 enhanced feedback, and a Session Initiation Protocol (SIP) controlled 284 conversational session involving two parties. Applications that 285 employ SDP are free to use additional SDP signaling for cases not 286 covered here. In addition, applications are free to use signaling 287 mechanisms other than SDP. 289 1.2 Terminology 291 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 292 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 293 document are to be interpreted as described in RFC 2119 [1] and 294 indicate requirement levels for compliance with this specification. 296 2. XR Packet Format 298 An XR packet consists of a header of two 32-bit words, followed by a 299 number, possibly zero, of extended report blocks. This type of 300 packet is laid out in a manner consistent with other RTCP packets, as 301 concerns the essential version, packet type, and length information. 302 XR packets are thus backwards compatible with RTCP receiver 303 implementations that do not recognize them, but that ought to be able 304 to parse past them using the length information. A padding field and 305 an SSRC field are also provided in the same locations that they 306 appear in other RTCP packets, for simplicity. The format is as 307 follows: 309 0 1 2 3 310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |V=2|P|reserved | PT=XR=207 | length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | SSRC | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 : report blocks : 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 version (V): 2 bits 320 Identifies the version of RTP. This specification applies to 321 RTP version two. 323 padding (P): 1 bit 324 If the padding bit is set, this XR packet contains some 325 additional padding octets at the end. The semantics of this 326 field are identical to the semantics of the padding field in the 327 SR packet, as defined by the RTP specification. 329 reserved: 5 bits 330 This field is reserved for future definition. In the absence of 331 such definition, the bits in this field MUST be set to zero and 332 MUST be ignored by the receiver. 334 packet type (PT): 8 bits 335 Contains the constant 207 to identify this as an RTCP XR packet. 336 This value is registered with the Internet Assigned Numbers 337 Authority (IANA), as described in Section 5.1. 339 length: 16 bits 340 As described for the RTCP Sender Report (SR) packet (see Section 341 6.3.1 of the RTP specification [9]). Briefly, the length of 342 this XR packet in 32-bit words minus one, including the header 343 and any padding. 345 SSRC: 32 bits 346 The synchronization source identifier for the originator of this 347 XR packet. 349 report blocks: variable length. 350 Zero or more extended report blocks. In keeping with the 351 extended report block framework defined below, each block MUST 352 consist of one or more 32-bit words. 354 3. Extended Report Block Framework 356 Extended report blocks are stacked, one after the other, at the end 357 of an XR packet. An individual block's length is a multiple of 4 358 octets. The XR header's length field describes the total length of 359 the packet, including these extended report blocks. 361 Each block has block type and length fields that facilitate parsing. 362 A receiving application can demultiplex the blocks based upon their 363 type, and can use the length information to locate each successive 364 block, even in the presence of block types it does not recognize. 366 An extended report block has the following format: 368 0 1 2 3 369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | BT | type-specific | block length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 : type-specific block contents : 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 block type (BT): 8 bits 377 Identifies the block format. Seven block types are defined in 378 Section 4. Additional block types may be defined in future 379 specifications. This field's name space is managed by the 380 Internet Assigned Numbers Authority (IANA), as described in 381 Section 5.2. 383 type-specific: 8 bits 384 The use of these bits is determined by the block type 385 definition. 387 block length: 16 bits 388 The length of this report block including the header, in 32-bit 389 words minus one. If the block type definition permits, zero is 390 an acceptable value, signifying a block that consists of only 391 the BT, type-specific, and block length fields, with a null 392 type-specific block contents field. 394 type-specific block contents: variable length 395 The use of this field is defined by the particular block type, 396 subject to the constraint that it MUST be a multiple of 32 bits 397 long. If the block type definition permits, It MAY be zero bits 398 long. 400 4. Extended Report Blocks 402 This section defines seven extended report blocks: block types for 403 reporting upon received packet losses and duplicates, packet 404 reception times, receiver reference time information, receiver inter- 405 report delays, detailed reception statistics, and voice over IP 406 (VoIP) metrics. An implementation SHOULD ignore incoming blocks with 407 types either not relevant or unknown to it. Additional block types 408 MUST be registered with the Internet Assigned Numbers Authority 409 (IANA) [16], as described in Section 5.2. 411 4.1 Loss RLE Report Block 413 This block type permits detailed reporting upon individual packet 414 receipt and loss events. Such reports can be used, for example, for 415 multicast inference of network characteristics (MINC) [11]. With 416 MINC, one can discover the topology of the multicast tree used for 417 distributing a source's RTP packets, and of the loss rates along 418 links within that tree. Or they could be used to provide raw data to 419 a network management application. 421 Since a Boolean trace of lost and received RTP packets is potentially 422 lengthy, this block type permits the trace to be compressed through 423 run length encoding. To further reduce block size, loss event 424 reports can be systematically dropped from the trace in a mechanism 425 called thinning that is described below and that is studied in [13]. 427 A participant that generates a Loss RLE Report Block should favor 428 accuracy in reporting on observed events over interpretation of those 429 events whenever possible. Interpretation should be left to those who 430 observe the report blocks. Following this approach implies that 431 accounting for Loss RLE Report Blocks will differ from the accounting 432 for the generation of the SR and RR packets described in the RTP 433 specification [9] in the following two areas: per-sender accounting 434 and per-packet accounting. 436 In its per-sender accounting, an RTP session participant SHOULD NOT 437 make the receipt of a threshold minimum number of RTP packets a 438 condition for reporting upon the sender of those packets. This 439 accounting technique differs from the technique described in Section 440 6.2.1 and Appendix A.1 of the RTP specification that allows a 441 threshold to determine whether a sender is considered valid. 443 In its per-packet accounting, an RTP session participant SHOULD treat 444 all sequence numbers as valid. This accounting technique differs 445 from the technique described in Appendix A.1 of the RTP specification 446 that suggests ruling a sequence number valid or invalid on the basis 447 of its contiguity with the sequence numbers of previously received 448 packets. 450 Sender validity and sequence number validity are interpretations of 451 the raw data. Such interpretations are justified in the interest, 452 for example, of excluding the stray old packet from an unrelated 453 session from having an effect upon the calculation of the RTCP 454 transmission interval. The presence of stray packets might, on the 455 other hand, be of interest to a network monitoring application. 457 One accounting interpretation that is still necessary is for a 458 participant to decide whether the 16 bit sequence number has rolled 459 over. Under ordinary circumstances this is not a difficult task. 460 For example, if packet number 65,535 (the highest possible sequence 461 number) is followed shortly by packet number 0, it is reasonable to 462 assume that there has been a rollover. However it is possible that 463 the packet is an earlier one (from 65,535 packets earlier). It is 464 also possible that the sequence numbers have rolled over multiple 465 times, either forward or backward. The interpretation becomes more 466 difficult when there are large gaps between the sequence numbers, 467 even accounting for rollover, and when there are long intervals 468 between received packets. 470 The per-packet accounting technique mandated here is for a 471 participant to keep track of the sequence number of the packet most 472 recently received from a sender. For the next packet that arrives 473 from that sender, the sequence number MUST be judged to fall no more 474 than 32,768 packets ahead or behind the most recent one, whichever 475 choice places it closer. In the event that both choices are equally 476 distant (only possible when the distance is 32,768), the choice MUST 477 be the one that does not require a rollover. Appendix A.1 presents 478 an algorithm that implements this technique. 480 Each block reports on a single RTP data packet source, identified by 481 its SSRC. The receiver that is supplying the report is identified in 482 the header of the RTCP packet. 484 Choice of beginning and ending RTP packet sequence numbers for the 485 trace is left to the application. These values are reported in the 486 block. The last sequence number in the trace MAY differ from the 487 sequence number reported on in any accompanying SR or RR report. 489 Note that because of sequence number wraparound the ending sequence 490 number MAY be less than the beginning sequence number. A Loss RLE 491 Report Block MUST NOT be used to report upon a range of 65,534 or 492 greater in the sequence number space, as there is no means to 493 identify multiple wraparounds. 495 The trace described by a Loss RLE report consists of a sequence of 496 Boolean values, one for each sequence number of the trace. A value 497 of one represents a packet receipt, meaning that one or more packets 498 having that sequence number have been received since the most recent 499 wraparound of sequence numbers (or since the beginning of the RTP 500 session if no wraparound has been judged to have occurred). A value 501 of zero represents a packet loss, meaning that there has been no 502 packet receipt for that sequence number as of the time of the report. 503 If a packet with a given sequence number is received after a report 504 of a loss for that sequence number, a later Loss RLE report MAY 505 report a packet receipt for that sequence number. 507 The encoding itself consists of a series of 16 bit units called 508 chunks that describe sequences of packet receipts or losses in the 509 trace. Each chunk either specifies a run length or a bit vector, or 510 is a null chunk. A run length describes between 1 and 16,383 events 511 that are all the same (either all receipts or all losses). A bit 512 vector describes 15 events that may be mixed receipts and losses. A 513 null chunk describes no events, and is used to round out the block to 514 a 32 bit word boundary. 516 The mapping from a sequence of lost and received packets into a 517 sequence of chunks is not necessarily unique. For example, the 518 following trace covers 45 packets, of which the 22nd and 24th have 519 been lost and the others received: 521 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 522 One way to encode this would be: 524 bit vector 1111 1111 1111 111 525 bit vector 1111 1101 0111 111 526 bit vector 1111 1111 1111 111 527 null chunk 529 Another way to encode this would be: 531 run of 21 receipts 532 bit vector 0101 1111 1111 111 533 run of 9 receipts 534 null chunk 536 The choice of encoding is left to the application. As part of this 537 freedom of choice, applications MAY terminate a series of run length 538 and bit vector chunks with a bit vector chunk that runs beyond the 539 sequence number space described by the report block. For example, if 540 the 44th packet in the same sequence were lost: 542 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 544 This could be encoded as: 546 run of 21 receipts 547 bit vector 0101 1111 1111 111 548 bit vector 1111 1110 1000 000 549 null chunk 551 In this example, the last five bits of the second bit vector describe 552 a part of the sequence number space that extends beyond the last 553 sequence number in the trace. These bits have been set to zero. 555 All bits in a bit vector chunk that describe a part of the sequence 556 number space that extends beyond the last sequence number in the 557 trace MUST be set to zero, and MUST be ignored by the receiver. 559 A null packet MUST appear at the end of a Loss RLE Report Block if 560 the number of run length plus bit vector chunks is odd. The null 561 chunk MUST NOT appear in any other context. 563 Caution should be used in sending Loss RLE Report Blocks because, 564 even with the compression provided by run length encoding, they can 565 easily consume bandwidth out of proportion with normal RTCP packets. 566 The block type includes a mechanism, called thinning, that allows an 567 application to limit report sizes. 569 A thinning value, T, selects a subset of packets within the sequence 570 number space: those with sequence numbers that are multiples of 2^T. 571 Packet reception and loss reports apply only to those packets. T can 572 vary between 0 and 15. If T is zero then every packet in the 573 sequence number space is reported upon. If T is fifteen then one in 574 every 32,768 packets is reported upon. 576 Suppose that the trace just described begins at sequence number 577 13,821. The last sequence number in the trace is 13,865. If the 578 trace were to be thinned with a thinning value of T=2, then the 579 following sequence numbers would be reported upon: 13,824, 13,828, 580 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 581 13,864. The thinned trace would be as follows: 583 1 1 1 1 1 0 1 1 1 1 0 585 This could be encoded as follows: 587 bit vector 1111 1011 1100 000 588 null chunk 590 The last four bits in the bit vector, representing sequence numbers 591 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are 592 thus set to zero and are ignored by the receiver. With thinning, the 593 loss of the 22nd packet goes unreported because its sequence number, 594 13,842, is not a multiple of four. Packet receipts for all sequence 595 numbers that are not multiples of four also go unreported. However, 596 in this example thinning has permitted the Loss RLE Report Block to 597 be shortened by one 32 bit word. 599 Choice of the thinning value is left to the application. 601 The Loss RLE Report Block has the following format: 603 0 1 2 3 604 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | BT=1 | rsvd. | T | block length | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | SSRC of source | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | begin_seq | end_seq | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | chunk 1 | chunk 2 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 : ... : 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | chunk n-1 | chunk n | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 block type (BT): 8 bits 620 A Loss RLE Report Block is identified by the constant 1. 622 rsvd.: 4 bits 623 This field is reserved for future definition. In the absence of 624 such definition, the bits in this field MUST be set to zero and 625 MUST be ignored by the receiver. 627 thinning (T): 4 bits 628 The amount of thinning performed on the sequence number space. 629 Only those packets with sequence numbers 0 mod 2^T are reported 630 on by this block. A value of 0 indicates that there is no 631 thinning, and all packets are reported on. The maximum thinning 632 is one packet in every 32,768 (amounting to two packets within 633 each 16-bit sequence space). 635 block length: 16 bits 636 Defined in Section 3. 638 SSRC of source: 32 bits 639 The SSRC of the RTP data packet source being reported upon by 640 this report block. 642 begin_seq: 16 bits 643 The first sequence number that this block reports on. 645 end_seq: 16 bits 646 The last sequence number that this block reports on plus one. 648 chunk i: 16 bits 649 There are three chunk types: run length, bit vector, and 650 terminating null, defined in the following sections. If the 651 chunk is all zeroes then it is a terminating null chunk. 652 Otherwise, the leftmost bit of the chunk determines its type: 0 653 for run length and 1 for bit vector. 655 4.1.1 Run Length Chunk 657 0 1 658 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 |C|R| run length | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 chunk type (C): 1 bit 664 A zero identifies this as a run length chunk. 666 run type (R): 1 bit 667 Zero indicates a run of 0s. One indicates a run of 1s. 669 run length: 14 bits 670 A value between 1 and 16,383. The value MUST not be zero for a 671 run length chunk (zeroes in both the run type and run length 672 fields would make the chunk a terminating null chunk). Run 673 lengths of 15 or less MAY be described with a run length chunk 674 despite the fact that they could also be described as part of a 675 bit vector chunk. 677 4.1.2 Bit Vector Chunk 679 0 1 680 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 |C| bit vector | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 chunk type (C): 1 bit 686 A one identifies this as a bit vector chunk. 688 bit vector: 15 bits 689 The vector is read from left to right, in order of increasing 690 sequence number (with the appropriate allowance for wraparound). 692 4.1.3 Terminating Null Chunk 693 This chunk is all zeroes. 695 0 1 696 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 4.2 Duplicate RLE Report Block 703 This block type permits per-sequence-number reports on duplicates in 704 a source's RTP packet stream. Such information can be used for 705 network diagnosis, and provide an alternative to packet losses as a 706 basis for multicast tree topology inference. 708 The Duplicate RLE Report Block format is identical to the Loss RLE 709 Report Block format. Only the interpretation is different, in that 710 the information concerns packet duplicates rather than packet losses. 711 The trace to be encoded in this case also consists of zeros and ones, 712 but a zero here indicates the presence of duplicate packets for a 713 given sequence number, whereas a one indicates that no duplicates 714 were received. 716 The existence of a duplicate for a given sequence number is 717 determined over the entire reporting period. For example, if packet 718 number 12,593 arrives, followed by other packets with other sequence 719 numbers, the arrival later in the reporting period of another packet 720 numbered 12,593 counts as a duplicate for that sequence number. The 721 duplicate does not need to follow immediately upon the first packet 722 of that number. Care must be taken that a report does not cover a 723 range of 65,534 or greater in the sequence number space. 725 No distinction is made between the existence of a single duplicate 726 packet and multiple duplicate packets for a given sequence number. 727 Note also that since there is no duplicate for a lost packet, a loss 728 is encoded as a one in a Duplicate RLE Report Block. 730 The Duplicate RLE Report Block has the following format: 732 0 1 2 3 733 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | BT=2 | rsvd. | T | block length | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | SSRC of source | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | begin_seq | end_seq | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | chunk 1 | chunk 2 | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 : ... : 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | chunk n-1 | chunk n | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 block type (BT): 8 bits 749 A Duplicate RLE Report Block is identified by the constant 2. 751 rsvd.: 4 bits 752 This field is reserved for future definition. In the absence of 753 such definition, the bits in this field MUST be set to zero and 754 MUST be ignored by the receiver. 756 thinning (T): 4 bits 757 As defined in Section 4.1. 759 block length: 16 bits 760 Defined in Section 3. 762 SSRC of source: 32 bits 763 As defined in Section 4.1. 765 begin_seq: 16 bits 766 As defined in Section 4.1. 768 end_seq: 16 bits 769 As defined in Section 4.1. 771 chunk i: 16 bits 772 As defined in Section 4.1. 774 4.3 Packet Receipt Times Report Block 776 This block type permits per-sequence-number reports on packet receipt 777 times for a given source's RTP packet stream. Such information can 778 be used for MINC inference of the topology of the multicast tree used 779 to distribute the source's RTP packets, and of the delays along the 780 links within that tree. It can also be used to measure partial path 781 characteristics and to model distributions for packet jitter. 783 Packet receipt times are expressed in the same units as used in the 784 RTP timestamps of data packets. This is so that, for each packet, 785 one can establish both the send time and the receipt time in 786 comparable terms. Note, however, that as an RTP sender ordinarily 787 initializes its time to a value chosen at random, there can be no 788 expectation that reported send and receipt times will differ by an 789 amount equal to the one-way delay between sender and receiver. The 790 reported times can nonetheless be useful for the purposes mentioned 791 above. 793 At least one packet MUST have been received for each sequence number 794 reported upon in this block. If this block type is used to report 795 receipt times for a series of sequence numbers that includes lost 796 packets, several blocks are required. If duplicate packets have been 797 received for a given sequence number, and those packets differ in 798 their receipt times, any time other than the earliest MUST NOT be 799 reported. This is to ensure consistency among reports. 801 Times reported in RTP timestamp format consume more bits than loss or 802 duplicate information, and do not lend themselves to run length 803 encoding. The use of thinning is encouraged to limit the size of 804 Packet Receipt Times Report Blocks. 806 The Packet Receipt Times Report Block has the following format: 808 0 1 2 3 809 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | BT=3 | rsvd. | T | block length | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | SSRC of source | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | begin_seq | end_seq | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Receipt time of packet begin_seq | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Receipt time of packet (begin_seq + 1) mod 65536 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 : ... : 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Receipt time of packet (end_seq - 1) mod 65536 | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 block type (BT): 8 bits 827 A Packet Receipt Times Report Block is identified by the 828 constant 3. 830 rsvd.: 4 bits 831 This field is reserved for future definition. In the absence of 832 such definition, the bits in this field MUST be set to zero and 833 MUST be ignored by the receiver. 835 thinning (T): 4 bits 836 As defined in Section 4.1. 838 block length: 16 bits 839 Defined in Section 3. 841 SSRC of source: 32 bits 842 As defined in Section 4.1. 844 begin_seq: 16 bits 845 As defined in Section 4.1. 847 end_seq: 16 bits 848 As defined in Section 4.1. 850 Packet i receipt time: 32 bits 851 The receipt time of the packet with sequence number i at the 852 receiver. The modular arithmetic shown in the packet format 853 diagram is to allow for sequence number rollover. It is 854 preferable for the time value to be established at the link 855 layer interface, or in any case as close as possible to the wire 856 arrival time. Units and format are the same as for the 857 timestamp in RTP data packets. As opposed to RTP data packet 858 timestamps, in which nominal values may be used instead of 859 system clock values in order to convey information useful for 860 periodic playout, the receipt times should reflect the actual 861 time as closely as possible. For a session, if the RTP 862 timestamp is chosen at random, the first receipt time value 863 SHOULD also be chosen at random, and subsequent timestamps 864 offset from this value. On the other hand, if the RTP timestamp 865 is meant to reflect the reference time at the sender, then the 866 receipt time SHOULD be as close as possible to the reference 867 time at the receiver. 869 4.4 Receiver Reference Time Report Block 871 This block extends RTCP's timestamp reporting so that non-senders may 872 also send timestamps. It recapitulates the NTP timestamp fields from 873 the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate 874 its round trip time (RTT) to other participants, as proposed in [18], 875 by sending this report block and receiving DLRR Report Blocks (see 876 next section) in reply. 878 0 1 2 3 879 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | BT=4 | reserved | block length = 2 | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | NTP timestamp, most significant word | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | NTP timestamp, least significant word | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 block type (BT): 8 bits 889 A Receiver Reference Time Report Block is identified by the 890 constant 4. 892 reserved: 8 bits 893 This field is reserved for future definition. In the absence of 894 such definition, the bits in this field MUST be set to zero and 895 MUST be ignored by the receiver. 897 block length: 16 bits 898 The constant 2, in accordance with the definition of this field 899 in Section 3. 901 NTP timestamp: 64 bits 902 Indicates the wallclock time when this block was sent so that it 903 may be used in combination with timestamps returned in DLRR 904 Report Blocks (see next section) from other receivers to measure 905 round-trip propagation to those receivers. Receivers should 906 expect that the measurement accuracy of the timestamp may be 907 limited to far less than the resolution of the NTP timestamp. 908 The measurement uncertainty of the timestamp is not indicated as 909 it may not be known. A report block sender that can keep track 910 of elapsed time but has no notion of wallclock time may use the 911 elapsed time since joining the session instead. This is assumed 912 to be less than 68 years, so the high bit will be zero. It is 913 permissible to use the sampling clock to estimate elapsed 914 wallclock time. A report sender that has no notion of wallclock 915 or elapsed time may set the NTP timestamp to zero. 917 4.5 DLRR Report Block 919 This block extends RTCP's delay since last Sender Report (DLSR) 920 mechanism [9, Sec. 6.3.1] so that non-senders may also calculate 921 round trip times, as proposed in [18]. It is termed DLRR for delay 922 since last Receiver Report, and may be sent in response to a Receiver 923 Timestamp Report Block (see previous section) from a receiver to 924 allow that receiver to calculate its round trip time to the 925 respondent. The report consists of one or more 3 word sub-blocks: 926 one sub-block per Receiver Report. 928 0 1 2 3 929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | BT=5 | reserved | block length | 932 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 933 | SSRC_1 (SSRC of first receiver) | sub- 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 935 | last RR (LRR) | 1 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | delay since last RR (DLRR) | 938 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 939 | SSRC_2 (SSRC of second receiver) | sub- 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 941 : ... : 2 942 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 944 block type (BT): 8 bits 945 A DLRR Report Block is identified by the constant 5. 947 reserved: 8 bits 948 This field is reserved for future definition. In the absence of 949 such definition, the bits in this field MUST be set to zero and 950 MUST be ignored by the receiver. 952 block length: 16 bits 953 Defined in Section 3. 955 last RR timestamp (LRR): 32 bits 956 The middle 32 bits out of 64 in the NTP timestamp (as explained 957 in the previous section) received as part of a Receiver 958 Reference Time Report Block from participant SSRC_n. If no such 959 block has been received, the field is set to zero. 961 delay since last RR (DLRR): 32 bits 962 The delay, expressed in units of 1/65536 seconds, between 963 receiving the last Receiver Reference Time Report Block from 964 participant SSRC_n and sending this DLRR Report Block. If no 965 Receiver Reference Time Report Block has been received yet from 966 SSRC_n, the DLRR field is set to zero (or the DLRR is omitted 967 entirely). Let SSRC_r denote the receiver issuing this DLRR 968 Report Block. Participant SSRC_n can compute the round-trip 969 propagation delay to SSRC_r by recording the time A when this 970 Receiver Timestamp Report Block is received. It calculates the 971 total round-trip time A-LRR using the last RR timestamp (LRR) 972 field, and then subtracting this field to leave the round-trip 973 propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig. 974 2]. 976 4.6 Statistics Summary Report Block 978 This block reports statistics beyond the information carried in the 979 standard RTCP packet format, but not as fine grained as that carried 980 in the report blocks previously described. Information is recorded 981 about lost packets, duplicate packets, jitter measurements, and TTL 982 or Hop Limit values. Such information can be useful for network 983 management. 985 The report block contents are dependent upon a series of flags bit 986 carried in the first part of the header. Not all parameters need to 987 be reported in each block. Flags indicate which are and which are 988 not reported. The fields corresponding to unreported parameters MUST 989 be present, but are set to zero. The receiver MUST ignore any 990 Statistics Summary Report Block with a non-zero value in any field 991 flagged as unreported. 993 The Statistics Summary Report Block has the following format: 995 0 1 2 3 996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | BT=6 |L|D|J|ToH|rsvd.| block length = 9 | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | SSRC of source | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | begin_seq | end_seq | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | lost_packets | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | dup_packets | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | min_jitter | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | max_jitter | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | mean_jitter | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | dev_jitter | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 block type (BT): 8 bits 1020 A Statistics Summary Report Block is identified by the constant 1021 6. 1023 loss report flag (L): 1 bit 1024 Bit set to 1 if the lost_packets field contains a report, 0 1025 otherwise. 1027 duplicate report flag (D): 1 bit 1028 Bit set to 1 if the dup_packets field contains a report, 0 1029 otherwise. 1031 jitter flag (J): 1 bit 1032 Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and 1033 dev_jitter fields all contain reports, 0 if none of them do. 1035 TTL or Hop Limit flag (ToH): 2 bits 1036 This field is set to 0 if none of the fields min_ttl_or_hl, 1037 max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports. 1038 If the field is non-zero then all of these fields contain 1039 reports. The value 1 signifies that they report on IPv4 TTL 1040 values. The value 2 signifies that they report on IPv6 Hop 1041 Limit values. This value 3 is undefined and MUST NOT be used. 1043 rsvd.: 3 bits 1044 This field is reserved for future definition. In the absence of 1045 such definition, the bits in this field MUST be set to zero and 1046 MUST be ignored by the receiver. 1048 block length: 16 bits 1049 The constant 9, in accordance with the definition of this field 1050 in Section 3. 1052 SSRC of source: 32 bits 1053 As defined in Section 4.1. 1055 begin_seq: 16 bits 1056 As defined in Section 4.1. 1058 end_seq: 16 bits 1059 As defined in Section 4.1. 1061 lost_packets: 32 bits 1062 Number of lost packets in the above sequence number interval. 1064 dup_packets: 32 bits 1065 Number of duplicate packets in the above sequence number 1066 interval. 1068 min_jitter: 32 bits 1069 The minimum relative transit time between two packets in the 1070 above sequence number interval. All jitter values are measured 1071 as the difference between a packet's RTP timestamp and the 1072 reporter's clock at the time of arrival, measured in the same 1073 units. 1075 max_jitter: 32 bits 1076 The maximum relative transit time between two packets in the 1077 above sequence number interval. 1079 mean_jitter: 32 bits 1080 The mean relative transit time between each two packet series in 1081 the above sequence number interval, rounded to the nearest value 1082 expressible as an RTP timestamp. 1084 dev_jitter: 32 bits 1085 The standard deviation of the relative transit time between each 1086 two packet series in the above sequence number interval. 1088 min_ttl_or_hl: 8 bits 1089 The minimum TTL or Hop Limit value of data packets in the 1090 sequence number range. 1092 max_ttl_or_hl: 8 bits 1093 The maximum TTL or Hop Limit value of data packets in the 1094 sequence number range. 1096 mean_ttl_or_hl: 8 bits 1097 The mean TTL or Hop Limit value of data packets in the sequence 1098 number range, rounded to the nearest integer. 1100 dev_ttl_or_hl: 8 bits 1101 The standard deviation of TTL or Hop Limit values of data 1102 packets in the sequence number range. 1104 4.7 VoIP Metrics Report Block 1106 The VoIP Metrics Report Block provides metrics for monitoring voice 1107 over IP (VoIP) calls. These metrics include packet loss and discard 1108 metrics, delay metrics, analog metrics, and voice quality metrics. 1109 The block reports separately on packets lost on the IP channel, and 1110 those that have been received but then discarded by the receiving 1111 jitter buffer. It also reports on the combined effect of losses and 1112 discards, as both have equal effect on call quality. 1114 In order to properly assess the quality of a Voice over IP call it is 1115 desirable to consider the degree of burstiness of packet loss [14]. 1116 Following a Gilbert-Elliott model [3], a period of time, bounded by 1117 lost and/or discarded packets, with a high rate of losses and/or 1118 discards is a "burst," and a period of time between two bursts is a 1119 "gap." Bursts correspond to periods of time during which the packet 1120 loss rate is high enough to produce noticeable degradation in audio 1121 quality. Gaps correspond to periods of time during which only 1122 isolated lost packets may occur, and in general these can be masked 1123 by packet loss concealment. Delay reports include the transit delay 1124 between RTP end points and the VoIP end system processing delays, 1125 both of which contribute to the user perceived delay. Additional 1126 metrics include signal, echo, noise, and distortion levels. Call 1127 quality metrics include R factors (as described by the E Model 1128 defined in [6,3]) and mean opinion scores (MOS scores). 1130 Implementations MUST provide values for all the fields defined here. 1131 For certain metrics, if the value is undefined or unknown, then the 1132 specified default or unknown field value MUST be provided. 1134 The block is encoded as seven 32-bit words: 1136 0 1 2 3 1137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | BT=7 | reserved | block length = 8 | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | SSRC of source | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | loss rate | discard rate | burst density | gap density | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | burst duration | gap duration | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | round trip delay | end system delay | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | signal level | noise level | RERL | Gmin | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | R factor | ext. R factor | MOS-LQ | MOS-CQ | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | RX config | reserved | JB nominal | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | JB maximum | JB abs max | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 block type (BT): 8 bits 1159 A VoIP Metrics Report Block is identified by the constant 7. 1161 reserved: 8 bits 1162 This field is reserved for future definition. In the absence of 1163 such definition, the bits in this field MUST be set to zero and 1164 MUST be ignored by the receiver. 1166 block length: 16 bits 1167 The constant 8, in accordance with the definition of this field 1168 in Section 3. 1170 SSRC of source: 32 bits 1171 As defined in Section 4.1. 1173 The remaining fields are described in the following six sections: 1174 Packet Loss and Discard Metrics, Delay Metrics, Signal Related 1175 Metrics, Call Quality or Transmission Quality Metrics, Configuration 1176 Metrics, and Jitter Buffer Parameters. 1178 4.7.1 Packet Loss and Discard Metrics 1180 It is very useful to distinguish between packets lost by the network 1181 and those discarded due to jitter. Both have equal effect on the 1182 quality of the voice stream however having separate counts helps 1183 identify the source of quality degradation. These fields MUST be 1184 populated, and MUST be set to zero if no packets have been received. 1186 loss rate: 8 bits 1187 The fraction of RTP data packets from the source lost since the 1188 beginning of reception, expressed as a fixed point number with 1189 the binary point at the left edge of the field. This value is 1190 calculated by dividing the total number of packets lost (after 1191 the effects of applying any error protection such as FEC) by the 1192 total number of packets expected, multiplying the result of the 1193 division by 256, limiting the maximum value to 255 (to avoid 1194 overflow), and taking the integer part. The numbers of 1195 duplicated packets and discarded packets do not enter into this 1196 calculation. Since receivers cannot be required to maintain 1197 unlimited buffers, a receiver MAY categorize late-arriving 1198 packets as lost. The degree of lateness that triggers a loss 1199 SHOULD be significantly greater than that which triggers a 1200 discard. 1202 discard rate: 8 bits 1203 The fraction of RTP data packets from the source that have been 1204 discarded since the beginning of reception, due to late or early 1205 arrival, under-run or overflow at the receiving jitter buffer. 1206 This value is expressed as a fixed point number with the binary 1207 point at the left edge of the field. It is calculated by 1208 dividing the total number of packets discarded (excluding 1209 duplicate packet discards) by the total number of packets 1210 expected, multiplying the result of the division by 256, 1211 limiting the maximum value to 255 (to avoid overflow), and 1212 taking the integer part. 1214 4.7.2 Burst Metrics 1216 A burst is a period during which a high proportion of packets are 1217 either lost or discarded due to late arrival. A burst is defined, in 1218 terms of a value Gmin, as a longest sequence that (a) starts with a 1219 lost or discarded packet, (b) does not contain any occurrences of 1220 Gmin or more consecutive received (and not discarded) packets, and 1221 (c) ends with a lost or discarded packet. 1223 A gap, informally, is a period of low packet losses and/or discards. 1224 Formally, a gap is defined as any of the following: (a) the period 1225 from the start of an RTP session to the receipt time of the last 1226 received packet before the first burst, (b) the period from the end 1227 of the last burst to either the time of the report or the end of the 1228 RTP session, whichever comes first, or (c) the period of time between 1229 two bursts. 1231 For the purpose of determining if a lost or discarded packet near the 1232 start or end of an RTP session is within a gap or a burst it is 1233 assumed that the RTP session is preceded and followed by at least 1234 Gmin received packets, and that the time of the report is followed by 1235 at least Gmin received packets. 1237 A gap has the property that any lost or discarded packets within the 1238 gap must be preceded and followed by at least Gmin packets that were 1239 received and not discarded. This gives a maximum loss/discard rate 1240 within a gap of: 1 / (Gmin + 1). 1242 A Gmin value of 16 is RECOMMENDED as it results in gap 1243 characteristics that correspond to good quality (i.e. low packet loss 1244 rate, a minimum distance of 16 received packets between lost packets) 1245 and hence differentiates nicely between good and poor quality 1246 periods. 1248 For example, a 1 denotes a received, 0 a lost, and X a discarded 1249 packet in the following pattern covering 64 packets: 1251 11110111111111111111111X111X1011110111111111111111111X111111111 1252 |---------gap----------|--burst---|------------gap------------| 1254 The burst consists of the twelve packets indicated above, starting at 1255 a discarded packet and ending at a lost packet. The first gap starts 1256 at the beginning of the session and the second gap ends at the time 1257 of the report. 1259 If the packet spacing is 10 ms and the Gmin value is the recommended 1260 value of 16, the burst duration is 120 ms, the burst density 0.33, 1261 the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04. 1263 This would result in reported values as follows (see field 1264 descriptions for semantics and details on how these are calculated): 1266 loss rate 12, which corresponds to 5% 1267 discard rate 12, which corresponds to 5% 1268 burst density 84, which corresponds to 33% 1269 gap density 10, which corresponds to 4% 1270 burst duration 120, value in milliseconds 1271 gap duration 520, value in milliseconds 1273 burst density: 8 bits 1274 The fraction of RTP data packets within burst periods since the 1275 beginning of reception that were either lost or discarded. This 1276 value is expressed as a fixed point number with the binary point 1277 at the left edge of the field. It is calculated by dividing the 1278 total number of packets lost or discarded (excluding duplicate 1279 packet discards) within burst periods by the total number of 1280 packets expected within the burst periods, multiplying the 1281 result of the division by 256, limiting the maximum value to 255 1282 (to avoid overflow), and taking the integer part. This field 1283 MUST be populated and MUST be set to zero if no packets have 1284 been received. 1286 gap density: 8 bits 1287 The fraction of RTP data packets within inter-burst gaps since 1288 the beginning of reception that were either lost or discarded. 1289 The value is expressed as a fixed point number with the binary 1290 point at the left edge of the field. It is calculated by 1291 dividing the total number of packets lost or discarded 1292 (excluding duplicate packet discards) within gap periods by the 1293 total number of packets expected within the gap periods, 1294 multiplying the result of the division by 256, limiting the 1295 maximum value to 255 (to avoid overflow), and taking the integer 1296 part. This field MUST be populated and MUST be set to zero if 1297 no packets have been received. 1299 burst duration: 16 bits 1300 The mean duration, expressed in milliseconds, of the burst 1301 periods that have occurred since the beginning of reception. 1302 The duration of each period is calculated based upon the packets 1303 that mark the beginning and end of that period. It is equal to 1304 the timestamp of the end packet, plus the duration of the end 1305 packet, minus the timestamp of the beginning packet. If the 1306 actual values are not available, estimated values MUST be used. 1307 If there have been no burst periods, the burst duration value 1308 MUST be zero. 1310 gap duration: 16 bits 1311 The mean duration, expressed in milliseconds, of the gap periods 1312 that have occurred since the beginning of reception. The 1313 duration of each period is calculated based upon the packet that 1314 marks the end of the prior burst and the packet that marks the 1315 beginning of the subsequent burst. It is equal to the timestamp 1316 of the subsequent burst packet, minus the timestamp of the prior 1317 burst packet, plus the duration of the prior burst packet. If 1318 the actual values are not available, estimated values MUST be 1319 used. In the case of a gap that occurs at the beginning of 1320 reception, the sum of the timestamp of the prior burst packet 1321 and the duration of the prior burst packet are replaced by the 1322 reception start time. In the case of a gap that occurs at the 1323 end of reception, the timestamp of the subsequent burst packet 1324 is replaced by the reception end time. If there have been no 1325 gap periods, the gap duration value MUST be zero. 1327 4.7.3 Delay Metrics 1329 For the purpose of the following definitions, the RTP interface is 1330 the interface between the RTP instance and the voice application 1331 (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For 1332 example, the time delay due to RTP payload multiplexing would be 1333 considered to be part of the voice application or end-system delay 1334 whereas delay due to multiplexing RTP frames within a UDP frame would 1335 be considered part of the RTP reported delay. This distinction is 1336 consistent with the use of RTCP for delay measurements. 1338 round trip delay: 16 bits 1339 The most recently calculated round trip time between RTP 1340 interfaces, expressed in milliseconds. This value MAY be 1341 measured using RTCP, the DLRR method defined in Section 4.5 of 1342 this document, in which case it is necessary to convert the 1343 units of measurement from NTP timestamp values to milliseconds, 1344 or other approaches. If RTCP is used then the reported delay 1345 value is the time of receipt of the most recent RTCP packet from 1346 source SSRC, minus the LSR (last SR) time reported in its SR 1347 (Sender Report), minus the DLSR (delay since last SR) reported 1348 in its SR. A non-zero LSR value is required in order to 1349 calculate round trip delay. A value of 0 is permissible, however 1350 this field MUST be populated as soon as a delay estimate is 1351 available. 1353 end system delay: 16 bits 1354 The most recently estimated end system delay, expressed in 1355 milliseconds. End system delay is defined as the sum of the 1356 total sample accumulation and encoding delay associated with the 1357 sending direction and the jitter buffer, decoding, and playout 1358 buffer delay associated with the receiving direction. This 1359 delay MAY be estimated or measured. This value SHOULD be 1360 provided in all VoIP metrics reports. If an implementation is 1361 unable to provide the data, the value 0 MUST be used. 1363 Note that the one way symmetric VoIP segment delay may be calculated 1364 from the round trip and end system delays as follows. If the round 1365 trip delay is denoted RTD and the end system delays associated with 1366 the two endpoints are ESD(A) and ESD(B) then: 1368 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 1370 4.7.4 Signal Related Metrics 1371 The following metrics are intended to provide real time information 1372 related to the non-packet elements of the voice over IP system to 1373 assist with the identification of problems affecting call quality. 1374 The values identified below must be determined for the received audio 1375 signal. The information required to populate these fields may not be 1376 available in all systems, although it is strongly recommended that 1377 this data SHOULD be provided to support problem diagnosis. 1379 signal level: 8 bits 1380 The voice signal relative level is defined as the ratio of the 1381 signal level to a 0 dBm0 reference [10], expressed in decibels 1382 as a signed integer in two's complement form. This is measured 1383 only for packets containing speech energy. The intent of this 1384 metric is not to provide a precise measurement of the signal 1385 level but to provide a real time indication that the signal 1386 level may be excessively high or low. 1388 signal level = 10 Log10 ( rms talkspurt power (mW) ) 1390 A value of 127 indicates that this parameter is unavailable. 1391 Typical values should be generally in the -15 to -20 dBm range. 1393 noise level: 8 bits 1394 The noise level is defined as the ratio of the silent period 1395 background noise level to a 0 dBm0 reference, expressed in 1396 decibels as a signed integer in two's complement form. 1398 noise level = 10 Log10 ( rms silence power (mW) ) 1400 A value of 127 indicates that this parameter is unavailable. 1402 residual echo return loss (RERL): 8 bits 1403 The residual echo return loss value may be measured directly by 1404 the VoIP end system's echo canceller or may be estimated by 1405 adding the echo return loss (ERL) and echo return loss 1406 enhancement (ERLE) values reported by the echo canceller. 1408 RERL(dB) = ERL (dB) + ERLE (dB) 1410 In the case of a VoIP gateway the source of echo is typically 1411 line echo that occurs at 2-4 wire conversion points in the 1412 network. This can be in the 8-12 dB range. A line echo 1413 canceler can provide an ERLE of 30 dB or more and hence reduce 1414 this to 40-50 dB. In the case of an IP phone this could be 1415 acoustic coupling between handset speaker and microphone or 1416 residual acoustic echo from speakerphone operation, and may more 1417 correctly be termed terminal coupling loss (TCL). A typical 1418 handset would result in 40-50 dB of echo loss due to acoustic 1419 feedback. 1421 Examples: 1423 - IP gateway connected to circuit switched network with 2 wire 1424 loop. Without echo cancellation, typical 2-4 wire converter ERL 1425 of 12 dB. RERL = ERL + ERLE = 12 + 0 = 12 dB. 1427 - IP gateway connected to circuit switched network with 2 wire 1428 loop. With echo canceler that improves echo by 30 dB. RERL = 1429 ERL + ERLE = 12 + 30 = 42 dB. 1431 - IP phone with conventional handset. Acoustic coupling from 1432 handset speaker to microphone (terminal coupling loss) is 1433 typically 40 dB. RERL = TCL = 40 dB. 1435 If we denote the local end of the VoIP path as A and the remote 1436 end as B and if the sender loudness rating (SLR) and receiver 1437 loudness rating (RLR) are known for A (default values 8 dB and 2 1438 dB respectively), then the echo loudness level at end A (talker 1439 echo loudness rating or TELR) is given by: 1441 TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A) 1443 TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B) 1445 Hence in order to incorporate echo into a voice quality estimate 1446 at the A end of a VoIP connection it is desirable to send the 1447 ERL + ERLE value from B to A using a format such as RTCP XR. 1449 Echo related information may not be available in all VoIP end 1450 systems. As echo does have a significant effect on 1451 conversational quality it is recommended that estimated values 1452 for echo return loss and terminal coupling loss be provided (if 1453 sensible estimates can be reasonably determined). 1455 Typical values for end systems are given below to provide 1456 guidance: 1458 - IP Phone with handset: typically 45 dB. 1460 - PC softphone or speakerphone: extremely variable, consider 1461 reporting "undefined" (127). 1463 - IP gateway with line echo canceller: typically has ERL and 1464 ERLE available. 1466 - IP gateway without line echo canceller: frequently a source of 1467 echo related problems, consider reporting either a low value (12 1468 dB) or "undefined" (127). 1470 Gmin 1471 See Configuration Parameters (Section 4.7.6, below). 1473 4.7.5 Call Quality or Transmission Quality Metrics 1475 The following metrics are direct measures of the call quality or 1476 transmission quality, and incorporate the effects of codec type, 1477 packet loss, discard, burstiness, delay etc. These metrics may not 1478 be available in all systems however SHOULD be provided in order to 1479 support problem diagnosis. 1481 R factor: 8 bits 1482 The R factor is a voice quality metric describing the segment of 1483 the call that is carried over this RTP session. It is expressed 1484 as an integer in the range 0 to 100, with a value of 94 1485 corresponding to "toll quality" and values of 50 or less 1486 regarded as unusable. This metric is defined as including the 1487 effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 1488 101 329-5 [3]. 1490 A value of 127 indicates that this parameter is unavailable. 1491 Values other than 127 and the valid range defined above MUST not 1492 be sent and MUST be ignored by the receiving system. 1494 ext. R factor: 8 bits 1495 The external R factor is a voice quality metric describing the 1496 segment of the call that is carried over a network segment 1497 external to the RTP segment, for example a cellular network. Its 1498 values are interpreted in the same manner as for the RTP R 1499 factor. This metric is defined as including the effects of 1500 delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 1501 [3], and relates to the outward voice path from the Voice over 1502 IP termination for which this metrics block applies. 1504 A value of 127 indicates that this parameter is unavailable. 1505 Values other than 127 and the valid range defined above MUST not 1506 be sent and MUST be ignored by the receiving system. 1508 Note that an overall R factor may be estimated from the RTP segment R 1509 factor and the external R factor, as follows: 1511 R total = RTP R factor + ext. R factor - 94 1513 MOS-LQ: 8 bits 1514 The estimated mean opinion score for listening quality (MOS-LQ) 1515 is a voice quality metric on a scale from 1 to 5, in which 5 1516 represents excellent and 1 represents unacceptable. This metric 1517 is defined as not including the effects of delay and can be 1518 compared to MOS scores obtained from listening quality (ACR) 1519 tests. It is expressed as an integer in the range 10 to 50, 1520 corresponding to MOS x 10. For example, a value of 35 would 1521 correspond to an estimated MOS score of 3.5. 1523 A value of 127 indicates that this parameter is unavailable. 1524 Values other than 127 and the valid range defined above MUST not 1525 be sent and MUST be ignored by the receiving system. 1527 MOS-CQ: 8 bits 1528 The estimated mean opinion score for conversational quality 1529 (MOS-CQ) is defined as including the effects of delay and other 1530 effects that would affect conversational quality. The metric 1531 may be calculated by converting an R factor determined according 1532 to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated 1533 MOS using the equation specified in G.107. It is expressed as 1534 an integer in the range 10 to 50, corresponding to MOS x 10, as 1535 for MOS-LQ. 1537 A value of 127 indicates that this parameter is unavailable. 1538 Values other than 127 and the valid range defined above MUST not 1539 be sent and MUST be ignored by the receiving system. 1541 4.7.6 Configuration Parameters 1543 Gmin: 8 bits 1544 The gap threshold. This field contains the value used for this 1545 report block to determine if a gap exists. The recommended 1546 value of 16 corresponds to a burst period having a minimum 1547 density of 6.25% of lost or discarded packets, which may cause 1548 noticeable degradation in call quality; during gap periods, if 1549 packet loss or discard occurs, each lost or discarded packet 1550 would be preceded by and followed by a sequence of at least 16 1551 received non-discarded packets. Note that lost or discarded 1552 packets that occur within Gmin packets of a report being 1553 generated may be reclassified as being part of a burst or gap in 1554 later reports. ETSI TS 101 329-5 [3] defines a computationally 1555 efficient algorithm for measuring burst and gap density using a 1556 packet loss/discard event driven approach. This algorithm is 1557 reproduced in Appendix A.2 of the present document. Gmin MUST 1558 not be zero and MUST be provided and MUST remain constant across 1559 VoIP Metrics report blocks for the duration of the RTP session. 1561 receiver configuration byte (RX config): 8 bits 1562 This byte consists of the following fields: 1564 0 1 2 3 4 5 6 7 1565 +-+-+-+-+-+-+-+-+ 1566 |PLC|JBA|JB rate| 1567 +-+-+-+-+-+-+-+-+ 1569 packet loss concealment (PLC): 2 bits 1570 Standard (11) / enhanced (10) / disabled (01) / unspecified 1571 (00). When PLC = 11 then a simple replay or interpolation 1572 algorithm is being used to fill-in the missing packet; this 1573 approach is typically able to conceal isolated lost packets 1574 at low packet loss rates. When PLC = 10 then an enhanced 1575 interpolation algorithm is being used; algorithms of this 1576 type are able to conceal high packet loss rates 1577 effectively. When PLC = 01 then silence is being inserted 1578 in place of lost packets. When PLC = 00 then no 1579 information is available concerning the use of PLC, however 1580 for some codecs this may be inferred. 1582 jitter buffer adaptive (JBA): 2 bits 1583 Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown 1584 (00). When the jitter buffer is adaptive then its size is 1585 being dynamically adjusted to deal with varying levels of 1586 jitter. When non-adaptive, the jitter buffer size is 1587 maintained at a fixed level. When either adaptive or non- 1588 adaptive modes are specified then the jitter buffer size 1589 parameters below MUST be specified. 1591 jitter buffer rate (JB rate): 4 bits 1592 J = adjustment rate (0-15). This represents the 1593 implementation specific adjustment rate of a jitter buffer 1594 in adaptive mode. This parameter is defined in terms of the 1595 approximate time taken to fully adjust to a step change in 1596 peak to peak jitter from 30 ms to 100 ms such that: 1598 adjustment time = 2 * J * frame size (ms) 1600 This parameter is intended only to provide a guide to the 1601 degree of "aggressiveness" of a an adaptive jitter buffer 1602 and may be estimated. A value of 0 indicates that the 1603 adjustment time is unknown for this implementation. 1605 reserved: 8 bits 1606 This field is reserved for future definition. In the absence of 1607 such definition, the bits in this field MUST be set to zero and 1608 MUST be ignored by the receiver. 1610 4.7.7 Jitter Buffer Parameters 1611 The values reported in these fields SHOULD be the most recently 1612 obtained values at the time of reporting. 1614 jitter buffer nominal delay (JB nominal): 16 bits 1615 This is the current nominal jitter buffer delay in milliseconds, 1616 which corresponds to the nominal jitter buffer delay for packets 1617 that arrive exactly on time. This parameter MUST be provided 1618 for both fixed and adaptive jitter buffer implementations. 1620 jitter buffer maximum delay (JB maximum): 16 bits 1621 This is the current maximum jitter buffer delay in milliseconds 1622 which corresponds to the earliest arriving packet that would not 1623 be discarded. In simple queue implementations this may 1624 correspond to the nominal size. In adaptive jitter buffer 1625 implementations this value may dynamically vary up to JB abs max 1626 (see below). This parameter MUST be provided for both fixed and 1627 adaptive jitter buffer implementations. 1629 jitter buffer absolute maximum delay (JB abs max): 16 bits 1630 This is the absolute maximum delay in milliseconds that the 1631 adaptive jitter buffer can reach under worst case conditions. 1632 If this value exceeds 65535 milliseconds then this field SHALL 1633 convey the value 65535. This parameter MUST be provided for 1634 adaptive jitter buffer implementations and its value MUST be set 1635 to JB maximum for fixed jitter buffer implementations. 1637 5. SDP Signaling 1639 This section defines Session Description Protocol (SDP) [4] signaling 1640 for XR blocks that can be employed by applications that utilize SDP. 1641 This signaling is defined to be used either by applications that 1642 implement the SDP Offer/Answer model [8] or by applications that use 1643 SDP to describe media and transport configurations in connection with 1644 such protocols as the Session Announcement Protocol (SAP) [15] or the 1645 Real Time Streaming Protocol (RTSP) [17]. There exist other 1646 potential signaling methods, which are not defined here. 1648 The XR blocks MAY be used without prior signaling. This is 1649 consistent with the rules governing other RTCP packet types, as 1650 described in [9]. An example in which signaling would not be used is 1651 an application that always requires the use of one or more XR blocks. 1652 However for applications that are configured at session initiation, 1653 the use of some type of signaling is recommended. 1655 Note that, although the use of SDP signaling for XR blocks may be 1656 optional, if used it MUST be used as defined here. If SDP signaling 1657 is used in an environment where XR blocks are only implemented by 1658 some fraction of the participants, the ones not implementing the XR 1659 blocks will ignore the SDP attribute. 1661 5.1 The SDP Attribute 1663 This section defines one new SDP attribute "rtcp-xr" that can be used 1664 to signal participants in a media session that they should use the 1665 specified XR blocks. This attribute can be easily extended in the 1666 future with new parameters to cover any new report blocks. 1668 The RTCP XR blocks SDP attribute is defined below in Augmented 1669 Backus-Naur Form (ABNF) [2]. It is both a session and a media level 1670 attribute. When specified at session level, it applies to all media 1671 level blocks in the session. Any media level specification MUST 1672 replace a session level specification, if one is present, for that 1673 media block. 1675 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 1677 xr-format = pkt-loss-rle 1678 / pkt-dup-rle 1679 / pkt-rcpt-times 1680 / rcvr-rtt 1681 / stat-summary 1682 / voip-metrics 1683 / format-ext 1685 pkt-loss-rle = "pkt-loss-rle" ["=" max-size] 1686 pkt-dup-rle = "pkt-dup-rle" ["=" max-size] 1687 pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size] 1688 rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size] 1689 rcvr-rtt-mode = "all" 1690 / "sender" 1691 stat-summary = "stat-summary" ["=" stat-flag *("," stat-flag)] 1692 stat-flag = "loss" 1693 / "dup" 1694 / "jitt" 1695 / "TTL" 1696 / "HL" 1697 voip-metrics = "voip-metrics" 1698 max-size = 1*DIGIT ; maximum block size in octets 1699 DIGIT = %x30-39 1700 format-ext = non-ws-string 1702 non-ws-string = 1*(%x21-FF) 1703 CRLF = %d13.10 1704 The "rtcp-xr" attribute contains zero, one, or more XR block related 1705 parameters. Each parameter signals functionality for an XR block, or 1706 a group of XR blocks. The attribute is extensible so that parameters 1707 can be defined for any future XR block (and a parameter should be 1708 defined for every future block). 1710 Each "rtcp-xr" parameter belongs to one of two categories. The first 1711 category, the unilateral parameters, are for report blocks that 1712 simply report on the RTP stream and related metrics. The second 1713 category, collaborative parameters, are for XR blocks that involve 1714 actions by more than one party in order to carry out their functions. 1716 Round trip time (RTT) measurement is an example of collaborative 1717 functionality. An RTP data packet receiver sends a Receiver 1718 Reference Time Report Block (Section 4.4). A participant that 1719 receives this block sends a DLRR Report Block (Section 4.5) in 1720 response, allowing the receiver to calculate its RTT to that 1721 participant. As this example illustrates, collaborative 1722 functionality may be implemented by two or more different XR blocks. 1723 The collaborative functionality of several XR blocks may be governed 1724 by a single "rtcp-xr" parameter. 1726 For the unilateral category, this document defines the following 1727 parameters. The parameter names and their corresponding XR formats 1728 are as follows: 1730 Parameter name XR block (block type and name) 1731 -------------- ------------------------------------ 1732 pkt-loss-rle 1 Loss RLE Report Block 1733 pkt-dup-rle 2 Duplicate RLE Report Block 1734 pkt-rcpt-times 3 Packet Receipt Times Report Block 1735 stat-summary 6 Statistics Summary Report Block 1736 voip-metrics 7 VoIP Metrics Report Block 1738 The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters 1739 MAY specify an integer value. This value indicates the largest size 1740 the whole report block SHOULD have in octets. This shall be seen as 1741 an indication that thinning shall be applied if necessary to meet the 1742 target size. 1744 The "stat-summary" parameter contains a list indicating which fields 1745 SHOULD be included in the Statistics Summary report blocks that are 1746 sent. The list is a comma separated list, containing one or more 1747 field indicators. The space character (0x20) SHALL NOT be present 1748 within the list. Field indicators represent the flags defined in 1749 section 4.6. The field indicators and their respective flags are as 1750 follows: 1752 Indicator Flag 1753 --------- --------------------------- 1754 loss loss report flag (L) 1755 dup duplicate report flag (D) 1756 jitt jitter flag (J) 1757 TTL TTL or Hop Limit flag (ToH) 1758 HL TTL or Hop Limit flag (ToH) 1760 For "loss", "dup", and "jitt", the presence of the indicator 1761 indicates that the corresponding flag should be set to 1 in the 1762 Statistics Summary report blocks that are sent. The presence of 1763 "TTL" indicates that the corresponding flag should be set to 1. The 1764 presence of "HL" indicates that the corresponding flag should be set 1765 to 2. The indicators "TTL" and "HL" MUST NOT be signaled together. 1767 Blocks in the collaborative category are classified as initiator 1768 blocks or response blocks. Signaling SHOULD indicate which 1769 participants are required to respond to the initiator block. A party 1770 that wishes to receive response blocks from those participants can 1771 trigger this by sending an initiator block. 1773 The collaborative category currently consists only of one 1774 functionality, namely the RTT measurement mechanism for RTP data 1775 receivers. The collective functionality of the Receiver Reference 1776 Time Report Block and DLRR Report Block is represented by the "rcvr- 1777 rtt" parameter. This parameter takes as its arguments a mode value 1778 and, optionally, a maximum size for the DLRR report block. The mode 1779 value "all" indicates that both RTP data senders and data receivers 1780 MAY send DLRR blocks, while the mode value "sender" indicates that 1781 only active RTP senders MAY send DLRR blocks, i.e. non RTP senders 1782 SHALL NOT send DLRR blocks. If a maximum size in octets is included, 1783 any DLRR Report Blocks that are sent SHALL NOT exceed the specified 1784 size. If size limitations mean that a DLRR Report Block sender 1785 cannot report in one block upon all participants from which it has 1786 received a Receiver Reference Time Report Block then it SHOULD report 1787 on participants in a round robin fashion across several report 1788 intervals. 1790 The "rtcp-xr" attributes parameter list MAY be empty. This is useful 1791 in cases in which an application needs to signal that it understands 1792 the SDP signaling but does not wish to avail itself of XR 1793 functionality. For example, an application in a SIP controlled 1794 session could signal that it wishes to stop using all XR blocks by 1795 removing all applicable SDP parameters in a re-INVITE message that it 1796 sends. If XR blocks are not to be used at all from the beginning of 1797 a session, it is RECOMMENDED that the "rtcp-xr" attribute not be 1798 supplied at all. 1800 When the "rtcp-xr" attribute is present, participants SHOULD NOT send 1801 XR blocks other than the ones indicated by the parameters. This 1802 means that inclusion of a "rtcp-xr" attribute without any parameters 1803 tells a participant that it SHOULD NOT send any XR blocks at all. 1804 The purpose is to conserve bandwidth. This is especially important 1805 when collaborative parameters are applied to a large multicast group: 1806 the sending of an initiator block could potentially trigger responses 1807 from all participants. There are, however, contexts in which it 1808 makes sense to send an XR block in the absence of a parameter 1809 signaling its use. For instance, an application might be designed so 1810 as to send certain report blocks without negotiation, while using SDP 1811 signaling to negotiate the use of other blocks. 1813 5.2 Usage in Offer/Answer 1815 In the Offer/Answer context [8], the interpretation of SDP signaling 1816 for XR packets depends upon the direction attribute that is signaled: 1817 "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute 1818 is supplied then "sendrecv" is assumed. This section applies only to 1819 unicast media streams, except where noted. Discussion of unilateral 1820 parameters is followed by discussion of collaborative parameters in 1821 this section. 1823 For "sendonly" and "sendrecv" media stream offers that specify 1824 unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send 1825 the corresponding XR blocks. For "sendrecv" offers, the answerer MAY 1826 include the "rtcp-xr" attribute in its response, and specify any 1827 unilateral parameters in order to request that the offerer send the 1828 corresponding XR blocks. The offerer SHOULD send these blocks. 1830 For "recvonly" media stream offers, the offerer's use of the "rtcp- 1831 xr" attribute in connection with unilateral parameters indicates that 1832 the offerer is capable of sending the corresponding XR blocks. If 1833 the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD 1834 send XR blocks for each specified unilateral parameter that was in 1835 its offer. 1837 For multicast media streams, the inclusion of an "rtcp-xr" attribute 1838 with unilateral parameters means that every media recipient SHOULD 1839 send the corresponding XR blocks. 1841 An SDP offer with a collaborative parameter declares the offerer 1842 capable of receiving the corresponding initiator and replying with 1843 the appropriate responses. For example, an offer that specifies the 1844 "rcvr-rtt" parameter means that the offerer is prepared to receive 1845 Receiver Reference Time Report Blocks and to send DLRR Report Blocks. 1846 An offer of a collaborative parameter means that the answerer MAY 1847 send the initiator, and, having received the initiator, the offerer 1848 SHOULD send the responses. 1850 There are exceptions to the rule that an offerer of a collaborative 1851 parameter should send responses. For instance, the collaborative 1852 parameter might specify a mode that excludes the offerer. Or 1853 congestion control or maximum transmission unit considerations might 1854 militate against the offerer's response. 1856 By including a collaborative parameter in its answer, the answerer 1857 declares its ability to receive initiators and to send responses. 1858 The offerer MAY then send initiators, to which the answerer SHOULD 1859 reply with responses. As for the offer of a collaborative parameter, 1860 there are exceptions to the rule that the answerer should reply. 1862 When making an SDP offer of a collaborative parameter for a multicast 1863 media stream, the offerer SHOULD specify which participants are to 1864 respond to a received initiator. A participant that is not specified 1865 SHOULD NOT send responses. Otherwise, undue bandwidth might be 1866 consumed. The offer indicates that each participant that is 1867 specified SHOULD respond if it receives an initiator. It also 1868 indicates that a specified participant MAY send an initiator block. 1870 An SDP answer for a multicast media stream SHOULD include all 1871 collaborative parameters that are present in the offer and that are 1872 supported by the answerer. It SHOULD NOT include any collaborative 1873 parameter that is absent from the offer. 1875 If a participant receives an SDP offer and understands the "rtcp-xr" 1876 attribute but does not wish to implement XR functionality offered, 1877 its answer SHOULD include an "rtcp-xr" attribute without parameters. 1878 By doing so, the party declares that at a minimum that it is capable 1879 of understanding the signaling. 1881 5.3 Usage Outside of Offer/Answer 1883 SDP can be employed outside of the Offer/Answer context, for instance 1884 for multimedia sessions that are announced through the Session 1885 Announcement Protocol (SAP) [15], or streamed through the Real Time 1886 Streaming Protocol (RTSP) [17]. The signaling model is simpler, as 1887 the sender does not negotiate parameters, but the functionality that 1888 is expected from specifying the "rtcp-xr" attribute is the same as in 1889 Offer/Answer. 1891 When a unilateral parameter is specified for the "rtcp-xr" attribute 1892 associated with a media stream, the receiver of that stream SHOULD 1893 send the corresponding XR block. When a collaborative parameter is 1894 specified, only the participants indicated by the mode value in the 1895 collaborative parameter are concerned. Each such participant that 1896 receives an initiator block SHOULD send the corresponding response 1897 block. Each such participant MAY also send initiator blocks. 1899 6. IANA Considerations 1901 This document defines a new RTCP packet type, the Extended Report 1902 (XR) type, within the existing Internet Assigned Numbers Authority 1903 (IANA) registry of RTP RTCP Control Packet Types. This document also 1904 defines a new IANA registry: the registry of RTCP XR Block Types. 1905 Within this new registry, this document defines an initial set of 1906 seven block types and describes how the remaining types are to be 1907 allocated. 1909 Further, this document defines a new SDP attribute, "rtcp-xr", within 1910 the existing IANA registry of SDP Parameters. It defines a new IANA 1911 registry, the registry of RTCP XR SDP Parameters, and an initial set 1912 of six parameters, and describes how additional parameters are to be 1913 allocated. 1915 6.1 XR Packet Type 1917 The XR packet type defined by this document is registered with the 1918 IANA as packet type 207 in the registry of RTP RTCP Control Packet 1919 types (PT). 1921 6.2 RTCP XR Block Type Registry 1923 This document creates an IANA registry called the RTCP XR Block Type 1924 Registry to cover the name space of the Extended Report block type 1925 (BT) field specified in Section 3. The BT field contains eight bits, 1926 allowing 256 values. The RTCP XR Block Type Registry is to be 1927 managed by the IANA according to the Specification Required policy of 1928 RFC 2434 [7]. Future specifications SHOULD attribute block type 1929 values in strict numeric order following the values attributed in 1930 this document: 1932 BT name 1933 -- ---- 1934 1 Loss RLE Report Block 1935 2 Duplicate RLE Report Block 1936 3 Packet Receipt Times Report Block 1937 4 Receiver Reference Time Report Block 1938 5 DLRR Report Block 1939 6 Statistics Summary Report Block 1940 7 VoIP Metrics Report Block 1942 The BT value 255 is reserved for future extensions. 1944 Furthermore, future specifications SHOULD avoid the value 0. Doing 1945 so facilitates packet validity checking, since an all-zeros field 1946 might commonly be found in an ill-formed packet. 1948 Any registration MUST contain the following information: 1950 - Contact information of the one doing the registration, including at 1951 least name, address, and email. 1953 - The format of the block type being registered, consistent with the 1954 extended report block format described in Section 3. 1956 - A description of what the block type represents and how it shall be 1957 interpreted, detailing this information for each of its fields. 1959 6.3 The "rtcp-xr" SDP Attribute 1961 This SDP attribute "rtcp-xr" defined by this document is registered 1962 with the IANA registry of SDP Parameters as follows: 1964 SDP Attribute ("att-field"): 1966 Attribute name: rtcp-xr 1967 Long form: RTP Control Protocol Extended Report Parameters 1968 Type of name: att-field 1969 Type of attribute: session and media level 1970 Subject to charset: no 1971 Purpose: see Section 5 of this document 1972 Reference: this document 1973 Values: see this document and registrations below 1975 The attribute has an extensible parameter field and therefore a 1976 registry for these parameters is required. This document creates an 1977 IANA registry called the RTCP XR SDP Parameters Registry. It 1978 contains the six parameters defined in Section 5.1: "pkt-loss-rle", 1979 "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and 1980 "recv-rtt". 1982 Additional parameters are to be added to this registry in accordance 1983 with the Specification Required policy of RFC 2434 [7]. Any 1984 registration MUST contain the following information: 1986 - Contact information of the one doing the registration, including at 1987 least name, address, and email. 1989 - An Augmented Backus-Naur Form (ABNF) [2] definition of the 1990 parameter, in accordance with the "format-ext" definition of 1991 Section 5.1. 1993 - A description of what the parameter represents and how it shall be 1994 interpreted, both normally and in Offer/Answer. 1996 7. Security Considerations 1998 This document extends the RTCP reporting mechanism. The security 1999 considerations that apply to RTCP reports [9, Appendix B] also apply 2000 to XR reports. This section details the additional security 2001 considerations that apply to the extensions. 2003 The extensions introduce heightened confidentiality concerns. 2004 Standard RTCP reports contain a limited number of summary statistics. 2005 The information contained in XR reports is both more detailed and 2006 more extensive (covering a larger number of parameters). The per- 2007 packet report blocks and the VoIP Metrics Report Block provide 2008 examples. 2010 The per-packet information contained in Loss RLE, Duplicate RLE, and 2011 Packet Receipt Times Report Blocks facilitates multicast inference of 2012 network characteristics (MINC) [11]. Such inference can reveal the 2013 gross topology of a multicast distribution tree, as well as 2014 parameters, such as the loss rates and delays, along paths between 2015 branching points in that tree. Such information might be considered 2016 sensitive to autonomous system administrators. 2018 The VoIP Metrics Report Block provides information on the quality of 2019 ongoing voice calls. Though such information might be carried in 2020 application specific format in standard RTP sessions, making it 2021 available in a standard format here makes it more available to 2022 potential eavesdroppers. 2024 No new mechanisms are introduced in this document to ensure 2025 confidentiality. Encryption procedures, such as those being 2026 suggested for a Secure RTCP (SRTCP) [12] at the time that this 2027 document was written, can be used when confidentiality is a concern 2028 to end hosts. Given that RTCP traffic can be encrypted by the end 2029 hosts, autonomous systems must be prepared for the fact that certain 2030 aspects of their network topology can be revealed. 2032 Any encryption or filtering of XR report blocks entails a loss of 2033 monitoring information to third parties. For example, a network that 2034 establishes a tunnel to encrypt VoIP Report Blocks denies that 2035 information to the service providers traversed by the tunnel. The 2036 service providers cannot then monitor or respond to the quality of 2037 the VoIP calls that they carry, potentially creating problems for the 2038 network's users. As a default, XR packets should not be encrypted or 2039 filtered. 2041 The extensions also make certain denial of service attacks easier. 2042 This is because of the potential to create RTCP packets much larger 2043 than average with the per packet reporting capabilities of the Loss 2044 RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the 2045 automatic bandwidth adjustment mechanisms in RTCP, if some session 2046 participants are sending large RTCP packets, all participants will 2047 see their RTCP reporting intervals lengthened, meaning they will be 2048 able to report less frequently. To limit the effects of large 2049 packets, even in the absence of denial of service attacks, 2050 applications SHOULD place an upper limit on the size of the XR report 2051 blocks they employ. The "thinning" techniques described in Section 2052 4.1 permit the packet-by-packet report blocks to adhere to a 2053 predefined size limit. 2055 A. Algorithms 2057 A.1 Sequence Number Interpretation 2059 This the algorithm suggested by Section 4.1 for keeping track of the 2060 sequence numbers from a given sender. It implements the accounting 2061 practice required for the generation of Loss RLE Report Blocks. 2063 This algorithm keeps track of 16 bit sequence numbers by translating 2064 them into a 32 bit sequence number space. The first packet received 2065 from a source is considered to have arrived roughly in the middle of 2066 that space. Each packet that follows is placed either ahead or 2067 behind the prior one in this 32 bit space, depending upon which 2068 choice would place it closer (or, in the event of a tie, which choice 2069 would not require a rollover in the 16 bit sequence number). 2071 // The reference sequence number is an extended sequence number 2072 // that serves as the basis for determining whether a new 16 bit 2073 // sequence number comes earlier or later in the 32 bit sequence 2074 // space. 2075 u_int32 _src_ref_seq; 2076 bool _uninitialized_src_ref_seq; 2078 // Place seq into a 32-bit sequence number space based upon a 2079 // heuristic for its most likely location. 2080 u_int32 extend_seq(const u_int16 seq) { 2082 u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; 2083 if(_uninitialized_src_ref_seq) { 2085 // This is the first sequence number received. Place 2086 // it in the middle of the extended sequence number 2087 // space. 2088 _src_ref_seq = seq | 0x80000000u; 2089 _uninitialized_src_ref_seq = false; 2090 extended_seq = _src_ref_seq; 2091 } 2092 else { 2094 // Prior sequence numbers have been received. 2095 // Propose two candidates for the extended sequence 2096 // number: seq_a is without wraparound, seq_b with 2097 // wraparound. 2098 seq_a = seq | (_src_ref_seq & 0xFFFF0000u); 2099 if(_src_ref_seq < seq_a) { 2100 seq_b = seq_a - 0x00010000u; 2101 diff_a = seq_a - _src_ref_seq; 2102 diff_b = _src_ref_seq - seq_b; 2103 } 2104 else { 2105 seq_b = seq_a + 0x00010000u; 2106 diff_a = _src_ref_seq - seq_a; 2107 diff_b = seq_b - _src_ref_seq; 2108 } 2110 // Choose the closer candidate. If they are equally 2111 // close, the choice is somewhat arbitrary: we choose 2112 // the candidate for which no rollover is necessary. 2113 if(diff_a < diff_b) { 2114 extended_seq = seq_a; 2115 } 2116 else { 2117 extended_seq = seq_b; 2118 } 2120 // Set the reference sequence number to be this most 2121 // recently-received sequence number. 2122 _src_ref_seq = extended_seq; 2123 } 2125 // Return our best guess for a 32-bit sequence number that 2126 // corresponds to the 16-bit number we were given. 2127 return extended_seq; 2128 } 2130 A.2 Example Burst Packet Loss Calculation. 2132 This is an algorithm for measuring the burst characteristics for the 2133 VoIP Metrics Report Block (Section 4.7). The algorithm, which has 2134 been verified against a working implementation for correctness, is 2135 reproduced from ETSI TS 101 329-5 [3]. The algorithm as described 2136 here takes precedence over any change that might eventually be made 2137 to the algorithm in future ETSI documents. 2139 This algorithm is event driven and hence extremely computationally 2140 efficient. 2142 Given the following definition of states: 2144 state 1 = received a packet during a gap 2145 state 2 = received a packet during a burst 2146 state 3 = lost a packet during a burst 2147 state 4 = lost an isolated packet during a gap 2149 The "c" variables below correspond to state transition counts, i.e. 2150 c14 is the transition from state 1 to state 4. It is possible to 2151 infer one of a pair of state transition counts to an accuracy of 1 2152 which is generally sufficient for this application. 2154 "pkt" is the count of packets received since the last packet was 2155 declared lost or discarded and "lost" is the number of packets lost 2156 within the current burst. "packet_lost" and "packet_discarded" are 2157 Boolean variables that indicate if the event that resulted in this 2158 function being invoked was a lost or discarded packet. 2160 if(packet_lost) { 2161 loss_count++; 2162 } 2163 if(packet_discarded) { 2164 discard_count++; 2165 } 2166 if(!packet_lost && !packet_discarded) { 2167 pkt++; 2168 } 2169 else { 2170 if(pkt >= gmin) { 2171 if(lost == 1) { 2172 c14++; 2173 } 2174 else { 2175 c13++; 2176 } 2177 lost = 1; 2178 c11 += pkt; 2179 } 2180 else { 2181 lost++; 2182 if(pkt == 0) { 2183 c33++; 2184 } 2185 else { 2186 c23++; 2187 c22 += (pkt - 1); 2188 } 2189 } 2190 pkt = 0; 2191 } 2193 At each reporting interval the burst and gap metrics can be 2194 calculated as follows. 2196 // Calculate additional transition counts. 2197 c31 = c13; 2198 c32 = c23; 2199 ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; 2201 // Calculate burst and densities. 2202 p32 = c32 / (c31 + c32 + c33); 2203 if((c22 + c23) < 1) { 2204 p23 = 1; 2205 } 2206 else { 2207 p23 = 1 - c22/(c22 + c23); 2208 } 2209 burst_density = 256 * p23 / (p23 + p32); 2210 gap_density = 256 * c14 / (c11 + c14); 2212 // Calculate burst and gap durations in ms 2213 m = frameDuration_in_ms * framesPerRTPPkt; 2214 gap_length = (c11 + c14 + c13) * m / c13; 2215 burst_length = ctotal * m / c13 - lgap; 2217 /* calculate loss and discard rates */ 2218 loss_rate = 256 * loss_count / ctotal; 2219 discard_rate = 256 * discard_count / ctotal; 2221 Intellectual Property 2223 The IETF takes no position regarding the validity or scope of any 2224 intellectual property or other rights that might be claimed to 2225 pertain to the implementation or use of the technology described in 2226 this document or the extent to which any license under such rights 2227 might or might not be available; neither does it represent that it 2228 has made any effort to identify any such rights. Information on the 2229 IETF's procedures with respect to rights in standards-track and 2230 standards-related documentation can be found in BCP 11 [5]. Copies 2231 of claims of rights made available for publication and any assurances 2232 of licenses to be made available, or the result of an attempt made to 2233 obtain a general license or permission for the use of such 2234 proprietary rights by implementors or users of this specification can 2235 be obtained from the IETF Secretariat. 2237 The IETF invites any interested party to bring to its attention any 2238 copyrights, patents or patent applications, or other proprietary 2239 rights which may cover technology that may be required to practice 2240 this standard. Please address the information to the IETF Executive 2241 Director. 2243 Full Copyright Statement 2245 Copyright (C) The Internet Society (2003). All Rights Reserved. 2247 This document and translations of it may be copied and furnished to 2248 others, and derivative works that comment on or otherwise explain it 2249 or assist in its implementation may be prepared, copied, published 2250 and distributed, in whole or in part, without restriction of any 2251 kind, provided that the above copyright notice and this paragraph are 2252 included on all such copies and derivative works. However, this 2253 document itself may not be modified in any way, such as by removing 2254 the copyright notice or references to the Internet Society or other 2255 Internet organizations, except as needed for the purpose of 2256 developing Internet standards in which case the procedures for 2257 copyrights defined in the Internet Standards process must be 2258 followed, or as required to translate it into languages other than 2259 English. 2261 The limited permissions granted above are perpetual and will not be 2262 revoked by the Internet Society or its successors or assigns. 2264 This document and the information contained herein is provided on an 2265 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2266 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2267 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2268 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2269 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2271 Acknowledgments 2273 We thank the following people: Colin Perkins, Steve Casner, and 2274 Henning Schulzrinne for their considered guidance; Sue Moon for 2275 helping foster collaboration between the authors; Mounir Benzaid for 2276 drawing our attention to the reporting needs of MLDA; Dorgham Sisalem 2277 and Adam Wolisz for encouraging us to incorporate MLDA block types; 2278 and Jose Rey for valuable review of the SDP Signaling section. 2280 Contributors 2282 The following people are the authors of this document: 2284 Kevin Almeroth, UCSB 2285 Ramon Caceres, ShieldIP 2286 Alan Clark, Telchemy 2287 Robert Cole, AT&T Labs 2288 Nick Duffield, AT&T Labs-Research 2289 Timur Friedman, Paris 6 2290 Kaynam Hedayat, Brix Networks 2291 Kamil Sarac, UT Dallas 2292 Magnus Westerlund, Ericsson 2294 The principal people to contact regarding the individual report 2295 blocks described in this document are as follows: 2297 sec. report block principal contributors 2298 ---- ------------ ---------------------- 2299 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 2300 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 2301 4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield 2302 4.4 Receiver Reference Time Report Block Friedman 2303 4.5 DLRR Report Block Friedman 2304 4.6 Statistics Summary Report Block Almeroth, Sarac 2305 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat 2307 The principal person to contact regarding the SDP signaling described 2308 in this document is Magnus Westerlund. 2310 Authors' Addresses 2312 Kevin Almeroth 2313 Department of Computer Science 2314 University of California 2315 Santa Barbara, CA 93106 USA 2317 Ramon Caceres 2318 ShieldIP, Inc. 2319 11 West 42nd Street, 31st Floor 2320 New York, NY 10036 USA 2321 Alan Clark 2322 Telchemy Incorporated 2323 3360 Martins Farm Road, Suite 200 2324 Suwanee, GA 30024 USA 2325 Tel: +1 770 614 6944 2326 Fax: +1 770 614 3951 2328 Robert Cole 2329 AT&T Labs 2330 330 Saint Johns Street, 2331 2nd Floor 2332 Havre de Grace, MD 21078 USA 2333 Tel: +1 410 939 8732 2334 Fax: +1 410 939 8732 2336 Nick Duffield 2337 AT&T Labs-Research 2338 180 Park Avenue, P.O. Box 971 2339 Florham Park, NJ 07932-0971 USA 2340 Tel: +1 973 360 8726 2341 Fax: +1 973 360 8050 2343 Timur Friedman 2344 Universite Pierre et Marie Curie (Paris 6) 2345 Laboratoire LiP6-CNRS 2346 8, rue du Capitaine Scott 2347 75015 PARIS France 2348 Tel: +33 1 44 27 71 06 2349 Fax: +33 1 44 27 74 95 2351 Kaynam Hedayat 2352 Brix Networks 2353 285 Mill Road 2354 Chelmsford, MA 01824 USA 2355 Tel: +1 978 367 5600 2356 Fax: +1 978 367 5700 2358 Kamil Sarac 2359 Department of Computer Science (ES 4.207) 2360 Eric Jonsson School of Engineering & Computer Science 2361 University of Texas at Dallas 2362 Richardson, TX 75083-0688 USA 2363 Tel: +1 972 883 2337 2364 Fax: +1 972 883 2349 2365 Magnus Westerlund 2366 Ericsson Research, Corporate Unit 2367 Ericsson Radio Systems AB 2368 SE-164 80 Stockholm 2369 Sweden 2370 Tel: +46 8 404 82 87 2371 Fax: +46 8 757 55 50 2373 References 2375 The references are divided into normative references and non- 2376 normative references. 2378 Normative References 2380 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 2381 levels," BCP 14, RFC 2119, IETF, March 1997. 2383 [2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: 2384 ABNF", RFC 2234, Internet Engineering Task Force, November 1997. 2386 [3] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI 2387 TS 101 329-5 V1.1.1 (2000-11), November 2000. 2389 [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2390 2327, Internet Engineering Task Force, April 1998. 2392 [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF 2393 Standards Process," best current practice BCP 11, RFC 2028, IETF, 2394 October 1996. 2396 [6] ITU-T, "The E-Model, a computational model for use in 2397 transmission planning," Recommendation G.107 (05/00), May 2000. 2399 [7] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 2400 Considerations Section in RFCs," best current practice BCP 26, RFC 2401 2434, IETF, October 1998. 2403 [8] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 2404 Session Description Protocol (SDP)", RFC 3264, Internet Engineering 2405 Task Force, June 2002. 2407 [9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 2408 transport protocol for real-time applications," RFC 1889, IETF, 2409 February 1996. 2411 [10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice 2412 over IP and Voice over PCM Digital Wireline Telephones, December 2413 2000. 2415 Non-Normative References 2417 [11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. 2418 Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The 2419 Use of End-to-End Multicast Measurements for Characterizing Internal 2420 Network Behavior," IEEE Communications Magazine, May 2000. 2422 [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The 2423 Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt- 2424 srtp-05.txt, June 2002. Note: this is is a work in progress. 2426 [13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu 2427 measurement infrastructures using RTP," Proc. IEEE Infocom 2002. 2429 [14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and 2430 Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2431 2001. 2433 [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement 2434 Protocol", RFC 2974, Internet Engineering Task Force, October 2000. 2436 [16] J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by an On- 2437 line Database", RFC 3232, IETF, January 2002. 2439 [17] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming 2440 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 2441 1998. 2443 [18] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion 2444 Control Framework for Heterogeneous Multicast Environments", Proc. 2445 IWQoS 2000.