idnits 2.17.1 draft-ietf-avt-rtcp-report-extns-03.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 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 [2] 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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: '3' is defined on line 1825, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2028 (ref. '3') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1889 (ref. '7') (Obsoleted by RFC 3550) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Expires: 2 September 2003 2 Audio/Video Transport Working Group 4 Timur Friedman, Paris 6 5 Ramon Caceres, ShieldIP 6 Alan Clark, Telchemy 7 Editors 9 RTP Extended Reports (RTP XR) 11 draft-ietf-avt-rtcp-report-extns-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines the extended report (XR) packet type for the 41 RTP control protocol (RTCP). XR packets are composed of report 42 blocks, and seven block types are defined here. The purpose of the 43 extended reporting format is to convey information that supplements 44 the six statistics that are contained in the report blocks used by 45 RTCP's sender report (SR) and receiver report (RR) packets. Some 46 applications, such as multicast inference of network characteristics 47 (MINC) or voice over IP (VoIP) monitoring, require other and more 48 detailed statistics. In addition to the block types defined here, 49 additional block types may be defined in the future by adhering to 50 the framework that this document provides. 52 Table of Contents 54 1. Introduction .............................................. 2 55 1.1 Terminology ............................................... 3 56 2. XR Packet Format .......................................... 4 57 3. Extended Report Block Framework ........................... 5 58 4. Extended Report Blocks .................................... 6 59 4.1 Loss RLE Report Block ..................................... 6 60 4.1.1 Run Length Chunk .......................................... 12 61 4.1.2 Bit Vector Chunk .......................................... 12 62 4.1.3 Terminating Null Chunk .................................... 12 63 4.2 Duplicate RLE Report Block ................................ 13 64 4.3 Timestamp Report Block .................................... 14 65 4.4 Statistics Summary Report Block ........................... 16 66 4.5 Receiver Timestamp Report Block ........................... 19 67 4.6 DLRR Report Block ......................................... 20 68 4.7 VoIP Metrics Report Block ................................. 21 69 4.7.1 Packet Loss and Discard Metrics ........................... 22 70 4.7.2 Burst Metrics ............................................. 23 71 4.7.3 Delay Metrics ............................................. 25 72 4.7.4 Signal Related Metrics .................................... 26 73 4.7.5 Call Quality or Transmission Quality Metrics .............. 29 74 4.7.6 Configuration Parameters .................................. 30 75 4.7.7 Jitter Buffer Parameters .................................. 31 76 5. IANA Considerations ....................................... 32 77 5.1 XR Packet Type ............................................ 32 78 5.2 RTP XR Block Type Registry ................................ 32 79 6. Security Considerations ................................... 33 80 A. Algorithms ................................................ 34 81 A.1 Sequence Number Interpretation ............................ 34 82 A.2 Example Burst Packet Loss Calculation ..................... 35 83 Intellectual Property ..................................... 37 84 Full Copyright Statement .................................. 37 85 Acknowledgments ........................................... 38 86 Contributors .............................................. 38 87 Authors' Addresses ........................................ 39 88 References ................................................ 40 89 Normative References ...................................... 40 90 Non-Normative References .................................. 41 92 1. Introduction 94 This document defines the extended report (XR) packet type for the 95 RTP control protocol (RTCP) [7]. XR packets convey information 96 beyond that already contained in the reception report blocks of 97 RTCP's sender report (SR) or receiver report (RR) packets. The 98 information is of use across RTP profiles, and so is not 99 appropriately carried in SR or RR profile-specific extensions. 100 Information used for network management falls into this category, for 101 instance. 103 The definition is broken out over the three following sections of 104 this document, starting with a general framework and finishing with 105 the specific information conveyed. The framework defined by Section 106 2 contains common header information followed by a series of 107 components called report blocks. Section 3 defines the format common 108 to such blocks. Section 4 defines seven block types. 110 Seven report block formats are defined by this document: 112 - Loss RLE Report Block (Section 4.1): Run length encoding of RTP 113 packet loss reports. 115 - Duplicate RLE Report Block (Section 4.2): Run length encoding of 116 reports of RTP packet duplicates. 118 - Timestamp Report Block (Section 4.3): A list of timestamps of 119 received RTP packets. 121 - Statistics Summary Report Block (Section 4.4): Statistics on RTP 122 packet sequence numbers, losses, duplicates, jitter, and TTL values. 124 - Receiver Timestamp Report Block (Section 4.5): Receiver-end 125 timestamps that complement the sender-end timestamps already defined 126 for RTCP. 128 - DLRR Report Block (Section 4.6): The delay since the last Receiver 129 Timestamp Report Block was received, allowing non-senders to 130 calculate round-trip times. 132 - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring 133 Voice over IP (VoIP) calls. 135 These blocks are defined within a minimal framework: a type field and 136 a length field are common to all XR blocks. The purpose is to 137 maintain flexibility and to keep overhead low. Other block formats, 138 beyond the seven defined here, may be defined within this framework 139 as the need arises. 141 1.1 Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [1] and 145 indicate requirement levels for compliance with this specification. 147 2. XR Packet Format 149 The XR packet consists of a header of two 32-bit words, followed by a 150 number, possibly zero, of extended report blocks. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |V=2|P|reserved | PT=XP=207 | length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | SSRC/CSRC | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 : report blocks : 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 version (V): 2 bits 163 Identifies the version of RTP. This specification applies to 164 RTP version two. 166 padding (P): 1 bit 167 If the padding bit is set, this XR packet contains some 168 additional padding octets at the end. The semantics of this 169 field are identical to the semantics of the padding field in the 170 SR packet, as defined by the RTP specification. 172 reserved: 5 bits 173 This field is reserved for future definition. In the absence of 174 such definition, the bits in this field MUST be set to zero and 175 MUST be ignored by the receiver. 177 packet type (PT): 8 bits 178 Contains the constant 207 to identify this as an RTCP XR packet. 179 This value is registered with the Internet Assigned Numbers 180 Authority (IANA), as described in Section 5.1. 182 length: 16 bits 183 As described for the RTP sender report (SR) packet (see Section 184 6.3.1 of the RTP specification [7]). Briefly, the length of 185 this XR packet in 32-bit words minus one, including the header 186 and any padding. 188 SSRC: 32 bits 189 The synchronization source identifier for the originator of this 190 XR packet. 192 report blocks: variable length. 193 Zero or more extended report blocks. In keeping with the 194 extended report block framework defined below, each block MUST 195 consist of one or more 32-bit words. 197 3. Extended Report Block Framework 199 Extended report blocks are stacked, one after the other, at the end 200 of an XR packet. An individual block's length is a multiple of 4 201 octets. The XR header's length field describes the total length of 202 the packet, including these extended report blocks. 204 Each block has block type and length fields that facilitate parsing. 205 A receiving application can demultiplex the blocks based upon their 206 type, and can use the length information to locate each successive 207 block, even in the presence of block types it does not recognize. 209 An extended report block has the following format: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | BT | type-specific | block length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 : type-specific data : 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 block type (BT): 8 bits 220 Identifies the block format. Seven block types are defined in 221 Section 4. Additional block types may be defined in future 222 specifications. This field's name space is managed by the 223 Internet Assigned Numbers Authority (IANA), as described in 224 Section 5.2. 226 type-specific: 8 bits 227 The use of these bits is determined by the block type 228 definition. 230 block length: 16 bits 231 The length of this report block including the header, in 32-bit 232 words minus one. If the block type definition permits, zero is 233 an acceptable value, signifying a block that consists of only 234 the BT, type-specific, and block length fields, with a null 235 type-specific data field. 237 type-specific data: variable length 238 The use of this field is defined by the particular block type, 239 subject to the constraint that it MUST be a multiple of 32 bits 240 long. If the block type definition permits, It MAY be zero bits 241 long. 243 4. Extended Report Blocks 245 This section defines seven extended report blocks: block types for 246 losses, duplicates, packet reception timestamps, detailed reception 247 statistics, receiver timestamps, receiver inter-report delays, and 248 voice over IP (VoIP) metrics. An implementation SHOULD ignore 249 incoming blocks with types either not relevant or unknown to it. 250 Additional block types MUST be registered with the Internet Assigned 251 Numbers Authority (IANA) [5], as described in Section 5.2. 253 4.1 Loss RLE Report Block 255 This block type permits detailed reporting upon individual packet 256 receipt and loss events. Such reports can be used, for example, for 257 multicast inference of network characteristics (MINC) [8]. With 258 MINC, one can discover the topology of the multicast tree used for 259 distributing a source's RTP packets, and of the loss rates along 260 links within that tree. Or they could be used to provide raw data to 261 a network management application. 263 Since a Boolean trace of lost and received RTP packets is potentially 264 lengthy, this block type permits the trace to be compressed through 265 run length encoding. To further reduce block size, loss event 266 reports can be systematically dropped from the trace in a mechanism 267 called thinning that is described below and that is studied in [9]. 269 A participant that generates a Loss RLE Report Block should favor 270 accuracy in reporting on observed events over interpretation of those 271 events whenever possible. Interpretation should be left to those who 272 observe the report blocks. Following this approach implies that 273 accounting for Loss RLE Report Blocks will differ from the accounting 274 for the generation of the SR and RR packets described in the RTP 275 specification [7] in the following two areas: per-sender accounting 276 and per-packet accounting. 278 In its per-sender accounting, an RTP session participant SHOULD NOT 279 make the receipt of a threshold minimum number of RTP packets a 280 condition for reporting upon the sender of those packets. This 281 accounting technique differs from the technique described in Section 282 6.2.1 and Appendix A.1 of the RTP specification that allows a 283 threshold to determine whether a sender is considered valid. 285 In its per-packet accounting, an RTP session participant SHOULD treat 286 all sequence numbers as valid. This accounting technique differs 287 from the technique described in Appendix A.1 of the RTP specification 288 that suggests ruling a sequence number valid or invalid on the basis 289 of its contiguity with the sequence numbers of previously received 290 packets. 292 Sender validity and sequence number validity are interpretations of 293 the raw data. Such interpretations are justified in the interest, 294 for example, of excluding the stray old packet from an unrelated 295 session from having an effect upon the calculation of the RTCP 296 transmission interval. The presence of stray packets might, on the 297 other hand, be of interest to a network monitoring application. 299 One accounting interpretation that is still necessary is for a 300 participant to decide whether the 16 bit sequence number has rolled 301 over. Under ordinary circumstances this is not a difficult task. 302 For example, if packet number 65,535 (the highest possible sequence 303 number) is followed shortly by packet number 0, it is reasonable to 304 assume that there has been a rollover. However it is possible that 305 the packet is an earlier one (from 65,535 packets earlier). It is 306 also possible that the sequence numbers have rolled over multiple 307 times, either forward or backward. The interpretation becomes more 308 difficult when there are large gaps between the sequence numbers, 309 even accounting for rollover, and when there are long intervals 310 between received packets. 312 The per-packet accounting technique mandated here is for a 313 participant to keep track of the sequence number of the packet most 314 recently received from a sender. For the next packet that arrives 315 from that sender, the sequence number MUST be judged to fall no more 316 than 32,768 packets ahead or behind the most recent one, whichever 317 choice places it closer. In the event that both choices are equally 318 distant (only possible when the distance is 32,768), the choice MUST 319 be the one that does not require a rollover. Appendix A.1 presents 320 an algorithm that implements this technique. 322 Each block reports on a single source, identified by its SSRC. The 323 receiver that is supplying the report is identified in the header of 324 the RTCP packet. 326 Choice of beginning and ending RTP packet sequence numbers for the 327 trace is left to the application. These values are reported in the 328 block. The last sequence number in the trace MAY differ from the 329 sequence number reported on in any accompanying SR or RR report. 331 Note that because of sequence number wraparound the ending sequence 332 number MAY be less than the beginning sequence number. A Loss RLE 333 Report Block MUST NOT be used to report upon a range of 65,534 or 334 greater in the sequence number space, as there is no means to 335 identify multiple wraparounds. 337 The trace described by a Loss RLE report consists of a sequence of 338 Boolean values, one for each sequence number of the trace. A value 339 of one represents a packet receipt, meaning that one or more packets 340 having that sequence number have been received since the most recent 341 wraparound of sequence numbers (or since the beginning of the RTP 342 session if no wraparound has been judged to have occurred). A value 343 of zero represents a packet loss, meaning that there has been no 344 packet receipt for that sequence number as of the time of the report. 345 If a packet with a given sequence number is received after a report 346 of a loss for that sequence number, a later Loss RLE report MAY 347 report a packet receipt for that sequence number. 349 The encoding itself consists of a series of 16 bit units called 350 chunks that describe sequences of packet receipts or losses in the 351 trace. Each chunk either specifies a run length or a bit vector, or 352 is a null chunk. A run length describes between 1 and 16,383 events 353 that are all the same (either all receipts or all losses). A bit 354 vector describes 15 events that may be mixed receipts and losses. A 355 null chunk describes no events, and is used to round out the block to 356 a 32 bit word boundary. 358 The mapping from a sequence of lost and received packets into a 359 sequence of chunks is not necessarily unique. For example, the 360 following trace covers 45 packets, of which the 22nd and 24th have 361 been lost and the others received: 363 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 365 One way to encode this would be: 367 bit vector 1111 1111 1111 111 368 bit vector 1111 1101 0111 111 369 bit vector 1111 1111 1111 111 370 null chunk 372 Another way to encode this would be: 374 run of 21 receipts 375 bit vector 0101 1111 1111 111 376 run of 9 receipts 377 null chunk 379 The choice of encoding is left to the application. As part of this 380 freedom of choice, applications MAY terminate a series of run length 381 and bit vector chunks with a bit vector chunk that runs beyond the 382 sequence number space described by the report block. For example, if 383 the 44th packet in the same sequence were lost: 385 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 387 This could be encoded as: 389 run of 21 receipts 390 bit vector 0101 1111 1111 111 391 bit vector 1111 1110 1000 000 392 null chunk 394 In this example, the last five bits of the second bit vector describe 395 a part of the sequence number space that extends beyond the last 396 sequence number in the trace. These bits have been set to zero. 398 All bits in a bit vector chunk that describe a part of the sequence 399 number space that extends beyond the last sequence number in the 400 trace MUST be set to zero, and MUST be ignored by the receiver. 402 A null packet MUST appear at the end of a Loss RLE Report Block if 403 the number of run length plus bit vector chunks is odd. The null 404 chunk MUST NOT appear in any other context. 406 Caution should be used in sending Loss RLE Report Blocks because, 407 even with the compression provided by run length encoding, they can 408 easily consume bandwidth out of proportion with normal RTCP packets. 409 The block type includes a mechanism, called thinning, that allows an 410 application to limit report sizes. 412 A thinning value, T, selects a subset of packets within the sequence 413 number space: those with sequence numbers that are multiples of 2^T. 414 Packet reception and loss reports apply only to those packets. T can 415 vary between 0 and 15. If T is zero then every packet in the 416 sequence number space is reported upon. If T is fifteen then one in 417 every 32,768 packets is reported upon. 419 Suppose that the trace just described begins at sequence number 420 13,821. The last sequence number in the trace is 13,865. If the 421 trace were to be thinned with a thinning value of T=2, then the 422 following sequence numbers would be reported upon: 13,824, 13,828, 423 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 424 13,864. The thinned trace would be as follows: 426 1 1 1 1 1 0 1 1 1 1 0 428 This could be encoded as follows: 430 bit vector 1111 1011 1100 000 431 null chunk 433 The last four bits in the bit vector, representing sequence numbers 434 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are 435 thus set to zero and are ignored by the receiver. With thinning, the 436 loss of the 22nd packet goes unreported because its sequence number, 437 13,842, is not a multiple of four. Packet receipts for all sequence 438 numbers that are not multiples of four also go unreported. However, 439 in this example thinning has permitted the Loss RLE Report Block to 440 be shortened by one 32 bit word. 442 Choice of the thinning value is left to the application. 444 The Loss RLE Report Block has the following format: 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | BT=1 | rsvd. | T | block length | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | SSRC of source | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | begin_seq | end_seq | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | chunk 1 | chunk 2 | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 : ... : 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | chunk n-1 | chunk n | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 block type (BT): 8 bits 463 A Loss RLE Report Block is identified by the constant 1. 465 rsvd.: 4 bits 466 This field is reserved for future definition. In the absence of 467 such definition, the bits in this field MUST be set to zero and 468 MUST be ignored by the receiver. 470 thinning (T): 4 bits 471 The amount of thinning performed on the sequence number space. 472 Only those packets with sequence numbers 0 mod 2^T are reported 473 on by this block. A value of 0 indicates that there is no 474 thinning, and all packets are reported on. The maximum thinning 475 is one packet in every 32,768 (amounting to two packets within 476 each 16-bit sequence space). 478 block length: 16 bits 479 Defined in Section 3. 481 begin_seq: 16 bits 482 The first sequence number that this block reports on. 484 end_seq: 16 bits 485 The last sequence number that this block reports on plus one. 487 chunk i: 16 bits 488 There are three chunk types: run length, bit vector, and 489 terminating null, defined in the following sections. If the 490 chunk is all zeroes then it is a terminating null chunk. 491 Otherwise, the leftmost bit of the chunk determines its type: 0 492 for run length and 1 for bit vector. 494 4.1.1 Run Length Chunk 496 0 1 497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |C|R| run length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 chunk type (C): 1 bit 503 A zero identifies this as a run length chunk. 505 run type (R): 1 bit 506 Zero indicates a run of 0s. One indicates a run of 1s. 508 run length: 14 bits 509 A value between 1 and 16,383. The value MUST not be zero for a 510 run length chunk (zeroes in both the run type and run length 511 fields would make the chunk a terminating null chunk). Run 512 lengths of 15 or less MAY be described with a run length chunk 513 despite the fact that they could also be described as part of a 514 bit vector chunk. 516 4.1.2 Bit Vector Chunk 518 0 1 519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |C| bit vector | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 chunk type (C): 1 bit 525 A one identifies this as a bit vector chunk. 527 bit vector: 15 bits 528 The vector is read from left to right, in order of increasing 529 sequence number (with the appropriate allowance for wraparound). 531 4.1.3 Terminating Null Chunk 533 This chunk is all zeroes. 535 0 1 536 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 4.2 Duplicate RLE Report Block 543 This block type permits per-sequence-number reports on duplicates in 544 a source's RTP packet stream. Such information can be used for 545 network diagnosis, and provide an alternative to packet losses as a 546 basis for multicast tree topology inference. 548 The Duplicate RLE Report Block format is identical to the Loss RLE 549 Report Block format. Only the interpretation is different, in that 550 the information concerns packet duplicates rather than packet losses. 551 The trace to be encoded in this case also consists of zeros and ones, 552 but a zero here indicates the presence of duplicate packets for a 553 given sequence number, whereas a one indicates that no duplicates 554 were received. 556 The existence of a duplicate for a given sequence number is 557 determined over the entire reporting period. For example, if packet 558 number 12,593 arrives, followed by other packets with other sequence 559 numbers, the arrival later in the reporting period of another packet 560 numbered 12,593 counts as a duplicate for that sequence number. The 561 duplicate does not need to follow immediately upon the first packet 562 of that number. Care must be taken that a report does not cover a 563 range of 65,534 or greater in the sequence number space. 565 No distinction is made between the existence of a single duplicate 566 packet and multiple duplicate packets for a given sequence number. 567 Note also that since there is no duplicate for a lost packet, a loss 568 is encoded as a one in a Duplicate RLE Report Block. 570 The Duplicate RLE Report Block has the following format: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | BT=2 | rsvd. | T | block length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | SSRC of source | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | begin_seq | end_seq | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | chunk 1 | chunk 2 | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 : ... : 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | chunk n-1 | chunk n | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 block type (BT): 8 bits 589 A Duplicate RLE Report Block is identified by the constant 2. 591 rsvd.: 4 bits 592 This field is reserved for future definition. In the absence of 593 such definition, the bits in this field MUST be set to zero and 594 MUST be ignored by the receiver. 596 thinning (T): 4 bits 597 As defined in Section 4.1. 599 block length: 16 bits 600 Defined in Section 3. 602 begin_seq: 16 bits 603 As defined in Section 4.1. 605 end_seq: 16 bits 606 As defined in Section 4.1. 608 chunk i: 16 bits 609 As defined in Section 4.1. 611 4.3 Timestamp Report Block 613 This block type permits per-sequence-number reports on packet receipt 614 timestamps for a given source's RTP packet stream. Such information 615 can be used for MINC inference of the topology of the multicast tree 616 used to distribute the source's RTP packets, and of the delays along 617 the links within that tree. It can also be used to measure partial 618 path characteristics and to model distributions for packet jitter. 620 At least one packet MUST have been received for each sequence number 621 reported upon in this block. If this block type is used to report 622 timestamps for a series of sequence numbers that includes lost 623 packets, several blocks are required. If duplicate packets have been 624 received for a given sequence number, and those packets differ in 625 their receiver timestamps, any timestamp other than the earliest MUST 626 NOT be reported. This is to ensure consistency among reports. 628 Timestamps consume more bits than loss or duplicate information, and 629 do not lend themselves to run length encoding. The use of thinning 630 is encouraged to limit the size of Timestamp Report Blocks. 632 The Timestamp Report Block has the following format: 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | BT=3 | rsvd. | T | block length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | SSRC of source | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | begin_seq | end_seq | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | RTP timestamp 1 | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | RTP timestamp 2 | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 : ... : 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | RTP timestamp n | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 block type (BT): 8 bits 653 A Timestamp Report Block is identified by the constant 3. 655 rsvd.: 4 bits 656 This field is reserved for future definition. In the absence of 657 such definition, the bits in this field MUST be set to zero and 658 MUST be ignored by the receiver. 660 thinning (T): 4 bits 661 As defined in Section 4.1. 663 block length: 16 bits 664 Defined in Section 3. 666 begin_seq: 16 bits 667 As defined in Section 4.1. 669 end_seq: 16 bits 670 As defined in Section 4.1. 672 RTP timestamp i: 32 bits 673 The timestamp reflects the packet arrival time at the receiver. 674 It is preferable for the timestamp to be established at the link 675 layer interface, or in any case as close as possible to the wire 676 arrival time. Units and format are the same as for the 677 timestamp in RTP data packets. As opposed to RTP data packet 678 timestamps, in which nominal values may be used instead of 679 system clock values in order to convey information useful for 680 periodic playout, the receiver timestamps should reflect the 681 actual time as closely as possible. The initial value of the 682 timestamp is random, and subsequent timestamps are offset from 683 this value. 685 4.4 Statistics Summary Report Block 687 This block reports statistics beyond the information carried in the 688 standard RTCP packet format, but not as fine grained as that carried 689 in the report blocks previously described. Information is recorded 690 about lost packets, duplicate packets, jitter measurements, and TTL 691 values (TTL values being taken from the TTL field of IPv4 packets, if 692 the data packets are carried over IPv4). Such information can be 693 useful for network management. 695 The report block contents are dependent upon a bit vector carried in 696 the first part of the header. Not all parameters need to be reported 697 in each block. Flags indicate which are and which are not reported. 698 The fields corresponding to unreported parameters MUST be set to 699 zero. The receiver MUST ignore any Statistics Summary Report Block 700 with a non-zero value in any field flagged as unreported. 702 The Statistics Summary Report Block has the following format: 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | BT=4 |L|D|J|T| rsvd. | block length = 9 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | SSRC of source | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | begin_seq | end_seq | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | lost_packets | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | dup_packets | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | min_jitter | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | max_jitter | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | avg_jitter | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | dev_jitter | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | min_ttl | max_ttl | avg_ttl | dev_ttl | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 block type (BT): 8 bits 729 A Statistics Summary Report Block is identified by the constant 730 4. 732 loss report flag (L): 1 bit 733 Bit set to 1 if the lost_packets field contains a report, 0 734 otherwise. 736 duplicate report flag (D): 1 bit 737 Bit set to 1 if the dup_packets field contains a report, 0 738 otherwise. 740 jitter flag (J): 1 bit 741 Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and 742 dev_jitter fields all contain reports, 0 if none of them do. 744 TTL flag (T): 1 bit 745 Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl 746 fields all contain reports, 0 if none of them do. 748 rsvd.: 4 bits 749 This field is reserved for future definition. In the absence of 750 such definition, the bits in this field MUST be set to zero and 751 MUST be ignored by the receiver. 753 block length: 16 bits 754 The constant 9, in accordance with the definition of this field 755 in Section 3. 757 begin_seq: 16 bits 758 As defined in Section 4.1. 760 end_seq: 16 bits 761 As defined in Section 4.1. 763 lost_packets: 32 bits 764 Number of lost packets in the above sequence number interval. 766 dup_packets: 32 bits 767 Number of duplicate packets in the above sequence number 768 interval. 770 min_jitter: 32 bits 771 The minimum relative transit time between two packets in the 772 above sequence number interval. All jitter values are measured 773 as the difference between a packet's RTP timestamp and the 774 reporter's clock at the time of arrival, measured in the same 775 units. 777 max_jitter: 32 bits 778 The maximum relative transit time between two packets in the 779 above sequence number interval. 781 avg_jitter: 32 bits 782 The average relative transit time between each two packet series 783 in the above sequence number interval. 785 dev_jitter: 32 bits 786 The standard deviation of the relative transit time between each 787 two packet series in the above sequence number interval. 789 min_ttl: 8 bits 790 The minimum TTL value of data packets in sequence number range. 792 max_ttl: 8 bits 793 The maximum TTL value of data packets in sequence number range. 795 avg_ttl: 8 bits 796 The average TTL value of data packets in sequence number range. 798 dev_ttl: 8 bits 799 The standard deviation of TTL values of data packets in sequence 800 number range. 802 4.5 Receiver Timestamp Report Block 804 This block extends RTCP's timestamp reporting so that non-senders may 805 also send timestamps. It recapitulates the NTP timestamp fields from 806 the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate 807 its RTT to other participants, as proposed in [11], by sending this 808 report block and receiving DLRR Report Blocks (see next section) in 809 reply. 811 0 1 2 3 812 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 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | BT=5 | reserved | block length = 2 | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | NTP timestamp, most significant word | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | NTP timestamp, least significant word | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 block type (BT): 8 bits 822 A Receiver Timestamp Report Block is identified by the constant 823 5. 825 reserved: 8 bits 826 This field is reserved for future definition. In the absence of 827 such definition, the bits in this field MUST be set to zero and 828 MUST be ignored by the receiver. 830 block length: 16 bits 831 The constant 2, in accordance with the definition of this field 832 in Section 3. 834 NTP timestamp: 64 bits 835 Indicates the wallclock time when this block was sent so that it 836 may be used in combination with timestamps returned in DLRR 837 Report Blocks (see next section) from other receivers to measure 838 round-trip propagation to those receivers. Receivers should 839 expect that the measurement accuracy of the timestamp may be 840 limited to far less than the resolution of the NTP timestamp. 841 The measurement uncertainty of the timestamp is not indicated as 842 it may not be known. A report block sender that can keep track 843 of elapsed time but has no notion of wallclock time may use the 844 elapsed time since joining the session instead. This is assumed 845 to be less than 68 years, so the high bit will be zero. It is 846 permissible to use the sampling clock to estimate elapsed 847 wallclock time. A report sender that has no notion of wallclock 848 or elapsed time may set the NTP timestamp to zero. 850 4.6 DLRR Report Block 852 This block extends RTCP's delay since last sender report (DLSR) 853 mechanism [7, Sec. 6.3.1] so that non-senders may also calculate 854 round trip times, as proposed in [11]. It is termed DLRR for delay 855 since last receiver report, and may be sent in response to a Receiver 856 Timestamp Report Block (see previous section) from a receiver to 857 allow that receiver to calculate its round trip time to the 858 respondent. The report consists of one or more 3 word sub-blocks: 859 one sub-block per receiver report. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | BT=6 | reserved | block length | 865 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 866 | SSRC_1 (SSRC of first receiver) | sub- 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 868 | last RR (LRR) | 1 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | delay since last RR (DLRR) | 871 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 872 | SSRC_2 (SSRC of second receiver) | sub- 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 874 : ... : 2 875 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 877 block type (BT): 8 bits 878 A DLRR Report Block is identified by the constant 6. 880 reserved: 8 bits 881 This field is reserved for future definition. In the absence of 882 such definition, the bits in this field MUST be set to zero and 883 MUST be ignored by the receiver. 885 block length: 16 bits 886 Defined in Section 3. 888 last RR timestamp (LRR): 32 bits 889 The middle 32 bits out of 64 in the NTP timestamp (as explained 890 in the previous section) received as part of a Receiver 891 Timestamp Report Block from participant SSRC_n. If no such block 892 has been received, the field is set to zero. 894 delay since last RR (DLRR): 32 bits 895 The delay, expressed in units of 1/65536 seconds, between 896 receiving the last Receiver Timestamp Report Block from 897 participant SSRC_n and sending this DLRR Report Block. If no 898 Receiver Timestamp Report Block has been received yet from 899 SSRC_n, the DLRR field is set to zero (or the DLRR is omitted 900 entirely). Let SSRC_r denote the receiver issuing this DLRR 901 Report Block. Participant SSRC_n can compute the round-trip 902 propagation delay to SSRC_r by recording the time A when this 903 Receiver Timestamp Report Block is received. It calculates the 904 total round-trip time A-LSR using the last SR timestamp (LSR) 905 field, and then subtracting this field to leave the round-trip 906 propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig. 907 2]. 909 4.7 VoIP Metrics Report Block 911 The VoIP Metrics Report Block provides metrics for monitoring voice 912 over IP (VoIP) calls. These metrics include packet loss and discard 913 metrics, delay metrics, analog metrics, and voice quality metrics. 914 The block reports separately on packets lost on the IP channel, and 915 those that have been received but then discarded by the receiving 916 jitter buffer. It also reports on the combined effect of losses and 917 discards, as both have equal effect on call quality. 919 In order to properly assess the quality of a Voice over IP call it is 920 desirable to consider the degree of burstiness of packet loss [10]. 921 Following a Gilbert-Elliott model [2], a period of time, bounded by 922 lost and/or discarded packets, with a high rate of losses and/or 923 discards is a "burst," and a period of time between two bursts is a 924 "gap." Bursts correspond to periods of time during which the packet 925 loss rate is high enough to produce noticeable degradation in audio 926 quality. Gaps correspond to periods of time during which only 927 isolated lost packets may occur, and in general these can be masked 928 by packet loss concealment. Delay reports include the transit delay 929 between RTCP end points and the VoIP end system processing delays, 930 both of which contribute to the user perceived delay. Additional 931 metrics include signal, echo, noise, and distortion levels. Call 932 quality metrics include R factors (as described by the E Model 933 defined in [2]) and mean opinion scores (MOS scores). 935 An implementation that sends these blocks SHOULD send at least one 936 every ten seconds for the duration of the call, SHOULD send one 937 whenever a codec type change or other significant change occurs, 938 SHOULD send one when significant call quality degradation is detected 939 and SHOULD send one upon call termination. Implementations MUST 940 provide values for all the fields defined here. For certain metrics, 941 if the value is undefined or unknown, then the specified default or 942 unknown field value MUST be provided. 944 The block is encoded as seven 32-bit words: 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | BT=7 | reserved | block length = 6 | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | loss rate | discard rate | burst density | gap density | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | burst duration | gap duration | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | round trip delay | end system delay | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | signal level | noise level | RERL | Gmin | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | R factor | ext. R factor | MOS-LQ | MOS-CQ | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | RX config | JB nominal | JB maximum | JB abs max | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 block type (BT): 8 bits 965 A VoIP Metrics Report Block is identified by the constant 7. 967 reserved: 8 bits 968 This field is reserved for future definition. In the absence of 969 such definition, the bits in this field MUST be set to zero and 970 MUST be ignored by the receiver. 972 block length: 16 bits 973 The constant 6, in accordance with the definition of this field 974 in Section 3. 976 The remaining fields are described in the following six sections: 977 Packet Loss and Discard Metrics, Delay Metrics, Signal Related 978 Metrics, Call Quality or Transmission Quality Metrics, Configuration 979 Metrics, and Jitter Buffer Parameters. 981 4.7.1 Packet Loss and Discard Metrics 983 It is very useful to distinguish between packets lost by the network 984 and those discarded due to jitter. Both have equal effect on the 985 quality of the voice stream however having separate counts helps 986 identify the source of quality degradation. These fields MUST be 987 populated. 989 loss rate: 8 bits 990 The fraction of RTP data packets from the source lost since the 991 beginning of reception, expressed as a fixed point number with 992 the binary point at the left edge of the field. This value is 993 calculated by dividing the total number of packets lost (after 994 the effects of applying any error protection such as FEC) by the 995 total number of packets expected, multiplying the result of the 996 division by 256, limiting the maximum value to 255 (to avoid 997 overflow), and taking the integer part. The numbers of 998 duplicated packets and discarded packets do not enter into this 999 calculation. Since receivers cannot be required to maintain 1000 unlimited buffers, a receiver MAY categorize late-arriving 1001 packets as lost. The degree of lateness that triggers a loss 1002 SHOULD be significantly greater than that which triggers a 1003 discard. 1005 discard rate: 8 bits 1006 The fraction of RTP data packets from the source that have been 1007 discarded since the beginning of reception, due to late or early 1008 arrival, under-run or overflow at the receiving jitter buffer. 1009 This value is expressed as a fixed point number with the binary 1010 point at the left edge of the field. It is calculated by 1011 dividing the total number of packets discarded (excluding 1012 duplicate packet discards) by the total number of packets 1013 expected, multiplying the result of the division by 256, 1014 limiting the maximum value to 255 (to avoid overflow), and 1015 taking the integer part. 1017 4.7.2 Burst Metrics 1019 A burst, informally, is a period of high packet losses and/or 1020 discards. Formally, a burst is defined as a longest sequence of 1021 packets bounded by lost or discarded packets with the constraint that 1022 within a burst any sequence of successive packets that were received, 1023 and not discarded due to delay variation, is of length less than a 1024 value Gmin. 1026 A gap, informally, is a period of low packet losses and/or discards. 1027 Formally, a gap is defined as any of the following: (a) the period 1028 from the start of an RTP session to the receipt time of the last 1029 received packet before the first burst, (b) the period from the end 1030 of the last burst to either the time of the report or the end of the 1031 RTP session, whichever comes first, or (c) the period of time between 1032 two bursts. 1034 For the purpose of determining if a lost or discarded packet near the 1035 start or end of an RTP session is within a gap or a burst it is 1036 assumed that the RTP session is preceded and followed by at least 1037 Gmin received packets, and that the time of the report is followed by 1038 at least Gmin received packets. 1040 A gap has the property that any lost or discarded packets within the 1041 gap must be preceded and followed by at least Gmin packets that were 1042 received and not discarded. This gives a maximum loss/discard 1043 density within a gap of: 1 / (Gmin + 1). 1045 A Gmin value of 16 is RECOMMENDED as it results in gap 1046 characteristics that correspond to good quality (i.e. low packet loss 1047 rate, a minimum distance of 16 received packets between lost packets) 1048 and hence differentiates nicely between good and poor quality 1049 periods. 1051 For example, a 1 denotes a received, 0 a lost, and X a discarded 1052 packet in the following pattern covering 64 packets: 1054 11110111111111111111111X111X1011110111111111111111111X111111111 1055 |---------gap----------|--burst---|------------gap------------| 1057 The burst consists of the twelve packets indicated above, starting at 1058 a discarded packet and ending at a lost packet. The first gap starts 1059 at the beginning of the session and the second gap ends at the time 1060 of the report. 1062 If the packet spacing is 10 ms and the Gmin value is the recommended 1063 value of 16, the burst duration is 120 ms, the burst density 0.33, 1064 the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04. 1066 This would result in reported values as follows (see field 1067 descriptions for semantics and details on how these are calculated): 1069 loss density 12, which corresponds to 5% 1070 discard density 12, which corresponds to 5% 1071 burst density 84, which corresponds to 33% 1072 gap density 10, which corresponds to 4% 1073 burst duration 120, value in milliseconds 1074 gap duration 520, value in milliseconds 1076 burst density: 8 bits 1077 The fraction of RTP data packets within burst periods since the 1078 beginning of reception that were either lost or discarded. This 1079 value is expressed as a fixed point number with the binary point 1080 at the left edge of the field. It is calculated by dividing the 1081 total number of packets lost or discarded (excluding duplicate 1082 packet discards) within burst periods by the total number of 1083 packets expected within the burst periods, multiplying the 1084 result of the division by 256, limiting the maximum value to 255 1085 (to avoid overflow), and taking the integer part. 1087 gap density: 8 bits 1088 The fraction of RTP data packets within inter-burst gaps since 1089 the beginning of reception that were either lost or discarded. 1090 The value is expressed as a fixed point number with the binary 1091 point at the left edge of the field. It is calculated by 1092 dividing the total number of packets lost or discarded 1093 (excluding duplicate packet discards) within gap periods by the 1094 total number of packets expected within the gap periods, 1095 multiplying the result of the division by 256, limiting the 1096 maximum value to 255 (to avoid overflow), and taking the integer 1097 part. 1099 burst duration: 16 bits 1100 The mean duration, expressed in milliseconds, of the burst 1101 periods that have occurred since the beginning of reception. 1102 The duration of each period is calculated based upon the packets 1103 that mark the beginning and end of that period. It is equal to 1104 the timestamp of the end packet, plus the duration of the end 1105 packet, minus the timestamp of the beginning packet. If the 1106 actual values are not available, estimated values MUST be used. 1107 If there have been no burst periods, the burst duration value 1108 MUST be zero. 1110 gap duration: 16 bits 1111 The mean duration, expressed in milliseconds, of the gap periods 1112 that have occurred since the beginning of reception. The 1113 duration of each period is calculated based upon the packet that 1114 marks the end of the prior burst and the packet that marks the 1115 beginning of the subsequent burst. It is equal to the timestamp 1116 of the subsequent burst packet, minus the timestamp of the prior 1117 burst packet, plus the duration of the prior burst packet. If 1118 the actual values are not available, estimated values MUST be 1119 used. In the case of a gap that occurs at the beginning of 1120 reception, the sum of the timestamp of the prior burst packet 1121 and the duration of the prior burst packet are replaced by the 1122 reception start time. In the case of a gap that occurs at the 1123 end of reception, the timestamp of the subsequent burst packet 1124 is replaced by the reception end time. If there have been no 1125 gap periods, the gap duration value MUST be zero. 1127 4.7.3 Delay Metrics 1128 For the purpose of the following definitions, the RTP interface is 1129 the interface between the RTP instance and the voice application 1130 (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For 1131 example, the time delay due to RTP payload multiplexing would be 1132 considered to be part of the voice application or end-system delay 1133 whereas delay due to multiplexing RTP frames within a UDP frame would 1134 be considered part of the RTP reported delay. This distinction is 1135 consistent with the use of RTCP for delay measurements. 1137 round trip delay: 16 bits 1138 The most recently calculated round trip time between RTP 1139 interfaces, expressed in milliseconds. This value is the time of 1140 receipt of the most recent RTCP packet from source SSRC, minus 1141 the LSR (last SR) time reported in its SR (sender report), minus 1142 the DLSR (delay since last SR) reported in its SR. A non-zero 1143 LSR value is REQUIRED in order to calculate round trip delay. A 1144 value of 0 is permissible during the first two or three RTCP 1145 exchanges as insufficient data may be available to determine 1146 delay however MUST be populated as soon as a delay estimate is 1147 available. 1149 end system delay: 16 bits 1150 The most recently estimated end system delay, expressed in 1151 milliseconds. End system delay is defined as the total 1152 encoding, decoding and jitter buffer delay determined at the 1153 reporting endpoint. This is the time required for an RTP frame 1154 to be buffered, decoded, converted to analog form, looped back 1155 at the local analog interface, encoded, and made available for 1156 transmission as an RTP frame. The manner in which this value is 1157 estimated is implementation dependent. This parameter MUST be 1158 provided in all VoIP metrics reports. 1160 Note that the one way symmetric VoIP segment delay may be calculated 1161 from the round trip and end system delays as follows. If the round 1162 trip delay is denoted RTD and the end system delays associated with 1163 the two endpoints are ESD(A) and ESD(B) then: 1165 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 1167 4.7.4 Signal Related Metrics 1169 The following metrics are intended to provide real time information 1170 related to the non-packet elements of the voice over IP system to 1171 assist with the identification of problems affecting call quality. 1172 The values identified below must be determined for the received audio 1173 signal. The information required to populate these fields may not be 1174 available in all systems, although it is strongly recommended that 1175 this data SHOULD be provided to support problem diagnosis. 1177 signal level: 8 bits 1178 The voice signal relative level is defined as the ratio of the 1179 signal level to a reference digital milliwatt, expressed in 1180 decibels as a signed integer in two's complement form. This is 1181 measured only for packets containing speech energy. The intent 1182 of this metric is not to provide a precise measurement of the 1183 signal level but to provide a real time indication that the 1184 signal level may be excessively high or low. 1186 signal level = 10 log 10 ( rms talkspurt power (mW) ) 1188 A value of 127 indicates that this parameter is unavailable. 1189 Typical values should be generally in the -15 to -20 dBm range. 1191 noise level: 8 bits 1192 The noise level is defined as the ratio of the silent period 1193 background noise level to a reference digital milliwatt, 1194 expressed in decibels as a signed integer in two's complement 1195 form. 1197 noise level = 10 log10 ( rms silence power (mW) ) 1199 A value of 127 indicates that this parameter is unavailable. 1201 residual echo return loss (RERL): 8 bits 1202 The residual echo return loss is defined as the sum of the 1203 measured echo return loss (ERL) and the echo return loss 1204 enhancement (ERLE) expressed in dB as a signed integer in two's 1205 complement form. It defines the ratio of a transmitted voice 1206 signal that is reflected back to the talker. A low level of 1207 echo return loss (say less than 20 dB) in conjunction with some 1208 delay can lead to hollowness or audible echo. A high level of 1209 echo return loss (say over 40 dB) is preferable. 1211 The ERL and ERLE parameters are often available directly from the 1212 echo canceler contained within the VoIP end system. They relate to 1213 the echo on the external network attached to the end point. 1215 In the case of a VoIP gateway this would be line echo that typically 1216 occurs at 2-4 wire conversion points in the network. Echo return 1217 loss from typical 2-4 wire conversions can be in the 8-12 dB range. 1218 A line echo canceler can provide an ERLE of 30 dB or more and hence 1219 reduce this to 40-50 dB. In the case of an IP phone this could be 1220 residual acoustic echo from speakerphone operation, and may more 1221 correctly be termed terminal coupling loss (TCL). A typical handset 1222 would result in 40-50 dB of echo due to acoustic feedback. 1224 Typical values for RERL are as follows: 1226 (i) IP gateway connected to circuit switched network with 2 wire loop 1227 Without echo cancellation, typical 2-4 wire converter ERL of 12 dB 1228 RERL = ERL + ERLE = 12 + 0 = 12 dB 1230 (ii) IP gateway connected to circuit switched network with 2 wire loop 1231 With echo canceler that improves echo by 30 dB 1232 RERL = ERL + ERLE = 12 + 30 = 42 dB 1234 (iii) IP phone with conventional handset 1235 Acoustic coupling from handset speaker to microphone 40 dB 1236 Residual echo return loss = TCL = 40 dB 1238 If we denote the "local" end of the VoIP path as A and the remote end 1239 as B and if the sender loudness rating (SLR) and receiver loudness 1240 rating (RLR) are known for A (default values 8 dB and 2 dB 1241 respectively), then the echo loudness level at end A (talker echo 1242 loudness rating or TELR) is given by: 1244 TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A) 1246 TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B) 1248 Hence in order to incorporate echo into a voice quality estimate at 1249 the A end of a VoIP connection it is desirable to send the ERL + ERLE 1250 value from B to A. 1252 For an IP phone with handset this metric MUST be set to the designed 1253 or measured terminal coupling loss, which would typically be 40-50 1254 dB. 1256 For a PC softphone or speakerphone this metric MUST be set to either 1257 the value reported by the acoustic echo canceler or to 127 to 1258 indicate an undefined value. 1260 For an IP gateway with ERL and ERLE measurements this metric MUST be 1261 reported as ERL + ERLE. 1263 For an IP gateway without ERL and ERLE measurement capability then 1264 this metric MUST be reported as 12 dB if line echo cancellation is 1265 disabled and 40 dB if line echo cancellation is enabled. 1267 Gmin 1268 See Configuration Parameters (Section 4.7.6, below). 1270 4.7.5 Call Quality or Transmission Quality Metrics 1272 The following metrics are direct measures of the call quality or 1273 transmission quality, and incorporate the effects of codec type, 1274 packet loss, discard, burstiness, delay etc. These metrics may not 1275 be available in all systems however SHOULD be provided in order to 1276 support problem diagnosis. 1278 R factor: 8 bits 1279 The R factor is a voice quality metric describing the segment of 1280 the call that is carried over this RTP session. It is expressed 1281 as an integer in the range 0 to 100, with a value of 94 1282 corresponding to "toll quality" and values of 50 or less 1283 regarded as unusable. This metric is defined as including the 1284 effects of delay, consistent with ITU-T G.107 [4] and ETSI TS 1285 101 329-5 [2]. 1287 A value of 127 indicates that this parameter is unavailable. 1289 ext. R factor: 8 bits 1290 The external R factor is a voice quality metric describing the 1291 segment of the call that is carried over a network segment 1292 external to the RTP segment, for example a cellular network. Its 1293 values are interpreted in the same manner as for the RTP R 1294 factor. This metric is defined as including the effects of 1295 delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 1296 [2], and relates to the outward voice path from the Voice over 1297 IP termination for which this metrics block applies. 1299 A value of 127 indicates that this parameter is unavailable. 1301 Note that an overall R factor may be estimated from the RTP segment R 1302 factor and the external R factor, as follows: 1304 R total = RTP R factor + ext. R factor - 94 1306 MOS-LQ: 8 bits 1307 The estimated mean opinion score for listening quality (MOS-LQ) 1308 is a voice quality metric on a scale from 1 to 5, in which 5 1309 represents excellent and 1 represents unacceptable. This metric 1310 is defined as not including the effects of delay and can be 1311 compared to MOS scores obtained from listening quality (ACR) 1312 tests. It is expressed as an integer in the range 10 to 50, 1313 corresponding to MOS x 10. For example, a value of 35 would 1314 correspond to an estimated MOS score of 3.5. 1316 A value of 127 indicates that this parameter is unavailable. 1318 MOS-CQ: 8 bits 1319 The estimated mean opinion score for conversational quality 1320 (MOS-CQ) is defined as including the effects of delay and other 1321 effects that would affect conversational quality. The metric 1322 may be calculated by converting an R factor determined according 1323 to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated 1324 MOS using the equation specified in G.107. It is expressed as 1325 an integer in the range 10 to 50, corresponding to MOS x 10, as 1326 for MOS-LQ. 1328 A value of 127 indicates that this parameter is unavailable. 1330 4.7.6 Configuration Parameters 1332 Gmin: 8 bits 1333 The gap threshold. This field contains the value used for this 1334 report block to determine if a gap exists. The recommended 1335 value of 16 corresponds to a burst period having a minimum 1336 density of 6.25% of lost or discarded packets, which may cause 1337 noticeable degradation in call quality; during gap periods, if 1338 packet loss or discard occurs, each lost or discarded packet 1339 would be preceded by and followed by a sequence of at least 16 1340 received non-discarded packets. Note that lost or discarded 1341 packets that occur within Gmin packets of a report being 1342 generated may be reclassified as being part of a burst or gap in 1343 later reports. ETSI TS 101 329-5 [2] defines a computationally 1344 efficient algorithm for measuring burst and gap density using a 1345 packet loss/discard event driven approach. This algorithm is 1346 reproduced in Appendix A.2 of the present document. Gmin MUST 1347 not be zero and MUST be provided. 1349 receiver configuration byte (RX config): 8 bits 1350 This byte consists of the following fields: 1352 0 1 2 3 4 5 6 7 1353 +-+-+-+-+-+-+-+-+ 1354 |PLC|JBA|JB rate| 1355 +-+-+-+-+-+-+-+-+ 1357 packet loss concealment (PLC): 2 bits 1358 Standard (11) / enhanced (10) / disabled (01) / unspecified 1359 (00). When PLC = 11 then a simple replay or interpolation 1360 algorithm is being used to fill-in the missing packet. 1361 This is typically able to conceal isolated lost packets 1362 with loss rates under 3%. When PLC = 10 then an enhanced 1363 interpolation algorithm is being used. This would 1364 typically be able to conceal lost packets for loss rates of 1365 10% or more. When PLC = 01 then silence is inserted in 1366 place of lost packets. When PLC = 00 then no information 1367 is available concerning the use of PLC however for some 1368 codecs this may be inferred. 1370 jitter buffer adaptive (JBA): 2 bits 1371 Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown 1372 (00). When the jitter buffer is adaptive then its size is 1373 being dynamically adjusted to deal with varying levels of 1374 jitter. When non-adaptive, the jitter buffer size is 1375 maintained at a fixed level. When either adaptive or non- 1376 adaptive modes are specified then the jitter buffer size 1377 parameters below MUST be specified. 1379 jitter buffer rate (JB rate): 4 bits 1380 J = adjustment rate (0-15). This represents the 1381 implementation specific adjustment rate of a jitter buffer 1382 in adaptive mode. This parameter is defined in terms of the 1383 approximate time taken to fully adjust to a step change in 1384 peak to peak jitter from 30 ms to 100 ms such that: 1386 adjustment time = 2 * J * frame size (ms) 1388 This parameter is intended only to provide a guide to the 1389 degree of "aggressiveness" of a an adaptive jitter buffer 1390 and may be estimated. A value of 0 indicates that the 1391 adjustment time is unknown for this implementation. 1393 4.7.7 Jitter Buffer Parameters 1395 jitter buffer nominal size in frames (JB nominal): 8 bits 1396 This is the current nominal fill point within the jitter buffer, 1397 which corresponds to the nominal jitter buffer delay for packets 1398 that arrive exactly on time. This parameter MUST be provided 1399 for both fixed and adaptive jitter buffer implementations. 1401 jitter buffer maximum size in frames (JB maximum): 8 bits 1402 This is the current maximum jitter buffer level corresponding to 1403 the earliest arriving packet that would not be discarded. In 1404 simple queue implementations this may correspond to the nominal 1405 size. In adaptive jitter buffer implementations this value may 1406 dynamically vary up to JB abs max (see below). This parameter 1407 MUST be provided for both fixed and adaptive jitter buffer 1408 implementations. 1410 jitter buffer absolute maximum size in frames (JB abs max): 8 bits 1411 This is the absolute maximum size that the adaptive jitter 1412 buffer can reach under worst case jitter conditions. This 1413 parameter MUST be provided for adaptive jitter buffer 1414 implementations and its value MUST be set to JB maximum for 1415 fixed jitter buffer implementations. 1417 5. IANA Considerations 1419 This document defines a new RTP packet type, the extended report (XR) 1420 type, within the existing Internet Assigned Numbers Authority (IANA) 1421 registry of RTP RTCP Control Packet Types. This document also 1422 defines a new IANA registry: the registry of RTP XR Block Types. 1423 Within this new registry, this document defines an initial set of 1424 seven block types and describes how the remaining types are to be 1425 allocated. 1427 5.1 XR Packet Type 1429 The IANA SHALL register the RTP extended report (XR) packet defined 1430 by this document as packet type 207 in the registry of RTP RTCP 1431 Control Packet types (PT). 1433 5.2 RTP XR Block Type Registry 1435 The IANA SHALL create the RTP XR Block Type Registry to cover the 1436 name space of the extended report block type (BT) field specified in 1437 Section 3 of this document. The BT field contains eight bits, 1438 allowing 256 values. The IANA SHALL manage the RTP XR Block Type 1439 Registry according to the Specification Required policy of RFC 2434 1440 [6]. Future specifications SHOULD attribute block type values in 1441 strict numeric order following the values attributed in this 1442 document: 1444 BT name 1445 -- ---- 1446 1 Loss RLE Report Block 1447 2 Duplicate RLE Report Block 1448 3 Timestamp Report Block 1449 4 Statistics Summary Report Block 1450 5 Receiver Timestamp Report Block 1451 6 DLRR Report Block 1452 7 VoIP Metrics Report Block 1454 Furthermore, future specifications SHOULD avoid the values 0 and 255. 1455 Doing so facilitates packet validity checking, since all-zeros and 1456 all-ones are values that might commonly be found in ill-formed 1457 packets. 1459 6. Security Considerations 1461 This document extends the RTCP reporting mechanism. The security 1462 considerations that apply to RTCP reports also apply to XR reports. 1463 This section details the additional security considerations that 1464 apply to the extensions. 1466 The extensions introduce heightened confidentiality concerns. 1467 Standard RTCP reports contain a limited number of summary statistics. 1468 The information contained in XR reports is both more detailed and 1469 more extensive (covering a larger number of parameters). The per- 1470 packet information contained in Loss RLE, Duplicate RLE, and 1471 Timestamp Report Blocks facilitates MINC inference of multicast 1472 distribution trees for RTP data packets, and inference of link 1473 characteristics such as loss and delay. This inference reveals 1474 information that might otherwise be considered confidential to 1475 autonomous system administrators. The VoIP Metrics Report Block 1476 provides information on the quality of ongoing voice calls. Though 1477 such information might be carried in application specific format in 1478 standard RTP sessions, making it available in a standard format here 1479 makes it more available to potential eavesdroppers. 1481 No new mechanisms are introduced in this document to ensure 1482 confidentiality. Standard encryption procedures can be used when 1483 confidentiality is a concern to end hosts. Autonomous system 1484 administrators concerned about the loss of confidentiality regarding 1485 their networks can encrypt traffic, or filter it to exclude RTCP 1486 packets containing the XR report blocks concerned. 1488 Any encryption or filtering of XR report blocks entails a loss of 1489 monitoring information to third parties. For example, a network that 1490 establishes a tunnel to encrypt VoIP Report Blocks denies that 1491 information to the service providers traversed by the tunnel. The 1492 service providers cannot then monitor or respond to the quality of 1493 the VoIP calls that they carry, potentially creating problems for the 1494 network's users. As a default, XR packets SHOULD NOT be encrypted or 1495 filtered. 1497 The extensions also make certain denial of service attacks easier. 1498 This is because of the potential to create RTCP packets much larger 1499 than average with the per packet reporting capabilities of the Loss 1500 RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the 1501 automatic bandwidth adjustment mechanisms in RTCP, if some session 1502 participants are sending large RTCP packets, all participants will 1503 see their RTCP reporting intervals lengthened, meaning they will be 1504 able to report less frequently. To limit the effects of large 1505 packets, even in the absence of denial of service attacks, 1506 applications SHOULD limit the size of XR report blocks and employ the 1507 thinning techniques described in this document in order to fit 1508 reports into the space available. 1510 A. Algorithms 1512 A.1 Sequence Number Interpretation 1514 This the algorithm suggested by Section 4.1 for keeping track of the 1515 sequence numbers from a given sender. It implements the accounting 1516 practice required for the generation of Loss RLE Report Blocks. 1518 This algorithm keeps track of 16 bit sequence numbers by translating 1519 them into a 32 bit sequence number space. The first packet received 1520 from a source is considered to have arrived roughly in the middle of 1521 that space. Each packet that follows is placed either ahead or 1522 behind the prior one in this 32 bit space, depending upon which 1523 choice would place it closer (or, in the event of a tie, which choice 1524 would not require a rollover in the 16 bit sequence number). 1526 // The reference sequence number is an extended sequence number 1527 // that serves as the basis for determining whether a new 16 bit 1528 // sequence number comes earlier or later in the 32 bit sequence 1529 // space. 1530 u_int32 _src_ref_seq; 1531 bool _uninitialized_src_ref_seq; 1533 // Place seq into a 32-bit sequence number space based upon a 1534 // heuristic for its most likely location. 1535 u_int32 extend_seq(const u_int16 seq) { 1537 u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; 1538 if(_uninitialized_src_ref_seq) { 1540 // This is the first sequence number received. Place 1541 // it in the middle of the extended sequence number 1542 // space. 1543 _src_ref_seq = seq | 0x80000000u; 1544 _uninitialized_src_ref_seq = false; 1545 extended_seq = _src_ref_seq; 1546 } 1547 else { 1549 // Prior sequence numbers have been received. 1550 // Propose two candidates for the extended sequence 1551 // number: seq_a is without wraparound, seq_b with 1552 // wraparound. 1553 seq_a = seq | (_src_ref_seq & 0xFFFF0000u); 1554 if(_src_ref_seq < seq_a) { 1555 seq_b = seq_a - 0x00010000u; 1556 diff_a = seq_a - _src_ref_seq; 1557 diff_b = _src_ref_seq - seq_b; 1558 } 1559 else { 1560 seq_b = seq_a + 0x00010000u; 1561 diff_a = _src_ref_seq - seq_a; 1562 diff_b = seq_b - _src_ref_seq; 1563 } 1565 // Choose the closer candidate. If they are equally 1566 // close, the choice is somewhat arbitrary: we choose 1567 // the candidate for which no rollover is necessary. 1568 if(diff_a < diff_b) { 1569 extended_seq = seq_a; 1570 } 1571 else { 1572 extended_seq = seq_b; 1573 } 1575 // Set the reference sequence number to be this most 1576 // recently-received sequence number. 1577 _src_ref_seq = extended_seq; 1578 } 1580 // Return our best guess for a 32-bit sequence number that 1581 // corresponds to the 16-bit number we were given. 1582 return extended_seq; 1583 } 1585 A.2 Example Burst Packet Loss Calculation. 1587 This is an algorithm for measuring the burst characteristics for the 1588 VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI 1589 TS 101 329-5 [2]. The algorithm is event driven and hence extremely 1590 computationally efficient. 1592 Given the following definition of states: 1594 state 1 = received a packet during a gap 1595 state 2 = received a packet during a burst 1596 state 3 = lost a packet during a burst 1597 state 4 = lost an isolated packet during a gap 1599 The "c" variables below correspond to state transition counts, i.e. 1600 c14 is the transition from state 1 to state 4. It is possible to 1601 infer one of a pair of state transition counts to an accuracy of 1 1602 which is generally sufficient for this application. 1604 "pkt" is the count of packets received since the last packet was 1605 declared lost or discarded and "lost" is the number of packets lost 1606 within the current burst. "packet_lost" and "packet_discarded" are 1607 Boolean variables that indicate if the event that resulted in this 1608 function being invoked was a lost or discarded packet. 1610 if(packet_lost) { 1611 loss_count++; 1612 } 1613 if(packet_discarded) { 1614 discard_count++; 1615 } 1616 if(!packet_lost && !packet_discarded) { 1617 pkt++; 1618 } 1619 else { 1620 if(pkt >= gmin) { 1621 if(lost == 1) { 1622 c14++; 1623 } 1624 else { 1625 c13++; 1626 } 1627 lost = 1; 1628 c11 += pkt; 1629 } 1630 else { 1631 lost++; 1632 if(pkt == 0) { 1633 c33++; 1634 } 1635 else { 1636 c23++; 1637 c22 += (pkt - 1); 1638 } 1639 } 1640 pkt = 0; 1641 } 1643 At each reporting interval the burst and gap metrics can be 1644 calculated as follows. 1646 // Calculate additional transition counts. 1647 c31 = c13; 1648 c32 = c23; 1649 ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; 1651 // Calculate burst and densities. 1652 p32 = c32 / (c31 + c32 + c33); 1653 if((c22 + c23) < 1) { 1654 p23 = 1; 1655 } 1656 else { 1657 p23 = 1 - c22/(c22 + c23); 1658 } 1659 burst_density = 256 * p23 / (p23 + p32); 1660 gap_density = 256 * c14 / (c11 + c14); 1662 // Calculate burst and gap durations in ms 1663 m = frameDuration_in_ms * framesPerRTPPkt; 1664 gap_length = (c11 + c14 + c13) * m / c13; 1665 burst_length = ctotal * m / c13 - lgap; 1667 /* calculate loss and discard densities */ 1668 loss_density = 256 * loss_count / ctotal; 1669 discard_density = 256 * discard_count / ctotal; 1671 Intellectual Property 1673 The IETF takes no position regarding the validity or scope of any 1674 intellectual property or other rights that might be claimed to 1675 pertain to the implementation or use of the technology described in 1676 this document or the extent to which any license under such rights 1677 might or might not be available; neither does it represent that it 1678 has made any effort to identify any such rights. Information on the 1679 IETF's procedures with respect to rights in standards-track and 1680 standards-related documentation can be found in BCP 11 [3]. Copies 1681 of claims of rights made available for publication and any assurances 1682 of licenses to be made available, or the result of an attempt made to 1683 obtain a general license or permission for the use of such 1684 proprietary rights by implementors or users of this specification can 1685 be obtained from the IETF Secretariat. 1687 The IETF invites any interested party to bring to its attention any 1688 copyrights, patents or patent applications, or other proprietary 1689 rights which may cover technology that may be required to practice 1690 this standard. Please address the information to the IETF Executive 1691 Director. 1693 Full Copyright Statement 1695 Copyright (C) The Internet Society (2003). All Rights Reserved. 1697 This document and translations of it may be copied and furnished to 1698 others, and derivative works that comment on or otherwise explain it 1699 or assist in its implementation may be prepared, copied, published 1700 and distributed, in whole or in part, without restriction of any 1701 kind, provided that the above copyright notice and this paragraph are 1702 included on all such copies and derivative works. However, this 1703 document itself may not be modified in any way, such as by removing 1704 the copyright notice or references to the Internet Society or other 1705 Internet organizations, except as needed for the purpose of 1706 developing Internet standards in which case the procedures for 1707 copyrights defined in the Internet Standards process must be 1708 followed, or as required to translate it into languages other than 1709 English. 1711 The limited permissions granted above are perpetual and will not be 1712 revoked by the Internet Society or its successors or assigns. 1714 This document and the information contained herein is provided on an 1715 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1716 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1717 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1718 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1719 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1721 Acknowledgments 1723 We thank the following people: Colin Perkins, Steve Casner, and 1724 Henning Schulzrinne for their considered guidance; Sue Moon for 1725 helping foster collaboration between the authors; Magnus Westerlund 1726 for his detailed comments; Mounir Benzaid for drawing our attention 1727 to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz 1728 for encouraging us to incorporate MLDA block types. 1730 Contributors 1732 The following people are the authors of this document: 1734 Kevin Almeroth, UCSB 1735 Ramon Caceres, ShieldIP 1736 Alan Clark, Telchemy 1737 Robert Cole, AT&T Labs 1738 Nick Duffield, AT&T Labs-Research 1739 Timur Friedman, Paris 6 1740 Kaynam Hedayat, Brix Networks 1741 Kamil Sarac, UT Dallas 1743 The principal people to contact regarding the individual report 1744 blocks described in this document are as follows: 1746 sec. report block principal contributors 1747 ---- ------------ ---------------------- 1748 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 1749 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 1750 4.3 Timestamp Report Block Friedman, Caceres, Duffield 1751 4.4 Statistics Summary Report Block Almeroth, Sarac 1752 4.5 Receiver Timestamp Report Block Friedman 1753 4.6 DLRR Report Block Friedman 1754 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat 1756 Authors' Addresses 1758 Kevin Almeroth 1759 Department of Computer Science 1760 University of California 1761 Santa Barbara, CA 93106 USA 1763 Ramon Caceres 1764 ShieldIP, Inc. 1765 11 West 42nd Street, 31st Floor 1766 New York, NY 10036 USA 1768 Alan Clark 1769 Telchemy Incorporated 1770 3360 Martins Farm Road, Suite 200 1771 Suwanee, GA 30024 USA 1772 Tel: +1 770 614 6944 1773 Fax: +1 770 614 3951 1775 Robert Cole 1776 AT&T Labs 1777 330 Saint Johns Street, 1778 2nd Floor 1779 Havre de Grace, MD 21078 USA 1780 Tel: +1 410 939 8732 1781 Fax: +1 410 939 8732 1783 Nick Duffield 1784 AT&T Labs-Research 1785 180 Park Avenue, P.O. Box 971 1786 Florham Park, NJ 07932-0971 USA 1787 Tel: +1 973 360 8726 1788 Fax: +1 973 360 8050 1789 Timur Friedman 1790 Universite Pierre et Marie Curie (Paris 6) 1791 Laboratoire LiP6-CNRS 1792 8, rue du Capitaine Scott 1793 75015 PARIS France 1794 Tel: +33 1 44 27 71 06 1795 Fax: +33 1 44 27 74 95 1797 Kaynam Hedayat 1798 Brix Networks 1799 285 Mill Road 1800 Chelmsford, MA 01824 USA 1801 Tel: +1 978 367 5600 1802 Fax: +1 978 367 5700 1804 Kamil Sarac 1805 Department of Computer Science (ES 4.207) 1806 Eric Jonsson School of Engineering & Computer Science 1807 University of Texas at Dallas 1808 Richardson, TX 75083-0688 USA 1809 Tel: +1 972 883 2337 1810 Fax: +1 972 883 2349 1812 References 1814 The references are divided into normative references and non- 1815 normative references. 1817 Normative References 1819 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 1820 levels," BCP 14, RFC 2119, IETF, March 1997. 1822 [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI 1823 TS 101 329-5 V1.1.1 (2000-11), November 2000. 1825 [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF 1826 Standards Process," best current practice BCP 11, RFC 2028, IETF, 1827 October 1996. 1829 [4] ITU-T, "The E-Model, a computational model for use in 1830 transmission planning," Recommendation G.107 (05/00), May 2000. 1832 [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, 1833 RFC 1700, IETF, October 1994. 1835 [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 1836 Considerations Section in RFCs," best current practice BCP 26, RFC 1837 2434, IETF, October 1998. 1839 [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 1840 transport protocol for real-time applications," RFC 1889, IETF, 1841 February 1996. 1843 Non-Normative References 1845 [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. 1846 Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The 1847 Use of End-to-End Multicast Measurements for Characterizing Internal 1848 Network Behavior," IEEE Communications Magazine, May 2000. 1850 [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu 1851 measurement infrastructures using RTP," Proc. IEEE Infocom 2002. 1853 [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and 1854 Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 1855 2001. 1857 [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion 1858 Control Framework for Heterogeneous Multicast Environments", Proc. 1859 IWQoS 2000.