the end packet, minus the timestamp of the beginning packet.
If the actual values are not available, estimated values MUST
be used. If there have been no burst periods, the burst
duration value MUST be zero.
gap duration: 16 bits
The mean duration, expressed in milliseconds, of the gap
periods that have occurred since the beginning of reception.
The duration of each period 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 periods, the gap duration value MUST
be zero.
4.7.3. 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
considered 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
The most recently calculated round trip time between RTP
interfaces, expressed in milliseconds. This value MAY be
measured using RTCP, the DLRR method defined in Section 4.5 of
this document, where it is necessary to convert the units of
measurement from NTP timestamp values to milliseconds, or other
approaches. If RTCP is used, then the reported delay 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; however, this
field 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
milliseconds. End system delay is defined as the sum of the
total sample accumulation and encoding delay associated with
the sending direction and the jitter buffer, decoding, and
playout buffer delay associated with the receiving direction.
This delay MAY be estimated or measured. This value SHOULD be
provided in all VoIP metrics reports. If an implementation is
unable to provide the data, the value 0 MUST be used.
Note that the one way symmetric VoIP segment delay may be calculated
from the round trip and end system delays is 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.4. 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 a 0 dBm0 reference [10], 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 provide a precise measurement of the signal
level but to provide a real time indication that the signal
level may be excessively high or low.
signal level = 10 Log10 ( rms talkspurt power (mW) )
A value of 127 indicates that this parameter is unavailable.
Typical values should generally be 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 0 dBm0 reference, 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.
residual echo return loss (RERL): 8 bits
The residual echo return loss value may be measured directly by
the VoIP end system’s echo canceller or may be estimated by
adding the echo return loss (ERL) and echo return loss
enhancement (ERLE) values reported by the echo canceller.
RERL(dB) = ERL (dB) + ERLE (dB)
In the case of a VoIP gateway, the source of echo is typically
line echo that occurs at 2-4 wire conversion points in the
network. This can be in the 8-12 dB range. 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
acoustic coupling between handset speaker and microphone or
residual acoustic echo from speakerphone operation, and may
more correctly be termed terminal coupling loss (TCL). A
typical handset would result in 40-50 dB of echo loss due to
acoustic feedback.
Examples:
- IP gateway connected to circuit switched network with 2 wire
loop. Without echo cancellation, typical 2-4 wire converter
ERL of 12 dB. RERL = ERL + ERLE = 12 + 0 = 12 dB.
- IP gateway connected to circuit switched network with 2 wire
loop. With echo canceler that improves echo by 30 dB.
RERL = ERL + ERLE = 12 + 30 = 42 dB.
- IP phone with conventional handset. Acoustic coupling from
handset speaker to microphone (terminal coupling loss) is
typically 40 dB. RERL = TCL = 40 dB.
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 rating (RLR) are known for A (default values 8 dB and
2 dB respectively), then the echo loudness level at end A
(talker echo loudness rating or TELR) is given by:
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
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 value from B to A using a format such as
RTCP XR.
Echo related information may not be available in all VoIP end
systems. As echo does have a significant effect on
conversational quality, it is recommended that estimated values
for echo return loss and terminal coupling loss be provided (if
sensible estimates can be reasonably determined).
Typical values for end systems are given below to provide
guidance:
- IP Phone with handset: typically 45 dB.
- PC softphone or speakerphone: extremely variable, consider
reporting "undefined" (127).
- IP gateway with line echo canceller: typically has ERL and
ERLE available.
- IP gateway without line echo canceller: frequently a source
of echo related problems, consider reporting either a low
value (12 dB) or "undefined" (127).
Gmin
See Configuration Parameters (Section 4.7.6, below).
4.7.5. Call Quality or Transmission Quality Metrics
The following metrics are direct measures of the call quality or
transmission quality, and incorporate the effects of codec type,
packet loss, discard, burstiness, delay etc. These metrics may not
be available in all systems, however, they SHOULD be provided in
order to support 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 metric is defined as including the
effects of delay, consistent with ITU-T G.107 [6] and ETSI TS
101 329-5 [3].
A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST
not be sent and MUST be ignored by the receiving system.
ext. R factor: 8 bits
The external R factor is a voice quality metric describing the
segment 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
[3], and relates to the outward voice path from the Voice over
IP termination for which this metrics block applies.
A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST
not be sent and MUST be ignored by the receiving system.
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
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 example, a value of 35 would
correspond to an estimated MOS score of 3.5.
A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST
not be sent and MUST be ignored by the receiving system.
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 [3] into an
estimated MOS using the equation specified in G.107. It is
expressed as an integer in the range 10 to 50, corresponding to
MOS x 10, as for MOS-LQ.
A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST
not be sent and MUST be ignored by the receiving system.
4.7.6. Configuration Parameters
Gmin: 8 bits
The gap threshold. This field contains the value used for this
report block to determine if a gap exists. The recommended
value of 16 corresponds to a burst period having a minimum
density of 6.25% of lost or discarded packets, which may cause
noticeable degradation in call quality; during gap periods, if
packet loss or discard occurs, each lost or discarded packet
would be preceded by and followed by a sequence of at least 16
received non-discarded packets. Note that lost or discarded
packets that occur within Gmin packets of a report being
generated may be reclassified as part of a burst or gap in
later reports. ETSI TS 101 329-5 [3] defines a computationally
efficient algorithm for measuring burst and gap density using a
packet loss/discard event driven approach. This algorithm is
reproduced in Appendix A.2 of the present document. Gmin MUST
not be zero, MUST be provided, and MUST remain constant across
VoIP Metrics report blocks for the duration of the RTP session.
receiver configuration byte (RX config): 8 bits
This byte consists of the following fields:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+
packet loss concealment (PLC): 2 bits
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
approach is typically able to conceal isolated lost packets at
low packet loss rates. When PLC = 10, then an enhanced
interpolation algorithm is being used; algorithms of this type
are able to conceal high packet loss rates effectively. When
PLC = 01, then silence is being 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.
jitter buffer adaptive (JBA): 2 bits
Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown
(00). When the jitter buffer is adaptive, then its size is
being dynamically adjusted to deal with varying levels of
jitter. When non-adaptive, the jitter buffer size is
maintained at a fixed level. When either adaptive or non-
adaptive modes are specified, then the jitter buffer size
parameters below MUST be specified.
jitter buffer rate (JB rate): 4 bits
J = adjustment rate (0-15). This represents the implementation
specific 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 30 ms to 100 ms such that:
adjustment time = 2 * J * frame size (ms)
This parameter is intended only to provide a guide to the
degree of "aggressiveness" of an adaptive jitter buffer and may
be estimated. A value of 0 indicates that the adjustment time
is unknown for this implementation.
reserved: 8 bits
This field is reserved for future definition. In the absence
of such a definition, the bits in this field MUST be set to
zero and MUST be ignored by the receiver.
4.7.7. Jitter Buffer Parameters
The values reported in these fields SHOULD be the most recently
obtained values at the time of reporting.
jitter buffer nominal delay (JB nominal): 16 bits
This is the current nominal jitter buffer delay in
milliseconds, 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 delay (JB maximum): 16 bits
This is the current maximum jitter buffer delay in milliseconds
which corresponds 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 JB abs
max (see below). This parameter MUST be provided for both
fixed and adaptive jitter buffer implementations.
jitter buffer absolute maximum delay (JB abs max): 16 bits
This is the absolute maximum delay in milliseconds that the
adaptive jitter buffer can reach under worst case conditions.
If this value exceeds 65535 milliseconds, then this field SHALL
convey the value 65535. This parameter MUST be provided for
adaptive jitter buffer implementations and its value MUST be
set to JB maximum for fixed jitter buffer implementations.
5. SDP Signaling
This section defines Session Description Protocol (SDP) [4] signaling
for XR blocks that can be employed by applications that utilize SDP.
This signaling is defined to be used either by applications that
implement the SDP Offer/Answer model [8] or by applications that use
SDP to describe media and transport configurations in connection
with such protocols as the Session Announcement Protocol (SAP) [15]
or the Real Time Streaming Protocol (RTSP) [17]. There exist other
potential signaling methods that are not defined here.
The XR blocks MAY be used without prior signaling. This is
consistent with the rules governing other RTCP packet types, as
described in [9]. An example in which signaling would not be used is
an application that always requires the use of one or more XR blocks.
However, for applications that are configured at session initiation,
the use of some type of signaling is recommended.
Note that, although the use of SDP signaling for XR blocks may be
optional, if used, it MUST be used as defined here. If SDP signaling
is used in an environment where XR blocks are only implemented by
some fraction of the participants, the ones not implementing the XR
blocks will ignore the SDP attribute.
5.1. The SDP Attribute
This section defines one new SDP attribute "rtcp-xr" that can be used
to signal participants in a media session that they should use the
specified XR blocks. This attribute can be easily extended in the
future with new parameters to cover any new report blocks.
The RTCP XR blocks SDP attribute is defined below in Augmented
Backus-Naur Form (ABNF) [2]. It is both a session and a media level
attribute. When specified at session level, it applies to all media
level blocks in the session. Any media level specification MUST
replace a session level specification, if one is present, for that
media block.
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
xr-format = pkt-loss-rle
/ pkt-dup-rle
/ pkt-rcpt-times
/ rcvr-rtt
/ stat-summary
/ voip-metrics
/ format-ext
pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
rcvr-rtt-mode = "all"
/ "sender"
stat-summary = "stat-summary" ["=" stat-flag *("," stat-flag)]
stat-flag = "loss"
/ "dup"
/ "jitt"
/ "TTL"
/ "HL"
voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39
format-ext = non-ws-string
non-ws-string = 1*(%x21-FF)
CRLF = %d13.10
The "rtcp-xr" attribute contains zero, one, or more XR block related
parameters. Each parameter signals functionality for an XR block, or
a group of XR blocks. The attribute is extensible so that parameters
can be defined for any future XR block (and a parameter should be
defined for every future block).
Each "rtcp-xr" parameter belongs to one of two categories. The first
category, the unilateral parameters, are for report blocks that
simply report on the RTP stream and related metrics. The second
category, collaborative parameters, are for XR blocks that involve
actions by more than one party in order to carry out their functions.
Round trip time (RTT) measurement is an example of collaborative
functionality. An RTP data packet receiver sends a Receiver
Reference Time Report Block (Section 4.4). A participant that
receives this block sends a DLRR Report Block (Section 4.5) in
response, allowing the receiver to calculate its RTT to that
participant. As this example illustrates, collaborative
functionality may be implemented by two or more different XR blocks.
The collaborative functionality of several XR blocks may be governed
by a single "rtcp-xr" parameter.
For the unilateral category, this document defines the following
parameters. The parameter names and their corresponding XR formats
are as follows:
Parameter name XR block (block type and name)
-------------- ------------------------------------