Internet Engineering Task Force (IETF) A. Pendleton
Request for Comments: 6035 A. Clark
Category: Standards Track Telchemy Incorporated
ISSN: 2070-1721 A. Johnston
Avaya
H. Sinnreich
Unaffiliated
November 2010
Session Initiation Protocol Event Package for Voice Quality Reporting
Abstract
This document defines a Session Initiation Protocol (SIP) event
package that enables the collection and reporting of metrics that
measure the quality for Voice over Internet Protocol (VoIP) sessions.
Voice call quality information derived from RTP Control Protocol
Extended Reports (RTCP-XR) and call information from SIP is conveyed
from a User Agent (UA) in a session, known as a reporter, to a third
party, known as a collector. A registration for the application/ vq-
rtcpxr media type is also included.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6035.
Pendleton, et al. Standards Track [Page 1]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Pendleton, et al. Standards Track [Page 2]

RFC 6035 SIP Package for Voice Quality Reporting November 20101. Introduction
Real-time communications over IP networks use SIP for signaling with
RTP/RTCP for media transport and reporting, respectively. These
protocols are very flexible and can support an extremely wide
spectrum of usage scenarios. For this reason, extensions to these
protocols must be specified in the context of a specific usage
scenario. In this memo, extensions to SIP are proposed to support
the reporting of RTP Control Protocol Extended Reports [4] metrics.
1.1. Applicability Statement
RTP is utilized in many different architectures and topologies. RFC5117 [13] lists and describes the following topologies: point-to-
point, point-to-multipoint using multicast, point-to-multipoint using
the translator from RFC 3550, point-to-multipoint using the mixer
model from RFC 3550, point-to-multipoint using video-switching
Multipoint Control Units (MCUs), point-to-multipoint using RTCP-
terminating MCU, and non-symmetric mixer/translators. As the
Abstract of this document points out, this specification is for
reporting quality of Voice over Internet Protocol (VoIP) sessions.
As such, only the first topology, point to point, is currently
supported by this specification. This reflects both current VoIP
deployments, which are predominantly point to point using unicast,
and the state of research in the area of quality.
How to accurately report the quality of a multipart conference or a
session involving multiple hops through translators and mixers is
currently an area of research in the industry. However, this
mechanism can easily be used for centrally mixed conference calls, in
which each leg of the conferences is just a point-to-point call.
This mechanism could be extended to cover additional RTP topologies
in the future once these topics progress out of the realm of research
and into actual Internet deployments.
1.2. Use of the Mechanism
RTCP reports are usually sent to other participating endpoints in a
session. This can make the collection of performance information by
an administrator or management system quite complex to implement. In
the usage scenarios addressed in this memo, the data contained in
RTCP XR VoIP metrics reports (RFC 3611 [4]) are forwarded to a
central collection server systems using SIP.
Pendleton, et al. Standards Track [Page 4]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
Applications residing in the server or elsewhere can aid in network
management to alleviate bandwidth constraints and also to support
customer service by identifying and acknowledging calls of poor
quality. However, specifying such applications is beyond the scope
of this paper.
There is a large portfolio of quality parameters that can be
associated with VoIP, but only a minimal necessary number of
parameters are included on the RTCP-XR reports:
1. The codec type, as resulting from the Session Description
Protocol (SDP) offer-answer negotiation in SIP,
2. The burst gap loss density and max gap duration, since voice cut-
outs are the most annoying quality impairment in VoIP,
3. Round-trip delay, because it is critical to conversational
quality,
4. Conversational quality as a catch-all for other voice quality
impairments, such as randomly distributed packet loss, jitter,
annoying silent suppression effects, etc.
In specific usage scenarios where other parameters are required,
designers can include other parameters beyond the scope of this
paper.
RTCP reports are best effort only, and though they are very useful,
they have a number of limitations as discussed in [3]. This must be
considered when using RTCP reports in managed networks.
This document defines a new SIP event package, vq-rtcpxr, and a new
MIME type, application/vq-rtcpxr, that enable the collection and
reporting of metrics that measure quality for RTP [3] sessions. The
definitions of the metrics used in the event package are based on
RTCP Extended Reports [4] and RTCP [3]; a mapping between the SIP
event parameters and the parameters within the aforementioned RFCs is
defined within this document in Section 4.6.2.
Monitoring of voice quality is believed to be the highest priority
for usage of this mechanism, and as such, the metrics in the event
package are largely tailored for voice quality measurements. The
event package is designed to be extensible. However, the negotiation
of such extensions is not defined in this document.
The event package supports reporting the voice quality metrics for
both the inbound and outbound directions. Voice quality metrics for
the inbound direction can generally be computed locally by the
Pendleton, et al. Standards Track [Page 5]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
reporting endpoint; however, voice quality metrics for the outbound
direction are computed by the remote endpoint and sent to the
reporting endpoint using the RTCP Extended Reports [4].
The configuration of the usage of this event package is not covered
in this document. It is the recommendation of this document that the
SIP configuration framework [15] be used. This is discussed in
Section 4.8.
The event package SHOULD be used with the SUBSCRIBE/NOTIFY method;
however, it MAY also be used with the PUBLISH method [8] for backward
compatibility with some existing implementations. Message flow
examples for both methods are provided in this document.
2. 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 BCP 14, RFC 2119 [1].
3. SIP Events for VoIP Quality Reporting
This document defines a SIP events package [5] for Voice over IP
performance reporting. A SIP UA can send these events to an entity
that can make the information available to other applications. For
purposes of illustration, the entities involved in SIP vq-rtcpxr
event reporting will be referred to as follows:
o REPORTER: an entity involved in the measurement and reporting of
media quality, i.e., the SIP UA involved in a media session.
o COLLECTOR: an entity that receives SIP vq-rtcpxr events. A
COLLECTOR may be a proxy server or another entity that is capable
of supporting SIP vq-rtcpxr events.
3.1. SUBSCRIBE NOTIFY Method
The COLLECTOR SHALL send a SUBSCRIBE to the REPORTER to explicitly
establish the relationship. The REPORTER SHOULD send the voice
quality metric reports using the NOTIFY method. The REPORTER MUST
NOT send any vq-rtcpxr events if a COLLECTOR address has not been
configured. The REPORTER populates the Request-URI according to the
rules for an in-dialog request. The COLLECTOR MAY send a SUBSCRIBE
to a SIP Proxy acting on behalf of the reporting SIP UAs.
Pendleton, et al. Standards Track [Page 6]

RFC 6035 SIP Package for Voice Quality Reporting November 20103.2. PUBLISH Method
A SIP UA that supports this specification MAY also send the service
quality metric reports using the PUBLISH method [8]; however, this
approach SHOULD NOT be used, in general, on the public Internet. The
PUBLISH method MAY be supported for backward compatibility with
existing implementations.
The REPORTER MAY therefore populate the Request-URI of the PUBLISH
method with the address of the COLLECTOR. To ensure security of SIP
proxies and the COLLECTOR, the REPORTER MUST be configured with the
address of the COLLECTOR, preferably using the SIP UA configuration
framework [15], as described in Section 5.8.
It is RECOMMENDED that the REPORTER send an OPTIONS message to the
COLLECTOR to ensure support of the PUBLISH message.
If PUBLISH is not supported, then the REPORTER can only wait for a
SUBSCRIBE request from the COLLECTOR and then deliver the
information in NOTIFYs. If a REPORTER sends a PUBLISH to a
COLLECTOR that does not support or allow this method, a 501 Not
Implemented or a 405 Method Not Allowed response will be received,
and the REPORTER will stop publication.
3.3. Multi-Party and Multi-Segment Calls
A voice quality metric report may be sent for each session
terminating at the REPORTER, and it may contain multiple report
bodies. For a multi-party call, the report MAY contain report bodies
for the session between the reporting endpoint and each remote
endpoint for which there was an RTP session during the call.
Multi-party services such as call hold and call transfer can result
in the user participating in a series of concatenated sessions,
potentially with different choices of codec or sample rate, although
these may be perceived by the user as a single call. A REPORTER MAY
send a voice quality metric report at the end of each session or MAY
send a single voice quality metric report containing an application/
vq-rtcpxr body for each segment of the call.
3.4. Overload Avoidance
Users of this extension should ensure that they implement general SIP
mechanisms for avoiding overload. For instance, an overloaded proxy
or COLLECTOR MUST send a 503 Service Unavailable or other 5xx
response with an appropriate Retry-After time specified. REPORTERs
MUST act on these responses and respect the Retry-After time
Pendleton, et al. Standards Track [Page 7]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
interval. In addition, future SIP extensions to better handle
overload as covered in [14] should be followed as they are
standardized.
To avoid overload of SIP Proxies or COLLECTORS, it is important to do
capacity planning and to minimize the number of reports that are
sent.
Approaches to avoiding overload include:
a. Send only one report at the end of each call.
b. Use interval reports only on "problem" calls that are being
closely monitored.
c. Limit the number of alerts that can be sent to a maximum of one
per call.
4. Event Package Formal Definition4.1. Event Package Name
This document defines a SIP Event Package. SIP Event Packages were
originally defined in RFC 3265 [5].
4.2. Event Package Parameters
No event package parameters are defined.
4.3. SUBSCRIBE Bodies
SUBSCRIBE bodies are described by this specification.
4.4. Subscribe Duration
Subscriptions to this event package MAY range from minutes to weeks.
Subscriptions in hours or days are more typical and are RECOMMENDED.
The default subscription duration for this event package is one hour.
4.5. NOTIFY Bodies
There are three notify bodies: a Session report, an Interval report,
and an Alert report.
The Session report SHOULD be used for reporting when a voice media
session terminates, when a media change occurs, such as a codec
change or a session fork, or when a session terminates due to no
media packets being received and MUST NOT be used for reporting at
Pendleton, et al. Standards Track [Page 8]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
arbitrary points in time. This report MUST be used for cumulative
metric reporting and the report timestamps MUST be from the start of
a media session to the time at which the report is generated.
The Interval report SHOULD be used for periodic or interval reporting
and MUST NOT be used for reporting of the complete media session.
This report is intended to capture short duration metric reporting
and the report intervals SHOULD be non-overlapping time windows.
The Alert report MAY be used when voice quality degrades during a
session. The time window to which an Alert report relates MAY be a
short time interval or from the start of the call to the point the
alert is generated; this time window SHOULD be selected to provide
the most useful information to support problem diagnosis.
Session, Interval, and Alert reports MUST populate the metrics with
values that are measured over the interval explicitly defined by the
"start" and "stop" timestamps.
Voice quality summary reports reference only one codec (payload
type). This payload type SHOULD be the main voice payload, not
comfort noise or telephone event payloads. For applications that
consistently and rapidly switch codecs, the most used codec should be
reported. All values in the report, such as IP addresses,
synchronization source (SSRC), etc., represent those values as
received by the REPORTER. In some scenarios, these may not be the
same on either end of the session -- the COLLECTOR will need logic to
be able to put these sessions together. The values of parameters
such as sample rate, frame duration, frame octets, packets per
second, round-trip delay, etc., depend on the type of report in which
they are present. If present in a Session or an Interval report,
they represent average values over the session or interval. If
present in an Alert report, they represent instantaneous values.
The REPORTER always includes local quality reporting information and
should, if possible, share remote quality reporting information to
the COLLECTOR. This remote quality could be available from received
RTCP-XR reports or other sources. Reporting this is useful in cases
where the other end might support RTCP-XR but not this voice quality
reporting.
This specification defines a new MIME type, application/vq-rtcpxr,
which is a text encoding of the RTCP and RTCP-XR statistics with some
additional metrics and correlation information.
Pendleton, et al. Standards Track [Page 9]

RFC 6035 SIP Package for Voice Quality Reporting November 20104.6. Voice Quality Event and Semantics
This section describes the syntax extensions required for event
publication in SIP. The formal syntax definitions described in this
section are expressed in the Augmented BNF [6] format used in SIP [2]
and contain references to elements defined therein.
Additionally, the definition of the timestamp format is provided in
[7]. Note that most of the parameters are optional. In practice,
most implementations will send a subset of the parameters. It is not
the intention of this document to define what parameters may or may
not be useful for monitoring the quality of a voice session, but to
enable reporting of voice quality. As such, the syntax allows the
implementer to choose which metrics are most appropriate for their
solution. As there are no "invalid", "unknown", or "not applicable"
values in the syntax, the intention is to exclude any parameters for
which values are not available, not applicable, or unknown.
The authors recognize that implementers may need to add new parameter
lines to the reports and new metrics to the existing parameter lines.
The extension tokens are intended to fulfill this need.
4.6.1. ABNF Syntax Definition
VQReportEvent = AlertReport / SessionReport / IntervalReport
SessionReport = "VQSessionReport" [ HCOLON "CallTerm" ] CRLF
SessionInfo CRLF
LocalMetrics [ CRLF RemoteMetrics ]
[ CRLF DialogID ]
; CallTerm indicates the final report of a session.
IntervalReport = "VQIntervalReport" [ HCOLON "CallTerm" ] CRLF
SessionInfo CRLF
LocalMetrics [ CRLF RemoteMetrics ]
[ CRLF DialogID ]
LocalMetrics = "LocalMetrics" HCOLON CRLF Metrics
RemoteMetrics = "RemoteMetrics" HCOLON CRLF Metrics
AlertReport = "VQAlertReport" HCOLON
MetricType WSP Severity WSP Direction CRLF
SessionInfo CRLF
LocalMetrics [ CRLF RemoteMetrics ]
[ DialogID ]
Pendleton, et al. Standards Track [Page 10]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
[ PacketLossConcealment WSP ]
[ SilenceSuppressionState ]
*(WSP Extension)
; PayloadType provides the PT parameter used in the RTP packets.
PayloadType = "PT" EQUAL (1*3DIGIT)
; PayloadDesc provides a text description of the codec.
; This parameter SHOULD use the IANA registry for
; media-type names defined by RFC 4855 where it unambiguously
; defines the codec. Refer to the "Audio Media Types"
; registry on http://www.iana.org.
PayloadDesc = "PD" EQUAL (word / DQUOTE word-plus DQUOTE)
; SampleRate reports the rate at which a voice was sampled
; in the case of narrowband codecs, this value will typically
; be 8000.
; For codecs that are able to change sample rates, the lowest and
; highest sample rates MUST be reported (e.g., 8000;16000).
SampleRate = "SR" EQUAL (1*6DIGIT) *(SEMI (1*66DIGIT))
; FrameDuration can be combined with the FramesPerPacket
; to determine the packetization rate; the units for
; FrameDuration are milliseconds. NOTE: for frame-based codecs,
; each frame constitutes a single frame; for sample-based codecs,
; a "frame" refers to the set of samples carried in an RTP packet.
FrameDuration = "FD" EQUAL (1*4DIGIT)
; FrameOctets provides the number of octets in each frame
; at the time the report is generated (i.e., last value).
; This MAY be used where FrameDuration is not available.
; NOTE: for frame-based codecs, each frame constitutes a single frame;
; for sample-based codecs, a "frame" refers to the set of samples
; carried in an RTP packet.
FrameOctets = "FO" EQUAL (1*5DIGIT)
; FramesPerPacket provides the number of frames in each RTP
; packet at the time the report is generated.
; NOTE: for frame-based codecs, each frame constitutes a single frame;
; for sample-based codecs, a "frame" refers to the set of samples
; carried in an RTP packet.
FramesPerPacket = "FPP" EQUAL (1*2DIGIT)
Pendleton, et al. Standards Track [Page 12]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
word-plus = 1*(alphanum / "-" / "." / "!" / "%" / "*" /
"_" / "+" / "`" / "'" / "~" /
"(" / ")" / "<" / ">" / ":" /
"\" / "/" / "[" / "]" / "?" /
"{" / "}" / "=" / " ")
4.6.2. Parameter Definitions and Mappings
Parameter values, codec types, and other aspects of the endpoints may
change dynamically during a session. The reported values of metrics
and configuration parameters SHALL be the current value at the time
the report is generated.
The Packet Loss Rate and Packet Discard Rate parameters are
calculated over the period between the starting and ending timestamps
for the report. These are normally calculated from a count of the
number of lost or discarded packets divided by the count of the
number of packets, and hence are based on the current values of these
counters at the time the report was generated.
Packet delay variation, signal level, noise level, and echo level are
computed as running or interval averages, based on the appropriate
standard, e.g., RFC 3550 for Packet Delay Variation (PDV), and the
sampled value of these running averages is reported. Delay, packet
size, jitter buffer size, and codec-related data may change during a
session and the current value of these parameters is reported as
sampled at the time the report is generated.
4.6.2.1. General Mapping Percentages from 8-bit, Fixed-Point NumbersRFC 3611 uses an 8-bit, 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 by the total number of packets expected
and multiplying the result by 256, and then taking the integer part.
For any RTCP XR parameter in this format, to map into the equivalent
SIP vq-rtcpxr parameter, simply reverse the equation, i.e., divide by
256 and take the integer part.
4.6.2.2. Timestamps
Following SIP and other IETF conventions, timestamps are provided in
Coordinated Universal Time (UTC) using the ABNF format provided in
RFC 3339 [7]. These timestamps SHOULD reflect, as closely as
possible, the actual time during which the media session was running
to enable correlation to related events occurring in the network and
to accounting or billing records.
Pendleton, et al. Standards Track [Page 21]

RFC 6035 SIP Package for Voice Quality Reporting November 20104.6.2.3. SessionDescription
The parameters in this field provide a shortened version of the
session SDP(s), containing only the relevant parameters for session
quality reporting purposes. Where values may change during a
session, for example, a codec may change rate, then the most-recent
value of the parameter is reported.
4.6.2.3.1. Payload Type
This is the "payload type" parameter used in the RTP packets, i.e.,
the codec. This field can also be mapped from the SDP "rtpmap"
attribute field "payload type". IANA-registered types SHOULD be
used.
4.6.2.3.2. Payload Desc
This parameter is a text description of the codec. This parameter
SHOULD use the IANA registry for media-type names where it
unambiguously defines the codec. Refer to the "Audio Media Types"
registry on http://www.iana.org.
4.6.2.3.3. Sample Rate
This parameter is mapped from the SDP "rtpmap" attribute field "clock
rate". The field provides the rate at which a voice was sampled,
measured in Hertz (Hz).
4.6.2.3.4. Packets Per Second
This parameter is not contained in RTP or SDP but can usually be
obtained from the device codec. Packets per second provides the
(rounded) number of RTP packets that are transmitted per second.
4.6.2.3.5. Frame Duration
This parameter is not contained in RTP or SDP but can usually be
obtained from the device codec. The field reflects the amount of
voice content in each frame within the RTP payload, measured in
milliseconds. Note that this value can be combined with the
FramesPerPacket to determine the packetization rate. Also, where a
sample-based codec is used, a "frame" refers to the set of samples
carried in an RTP packet.
Pendleton, et al. Standards Track [Page 22]

RFC 6035 SIP Package for Voice Quality Reporting November 20104.6.2.3.6. Frame Octets
This parameter is not contained in RTP or SDP but is usually provided
by the device codec. The field provides the number of octets in each
frame within the RTP payload. This field is usually not provided
when the FrameDuration is provided. Also, where a sample-based codec
is used, a "frame" refers to the set of samples carried in an RTP
packet.
4.6.2.3.7. Frames Per Packet
This parameter is not contained in RTP or SDP but can usually be
obtained from the device codec. This field provides the number of
frames in each RTP packet. Note that this value can be combined with
the FrameDuration to determine the packetization rate. Also, where a
sample-based codec is used, a "frame" refers to the set of samples
carried in an RTP packet.
4.6.2.3.8. FMTP Options
This parameter is taken directly from the SDP attribute "fmtp"
defined in RFC 4566.
4.6.2.3.9. Silence Suppression State
This parameter does not correspond to SDP, RTP, or RTCP XR. It
indicates whether silence suppression, also known as Voice Activity
Detection (VAD), is enabled for the identified session.
4.6.2.3.10. Packet Loss Concealment
This value corresponds to "PLC" in RFC 3611 in the VoIP Metrics
Report Block. The values defined by RFC 3611 are reused by this
recommendation and therefore no mapping is required.
4.6.2.4. LocalAddr
This field provides the IP address, port, and synchronization source
(SSRC) for the session from the perspective of the endpoint that is
measuring performance. The IPAddress MAY be in IPv4 or IPv6 format.
The SSRC is taken from SDP, RTCP, or RTCP XR input parameters.
In the presence of NAT and where a NAT-traversal mechanism such as
Session Traversal Utilities for NAT (STUN) [16] is used, the external
IP address can be reported, since the internal IP address is not
visible to the network operator.
Pendleton, et al. Standards Track [Page 23]

RFC 6035 SIP Package for Voice Quality Reporting November 20104.6.2.5. RemoteAddr
This field provides the IP address, port, and SSRC of the session
peer from the perspective of the remote endpoint measuring
performance. In the presence of NAT and where a NAT-traversal
mechanism such as STUN [16] is used, the external IP address can be
reported, since the internal IP address is not visible to the network
operator.
4.6.2.6. Jitter Buffer Parameters4.6.2.6.1. Jitter Buffer Adaptive
This value corresponds to "JBA" in RFC 3611 in the VoIP Metrics
Report Block. The values defined by RFC 3611 are unchanged and
therefore no mapping is required.
4.6.2.6.2. Jitter Buffer Rate
This value corresponds to "JB rate" in RFC 3611 in the VoIP Metrics
Report Block. The parameter does not require any conversion.
4.6.2.6.3. Jitter Buffer Nominal
This value corresponds to "JB nominal" in RFC 3611 in the VoIP
Metrics Report Block. The parameter does not require any conversion.
4.6.2.6.4. Jitter Buffer Max
This value corresponds to "JB maximum" in RFC 3611 in the VoIP
Metrics Report Block. The parameter does not require any conversion.
4.6.2.6.5. Jitter Buffer Abs Max
This value corresponds to "JB abs max" in RFC 3611 in the VoIP
Metrics Report Block. The parameter does not require any conversion.
4.6.2.7. Packet Loss Parameters4.6.2.7.1. Network Loss Rate
This value corresponds to "loss rate" in RFC 3611 in the VoIP Metrics
Report Block. For conversion, see Section 4.6.2.1. A loss rate of
100% MAY be reported if media packets were expected but none had been
received at the time of session termination.
Pendleton, et al. Standards Track [Page 24]

RFC 6035 SIP Package for Voice Quality Reporting November 20104.6.2.7.2. Jitter Buffer Discard Rate
This value corresponds to "discard rate" in RFC 3611 in the VoIP
Metrics Report Block. For conversion, see Section 4.6.2.1.
4.6.2.8. Burst/Gap Parameters4.6.2.8.1. Burst Loss Density
This value corresponds to "burst density" in RFC 3611 in the VoIP
Metrics Report Block. For conversion, see Section 4.6.2.1.
4.6.2.8.2. Burst Duration
This value corresponds to "burst duration" in RFC 3611 in the VoIP
Metrics Report Block. This value requires no conversion; the exact
value sent in an RTCP XR VoIP Metrics Report Block can be included in
the SIP vq-rtcpxr parameter.
4.6.2.8.3. Gap Loss Density
This value corresponds to "gap density" in RFC 3611 in the VoIP
metrics Report Block.
4.6.2.8.4. Gap Duration
This value corresponds to "gap duration" in RFC 3611 in the VoIP
Metrics Report Block. This value requires no conversion; the exact
value sent in an RTCP XR VoIP Metrics Report Block can be reported.
4.6.2.8.5. Minimum Gap Threshold
This value corresponds to "Gmin" in RFC 3611 in the VoIP Metrics
Report Block. This value requires no conversion; the exact value
sent in an RTCP XR VoIP Metrics Report Block can be reported.
4.6.2.9. Delay Parameters4.6.2.9.1. Round-Trip Delay
This value corresponds to "round trip delay" in RFC 3611 in the VoIP
Metrics Report Block and may be measured using the method defined in
RFC 3550. The parameter is expressed in milliseconds.
Pendleton, et al. Standards Track [Page 25]

RFC 6035 SIP Package for Voice Quality Reporting November 20104.6.2.9.2. End System Delay
This value corresponds to "end system delay" in RFC 3611 in the VoIP
Metrics Report Block. This parameter does not require any
conversion. The parameter is expressed in milliseconds.
4.6.2.9.3. Symmetric One-Way Delay
This value is computed by adding Round-Trip Delay to the local and
remote End System Delay and dividing by two.
4.6.2.9.4. One-Way Delay
This value SHOULD be measured using the methods defined in IETF RFC2679 [12]. The parameter is expressed in milliseconds.
4.6.2.9.5. Inter-Arrival Jitter
Inter-arrival jitter is calculated as defined in RFC 3550 and
converted into milliseconds.
4.6.2.9.6. Mean Absolute Jitter
It is recommended that MAJ be measured as defined in ITU-T G.1020
[9]. This parameter is often referred to as MAPDV (Mean Absolute
Packet Delay Variation). The parameter is expressed in milliseconds.
4.6.2.10. Signal-Related Parameters4.6.2.10.1. Signal Level
This field corresponds to "signal level" in RFC 3611 in the VoIP
Metrics Report Block. This field provides the voice signal relative
level is defined as the ratio of the signal level to a 0 dBm0
reference, expressed in decibels. This value can be used directly
without extra conversion.
4.6.2.10.2. Noise Level
This field corresponds to "noise level" in RFC 3611 in the VoIP
Metrics Report Block. This field provides the ratio of the silent
period background noise level to a 0 dBm0 reference, expressed in
decibels. This value can be used directly without extra conversion.
Pendleton, et al. Standards Track [Page 26]

RFC 6035 SIP Package for Voice Quality Reporting November 20104.6.2.10.3. Residual Echo Return Loss (RERL)
This field corresponds to "RERL" in RFC 3611 in the VoIP Metrics
Report Block. This field provides the ratio between the original
signal and the echo level in decibels, as measured after echo
cancellation or suppression has been applied. This value can be used
directly without extra conversion.
4.6.2.11. Quality Scores4.6.2.11.1. ListeningQualityR
This field reports the listening quality expressed as an R factor
(per G.107). This does not include the effects of echo or delay.
The range of R is 0-95 for narrowband calls and 0-120 for wideband
calls. Algorithms for computing this value SHOULD be compliant with
ITU-T Recommendations P.564 [10] and G.107 [11].
4.6.2.11.2. RLQEstAlg
This field provides a text name for the algorithm used to estimate
ListeningQualityR. This field will be free form text and not
necessarily reflective of any standards or recommendations.
4.6.2.11.3. ConversationalQualityR
This field corresponds to "R factor" in RFC 3611 in the VoIP Metrics
Report Block. This parameter provides a cumulative measurement of
voice quality from the start of the session to the reporting time.
The range of R is 0-95 for narrowband calls and 0-120 for wideband
calls. Algorithms for computing this value SHOULD be compliant with
ITU-T Recommendations P.564 and G.107. Within RFC 3611, a reported R
factor of 127 indicates that this parameter is unavailable; in this
case, the ConversationalQualityR parameter MUST be omitted from the
vq-rtcpxr event.
4.6.2.11.4. RCQEstAlg
This field provides a text name for the algorithm used to estimate
ConversationalQualityR. This field will be free form text and not
necessarily reflective of any standards or recommendations.
4.6.2.11.5. ExternalR-In
This field corresponds to "ext. R factor" in RFC 3611 in the VoIP
Metrics Report Block. This parameter reflects voice quality as
measured by the local endpoint for incoming connection on "other"
side (refer to RFC 3611 for a more-detailed explanation). The range
Pendleton, et al. Standards Track [Page 27]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
of R is 0-95 for narrowband calls and 0-120 for wideband calls.
Algorithms for computing this value SHOULD be compliant with ITU-T
Recommendations P.564 and G.107. Within RFC 3611, a reported R
factor of 127 indicates that this parameter is unavailable; in this
case, the ConversationalQualityR parameter MUST be omitted from the
vq-rtcpxr event.
4.6.2.11.6. ExtRInEstAlg
This field provides a text name for the algorithm used to estimate
ExternalR-In. This field will be free-form text and not necessarily
reflective of any standards or recommendations.
4.6.2.11.7. ExternalR-Out
This field corresponds to "ext. R factor" in RFC 3611 in the VoIP
Metrics Report Block. Here, the value is copied from RTCP XR message
received from the remote endpoint on the "other" side of this
endpoint; refer to RFC 3611 for a more detailed explanation). The
range of R is 0-95 for narrowband calls and 0-120 for wideband calls.
Algorithms for computing this value SHOULD be compliant with ITU-T
Recommendations P.564 and G.107. Within RFC 3611, a reported R
factor of 127 indicates that this parameter is unavailable; in this
case, the ConversationalQualityR parameter SHALL be omitted from the
vq-rtcpxr event.
4.6.2.11.8. ExtROutEstAlg
This field provides a text name for the algorithm used to estimate
ExternalR-Out. This field will be free-form text and not necessarily
reflective of any standards or recommendations.
4.6.2.11.9. MOS Reporting
Conversion of RFC 3611 reported mean opinion scores (MOSs) for use in
reporting MOS-LQ and MOS-CQ MUST be performed by dividing the RFC3611 reported value by 10 if this value is less than or equal to 50
or omitting the MOS-xQ parameter if the RFC 3611 reported value is
127 (which indicates unavailable).
4.6.2.11.9.1. MOS-LQ
This field corresponds to "MOSLQ" in RFC 3611 in the VoIP Metrics
Report Block. This parameter is the estimated mean opinion score for
listening voice quality on a scale from 1 to 5, in which 5 represents
"Excellent" and 1 represents "Unacceptable". Algorithms for
Pendleton, et al. Standards Track [Page 28]

RFC 6035 SIP Package for Voice Quality Reporting November 2010
computing this value SHOULD be compliant with ITU-T Recommendation
P.564 [10]. This field provides a text name for the algorithm used
to estimate MOS-LQ.
4.6.2.11.9.2. MOS-CQ
This field corresponds to "MOSCQ" in RFC 3611 in the VoIP Metrics
Report Block. This parameter is the estimated mean opinion score for
conversation voice quality on a scale from 1 to 5, in which 5
represents excellent and 1 represents unacceptable. Algorithms for
computing this value SHOULD be compliant with ITU-T Recommendation
P.564 with regard to the listening quality element of the computed
MOS score.
4.6.2.11.9.3. MOSCQEstAlg
This field provides a text name for the algorithm used to estimate
MOS-CQ. This field will be free-form text and not necessarily
reflective of any standards or recommendations.
4.6.2.11.10. QoEEstAlg
This field provides a text description of the algorithm used to
estimate all voice quality metrics. This parameter is provided as an
alternative to the separate estimation algorithms for use when the
same algorithm is used for all measurements. This field will be
free-form text and not necessarily reflective of any standards or
recommendations.
4.7. Message Flow and Syntax Examples
This section shows a number of message flow examples showing how the
event package works.
4.7.1. End of Session Report Using NOTIFYPendleton, et al. Standards Track [Page 29]