[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-friedman-avt-rtcp-report-extns) 00 01 02 03 04 05 06 RFC 3611

INTERNET-DRAFT                                           3 November 2002
Internet Engineering Task Force                      Expires: 3 May 2003
Audio/Video Transport Working Group

                                                 Timur Friedman, Paris 6
                                                 Ramon Caceres, ShieldIP
                                                    Kevin Almeroth, UCSB
                                                       Kamil Sarac, UCSB
                                                    Alan Clark, Telchemy
                                                       Robert Cole, AT&T
                                           Kaynam Hedayat, Brix Networks

                       RTCP Reporting Extensions

                draft-ietf-avt-rtcp-report-extns-01.txt


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines the XR (extended report) RTCP packet type and
   seven XR block types. The purpose of the extended reporting format is
   to convey information that supplements the six statistics that are
   contained in the report blocks used by SR (sender report) and RR



Friedman et al.                                                 [Page 1]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   (receiver report) packets.  Some applications, such as MINC
   (multicast inference of network characteristics) or VoIP (voice over
   IP) monitoring, require other and more detailed statistics.  In
   addition to the block types defined here, additional block types may
   be defined in the future by adhereing to the simple framework that
   this document provides.

1. Introduction

   This document defines the XR (extended report) RTCP packet type for
   RTCP, the control portion of RTP [8].  The definition consists of
   three parts.  First, Section 2 of this document defines a general
   packet framework capable of including a number of different "extended
   report blocks."  Second, Section 3 defines the general format for
   such blocks.  Third, Section 4 defines a number of such blocks.

   The extended report blocks convey information beyond that which is
   already contained in the reception report blocks of RTCP's SR or RR
   packets. XR report blocks carry information that is not appropriately
   carried in SR or RR profile-specific extensions because it is of use
   across profiles.  Information that is useful to network management
   falls into this category, for instance.

   Seven report block formats are defined by this document:

   - Loss RLE Report Block (Section 4.1): Run-length encoding of RTP
   packet loss reports.

   - Duplicate RLE Report Block (Section 4.2): Run-length encoding of
   reports of RTP packet duplicates.

   - Timestamp Report Block (Section 4.3): A list of timestamps of
   received RTP packets.

   - Statistics Summary Report Block (Section 4.4): Statistics on RTP
   packet sequence numbers, losses, duplicates, jitter, and TTL values.

   - Receiver Timestamp Report Block (Section 4.5): Receiver-end
   timestamps that complement the sender-end timestamps already defined
   for RTCP.

   - DLRR Report Block (Section 4.6): The delay since the last receiver
   timestamp report block was received, allowing non-senders to
   calculate round-trip times.

   - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
   Voice over IP (VoIP) calls.




Friedman et al.                                                 [Page 2]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   These blocks are defined within a minimal framework: a type field and
   a length field are common to all XR blocks.  The purpose is to
   maintain flexibility and to keep overhead low.  0ther block formats,
   beyond the seven defined here, may be defined within this framework
   as the need arises.


1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for compliance with this specification.


2. XR Packet Format

   The XR packet consists of a header of two 32-bit words, followed by a
   number, possibly zero, of extended report blocks.


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved |   PT=XP=205   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         report blocks                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


version (V): 2 bits
   Identifies the version of RTP. This specification applies to RTP ver-
   sion two (2).

padding (P): 1 bit
   If the padding bit is set, this individual RTCP packet contains some
   additional padding octets at the end that are not part of the control
   information but are included in the length field. The last octet of
   the padding is a count of how many padding octets should be ignored,
   including itself (it will be a multiple of four).  A full description
   of padding in RTCP packets may be found in the RTP specification.

reserved: 5 bits
   This field is reserved for future definition.  In the absence of such
   definition, the bits in this field MUST be set to zero and MUST be
   ignored by the receiver.



Friedman et al.                                                 [Page 3]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


packet type (PT): 8 bits
   Contains the constant 205 to identify this as an RTCP XR packet.
   This is a proposed value, pending assignment of a number by the
   Internet Assigned Numbers Authority (IANA) [7].

length: 16 bits
   The length of this RTCP packet in 32-bit words minus one, including
   the header and any padding. (The offset of one makes zero a valid
   length and avoids a possible infinite loop in scanning a compound
   RTCP packet, while counting 32-bit words avoids a validity check for
   a multiple of 4.)

SSRC: 32 bits
   The synchronization source identifier for the originator of this XR
   packet.

report blocks: variable length.
   Zero or more extended report blocks.  Each block MUST be a multiple
   of 32 bits long.  A block MAY be zero bits long.


3. Extended Report Block Framework

   Extended report blocks are stacked, one after the other, at the end
   of an XR packet.  An individual block's length is a multiple of 4
   octets.  The XR header's length field describes the total length of
   the packet, including these extended report blocks.

   Each block has block type and length fields that facilitate parsing.
   A receiving application can demultiplex the blocks based upon their
   type, and can use the length information to locate each successive
   block, even in the presence of block types it does not recognize.

   An extended report block has the following format:


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      BT       | type-specific |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                      type-specific data                       :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


block type (BT): 8 bits
   Identifies the specific block format.




Friedman et al.                                                 [Page 4]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


type-specific: 8 bits
   The use of these bits is defined by the particular block type.

length: 16 bits
   The length of this report block in 32-bit words minus one, including
   the header.

type-specific data: variable length
   This field MUST be a multiple of 32 bits long.  It MAY be zero bits
   long.


4. Specific Extended Report Blocks

   This section defines seven extended report blocks: block types for
   losses, duplicates, packet reception timestamps, detailed reception
   statistics, receiver timestamps, receiver inter-report delays, and
   VoIP metrics.  An implementation MAY ignore incoming blocks with
   types either not relevant or unknown to it. Additional block types
   MUST be registered with the Internet Assigned Numbers Authority
   (IANA) [7], as described in Section 5.


4.1 Loss RLE Report Block

   This block type permits detailed reporting upon individual packet
   receipt and loss events.  Such reports could be used, for example,
   for MINC inference [1] of the topology of the multicast tree used for
   distributing a source's RTP packets, and of the loss rates along
   links within that tree.  Since a Boolean trace of lost and received
   RTP packets is potentially lengthy, this block type permits the trace
   to be compressed through run length encoding.

   Each block reports on a single source, identified by its SSRC.  The
   receiver that is supplying the report is identified in the header of
   the RTCP packet.

   The beginning and ending RTP packet sequence numbers for the trace
   are specified in the block, the ending sequence number being the last
   sequence number in the trace plus one.  The last sequence number in
   the trace MAY differ from the sequence number reported on in any
   accompanying SR or RR packet.

   The ending sequence number MAY be less than the beginning sequence
   number.  This happens when the sequence numbers that are being
   reported upon have wrapped around.  However, a Loss RLE Block MUST
   NOT be used to report upon a range of 65,534 or greater in the
   sequence number space, as there is no means to identify multiple



Friedman et al.                                                 [Page 5]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   wrap-arounds.

   The encoding itself consists of a series of 16 bit chunks that
   describe packet receipts or losses.  Each chunk either specifies a
   run length or a bit vector, or is a null chunk.  A run length
   describes between 1 and 16,383 events that are all the same (either
   all receipts or all losses).  A bit vector describes 15 events that
   may be mixed receipts and losses.  A null chunk describes no events,
   and is used to to round out the block to a 32 bit word boundary.

   The mapping from a sequence of lost and received packets into a
   sequence of chunks is not necessarily unique.  For example, the fol-
   lowing trace covers 45 packets, of which the 22nd and 24th have been
   lost and the others received:


1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1


   One way to encode this would be:


bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunk


   Another way to encode this would be:


run of 21 receipts
bit vector 0101 1111 1111 111
run of 9 receipts
null chunk


   The choice of encoding is left to the application.  As part of this
   freedom of choice, applications MAY terminate a series of run length
   and bit vector chunks with a bit vector chunk that runs beyond the
   sequence number space described by the report block.  For example, if
   the 44th packet in the same sequence were lost:


1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1


   This could be encoded as:



Friedman et al.                                                 [Page 6]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk


   In this example, the last five bits of the second bit vector describe
   a part of the sequence number space that extends beyond the last
   sequence number in the trace.  These bits have been set to zero.

   All bits in a bit vector chunk that describe a part of the sequence
   number space that extends beyond the last sequence number in the
   trace MUST be set to zero and MUST be ignored by the receiver.

   A null packet MUST appear at the end of a Loss RLE Block if the num-
   ber of run length plus bit vector chunks is odd.  The null chunk MUST
   NOT appear in any other context.

   Caution should be used in sending Loss RLE Blocks because, even with
   the compression provided by run-length encoding, they can easily con-
   sume bandwidth out of proportion with normal RTCP packets.  The block
   type includes a mechanism, called thinning, that allows an applica-
   tion to limit report sizes.

   A thinning value, T, selects a subset of packets within the sequence
   number space: those with sequence numbers that are multiples of 2^T.
   Packet reception and loss reports apply only to those packets.  T can
   vary between 0 and 15.  If T is zero then every packet in the
   sequence number space is reported upon.  If T is fifteen then one in
   every 32,768 packets is reported upon.

   Suppose that the trace just described begins at sequence number
   13,821.  The last sequence number in the trace is 13,865.  If the
   trace were to be thinned with a thinning value of T=2, then the fol-
   lowing sequence numbers would be reported upon: 13,824, 13,828,
   13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
   13,864.  The thinned trace would be as follows:


   1    1    1    1    1    0    1    1    1    1    0


   This could be encoded as follows:








Friedman et al.                                                 [Page 7]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


bit vector 1111 1011 1100 000
null chunk


   The last four bits in the bit vector, representing sequence numbers
   13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are
   thus set to zero and are ignored by the receiver.  With thinning, the
   loss of the 22nd packet goes unreported because its sequence number,
   13,842, is not a multiple of four.  Packet receipts for all sequence
   numbers that are not multiples of four also go unreported.  However,
   in this example thinning has permitted the Loss RLE Block to be
   shortened by one 32 bit word.

   Choice of the thinning value is left to the application.

   The Loss RLE Block has the following format:


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     BT=17     | rsvd. |   T   |         block length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          begin_seq            |             end_seq           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk 1              |             chunk 2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk n-1            |             chunk n           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


block type (BT): 8 bits
   A Loss RLE block is identified by the constant 17.

rsvd.: 4 bits
   This field is reserved for future definition.  In the absence of such
   definition, the bits in this field MUST be set to zero and receivers
   MUST ignore this field.

thinning (T): 4 bits
   The amount of thinning performed on the sequence number space.  Only
   those packets with sequence numbers 0 mod 2^T are reported on by this
   block.  A value of 0 indicates that there is no thinning, and all
   packets are reported on.  The maximum thinning is one packet in every



Friedman et al.                                                 [Page 8]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   32,768 (amounting to two packets within each 16-bit sequence space).

length: 16 bits
   Defined in Section 3.

begin_seq: 16 bits
   The first sequence number that this block reports on.

end_seq: 16 bits
   The last sequence number that this block reports on plus one.

chunk i: 16 bits
   There are three chunk types: run length, bit vector, and terminating
   null.  If the chunk is all zeroes then it is a terminating null
   chunk. Otherwise, the leftmost bit of the chunk determines its type:
   0 for run length and 1 for bit vector.


4.1.1 Run-Length Chunk


 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|        run length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


chunk type (C): 1 bit
   A zero identifies this as a runlength chunk.

run type (R): 1 bit
   Zero indicates a run of losses.  One indicates a run of received
   packets.

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.


4.1.2 Bit Vector Chunk







Friedman et al.                                                 [Page 9]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|        bit vector           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


chunk type (C): 1 bit
   A one identifies this as a bit vector chunk.

bit vector: 15 bits
   The vector is read from left to right, in order of increasing
   sequence number (with the appropriate allowance for wrap around).  A
   zero indicates a packet loss and a one indicates a received packet.


4.1.3 Terminating Null Chunk

   This chunk is all zeroes.


 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



4.2 Duplicate RLE Report Block

   This block type permits per-sequence-number reports on duplicates in
   a source's RTP packet stream.  Such information can be used for net-
   work diagnosis, and provide an alternative to packet losses as a
   basis for multicast tree topology inference.

   The Duplicate RLE Block format is identical to the Loss RLE Block
   format.  Only the interpretation is different, in that the informa-
   tion concerns packet duplicates rather than packet losses.  The trace
   to be encoded in this case also consists of zeros and ones, but a
   zero here indicates the presence of duplicate packets for a given
   sequence number, whereas a one indicates that no duplicates were
   received.

   The existence of a duplicate for a given sequence number is deter-
   mined over the entire reporting period.  For example, if packet num-
   ber 12,593 arrives, followed by other packets with other sequence
   numbers, the arrival later in the reporting period of another packet



Friedman et al.                                                [Page 10]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   numbered 12,593 counts as a duplicate for that sequence number.  The
   duplicate does not need to follow immediately upon the first packet
   of that number.  Care must be taken that a report does not cover a
   range of 65,534 or greater in the sequence number space.

   No distinction is made between the existance of a single duplicate
   packet and multiple duplicate packets for a given sequence number.
   Note also that since there is no duplicate for a lost packet, a loss
   is encoded as a one in a Duplicate RLE Block.

   The Duplicate RLE Block has the following format:


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    BT=33      | rsvd. |   T   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          begin_seq                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          end_seq                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk 1              |             chunk 2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk n-1            |             chunk n           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


block type (BT): 8 bits
   A Duplicate RLE block is identified by the constant 33.

rsvd.: 4 bits
   This field is reserved for future definition.  In the absence of such
   definition, the bits in this field MUST be set to zero and receivers
   MUST ignore this field.

thinning (T): 4 bits
   The amount of thinning performed on the sequence number space.

length: 16 bits
   Defined in Section 3.

begin_seq: 32 bits
   The first sequence number that this block reports on.



Friedman et al.                                                [Page 11]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


end_seq: 32 bits
   The last sequence number that this block reports on plus one.

chunk i: 16 bits
   There are three chunk types: run length, bit vector, and terminating
   null.  All zeroes indicates a terminating null.  Otherwise, the left-
   most bit of the chunk determines its type: 0 for run length and 1 for
   bit vector.  See the descriptions of these block types in the section
   on the Loss RLE Block, above, for details.


4.3 Timestamp Report Block

   This block type permits per-sequence-number reports on packet receipt
   timestamps for a given source's RTP packet stream.  Such information
   can be used for MINC inference of the topology of the multicast tree
   used to distribute the source's RTP packets, and of the delays along
   the links within that tree.  It can also be used to measure partial
   path characteristics and to model distributions for packet jitter.

   Timestamps consume more bits than loss or duplicate information, and
   do not lend themselves to run length encoding.  The use of thinning
   is encouraged to limit the size of Timestamp Report Blocks.

   The Timestamp Report Block has the following format:


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    BT=48      | rsvd. |   T   |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          begin_seq                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          end_seq                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP timestamp 1                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP timestamp 2                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP timestamp n                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Friedman et al.                                                [Page 12]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


block type (BT): 8 bits
   A Timestamp Report Block is identified by the constant 48.

rsvd.: 4 bits
   This field is reserved for future definition.  In the absence of such
   definition, the bits in this field MUST be set to zero and receivers
   MUST ignore this field.

thinning (T): 4 bits
   The amount of thinning performed on the sequence number space.

length: 16 bits
   Defined in Section 3.

begin_seq: 32 bits
   The first sequence number that this block reports on.

end_seq: 32 bits
   The last sequence number that this block reports on plus one.

RTP timestamp i: 32 bits
   The timestamp reflects the packet arrival time at the receiver.  It
   is preferable for the timestamp to be established at the link layer
   interface, or in any case as close as possible to the wire arrival
   time.  Units and format are the same as for the timestamp in RTP data
   packets.  As opposed to RTP data packet timestamps, in which nominal
   values may be used instead of system clock values in order to convey
   information useful for periodic playout, the receiver timestamps
   should reflect the actual time as closely as possible.  The initial
   value of the timestamp is random, and subsequent timestamps are off-
   set from this value.


4.4 Statistics Summary Report Block

   This block reports statistics beyond the information carried in the
   standard RTCP packet format, but not as fine grained as that carried
   in the report blocks previously described.  Information is recorded
   about lost packets, duplicate packets, jitter measurements, and TTL
   values (TTL values being taken from the TTL field of IPv4 packets, if
   the data packets are carried over IPv4).  Such information can be
   useful for network management.

   The packet contents are dependent upon a bit vector carried in the
   first part of the header.  Not all values need to be carried in each
   packet.  Header fields for values not carried are not included in the
   packet.




Friedman et al.                                                [Page 13]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   The Statistics Summary Report Block has the following format:


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     BT=1      |L|D|J|T|resvd. |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          begin_seq                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          end_seq                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        lost_packets                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        dup_packets                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         min_jitter                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         max_jitter                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         avg_jitter                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         dev_jitter                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   min_ttl     |   max_ttl     |   avg_ttl     |     dev_ttl   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


block type (BT): 8 bits
   A Statistics Summary block is identified by the constant 1.

content bits (L,D,J,T): 4 bits
   Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or
   (T)TL report.

resvd.: 4 bits
   This field is reserved for future definition.  In the absence of such
   definition, all bits in this field MUST be set to zero, and receivers
   MUST ignore this field.

length: 16 bits
   Defined in Section 3.

begin_seq: 32 bits
   The first sequence number that this block reports on.




Friedman et al.                                                [Page 14]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


end_seq: 32 bits
   The last sequence number that this block reports on plus one.

lost_packets: 32 bits
   Number of lost packets in the above sequence number interval.

dup_packets: 32 bits
   Number of duplicate packets in the above sequence number interval.

min_jitter: 32 bits
   The minimum relative transit time between two packets in the above
   sequence number interval.  All jitter values are measured as the dif-
   ference between a packet's RTP timestamp and the reporter's clock at
   the time of arrival, measured in the same units.

max_jitter: 32 bits
   The maximum relative transit time between two packets in the above
   sequence number interval.

avg_jitter: 32 bits
   The average relative transit time between each two packet series in
   the above sequence number interval.

dev_jitter: 32 bits
   The standard deviation of the relative transit time between each two
   packet series in the above sequence number interval.

min_ttl: 8 bits
   The minimum TTL value of data packets in sequence number range.

max_ttl: 8 bits
   The maximum TTL value of data packets in sequence number range.

avg_ttl: 8 bits
   The average TTL value of data packets in sequence number range.

dev_ttl: 8 bits
   The standard deviation of TTL values of data packets in sequence num-
   ber range.


4.5 Receiver Timestamp Report Block

   This block extends RTCP's timestamp reporting so that non-senders may
   also send timestamps.  It recapitulates the NTP timestamp fields from
   the RTCP Sender Report [7, Sec. 6.3.1].  A non-sender may estimate
   its RTT to other participants, as proposed in [9], by sending this
   report block and receiving DLRR report blocks (see next section) in



Friedman et al.                                                [Page 15]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   reply.


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     BT=2      |                 reserved                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              NTP timestamp, most significant word             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             NTP timestamp, least significant word             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


block type (BT): 8 bits
   A Receiver Timestamp block is identified by the constant 2.

reserved: 24 bits
   This field is reserved for future definition.  In the absence of such
   definition, the bits in this field MUST be set to zero, and receivers
   MUST ignore this field.

NTP timestamp: 64 bits
   Indicates the wallclock time when this block was sent so that it may
   be used in combination with timestamps returned in DLRR report blocks
   from other receivers to measure round-trip propagation to those
   receivers.  Receivers should expect that the measurement accuracy of
   the timestamp may be limited to far less than the resolution of the
   NTP timestamp. The measurement uncertainty of the timestamp is not
   indicated as it may not be known. A report block sender that can keep
   track of elapsed time but has no notion of wallclock time may use the
   elapsed time since joining the session instead. This is assumed to be
   less than 68 years, so the high bit will be zero.  It is permissible
   to use the sampling clock to estimate elapsed wallclock time. A
   report sender that has no notion of wallclock or elapsed time may set
   the NTP timestamp to zero.


4.6 DLRR Report Block

   This block extends RTCP's DLSR mechanism [7, Sec. 6.3.1] so that non-
   senders may also calculate round trip times, as proposed in [9]. It
   is termed DLRR for Delay since Last Receiver Report, and may be sent
   in response to a Receiver Timestamp report block (see previous sec-
   tion) from a receiver to allow that receiver to calculate its round
   trip time to the respondant.  The report consists of one or more 3
   word sub-blocks: one sub-block per receiver report.




Friedman et al.                                                [Page 16]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     BT=3      |   reserved    |             length            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                 SSRC_1 (SSRC of first receiver)               | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
|                         last RR (LRR)                         |   1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   delay since last RR (DLRR)                  |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                 SSRC_2 (SSRC of second receiver)              | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
:                               ...                             :   2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


block type (BT): 8 bits
   A DLRR block is identified by the constant 3.

reserved: 8 bits
   This field is reserved for future definition.  In the absence of such
   definition, all bits in this field MUST be set to zero, and receivers
   MUST ignore this field.

length: 16 bits
   Defined in Section 3.

last RR timestamp (LRR): 32 bits
   The middle 32 bits out of 64 in the NTP timestamp (as explained in
   the previous section) received as part of a Receiver Timestamp report
   block from participant SSRC_n. If no such block has been received,
   the field is set to zero.

delay since last RR (DLRR): 32 bits
   The delay, expressed in units of 1/65536 seconds, between receiving
   the last Receiver Timestamp report block from participant SSRC_n and
   sending this DLRR report block.  If no Receiver Timestamp report
   block has been received yet from SSRC_n, the DLRR field is set to
   zero (or the DLRR is omitted entirely). Let SSRC_r denote the
   receiver issuing this DLRR report block. Participant SSRC_n can com-
   pute the round-trip propagation delay to SSRC_r by recording the time
   A when this Receiver Timestamp report block is received.  It calcu-
   lates the total round-trip time A-LSR using the last SR timestamp
   (LSR) field, and then subtracting this field to leave the round-trip
   propagation delay as (A- LSR - DLSR). This is illustrated in [7, Fig.
   2].




Friedman et al.                                                [Page 17]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


4.7 VoIP Metrics Report Block

4.7.1 Summary

   The VoIP Metrics report block provides metrics for monitoring voice
   over IP (VoIP) calls.  These metrics include packet loss and discard
   metrics, delay metrics, analog metrics, and voice quality metrics.
   The block reports separately on packets lost on the IP channel, and
   those that have been received but then discarded by the receiving
   jitter buffer.  It also reports on the combined effect of losses and
   discards, as both have equal effect on call quality.

   In order to properly assess the quality of a Voice over IP call it is
   desirable to consider the degree of burstiness of packet loss [4].
   Following a Gilbert-Elliott model [5], an interval, bounded by lost
   and/or discarded packets, with a high rate of losses and/or discards
   is a "burst," and an interval between two bursts is a "gap."  Bursts
   correspond to intervals of time during which the packet loss rate is
   high enough to produce noticeable degradation in audio quality.  Gaps
   correspond to periods of time during which only isolated lost packets
   may occur, and in general these can  be masked by packet loss con-
   cealment.   Delay reports include the transit delay between RTCP end
   points and the VoIP end system processing delays, both of which con-
   tribute to the user perceived delay.  Additional metrics include sig-
   nal, echo, noise, and distortion levels.  Call quality metrics
   include R factors (E Model) [5] and MOS scores (Mean Opinion Scores).

   An implementation that sends these blocks SHOULD send at least one
   every ten seconds for the duration of a call, and SHOULD send one
   upon call termination.  An implementation MUST supply values for all
   fields defined here.

4.7.2 VoIP Metrics block structure

    The block is encoded as seven 32-bit words:
















Friedman et al.                                                [Page 18]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     BT=64     |   reserved    |          length=6             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   loss rate   | discard rate  |       burst duration          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst density |         gap duration          |  gap density  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     round trip delay          |       end system delay        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal power  | doubletalk    |  noise level  |       Gmin    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   R factor    | ext. R factor |    MOS-LQ     |    MOS-CQ     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   RX Config   | JB Nominal    |   JB Maximum  |  JB Abs Max   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


block type (BT): 8 bits
    A VoIP Metrics block is identified by the constant 64.

reserved: 8 bits
   This field is reserved for future definition.  In the absence of such
   definition, all bits in this field MUST be set to zero, and receivers
   MUST ignore this field.

length: 16 bits
   As defined in Section 3, this is the constant 6 for this block type.


4.7.3 Packet loss and discard metrics

   It is very useful to distinguish between packets lost by the network
   and those discarded due to jitter. Both have equal effect on the
   quality of the voice stream however having separate counts helps
   identify the source of quality degradation. These fields MUST be pop-
   ulated.

loss rate: 8 bits
   The fraction of RTP data packets from the source lost since the
   beginning of reception, expressed as a fixed point number with the
   binary point at the left edge of the field.  This value is calculated
   by dividing the total number of packets lost (after the effects of
   applying any error protection such as FEC) by the total number of
   packets expected, multiplying the result of the division by 256, and
   taking the integer part.  The numbers of duplicated packets and dis-
   carded packets do not enter into this calculation.  Since receivers



Friedman et al.                                                [Page 19]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   cannot be required to maintain unlimited buffers, a receiver MAY cat-
   egorize late-arriving packets as lost.  The degree of lateness that
   triggers a loss SHOULD be significantly greater than that which trig-
   gers a discard.

discard rate: 8 bits
   The fraction of RTP data packets from the source that have been dis
   carded since the beginning of reception, due to late or early
   arrival, under-run or overflow at the receiving jitter buffer.  This
   value is expressed as a fixed point number with the binary point at
   the left edge of the field.  It is calculated by dividing the total
   number of packets discarded (excluding duplicate packet discards) by
   the total number of packets expected, multiplying the result of the
   division by 256, and taking the integer part.

burst metrics:
   A burst is defined as a longest sequence of packets bounded by lost
   or discarded packets with the constraint that within a burst the num-
   ber of successive packets that were received, and not discarded due
   to delay variation, is less than some value Gmin.  A gap is defined
   as the interval between bursts, and has the property that any lost or
   discarded packets must be preceded and followed by at least Gmin
   packets that were received and not discarded. This gives a maximum
   loss/discard density within a gap of: 1 / (Gmin + 1).

burst duration: 16 bits
   The mean duration, expressed in milliseconds, of the burst intervals
   that have occurred since the beginning of reception.  The duration of
   each interval is calculated based upon the packets that mark the
   beginning and end of that interval.  It is equal to the timestamp of
   the end packet, plus the duration of the end packet, minus the times
   tamp of the beginning packet.  If the actual values are not avail
   able, estimated values MUST be used.  If there have been no burst
   intervals, the burst duration value MUST be zero.

burst density: 8 bits
   The fraction of RTP data packets within burst intervals since the
   beginning of reception that were either lost or discarded.  This
   value is expressed as a fixed point number with the binary point at
   the left edge of the field.  It is calculated by dividing the total
   number of packets lost or discarded (excluding duplicate packet dis-
   cards) within burst intervals by the total number of packets expected
   within the burst intervals, multiplying the result of the division by
   256, and taking the integer part.

gap duration: 16 bits
   The mean duration, expressed in milliseconds, of the gap intervals
   that have occurred since the beginning of reception.  The duration of



Friedman et al.                                                [Page 20]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   each interval is calculated based upon the packet that marks the end
   of the prior burst and the packet that marks the beginning of the
   subsequent burst. It is equal to the timestamp of the subsequent
   burst packet, minus the timestamp of the prior burst packet, plus the
   duration of the prior burst packet.  If the actual values are not
   available, estimated values MUST be used.  In the case of a gap that
   occurs at the beginning of reception, the sum of the timestamp of the
   prior burst packet and the duration of the prior burst packet are
   replaced by the reception start time.  In the case of a gap that
   occurs at the end of reception, the timestamp of the subsequent burst
   packet is replaced by the reception end time.  If there have been no
   gap intervals, the gap duration value MUST be zero.

gap density: 8 bits
   The fraction of RTP data packets within inter-burst gaps since the
   beginning of reception that were either lost or discarded.  The value
   is expressed as a fixed point number with the binary point at the
   left edge of the field.  It is calculated by dividing the total num-
   ber of packets lost or discarded (excluding duplicate packet dis
   cards) within gap intervals by the total number of packets expected
   within the gap intervals, multiplying the result of the division by
   256, and taking the integer part.

   For example, if the packet spacing is 10mS and a 1 denotes a received
   packet and 0, a lost, and X, a discarded, packet then the following
   pattern:


     11110111111111111111111X111X1011110111111111111111111X111111111
                            |--burst---|


   would have a burst duration of 120mS, a burst density of 0.33, a gap
   duration of 510mS and a gap density of 0.04, for a GMIN value of 4 or
   larger.

4.7.4 Delay metrics

   For the purpose of the following definitions,  the RTP interface is
   the interface between the RTP instance and the voice application
   (i.e.  FEC/de-interleaving/ de-multiplexing, jitter buffer). For
   example, the time delay due to RTP payload multiplexing would be con-
   sidered to be part of the voice application or end-system delay
   whereas delay due to multiplexing RTP frames within a UDP frame would
   be considered part of the RTP reported delay.  This distinction is
   consistent with the use of RTCP for delay measurements.

round trip delay: 16 bits



Friedman et al.                                                [Page 21]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   The most recently calculated round trip time between RTP interfaces,
   expressed in milliseconds. This value is the time of receipt of the
   most recent RTCP packet from source SSRC, minus the LSR (last SR)
   time reported in its SR (sender report), minus the DLSR (delay since
   last SR) reported in its SR.  A non-zero LSR value is REQUIRED in
   order to calculate round trip delay. A value of 0 is permissible dur-
   ing the first 2-3 RTCP exchanges as insufficient data may be avail-
   able to determine delay however MUST be populated as soon as a delay
   estimate is available.

end system delay: 16 bits
   The most recently estimated end system delay, expressed in millisec-
   onds.  End system delay is defined as the total encoding, decoding
   and jitter buffer delay determined at the reporting endpoint.  This
   is the time required for an RTP frame to be buffered, decoded, con-
   verted to analog form, looped back at the local analog interface,
   encoded, and made available for transmission as an RTP frame.  The
   manner in which this value is estimated is implementation dependent.
   This parameter MUST be provided in all VoIP metrics reports.

   Note that the one way symmetric VoIP segment delay may be calculated
   from the round trip and end system delays as follows.  If the round
   trip delay is denoted RTD and the end system delays associated with
   the two endpoints are ESD(A) and ESD(B) then:


   one way symmetric voice path delay  =  ( RTD + ESD(A) + ESD(B) ) / 2


4.7.5 Signal related metrics

   The following metrics are intended to provide real time information
   related to the non-packet elements of the voice over IP system to
   assist with the identification of problems affecting call quality.
   The values identified below must be determined for the received audio
   signal. The information required to populate these fields may not be
   available in all systems, although it is strongly recommended that
   this data SHOULD be provided to support problem diagnosis.

signal level: 8 bits
   The voice signal relative level is defined as the ratio of the signal
   level to overflow signal level, expressed in decibels as a signed
   integer in two's complement form.  This is measured only for packets
   containing speech energy.  The intent of this metric is not to pro-
   vide a precise measurement of the signal level but to provide a real
   time indication that the signal level may be excessively high or low.
   If the full range (overflow level) of the Vocoder's Digital to Analog
   conversion function is +/- L and the value of a decoded sample during



Friedman et al.                                                [Page 22]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   a talkspurt is V then the signal level is given by


         Signal level = 10 log10 ( mean( abs(V) / L ) )


   A value of 127 indicates that this parameter is unavailable.

doubletalk level: 8 bits
   The doubletalk level is defined as the proportion of voice frame
   intervals during which speech energy was present in both sending and
   receiving directions.  High levels of doubletalk can provide an indi-
   cation of delay or echo related problems. The value is expressed as a
   fixed point number with the binary point at the left edge of the
   field.  It is calculated by dividing the total number of voice frame
   intervals by the number of voice frame intervals during which energy
   was present in both sending and receiving directions,  multiplying
   the result of the division by 256, and taking the integer part.

   A value of 255 indicates that this value is unavailable

noise level: 8 bits
   The noise level is defined as the ratio of the silent period back
   ground noise level to overflow signal power, expressed in decibels as
   a signed integer in two's complement form.   If the full range (over-
   flow level) of the Vocoder's Digital to Analog conversion function is
   +/- L and the value of a decoded sample during a silence period is V
   then the noise level is given by


         Noise level = 10 log10 ( mean( abs(V) / L ) )


   A value of 127 indicates that this parameter is unavailable.

4.7.6 Call quality/ transmission quality metrics

   The following metrics are direct measures of the transmission quality
   or call quality, and incorporate the effects of CODEC type, packet
   loss, discard, burstiness, delay etc.  These metrics may not be
   available in all systems however SHOULD be provided in order to sup-
   port problem diagnosis.

R factor: 8 bits
   The R factor is a voice quality metric describing the segment of the
   call that is carried over this RTP session.  It is expressed as an
   integer in the range 0 to 100, with a value of 94 corresponding to
   "toll quality" and values of 50 or less regarded as unusable.  This



Friedman et al.                                                [Page 23]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   metric is defined as including the effects of delay, consistent with
   ITU-T G.107 [6] and ETSI TS 101 329-5 [5].

   A value of 127 indicates that this parameter is unavailable.

ext. R factor: 8 bits
   The external R factor is a voice quality metric describing the seg
   ment of the call that is carried over a network segment external to
   the RTP segment, for example a cellular network. Its values are
   interpreted in the same manner as for the RTP R factor.  This metric
   is defined as including the effects of delay, consistent with ITU-T
   G.107 [6] and ETSI TS 101 329-5 [5], and relates to the outward voice
   path from the Voice over IP termination for which this metrics block
   applies.

   Note that an overall R factor may be estimated from the RTP segment R
   factor and the external R factor, as follows:


        R total = RTP R factor + ext. R factor - 94


   A value of 127 indicates that this parameter is unavailable.

MOS-LQ: 8 bits
   The estimated mean opinion score for listening quality (MOS-LQ) is a
   voice quality metric on a scale from 1 to 5, in which 5 represents
   excellent and 1 represents unacceptable.  This metric is defined as
   not including the effects of delay and can be compared to MOS scores
   obtained from listening quality (ACR) tests. It is expressed as an
   integer in the range 10 to 50, corresponding to MOS x 10.  For exam-
   ple, a value of 35 would correspond to an estimated MOS score of 3.5.

   A value of 127 indicates that this parameter is unavailable.

MOS-CQ: 8 bits
   The estimated mean opinion score for conversational quality (MOS-CQ)
   is defined as including the effects of delay and other effects that
   would affect conversational quality.  The metric may be calculated by
   converting an R factor determined according to ITU-T G.107 [6] or
   ETSI TS 101 329-5 [5] into an estimated MOS using the equation speci-
   fied in G.107

   A value of 127 indicates that this parameter is unavailable.

4.7.7 Configuration parameters:

Gmin: 8 bits



Friedman et al.                                                [Page 24]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   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.

   Receiver Configuration byte:


    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |PLC|JBA|JB rate|
   +-+-+-+-+-+-+-+-+


PLC - packet loss concealment
   Standard (11) / enhanced (10) / disabled (01) / unspecified (00).
   When PLC=11 then a simple replay or interpolation algorithm is being
   used to fill-in the missing packet - this is typically able to con-
   ceal isolated lost packets with loss rates under 3%.  When PLC=10
   then an enhanced interpolation algorithm is being used - this would
   typically be able to conceal lost packets for loss rates of 10% or
   more.  When PLC=01 then silence is inserted in place of lost packets.
   When PLC = 00 then no information is available concerning the use of
   PLC however for some CODECs this may be inferred.

JBA - Jitter Buffer Adaptive
   Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When
   Jitter Buffer is adaptive then its size is being dynamically adjusted
   to deal with varying levels of jitter.  When non-adaptive then the
   Jitter Buffer size is maintained at a fixed level.  When either adap-
   tive or non-adaptive modes are specified then the Jitter Buffer Size
   parameters below MUST be specified.

JB Rate - Jitter Buffer Rate
   J = adjustment rate (0-15). This represents the implementation spe-
   cific adjustment rate of a Jitter Buffer in adaptive mode. This
   parameter is defined in terms of the approximate time taken to fully
   adjust to a step change in peak to peak jitter from 30mS to 100mS
   such that:



Friedman et al.                                                [Page 25]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


     adjustment time = 2* J * frame size (mS)


   This parameter is intended only to provide a guide to the degree of
   "aggressiveness" of a an adaptive jitter buffer and may be estimated.
   A value of 0 indicates that the adjustment time is unknown for this
   implementation.

4.7.7 Jitter Buffer Parameters

Jitter Buffer - nominal size in frames (8 bit)
   This is the current nominal fill point within the jitter buffer,
   which corresponds to the nominal jitter buffer delay for packets that
   arrive exactly on time.  This parameter MUST be provided for both
   fixed and adaptive jitter buffer implementations.

Jitter Buffer Maximum - size in frames (8 bit)
   This is the current maximum jitter buffer level corresponding to the
   earliest arriving packet that would not be discarded.  In simple
   queue implementations this may correspond to the nominal size. In
   adaptive jitter buffer implementations this value may dynamically
   vary up to Jitter Buffer Absolute Maximum.  This parameter MUST be
   provided for both fixed and adaptive jitter buffer implementations.

Jitter Buffer Absolute Maximum - size in frames (8 bit)
   This is the absolute maximum size that the adaptive jitter buffer can
   reach under worst case jitter conditions.  This parameter MUST be
   provided for adaptive jitter buffer implementations and its value
   MUST be set to JB Maximum for fixed jitter buffer implementations.

   Example of burst packet loss calculation.

   This is an event driven algorithm for measuring burst characteristics
   and is hence extremely computationally efficient.

   Given the following definition of states:


     State 1 = received a packet during a gap
     State 2 = received a packet during a burst
     State 3 = lost a packet during a burst
     State 4 = lost an isolated packet during a gap


   The "c" variables below correspond to state transition counts, i.e.
   c14 is the transition from state 1 to state 4. It is possible to
   infer one of a pair of state transition counts to an accuracy of 1
   which is generally sufficient for this application.  "pkt" is the



Friedman et al.                                                [Page 26]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   count of packets received since the last packet was declared lost or
   discarded and "lost" is the number of packets lost within the current
   burst.


    if ( packet_lost ) loss_count++;
    if ( packet_discarded ) discard_count++;
    if (pkt >= gmin)
    {
        if (lost == 1)
           c14++;
        else
            c13++;
        lost = 1;
        c11 += pkt;
    }
    else
    {
        lost++;
        if (pkt == 0)
            c33++;
        else
        {
            c23++;
            c22 += (pkt - 1);
        }
    }


   At each reporting interval the burst and gap metrics can be calcu-
   lated as follows.




















Friedman et al.                                                [Page 27]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


    /* calculate additional transition counts */
    c31 = c13;
    c32 = c23;
    ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;

    /* calculate burst and densities */
    p32 = c32 / (c31 + c32 + c33);
    if ((c22 + c23) < 1)
        p23 = 1;
    else
        p23 = 1 - c22/(c22 + c23);
    burst_density = 256 * p23 / (p23 + p32);
    gap_density = 256 * c14 / (c11 + c14);

    /* calculate burst and gap durations in mS */
    m = frameDuration_in_mS * framesPerRTPPkt;
    gap_length = (c11 + c14 + c13) * m / c13;
    burst_length = ctotal * m / c13 - lgap;

    /* calculate loss and discard densities */
    loss_density = 256 * loss_count / ctotal;
    discard_density = 256 * discard_count / ctotal;


5. IANA Considerations

   The extended report block type (BT) field defined by this document is
   a name space to be managed by the Internet Assigned Numbers Authority
   (IANA).  The field contains eight bits, allowing 256 values, of which
   seven are defined here:


 1 (Statistics Summary Block, see Section 4.4)
 2 (Receiver Timestamp Report Block, see Section 4.5)
 3 (DLRR Report Block, see Section 4.6)
17 (Loss RLE Block, see Section 4.1)
33 (Duplicate RLE Block, see Section 4.2)
48 (Timestamp Report Block, see Section 4.3)
64 (VoIP Metrics Report Block, see Section 4.7)


   In addition, the value 0 is reserved for experimental use.

   No review is necessary by the IANA in order for it to record the
   assignment of additional numbers from this name space.  Such numbers
   are to be assigned as part of the IETF standards process.





Friedman et al.                                                [Page 28]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


6. Security Considerations

   This document extends the RTCP reporting mechanism, so all security
   considerations for RTCP reports also apply to the XR packets
   described here.  This section details the additional security consid-
   erations that apply to the extensions.

   The extensions introduce heightened confidentiality concerns.  Stan-
   dard RTCP reports contain a limited number of summary statistics.
   The information contained in XR reports is both more detailed and
   more extensive (covering a larger number of parameters).  The per
   packet information contained in Loss RLE, Duplicate RLE, and Times-
   tamp Report Blocks facilitates MINC inference of multicast distribu-
   tion trees for RTP data packets, and inference of link characteris-
   tics such as loss and delay.  This inference reveals information that
   might otherwise be considered confidential to autonomous system
   administrators.  The VoIP Metrics Report Block provides information
   on the quality of ongoing voice calls.  Though such information might
   be carried in application specific format in standard RTP sessions,
   making it available in a standard format here makes it more available
   to potential eavesdroppers.

   No new mechanisms are introduced in this document to ensure confiden-
   tiality.  Already available authentification and encryption proce-
   dures should be used when confidentiality is a concern to end hosts.
   Autonomous system administrators concerned about the loss of confi-
   dentiality regarding their networks can filter traffic to exclude
   RTCP packets containing the XR report blocks concerned.

   The extensions also make certain denial of service attacks easier.
   This is because of the potential to create RTCP packets much larger
   than average with the per packet reporting capabilities of the Loss
   RLE, Duplicate RLE, and Timestamp Report Blocks.  Because of the
   automatic bandwidth adjustment mechanisms in RTCP, if some session
   participants are sending large RTCP packets, all participants will
   see their RTCP reporting intervals lengthened, meaning they will be
   able to report less frequently.

   No new mechanisms are introduced in this document to prevent such
   denial of service attacks.


7. Acknowledgements

   We thank the following people: Colin Perkins, Steve Casner, and Hen-
   ning Schulzrinne for their considered guidance; Nick Duffield for
   extensive ongoing contributions; Sue Moon for helping foster collabo-
   ration between the authors of this document; and Mounir Benzaid for



Friedman et al.                                                [Page 29]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   drawing our attention to the reporting needs of MLDA.


8. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to per-
   tain to the implementation or use of the technology described in this
   document or the extent to which any license under such rights might
   or might not be available; neither does it represent that it has made
   any effort to identify any such rights.  Information on the IETF's
   procedures with respect to rights in standards-track and standards-
   related documentation can be found in BCP 11 [7].  Copies of claims
   of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such propri-
   etary rights by implementors or users of this specification can be
   obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


9. References

   [1] A. Adams, T. Bu, R. Caceres, N.G. Duffield, T. Friedman, J.
   Horowitz, F. Lo Presti, S.B. Moon, V. Paxson, and D. Towsley, "The
   Use of End-to-End Multicast Measurements for Characterizing Internal
   Network Behavior,"  IEEE Communications Magazine, May 2000.

   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," BCP 14, RFC 2119, IETF, March 1997.

   [3] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measure-
   ment infrastructures using RTP," Proc. IEEE Infocom 2002.

   [4] A. D. Clark, "Modeling the Effects of Burst Packet Loss and
   Recency on Subjective Voice Quality," Proc. IP Telephony Workshop
   2001.

   [5] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI
   TS 101 329-5 V1.1.1 (2000-11), November 2000.

   [6] ITU-T, "The E-Model, a computational model for use in transmis-
   sion planning," Recommendation G.107 (05/00), May 2000.



Friedman et al.                                                [Page 30]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


   [7] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700,
   IETF, October 1994.

   [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
   transport protocol for real-time applications," RFC 1889, IETF,
   February 1996.

   [9] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Con-
   trol Framework for Heterogeneous Multicast Environments", Proc. IWQoS
   2000.


10. Full Copyright Statement

   Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this doc-
   ument itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


9. Authors' Addresses

    Timur Friedman <timur.friedman@lip6.fr>
    University of Paris 6
    Laboratoire LiP6-CNRS
    8, rue du Capitaine Scott
    75015 PARIS, FRANCE




Friedman et al.                                                [Page 31]


draft-ietf-avt-rtcp-report-extns-01.txt                  3 November 2002


    Ramon Caceres <ramon@shieldip.com>
    ShieldIP, Inc.
    11 West 42nd Street, 31st Floor
    New York, NY 10036, USA

    Kevin Almeroth <almeroth@cs.ucsb.edu>
    Department of Computer Science
    University of California
    Santa Barbara, CA 93106, USA

    Kamil Sarac <ksarac@cs.uscb.edu>
    Department of Computer Science
    University of California
    Santa Barbara, CA 93106, USA

    Alan Clark <alan@telchemy.com>
    Telchemy Incorporated
    3360 Martins Farm Road, Suite 200
    Suwanee, GA 30024
    Tel: +1 770 614-6944
    Fax: +1 770 614-3951

    Robert Cole <rgcole@att.com>
    AT&T Labs
    330 Saint Johns Street,
    2nd Floor
    Havre de Grace, MD, USA 21078
    Tel: +1 410 939-8732
    Fax: +1 410 939-8732

    Kaynam Hedayat <khedayat@brixnet.com>
    Brix Networks
    285 Mill Road
    Chelmsford, MA 01824
    Tel: +1 978 367-5600
    Fax: +1 978 367-5700















Friedman et al.                                                [Page 32]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/