idnits 2.17.1 draft-ietf-avt-rtcp-report-extns-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 786 has weird spacing: '...ese can be ma...' == 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 (zeroes in both the run type and run length fields would make the chunk a termi-nating 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 (octal 0x10) corresponds to a burst interval having a minimum den-sity of 6.25% of lost or discarded packets, which may cause notice-able degradation in call quality; during gap intervals, if packet loss or dis card occurs, each lost or discarded packet would be pre-ceded by and followed by a sequence of at least 16 received non-dis-carded 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 [5] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. 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 (3 November 2002) is 7846 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 1325, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1700 (ref. '7') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1889 (ref. '8') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 November 2002 3 Internet Engineering Task Force Expires: 3 May 2003 4 Audio/Video Transport Working Group 6 Timur Friedman, Paris 6 7 Ramon Caceres, ShieldIP 8 Kevin Almeroth, UCSB 9 Kamil Sarac, UCSB 10 Alan Clark, Telchemy 11 Robert Cole, AT&T 12 Kaynam Hedayat, Brix Networks 14 RTCP Reporting Extensions 16 draft-ietf-avt-rtcp-report-extns-01.txt 18 Status of this Memo 20 This document is an Internet-Draft and is subject to all provisions 21 of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 This document defines the XR (extended report) RTCP packet type and 46 seven XR block types. The purpose of the extended reporting format is 47 to convey information that supplements the six statistics that are 48 contained in the report blocks used by SR (sender report) and RR 49 (receiver report) packets. Some applications, such as MINC 50 (multicast inference of network characteristics) or VoIP (voice over 51 IP) monitoring, require other and more detailed statistics. In 52 addition to the block types defined here, additional block types may 53 be defined in the future by adhereing to the simple framework that 54 this document provides. 56 1. Introduction 58 This document defines the XR (extended report) RTCP packet type for 59 RTCP, the control portion of RTP [8]. The definition consists of 60 three parts. First, Section 2 of this document defines a general 61 packet framework capable of including a number of different "extended 62 report blocks." Second, Section 3 defines the general format for 63 such blocks. Third, Section 4 defines a number of such blocks. 65 The extended report blocks convey information beyond that which is 66 already contained in the reception report blocks of RTCP's SR or RR 67 packets. XR report blocks carry information that is not appropriately 68 carried in SR or RR profile-specific extensions because it is of use 69 across profiles. Information that is useful to network management 70 falls into this category, for instance. 72 Seven report block formats are defined by this document: 74 - Loss RLE Report Block (Section 4.1): Run-length encoding of RTP 75 packet loss reports. 77 - Duplicate RLE Report Block (Section 4.2): Run-length encoding of 78 reports of RTP packet duplicates. 80 - Timestamp Report Block (Section 4.3): A list of timestamps of 81 received RTP packets. 83 - Statistics Summary Report Block (Section 4.4): Statistics on RTP 84 packet sequence numbers, losses, duplicates, jitter, and TTL values. 86 - Receiver Timestamp Report Block (Section 4.5): Receiver-end 87 timestamps that complement the sender-end timestamps already defined 88 for RTCP. 90 - DLRR Report Block (Section 4.6): The delay since the last receiver 91 timestamp report block was received, allowing non-senders to 92 calculate round-trip times. 94 - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring 95 Voice over IP (VoIP) calls. 97 These blocks are defined within a minimal framework: a type field and 98 a length field are common to all XR blocks. The purpose is to 99 maintain flexibility and to keep overhead low. 0ther block formats, 100 beyond the seven defined here, may be defined within this framework 101 as the need arises. 103 1.1 Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [2] and 108 indicate requirement levels for compliance with this specification. 110 2. XR Packet Format 112 The XR packet consists of a header of two 32-bit words, followed by a 113 number, possibly zero, of extended report blocks. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 |V=2|P|reserved | PT=XP=205 | length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | SSRC/CSRC | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 : report blocks : 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 version (V): 2 bits 126 Identifies the version of RTP. This specification applies to RTP ver- 127 sion two (2). 129 padding (P): 1 bit 130 If the padding bit is set, this individual RTCP packet contains some 131 additional padding octets at the end that are not part of the control 132 information but are included in the length field. The last octet of 133 the padding is a count of how many padding octets should be ignored, 134 including itself (it will be a multiple of four). A full description 135 of padding in RTCP packets may be found in the RTP specification. 137 reserved: 5 bits 138 This field is reserved for future definition. In the absence of such 139 definition, the bits in this field MUST be set to zero and MUST be 140 ignored by the receiver. 142 packet type (PT): 8 bits 143 Contains the constant 205 to identify this as an RTCP XR packet. 144 This is a proposed value, pending assignment of a number by the 145 Internet Assigned Numbers Authority (IANA) [7]. 147 length: 16 bits 148 The length of this RTCP packet in 32-bit words minus one, including 149 the header and any padding. (The offset of one makes zero a valid 150 length and avoids a possible infinite loop in scanning a compound 151 RTCP packet, while counting 32-bit words avoids a validity check for 152 a multiple of 4.) 154 SSRC: 32 bits 155 The synchronization source identifier for the originator of this XR 156 packet. 158 report blocks: variable length. 159 Zero or more extended report blocks. Each block MUST be a multiple 160 of 32 bits long. A block MAY be zero bits long. 162 3. Extended Report Block Framework 164 Extended report blocks are stacked, one after the other, at the end 165 of an XR packet. An individual block's length is a multiple of 4 166 octets. The XR header's length field describes the total length of 167 the packet, including these extended report blocks. 169 Each block has block type and length fields that facilitate parsing. 170 A receiving application can demultiplex the blocks based upon their 171 type, and can use the length information to locate each successive 172 block, even in the presence of block types it does not recognize. 174 An extended report block has the following format: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | BT | type-specific | length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 : type-specific data : 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 block type (BT): 8 bits 185 Identifies the specific block format. 187 type-specific: 8 bits 188 The use of these bits is defined by the particular block type. 190 length: 16 bits 191 The length of this report block in 32-bit words minus one, including 192 the header. 194 type-specific data: variable length 195 This field MUST be a multiple of 32 bits long. It MAY be zero bits 196 long. 198 4. Specific Extended Report Blocks 200 This section defines seven extended report blocks: block types for 201 losses, duplicates, packet reception timestamps, detailed reception 202 statistics, receiver timestamps, receiver inter-report delays, and 203 VoIP metrics. An implementation MAY ignore incoming blocks with 204 types either not relevant or unknown to it. Additional block types 205 MUST be registered with the Internet Assigned Numbers Authority 206 (IANA) [7], as described in Section 5. 208 4.1 Loss RLE Report Block 210 This block type permits detailed reporting upon individual packet 211 receipt and loss events. Such reports could be used, for example, 212 for MINC inference [1] of the topology of the multicast tree used for 213 distributing a source's RTP packets, and of the loss rates along 214 links within that tree. Since a Boolean trace of lost and received 215 RTP packets is potentially lengthy, this block type permits the trace 216 to be compressed through run length encoding. 218 Each block reports on a single source, identified by its SSRC. The 219 receiver that is supplying the report is identified in the header of 220 the RTCP packet. 222 The beginning and ending RTP packet sequence numbers for the trace 223 are specified in the block, the ending sequence number being the last 224 sequence number in the trace plus one. The last sequence number in 225 the trace MAY differ from the sequence number reported on in any 226 accompanying SR or RR packet. 228 The ending sequence number MAY be less than the beginning sequence 229 number. This happens when the sequence numbers that are being 230 reported upon have wrapped around. However, a Loss RLE Block MUST 231 NOT be used to report upon a range of 65,534 or greater in the 232 sequence number space, as there is no means to identify multiple 233 wrap-arounds. 235 The encoding itself consists of a series of 16 bit chunks that 236 describe packet receipts or losses. Each chunk either specifies a 237 run length or a bit vector, or is a null chunk. A run length 238 describes between 1 and 16,383 events that are all the same (either 239 all receipts or all losses). A bit vector describes 15 events that 240 may be mixed receipts and losses. A null chunk describes no events, 241 and is used to to round out the block to a 32 bit word boundary. 243 The mapping from a sequence of lost and received packets into a 244 sequence of chunks is not necessarily unique. For example, the fol- 245 lowing trace covers 45 packets, of which the 22nd and 24th have been 246 lost and the others received: 248 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 250 One way to encode this would be: 252 bit vector 1111 1111 1111 111 253 bit vector 1111 1101 0111 111 254 bit vector 1111 1111 1111 111 255 null chunk 257 Another way to encode this would be: 259 run of 21 receipts 260 bit vector 0101 1111 1111 111 261 run of 9 receipts 262 null chunk 264 The choice of encoding is left to the application. As part of this 265 freedom of choice, applications MAY terminate a series of run length 266 and bit vector chunks with a bit vector chunk that runs beyond the 267 sequence number space described by the report block. For example, if 268 the 44th packet in the same sequence were lost: 270 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 272 This could be encoded as: 274 run of 21 receipts 275 bit vector 0101 1111 1111 111 276 bit vector 1111 1110 1000 000 277 null chunk 279 In this example, the last five bits of the second bit vector describe 280 a part of the sequence number space that extends beyond the last 281 sequence number in the trace. These bits have been set to zero. 283 All bits in a bit vector chunk that describe a part of the sequence 284 number space that extends beyond the last sequence number in the 285 trace MUST be set to zero and MUST be ignored by the receiver. 287 A null packet MUST appear at the end of a Loss RLE Block if the num- 288 ber of run length plus bit vector chunks is odd. The null chunk MUST 289 NOT appear in any other context. 291 Caution should be used in sending Loss RLE Blocks because, even with 292 the compression provided by run-length encoding, they can easily con- 293 sume bandwidth out of proportion with normal RTCP packets. The block 294 type includes a mechanism, called thinning, that allows an applica- 295 tion to limit report sizes. 297 A thinning value, T, selects a subset of packets within the sequence 298 number space: those with sequence numbers that are multiples of 2^T. 299 Packet reception and loss reports apply only to those packets. T can 300 vary between 0 and 15. If T is zero then every packet in the 301 sequence number space is reported upon. If T is fifteen then one in 302 every 32,768 packets is reported upon. 304 Suppose that the trace just described begins at sequence number 305 13,821. The last sequence number in the trace is 13,865. If the 306 trace were to be thinned with a thinning value of T=2, then the fol- 307 lowing sequence numbers would be reported upon: 13,824, 13,828, 308 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 309 13,864. The thinned trace would be as follows: 311 1 1 1 1 1 0 1 1 1 1 0 313 This could be encoded as follows: 315 bit vector 1111 1011 1100 000 316 null chunk 318 The last four bits in the bit vector, representing sequence numbers 319 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are 320 thus set to zero and are ignored by the receiver. With thinning, the 321 loss of the 22nd packet goes unreported because its sequence number, 322 13,842, is not a multiple of four. Packet receipts for all sequence 323 numbers that are not multiples of four also go unreported. However, 324 in this example thinning has permitted the Loss RLE Block to be 325 shortened by one 32 bit word. 327 Choice of the thinning value is left to the application. 329 The Loss RLE Block has the following format: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | BT=17 | rsvd. | T | block length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | SSRC of source | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | begin_seq | end_seq | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | chunk 1 | chunk 2 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 : : 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | chunk n-1 | chunk n | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 block type (BT): 8 bits 348 A Loss RLE block is identified by the constant 17. 350 rsvd.: 4 bits 351 This field is reserved for future definition. In the absence of such 352 definition, the bits in this field MUST be set to zero and receivers 353 MUST ignore this field. 355 thinning (T): 4 bits 356 The amount of thinning performed on the sequence number space. Only 357 those packets with sequence numbers 0 mod 2^T are reported on by this 358 block. A value of 0 indicates that there is no thinning, and all 359 packets are reported on. The maximum thinning is one packet in every 360 32,768 (amounting to two packets within each 16-bit sequence space). 362 length: 16 bits 363 Defined in Section 3. 365 begin_seq: 16 bits 366 The first sequence number that this block reports on. 368 end_seq: 16 bits 369 The last sequence number that this block reports on plus one. 371 chunk i: 16 bits 372 There are three chunk types: run length, bit vector, and terminating 373 null. If the chunk is all zeroes then it is a terminating null 374 chunk. Otherwise, the leftmost bit of the chunk determines its type: 375 0 for run length and 1 for bit vector. 377 4.1.1 Run-Length Chunk 379 0 1 380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 |C|R| run length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 chunk type (C): 1 bit 386 A zero identifies this as a runlength chunk. 388 run type (R): 1 bit 389 Zero indicates a run of losses. One indicates a run of received 390 packets. 392 run length: 14 bits 393 A value between 1 and 16,383. The value MUST not be zero (zeroes in 394 both the run type and run length fields would make the chunk a termi- 395 nating null chunk). Run lengths of 15 or less MAY be described with 396 a run length chunk despite the fact that they could also be described 397 as part of a bit vector chunk. 399 4.1.2 Bit Vector Chunk 400 0 1 401 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |C| bit vector | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 chunk type (C): 1 bit 407 A one identifies this as a bit vector chunk. 409 bit vector: 15 bits 410 The vector is read from left to right, in order of increasing 411 sequence number (with the appropriate allowance for wrap around). A 412 zero indicates a packet loss and a one indicates a received packet. 414 4.1.3 Terminating Null Chunk 416 This chunk is all zeroes. 418 0 1 419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 4.2 Duplicate RLE Report Block 426 This block type permits per-sequence-number reports on duplicates in 427 a source's RTP packet stream. Such information can be used for net- 428 work diagnosis, and provide an alternative to packet losses as a 429 basis for multicast tree topology inference. 431 The Duplicate RLE Block format is identical to the Loss RLE Block 432 format. Only the interpretation is different, in that the informa- 433 tion concerns packet duplicates rather than packet losses. The trace 434 to be encoded in this case also consists of zeros and ones, but a 435 zero here indicates the presence of duplicate packets for a given 436 sequence number, whereas a one indicates that no duplicates were 437 received. 439 The existence of a duplicate for a given sequence number is deter- 440 mined over the entire reporting period. For example, if packet num- 441 ber 12,593 arrives, followed by other packets with other sequence 442 numbers, the arrival later in the reporting period of another packet 443 numbered 12,593 counts as a duplicate for that sequence number. The 444 duplicate does not need to follow immediately upon the first packet 445 of that number. Care must be taken that a report does not cover a 446 range of 65,534 or greater in the sequence number space. 448 No distinction is made between the existance of a single duplicate 449 packet and multiple duplicate packets for a given sequence number. 450 Note also that since there is no duplicate for a lost packet, a loss 451 is encoded as a one in a Duplicate RLE Block. 453 The Duplicate RLE Block has the following format: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | BT=33 | rsvd. | T | length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | SSRC of source | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | begin_seq | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | end_seq | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | chunk 1 | chunk 2 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 : : 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | chunk n-1 | chunk n | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 block type (BT): 8 bits 474 A Duplicate RLE block is identified by the constant 33. 476 rsvd.: 4 bits 477 This field is reserved for future definition. In the absence of such 478 definition, the bits in this field MUST be set to zero and receivers 479 MUST ignore this field. 481 thinning (T): 4 bits 482 The amount of thinning performed on the sequence number space. 484 length: 16 bits 485 Defined in Section 3. 487 begin_seq: 32 bits 488 The first sequence number that this block reports on. 490 end_seq: 32 bits 491 The last sequence number that this block reports on plus one. 493 chunk i: 16 bits 494 There are three chunk types: run length, bit vector, and terminating 495 null. All zeroes indicates a terminating null. Otherwise, the left- 496 most bit of the chunk determines its type: 0 for run length and 1 for 497 bit vector. See the descriptions of these block types in the section 498 on the Loss RLE Block, above, for details. 500 4.3 Timestamp Report Block 502 This block type permits per-sequence-number reports on packet receipt 503 timestamps for a given source's RTP packet stream. Such information 504 can be used for MINC inference of the topology of the multicast tree 505 used to distribute the source's RTP packets, and of the delays along 506 the links within that tree. It can also be used to measure partial 507 path characteristics and to model distributions for packet jitter. 509 Timestamps consume more bits than loss or duplicate information, and 510 do not lend themselves to run length encoding. The use of thinning 511 is encouraged to limit the size of Timestamp Report Blocks. 513 The Timestamp Report Block has the following format: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | BT=48 | rsvd. | T | length | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | SSRC of source | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | begin_seq | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | end_seq | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | RTP timestamp 1 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | RTP timestamp 2 | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 : : 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | RTP timestamp n | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 block type (BT): 8 bits 535 A Timestamp Report Block is identified by the constant 48. 537 rsvd.: 4 bits 538 This field is reserved for future definition. In the absence of such 539 definition, the bits in this field MUST be set to zero and receivers 540 MUST ignore this field. 542 thinning (T): 4 bits 543 The amount of thinning performed on the sequence number space. 545 length: 16 bits 546 Defined in Section 3. 548 begin_seq: 32 bits 549 The first sequence number that this block reports on. 551 end_seq: 32 bits 552 The last sequence number that this block reports on plus one. 554 RTP timestamp i: 32 bits 555 The timestamp reflects the packet arrival time at the receiver. It 556 is preferable for the timestamp to be established at the link layer 557 interface, or in any case as close as possible to the wire arrival 558 time. Units and format are the same as for the timestamp in RTP data 559 packets. As opposed to RTP data packet timestamps, in which nominal 560 values may be used instead of system clock values in order to convey 561 information useful for periodic playout, the receiver timestamps 562 should reflect the actual time as closely as possible. The initial 563 value of the timestamp is random, and subsequent timestamps are off- 564 set from this value. 566 4.4 Statistics Summary Report Block 568 This block reports statistics beyond the information carried in the 569 standard RTCP packet format, but not as fine grained as that carried 570 in the report blocks previously described. Information is recorded 571 about lost packets, duplicate packets, jitter measurements, and TTL 572 values (TTL values being taken from the TTL field of IPv4 packets, if 573 the data packets are carried over IPv4). Such information can be 574 useful for network management. 576 The packet contents are dependent upon a bit vector carried in the 577 first part of the header. Not all values need to be carried in each 578 packet. Header fields for values not carried are not included in the 579 packet. 581 The Statistics Summary Report Block has the following format: 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | BT=1 |L|D|J|T|resvd. | length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | SSRC of source | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | begin_seq | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | end_seq | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | lost_packets | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | dup_packets | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | min_jitter | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | max_jitter | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | avg_jitter | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | dev_jitter | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | min_ttl | max_ttl | avg_ttl | dev_ttl | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 block type (BT): 8 bits 610 A Statistics Summary block is identified by the constant 1. 612 content bits (L,D,J,T): 4 bits 613 Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or 614 (T)TL report. 616 resvd.: 4 bits 617 This field is reserved for future definition. In the absence of such 618 definition, all bits in this field MUST be set to zero, and receivers 619 MUST ignore this field. 621 length: 16 bits 622 Defined in Section 3. 624 begin_seq: 32 bits 625 The first sequence number that this block reports on. 627 end_seq: 32 bits 628 The last sequence number that this block reports on plus one. 630 lost_packets: 32 bits 631 Number of lost packets in the above sequence number interval. 633 dup_packets: 32 bits 634 Number of duplicate packets in the above sequence number interval. 636 min_jitter: 32 bits 637 The minimum relative transit time between two packets in the above 638 sequence number interval. All jitter values are measured as the dif- 639 ference between a packet's RTP timestamp and the reporter's clock at 640 the time of arrival, measured in the same units. 642 max_jitter: 32 bits 643 The maximum relative transit time between two packets in the above 644 sequence number interval. 646 avg_jitter: 32 bits 647 The average relative transit time between each two packet series in 648 the above sequence number interval. 650 dev_jitter: 32 bits 651 The standard deviation of the relative transit time between each two 652 packet series in the above sequence number interval. 654 min_ttl: 8 bits 655 The minimum TTL value of data packets in sequence number range. 657 max_ttl: 8 bits 658 The maximum TTL value of data packets in sequence number range. 660 avg_ttl: 8 bits 661 The average TTL value of data packets in sequence number range. 663 dev_ttl: 8 bits 664 The standard deviation of TTL values of data packets in sequence num- 665 ber range. 667 4.5 Receiver Timestamp Report Block 669 This block extends RTCP's timestamp reporting so that non-senders may 670 also send timestamps. It recapitulates the NTP timestamp fields from 671 the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate 672 its RTT to other participants, as proposed in [9], by sending this 673 report block and receiving DLRR report blocks (see next section) in 674 reply. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | BT=2 | reserved | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | NTP timestamp, most significant word | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | NTP timestamp, least significant word | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 block type (BT): 8 bits 687 A Receiver Timestamp block is identified by the constant 2. 689 reserved: 24 bits 690 This field is reserved for future definition. In the absence of such 691 definition, the bits in this field MUST be set to zero, and receivers 692 MUST ignore this field. 694 NTP timestamp: 64 bits 695 Indicates the wallclock time when this block was sent so that it may 696 be used in combination with timestamps returned in DLRR report blocks 697 from other receivers to measure round-trip propagation to those 698 receivers. Receivers should expect that the measurement accuracy of 699 the timestamp may be limited to far less than the resolution of the 700 NTP timestamp. The measurement uncertainty of the timestamp is not 701 indicated as it may not be known. A report block sender that can keep 702 track of elapsed time but has no notion of wallclock time may use the 703 elapsed time since joining the session instead. This is assumed to be 704 less than 68 years, so the high bit will be zero. It is permissible 705 to use the sampling clock to estimate elapsed wallclock time. A 706 report sender that has no notion of wallclock or elapsed time may set 707 the NTP timestamp to zero. 709 4.6 DLRR Report Block 711 This block extends RTCP's DLSR mechanism [7, Sec. 6.3.1] so that non- 712 senders may also calculate round trip times, as proposed in [9]. It 713 is termed DLRR for Delay since Last Receiver Report, and may be sent 714 in response to a Receiver Timestamp report block (see previous sec- 715 tion) from a receiver to allow that receiver to calculate its round 716 trip time to the respondant. The report consists of one or more 3 717 word sub-blocks: one sub-block per receiver report. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | BT=3 | reserved | length | 723 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 724 | SSRC_1 (SSRC of first receiver) | sub- 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 726 | last RR (LRR) | 1 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | delay since last RR (DLRR) | 729 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 730 | SSRC_2 (SSRC of second receiver) | sub- 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 732 : ... : 2 733 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 735 block type (BT): 8 bits 736 A DLRR block is identified by the constant 3. 738 reserved: 8 bits 739 This field is reserved for future definition. In the absence of such 740 definition, all bits in this field MUST be set to zero, and receivers 741 MUST ignore this field. 743 length: 16 bits 744 Defined in Section 3. 746 last RR timestamp (LRR): 32 bits 747 The middle 32 bits out of 64 in the NTP timestamp (as explained in 748 the previous section) received as part of a Receiver Timestamp report 749 block from participant SSRC_n. If no such block has been received, 750 the field is set to zero. 752 delay since last RR (DLRR): 32 bits 753 The delay, expressed in units of 1/65536 seconds, between receiving 754 the last Receiver Timestamp report block from participant SSRC_n and 755 sending this DLRR report block. If no Receiver Timestamp report 756 block has been received yet from SSRC_n, the DLRR field is set to 757 zero (or the DLRR is omitted entirely). Let SSRC_r denote the 758 receiver issuing this DLRR report block. Participant SSRC_n can com- 759 pute the round-trip propagation delay to SSRC_r by recording the time 760 A when this Receiver Timestamp report block is received. It calcu- 761 lates the total round-trip time A-LSR using the last SR timestamp 762 (LSR) field, and then subtracting this field to leave the round-trip 763 propagation delay as (A- LSR - DLSR). This is illustrated in [7, Fig. 764 2]. 766 4.7 VoIP Metrics Report Block 768 4.7.1 Summary 770 The VoIP Metrics report block provides metrics for monitoring voice 771 over IP (VoIP) calls. These metrics include packet loss and discard 772 metrics, delay metrics, analog metrics, and voice quality metrics. 773 The block reports separately on packets lost on the IP channel, and 774 those that have been received but then discarded by the receiving 775 jitter buffer. It also reports on the combined effect of losses and 776 discards, as both have equal effect on call quality. 778 In order to properly assess the quality of a Voice over IP call it is 779 desirable to consider the degree of burstiness of packet loss [4]. 780 Following a Gilbert-Elliott model [5], an interval, bounded by lost 781 and/or discarded packets, with a high rate of losses and/or discards 782 is a "burst," and an interval between two bursts is a "gap." Bursts 783 correspond to intervals of time during which the packet loss rate is 784 high enough to produce noticeable degradation in audio quality. Gaps 785 correspond to periods of time during which only isolated lost packets 786 may occur, and in general these can be masked by packet loss con- 787 cealment. Delay reports include the transit delay between RTCP end 788 points and the VoIP end system processing delays, both of which con- 789 tribute to the user perceived delay. Additional metrics include sig- 790 nal, echo, noise, and distortion levels. Call quality metrics 791 include R factors (E Model) [5] and MOS scores (Mean Opinion Scores). 793 An implementation that sends these blocks SHOULD send at least one 794 every ten seconds for the duration of a call, and SHOULD send one 795 upon call termination. An implementation MUST supply values for all 796 fields defined here. 798 4.7.2 VoIP Metrics block structure 800 The block is encoded as seven 32-bit words: 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | BT=64 | reserved | length=6 | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | loss rate | discard rate | burst duration | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | burst density | gap duration | gap density | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | round trip delay | end system delay | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | signal power | doubletalk | noise level | Gmin | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | R factor | ext. R factor | MOS-LQ | MOS-CQ | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | RX Config | JB Nominal | JB Maximum | JB Abs Max | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 block type (BT): 8 bits 821 A VoIP Metrics block is identified by the constant 64. 823 reserved: 8 bits 824 This field is reserved for future definition. In the absence of such 825 definition, all bits in this field MUST be set to zero, and receivers 826 MUST ignore this field. 828 length: 16 bits 829 As defined in Section 3, this is the constant 6 for this block type. 831 4.7.3 Packet loss and discard metrics 833 It is very useful to distinguish between packets lost by the network 834 and those discarded due to jitter. Both have equal effect on the 835 quality of the voice stream however having separate counts helps 836 identify the source of quality degradation. These fields MUST be pop- 837 ulated. 839 loss rate: 8 bits 840 The fraction of RTP data packets from the source lost since the 841 beginning of reception, expressed as a fixed point number with the 842 binary point at the left edge of the field. This value is calculated 843 by dividing the total number of packets lost (after the effects of 844 applying any error protection such as FEC) by the total number of 845 packets expected, multiplying the result of the division by 256, and 846 taking the integer part. The numbers of duplicated packets and dis- 847 carded packets do not enter into this calculation. Since receivers 848 cannot be required to maintain unlimited buffers, a receiver MAY cat- 849 egorize late-arriving packets as lost. The degree of lateness that 850 triggers a loss SHOULD be significantly greater than that which trig- 851 gers a discard. 853 discard rate: 8 bits 854 The fraction of RTP data packets from the source that have been dis 855 carded since the beginning of reception, due to late or early 856 arrival, under-run or overflow at the receiving jitter buffer. This 857 value is expressed as a fixed point number with the binary point at 858 the left edge of the field. It is calculated by dividing the total 859 number of packets discarded (excluding duplicate packet discards) by 860 the total number of packets expected, multiplying the result of the 861 division by 256, and taking the integer part. 863 burst metrics: 864 A burst is defined as a longest sequence of packets bounded by lost 865 or discarded packets with the constraint that within a burst the num- 866 ber of successive packets that were received, and not discarded due 867 to delay variation, is less than some value Gmin. A gap is defined 868 as the interval between bursts, and has the property that any lost or 869 discarded packets must be preceded and followed by at least Gmin 870 packets that were received and not discarded. This gives a maximum 871 loss/discard density within a gap of: 1 / (Gmin + 1). 873 burst duration: 16 bits 874 The mean duration, expressed in milliseconds, of the burst intervals 875 that have occurred since the beginning of reception. The duration of 876 each interval is calculated based upon the packets that mark the 877 beginning and end of that interval. It is equal to the timestamp of 878 the end packet, plus the duration of the end packet, minus the times 879 tamp of the beginning packet. If the actual values are not avail 880 able, estimated values MUST be used. If there have been no burst 881 intervals, the burst duration value MUST be zero. 883 burst density: 8 bits 884 The fraction of RTP data packets within burst intervals since the 885 beginning of reception that were either lost or discarded. This 886 value is expressed as a fixed point number with the binary point at 887 the left edge of the field. It is calculated by dividing the total 888 number of packets lost or discarded (excluding duplicate packet dis- 889 cards) within burst intervals by the total number of packets expected 890 within the burst intervals, multiplying the result of the division by 891 256, and taking the integer part. 893 gap duration: 16 bits 894 The mean duration, expressed in milliseconds, of the gap intervals 895 that have occurred since the beginning of reception. The duration of 896 each interval is calculated based upon the packet that marks the end 897 of the prior burst and the packet that marks the beginning of the 898 subsequent burst. It is equal to the timestamp of the subsequent 899 burst packet, minus the timestamp of the prior burst packet, plus the 900 duration of the prior burst packet. If the actual values are not 901 available, estimated values MUST be used. In the case of a gap that 902 occurs at the beginning of reception, the sum of the timestamp of the 903 prior burst packet and the duration of the prior burst packet are 904 replaced by the reception start time. In the case of a gap that 905 occurs at the end of reception, the timestamp of the subsequent burst 906 packet is replaced by the reception end time. If there have been no 907 gap intervals, the gap duration value MUST be zero. 909 gap density: 8 bits 910 The fraction of RTP data packets within inter-burst gaps since the 911 beginning of reception that were either lost or discarded. The value 912 is expressed as a fixed point number with the binary point at the 913 left edge of the field. It is calculated by dividing the total num- 914 ber of packets lost or discarded (excluding duplicate packet dis 915 cards) within gap intervals by the total number of packets expected 916 within the gap intervals, multiplying the result of the division by 917 256, and taking the integer part. 919 For example, if the packet spacing is 10mS and a 1 denotes a received 920 packet and 0, a lost, and X, a discarded, packet then the following 921 pattern: 923 11110111111111111111111X111X1011110111111111111111111X111111111 924 |--burst---| 926 would have a burst duration of 120mS, a burst density of 0.33, a gap 927 duration of 510mS and a gap density of 0.04, for a GMIN value of 4 or 928 larger. 930 4.7.4 Delay metrics 932 For the purpose of the following definitions, the RTP interface is 933 the interface between the RTP instance and the voice application 934 (i.e. FEC/de-interleaving/ de-multiplexing, jitter buffer). For 935 example, the time delay due to RTP payload multiplexing would be con- 936 sidered to be part of the voice application or end-system delay 937 whereas delay due to multiplexing RTP frames within a UDP frame would 938 be considered part of the RTP reported delay. This distinction is 939 consistent with the use of RTCP for delay measurements. 941 round trip delay: 16 bits 942 The most recently calculated round trip time between RTP interfaces, 943 expressed in milliseconds. This value is the time of receipt of the 944 most recent RTCP packet from source SSRC, minus the LSR (last SR) 945 time reported in its SR (sender report), minus the DLSR (delay since 946 last SR) reported in its SR. A non-zero LSR value is REQUIRED in 947 order to calculate round trip delay. A value of 0 is permissible dur- 948 ing the first 2-3 RTCP exchanges as insufficient data may be avail- 949 able to determine delay however MUST be populated as soon as a delay 950 estimate is available. 952 end system delay: 16 bits 953 The most recently estimated end system delay, expressed in millisec- 954 onds. End system delay is defined as the total encoding, decoding 955 and jitter buffer delay determined at the reporting endpoint. This 956 is the time required for an RTP frame to be buffered, decoded, con- 957 verted to analog form, looped back at the local analog interface, 958 encoded, and made available for transmission as an RTP frame. The 959 manner in which this value is estimated is implementation dependent. 960 This parameter MUST be provided in all VoIP metrics reports. 962 Note that the one way symmetric VoIP segment delay may be calculated 963 from the round trip and end system delays as follows. If the round 964 trip delay is denoted RTD and the end system delays associated with 965 the two endpoints are ESD(A) and ESD(B) then: 967 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 969 4.7.5 Signal related metrics 971 The following metrics are intended to provide real time information 972 related to the non-packet elements of the voice over IP system to 973 assist with the identification of problems affecting call quality. 974 The values identified below must be determined for the received audio 975 signal. The information required to populate these fields may not be 976 available in all systems, although it is strongly recommended that 977 this data SHOULD be provided to support problem diagnosis. 979 signal level: 8 bits 980 The voice signal relative level is defined as the ratio of the signal 981 level to overflow signal level, expressed in decibels as a signed 982 integer in two's complement form. This is measured only for packets 983 containing speech energy. The intent of this metric is not to pro- 984 vide a precise measurement of the signal level but to provide a real 985 time indication that the signal level may be excessively high or low. 986 If the full range (overflow level) of the Vocoder's Digital to Analog 987 conversion function is +/- L and the value of a decoded sample during 988 a talkspurt is V then the signal level is given by 990 Signal level = 10 log10 ( mean( abs(V) / L ) ) 992 A value of 127 indicates that this parameter is unavailable. 994 doubletalk level: 8 bits 995 The doubletalk level is defined as the proportion of voice frame 996 intervals during which speech energy was present in both sending and 997 receiving directions. High levels of doubletalk can provide an indi- 998 cation of delay or echo related problems. The value is expressed as a 999 fixed point number with the binary point at the left edge of the 1000 field. It is calculated by dividing the total number of voice frame 1001 intervals by the number of voice frame intervals during which energy 1002 was present in both sending and receiving directions, multiplying 1003 the result of the division by 256, and taking the integer part. 1005 A value of 255 indicates that this value is unavailable 1007 noise level: 8 bits 1008 The noise level is defined as the ratio of the silent period back 1009 ground noise level to overflow signal power, expressed in decibels as 1010 a signed integer in two's complement form. If the full range (over- 1011 flow level) of the Vocoder's Digital to Analog conversion function is 1012 +/- L and the value of a decoded sample during a silence period is V 1013 then the noise level is given by 1015 Noise level = 10 log10 ( mean( abs(V) / L ) ) 1017 A value of 127 indicates that this parameter is unavailable. 1019 4.7.6 Call quality/ transmission quality metrics 1021 The following metrics are direct measures of the transmission quality 1022 or call quality, and incorporate the effects of CODEC type, packet 1023 loss, discard, burstiness, delay etc. These metrics may not be 1024 available in all systems however SHOULD be provided in order to sup- 1025 port problem diagnosis. 1027 R factor: 8 bits 1028 The R factor is a voice quality metric describing the segment of the 1029 call that is carried over this RTP session. It is expressed as an 1030 integer in the range 0 to 100, with a value of 94 corresponding to 1031 "toll quality" and values of 50 or less regarded as unusable. This 1032 metric is defined as including the effects of delay, consistent with 1033 ITU-T G.107 [6] and ETSI TS 101 329-5 [5]. 1035 A value of 127 indicates that this parameter is unavailable. 1037 ext. R factor: 8 bits 1038 The external R factor is a voice quality metric describing the seg 1039 ment of the call that is carried over a network segment external to 1040 the RTP segment, for example a cellular network. Its values are 1041 interpreted in the same manner as for the RTP R factor. This metric 1042 is defined as including the effects of delay, consistent with ITU-T 1043 G.107 [6] and ETSI TS 101 329-5 [5], and relates to the outward voice 1044 path from the Voice over IP termination for which this metrics block 1045 applies. 1047 Note that an overall R factor may be estimated from the RTP segment R 1048 factor and the external R factor, as follows: 1050 R total = RTP R factor + ext. R factor - 94 1052 A value of 127 indicates that this parameter is unavailable. 1054 MOS-LQ: 8 bits 1055 The estimated mean opinion score for listening quality (MOS-LQ) is a 1056 voice quality metric on a scale from 1 to 5, in which 5 represents 1057 excellent and 1 represents unacceptable. This metric is defined as 1058 not including the effects of delay and can be compared to MOS scores 1059 obtained from listening quality (ACR) tests. It is expressed as an 1060 integer in the range 10 to 50, corresponding to MOS x 10. For exam- 1061 ple, a value of 35 would correspond to an estimated MOS score of 3.5. 1063 A value of 127 indicates that this parameter is unavailable. 1065 MOS-CQ: 8 bits 1066 The estimated mean opinion score for conversational quality (MOS-CQ) 1067 is defined as including the effects of delay and other effects that 1068 would affect conversational quality. The metric may be calculated by 1069 converting an R factor determined according to ITU-T G.107 [6] or 1070 ETSI TS 101 329-5 [5] into an estimated MOS using the equation speci- 1071 fied in G.107 1073 A value of 127 indicates that this parameter is unavailable. 1075 4.7.7 Configuration parameters: 1077 Gmin: 8 bits 1078 The gap threshold. This field contains the value used for this 1079 report block to determine if a gap exists. The recommended value of 1080 16 (octal 0x10) corresponds to a burst interval having a minimum den- 1081 sity of 6.25% of lost or discarded packets, which may cause notice- 1082 able degradation in call quality; during gap intervals, if packet 1083 loss or dis card occurs, each lost or discarded packet would be pre- 1084 ceded by and followed by a sequence of at least 16 received non-dis- 1085 carded packets. Note that lost or discarded packets that occur 1086 within Gmin packets of a report being generated may be reclassified 1087 as being part of a burst or gap in later reports. ETSI TS 101 329-5 1088 [5] defines a computationally efficient algorithm for measuring burst 1089 and gap density using a packet loss/discard event driven approach. 1090 Gmin MUST not be zero and MUST be provided. 1092 Receiver Configuration byte: 1094 0 1 2 3 4 5 6 7 1095 +-+-+-+-+-+-+-+-+ 1096 |PLC|JBA|JB rate| 1097 +-+-+-+-+-+-+-+-+ 1099 PLC - packet loss concealment 1100 Standard (11) / enhanced (10) / disabled (01) / unspecified (00). 1101 When PLC=11 then a simple replay or interpolation algorithm is being 1102 used to fill-in the missing packet - this is typically able to con- 1103 ceal isolated lost packets with loss rates under 3%. When PLC=10 1104 then an enhanced interpolation algorithm is being used - this would 1105 typically be able to conceal lost packets for loss rates of 10% or 1106 more. When PLC=01 then silence is inserted in place of lost packets. 1107 When PLC = 00 then no information is available concerning the use of 1108 PLC however for some CODECs this may be inferred. 1110 JBA - Jitter Buffer Adaptive 1111 Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When 1112 Jitter Buffer is adaptive then its size is being dynamically adjusted 1113 to deal with varying levels of jitter. When non-adaptive then the 1114 Jitter Buffer size is maintained at a fixed level. When either adap- 1115 tive or non-adaptive modes are specified then the Jitter Buffer Size 1116 parameters below MUST be specified. 1118 JB Rate - Jitter Buffer Rate 1119 J = adjustment rate (0-15). This represents the implementation spe- 1120 cific adjustment rate of a Jitter Buffer in adaptive mode. This 1121 parameter is defined in terms of the approximate time taken to fully 1122 adjust to a step change in peak to peak jitter from 30mS to 100mS 1123 such that: 1125 adjustment time = 2* J * frame size (mS) 1127 This parameter is intended only to provide a guide to the degree of 1128 "aggressiveness" of a an adaptive jitter buffer and may be estimated. 1129 A value of 0 indicates that the adjustment time is unknown for this 1130 implementation. 1132 4.7.7 Jitter Buffer Parameters 1134 Jitter Buffer - nominal size in frames (8 bit) 1135 This is the current nominal fill point within the jitter buffer, 1136 which corresponds to the nominal jitter buffer delay for packets that 1137 arrive exactly on time. This parameter MUST be provided for both 1138 fixed and adaptive jitter buffer implementations. 1140 Jitter Buffer Maximum - size in frames (8 bit) 1141 This is the current maximum jitter buffer level corresponding to the 1142 earliest arriving packet that would not be discarded. In simple 1143 queue implementations this may correspond to the nominal size. In 1144 adaptive jitter buffer implementations this value may dynamically 1145 vary up to Jitter Buffer Absolute Maximum. This parameter MUST be 1146 provided for both fixed and adaptive jitter buffer implementations. 1148 Jitter Buffer Absolute Maximum - size in frames (8 bit) 1149 This is the absolute maximum size that the adaptive jitter buffer can 1150 reach under worst case jitter conditions. This parameter MUST be 1151 provided for adaptive jitter buffer implementations and its value 1152 MUST be set to JB Maximum for fixed jitter buffer implementations. 1154 Example of burst packet loss calculation. 1156 This is an event driven algorithm for measuring burst characteristics 1157 and is hence extremely computationally efficient. 1159 Given the following definition of states: 1161 State 1 = received a packet during a gap 1162 State 2 = received a packet during a burst 1163 State 3 = lost a packet during a burst 1164 State 4 = lost an isolated packet during a gap 1166 The "c" variables below correspond to state transition counts, i.e. 1167 c14 is the transition from state 1 to state 4. It is possible to 1168 infer one of a pair of state transition counts to an accuracy of 1 1169 which is generally sufficient for this application. "pkt" is the 1170 count of packets received since the last packet was declared lost or 1171 discarded and "lost" is the number of packets lost within the current 1172 burst. 1174 if ( packet_lost ) loss_count++; 1175 if ( packet_discarded ) discard_count++; 1176 if (pkt >= gmin) 1177 { 1178 if (lost == 1) 1179 c14++; 1180 else 1181 c13++; 1182 lost = 1; 1183 c11 += pkt; 1184 } 1185 else 1186 { 1187 lost++; 1188 if (pkt == 0) 1189 c33++; 1190 else 1191 { 1192 c23++; 1193 c22 += (pkt - 1); 1194 } 1195 } 1197 At each reporting interval the burst and gap metrics can be calcu- 1198 lated as follows. 1200 /* calculate additional transition counts */ 1201 c31 = c13; 1202 c32 = c23; 1203 ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; 1205 /* calculate burst and densities */ 1206 p32 = c32 / (c31 + c32 + c33); 1207 if ((c22 + c23) < 1) 1208 p23 = 1; 1209 else 1210 p23 = 1 - c22/(c22 + c23); 1211 burst_density = 256 * p23 / (p23 + p32); 1212 gap_density = 256 * c14 / (c11 + c14); 1214 /* calculate burst and gap durations in mS */ 1215 m = frameDuration_in_mS * framesPerRTPPkt; 1216 gap_length = (c11 + c14 + c13) * m / c13; 1217 burst_length = ctotal * m / c13 - lgap; 1219 /* calculate loss and discard densities */ 1220 loss_density = 256 * loss_count / ctotal; 1221 discard_density = 256 * discard_count / ctotal; 1223 5. IANA Considerations 1225 The extended report block type (BT) field defined by this document is 1226 a name space to be managed by the Internet Assigned Numbers Authority 1227 (IANA). The field contains eight bits, allowing 256 values, of which 1228 seven are defined here: 1230 1 (Statistics Summary Block, see Section 4.4) 1231 2 (Receiver Timestamp Report Block, see Section 4.5) 1232 3 (DLRR Report Block, see Section 4.6) 1233 17 (Loss RLE Block, see Section 4.1) 1234 33 (Duplicate RLE Block, see Section 4.2) 1235 48 (Timestamp Report Block, see Section 4.3) 1236 64 (VoIP Metrics Report Block, see Section 4.7) 1238 In addition, the value 0 is reserved for experimental use. 1240 No review is necessary by the IANA in order for it to record the 1241 assignment of additional numbers from this name space. Such numbers 1242 are to be assigned as part of the IETF standards process. 1244 6. Security Considerations 1246 This document extends the RTCP reporting mechanism, so all security 1247 considerations for RTCP reports also apply to the XR packets 1248 described here. This section details the additional security consid- 1249 erations that apply to the extensions. 1251 The extensions introduce heightened confidentiality concerns. Stan- 1252 dard RTCP reports contain a limited number of summary statistics. 1253 The information contained in XR reports is both more detailed and 1254 more extensive (covering a larger number of parameters). The per 1255 packet information contained in Loss RLE, Duplicate RLE, and Times- 1256 tamp Report Blocks facilitates MINC inference of multicast distribu- 1257 tion trees for RTP data packets, and inference of link characteris- 1258 tics such as loss and delay. This inference reveals information that 1259 might otherwise be considered confidential to autonomous system 1260 administrators. The VoIP Metrics Report Block provides information 1261 on the quality of ongoing voice calls. Though such information might 1262 be carried in application specific format in standard RTP sessions, 1263 making it available in a standard format here makes it more available 1264 to potential eavesdroppers. 1266 No new mechanisms are introduced in this document to ensure confiden- 1267 tiality. Already available authentification and encryption proce- 1268 dures should be used when confidentiality is a concern to end hosts. 1269 Autonomous system administrators concerned about the loss of confi- 1270 dentiality regarding their networks can filter traffic to exclude 1271 RTCP packets containing the XR report blocks concerned. 1273 The extensions also make certain denial of service attacks easier. 1274 This is because of the potential to create RTCP packets much larger 1275 than average with the per packet reporting capabilities of the Loss 1276 RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the 1277 automatic bandwidth adjustment mechanisms in RTCP, if some session 1278 participants are sending large RTCP packets, all participants will 1279 see their RTCP reporting intervals lengthened, meaning they will be 1280 able to report less frequently. 1282 No new mechanisms are introduced in this document to prevent such 1283 denial of service attacks. 1285 7. Acknowledgements 1287 We thank the following people: Colin Perkins, Steve Casner, and Hen- 1288 ning Schulzrinne for their considered guidance; Nick Duffield for 1289 extensive ongoing contributions; Sue Moon for helping foster collabo- 1290 ration between the authors of this document; and Mounir Benzaid for 1291 drawing our attention to the reporting needs of MLDA. 1293 8. Intellectual Property 1295 The IETF takes no position regarding the validity or scope of any 1296 intellectual property or other rights that might be claimed to per- 1297 tain to the implementation or use of the technology described in this 1298 document or the extent to which any license under such rights might 1299 or might not be available; neither does it represent that it has made 1300 any effort to identify any such rights. Information on the IETF's 1301 procedures with respect to rights in standards-track and standards- 1302 related documentation can be found in BCP 11 [7]. Copies of claims 1303 of rights made available for publication and any assurances of 1304 licenses to be made available, or the result of an attempt made to 1305 obtain a general license or permission for the use of such propri- 1306 etary rights by implementors or users of this specification can be 1307 obtained from the IETF Secretariat. 1309 The IETF invites any interested party to bring to its attention any 1310 copyrights, patents or patent applications, or other proprietary 1311 rights which may cover technology that may be required to practice 1312 this standard. Please address the information to the IETF Executive 1313 Director. 1315 9. References 1317 [1] A. Adams, T. Bu, R. Caceres, N.G. Duffield, T. Friedman, J. 1318 Horowitz, F. Lo Presti, S.B. Moon, V. Paxson, and D. Towsley, "The 1319 Use of End-to-End Multicast Measurements for Characterizing Internal 1320 Network Behavior," IEEE Communications Magazine, May 2000. 1322 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 1323 levels," BCP 14, RFC 2119, IETF, March 1997. 1325 [3] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measure- 1326 ment infrastructures using RTP," Proc. IEEE Infocom 2002. 1328 [4] A. D. Clark, "Modeling the Effects of Burst Packet Loss and 1329 Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 1330 2001. 1332 [5] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI 1333 TS 101 329-5 V1.1.1 (2000-11), November 2000. 1335 [6] ITU-T, "The E-Model, a computational model for use in transmis- 1336 sion planning," Recommendation G.107 (05/00), May 2000. 1338 [7] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700, 1339 IETF, October 1994. 1341 [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 1342 transport protocol for real-time applications," RFC 1889, IETF, 1343 February 1996. 1345 [9] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Con- 1346 trol Framework for Heterogeneous Multicast Environments", Proc. IWQoS 1347 2000. 1349 10. Full Copyright Statement 1351 Copyright (C) The Internet Society (2002). All Rights Reserved. 1353 This document and translations of it may be copied and furnished to 1354 others, and derivative works that comment on or otherwise explain it 1355 or assist in its implementation may be prepared, copied, published 1356 and distributed, in whole or in part, without restriction of any 1357 kind, provided that the above copyright notice and this paragraph are 1358 included on all such copies and derivative works. However, this doc- 1359 ument itself may not be modified in any way, such as by removing the 1360 copyright notice or references to the Internet Society or other 1361 Internet organizations, except as needed for the purpose of develop- 1362 ing Internet standards in which case the procedures for copyrights 1363 defined in the Internet Standards process must be followed, or as 1364 required to translate it into languages other than English. 1366 The limited permissions granted above are perpetual and will not be 1367 revoked by the Internet Society or its successors or assigns. 1369 This document and the information contained herein is provided on an 1370 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1371 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1372 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1373 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1374 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1376 9. Authors' Addresses 1378 Timur Friedman 1379 University of Paris 6 1380 Laboratoire LiP6-CNRS 1381 8, rue du Capitaine Scott 1382 75015 PARIS, FRANCE 1383 Ramon Caceres 1384 ShieldIP, Inc. 1385 11 West 42nd Street, 31st Floor 1386 New York, NY 10036, USA 1388 Kevin Almeroth 1389 Department of Computer Science 1390 University of California 1391 Santa Barbara, CA 93106, USA 1393 Kamil Sarac 1394 Department of Computer Science 1395 University of California 1396 Santa Barbara, CA 93106, USA 1398 Alan Clark 1399 Telchemy Incorporated 1400 3360 Martins Farm Road, Suite 200 1401 Suwanee, GA 30024 1402 Tel: +1 770 614-6944 1403 Fax: +1 770 614-3951 1405 Robert Cole 1406 AT&T Labs 1407 330 Saint Johns Street, 1408 2nd Floor 1409 Havre de Grace, MD, USA 21078 1410 Tel: +1 410 939-8732 1411 Fax: +1 410 939-8732 1413 Kaynam Hedayat 1414 Brix Networks 1415 285 Mill Road 1416 Chelmsford, MA 01824 1417 Tel: +1 978 367-5600 1418 Fax: +1 978 367-5700