idnits 2.17.1 draft-ietf-avt-rtcp-report-extns-00.txt: -(108): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(231): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(240): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(325): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(357): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(400): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(409): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(449): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(456): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(519): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(638): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(668): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(669): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(726): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(745): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(768): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(793): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(815): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(827): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(833): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(876): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(889): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(903): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(939): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(949): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(960): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(993): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1104): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1106): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1175): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1178): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1190): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 50 instances of lines with non-ascii characters in the document. == 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 666 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 = 0x10 corresponds to a burst interval having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degra� dation in call quality; during gap intervals, 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 [5] defines a computa� tionally 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 (16 October 2002) is 7863 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) -- 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: 8 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 16 October 2002 3 Internet Engineering Task Force Expires: 16 April 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-00.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 eight 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. For example, while a reception report block contains an 68 average loss rate field, an application might opt to use an extended 69 report block that details exactly which packets were received and 70 which were lost. Or, for example, a voice over IP application might 71 require information concerning packets that were discarded from the 72 jitter buffer, in addition to those that were lost. 74 The framework for these blocks is minimal: only a type field and a 75 length field are required. The purpose is to maintain flexibility 76 and to keep overhead low. While some specific block formats are 77 provided here, others may be defined as the need arises. 79 1.1 Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [2] and 84 indicate requirement levels for compliant RTP implementations. 86 2. XR Packet Format 88 The XR packet consists of a header of two 32-bit words, followed by a 89 number, possibly zero, of extended report blocks. 91 This packet format has been implemented as an RTCP APP (application- 92 specific) packet and deployed in the Internet, as described in [3] 93 and [1]. The differences between the APP packet header and the 94 header defined here are that the name field is removed and the 95 subtype field is replaced by a reserved field. 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 |V=2|P|reserved | PT=XP=205 | length | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | SSRC/CSRC | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 : report blocks : 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 version (V): 2 bits 108 Identifies the version of RTP. This specification applies to RTP ver� 109 sion two (2). 111 padding (P): 1 bit 112 If the padding bit is set, this individual RTCP packet contains some 113 additional padding octets at the end that are not part of the control 114 information but are included in the length field. The last octet of 115 the padding is a count of how many padding octets should be ignored, 116 including itself (it will be a multiple of four). A full description 117 of padding in RTCP packets may be found in the RTP specification. 119 reserved: 5 bits 120 This field is reserved for future definition. The bits in this field 121 MUST be set to zero unless otherwise defined. 123 packet type (PT): 8 bits 124 Contains the constant 205 to identify this as an RTCP XR packet. 125 This is a proposed value, pending assignment of a number by the 126 Internet Assigned Numbers Authority (IANA) [7]. 128 length: 16 bits 129 The length of this RTCP packet in 32-bit words minus one, including 130 the header and any padding. (The offset of one makes zero a valid 131 length and avoids a possible infinite loop in scanning a compound 132 RTCP packet, while counting 32-bit words avoids a validity check for 133 a multiple of 4.) 135 SSRC: 32 bits 136 The synchronization source identifier for the originator of this XR 137 packet. 139 report blocks: variable length. 140 Zero or more extended report blocks. The blocks MUST be a multiple 141 of 32 bits long. They MAY be zero bits long. 143 3. Extended Report Block Framework 145 Extended report blocks MUST be stacked, one after the other, at the 146 end of an XR packet. An individual block's length MUST be a multiple 147 of 4 octets. The XR header's length field MUST describe the total 148 length of the packet, including these extended report blocks. 150 Each block has block type and length fields that facilitate parsing. 151 A receiving application can demultiplex the blocks based upon their 152 type, and can use the length information to locate each successive 153 block, even in the presence of block types it does not recognize. 155 An extended report block has the following format: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | BT | type-specific | length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 : type-specific data : 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 block type (BT): 8 bits 166 Identifies the specific block format. 168 type-specific: 8 bits 169 The use of these bits is defined by the particular block type. 171 length: 16 bits 172 The length of this report block in 32-bit words minus one, including 173 the header. 175 type-specific data: variable length 176 This MUST be a multiple of 32 bits long. It MAY be zero bits long. 178 4. Specific Extended Report Blocks 180 This section defines eight extended report blocks: an experimental 181 block type, and block types for losses, duplicates, packet reception 182 timestamps, detailed reception statistics, receiver timestamps, 183 receiver inter-report delays, and VoIP metrics. An implementation 184 MAY ignore incoming blocks with types either not relevant or unknown 185 to it. Additional block types MAY be registered with the Internet 186 Assigned Numbers Authority (IANA) [7]. 188 4.1 Experimental Block 190 This type MUST be used for extended report block types that have not 191 been standardized. In addition to the standard type and length 192 fields, it includes a 32 bit name field that serves to distinguish 193 one experimental block type from another. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | BT=0 | app-specific | length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | name (ASCII) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 : application-specific data : 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 block type (BT): 8 bits 206 Block type 0 identifies this as an experimental block. 208 app-specific: 8 bits 209 The use of these bits is defined by the application that uses this 210 block. 212 length: 16 bits 213 The length of this report block in 32-bit words minus one, including 214 the header. 216 name: 4 octets 217 A name chosen by the person definining the experimental block to be 218 unique with respect to other experimental blocks the application 219 might receive. 221 application-specific data: variable length. 222 This MUST be a multiple of 32 bits long. It MAY be zero bits long. 224 4.2 Loss RLE Block 226 With this block type, a Boolean trace of lost and received packets 227 can be conveyed in compressed form using run length encoding. This 228 block type has been deployed on the Internet, as part of an RTCP APP 229 (application-specific) packet, as described in [3] and [1]. 231 Caution SHOULD be used in sending such blocks because, even with com� 232 pression, they can easily consume bandwidth out of proportion with 233 normal RTCP packets. 235 Each block reports on a single source, identified by its SSRC. The 236 receiver that is supplying the report is identified in the header of 237 the RTCP packet. 239 The beginning and ending sequence numbers for the trace are specified 240 in the block, the ending sequence number being the last sequence num� 241 ber in the trace plus one. The last sequence number in the trace MAY 242 or may not be the sequence number reported on accompanying SR or RR 243 packets, depending on the needs of the application. 245 The encoding itself consists of a series of 16 bit chunks. Each 246 chunk either specifies a run length or a bit vector, or, if the trace 247 otherwise encodes into an odd number of chunks, MUST be a terminating 248 null chunk used to round out the block to a 32 bit word boundary. 250 The mapping from a sequence of lost and received packets into a 251 sequence of chunks is not unique and is left to the application. A 252 run length chunk can describe runs of between 1 and 16,383 packet 253 losses or receipts whereas a bit vector chunk can describe a sequence 254 of 15 packet losses and receipts. It is RECOMMENDED that the 255 description of run lengths of 14 or shorter be subsumed into bit vec� 256 tor chunks, for purposes of brevity. 258 A bit vector chunk MAY purport to contain information on packets at 259 or beyond the ending sequence number. Any such purported information 260 MUST be ignored. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | BT=17 | rsvd. | T | block length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | SSRC of source | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | begin_seq | end_seq | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | chunk 1 | chunk 2 | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 : : 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | chunk n-1 | chunk n | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 block type (BT): 8 bits 279 A Loss RLE block is identified by the constant 17 = 0x11. 281 rsvd.: 4 bits 282 This field is reserved for future definition. The bits in this field 283 MUST be set to zero unless otherwise defined. 285 thinning (T): 4 bits 286 The amount of thinning performed on the sequence space. Only those 287 packets with sequence numbers 0 mod 2^T are reported on by this 288 block. A value of 0 indicates that there is no thinning, and all 289 packets are reported on. The maximum thinning is one packet in every 290 32,768 (amounting to two packets within each 16-bit sequence space). 292 length: 16 bits 293 The length of this report block in 32-bit words minus one, including 294 the header. 296 begin_seq: 16 bits 297 The first sequence number that this block reports on. 299 end_seq: 16 bits 300 The last sequence number that this block reports on plus one. 302 chunk i: 16 bits 303 There are three chunk types: run length, bit vector, and terminating 304 null. If the chunk is all zeroes then it is a terminating null 305 chunk. Otherwise, the leftmost bit of the chunk determines its type: 306 0 for run length and 1 for bit vector. 308 4.2.1 Run-Length Chunk 310 0 1 311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 |C|R| run length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 chunk type (C): 1 bit 317 A zero identifies this as a runlength chunk. 319 run type (R): 1 bit 320 Zero indicates a run of losses. One indicates a run of received 321 packets. 323 run length: 14 bits 324 A value between 1 and 16,383. The value MUST not be zero (zeroes in 325 both the run type and run length fields would make the chunk a termi� 326 nating null chunk). Run lengths of 15 or less MAY be described with 327 a run length chunk despite the fact that they could also be described 328 as part of a bit vector chunk. 330 4.2.2 Bit Vector Chunk 332 0 1 333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |C| bit vector | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 chunk type (C): 1 bit 339 A one identifies this as a bit vector chunk. 341 bit vector: 15 bits 342 In the bit vector, as in the run length chunk, a zero indicates a 343 loss and a one indicates a received packet. 345 4.2.3 Terminating Null Chunk 347 This chunk is all zeroes. 349 0 1 350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 4.3 Duplicate RLE Block 357 This block is identical in format to the Loss RLE Block type but car� 358 ries information about individual or runs of duplicate packets. A 359 zero indicates the presence of duplicate packets for a given sequence 360 number, whereas a one indicates that no duplicates were received. 361 Note that a packet loss is encoded as a one in this case. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | BT=33 | reserved | length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | SSRC of source | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | begin_seq | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | end_seq | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | chunk 1 | chunk 2 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 : : 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | chunk n-1 | chunk n | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 block type (BT): 8 bits 382 A Duplicate RLE block is identified by the constant 33 = 0x21. 384 reserved: 8 bits 385 This field is reserved for future definition All of the bits in this 386 field MUST be set to zero unless otherwise defined. 388 length: 16 bits 389 The length of this report block in 32-bit words minus one, including 390 the header. 392 begin_seq: 32 bits 393 The first sequence number that this block reports on. 395 end_seq: 32 bits 396 The last sequence number that this block reports on plus one. 398 chunk i: 16 bits 399 There are three chunk types: run length, bit vector, and terminating 400 null. All zeroes indicates a terminating null. Otherwise, the left� 401 most bit of the chunk determines its type: 0 for run length and 1 for 402 bit vector. See the descriptions of these block types in the section 403 on the Loss RLE Block, above, for details. 405 4.4 Timestamp Report Block 407 This block carries RTCP-style timestamps for each packet in the range 408 of packet sequence numbers. A similar caution, but more emphatic, is 409 made for timestamp report blocks as was made for Loss RLE Block pack� 410 ets. For each packet in the sequence number range, a 32 bit value 411 MUST be recorded and sent. This could easily consume significant 412 bandwidth. Care SHOULD be taken in the size of the sequence space 413 over which to monitor timestamps. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | BT=48 | reserved | length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | SSRC of source | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | begin_seq | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | end_seq | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | RTP timestamp (pkt n) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 : : 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 block type (BT): 8 bits 432 A Timestamp block is identified by the constant 48 = 0x30. 434 reserved: 8 bits 435 This field is reserved for future definition. All bits in this field 436 MUST be set to zero unless otherwise defined. 438 length: 16 bits 439 The length of this report block in 32-bit words minus one, including 440 the header. 442 begin_seq: 32 bits 443 The first sequence number that this block reports on. 445 end_seq: 32 bits 446 The last sequence number that this block reports on plus one. 448 RTP timestamp: 32 bits 449 Corresponds to the same units as the RTP timestamp in RTP data pack� 450 ets. The timestamp is established upon packet arrival. It can be 451 used to measure partial path characteristics and to model distribu� 452 tions for packet jitter. 454 4.5 Statistics Summary Block 456 This block reports detailed statistics above and beyond the informa� 457 tion carried in the standard RTCP packet format. Information is 458 recorded about lost packets, duplicate packets, jitter measurements, 459 and TTL values. The packet contents are dependent upon a bit vector 460 carried in the first part of the header. Not all values need to be 461 carried in each packet. Header fields for values not carried are not 462 included in the packet. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | BT=1 |L|D|J|T|resvd. | length | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | SSRC of source | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | begin_seq | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | end_seq | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | lost_packets | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | dup_packets | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | min_jitter | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | max_jitter | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | avg_jitter | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | dev_jitter | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | min_ttl | max_ttl | avg_ttl | dev_ttl | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 block type (BT): 8 bits 491 A Statistics Summary block is identified by the constant 1 = 0x01. 493 content bits (L,D,J,T): 4 bits 494 Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or 495 (T)TL report. 497 resvd.: 4 bits 498 This field is reserved for future definition. All bits in this field 499 MUST be set to zero unless otherwise defined. 501 length: 16 bits 502 The length of this report block in 32-bit words minus one, including 503 the header. 505 begin_seq: 32 bits 506 The first sequence number that this block reports on. 508 end_seq: 32 bits 509 The last sequence number that this block reports on plus one. 511 lost_packets: 32 bits 512 Number of lost packets in the above sequence number interval. 514 dup_packets: 32 bits 515 Number of duplicate packets in the above sequence number interval. 517 min_jitter: 32 bits 518 The minimum relative transit time between two packets in the above 519 sequence number interval. All jitter values are measured as the dif� 520 ference between a packet's RTP timestamp and the reporter's clock at 521 the time of arrival, measured in the same units. 523 max_jitter: 32 bits 524 The maximum relative transit time between two packets in the above 525 sequence number interval. 527 avg_jitter: 32 bits 528 The average relative transit time between each two packet series in 529 the above sequence number interval. 531 dev_jitter: 32 bits 532 The standard deviation of the relative transit time between each two 533 packet series in the above sequence number interval. 535 min_ttl: 8 bits 536 The minimum TTL value of data packets in sequence number range. 538 max_ttl: 8 bits 539 The maximum TTL value of data packets in sequence number range. 541 avg_ttl: 8 bits 542 The average TTL value of data packets in sequence number range. 544 dev_ttl: 8 bits 545 The standard deviation of TTL values of data packets in sequence num� 546 ber range. 548 4.6 Receiver Timestamp Report Block 550 This block extends RTCP's timestamp reporting so that non-senders may 551 also send timestamps. It recapitulates the NTP timestamp fields from 552 the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate 553 its RTT to other participants, as proposed in [9], by sending this 554 report block and receiving DLRR report blocks (see next section) in 555 reply. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | BT=2 | reserved | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | NTP timestamp, most significant word | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | NTP timestamp, least significant word | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 block type (BT): 8 bits 568 A Receiver Timestamp block is identified by the constant 2 = 0x02. 570 reserved: 24 bits 571 This field is reserved for future definition. The bits in this field 572 MUST be set to zero unless otherwise defined. 574 NTP timestamp: 64 bits 575 Indicates the wallclock time when this block was sent so that it may 576 be used in combination with timestamps returned in DLRR report blocks 577 from other receivers to measure round-trip propagation to those 578 receivers. Receivers should expect that the measurement accuracy of 579 the timestamp may be limited to far less than the resolution of the 580 NTP timestamp. The measurement uncertainty of the timestamp is not 581 indicated as it may not be known. A report block sender that can keep 582 track of elapsed time but has no notion of wallclock time may use the 583 elapsed time since joining the session instead. This is assumed to be 584 less than 68 years, so the high bit will be zero. It is permissible 585 to use the sampling clock to estimate elapsed wallclock time. A 586 report sender that has no notion of wallclock or elapsed time may set 587 the NTP timestamp to zero. 589 4.7 DLRR Report Block 591 This block extends RTCP's DLSR mechanism [7, Sec. 6.3.1] so that non- 592 senders may also calculate round trip times, as proposed in [9]. It 593 is termed DLRR for Delay since Last Receiver Report, and may be sent 594 in response to a Receiver Timestamp report block (see previous sec� 595 tion) from a receiver to allow that receiver to calculate its round 596 trip time to the respondant. The report consists of one or more 3 597 word sub-blocks: one sub-block per receiver report. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | BT=3 | reserved | length | 603 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 604 | SSRC_1 (SSRC of first receiver) | sub- 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 606 | last RR (LRR) | 1 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | delay since last RR (DLRR) | 609 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 610 | SSRC_2 (SSRC of second receiver) | sub- 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 612 : ... : 2 613 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 615 block type (BT): 8 bits 616 A DLRR block is identified by the constant 3 = 0x03. 618 reserved: 8 bits 619 This field is reserved for future definition. All bits in this field 620 MUST be set to zero unless otherwise defined. 622 length: 16 bits 623 The length of this report block in 32-bit words minus one, including 624 the header. The number of sub-blocks is length divided by three (3). 626 last RR timestamp (LRR): 32 bits 627 The middle 32 bits out of 64 in the NTP timestamp (as explained in 628 the previous section) received as part of a Receiver Timestamp report 629 block from participant SSRC_n. If no such block has been received, 630 the field is set to zero. 632 delay since last RR (DLRR): 32 bits 633 The delay, expressed in units of 1/65536 seconds, between receiving 634 the last Receiver Timestamp report block from participant SSRC_n and 635 sending this DLRR report block. If no Receiver Timestamp report 636 block has been received yet from SSRC_n, the DLRR field is set to 637 zero (or the DLRR is omitted entirely). Let SSRC_r denote the 638 receiver issuing this DLRR report block. Participant SSRC_n can com� 639 pute the round-trip propagation delay to SSRC_r by recording the time 640 A when this Receiver Timestamp report block is received. It calcu� 641 lates the total round-trip time A-LSR using the last SR timestamp 642 (LSR) field, and then subtracting this field to leave the round-trip 643 propagation delay as (A- LSR - DLSR). This is illustrated in [7, Fig. 644 2]. 646 4.8 VoIP Metrics Report Block 648 4.8.1 Summary 650 The VoIP Metrics report block provides metrics for monitoring voice 651 over IP (VoIP) calls. These metrics include packet loss and discard 652 metrics, delay metrics, analog metrics, and voice quality metrics. 653 The block reports separately on packets lost on the IP channel, and 654 those that have been received but then discarded by the receiving 655 jitter buffer. It also reports on the combined effect of losses and 656 discards, as both have equal effect on call quality. 658 In order to properly assess the quality of a Voice over IP call it is 659 desirable to consider the degree of burstiness of packet loss [4]. 660 Following a Gilbert-Elliott model [5], an interval, bounded by lost 661 and/or discarded packets, with a high rate of losses and/or discards 662 is a "burst," and an interval between two bursts is a "gap." Bursts 663 correspond to intervals of time during which the packet loss rate is 664 high enough to produce noticeable degradation in audio quality. Gaps 665 correspond to periods of time during which only isolated lost packets 666 may occur, and in general these can be masked by packet loss con� 667 cealment. Delay reports include the transit delay between RTCP end 668 points and the VoIP end system processing delays, both of which con� 669 tribute to the user perceived delay. Additional metrics include sig� 670 nal, echo, noise, and distortion levels. Call quality metrics 671 include R factors (E Model) [5] and MOS scores (Mean Opinion Scores). 673 An implementation that sends these blocks SHOULD send at least one 674 every ten seconds for the duration of a call, and SHOULD send one 675 upon call termination. An implementation MUST supply values for all 676 fields defined here. 678 4.8.2 VoIP Metrics block structure 680 The block is encoded as seven 32-bit words: 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | BT=64 | reserved | length=7 | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | loss rate | discard rate | burst duration | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | burst density | gap duration | gap density | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | round trip delay | end system delay | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | signal power | doubletalk | noise level | Gmin | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | R factor | ext. R factor | MOS-LQ | MOS-CQ | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | RX Config | JB Nominal | JB Maximum | JB Abs Max | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 block type (BT): 8 bits 701 A VoIP Metrics block is identified by the constant 64 = 0x40. 703 reserved: 8 bits 704 This field is reserved for future definition. All bits in this field 705 MUST be set to zero unless otherwise defined. 707 length: 16 bits 708 The length of this report block in 32-bit words minus one, including 709 the header. This is the constant 6 = 0x06. 711 4.8.3 Packet loss and discard metrics 713 It is very useful to distinguish between packets lost by the network 714 and those discarded due to jitter. Both have equal effect on the 715 quality of the voice stream however having separate counts is very 716 useful when trying to identify the source of quality degradation. 717 These fields MUST be populated. 719 loss rate: 8 bits 720 The fraction of RTP data packets from the source lost since the 721 beginning of reception, expressed as a fixed point number with the 722 binary point at the left edge of the field. This value is calculated 723 by dividing the total number of packets lost (after the effects of 724 applying any error protection such as FEC) by the total number of 725 packets expected, multiplying the result of the division by 256, and 726 taking the integer part. The numbers of duplicated packets and dis� 727 carded packets do not enter into this calculation. Since receivers 728 cannot be required to maintain unlimited buffers, a receiver MAY 729 categorize late-arriving packets as lost. The degree of lateness 730 that triggers a loss SHOULD be significantly greater than that which 731 triggers a discard. 733 discard rate: 8 bits 734 The fraction of RTP data packets from the source that have been dis 735 carded since the beginning of reception, due to late or early 736 arrival, under-run or overflow at the receiving jitter buffer. This 737 value is expressed as a fixed point number with the binary point at 738 the left edge of the field. It is calculated by dividing the total 739 number of packets discarded (excluding duplicate packet discards) by 740 the total number of packets expected, multiplying the result of the 741 division by 256, and taking the integer part. 743 burst metrics: 744 A burst is defined as a longest sequence of packets bounded by lost 745 or discarded packets with the constraint that within a burst the num� 746 ber of successive packets that were received, and not discarded due 747 to delay variation, is less than some value Gmin. A gap is defined 748 as the interval between bursts, and has the property that any lost or 749 discarded packets must be preceded and followed by at least Gmin 750 packets that were received and not discarded. This gives a maximum 751 loss/discard density within a gap of 1 / (Gmin + 1). 753 burst duration: 16 bits 754 The mean duration, expressed in milliseconds, of the burst intervals 755 that have occurred since the beginning of reception. The duration of 756 each interval is calculated based upon the packets that mark the 757 beginning and end of that interval. It is equal to the timestamp of 758 the end packet, plus the duration of the end packet, minus the times 759 tamp of the beginning packet. If the actual values are not avail 760 able, estimated values MUST be used. If there have been no burst 761 intervals, the burst duration value MUST be zero. 763 burst density: 8 bits 764 The fraction of RTP data packets within burst intervals since the 765 beginning of reception that were either lost or discarded. This 766 value is expressed as a fixed point number with the binary point at 767 the left edge of the field. It is calculated by dividing the total 768 number of packets lost or discarded (excluding duplicate packet dis� 769 cards) within burst intervals by the total number of packets expected 770 within the burst intervals, multiplying the result of the division by 771 256, and taking the integer part. 773 gap duration: 16 bits 774 The mean duration, expressed in milliseconds, of the gap intervals 775 that have occurred since the beginning of reception. The duration of 776 each interval is calculated based upon the packet that marks the end 777 of the prior burst and the packet that marks the beginning of the 778 subsequent burst. It is equal to the timestamp of the subsequent 779 burst packet, minus the timestamp of the prior burst packet, plus the 780 duration of the prior burst packet. If the actual values are not 781 available, estimated values MUST be used. In the case of a gap that 782 occurs at the beginning of reception, the sum of the timestamp of the 783 prior burst packet and the duration of the prior burst packet are 784 replaced by the reception start time. In the case of a gap that 785 occurs at the end of reception, the timestamp of the subsequent burst 786 packet is replaced by the reception end time. If there have been no 787 gap intervals, the gap duration value MUST be zero. 789 gap density: 8 bits 790 The fraction of RTP data packets within inter-burst gaps since the 791 beginning of reception that were either lost or discarded. The value 792 is expressed as a fixed point number with the binary point at the 793 left edge of the field. It is calculated by dividing the total num� 794 ber of packets lost or discarded (excluding duplicate packet dis 795 cards) within gap intervals by the total number of packets expected 796 within the gap intervals, multiplying the result of the division by 797 256, and taking the integer part. 799 For example, if the packet spacing is 10mS and a 1 denotes a received 800 packet and 0, a lost, and X, a discarded, packet then the following 801 pattern: 803 11110111111111111111111X111X1011110111111111111111111X111111111 804 |--burst---| 806 would have a burst duration of 120mS, a burst density of 0.33, a gap 807 duration of 510mS and a gap density of 0.04, for a GMIN value of 4 or 808 larger. 810 4.8.4 Delay metrics 812 For the purpose of the following definitions, the RTP interface is 813 the interface between the RTP instance and the voice application 814 (i.e. FEC/de-interleaving/ de-multiplexing, jitter buffer). For 815 example, the time delay due to RTP payload multiplexing would be con� 816 sidered to be part of the voice application or end-system delay 817 whereas delay due to multiplexing RTP frames within a UDP frame would 818 be considered part of the RTP reported delay. This distinction is 819 consistent with the use of RTCP for delay measurements. 821 round trip delay: 16 bits 822 The most recently calculated round trip time between RTP interfaces, 823 expressed in milliseconds. This value is the time of receipt of the 824 most recent RTCP packet from source SSRC, minus the LSR (last SR) 825 time reported in its SR (sender report), minus the DLSR (delay since 826 last SR) reported in its SR. A non-zero LSR value is REQUIRED in 827 order to calculate round trip delay. A value of 0 is permissible dur� 828 ing the first 2-3 RTCP exchanges as insufficient data may be avail� 829 able to determine delay however MUST be populated as soon as a delay 830 estimate is available. 832 end system delay: 16 bits 833 The most recently estimated end system delay, expressed in millisec� 834 onds. End system delay is defined as the total encoding, decoding 835 and jitter buffer delay determined at the reporting endpoint. This 836 is the time required for an RTP frame to be buffered, decoded, con� 837 verted to analog form, looped back at the local analog interface, 838 encoded, and made available for transmission as an RTP frame. The 839 manner in which this value is estimated is implementation dependent. 840 This parameter MUST be provided in all VoIP metrics reports. 842 Note that the one way symmetric VoIP segment delay may be calculated 843 from the round trip and end system delays as follows. If the round 844 trip delay is denoted RTD and the end system delays associated with 845 the two endpoints are ESD(A) and ESD(B) then: 847 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 849 4.8.5 Signal related metrics 851 The following metrics are intended to provide real time information 852 related to the non-packet elements of the voice over IP system to 853 assist with the identification of problems affecting call quality. 854 The values identified below must be determined for the received audio 855 signal. The information required to populate these fields may not be 856 available in all systems, although it is strongly recommended that 857 this data SHOULD be provided to support problem diagnosis. 859 signal level: 8 bits 860 The voice signal relative level is defined as the ratio of the signal 861 level to overflow signal level, expressed in decibels as a signed 862 integer in two's complement form. This is measured only for packets 863 containing speech energy. The intent of this metric is not to pro� 864 vide a precise measurement of the signal level but to provide a real 865 time indication that the signal level may be excessively high or low. 866 If the full range (overflow level) of the Vocoder's Digital to Analog 867 conversion function is +/- L and the value of a decoded sample during 868 a talkspurt is V then the signal level is given by 869 Signal level = 10 log10 ( mean( abs(V) / L ) ) 871 A value of 127 indicates that this parameter is unavailable. 873 doubletalk level: 8 bits 874 The doubletalk level is defined as the proportion of voice frame 875 intervals during which speech energy was present in both sending and 876 receiving directions. High levels of doubletalk can provide an indi� 877 cation of delay or echo related problems. The value is expressed as a 878 fixed point number with the binary point at the left edge of the 879 field. It is calculated by dividing the total number of voice frame 880 intervals by the number of voice frame intervals during which energy 881 was present in both sending and receiving directions, multiplying 882 the result of the division by 256, and taking the integer part. 884 A value of 255 indicates that this value is unavailable 886 noise level: 8 bits 887 The noise level is defined as the ratio of the silent period back 888 ground noise level to overflow signal power, expressed in decibels as 889 a signed integer in two's complement form. If the full range (over� 890 flow level) of the Vocoder's Digital to Analog conversion function is 891 +/- L and the value of a decoded sample during a silence period is V 892 then the noise level is given by 894 Noise level = 10 log10 ( mean( abs(V) / L ) ) 896 A value of 127 indicates that this parameter is unavailable. 898 4.8.6 Call quality/ transmission quality metrics 900 The following metrics are direct measures of the transmission quality 901 or call quality, and incorporate the effects of CODEC type, packet 902 loss, discard, burstiness, delay etc. These metrics may not be 903 available in all systems however SHOULD be provided in order to sup� 904 port problem diagnosis. 906 R factor: 8 bits 907 The R factor is a voice quality metric describing the segment of the 908 call that is carried over this RTP session. It is expressed as an 909 integer in the range 0 to 100, with a value of 94 corresponding to 910 "toll quality" and values of 50 or less regarded as unusable. This 911 metric is defined as including the effects of delay, consistent with 912 ITU-T G.107 [6] and ETSI TS 101 329-5 [5]. 914 A value of 127 indicates that this parameter is unavailable. 916 ext. R factor: 8 bits 917 The external R factor is a voice quality metric describing the seg 918 ment of the call that is carried over a network segment external to 919 the RTP segment, for example a cellular network. Its values are 920 interpreted in the same manner as for the RTP R factor. This metric 921 is defined as including the effects of delay, consistent with ITU-T 922 G.107 [6] and ETSI TS 101 329-5 [5], and relates to the outward voice 923 path from the Voice over IP termination for which this metrics block 924 applies. 926 Note that an overall R factor may be estimated from the RTP segment R 927 factor and the external R factor, as follows: 929 R total = RTP R factor + ext. R factor - 94 931 A value of 127 indicates that this parameter is unavailable. 933 MOS-LQ: 8 bits 934 The estimated mean opinion score for listening quality (MOS-LQ) is a 935 voice quality metric on a scale from 1 to 5, in which 5 represents 936 excellent and 1 represents unacceptable. This metric is defined as 937 not including the effects of delay and can be compared to MOS scores 938 obtained from listening quality (ACR) tests. It is expressed as an 939 integer in the range 10 to 50, corresponding to MOS x 10. For exam� 940 ple, a value of 35 would correspond to an estimated MOS score of 3.5. 942 A value of 127 indicates that this parameter is unavailable. 944 MOS-CQ: 8 bits 945 The estimated mean opinion score for conversational quality (MOS-CQ) 946 is defined as including the effects of delay and other effects that 947 would affect conversational quality. The metric may be calculated by 948 converting an R factor determined according to ITU-T G.107 [6] or 949 ETSI TS 101 329-5 [5] into an estimated MOS using the equation speci� 950 fied in G.107 952 A value of 127 indicates that this parameter is unavailable. 954 4.8.7 Configuration parameters: 956 Gmin: 8 bits 957 The gap threshold. This field contains the value used for this 958 report block to determine if a gap exists. The recommended value of 959 16 = 0x10 corresponds to a burst interval having a minimum density of 960 6.25% of lost or discarded packets, which may cause noticeable degra� 961 dation in call quality; during gap intervals, if packet loss or dis 962 card occurs, each lost or discarded packet would be preceded by and 963 followed by a sequence of at least 16 received non-discarded packets. 964 Note that lost or discarded packets that occur within Gmin packets of 965 a report being generated may be reclassified as being part of a burst 966 or gap in later reports. ETSI TS 101 329-5 [5] defines a computa� 967 tionally efficient algorithm for measuring burst and gap density 968 using a packet loss/discard event driven approach. Gmin MUST not be 969 zero and MUST be provided. 971 Receiver Configuration byte: 973 0 1 2 3 4 5 6 7 974 +-+-+-+-+-+-+-+-+ 975 |PLC|JBA|JB rate| 976 +-+-+-+-+-+-+-+-+ 978 PLC - packet loss concealment 979 Standard (11) / enhanced (10) / disabled (01) / unspecified (00). 980 When PLC=11 then a simple replay or interpolation algorithm is being 981 used to fill-in the missing packet - this is typically able to con� 982 ceal isolated lost packets with loss rates under 3%. When PLC=10 983 then an enhanced interpolation algorithm is being used - this would 984 typically be able to conceal lost packets for loss rates of 10% or 985 more. When PLC=01 then silence is inserted in place of lost packets. 986 When PLC = 00 then no information is available concerning the use of 987 PLC however for some CODECs this may be inferred. 989 JBA - Jitter Buffer Adaptive 990 Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When 991 Jitter Buffer is adaptive then its size is being dynamically adjusted 992 to deal with varying levels of jitter. When non-adaptive then the 993 Jitter Buffer size is maintained at a fixed level. When either adap� 994 tive or non-adaptive modes are specified then the Jitter Buffer Size 995 parameters below MUST be specified. 997 JB Rate - Jitter Buffer Rate 998 J = adjustment rate (0-15). This represents the implementation spe� 999 cific adjustment rate of a Jitter Buffer in adaptive mode. This 1000 parameter is defined in terms of the approximate time taken to fully 1001 adjust to a step change in peak to peak jitter from 30mS to 100mS 1002 such that: 1004 adjustment time = 2* J * frame size (mS) 1006 This parameter is intended only to provide a guide to the degree of 1007 "aggressiveness" of a an adaptive jitter buffer and may be estimated. 1008 A value of 0 indicates that the adjustment time is unknown for this 1009 implementation. 1011 4.8.7 Jitter Buffer Parameters 1013 Jitter Buffer - nominal size in frames (8 bit) 1014 This is the current nominal fill point within the jitter buffer, 1015 which corresponds to the nominal jitter buffer delay for packets that 1016 arrive exactly on time. This parameter MUST be provided for both 1017 fixed and adaptive jitter buffer implementations. 1019 Jitter Buffer Maximum - size in frames (8 bit) 1020 This is the current maximum jitter buffer level corresponding to the 1021 earliest arriving packet that would not be discarded. In simple 1022 queue implementations this may correspond to the nominal size. In 1023 adaptive jitter buffer implementations this value may dynamically 1024 vary up to Jitter Buffer Absolute Maximum. This parameter MUST be 1025 provided for both fixed and adaptive jitter buffer implementations. 1027 Jitter Buffer Absolute Maximum - size in frames (8 bit) 1028 This is the absolute maximum size that the adaptive jitter buffer can 1029 reach under worst case jitter conditions. This parameter MUST be 1030 provided for adaptive jitter buffer implementations and its value 1031 MUST be set to JB Maximum for fixed jitter buffer implementations. 1033 Example of burst packet loss calculation. 1035 This is an event driven algorithm for measuring burst characteristics 1036 and is hence extremely computationally efficient. 1038 Given the following definition of states: 1040 State 1 = received a packet during a gap 1041 State 2 = received a packet during a burst 1042 State 3 = lost a packet during a burst 1043 State 4 = lost an isolated packet during a gap 1045 The "c" variables below correspond to state transition counts, i.e. 1046 c14 is the transition from state 1 to state 4. It is possible to 1047 infer one of a pair of state transition counts to an accuracy of 1 1048 which is generally sufficient for this application. "pkt" is the 1049 count of packets received since the last packet was declared lost or 1050 discarded and "lost" is the number of packets lost within the current 1051 burst. 1053 if ( packet_lost ) loss_count++; 1054 if ( packet_discarded ) discard_count++; 1055 if (pkt >= gmin) 1056 { 1057 if (lost == 1) 1058 c14++; 1059 else 1060 c13++; 1061 lost = 1; 1062 c11 += pkt; 1063 } 1064 else 1065 { 1066 lost++; 1067 if (pkt == 0) 1068 c33++; 1069 else 1070 { 1071 c23++; 1072 c22 += (pkt - 1); 1073 } 1074 } 1076 At each reporting interval the burst and gap metrics can be calcu� 1077 lated as follows. 1079 /* calculate additional transition counts */ 1080 c31 = c13; 1081 c32 = c23; 1082 ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; 1084 /* calculate burst and densities */ 1085 p32 = c32 / (c31 + c32 + c33); 1086 if ((c22 + c23) < 1) 1087 p23 = 1; 1088 else 1089 p23 = 1 - c22/(c22 + c23); 1090 burst_density = 256 * p23 / (p23 + p32); 1091 gap_density = 256 * c14 / (c11 + c14); 1093 /* calculate burst and gap durations in mS */ 1094 m = frameDuration_in_mS * framesPerRTPPkt; 1095 gap_length = (c11 + c14 + c13) * m / c13; 1096 burst_length = ctotal * m / c13 - lgap; 1098 /* calculate loss and discard densities */ 1099 loss_density = 256 * loss_count / ctotal; 1100 discard_density = 256 * discard_count / ctotal; 1102 5. Acknowledgements 1104 We thank the following people: Colin Perkins, Steve Casner, and Hen� 1105 ning Schulzrinne for their considered guidance; Nick Duffield for 1106 extensive ongoing contributions; Sue Moon for helping foster collabo� 1107 ration between the authors of this document; and Mounir Benzaid for 1108 drawing our attention to the reporting needs of MLDA. 1110 6. Intellectual Property 1112 The IETF takes no position regarding the validity or scope of any 1113 intellectual property or other rights that might be claimed to per� 1114 tain to the implementation or use of the technology described in this 1115 document or the extent to which any license under such rights might 1116 or might not be available; neither does it represent that it has made 1117 any effort to identify any such rights. Information on the IETF's 1118 procedures with respect to rights in standards-track and standards- 1119 related documentation can be found in BCP 11 [7]. Copies of claims 1120 of rights made available for publication and any assurances of 1121 licenses to be made available, or the result of an attempt made to 1122 obtain a general license or permission for the use of such propri� 1123 etary rights by implementors or users of this specification can be 1124 obtained from the IETF Secretariat. 1126 The IETF invites any interested party to bring to its attention any 1127 copyrights, patents or patent applications, or other proprietary 1128 rights which may cover technology that may be required to practice 1129 this standard. Please address the information to the IETF Executive 1130 Director. 1132 7. References 1134 [1] A. Adams, T. Bu, R. Caceres, N.G. Duffield, T. Friedman, J. 1135 Horowitz, F. Lo Presti, S.B. Moon, V. Paxson, and D. Towsley, "The 1136 Use of End-to-End Multicast Measurements for Characterizing Internal 1137 Network Behavior," IEEE Communications Magazine, May 2000. 1139 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 1140 levels," BCP 14, RFC 2119, IETF, March 1997. 1142 [3] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measure� 1143 ment infrastructures using RTP," Proc. IEEE Infocom 2002. 1145 [4] A. D. Clark, "Modeling the Effects of Burst Packet Loss and 1146 Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 1147 2001. 1149 [5] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI 1150 TS 101 329-5 V1.1.1 (2000-11), November 2000. 1152 [6] ITU-T, "The E-Model, a computational model for use in transmis� 1153 sion planning," Recommendation G.107 (05/00), May 2000. 1155 [7] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700, 1156 IETF, October 1994. 1158 [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 1159 transport protocol for real-time applications," RFC 1889, IETF, 1160 February 1996. 1162 [9] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Con� 1163 trol Framework for Heterogeneous Multicast Environments", Proc. IWQoS 1164 2000. 1166 8. Full Copyright Statement 1168 Copyright (C) The Internet Society (2002). All Rights Reserved. 1170 This document and translations of it may be copied and furnished to 1171 others, and derivative works that comment on or otherwise explain it 1172 or assist in its implementation may be prepared, copied, published 1173 and distributed, in whole or in part, without restriction of any 1174 kind, provided that the above copyright notice and this paragraph are 1175 included on all such copies and derivative works. However, this doc� 1176 ument itself may not be modified in any way, such as by removing the 1177 copyright notice or references to the Internet Society or other 1178 Internet organizations, except as needed for the purpose of develop� 1179 ing Internet standards in which case the procedures for copyrights 1180 defined in the Internet Standards process must be followed, or as 1181 required to translate it into languages other than English. 1183 The limited permissions granted above are perpetual and will not be 1184 revoked by the Internet Society or its successors or assigns. 1186 This document and the information contained herein is provided on an 1187 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1188 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1189 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1190 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER� 1191 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1193 9. Authors' Addresses 1195 Timur Friedman 1196 University of Paris 6 1197 Laboratoire LiP6-CNRS 1198 8, rue du Capitaine Scott 1199 75015 PARIS, FRANCE 1201 Ramon Caceres 1202 ShieldIP, Inc. 1203 11 West 42nd Street, 31st Floor 1204 New York, NY 10036, USA 1206 Kevin Almeroth 1207 Department of Computer Science 1208 University of California 1209 Santa Barbara, CA 93106, USA 1211 Kamil Sarac 1212 Department of Computer Science 1213 University of California 1214 Santa Barbara, CA 93106, USA 1215 Alan Clark 1216 Telchemy Incorporated 1217 3360 Martins Farm Road, Suite 200 1218 Suwanee, GA 30024 1219 Tel: +1 770 614-6944 1220 Fax: +1 770 614-3951 1222 Robert Cole 1223 AT&T Labs 1224 330 Saint Johns Street, 1225 2nd Floor 1226 Havre de Grace, MD, USA 21078 1227 Tel: +1 410 939-8732 1228 Fax: +1 410 939-8732 1230 Kaynam Hedayat 1231 Brix Networks 1232 285 Mill Road 1233 Chelmsford, MA 01824 1234 Tel: +1 978 367-5600 1235 Fax: +1 978 367-5700 1237 10. Expiry 1239 This draft expires 18 January 2003.