draft-ietf-avt-rtcp-report-extns-02.txt   draft-ietf-avt-rtcp-report-extns-03.txt 
Internet Engineering Task Force Expires: 24 July 2003 Internet Engineering Task Force Expires: 2 September 2003
Audio/Video Transport Working Group Audio/Video Transport Working Group
Timur Friedman, Paris 6 Timur Friedman, Paris 6
Ramon Caceres, ShieldIP Ramon Caceres, ShieldIP
Alan Clark, Telchemy Alan Clark, Telchemy
Editors Editors
RTP Extended Reports (RTP XR) RTP Extended Reports (RTP XR)
draft-ietf-avt-rtcp-report-extns-02.txt draft-ietf-avt-rtcp-report-extns-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
This document defines the extended report (XR) packet type for the This document defines the extended report (XR) packet type for the
RTP control protocol (RTCP). XR packets are composed of report RTP control protocol (RTCP). XR packets are composed of report
blocks, and seven block types are defined here. The purpose of the blocks, and seven block types are defined here. The purpose of the
extended reporting format is to convey information that supplements extended reporting format is to convey information that supplements
the six statistics that are contained in the report blocks used by the six statistics that are contained in the report blocks used by
RTCP's sender report (SR) and receiver report (RR) packets. Some RTCP's sender report (SR) and receiver report (RR) packets. Some
applications, such as multicast inference of network characteristics applications, such as multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring, require other and more (MINC) or voice over IP (VoIP) monitoring, require other and more
detailed statistics. In addition to the block types defined here, detailed statistics. In addition to the block types defined here,
additional block types may be defined in the future by adhereing to additional block types may be defined in the future by adhering to
the framework that this document provides. the framework that this document provides.
Table of Contents Table of Contents
1. Introduction .............................................. 2 1. Introduction .............................................. 2
1.1 Terminology ............................................... 3 1.1 Terminology ............................................... 3
2. XR Packet Format .......................................... 4 2. XR Packet Format .......................................... 4
3. Extended Report Block Framework ........................... 5 3. Extended Report Block Framework ........................... 5
4. Extended Report Blocks .................................... 6 4. Extended Report Blocks .................................... 6
4.1 Loss RLE Report Block ..................................... 6 4.1 Loss RLE Report Block ..................................... 6
4.1.1 Run Length Chunk .......................................... 12 4.1.1 Run Length Chunk .......................................... 12
4.1.2 Bit Vector Chunk .......................................... 12 4.1.2 Bit Vector Chunk .......................................... 12
4.1.3 Terminating Null Chunk .................................... 12 4.1.3 Terminating Null Chunk .................................... 12
4.2 Duplicate RLE Report Block ................................ 13 4.2 Duplicate RLE Report Block ................................ 13
4.3 Timestamp Report Block .................................... 13 4.3 Timestamp Report Block .................................... 14
4.4 Statistics Summary Report Block ........................... 16 4.4 Statistics Summary Report Block ........................... 16
4.5 Receiver Timestamp Report Block ........................... 19 4.5 Receiver Timestamp Report Block ........................... 19
4.6 DLRR Report Block ......................................... 20 4.6 DLRR Report Block ......................................... 20
4.7 VoIP Metrics Report Block ................................. 21 4.7 VoIP Metrics Report Block ................................. 21
4.7.1 Packet Loss and Discard Metrics ........................... 23 4.7.1 Packet Loss and Discard Metrics ........................... 22
4.7.2 Burst Metrics ............................................. 23 4.7.2 Burst Metrics ............................................. 23
4.7.3 Delay Metrics ............................................. 26 4.7.3 Delay Metrics ............................................. 25
4.7.4 Signal Related Metrics .................................... 26 4.7.4 Signal Related Metrics .................................... 26
4.7.5 Call Quality or Transmission Quality Metrics .............. 29 4.7.5 Call Quality or Transmission Quality Metrics .............. 29
4.7.6 Configuration Parameters .................................. 30 4.7.6 Configuration Parameters .................................. 30
4.7.7 Jitter Buffer Parameters .................................. 31 4.7.7 Jitter Buffer Parameters .................................. 31
5. IANA Considerations ....................................... 32 5. IANA Considerations ....................................... 32
5.1 XR Packet Type ............................................ 32 5.1 XR Packet Type ............................................ 32
5.2 RTP XR Block Type Registry ................................ 32 5.2 RTP XR Block Type Registry ................................ 32
6. Security Considerations ................................... 33 6. Security Considerations ................................... 33
A. Algorithms ................................................ 34 A. Algorithms ................................................ 34
A.1 Sequence Number Interpretation ............................ 34 A.1 Sequence Number Interpretation ............................ 34
A.2 Example Burst Packet Loss Calculation ..................... 35 A.2 Example Burst Packet Loss Calculation ..................... 35
Intellectual Property ..................................... 37 Intellectual Property ..................................... 37
Full Copyright Statement .................................. 38 Full Copyright Statement .................................. 37
Acknowledegments .......................................... 38 Acknowledgments ........................................... 38
Contributors .............................................. 39 Contributors .............................................. 38
Authors' Addresses ........................................ 39 Authors' Addresses ........................................ 39
References ................................................ 40 References ................................................ 40
Normative References ...................................... 40 Normative References ...................................... 40
Non-Normative References .................................. 41 Non-Normative References .................................. 41
1. Introduction 1. Introduction
This document defines the extended report (XR) packet type for the This document defines the extended report (XR) packet type for the
RTP control protocol (RTCP) [7]. XR packets convey information RTP control protocol (RTCP) [7]. XR packets convey information
beyond that already contained in the reception report blocks of beyond that already contained in the reception report blocks of
skipping to change at page 3, line 46 skipping to change at page 3, line 46
- DLRR Report Block (Section 4.6): The delay since the last Receiver - DLRR Report Block (Section 4.6): The delay since the last Receiver
Timestamp Report Block was received, allowing non-senders to Timestamp Report Block was received, allowing non-senders to
calculate round-trip times. calculate round-trip times.
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring
Voice over IP (VoIP) calls. Voice over IP (VoIP) calls.
These blocks are defined within a minimal framework: a type field and 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 a length field are common to all XR blocks. The purpose is to
maintain flexibility and to keep overhead low. 0ther block formats, maintain flexibility and to keep overhead low. Other block formats,
beyond the seven defined here, may be defined within this framework beyond the seven defined here, may be defined within this framework
as the need arises. as the need arises.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1] and document are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliance with this specification. indicate requirement levels for compliance with this specification.
2. XR Packet Format 2. XR Packet Format
skipping to change at page 4, line 32 skipping to change at page 4, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits version (V): 2 bits
Identifies the version of RTP. This specification applies to Identifies the version of RTP. This specification applies to
RTP version two. RTP version two.
padding (P): 1 bit padding (P): 1 bit
If the padding bit is set, this XR packet contains some If the padding bit is set, this XR packet contains some
additional padding octets at the end. The semantics of this additional padding octets at the end. The semantics of this
field are identical to the semantics of the padding field in the field are identical to the semantics of the padding field in the
the SR packet, as defined by the RTP specification. SR packet, as defined by the RTP specification.
reserved: 5 bits reserved: 5 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
the receiver MUST ignore any XR packet with a non-zero value in MUST be ignored by the receiver.
this field.
packet type (PT): 8 bits packet type (PT): 8 bits
Contains the constant 207 to identify this as an RTCP XR packet. Contains the constant 207 to identify this as an RTCP XR packet.
This value is registered with the Internet Assigned Numbers This value is registered with the Internet Assigned Numbers
Authority (IANA), as described in Section 5.1. Authority (IANA), as described in Section 5.1.
length: 16 bits length: 16 bits
As described for the RTP sender report (SR) packet (see Section As described for the RTP sender report (SR) packet (see Section
6.3.1 of the RTP specification [7]). Briefly, the length of 6.3.1 of the RTP specification [7]). Briefly, the length of
this XR packet in 32-bit words minus one, including the header this XR packet in 32-bit words minus one, including the header
skipping to change at page 6, line 18 skipping to change at page 6, line 18
The use of this field is defined by the particular block type, The use of this field is defined by the particular block type,
subject to the constraint that it MUST be a multiple of 32 bits subject to the constraint that it MUST be a multiple of 32 bits
long. If the block type definition permits, It MAY be zero bits long. If the block type definition permits, It MAY be zero bits
long. long.
4. Extended Report Blocks 4. Extended Report Blocks
This section defines seven extended report blocks: block types for This section defines seven extended report blocks: block types for
losses, duplicates, packet reception timestamps, detailed reception losses, duplicates, packet reception timestamps, detailed reception
statistics, receiver timestamps, receiver inter-report delays, and statistics, receiver timestamps, receiver inter-report delays, and
voice over IP (VoIP) metrics. An implementation MAY ignore incoming voice over IP (VoIP) metrics. An implementation SHOULD ignore
blocks with types either not relevant or unknown to it. Additional incoming blocks with types either not relevant or unknown to it.
block types MUST be registered with the Internet Assigned Numbers Additional block types MUST be registered with the Internet Assigned
Authority (IANA) [5], as described in Section 5.2. Numbers Authority (IANA) [5], as described in Section 5.2.
4.1 Loss RLE Report Block 4.1 Loss RLE Report Block
This block type permits detailed reporting upon individual packet This block type permits detailed reporting upon individual packet
receipt and loss events. Such reports can be used, for example, for receipt and loss events. Such reports can be used, for example, for
multicast inference of network characteristics (MINC) [8]. With multicast inference of network characteristics (MINC) [8]. With
MINC, one can discover the topology of the multicast tree used for MINC, one can discover the topology of the multicast tree used for
distributing a source's RTP packets, and of the loss rates along distributing a source's RTP packets, and of the loss rates along
links within that tree. Or they could be used to provide raw data to links within that tree. Or they could be used to provide raw data to
a network management application. a network management application.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
and per-packet accounting. and per-packet accounting.
In its per-sender accounting, an RTP session participant SHOULD NOT In its per-sender accounting, an RTP session participant SHOULD NOT
make the receipt of a threshold minimum number of RTP packets a make the receipt of a threshold minimum number of RTP packets a
condition for reporting upon the sender of those packets. This condition for reporting upon the sender of those packets. This
accounting technique differs from the technique described in Section accounting technique differs from the technique described in Section
6.2.1 and Appendix A.1 of the RTP specification that allows a 6.2.1 and Appendix A.1 of the RTP specification that allows a
threshold to determine whether a sender is considered valid. threshold to determine whether a sender is considered valid.
In its per-packet accounting, an RTP session participant SHOULD treat In its per-packet accounting, an RTP session participant SHOULD treat
all sequence numbers as valid. This accouting technique differs from all sequence numbers as valid. This accounting technique differs
the technique described in Appendix A.1 of the RTP specification that from the technique described in Appendix A.1 of the RTP specification
suggests ruling a sequence number valid or invalid on the basis of that suggests ruling a sequence number valid or invalid on the basis
its contiguity with the sequence numbers of previously received of its contiguity with the sequence numbers of previously received
packets. packets.
Sender validity and sequence number validity are interpretations of Sender validity and sequence number validity are interpretations of
the raw data. Such interpretations are justified in the interest, the raw data. Such interpretations are justified in the interest,
for example, of excluding the stray old packet from an unrelated for example, of excluding the stray old packet from an unrelated
session from having an effect upon the calculation of the RTCP session from having an effect upon the calculation of the RTCP
transmission interval. The presence of stray packets might, on the transmission interval. The presence of stray packets might, on the
other hand, be of interest to a network monitoring application. other hand, be of interest to a network monitoring application.
One accounting interpretation that is still necessary is for a One accounting interpretation that is still necessary is for a
skipping to change at page 8, line 29 skipping to change at page 8, line 29
If a packet with a given sequence number is received after a report If a packet with a given sequence number is received after a report
of a loss for that sequence number, a later Loss RLE report MAY of a loss for that sequence number, a later Loss RLE report MAY
report a packet receipt for that sequence number. report a packet receipt for that sequence number.
The encoding itself consists of a series of 16 bit units called The encoding itself consists of a series of 16 bit units called
chunks that describe sequences of packet receipts or losses in the chunks that describe sequences of packet receipts or losses in the
trace. Each chunk either specifies a run length or a bit vector, or trace. 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 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 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 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 null chunk describes no events, and is used to round out the block to
to a 32 bit word boundary. a 32 bit word boundary.
The mapping from a sequence of lost and received packets into a The mapping from a sequence of lost and received packets into a
sequence of chunks is not necessarily unique. For example, the sequence of chunks is not necessarily unique. For example, the
following trace covers 45 packets, of which the 22nd and 24th have following trace covers 45 packets, of which the 22nd and 24th have
been lost and the others received: been lost and the others received:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
One way to encode this would be: One way to encode this would be:
skipping to change at page 11, line 27 skipping to change at page 11, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Loss RLE Report Block is identified by the constant 1. A Loss RLE Report Block is identified by the constant 1.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
the receiver MUST ignore any Loss RLE Report Block with a non- MUST be ignored by the receiver.
zero value in this field.
thinning (T): 4 bits thinning (T): 4 bits
The amount of thinning performed on the sequence number space. The amount of thinning performed on the sequence number space.
Only those packets with sequence numbers 0 mod 2^T are reported 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 on by this block. A value of 0 indicates that there is no
thinning, and all packets are reported on. The maximum thinning thinning, and all packets are reported on. The maximum thinning
is one packet in every 32,768 (amounting to two packets within is one packet in every 32,768 (amounting to two packets within
each 16-bit sequence space). each 16-bit sequence space).
block length: 16 bits block length: 16 bits
skipping to change at page 12, line 41 skipping to change at page 12, line 40
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector | |C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit chunk type (C): 1 bit
A one identifies this as a bit vector chunk. A one identifies this as a bit vector chunk.
bit vector: 15 bits bit vector: 15 bits
The vector is read from left to right, in order of increasing The vector is read from left to right, in order of increasing
sequence number (with the appropriate allowance for wrap sequence number (with the appropriate allowance for wraparound).
around).
4.1.3 Terminating Null Chunk 4.1.3 Terminating Null Chunk
This chunk is all zeroes. This chunk is all zeroes.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 35 skipping to change at page 13, line 35
The existence of a duplicate for a given sequence number is The existence of a duplicate for a given sequence number is
determined over the entire reporting period. For example, if packet determined over the entire reporting period. For example, if packet
number 12,593 arrives, followed by other packets with other sequence number 12,593 arrives, followed by other packets with other sequence
numbers, the arrival later in the reporting period of another packet numbers, the arrival later in the reporting period of another packet
numbered 12,593 counts as a duplicate for that sequence number. The numbered 12,593 counts as a duplicate for that sequence number. The
duplicate does not need to follow immediately upon the first packet 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 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. range of 65,534 or greater in the sequence number space.
No distinction is made between the existance of a single duplicate No distinction is made between the existence of a single duplicate
packet and multiple duplicate packets for a given sequence number. packet and multiple duplicate packets for a given sequence number.
Note also that since there is no duplicate for a lost packet, a loss Note also that since there is no duplicate for a lost packet, a loss
is encoded as a one in a Duplicate RLE Report Block. is encoded as a one in a Duplicate RLE Report Block.
The Duplicate RLE Report Block has the following format: The Duplicate RLE Report Block has the following format:
0 1 2 3 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 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 | rsvd. | T | block length | | BT=2 | rsvd. | T | block length |
skipping to change at page 14, line 27 skipping to change at page 14, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Duplicate RLE Report Block is identified by the constant 2. A Duplicate RLE Report Block is identified by the constant 2.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
the receiver MUST ignore any Duplicate RLE Report Block with a MUST be ignored by the receiver.
non-zero value in this field.
thinning (T): 4 bits thinning (T): 4 bits
As defined in Section 4.1. As defined in Section 4.1.
block length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
begin_seq: 16 bits begin_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
skipping to change at page 15, line 44 skipping to change at page 15, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp n | | RTP timestamp n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Timestamp Report Block is identified by the constant 3. A Timestamp Report Block is identified by the constant 3.
rsvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
the receiver MUST ignore any Timestamp Report Block with a non- MUST be ignored by the receiver.
zero value in this field.
thinning (T): 4 bits thinning (T): 4 bits
As defined in Section 4.1. As defined in Section 4.1.
block length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
begin_seq: 16 bits begin_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
skipping to change at page 17, line 8 skipping to change at page 17, line 8
in each block. Flags indicate which are and which are not reported. in each block. Flags indicate which are and which are not reported.
The fields corresponding to unreported parameters MUST be set to The fields corresponding to unreported parameters MUST be set to
zero. The receiver MUST ignore any Statistics Summary Report Block zero. The receiver MUST ignore any Statistics Summary Report Block
with a non-zero value in any field flagged as unreported. with a non-zero value in any field flagged as unreported.
The Statistics Summary Report Block has the following format: The Statistics Summary Report Block has the following format:
0 1 2 3 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 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=4 |L|D|J|T|resvd. | block length = 9 | | BT=4 |L|D|J|T| rsvd. | block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets | | lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets | | dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter | | min_jitter |
skipping to change at page 17, line 49 skipping to change at page 17, line 49
otherwise. otherwise.
jitter flag (J): 1 bit jitter flag (J): 1 bit
Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and
dev_jitter fields all contain reports, 0 if none of them do. dev_jitter fields all contain reports, 0 if none of them do.
TTL flag (T): 1 bit TTL flag (T): 1 bit
Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl
fields all contain reports, 0 if none of them do. fields all contain reports, 0 if none of them do.
resvd.: 4 bits rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, all bits in this field MUST be set to zero, and such definition, the bits in this field MUST be set to zero and
the receiver MUST ignore any Statistics Summary Report Block MUST be ignored by the receiver.
with a non-zero value in this field.
block length: 16 bits block length: 16 bits
The constant 9, in accordance with the definition of this field The constant 9, in accordance with the definition of this field
in Section 3. in Section 3.
begin_seq: 16 bits begin_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
end_seq: 16 bits end_seq: 16 bits
As defined in Section 4.1. As defined in Section 4.1.
skipping to change at page 19, line 35 skipping to change at page 19, line 33
| NTP timestamp, least significant word | | NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A Receiver Timestamp Report Block is identified by the constant A Receiver Timestamp Report Block is identified by the constant
5. 5.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
the receiver MUST ignore any Receiver Timestamp Report Block MUST be ignored by the receiver.
with a non-zero value in this field.
block length: 16 bits block length: 16 bits
The constant 2, in accordance with the definition of this field The constant 2, in accordance with the definition of this field
in Section 3. in Section 3.
NTP timestamp: 64 bits NTP timestamp: 64 bits
Indicates the wallclock time when this block was sent so that it Indicates the wallclock time when this block was sent so that it
may be used in combination with timestamps returned in DLRR may be used in combination with timestamps returned in DLRR
Report Blocks (see next section) from other receivers to measure Report Blocks (see next section) from other receivers to measure
round-trip propagation to those receivers. Receivers should round-trip propagation to those receivers. Receivers should
skipping to change at page 20, line 19 skipping to change at page 20, line 17
or elapsed time may set the NTP timestamp to zero. or elapsed time may set the NTP timestamp to zero.
4.6 DLRR Report Block 4.6 DLRR Report Block
This block extends RTCP's delay since last sender report (DLSR) This block extends RTCP's delay since last sender report (DLSR)
mechanism [7, Sec. 6.3.1] so that non-senders may also calculate mechanism [7, Sec. 6.3.1] so that non-senders may also calculate
round trip times, as proposed in [11]. It is termed DLRR for delay round trip times, as proposed in [11]. It is termed DLRR for delay
since last receiver report, and may be sent in response to a Receiver since last receiver report, and may be sent in response to a Receiver
Timestamp Report Block (see previous section) from a receiver to Timestamp Report Block (see previous section) from a receiver to
allow that receiver to calculate its round trip time to the allow that receiver to calculate its round trip time to the
respondant. The report consists of one or more 3 word sub-blocks: respondent. The report consists of one or more 3 word sub-blocks:
one sub-block per receiver report. one sub-block per receiver report.
0 1 2 3 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 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=6 | reserved | block length | | BT=6 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub- | SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1 | last RR (LRR) | 1
skipping to change at page 20, line 43 skipping to change at page 20, line 41
| SSRC_2 (SSRC of second receiver) | sub- | SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2 : ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits block type (BT): 8 bits
A DLRR Report Block is identified by the constant 6. A DLRR Report Block is identified by the constant 6.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, all bits in this field MUST be set to zero, the such definition, the bits in this field MUST be set to zero and
receiver MUST ignore any DLRR Report Block with a non-zero value MUST be ignored by the receiver.
in this field.
block length: 16 bits block length: 16 bits
Defined in Section 3. Defined in Section 3.
last RR timestamp (LRR): 32 bits last RR timestamp (LRR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained The middle 32 bits out of 64 in the NTP timestamp (as explained
in the previous section) received as part of a Receiver in the previous section) received as part of a Receiver
Timestamp Report Block from participant SSRC_n. If no such block Timestamp Report Block from participant SSRC_n. If no such block
has been received, the field is set to zero. has been received, the field is set to zero.
skipping to change at page 22, line 5 skipping to change at page 21, line 50
isolated lost packets may occur, and in general these can be masked isolated lost packets may occur, and in general these can be masked
by packet loss concealment. Delay reports include the transit delay by packet loss concealment. Delay reports include the transit delay
between RTCP end points and the VoIP end system processing delays, between RTCP end points and the VoIP end system processing delays,
both of which contribute to the user perceived delay. Additional both of which contribute to the user perceived delay. Additional
metrics include signal, echo, noise, and distortion levels. Call metrics include signal, echo, noise, and distortion levels. Call
quality metrics include R factors (as described by the E Model quality metrics include R factors (as described by the E Model
defined in [2]) and mean opinion scores (MOS scores). defined in [2]) and mean opinion scores (MOS scores).
An implementation that sends these blocks SHOULD send at least one An implementation that sends these blocks SHOULD send at least one
every ten seconds for the duration of the call, SHOULD send one every ten seconds for the duration of the call, SHOULD send one
whenever a CODEC type change or other significant change occurs, whenever a codec type change or other significant change occurs,
SHOULD send one when significant call quality degradation is detected SHOULD send one when significant call quality degradation is detected
and SHOULD send one upon call termination. Implementations MUST and SHOULD send one upon call termination. Implementations MUST
provide values for all the fields defined here. For certain metrics, provide values for all the fields defined here. For certain metrics,
if the value is undefined or unknown, then the specified default or if the value is undefined or unknown, then the specified default or
unknown field value MUST be provided. unknown field value MUST be provided.
The block is encoded as seven 32-bit words: The block is encoded as seven 32-bit words:
0 1 2 3 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 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=7 | reserved | block length = 6 | | BT=7 | reserved | block length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density | | loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration | | burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay | | round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal power | RERL | noise level | Gmin | | signal level | noise level | RERL | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R factor | ext. R factor | MOS-LQ | MOS-CQ | | R factor | ext. R factor | MOS-LQ | MOS-CQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX config | JB nominal | JB maximum | JB abs max | | RX config | JB nominal | JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits block type (BT): 8 bits
A VoIP Metrics Report Block is identified by the constant 7. A VoIP Metrics Report Block is identified by the constant 7.
reserved: 8 bits reserved: 8 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, all bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
the receiver MUST ignore any VoIP Metrics Report Block with a MUST be ignored by the receiver.
non-zero value in this field.
block length: 16 bits block length: 16 bits
The constant 6, in accordance with the definition of this field The constant 6, in accordance with the definition of this field
in Section 3. in Section 3.
The remaining fields are described in the following six sections: The remaining fields are described in the following six sections:
Packet Loss and Discard Metrics, Delay Metrics, Signal Related Packet Loss and Discard Metrics, Delay Metrics, Signal Related
Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, Call Quality or Transmission Quality Metrics, Configuration
Metrics, and Jitter Buffer Parameters. Metrics, and Jitter Buffer Parameters.
skipping to change at page 27, line 4 skipping to change at page 26, line 44
provided in all VoIP metrics reports. provided in all VoIP metrics reports.
Note that the one way symmetric VoIP segment delay may be calculated 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 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 trip delay is denoted RTD and the end system delays associated with
the two endpoints are ESD(A) and ESD(B) then: the two endpoints are ESD(A) and ESD(B) then:
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
4.7.4 Signal Related Metrics 4.7.4 Signal Related Metrics
The following metrics are intended to provide real time information The following metrics are intended to provide real time information
related to the non-packet elements of the voice over IP system to related to the non-packet elements of the voice over IP system to
assist with the identification of problems affecting call quality. assist with the identification of problems affecting call quality.
The values identified below must be determined for the received audio The values identified below must be determined for the received audio
signal. The information required to populate these fields may not be signal. The information required to populate these fields may not be
available in all systems, although it is strongly recommended that available in all systems, although it is strongly recommended that
this data SHOULD be provided to support problem diagnosis. this data SHOULD be provided to support problem diagnosis.
signal power: 8 bits signal level: 8 bits
The voice signal relative level is defined as the ratio of the The voice signal relative level is defined as the ratio of the
signal level to overflow signal level, expressed in decibels as signal level to a reference digital milliwatt, expressed in
a signed integer in two's complement form. This is measured decibels as a signed integer in two's complement form. This is
only for packets containing speech energy. The intent of this measured only for packets containing speech energy. The intent
metric is not to provide a precise measurement of the signal of this metric is not to provide a precise measurement of the
level but to provide a real time indication that the signal signal level but to provide a real time indication that the
level may be excessively high or low. If the full range signal level may be excessively high or low.
(overflow level) of the Vocoder's digital to analog conversion
function is +/- L and the value of a decoded sample during a
talkspurt is V then the signal level is given by:
signal level = 10 log10 ( mean( abs(V) / L ) ) signal level = 10 log 10 ( rms talkspurt power (mW) )
A value of 127 indicates that this parameter is unavailable.
Typical values should be generally in the -15 to -20 dBm range.
noise level: 8 bits
The noise level is defined as the ratio of the silent period
background noise level to a reference digital milliwatt,
expressed in decibels as a signed integer in two's complement
form.
noise level = 10 log10 ( rms silence power (mW) )
A value of 127 indicates that this parameter is unavailable. A value of 127 indicates that this parameter is unavailable.
residual echo return loss (RERL): 8 bits residual echo return loss (RERL): 8 bits
The residual echo return loss is defined as the sum of the The residual echo return loss is defined as the sum of the
measured echo return loss (ERL) and the echo return loss measured echo return loss (ERL) and the echo return loss
enhancement (ERLE) expressed in dB as a signed integer in two's enhancement (ERLE) expressed in dB as a signed integer in two's
complement form. It defines the ratio of a transmitted voice complement form. It defines the ratio of a transmitted voice
signal that is reflected back to the talker. A low level of signal that is reflected back to the talker. A low level of
echo return loss (say less than 20 dB) in conjunction with some echo return loss (say less than 20 dB) in conjunction with some
delay can lead to hollowness or audible echo. A high level of delay can lead to hollowness or audible echo. A high level of
echo return loss (say over 40 dB) is preferable. echo return loss (say over 40 dB) is preferable.
The ERL and ERLE parameters are often available directly from the The ERL and ERLE parameters are often available directly from the
echo cancellor contained within the VoIP end system. They relate to echo canceler contained within the VoIP end system. They relate to
the echo on the external network attached to the end point. the echo on the external network attached to the end point.
In the case of a VoIP gateway this would be line echo that typically In the case of a VoIP gateway this would be line echo that typically
occurs at 2-4 wire conversion points in the network. Echo return occurs at 2-4 wire conversion points in the network. Echo return
loss from typical 2-4 wire conversions can be in the 8-12 dB range. loss from typical 2-4 wire conversions can be in the 8-12 dB range.
A line echo cancellor can provide an ERLE of 30 dB or more and hence A line echo canceler can provide an ERLE of 30 dB or more and hence
reduce this to 40-50 dB. In the case of an IP phone this could be reduce this to 40-50 dB. In the case of an IP phone this could be
residual acoustic echo from speakerphone operation, and may more residual acoustic echo from speakerphone operation, and may more
correctly be termed terminal coupling loss (TCL). A typical handset correctly be termed terminal coupling loss (TCL). A typical handset
would result in 40-50 dB of echo due to acoustic feedback. would result in 40-50 dB of echo due to acoustic feedback.
Typical values for RERL are as follows: Typical values for RERL are as follows:
(i) IP gateway connected to circuit switched network with 2 wire loop (i) IP gateway connected to circuit switched network with 2 wire loop
Without echo cancellation, typical 2-4 wire convertor ERL of 12 dB Without echo cancellation, typical 2-4 wire converter ERL of 12 dB
RERL = ERL + ERLE = 12 + 0 = 12 dB RERL = ERL + ERLE = 12 + 0 = 12 dB
(ii) IP gateway connected to circuit switched network with 2 wire loop (ii) IP gateway connected to circuit switched network with 2 wire loop
With echo cancellor that improves echo by 30 dB With echo canceler that improves echo by 30 dB
RERL = ERL + ERLE = 12 + 30 = 42 dB RERL = ERL + ERLE = 12 + 30 = 42 dB
(iii) IP phone with conventional handset (iii) IP phone with conventional handset
Acoustic coupling from handset speaker to microphone 40 dB Acoustic coupling from handset speaker to microphone 40 dB
Residual echo return loss = TCL = 40 dB Residual echo return loss = TCL = 40 dB
If we denote the "local" end of the VoIP path as A and the remote end If we denote the "local" end of the VoIP path as A and the remote end
as B and if the sender loudness rating (SLR) and receiver loudness as B and if the sender loudness rating (SLR) and receiver loudness
rating (RLR) are known for A (default values 8 dB and 2 dB rating (RLR) are known for A (default values 8 dB and 2 dB
respectively), then the echo loudness level at end A (talker echo respectively), then the echo loudness level at end A (talker echo
skipping to change at page 28, line 36 skipping to change at page 28, line 39
Hence in order to incorporate echo into a voice quality estimate at Hence in order to incorporate echo into a voice quality estimate at
the A end of a VoIP connection it is desirable to send the ERL + ERLE the A end of a VoIP connection it is desirable to send the ERL + ERLE
value from B to A. value from B to A.
For an IP phone with handset this metric MUST be set to the designed For an IP phone with handset this metric MUST be set to the designed
or measured terminal coupling loss, which would typically be 40-50 or measured terminal coupling loss, which would typically be 40-50
dB. dB.
For a PC softphone or speakerphone this metric MUST be set to either For a PC softphone or speakerphone this metric MUST be set to either
the value reported by the acoustic echo cancellor or to 127 to the value reported by the acoustic echo canceler or to 127 to
indicate an undefined value. indicate an undefined value.
For an IP gateway with ERL and ERLE measurements this metric MUST be For an IP gateway with ERL and ERLE measurements this metric MUST be
reported as ERL + ERLE. reported as ERL + ERLE.
For an IP gateway without ERL and ERLE measurement capability then For an IP gateway without ERL and ERLE measurement capability then
this metric MUST be reported as 12 dB if line echo cancellation is this metric MUST be reported as 12 dB if line echo cancellation is
disabled and 40 dB if line echo cancellation is enabled. disabled and 40 dB if line echo cancellation is enabled.
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 (overflow 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.
Gmin Gmin
See Configuration Parameters (Section 4.7.6, below). See Configuration Parameters (Section 4.7.6, below).
4.7.5 Call Quality or Transmission Quality Metrics 4.7.5 Call Quality or Transmission Quality Metrics
The following metrics are direct measures of the call quality or The following metrics are direct measures of the call quality or
transmission quality, and incorporate the effects of CODEC type, transmission quality, and incorporate the effects of codec type,
packet loss, discard, burstiness, delay etc. These metrics may not packet loss, discard, burstiness, delay etc. These metrics may not
be available in all systems however SHOULD be provided in order to be available in all systems however SHOULD be provided in order to
support problem diagnosis. support problem diagnosis.
R factor: 8 bits R factor: 8 bits
The R factor is a voice quality metric describing the segment of The R factor is a voice quality metric describing the segment of
the call that is carried over this RTP session. It is expressed 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 as an integer in the range 0 to 100, with a value of 94
corresponding to "toll quality" and values of 50 or less corresponding to "toll quality" and values of 50 or less
regarded as unusable. This metric is defined as including the regarded as unusable. This metric is defined as including the
skipping to change at page 31, line 15 skipping to change at page 31, line 8
Standard (11) / enhanced (10) / disabled (01) / unspecified Standard (11) / enhanced (10) / disabled (01) / unspecified
(00). When PLC = 11 then a simple replay or interpolation (00). When PLC = 11 then a simple replay or interpolation
algorithm is being used to fill-in the missing packet. algorithm is being used to fill-in the missing packet.
This is typically able to conceal isolated lost packets This is typically able to conceal isolated lost packets
with loss rates under 3%. When PLC = 10 then an enhanced with loss rates under 3%. When PLC = 10 then an enhanced
interpolation algorithm is being used. This would interpolation algorithm is being used. This would
typically be able to conceal lost packets for loss rates of typically be able to conceal lost packets for loss rates of
10% or more. When PLC = 01 then silence is inserted in 10% or more. When PLC = 01 then silence is inserted in
place of lost packets. When PLC = 00 then no information place of lost packets. When PLC = 00 then no information
is available concerning the use of PLC however for some is available concerning the use of PLC however for some
CODECs this may be inferred. codecs this may be inferred.
jitter buffer adaptive (JBA): 2 bits jitter buffer adaptive (JBA): 2 bits
Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
(00). When the jitter buffer is adaptive then its size is (00). When the jitter buffer is adaptive then its size is
being dynamically adjusted to deal with varying levels of being dynamically adjusted to deal with varying levels of
jitter. When non-adaptive, the jitter buffer size is jitter. When non-adaptive, the jitter buffer size is
maintained at a fixed level. When either adaptive or non- maintained at a fixed level. When either adaptive or non-
adaptive modes are specified then the jitter buffer size adaptive modes are specified then the jitter buffer size
parameters below MUST be specified. parameters below MUST be specified.
skipping to change at page 36, line 23 skipping to change at page 36, line 10
state 4 = lost an isolated packet during a gap state 4 = lost an isolated packet during a gap
The "c" variables below correspond to state transition counts, i.e. 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 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 infer one of a pair of state transition counts to an accuracy of 1
which is generally sufficient for this application. which is generally sufficient for this application.
"pkt" is the count of packets received since the last packet was "pkt" is the count of packets received since the last packet was
declared lost or discarded and "lost" is the number of packets lost declared lost or discarded and "lost" is the number of packets lost
within the current burst. "packet_lost" and "packet_discarded" are within the current burst. "packet_lost" and "packet_discarded" are
boolean variables that indicate if the event that resulted in this Boolean variables that indicate if the event that resulted in this
function being invoked was a lost or discarded packet. function being invoked was a lost or discarded packet.
if(packet_lost) { if(packet_lost) {
loss_count++; loss_count++;
} }
if(packet_discarded) { if(packet_discarded) {
discard_count++; discard_count++;
} }
if(!packet_lost && !packet_discarded) { if(!packet_lost && !packet_discarded) {
pkt++; pkt++;
skipping to change at page 38, line 43 skipping to change at page 38, line 29
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgements Acknowledgments
We thank the following people: Colin Perkins, Steve Casner, and We thank the following people: Colin Perkins, Steve Casner, and
Henning Schulzrinne for their considered guidance; Sue Moon for Henning Schulzrinne for their considered guidance; Sue Moon for
helping foster collaboration between the authors; Magnus Westerlund helping foster collaboration between the authors; Magnus Westerlund
for his detailed comments; Mounir Benzaid for drawing our attention for his detailed comments; Mounir Benzaid for drawing our attention
to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz
for encouraging us to incorporate MLDA block types. for encouraging us to incorporate MLDA block types.
Contributors Contributors
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/