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