idnits 2.17.1 draft-ietf-avt-rtcp-report-extns-04.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 8 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: 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. -- 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 (16 April 2003) is 7680 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) == Unused Reference: '5' is defined on line 2318, 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 1700 (ref. '7') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1889 (ref. '10') (Obsoleted by RFC 3550) == Outdated reference: A later version (-09) exists of draft-ietf-avt-srtp-05 -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '16') (Obsoleted by RFC 7826) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 16 April 2003 3 Internet Engineering Task Force Expires: 16 October 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-04.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 ............................................... 6 61 2. XR Packet Format .......................................... 6 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 ............................................. 29 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 ......................................... 36 83 5.2 Usage in Offer/Answer ..................................... 39 84 5.3 Usage Outside of Offer/Answer ............................. 40 85 6. IANA Considerations ....................................... 41 86 6.1 XR Packet Type ............................................ 41 87 6.2 RTCP XR Block Type Registry ............................... 41 88 6.3 The "rtcp-xr" SDP Attribute ............................... 42 89 7. Security Considerations ................................... 43 90 A. Algorithms ................................................ 44 91 A.1 Sequence Number Interpretation ............................ 44 92 A.2 Example Burst Packet Loss Calculation ..................... 45 93 Intellectual Property ..................................... 47 94 Full Copyright Statement .................................. 48 95 Acknowledgments ........................................... 48 96 Contributors .............................................. 48 97 Authors' Addresses ........................................ 49 98 References ................................................ 51 99 Normative References ...................................... 51 100 Non-Normative References .................................. 52 102 1. Introduction 104 This document defines the Extended Report (XR) packet type for the 105 RTP Control Protocol (RTCP) [10], 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 [10, 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 [10, Section 6.4.3]. Nonetheless, they are not 185 of 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 conversational, 190 multicast or broadcast application for which the use of RTP and RTCP 191 is 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 196 conferencing, multicast and broadcast 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 [17]. 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 The SDP signaling defined for XR packets in this document (Section 5) 270 was done so with three use scenarios in mind: a Real Time Streaming 271 Protocol (RTSP) controlled streaming application, a one-to-many 272 multicast multimedia application such as a course lecture with 273 enhanced feedback, and a Session Initiation Protocol (SIP) controlled 274 conversational session involving two parties. Applications that 275 employ SDP are free to use additional SDP signaling for cases not 276 covered here. In addition, applications are free to use signaling 277 mechanisms other than SDP. 279 1.2 Terminology 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 283 document are to be interpreted as described in RFC 2119 [1] and 284 indicate requirement levels for compliance with this specification. 286 2. XR Packet Format 288 An XR packet consists of a header of two 32-bit words, followed by a 289 number, possibly zero, of extended report blocks. This type of 290 packet is laid out in a manner consistent with other RTCP packets, as 291 concerns the essential version, packet type, and length information. 292 XR packets are thus backwards compatibility with RTCP receiver 293 implementations that do not recognize them, but that ought to be able 294 to parse past them using the length information. A padding field and 295 an SSRC/CSRC field are also provided in the same locations that they 296 appear in other RTCP packets, for simplicity. The format is as 297 follows: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |V=2|P|reserved | PT=XR=207 | length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | SSRC/CSRC | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 : report blocks : 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 version (V): 2 bits 310 Identifies the version of RTP. This specification applies to 311 RTP version two. 313 padding (P): 1 bit 314 If the padding bit is set, this XR packet contains some 315 additional padding octets at the end. The semantics of this 316 field are identical to the semantics of the padding field in the 317 SR packet, as defined by the RTP specification. 319 reserved: 5 bits 320 This field is reserved for future definition. In the absence of 321 such definition, the bits in this field MUST be set to zero and 322 MUST be ignored by the receiver. 324 packet type (PT): 8 bits 325 Contains the constant 207 to identify this as an RTCP XR packet. 326 This value is registered with the Internet Assigned Numbers 327 Authority (IANA), as described in Section 5.1. 329 length: 16 bits 330 As described for the RTCP Sender Report (SR) packet (see Section 331 6.3.1 of the RTP specification [10]). Briefly, the length of 332 this XR packet in 32-bit words minus one, including the header 333 and any padding. 335 SSRC/CSRC: 32 bits 336 The synchronization source identifier for the originator of this 337 XR packet. 339 report blocks: variable length. 340 Zero or more extended report blocks. In keeping with the 341 extended report block framework defined below, each block MUST 342 consist of one or more 32-bit words. 344 3. Extended Report Block Framework 346 Extended report blocks are stacked, one after the other, at the end 347 of an XR packet. An individual block's length is a multiple of 4 348 octets. The XR header's length field describes the total length of 349 the packet, including these extended report blocks. 351 Each block has block type and length fields that facilitate parsing. 352 A receiving application can demultiplex the blocks based upon their 353 type, and can use the length information to locate each successive 354 block, even in the presence of block types it does not recognize. 356 An extended report block has the following format: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | BT | type-specific | block length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 : type-specific block contents : 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 block type (BT): 8 bits 367 Identifies the block format. Seven block types are defined in 368 Section 4. Additional block types may be defined in future 369 specifications. This field's name space is managed by the 370 Internet Assigned Numbers Authority (IANA), as described in 371 Section 5.2. 373 type-specific: 8 bits 374 The use of these bits is determined by the block type 375 definition. 377 block length: 16 bits 378 The length of this report block including the header, in 32-bit 379 words minus one. If the block type definition permits, zero is 380 an acceptable value, signifying a block that consists of only 381 the BT, type-specific, and block length fields, with a null 382 type-specific block contents field. 384 type-specific block contents: variable length 385 The use of this field is defined by the particular block type, 386 subject to the constraint that it MUST be a multiple of 32 bits 387 long. If the block type definition permits, It MAY be zero bits 388 long. 390 4. Extended Report Blocks 392 This section defines seven extended report blocks: block types for 393 reporting upon received packet losses and duplicates, packet 394 reception times, receiver reference time information, receiver inter- 395 report delays, detailed reception statistics, and voice over IP 396 (VoIP) metrics. An implementation SHOULD ignore incoming blocks with 397 types either not relevant or unknown to it. Additional block types 398 MUST be registered with the Internet Assigned Numbers Authority 399 (IANA) [7], as described in Section 5.2. 401 4.1 Loss RLE Report Block 403 This block type permits detailed reporting upon individual packet 404 receipt and loss events. Such reports can be used, for example, for 405 multicast inference of network characteristics (MINC) [11]. With 406 MINC, one can discover the topology of the multicast tree used for 407 distributing a source's RTP packets, and of the loss rates along 408 links within that tree. Or they could be used to provide raw data to 409 a network management application. 411 Since a Boolean trace of lost and received RTP packets is potentially 412 lengthy, this block type permits the trace to be compressed through 413 run length encoding. To further reduce block size, loss event 414 reports can be systematically dropped from the trace in a mechanism 415 called thinning that is described below and that is studied in [13]. 417 A participant that generates a Loss RLE Report Block should favor 418 accuracy in reporting on observed events over interpretation of those 419 events whenever possible. Interpretation should be left to those who 420 observe the report blocks. Following this approach implies that 421 accounting for Loss RLE Report Blocks will differ from the accounting 422 for the generation of the SR and RR packets described in the RTP 423 specification [10] in the following two areas: per-sender accounting 424 and per-packet accounting. 426 In its per-sender accounting, an RTP session participant SHOULD NOT 427 make the receipt of a threshold minimum number of RTP packets a 428 condition for reporting upon the sender of those packets. This 429 accounting technique differs from the technique described in Section 430 6.2.1 and Appendix A.1 of the RTP specification that allows a 431 threshold to determine whether a sender is considered valid. 433 In its per-packet accounting, an RTP session participant SHOULD treat 434 all sequence numbers as valid. This accounting technique differs 435 from the technique described in Appendix A.1 of the RTP specification 436 that suggests ruling a sequence number valid or invalid on the basis 437 of its contiguity with the sequence numbers of previously received 438 packets. 440 Sender validity and sequence number validity are interpretations of 441 the raw data. Such interpretations are justified in the interest, 442 for example, of excluding the stray old packet from an unrelated 443 session from having an effect upon the calculation of the RTCP 444 transmission interval. The presence of stray packets might, on the 445 other hand, be of interest to a network monitoring application. 447 One accounting interpretation that is still necessary is for a 448 participant to decide whether the 16 bit sequence number has rolled 449 over. Under ordinary circumstances this is not a difficult task. 450 For example, if packet number 65,535 (the highest possible sequence 451 number) is followed shortly by packet number 0, it is reasonable to 452 assume that there has been a rollover. However it is possible that 453 the packet is an earlier one (from 65,535 packets earlier). It is 454 also possible that the sequence numbers have rolled over multiple 455 times, either forward or backward. The interpretation becomes more 456 difficult when there are large gaps between the sequence numbers, 457 even accounting for rollover, and when there are long intervals 458 between received packets. 460 The per-packet accounting technique mandated here is for a 461 participant to keep track of the sequence number of the packet most 462 recently received from a sender. For the next packet that arrives 463 from that sender, the sequence number MUST be judged to fall no more 464 than 32,768 packets ahead or behind the most recent one, whichever 465 choice places it closer. In the event that both choices are equally 466 distant (only possible when the distance is 32,768), the choice MUST 467 be the one that does not require a rollover. Appendix A.1 presents 468 an algorithm that implements this technique. 470 Each block reports on a single RTP data packet source, identified by 471 its SSRC. The receiver that is supplying the report is identified in 472 the header of the RTCP packet. 474 Choice of beginning and ending RTP packet sequence numbers for the 475 trace is left to the application. These values are reported in the 476 block. The last sequence number in the trace MAY differ from the 477 sequence number reported on in any accompanying SR or RR report. 479 Note that because of sequence number wraparound the ending sequence 480 number MAY be less than the beginning sequence number. A Loss RLE 481 Report Block MUST NOT be used to report upon a range of 65,534 or 482 greater in the sequence number space, as there is no means to 483 identify multiple wraparounds. 485 The trace described by a Loss RLE report consists of a sequence of 486 Boolean values, one for each sequence number of the trace. A value 487 of one represents a packet receipt, meaning that one or more packets 488 having that sequence number have been received since the most recent 489 wraparound of sequence numbers (or since the beginning of the RTP 490 session if no wraparound has been judged to have occurred). A value 491 of zero represents a packet loss, meaning that there has been no 492 packet receipt for that sequence number as of the time of the report. 493 If a packet with a given sequence number is received after a report 494 of a loss for that sequence number, a later Loss RLE report MAY 495 report a packet receipt for that sequence number. 497 The encoding itself consists of a series of 16 bit units called 498 chunks that describe sequences of packet receipts or losses in the 499 trace. Each chunk either specifies a run length or a bit vector, or 500 is a null chunk. A run length describes between 1 and 16,383 events 501 that are all the same (either all receipts or all losses). A bit 502 vector describes 15 events that may be mixed receipts and losses. A 503 null chunk describes no events, and is used to round out the block to 504 a 32 bit word boundary. 506 The mapping from a sequence of lost and received packets into a 507 sequence of chunks is not necessarily unique. For example, the 508 following trace covers 45 packets, of which the 22nd and 24th have 509 been lost and the others received: 511 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 513 One way to encode this would be: 515 bit vector 1111 1111 1111 111 516 bit vector 1111 1101 0111 111 517 bit vector 1111 1111 1111 111 518 null chunk 520 Another way to encode this would be: 522 run of 21 receipts 523 bit vector 0101 1111 1111 111 524 run of 9 receipts 525 null chunk 527 The choice of encoding is left to the application. As part of this 528 freedom of choice, applications MAY terminate a series of run length 529 and bit vector chunks with a bit vector chunk that runs beyond the 530 sequence number space described by the report block. For example, if 531 the 44th packet in the same sequence were lost: 533 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 535 This could be encoded as: 537 run of 21 receipts 538 bit vector 0101 1111 1111 111 539 bit vector 1111 1110 1000 000 540 null chunk 542 In this example, the last five bits of the second bit vector describe 543 a part of the sequence number space that extends beyond the last 544 sequence number in the trace. These bits have been set to zero. 546 All bits in a bit vector chunk that describe a part of the sequence 547 number space that extends beyond the last sequence number in the 548 trace MUST be set to zero, and MUST be ignored by the receiver. 550 A null packet MUST appear at the end of a Loss RLE Report Block if 551 the number of run length plus bit vector chunks is odd. The null 552 chunk MUST NOT appear in any other context. 554 Caution should be used in sending Loss RLE Report Blocks because, 555 even with the compression provided by run length encoding, they can 556 easily consume bandwidth out of proportion with normal RTCP packets. 557 The block type includes a mechanism, called thinning, that allows an 558 application to limit report sizes. 560 A thinning value, T, selects a subset of packets within the sequence 561 number space: those with sequence numbers that are multiples of 2^T. 562 Packet reception and loss reports apply only to those packets. T can 563 vary between 0 and 15. If T is zero then every packet in the 564 sequence number space is reported upon. If T is fifteen then one in 565 every 32,768 packets is reported upon. 567 Suppose that the trace just described begins at sequence number 568 13,821. The last sequence number in the trace is 13,865. If the 569 trace were to be thinned with a thinning value of T=2, then the 570 following sequence numbers would be reported upon: 13,824, 13,828, 571 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 572 13,864. The thinned trace would be as follows: 574 1 1 1 1 1 0 1 1 1 1 0 576 This could be encoded as follows: 578 bit vector 1111 1011 1100 000 579 null chunk 581 The last four bits in the bit vector, representing sequence numbers 582 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are 583 thus set to zero and are ignored by the receiver. With thinning, the 584 loss of the 22nd packet goes unreported because its sequence number, 585 13,842, is not a multiple of four. Packet receipts for all sequence 586 numbers that are not multiples of four also go unreported. However, 587 in this example thinning has permitted the Loss RLE Report Block to 588 be shortened by one 32 bit word. 590 Choice of the thinning value is left to the application. 592 The Loss RLE Report Block has the following format: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | BT=1 | rsvd. | T | block length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | SSRC of source | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | begin_seq | end_seq | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | chunk 1 | chunk 2 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 : ... : 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | chunk n-1 | chunk n | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 block type (BT): 8 bits 611 A Loss RLE Report Block is identified by the constant 1. 613 rsvd.: 4 bits 614 This field is reserved for future definition. In the absence of 615 such definition, the bits in this field MUST be set to zero and 616 MUST be ignored by the receiver. 618 thinning (T): 4 bits 619 The amount of thinning performed on the sequence number space. 620 Only those packets with sequence numbers 0 mod 2^T are reported 621 on by this block. A value of 0 indicates that there is no 622 thinning, and all packets are reported on. The maximum thinning 623 is one packet in every 32,768 (amounting to two packets within 624 each 16-bit sequence space). 626 block length: 16 bits 627 Defined in Section 3. 629 SSRC of source: 32 bits 630 The SSRC of the RTP data packet source being reported upon by 631 this report block. 633 begin_seq: 16 bits 634 The first sequence number that this block reports on. 636 end_seq: 16 bits 637 The last sequence number that this block reports on plus one. 639 chunk i: 16 bits 640 There are three chunk types: run length, bit vector, and 641 terminating null, defined in the following sections. If the 642 chunk is all zeroes then it is a terminating null chunk. 643 Otherwise, the leftmost bit of the chunk determines its type: 0 644 for run length and 1 for bit vector. 646 4.1.1 Run Length Chunk 648 0 1 649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 |C|R| run length | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 chunk type (C): 1 bit 655 A zero identifies this as a run length chunk. 657 run type (R): 1 bit 658 Zero indicates a run of 0s. One indicates a run of 1s. 660 run length: 14 bits 661 A value between 1 and 16,383. The value MUST not be zero for a 662 run length chunk (zeroes in both the run type and run length 663 fields would make the chunk a terminating null chunk). Run 664 lengths of 15 or less MAY be described with a run length chunk 665 despite the fact that they could also be described as part of a 666 bit vector chunk. 668 4.1.2 Bit Vector Chunk 670 0 1 671 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 |C| bit vector | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 chunk type (C): 1 bit 677 A one identifies this as a bit vector chunk. 679 bit vector: 15 bits 680 The vector is read from left to right, in order of increasing 681 sequence number (with the appropriate allowance for wraparound). 683 4.1.3 Terminating Null Chunk 684 This chunk is all zeroes. 686 0 1 687 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 4.2 Duplicate RLE Report Block 694 This block type permits per-sequence-number reports on duplicates in 695 a source's RTP packet stream. Such information can be used for 696 network diagnosis, and provide an alternative to packet losses as a 697 basis for multicast tree topology inference. 699 The Duplicate RLE Report Block format is identical to the Loss RLE 700 Report Block format. Only the interpretation is different, in that 701 the information concerns packet duplicates rather than packet losses. 702 The trace to be encoded in this case also consists of zeros and ones, 703 but a zero here indicates the presence of duplicate packets for a 704 given sequence number, whereas a one indicates that no duplicates 705 were received. 707 The existence of a duplicate for a given sequence number is 708 determined over the entire reporting period. For example, if packet 709 number 12,593 arrives, followed by other packets with other sequence 710 numbers, the arrival later in the reporting period of another packet 711 numbered 12,593 counts as a duplicate for that sequence number. The 712 duplicate does not need to follow immediately upon the first packet 713 of that number. Care must be taken that a report does not cover a 714 range of 65,534 or greater in the sequence number space. 716 No distinction is made between the existence of a single duplicate 717 packet and multiple duplicate packets for a given sequence number. 718 Note also that since there is no duplicate for a lost packet, a loss 719 is encoded as a one in a Duplicate RLE Report Block. 721 The Duplicate RLE Report Block has the following format: 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | BT=2 | rsvd. | T | block length | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | SSRC of source | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | begin_seq | end_seq | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | chunk 1 | chunk 2 | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 : ... : 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | chunk n-1 | chunk n | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 block type (BT): 8 bits 740 A Duplicate RLE Report Block is identified by the constant 2. 742 rsvd.: 4 bits 743 This field is reserved for future definition. In the absence of 744 such definition, the bits in this field MUST be set to zero and 745 MUST be ignored by the receiver. 747 thinning (T): 4 bits 748 As defined in Section 4.1. 750 block length: 16 bits 751 Defined in Section 3. 753 SSRC of source: 32 bits 754 As defined in Section 4.1. 756 begin_seq: 16 bits 757 As defined in Section 4.1. 759 end_seq: 16 bits 760 As defined in Section 4.1. 762 chunk i: 16 bits 763 As defined in Section 4.1. 765 4.3 Packet Receipt Times Report Block 767 This block type permits per-sequence-number reports on packet receipt 768 times for a given source's RTP packet stream. Such information can 769 be used for MINC inference of the topology of the multicast tree used 770 to distribute the source's RTP packets, and of the delays along the 771 links within that tree. It can also be used to measure partial path 772 characteristics and to model distributions for packet jitter. 774 Packet receipt times are expressed in the same units as used in the 775 RTP timestamps of data packets. This is so that, for each packet, 776 one can establish both the send time and the receipt time in 777 comparable terms. Note, however, that as an RTP sender ordinarily 778 initializes its time to a value chosen at random, there can be no 779 expectation that reported send and receipt times will differ by an 780 amount equal to the one-way delay between sender and receiver. The 781 reported times can nonetheless be useful for the purposes mentioned 782 above. 784 At least one packet MUST have been received for each sequence number 785 reported upon in this block. If this block type is used to report 786 receipt times for a series of sequence numbers that includes lost 787 packets, several blocks are required. If duplicate packets have been 788 received for a given sequence number, and those packets differ in 789 their receipt times, any time other than the earliest MUST NOT be 790 reported. This is to ensure consistency among reports. 792 Times reported in RTP timestamp format consume more bits than loss or 793 duplicate information, and do not lend themselves to run length 794 encoding. The use of thinning is encouraged to limit the size of 795 Packet Receipt Times Report Blocks. 797 The Packet Receipt Times Report Block has the following format: 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | BT=3 | rsvd. | T | block length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | SSRC of source | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | begin_seq | end_seq | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Receipt time of packet begin_seq | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Receipt time of packet (begin_seq + 1) mod 65536 | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 : ... : 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Receipt time of packet (end_seq - 1) mod 65536 | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 block type (BT): 8 bits 818 A Packet Receipt Times Report Block is identified by the 819 constant 3. 821 rsvd.: 4 bits 822 This field is reserved for future definition. In the absence of 823 such definition, the bits in this field MUST be set to zero and 824 MUST be ignored by the receiver. 826 thinning (T): 4 bits 827 As defined in Section 4.1. 829 block length: 16 bits 830 Defined in Section 3. 832 SSRC of source: 32 bits 833 As defined in Section 4.1. 835 begin_seq: 16 bits 836 As defined in Section 4.1. 838 end_seq: 16 bits 839 As defined in Section 4.1. 841 Receipt time of packet i: 32 bits 842 The receipt time of the packet with sequence number i at the 843 receiver. The modular arithmetic shown in the packet format 844 diagram is to allow for sequence number rollover. It is 845 preferable for the time value to be established at the link 846 layer interface, or in any case as close as possible to the wire 847 arrival time. Units and format are the same as for the 848 timestamp in RTP data packets. As opposed to RTP data packet 849 timestamps, in which nominal values may be used instead of 850 system clock values in order to convey information useful for 851 periodic playout, the receipt times should reflect the actual 852 time as closely as possible. For a session, if the RTP 853 timestamp is chosen at random, the first receipt time value 854 SHOULD also be chosen at random, and subsequent timestamps 855 offset from this value. On the other hand, if the RTP timestamp 856 is meant to reflect the reference time at the sender, then the 857 receipt time SHOULD be as close as possible to the reference 858 time at the receiver. 860 4.4 Receiver Reference Time Report Block 862 This block extends RTCP's timestamp reporting so that non-senders may 863 also send timestamps. It recapitulates the NTP timestamp fields from 864 the RTCP Sender Report [10, Sec. 6.3.1]. A non-sender may estimate 865 its round trip time (RTT) to other participants, as proposed in [17], 866 by sending this report block and receiving DLRR Report Blocks (see 867 next section) in reply. 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | BT=4 | reserved | block length = 2 | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | NTP timestamp, most significant word | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | NTP timestamp, least significant word | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 block type (BT): 8 bits 880 A Receiver Reference Time Report Block is identified by the 881 constant 4. 883 reserved: 8 bits 884 This field is reserved for future definition. In the absence of 885 such definition, the bits in this field MUST be set to zero and 886 MUST be ignored by the receiver. 888 block length: 16 bits 889 The constant 2, in accordance with the definition of this field 890 in Section 3. 892 NTP timestamp: 64 bits 893 Indicates the wallclock time when this block was sent so that it 894 may be used in combination with timestamps returned in DLRR 895 Report Blocks (see next section) from other receivers to measure 896 round-trip propagation to those receivers. Receivers should 897 expect that the measurement accuracy of the timestamp may be 898 limited to far less than the resolution of the NTP timestamp. 899 The measurement uncertainty of the timestamp is not indicated as 900 it may not be known. A report block sender that can keep track 901 of elapsed time but has no notion of wallclock time may use the 902 elapsed time since joining the session instead. This is assumed 903 to be less than 68 years, so the high bit will be zero. It is 904 permissible to use the sampling clock to estimate elapsed 905 wallclock time. A report sender that has no notion of wallclock 906 or elapsed time may set the NTP timestamp to zero. 908 4.5 DLRR Report Block 910 This block extends RTCP's delay since last Sender Report (DLSR) 911 mechanism [10, Sec. 6.3.1] so that non-senders may also calculate 912 round trip times, as proposed in [17]. It is termed DLRR for delay 913 since last Receiver Report, and may be sent in response to a Receiver 914 Timestamp Report Block (see previous section) from a receiver to 915 allow that receiver to calculate its round trip time to the 916 respondent. The report consists of one or more 3 word sub-blocks: 917 one sub-block per Receiver Report. 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | BT=5 | reserved | block length | 923 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 924 | SSRC_1 (SSRC of first receiver) | sub- 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 926 | last RR (LRR) | 1 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | delay since last RR (DLRR) | 929 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 930 | SSRC_2 (SSRC of second receiver) | sub- 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 932 : ... : 2 933 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 935 block type (BT): 8 bits 936 A DLRR Report Block is identified by the constant 5. 938 reserved: 8 bits 939 This field is reserved for future definition. In the absence of 940 such definition, the bits in this field MUST be set to zero and 941 MUST be ignored by the receiver. 943 block length: 16 bits 944 Defined in Section 3. 946 last RR timestamp (LRR): 32 bits 947 The middle 32 bits out of 64 in the NTP timestamp (as explained 948 in the previous section) received as part of a Receiver 949 Reference Time Report Block from participant SSRC_n. If no such 950 block has been received, the field is set to zero. 952 delay since last RR (DLRR): 32 bits 953 The delay, expressed in units of 1/65536 seconds, between 954 receiving the last Receiver Reference Time Report Block from 955 participant SSRC_n and sending this DLRR Report Block. If no 956 Receiver Reference Time Report Block has been received yet from 957 SSRC_n, the DLRR field is set to zero (or the DLRR is omitted 958 entirely). Let SSRC_r denote the receiver issuing this DLRR 959 Report Block. Participant SSRC_n can compute the round-trip 960 propagation delay to SSRC_r by recording the time A when this 961 Receiver Timestamp Report Block is received. It calculates the 962 total round-trip time A-LSR using the last SR timestamp (LSR) 963 field, and then subtracting this field to leave the round-trip 964 propagation delay as A-LSR-DLSR. This is illustrated in [10, 965 Fig. 2]. 967 4.6 Statistics Summary Report Block 969 This block reports statistics beyond the information carried in the 970 standard RTCP packet format, but not as fine grained as that carried 971 in the report blocks previously described. Information is recorded 972 about lost packets, duplicate packets, jitter measurements, and TTL 973 or Hop Limit values. Such information can be useful for network 974 management. 976 The report block contents are dependent upon a series of flags bit 977 carried in the first part of the header. Not all parameters need to 978 be reported in each block. Flags indicate which are and which are 979 not reported. The fields corresponding to unreported parameters MUST 980 be set to zero. The receiver MUST ignore any Statistics Summary 981 Report Block with a non-zero value in any field flagged as 982 unreported. 984 The Statistics Summary Report Block has the following format: 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | BT=6 |L|D|J|ToH|rsvd.| block length = 9 | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | SSRC of source | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | begin_seq | end_seq | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | lost_packets | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | dup_packets | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | min_jitter | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | max_jitter | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | avg_jitter | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | dev_jitter | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | min_ttl_or_hl | max_ttl_or_hl | avg_ttl_or_hl | dev_ttl_or_hl | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 block type (BT): 8 bits 1011 A Statistics Summary Report Block is identified by the constant 1012 6. 1014 loss report flag (L): 1 bit 1015 Bit set to 1 if the lost_packets field contains a report, 0 1016 otherwise. 1018 duplicate report flag (D): 1 bit 1019 Bit set to 1 if the dup_packets field contains a report, 0 1020 otherwise. 1022 jitter flag (J): 1 bit 1023 Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and 1024 dev_jitter fields all contain reports, 0 if none of them do. 1026 TTL or Hop Limit flag (ToH): 2 bits 1027 This field is set to 0 if none of the fields min_ttl_or_hl, 1028 max_ttl_or_hl, avg_ttl_or_hl, or dev_ttl_or_hl contain reports. 1029 If the field is non-zero then all of these fields contain 1030 reports. The value 1 signifies that they report on IPv4 TTL 1031 values. The value 2 signifies that they report on IPv6 Hop 1032 Limit values. This value 3 is undefined and MUST NOT be used. 1034 rsvd.: 3 bits 1035 This field is reserved for future definition. In the absence of 1036 such definition, the bits in this field MUST be set to zero and 1037 MUST be ignored by the receiver. 1039 block length: 16 bits 1040 The constant 9, in accordance with the definition of this field 1041 in Section 3. 1043 SSRC of source: 32 bits 1044 As defined in Section 4.1. 1046 begin_seq: 16 bits 1047 As defined in Section 4.1. 1049 end_seq: 16 bits 1050 As defined in Section 4.1. 1052 lost_packets: 32 bits 1053 Number of lost packets in the above sequence number interval. 1055 dup_packets: 32 bits 1056 Number of duplicate packets in the above sequence number 1057 interval. 1059 min_jitter: 32 bits 1060 The minimum relative transit time between two packets in the 1061 above sequence number interval. All jitter values are measured 1062 as the difference between a packet's RTP timestamp and the 1063 reporter's clock at the time of arrival, measured in the same 1064 units. 1066 max_jitter: 32 bits 1067 The maximum relative transit time between two packets in the 1068 above sequence number interval. 1070 avg_jitter: 32 bits 1071 The average relative transit time between each two packet series 1072 in the above sequence number interval. 1074 dev_jitter: 32 bits 1075 The standard deviation of the relative transit time between each 1076 two packet series in the above sequence number interval. 1078 min_ttl_or_hl: 8 bits 1079 The minimum TTL or Hop Limit value of data packets in the 1080 sequence number range. 1082 max_ttl_or_hl: 8 bits 1083 The maximum TTL or Hop Limit value of data packets in the 1084 sequence number range. 1086 avg_ttl_or_hl: 8 bits 1087 The average TTL or Hop Limit value of data packets in the 1088 sequence number range. 1090 dev_ttl_or_hl: 8 bits 1091 The standard deviation of TTL or Hop Limit values of data 1092 packets in the sequence number range. 1094 4.7 VoIP Metrics Report Block 1096 The VoIP Metrics Report Block provides metrics for monitoring voice 1097 over IP (VoIP) calls. These metrics include packet loss and discard 1098 metrics, delay metrics, analog metrics, and voice quality metrics. 1099 The block reports separately on packets lost on the IP channel, and 1100 those that have been received but then discarded by the receiving 1101 jitter buffer. It also reports on the combined effect of losses and 1102 discards, as both have equal effect on call quality. 1104 In order to properly assess the quality of a Voice over IP call it is 1105 desirable to consider the degree of burstiness of packet loss [14]. 1106 Following a Gilbert-Elliott model [3], a period of time, bounded by 1107 lost and/or discarded packets, with a high rate of losses and/or 1108 discards is a "burst," and a period of time between two bursts is a 1109 "gap." Bursts correspond to periods of time during which the packet 1110 loss rate is high enough to produce noticeable degradation in audio 1111 quality. Gaps correspond to periods of time during which only 1112 isolated lost packets may occur, and in general these can be masked 1113 by packet loss concealment. Delay reports include the transit delay 1114 between RTCP end points and the VoIP end system processing delays, 1115 both of which contribute to the user perceived delay. Additional 1116 metrics include signal, echo, noise, and distortion levels. Call 1117 quality metrics include R factors (as described by the E Model 1118 defined in [3]) and mean opinion scores (MOS scores). 1120 Implementations MUST provide values for all the fields defined here. 1121 For certain metrics, if the value is undefined or unknown, then the 1122 specified default or unknown field value MUST be provided. 1124 The block is encoded as seven 32-bit words: 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | BT=7 | reserved | block length = 8 | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | SSRC of source | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | loss rate | discard rate | burst density | gap density | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | burst duration | gap duration | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | round trip delay | end system delay | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | signal level | noise level | RERL | Gmin | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | R factor | ext. R factor | MOS-LQ | MOS-CQ | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | RX config | reserved | JB nominal | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | JB maximum | JB abs max | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 block type (BT): 8 bits 1149 A VoIP Metrics Report Block is identified by the constant 7. 1151 reserved: 8 bits 1152 This field is reserved for future definition. In the absence of 1153 such definition, the bits in this field MUST be set to zero and 1154 MUST be ignored by the receiver. 1156 block length: 16 bits 1157 The constant 8, in accordance with the definition of this field 1158 in Section 3. 1160 SSRC of source: 32 bits 1161 As defined in Section 4.1. 1163 The remaining fields are described in the following six sections: 1164 Packet Loss and Discard Metrics, Delay Metrics, Signal Related 1165 Metrics, Call Quality or Transmission Quality Metrics, Configuration 1166 Metrics, and Jitter Buffer Parameters. 1168 4.7.1 Packet Loss and Discard Metrics 1170 It is very useful to distinguish between packets lost by the network 1171 and those discarded due to jitter. Both have equal effect on the 1172 quality of the voice stream however having separate counts helps 1173 identify the source of quality degradation. These fields MUST be 1174 populated. 1176 loss rate: 8 bits 1177 The fraction of RTP data packets from the source lost since the 1178 beginning of reception, expressed as a fixed point number with 1179 the binary point at the left edge of the field. This value is 1180 calculated by dividing the total number of packets lost (after 1181 the effects of applying any error protection such as FEC) by the 1182 total number of packets expected, multiplying the result of the 1183 division by 256, limiting the maximum value to 255 (to avoid 1184 overflow), and taking the integer part. The numbers of 1185 duplicated packets and discarded packets do not enter into this 1186 calculation. Since receivers cannot be required to maintain 1187 unlimited buffers, a receiver MAY categorize late-arriving 1188 packets as lost. The degree of lateness that triggers a loss 1189 SHOULD be significantly greater than that which triggers a 1190 discard. 1192 discard rate: 8 bits 1193 The fraction of RTP data packets from the source that have been 1194 discarded since the beginning of reception, due to late or early 1195 arrival, under-run or overflow at the receiving jitter buffer. 1196 This value is expressed as a fixed point number with the binary 1197 point at the left edge of the field. It is calculated by 1198 dividing the total number of packets discarded (excluding 1199 duplicate packet discards) by the total number of packets 1200 expected, multiplying the result of the division by 256, 1201 limiting the maximum value to 255 (to avoid overflow), and 1202 taking the integer part. 1204 4.7.2 Burst Metrics 1206 A burst, informally, is a period of high packet losses and/or 1207 discards. Formally, a burst is defined as a longest sequence of 1208 packets bounded by lost or discarded packets with the constraint that 1209 within a burst any sequence of successive packets that were received, 1210 and not discarded due to delay variation, is of length less than a 1211 value Gmin. 1213 A gap, informally, is a period of low packet losses and/or discards. 1214 Formally, a gap is defined as any of the following: (a) the period 1215 from the start of an RTP session to the receipt time of the last 1216 received packet before the first burst, (b) the period from the end 1217 of the last burst to either the time of the report or the end of the 1218 RTP session, whichever comes first, or (c) the period of time between 1219 two bursts. 1221 For the purpose of determining if a lost or discarded packet near the 1222 start or end of an RTP session is within a gap or a burst it is 1223 assumed that the RTP session is preceded and followed by at least 1224 Gmin received packets, and that the time of the report is followed by 1225 at least Gmin received packets. 1227 A gap has the property that any lost or discarded packets within the 1228 gap must be preceded and followed by at least Gmin packets that were 1229 received and not discarded. This gives a maximum loss/discard 1230 density within a gap of: 1 / (Gmin + 1). 1232 A Gmin value of 16 is RECOMMENDED as it results in gap 1233 characteristics that correspond to good quality (i.e. low packet loss 1234 rate, a minimum distance of 16 received packets between lost packets) 1235 and hence differentiates nicely between good and poor quality 1236 periods. 1238 For example, a 1 denotes a received, 0 a lost, and X a discarded 1239 packet in the following pattern covering 64 packets: 1241 11110111111111111111111X111X1011110111111111111111111X111111111 1242 |---------gap----------|--burst---|------------gap------------| 1244 The burst consists of the twelve packets indicated above, starting at 1245 a discarded packet and ending at a lost packet. The first gap starts 1246 at the beginning of the session and the second gap ends at the time 1247 of the report. 1249 If the packet spacing is 10 ms and the Gmin value is the recommended 1250 value of 16, the burst duration is 120 ms, the burst density 0.33, 1251 the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04. 1253 This would result in reported values as follows (see field 1254 descriptions for semantics and details on how these are calculated): 1256 loss density 12, which corresponds to 5% 1257 discard density 12, which corresponds to 5% 1258 burst density 84, which corresponds to 33% 1259 gap density 10, which corresponds to 4% 1260 burst duration 120, value in milliseconds 1261 gap duration 520, value in milliseconds 1263 burst density: 8 bits 1264 The fraction of RTP data packets within burst periods since the 1265 beginning of reception that were either lost or discarded. This 1266 value is expressed as a fixed point number with the binary point 1267 at the left edge of the field. It is calculated by dividing the 1268 total number of packets lost or discarded (excluding duplicate 1269 packet discards) within burst periods by the total number of 1270 packets expected within the burst periods, multiplying the 1271 result of the division by 256, limiting the maximum value to 255 1272 (to avoid overflow), and taking the integer part. 1274 gap density: 8 bits 1275 The fraction of RTP data packets within inter-burst gaps since 1276 the beginning of reception that were either lost or discarded. 1277 The value is expressed as a fixed point number with the binary 1278 point at the left edge of the field. It is calculated by 1279 dividing the total number of packets lost or discarded 1280 (excluding duplicate packet discards) within gap periods by the 1281 total number of packets expected within the gap periods, 1282 multiplying the result of the division by 256, limiting the 1283 maximum value to 255 (to avoid overflow), and taking the integer 1284 part. 1286 burst duration: 16 bits 1287 The mean duration, expressed in milliseconds, of the burst 1288 periods that have occurred since the beginning of reception. 1289 The duration of each period is calculated based upon the packets 1290 that mark the beginning and end of that period. It is equal to 1291 the timestamp of the end packet, plus the duration of the end 1292 packet, minus the timestamp of the beginning packet. If the 1293 actual values are not available, estimated values MUST be used. 1294 If there have been no burst periods, the burst duration value 1295 MUST be zero. 1297 gap duration: 16 bits 1298 The mean duration, expressed in milliseconds, of the gap periods 1299 that have occurred since the beginning of reception. The 1300 duration of each period is calculated based upon the packet that 1301 marks the end of the prior burst and the packet that marks the 1302 beginning of the subsequent burst. It is equal to the timestamp 1303 of the subsequent burst packet, minus the timestamp of the prior 1304 burst packet, plus the duration of the prior burst packet. If 1305 the actual values are not available, estimated values MUST be 1306 used. In the case of a gap that occurs at the beginning of 1307 reception, the sum of the timestamp of the prior burst packet 1308 and the duration of the prior burst packet are replaced by the 1309 reception start time. In the case of a gap that occurs at the 1310 end of reception, the timestamp of the subsequent burst packet 1311 is replaced by the reception end time. If there have been no 1312 gap periods, the gap duration value MUST be zero. 1314 4.7.3 Delay Metrics 1315 For the purpose of the following definitions, the RTP interface is 1316 the interface between the RTP instance and the voice application 1317 (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For 1318 example, the time delay due to RTP payload multiplexing would be 1319 considered to be part of the voice application or end-system delay 1320 whereas delay due to multiplexing RTP frames within a UDP frame would 1321 be considered part of the RTP reported delay. This distinction is 1322 consistent with the use of RTCP for delay measurements. 1324 round trip delay: 16 bits 1325 The most recently calculated round trip time between RTP 1326 interfaces, expressed in milliseconds. This value MAY be 1327 measured using RTCP, the DLRR method defined in Section 4.5 of 1328 this document or other approaches. If RTCP is used then the 1329 reported delay value is the time of receipt of the most recent 1330 RTCP packet from source SSRC, minus the LSR (last SR) time 1331 reported in its SR (Sender Report), minus the DLSR (delay since 1332 last SR) reported in its SR. A non-zero LSR value is required 1333 in order to calculate round trip delay. A value of 0 is 1334 permissible, however this field MUST be populated as soon as a 1335 delay estimate is available. 1337 end system delay: 16 bits 1338 The most recently estimated end system delay, expressed in 1339 milliseconds. End system delay is defined as the total 1340 encoding, decoding and jitter buffer delay determined at the 1341 reporting endpoint. This is the time required for an RTP frame 1342 to be buffered, decoded, converted to analog form, looped back 1343 at the local analog interface, encoded, and made available for 1344 transmission as an RTP frame. The manner in which this value is 1345 estimated is implementation dependent. This parameter MUST be 1346 provided in all VoIP metrics reports. 1348 Note that the one way symmetric VoIP segment delay may be calculated 1349 from the round trip and end system delays as follows. If the round 1350 trip delay is denoted RTD and the end system delays associated with 1351 the two endpoints are ESD(A) and ESD(B) then: 1353 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 1355 4.7.4 Signal Related Metrics 1357 The following metrics are intended to provide real time information 1358 related to the non-packet elements of the voice over IP system to 1359 assist with the identification of problems affecting call quality. 1360 The values identified below must be determined for the received audio 1361 signal. The information required to populate these fields may not be 1362 available in all systems, although it is strongly recommended that 1363 this data SHOULD be provided to support problem diagnosis. 1365 signal level: 8 bits 1366 The voice signal relative level is defined as the ratio of the 1367 signal level to a reference digital milliwatt, expressed in 1368 decibels as a signed integer in two's complement form. This is 1369 measured only for packets containing speech energy. The intent 1370 of this metric is not to provide a precise measurement of the 1371 signal level but to provide a real time indication that the 1372 signal level may be excessively high or low. 1374 signal level = 10 Log10 ( rms talkspurt power (mW) ) 1376 A value of 127 indicates that this parameter is unavailable. 1377 Typical values should be generally in the -15 to -20 dBm range. 1379 noise level: 8 bits 1380 The noise level is defined as the ratio of the silent period 1381 background noise level to a reference digital milliwatt, 1382 expressed in decibels as a signed integer in two's complement 1383 form. 1385 noise level = 10 Log10 ( rms silence power (mW) ) 1387 A value of 127 indicates that this parameter is unavailable. 1389 residual echo return loss (RERL): 8 bits 1390 The residual echo return loss is defined as the sum of the 1391 measured echo return loss (ERL) and the echo return loss 1392 enhancement (ERLE) expressed in dB as a signed integer in two's 1393 complement form. It defines the ratio of a transmitted voice 1394 signal that is reflected back to the talker. A low level of 1395 echo return loss (say less than 20 dB) in conjunction with some 1396 delay can lead to hollowness or audible echo. A high level of 1397 echo return loss (say over 40 dB) is preferable. 1399 The ERL and ERLE parameters are often available directly from the 1400 echo canceler contained within the VoIP end system. They relate to 1401 the echo on the external network attached to the end point. 1403 In the case of a VoIP gateway this would be line echo that typically 1404 occurs at 2-4 wire conversion points in the network. Echo return 1405 loss from typical 2-4 wire conversions can be in the 8-12 dB range. 1406 A line echo canceler can provide an ERLE of 30 dB or more and hence 1407 reduce this to 40-50 dB. In the case of an IP phone this could be 1408 residual acoustic echo from speakerphone operation, and may more 1409 correctly be termed terminal coupling loss (TCL). A typical handset 1410 would result in 40-50 dB of echo due to acoustic feedback. 1412 Typical values for RERL are as follows: 1414 (i) IP gateway connected to circuit switched network with 2 wire loop 1415 Without echo cancellation, typical 2-4 wire converter ERL of 12 dB 1416 RERL = ERL + ERLE = 12 + 0 = 12 dB 1418 (ii) IP gateway connected to circuit switched network with 2 wire loop 1419 With echo canceler that improves echo by 30 dB 1420 RERL = ERL + ERLE = 12 + 30 = 42 dB 1422 (iii) IP phone with conventional handset 1423 Acoustic coupling from handset speaker to microphone 40 dB 1424 Residual echo return loss = TCL = 40 dB 1426 If we denote the "local" end of the VoIP path as A and the remote end 1427 as B and if the sender loudness rating (SLR) and receiver loudness 1428 rating (RLR) are known for A (default values 8 dB and 2 dB 1429 respectively), then the echo loudness level at end A (talker echo 1430 loudness rating or TELR) is given by: 1432 TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A) 1434 TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B) 1436 Hence in order to incorporate echo into a voice quality estimate at 1437 the A end of a VoIP connection it is desirable to send the ERL + ERLE 1438 value from B to A. 1440 For an IP phone with handset this metric MUST be set to the designed 1441 or measured terminal coupling loss, which would typically be 40-50 1442 dB. 1444 For a PC softphone or speakerphone this metric MUST be set to either 1445 the value reported by the acoustic echo canceler or to 127 to 1446 indicate an undefined value. 1448 For an IP gateway with ERL and ERLE measurements this metric MUST be 1449 reported as ERL + ERLE. 1451 For an IP gateway without ERL and ERLE measurement capability then 1452 this metric MUST be reported as 12 dB if line echo cancellation is 1453 disabled and 40 dB if line echo cancellation is enabled. 1455 Gmin 1456 See Configuration Parameters (Section 4.7.6, below). 1458 4.7.5 Call Quality or Transmission Quality Metrics 1460 The following metrics are direct measures of the call quality or 1461 transmission quality, and incorporate the effects of codec type, 1462 packet loss, discard, burstiness, delay etc. These metrics may not 1463 be available in all systems however SHOULD be provided in order to 1464 support problem diagnosis. 1466 R factor: 8 bits 1467 The R factor is a voice quality metric describing the segment of 1468 the call that is carried over this RTP session. It is expressed 1469 as an integer in the range 0 to 100, with a value of 94 1470 corresponding to "toll quality" and values of 50 or less 1471 regarded as unusable. This metric is defined as including the 1472 effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 1473 101 329-5 [3]. 1475 A value of 127 indicates that this parameter is unavailable. 1477 ext. R factor: 8 bits 1478 The external R factor is a voice quality metric describing the 1479 segment of the call that is carried over a network segment 1480 external to the RTP segment, for example a cellular network. Its 1481 values are interpreted in the same manner as for the RTP R 1482 factor. This metric is defined as including the effects of 1483 delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 1484 [3], and relates to the outward voice path from the Voice over 1485 IP termination for which this metrics block applies. 1487 A value of 127 indicates that this parameter is unavailable. 1489 Note that an overall R factor may be estimated from the RTP segment R 1490 factor and the external R factor, as follows: 1492 R total = RTP R factor + ext. R factor - 94 1494 MOS-LQ: 8 bits 1495 The estimated mean opinion score for listening quality (MOS-LQ) 1496 is a voice quality metric on a scale from 1 to 5, in which 5 1497 represents excellent and 1 represents unacceptable. This metric 1498 is defined as not including the effects of delay and can be 1499 compared to MOS scores obtained from listening quality (ACR) 1500 tests. It is expressed as an integer in the range 10 to 50, 1501 corresponding to MOS x 10. For example, a value of 35 would 1502 correspond to an estimated MOS score of 3.5. 1504 A value of 127 indicates that this parameter is unavailable. 1506 MOS-CQ: 8 bits 1507 The estimated mean opinion score for conversational quality 1508 (MOS-CQ) is defined as including the effects of delay and other 1509 effects that would affect conversational quality. The metric 1510 may be calculated by converting an R factor determined according 1511 to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated 1512 MOS using the equation specified in G.107. It is expressed as 1513 an integer in the range 10 to 50, corresponding to MOS x 10, as 1514 for MOS-LQ. 1516 A value of 127 indicates that this parameter is unavailable. 1518 4.7.6 Configuration Parameters 1520 Gmin: 8 bits 1521 The gap threshold. This field contains the value used for this 1522 report block to determine if a gap exists. The recommended 1523 value of 16 corresponds to a burst period having a minimum 1524 density of 6.25% of lost or discarded packets, which may cause 1525 noticeable degradation in call quality; during gap periods, if 1526 packet loss or discard occurs, each lost or discarded packet 1527 would be preceded by and followed by a sequence of at least 16 1528 received non-discarded packets. Note that lost or discarded 1529 packets that occur within Gmin packets of a report being 1530 generated may be reclassified as being part of a burst or gap in 1531 later reports. ETSI TS 101 329-5 [3] defines a computationally 1532 efficient algorithm for measuring burst and gap density using a 1533 packet loss/discard event driven approach. This algorithm is 1534 reproduced in Appendix A.2 of the present document. Gmin MUST 1535 not be zero and MUST be provided. 1537 receiver configuration byte (RX config): 8 bits 1538 This byte consists of the following fields: 1540 0 1 2 3 4 5 6 7 1541 +-+-+-+-+-+-+-+-+ 1542 |PLC|JBA|JB rate| 1543 +-+-+-+-+-+-+-+-+ 1545 packet loss concealment (PLC): 2 bits 1546 Standard (11) / enhanced (10) / disabled (01) / unspecified 1547 (00). When PLC = 11 then a simple replay or interpolation 1548 algorithm is being used to fill-in the missing packet. 1549 This is typically able to conceal isolated lost packets 1550 with loss rates under 3%. When PLC = 10 then an enhanced 1551 interpolation algorithm is being used. This would 1552 typically be able to conceal lost packets for loss rates of 1553 10% or more. When PLC = 01 then silence is inserted in 1554 place of lost packets. When PLC = 00 then no information 1555 is available concerning the use of PLC however for some 1556 codecs this may be inferred. 1558 jitter buffer adaptive (JBA): 2 bits 1559 Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown 1560 (00). When the jitter buffer is adaptive then its size is 1561 being dynamically adjusted to deal with varying levels of 1562 jitter. When non-adaptive, the jitter buffer size is 1563 maintained at a fixed level. When either adaptive or non- 1564 adaptive modes are specified then the jitter buffer size 1565 parameters below MUST be specified. 1567 jitter buffer rate (JB rate): 4 bits 1568 J = adjustment rate (0-15). This represents the 1569 implementation specific adjustment rate of a jitter buffer 1570 in adaptive mode. This parameter is defined in terms of the 1571 approximate time taken to fully adjust to a step change in 1572 peak to peak jitter from 30 ms to 100 ms such that: 1574 adjustment time = 2 * J * frame size (ms) 1576 This parameter is intended only to provide a guide to the 1577 degree of "aggressiveness" of a an adaptive jitter buffer 1578 and may be estimated. A value of 0 indicates that the 1579 adjustment time is unknown for this implementation. 1581 reserved: 8 bits 1582 This field is reserved for future definition. In the absence of 1583 such definition, the bits in this field MUST be set to zero and 1584 MUST be ignored by the receiver. 1586 4.7.7 Jitter Buffer Parameters 1588 jitter buffer nominal delay (JB nominal): 16 bits 1589 This is the current nominal jitter buffer delay in milliseconds, 1590 which corresponds to the nominal jitter buffer delay for packets 1591 that arrive exactly on time. This parameter MUST be provided 1592 for both fixed and adaptive jitter buffer implementations. 1594 jitter buffer maximum delay (JB maximum): 16 bits 1595 This is the current maximum jitter buffer delay corresponding to 1596 the earliest arriving packet that would not be discarded. In 1597 simple queue implementations this may correspond to the nominal 1598 size. In adaptive jitter buffer implementations this value may 1599 dynamically vary up to JB abs max (see below). This parameter 1600 MUST be provided for both fixed and adaptive jitter buffer 1601 implementations. 1603 jitter buffer absolute maximum delay (JB abs max): 16 bits 1604 This is the absolute maximum delay that the adaptive jitter 1605 buffer can reach under worst case jitter conditions. This 1606 parameter MUST be provided for adaptive jitter buffer 1607 implementations and its value MUST be set to JB maximum for 1608 fixed jitter buffer implementations. 1610 5. SDP Signaling 1612 This section defines Session Description Protocol (SDP) [4] signaling 1613 for XR blocks that can be employed by applications that utilize SDP. 1614 This signaling is defined to be used either by applications that 1615 implement the SDP Offer/Answer model [9] or by applications that use 1616 SDP to describe media and transport configurations in connection with 1617 such protocols as the Session Announcement Protocol (SAP) [15] or the 1618 Real Time Streaming Protocol (RTSP) [16]. There exist other 1619 potential signaling methods, which are not defined here. 1621 The XR blocks MAY be used without prior signaling. This is 1622 consistent with the rules governing other RTCP packet types, as 1623 described in [10]. An example in which signaling would not be used 1624 is an application that always requires the use of one or more XR 1625 blocks. However for applications that are configured at session 1626 initiation, the use of some type of signaling is recommended. 1628 Note that, although the use of SDP signaling for XR blocks may be 1629 optional, if used it MUST be used as defined here. If SDP signaling 1630 is used in an environment where XR blocks are only implemented by 1631 some fraction of the participants, the ones not implementing the XR 1632 blocks will ignore the SDP attribute. 1634 5.1 The SDP Attribute 1636 This section defines one new SDP attribute "rtcp-xr" that can be used 1637 to signal participants in a media session that they should use the 1638 specified XR blocks. This attribute can be easily extended in the 1639 future with new parameters to cover any new report blocks. 1641 The RTCP XR blocks SDP attribute is defined below in Augmented 1642 Backus-Naur Form (ABNF) [2]. It is both a session and a media level 1643 attribute. When specified at session level, it applies to all media 1644 level blocks in the session. Any media level specification MUST 1645 replace a session level specification, if one is present, for that 1646 media block. 1648 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 1650 xr-format = pkt-loss-rle 1651 / pkt-dup-rle 1652 / pkt-rcpt-times 1653 / rcvr-rtt 1654 / stat-summary 1655 / voip-metrics 1656 / format-ext 1658 pkt-loss-rle = "pkt-loss-rle" ["=" max-size] 1659 pkt-dup-rle = "pkt-dup-rle" ["=" max-size] 1660 pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size] 1661 rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size] 1662 stat-summary = "stat-summary" 1663 voip-metrics = "voip-metrics" 1664 max-size = 1*DIGIT ; maximum block size in octets 1665 rcvr-rtt-mode = "all" 1666 / "sender" 1667 format-ext = non-ws-string 1669 non-ws-string = 1*(%x21-FF) 1671 The "rtcp-xr" attribute contains zero, one, or more XR block related 1672 parameters. Each parameter signals functionality for an XR block, or 1673 a group of XR blocks. The attribute is extensible so that parameters 1674 can be defined for any future XR block (and a parameter should be 1675 defined for every future block). 1677 Each "rtcp-xr" parameter belongs to one of two categories. The first 1678 category, the unilateral parameters, are for report blocks that 1679 simply report on the RTP stream and related metrics. The second 1680 category, collaborative parameters, are for XR blocks that involve 1681 actions by more than one party in order to carry out their functions. 1683 Round trip time (RTT) measurement is an example of collaborative 1684 functionality. An RTP data packet receiver sends a Receiver 1685 Reference Time Report Block (Section 4.4). A participant that 1686 receives this block sends a DLRR Report Block (Section 4.5) in 1687 response, allowing the receiver to calculate its RTT to that 1688 participant. As this example illustrates, collaborative 1689 functionality may be implemented by two or more different XR blocks. 1690 The collaborative functionality of several XR blocks may be governed 1691 by a single "rtcp-xr" parameter. 1693 For the unilateral category, this document defines the following 1694 parameters. The parameter names and their corresponding XR formats 1695 are as follows: 1697 Parameter name XR block (block type and name) 1698 -------------- ------------------------------------ 1699 pkt-loss-rle 1 Loss RLE Report Block 1700 pkt-dup-rle 2 Duplicate RLE Report Block 1701 pkt-rcpt-times 3 Packet Receipt Times Report Block 1702 stat-summary 6 Statistics Summary Report Block 1703 voip-metrics 7 VoIP Metrics Report Block 1705 The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters 1706 MAY specify an integer value. This value indicates the largest size 1707 the whole report block SHOULD have in octets. This shall be seen as 1708 an indication that thinning shall be applied if necessary to meet the 1709 target size. 1711 Blocks in the collaborative category are classified as initiator 1712 blocks or response blocks. Signaling SHOULD indicate which 1713 participants are required to respond to the initiator block. A party 1714 that wishes to receive response blocks from those participants can 1715 trigger this by sending an initiator block. 1717 The collaborative category currently consists only of one 1718 functionality, namely the RTT measurement mechanism for RTP data 1719 receivers. The collective functionality of the Receiver Reference 1720 Time Report Block and DLRR Report Block is represented by the "rcvr- 1721 rtt" parameter. This parameter takes as its arguments a mode value 1722 and, optionally, a maximum size for the DLRR report block. The mode 1723 value "all" indicates that both RTP data senders and data receivers 1724 MAY send DLRR blocks, while the mode value "sender" indicates that 1725 only active RTP senders MAY send DLRR blocks, i.e. non RTP senders 1726 SHALL NOT send DLRR blocks. If a maximum size in octets is included, 1727 any DLRR Report Blocks that are sent SHALL NOT exceed the specified 1728 size. If size limitations mean that a DLRR Report Block sender 1729 cannot report in one block upon all participants from which it has 1730 received a Receiver Reference Time Report Block then it SHOULD report 1731 on participants in a round robin fashion across several report 1732 intervals. 1734 The "rtcp-xr" attributes parameter list MAY be empty. This is useful 1735 in cases in which an application needs to signal that it understands 1736 the SDP signaling but does not wish to avail itself of XR 1737 functionality. For example, an application in a SIP controlled 1738 session could signal that it wishes to stop using all XR blocks by 1739 removing all applicable SDP parameters in a re-INVITE message that it 1740 sends. If XR blocks are not to be used at all from the beginning of 1741 a session, it is RECOMMENDED that the "rtcp-xr" attribute not be 1742 supplied at all. 1744 When the "rtcp-xr" attribute is present, participants SHOULD NOT send 1745 XR blocks other than the ones indicated by the parameters. This 1746 means that inclusion of a "rtcp-xr" attribute without any parameters 1747 tells a participant that it SHOULD NOT send any XR blocks at all. 1748 The purpose is to conserve bandwidth. This is especially important 1749 when collaborative parameters are applied to a large multicast group: 1750 the sending of an initiator block could potentially trigger responses 1751 from all participants. There are, however, contexts in which it 1752 makes sense to send an XR block in the absence of a parameter 1753 signaling its use. For instance, an application might be designed so 1754 as to send certain report blocks without negotiation, while using SDP 1755 signaling to negotiate the use of other blocks. 1757 5.2 Usage in Offer/Answer 1759 In the Offer/Answer context [9], the interpretation of SDP signaling 1760 for XR packets depends upon the direction attribute that is signaled: 1761 "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute 1762 is supplied then "sendrecv" is assumed. This section applies only to 1763 unicast media streams, except where noted. Discussion of unilateral 1764 parameters is followed by discussion of collaborative parameters in 1765 this section. 1767 For "sendonly" and "sendrecv" media stream offers that specify 1768 unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send 1769 the corresponding XR blocks. For "sendrecv" offers, the answerer MAY 1770 include the "rtcp-xr" attribute in its response, and specify any 1771 unilateral parameters in order to request that the offerer send the 1772 corresponding XR blocks. The offerer SHOULD send these blocks. 1774 For "recvonly" media stream offers, the offerer's use of the "rtcp- 1775 xr" attribute in connection with unilateral parameters indicates that 1776 the offerer is capable of sending the corresponding XR blocks. If 1777 the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD 1778 send XR blocks for each specified unilateral parameter that was in 1779 its offer. 1781 For multicast media streams, the inclusion of an "rtcp-xr" attribute 1782 with unilateral parameters means that every media recipient SHOULD 1783 send the corresponding XR blocks. 1785 An SDP offer with a collaborative parameter declares the offerer 1786 capable of receiving the corresponding initiator and replying with 1787 the appropriate responses. For example, an offer that specifies the 1788 "rcvr-rtt" parameter means that the offerer is prepared to receive 1789 Receiver Reference Time Report Blocks and to send DLRR Report Blocks. 1790 An offer of a collaborative parameter means that the answerer MAY 1791 send the initiator, and, having received the initiator, the offerer 1792 SHOULD send the responses. 1794 There are exceptions to the rule that an offerer of a collaborative 1795 parameter should send responses. For instance, the collaborative 1796 parameter might specify a mode that excludes the offerer. Or 1797 congestion control or maximum transmission unit considerations might 1798 militate against the offerer's response. 1800 By including a collaborative parameter in its answer, the answerer 1801 declares its ability to receive initiators and to send responses. 1802 The offerer MAY then send initiators, to which the answerer SHOULD 1803 reply with responses. As for the offer of a collaborative parameter, 1804 there are exceptions to the rule that the answerer should reply. 1806 When making an SDP offer of a collaborative parameter for a multicast 1807 media stream, the offerer SHOULD specify which participants are to 1808 respond to a received initiator. A participant that is not specified 1809 SHOULD NOT send responses. Otherwise, undue bandwidth might be 1810 consumed. The offer indicates that each participant that is 1811 specified SHOULD respond if it receives an initiator. It also 1812 indicates that a specified participant MAY send an initiator block. 1814 An SDP answer for a multicast media stream SHOULD include all 1815 collaborative parameters that are present in the offer and that are 1816 supported by the answerer. It SHOULD NOT include any collaborative 1817 parameter that is absent from the offer. 1819 If a participant receives an SDP offer and understands the "rtcp-xr" 1820 attribute but does not wish to implement XR functionality offered, 1821 its answer SHOULD include an "rtcp-xr" attribute without parameters. 1822 By doing so, the party declares that at a minimum that it is capable 1823 of understanding the signaling. 1825 5.3 Usage Outside of Offer/Answer 1827 SDP can be employed outside of the Offer/Answer context, for instance 1828 for multimedia sessions that are announced through the Session 1829 Announcement Protocol (SAP) [15], or streamed through the Real Time 1830 Streaming Protocol (RTSP) [16]. The signaling model is simpler, as 1831 the sender does not negotiate parameters, but the functionality that 1832 is expected from specifying the "rtcp-xr" attribute is the same as in 1833 Offer/Answer. 1835 When a unilateral parameter is specified for the "rtcp-xr" attribute 1836 associated with a media stream, the receiver of that stream SHOULD 1837 send the corresponding XR block. When a collaborative parameter is 1838 specified, only the participants indicated by the mode value in the 1839 collaborative parameter are concerned. Each such participant that 1840 receives an initiator block SHOULD send the corresponding response 1841 block. Each such participant MAY also send initiator blocks. 1843 6. IANA Considerations 1845 This document defines a new RTCP packet type, the Extended Report 1846 (XR) type, within the existing Internet Assigned Numbers Authority 1847 (IANA) registry of RTP RTCP Control Packet Types. This document also 1848 defines a new IANA registry: the registry of RTCP XR Block Types. 1849 Within this new registry, this document defines an initial set of 1850 seven block types and describes how the remaining types are to be 1851 allocated. 1853 Further, this document defines a new SDP attribute, "rtcp-xr", within 1854 the existing IANA registry of SDP Parameters. It defines a new IANA 1855 registry, the registry of RTCP XR SDP Parameters, and an initial set 1856 of six parameters, and describes how additional parameters are to be 1857 allocated. 1859 6.1 XR Packet Type 1861 The XR packet type defined by this document is registered with the 1862 IANA as packet type 207 in the registry of RTP RTCP Control Packet 1863 types (PT). 1865 6.2 RTCP XR Block Type Registry 1867 This document creates an IANA registry called the RTCP XR Block Type 1868 Registry to cover the name space of the Extended Report block type 1869 (BT) field specified in Section 3. The BT field contains eight bits, 1870 allowing 256 values. The RTCP XR Block Type Registry is to be 1871 managed by the IANA according to the Specification Required policy of 1872 RFC 2434 [8]. Future specifications SHOULD attribute block type 1873 values in strict numeric order following the values attributed in 1874 this document: 1876 BT name 1877 -- ---- 1878 1 Loss RLE Report Block 1879 2 Duplicate RLE Report Block 1880 3 Packet Receipt Times Report Block 1881 4 Receiver Reference Time Report Block 1882 5 DLRR Report Block 1883 6 Statistics Summary Report Block 1884 7 VoIP Metrics Report Block 1886 The BT value 255 is reserved for future extensions. 1888 Furthermore, future specifications SHOULD avoid the value 0. Doing 1889 so facilitates packet validity checking, since an all-zeros field 1890 might commonly be found in an ill-formed packet. 1892 6.3 The "rtcp-xr" SDP Attribute 1894 This SDP attribute "rtcp-xr" defined by this document is registered 1895 with the IANA registry of SDP Parameters as follows: 1897 SDP Attribute ("att-field"): 1899 Attribute name: rtcp-xr 1900 Long form: RTP Control Protocol Extended Report Parameters 1901 Type of name: att-field 1902 Type of attribute: session and media level 1903 Subject to charset: no 1904 Purpose: see Section 5 of this document 1905 Reference: this document 1906 Values: see this document and registrations below 1908 The attribute has an extensible parameter field and therefore a 1909 registry for these parameters is required. This document creates an 1910 IANA registry called the RTCP XR SDP Parameters Registry. It 1911 contains the six parameters defined in Section 5.1: "pkt-loss-rle", 1912 "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and 1913 "recv-rtt". 1915 Additional parameters are to be added to this registry in accordance 1916 with the Specification Required policy of RFC 2434 [8]. Any 1917 registration MUST contain the following information: 1919 - Contact information of the one doing the registration, including at 1920 least name, address, and email. 1922 - An Augmented Backus-Naur Form (ABNF) [2] definition of the 1923 parameter, in accordance with the "format-ext" definition. 1925 - A description of what the parameter represents and how it shall be 1926 interpreted, both normally and in Offer/Answer. 1928 7. Security Considerations 1930 This document extends the RTCP reporting mechanism. The security 1931 considerations that apply to RTCP reports also apply to XR reports. 1932 This section details the additional security considerations that 1933 apply to the extensions. 1935 The extensions introduce heightened confidentiality concerns. 1936 Standard RTCP reports contain a limited number of summary statistics. 1937 The information contained in XR reports is both more detailed and 1938 more extensive (covering a larger number of parameters). The per- 1939 packet report blocks and the VoIP Metrics Report Block provide 1940 examples. 1942 The per-packet information contained in Loss RLE, Duplicate RLE, and 1943 Packet Receipt Times Report Blocks facilitates multicast inference of 1944 network characteristics (MINC) [11]. Such inference can reveal the 1945 gross topology of a multicast distribution tree, as well as 1946 parameters, such as the loss rates and delays, along paths between 1947 branching points in that tree. Such information might be considered 1948 sensitive to autonomous system administrators. 1950 The VoIP Metrics Report Block provides information on the quality of 1951 ongoing voice calls. Though such information might be carried in 1952 application specific format in standard RTP sessions, making it 1953 available in a standard format here makes it more available to 1954 potential eavesdroppers. 1956 No new mechanisms are introduced in this document to ensure 1957 confidentiality. Encryption procedures, such as those being 1958 suggested for a Secure RTCP (SRTCP) [12] at the time that this 1959 document was written, can be used when confidentiality is a concern 1960 to end hosts. Given that RTCP traffic can be encrypted by the end 1961 hosts, autonomous systems must be prepared for the fact that certain 1962 aspects of their network topology can be revealed. 1964 Any encryption or filtering of XR report blocks entails a loss of 1965 monitoring information to third parties. For example, a network that 1966 establishes a tunnel to encrypt VoIP Report Blocks denies that 1967 information to the service providers traversed by the tunnel. The 1968 service providers cannot then monitor or respond to the quality of 1969 the VoIP calls that they carry, potentially creating problems for the 1970 network's users. As a default, XR packets SHOULD NOT be encrypted or 1971 filtered. 1973 The extensions also make certain denial of service attacks easier. 1974 This is because of the potential to create RTCP packets much larger 1975 than average with the per packet reporting capabilities of the Loss 1976 RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the 1977 automatic bandwidth adjustment mechanisms in RTCP, if some session 1978 participants are sending large RTCP packets, all participants will 1979 see their RTCP reporting intervals lengthened, meaning they will be 1980 able to report less frequently. To limit the effects of large 1981 packets, even in the absence of denial of service attacks, 1982 applications SHOULD place an upper limit on the size of the XR report 1983 blocks they employ. The "thinning" techniques described in Section 1984 4.1 permit the packet-by-packet report blocks to adhere to a 1985 predefined size limit. 1987 A. Algorithms 1989 A.1 Sequence Number Interpretation 1991 This the algorithm suggested by Section 4.1 for keeping track of the 1992 sequence numbers from a given sender. It implements the accounting 1993 practice required for the generation of Loss RLE Report Blocks. 1995 This algorithm keeps track of 16 bit sequence numbers by translating 1996 them into a 32 bit sequence number space. The first packet received 1997 from a source is considered to have arrived roughly in the middle of 1998 that space. Each packet that follows is placed either ahead or 1999 behind the prior one in this 32 bit space, depending upon which 2000 choice would place it closer (or, in the event of a tie, which choice 2001 would not require a rollover in the 16 bit sequence number). 2003 // The reference sequence number is an extended sequence number 2004 // that serves as the basis for determining whether a new 16 bit 2005 // sequence number comes earlier or later in the 32 bit sequence 2006 // space. 2007 u_int32 _src_ref_seq; 2008 bool _uninitialized_src_ref_seq; 2010 // Place seq into a 32-bit sequence number space based upon a 2011 // heuristic for its most likely location. 2012 u_int32 extend_seq(const u_int16 seq) { 2014 u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; 2015 if(_uninitialized_src_ref_seq) { 2017 // This is the first sequence number received. Place 2018 // it in the middle of the extended sequence number 2019 // space. 2020 _src_ref_seq = seq | 0x80000000u; 2021 _uninitialized_src_ref_seq = false; 2022 extended_seq = _src_ref_seq; 2023 } 2024 else { 2026 // Prior sequence numbers have been received. 2027 // Propose two candidates for the extended sequence 2028 // number: seq_a is without wraparound, seq_b with 2029 // wraparound. 2030 seq_a = seq | (_src_ref_seq & 0xFFFF0000u); 2031 if(_src_ref_seq < seq_a) { 2032 seq_b = seq_a - 0x00010000u; 2033 diff_a = seq_a - _src_ref_seq; 2034 diff_b = _src_ref_seq - seq_b; 2035 } 2036 else { 2037 seq_b = seq_a + 0x00010000u; 2038 diff_a = _src_ref_seq - seq_a; 2039 diff_b = seq_b - _src_ref_seq; 2040 } 2042 // Choose the closer candidate. If they are equally 2043 // close, the choice is somewhat arbitrary: we choose 2044 // the candidate for which no rollover is necessary. 2045 if(diff_a < diff_b) { 2046 extended_seq = seq_a; 2047 } 2048 else { 2049 extended_seq = seq_b; 2050 } 2052 // Set the reference sequence number to be this most 2053 // recently-received sequence number. 2054 _src_ref_seq = extended_seq; 2055 } 2057 // Return our best guess for a 32-bit sequence number that 2058 // corresponds to the 16-bit number we were given. 2059 return extended_seq; 2060 } 2062 A.2 Example Burst Packet Loss Calculation. 2064 This is an algorithm for measuring the burst characteristics for the 2065 VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI 2066 TS 101 329-5 [3]. The algorithm is event driven and hence extremely 2067 computationally efficient. 2069 Given the following definition of states: 2071 state 1 = received a packet during a gap 2072 state 2 = received a packet during a burst 2073 state 3 = lost a packet during a burst 2074 state 4 = lost an isolated packet during a gap 2076 The "c" variables below correspond to state transition counts, i.e. 2077 c14 is the transition from state 1 to state 4. It is possible to 2078 infer one of a pair of state transition counts to an accuracy of 1 2079 which is generally sufficient for this application. 2081 "pkt" is the count of packets received since the last packet was 2082 declared lost or discarded and "lost" is the number of packets lost 2083 within the current burst. "packet_lost" and "packet_discarded" are 2084 Boolean variables that indicate if the event that resulted in this 2085 function being invoked was a lost or discarded packet. 2087 if(packet_lost) { 2088 loss_count++; 2089 } 2090 if(packet_discarded) { 2091 discard_count++; 2092 } 2093 if(!packet_lost && !packet_discarded) { 2094 pkt++; 2095 } 2096 else { 2097 if(pkt >= gmin) { 2098 if(lost == 1) { 2099 c14++; 2100 } 2101 else { 2102 c13++; 2103 } 2104 lost = 1; 2105 c11 += pkt; 2106 } 2107 else { 2108 lost++; 2109 if(pkt == 0) { 2110 c33++; 2111 } 2112 else { 2113 c23++; 2114 c22 += (pkt - 1); 2115 } 2116 } 2117 pkt = 0; 2118 } 2120 At each reporting interval the burst and gap metrics can be 2121 calculated as follows. 2123 // Calculate additional transition counts. 2124 c31 = c13; 2125 c32 = c23; 2126 ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; 2128 // Calculate burst and densities. 2129 p32 = c32 / (c31 + c32 + c33); 2130 if((c22 + c23) < 1) { 2131 p23 = 1; 2132 } 2133 else { 2134 p23 = 1 - c22/(c22 + c23); 2135 } 2136 burst_density = 256 * p23 / (p23 + p32); 2137 gap_density = 256 * c14 / (c11 + c14); 2139 // Calculate burst and gap durations in ms 2140 m = frameDuration_in_ms * framesPerRTPPkt; 2141 gap_length = (c11 + c14 + c13) * m / c13; 2142 burst_length = ctotal * m / c13 - lgap; 2144 /* calculate loss and discard densities */ 2145 loss_density = 256 * loss_count / ctotal; 2146 discard_density = 256 * discard_count / ctotal; 2148 Intellectual Property 2150 The IETF takes no position regarding the validity or scope of any 2151 intellectual property or other rights that might be claimed to 2152 pertain to the implementation or use of the technology described in 2153 this document or the extent to which any license under such rights 2154 might or might not be available; neither does it represent that it 2155 has made any effort to identify any such rights. Information on the 2156 IETF's procedures with respect to rights in standards-track and 2157 standards-related documentation can be found in BCP 11 [5]. Copies 2158 of claims of rights made available for publication and any assurances 2159 of licenses to be made available, or the result of an attempt made to 2160 obtain a general license or permission for the use of such 2161 proprietary rights by implementors or users of this specification can 2162 be obtained from the IETF Secretariat. 2164 The IETF invites any interested party to bring to its attention any 2165 copyrights, patents or patent applications, or other proprietary 2166 rights which may cover technology that may be required to practice 2167 this standard. Please address the information to the IETF Executive 2168 Director. 2170 Full Copyright Statement 2172 Copyright (C) The Internet Society (2003). All Rights Reserved. 2174 This document and translations of it may be copied and furnished to 2175 others, and derivative works that comment on or otherwise explain it 2176 or assist in its implementation may be prepared, copied, published 2177 and distributed, in whole or in part, without restriction of any 2178 kind, provided that the above copyright notice and this paragraph are 2179 included on all such copies and derivative works. However, this 2180 document itself may not be modified in any way, such as by removing 2181 the copyright notice or references to the Internet Society or other 2182 Internet organizations, except as needed for the purpose of 2183 developing Internet standards in which case the procedures for 2184 copyrights defined in the Internet Standards process must be 2185 followed, or as required to translate it into languages other than 2186 English. 2188 The limited permissions granted above are perpetual and will not be 2189 revoked by the Internet Society or its successors or assigns. 2191 This document and the information contained herein is provided on an 2192 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2193 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2194 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2195 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2196 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2198 Acknowledgments 2200 We thank the following people: Colin Perkins, Steve Casner, and 2201 Henning Schulzrinne for their considered guidance; Sue Moon for 2202 helping foster collaboration between the authors; Mounir Benzaid for 2203 drawing our attention to the reporting needs of MLDA; Dorgham Sisalem 2204 and Adam Wolisz for encouraging us to incorporate MLDA block types; 2205 and Jose Rey for valuable review of the SDP Signaling section. 2207 Contributors 2208 The following people are the authors of this document: 2210 Kevin Almeroth, UCSB 2211 Ramon Caceres, ShieldIP 2212 Alan Clark, Telchemy 2213 Robert Cole, AT&T Labs 2214 Nick Duffield, AT&T Labs-Research 2215 Timur Friedman, Paris 6 2216 Kaynam Hedayat, Brix Networks 2217 Kamil Sarac, UT Dallas 2218 Magnus Westerlund, Ericsson 2220 The principal people to contact regarding the individual report 2221 blocks described in this document are as follows: 2223 sec. report block principal contributors 2224 ---- ------------ ---------------------- 2225 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 2226 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 2227 4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield 2228 4.4 Receiver Reference Time Report Block Friedman 2229 4.5 DLRR Report Block Friedman 2230 4.6 Statistics Summary Report Block Almeroth, Sarac 2231 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat 2233 The principal person to contact regarding the SDP signaling described 2234 in this document is Magnus Westerlund. 2236 Authors' Addresses 2238 Kevin Almeroth 2239 Department of Computer Science 2240 University of California 2241 Santa Barbara, CA 93106 USA 2243 Ramon Caceres 2244 ShieldIP, Inc. 2245 11 West 42nd Street, 31st Floor 2246 New York, NY 10036 USA 2247 Alan Clark 2248 Telchemy Incorporated 2249 3360 Martins Farm Road, Suite 200 2250 Suwanee, GA 30024 USA 2251 Tel: +1 770 614 6944 2252 Fax: +1 770 614 3951 2254 Robert Cole 2255 AT&T Labs 2256 330 Saint Johns Street, 2257 2nd Floor 2258 Havre de Grace, MD 21078 USA 2259 Tel: +1 410 939 8732 2260 Fax: +1 410 939 8732 2262 Nick Duffield 2263 AT&T Labs-Research 2264 180 Park Avenue, P.O. Box 971 2265 Florham Park, NJ 07932-0971 USA 2266 Tel: +1 973 360 8726 2267 Fax: +1 973 360 8050 2269 Timur Friedman 2270 Universite Pierre et Marie Curie (Paris 6) 2271 Laboratoire LiP6-CNRS 2272 8, rue du Capitaine Scott 2273 75015 PARIS France 2274 Tel: +33 1 44 27 71 06 2275 Fax: +33 1 44 27 74 95 2277 Kaynam Hedayat 2278 Brix Networks 2279 285 Mill Road 2280 Chelmsford, MA 01824 USA 2281 Tel: +1 978 367 5600 2282 Fax: +1 978 367 5700 2284 Kamil Sarac 2285 Department of Computer Science (ES 4.207) 2286 Eric Jonsson School of Engineering & Computer Science 2287 University of Texas at Dallas 2288 Richardson, TX 75083-0688 USA 2289 Tel: +1 972 883 2337 2290 Fax: +1 972 883 2349 2291 Magnus Westerlund 2292 Ericsson Research, Corporate Unit 2293 Ericsson Radio Systems AB 2294 SE-164 80 Stockholm 2295 Sweden 2296 Tel: +46 8 404 82 87 2297 Fax: +46 8 757 55 50 2299 References 2301 The references are divided into normative references and non- 2302 normative references. 2304 Normative References 2306 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 2307 levels," BCP 14, RFC 2119, IETF, March 1997. 2309 [2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: 2310 ABNF", RFC 2234, Internet Engineering Task Force, November 1997. 2312 [3] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI 2313 TS 101 329-5 V1.1.1 (2000-11), November 2000. 2315 [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2316 2327, Internet Engineering Task Force, April 1998. 2318 [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF 2319 Standards Process," best current practice BCP 11, RFC 2028, IETF, 2320 October 1996. 2322 [6] ITU-T, "The E-Model, a computational model for use in 2323 transmission planning," Recommendation G.107 (05/00), May 2000. 2325 [7] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, 2326 RFC 1700, IETF, October 1994. 2328 [8] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 2329 Considerations Section in RFCs," best current practice BCP 26, RFC 2330 2434, IETF, October 1998. 2332 [9] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the 2333 Session Description Protocol (SDP)", RFC 3264, Internet Engineering 2334 Task Force, June 2002. 2336 [10] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 2337 A transport protocol for real-time applications," RFC 1889, IETF, 2338 February 1996. 2340 Non-Normative References 2342 [11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. 2343 Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The 2344 Use of End-to-End Multicast Measurements for Characterizing Internal 2345 Network Behavior," IEEE Communications Magazine, May 2000. 2347 [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The 2348 Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt- 2349 srtp-05.txt, June 2002. Note: this is is a work in progress. 2351 [13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu 2352 measurement infrastructures using RTP," Proc. IEEE Infocom 2002. 2354 [14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and 2355 Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2356 2001. 2358 [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement 2359 Protocol", RFC 2974, Internet Engineering Task Force, October 2000. 2361 [16] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming 2362 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 2363 1998. 2365 [17] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion 2366 Control Framework for Heterogeneous Multicast Environments", Proc. 2367 IWQoS 2000.