Internet Engineering Task Force R.Kumar
Internet Draft D.Auerbach
Document: draft-auerbach-mgcp-rtcpxr-02 C. Sivalchelvan
Category: Informational Cisco Systems
Expires: December 15, 2005 D. Hancock
CableLabs
B. Hare
Arris
June 15, 2005
RTCP XR VoIP Metrics Package for the Media Gateway Control Protocol
draft-auerbach-mgcp-rtcpxr-02
Status of this Memo
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 28, 2005.
Abstract
The main intent of this document is to define a Media Gateway Control
Protocol (MGCP) package to control the reporting of metrics supported
by the VoIP metrics block in RTCP Extended Reports as specified in [RFC
3611]. It also allows the call agent to control whether or not the
gateway will request a peer device via SDP to send the VoIP metrics
block in RTCP Extended Reports and whether it will respond positively
to such requests from the peer device. Besides this primary focus, this
package also allows the reporting of metrics defined for RTCP Sender
Reports and Receiver Reports [RFC 3550] and the reporting of session
description parameters (based on the ones defined in RFC 2327, RFC 2198
etc.).
MGCP RTCP-XR Package 6/14/2005
Conventions used in this document
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.
Table of Contents
1. Introduction
2. VoIP Metrics Package Definition
2.1 Local Connection Options
2.1.1 Responses to the xrm/mcr local connection option
2.1.1.1 Response to a value of "off"
2.1.1.2 Response to a value of "on"
2.1.1.3 Response to a value of "negotiate"
2.1.2 Impact of the xrm/mcr LCO on VoIP metrics block exchange
2.2 MGCP Protocol Procedures
2.2.1 DeleteConnection Procedures
2.2.2 AuditConnection Procedures
2.2.3 ModifyConnection Procedures
2.3 The LVM and RVM Lines for reporting Local And Remote Metrics
2.3.1 Rules for the inclusion of XRM/LVM and XRM/RVM parameters
2.3.2 XRM/LVM and XRM/RVM parameter values
2.3.3 Procedures for the resetting of metrics
2.3.4 Impact redundancy and FEC on packet loss computations
2.3.5 Parameter Extension Mechanism
2.3.6 Grammar for VoIP metrics parameters
2.3.7 Applicability of VoIP metrics to Voice Band Data
3. Call Flow Examples
3.1 Metrics Reporting during Call agent-initiated Delete Connection
3.2 Metrics Reporting during Gateway-initiated Delete Connection
3.3 Metrics Reporting during Audit Connection
3.4 Metrics Reporting during Modify Connection
4. Security Considerations
5. IANA Considerations
5.1 Package Registration
5.2 Extension Registration
6. Changes from earlier drafts
6.1 Changes from the -00 version to the -01 version
6.2 Changes from the -01 version to the -02 version
7. Normative References
8. Acknowledgments
9. Copyright Statement
1. Introduction
This document defines a Media Gateway Control Protocol (MGCP) [RFC
3435] package that enables the collection and reporting of metrics that
measure the quality of traffic on two-way VoIP connections. This
capability is based on and utilizes the VoIP Metrics Block of the RTCP
Extended Report as specified in [RFC 3611].
Kumar et al Informational Page 2
MGCP RTCP-XR Package 6/14/2005
In accordance with [RFC 3435], the term "gateway" is used to denote the
device controlled via MGCP. This is not intended to preclude the use of
MGCP or of this package to control devices that are not, in the
strictest terms, media gateways. For the purposes of this package, the
terms "gateway" and "endpoint" are used interchangeably.
In addition to the parameters in the RTCP XR VoIP metrics block, this
package allows the collection of statistics defined for RTCP Sender
Reports and Receiver Reports [RFC 3550]. The ConnectionParameters
structure [RFC 3435] allows the reporting of the local, but not the
remote, version of statistics defined for RTCP Sender Reports and
Receiver Reports [RFC 3550]. To report both the local and remote
versions of these RTP statistics, this package may be used. Note that
this package does not affect the collection or reporting of connection
parameters defined in the base MGCP specification (RFC 3435). Nor does
it affect the sending of RTCP Sender Reports (SR) and Receiver Reports
(RR).
This package also includes session description parameters (based on the
ones defined in RFC 2327, RFC 2198 etc.). These may be reported via
this package to obviate the need for call agents to snoop SDP session
descriptors.
This package makes a distinction between collecting, responding and
reporting. The term "collecting" refers to the process of calculating
and accumulating local metric data and accumulating remote metric data
received in RTCP Sender, Receiver and Extended Reports from the remote
device. The term "responding" in the context of this package is
limited to the sending of accumulated local metric data via RTCP
Extended Reports to the remote device as specified in [RFC 3611]. Note
that this package does not control the communication of session
statistics via RTCP Sender Reports (SR) and Receiver Reports (RR).
These reports MUST be sent in the manner required of all RTP endpoints
[RFC 3550]. The term "reporting" refers to the process of reporting the
accumulated local and remote metric data for the connection to the Call
Agent in either a DeleteConnection, ModifyConnection or AuditConnection
command sequence.
An endpoint will "collect" local session metrics for several reasons:
- To report metrics in the "northbound" direction via the XRM/LVM
and XRM/RVM parameters specified in this package.
- To communicate metrics in the "east-west" direction via RTCP
extended reports,
- To report metrics in the "northbound" direction via other
mechanisms such as connection parameters [RFC 3435] and log
transfers not addressed in this document,
- To communicate metrics in the "east-west" direction via RTCP
Sender Reports and Receiver Reports.
The sets of metrics collected for these purposes are not the same. This
package is limited to defining the metrics that may be reported via the
XRM/LVM and XRM/RVM lines. This may or may not be a superset of the
Kumar et al Informational Page 3
MGCP RTCP-XR Package 6/14/2005
metrics that may be communicated via the VoIP metrics block in RTCP
extended reports.
The Call Agent can ask an endpoint to enable or disable the reporting
of metrics via this package. Enabling this reporting also enables the
"east-west" communication of metrics via the RTCP XR VoIP metrics block
from the local endpoint's perspective. Whether this "east-west"
communication actually takes place also depends on the peer endpoint's
capabilities. When it disables "northbound" reporting via this package,
the call agent may either disable the "east-west" communication of
metrics via the RTCP XR VoIP metrics block, or it may require the
endpoint to communicate the VoIP metrics block in the "east-west"
direction if the remote end requests it. Disabling "northbound"
reporting via this package has no impact on the use of RTCP Sender
Reports or Receiver Reports.
The metric data reported to the Call Agent via this package when a
connection is deleted, modified or audited represents the data that was
accumulated since:
- the start of the session, or,
- the last metrics reset, whether autonomous or commanded by the
call agent. An autonomous reset occurs when the media changes its
mode e.g. from voice to voice band data. A commanded reset may
occur when the call agent modifies the connection in response to
feature invocations, such as call transfer or call pick-up.
The VoIP Metrics package definition is provided in Section 2. This
includes a detailed description of relevant MGCP protocol procedures, a
list of parameters that can be reported via this package, and an
analysis of the applicability of these parameters to voice band data.
In Section 3, we provide four call flow examples showing how to use
the package. Security considerations are found in Section 4, followed
by the IANA considerations and references. Table 1 lists the metrics
based on the VoIP metrics block in RTCP Extended Reports [RFC 3611].
Table 2 lists the metrics based on RTCP Sender Reports and Receiver
Reports [RFC 3550]. Note that Table 2 uses the metrics definitions in
[RFC 3550] and [RFC 3435] as is, without attempting to improve them by,
for instance, specifying a better method for handling duplicates. Table
3 lists session parameters, most of which are from RFCs which define
SDP constructs (e.g. RFC 2327, RFC 2198, RFC 2733).
2. VoIP Session Metrics Package Definition
A package is defined for VoIP session metrics. Here, the term "VoIP"
is used in a broad manner that includes voice band data.
Package Name: XRM
Package Version: 0
This package defines the following parameters:
- A new local connections option, "mcr" (Metrics Reporting) for
enabling and disabling metrics reporting via this package. Note
Kumar et al Informational Page 4
MGCP RTCP-XR Package 6/14/2005
that metrics collection might also be contingent upon other
factors not affected by this package (e.g. the connection
parameters in the base MGCP specification, RFC 3435).
- A new parameter line, "MMO" (Media Metrics Option) that allows
the call agent to request local and remote metrics in a modify
connection response, and/or to reset the local and remote
metrics.
- A new parameter line, "LVM" (Local VoIP Metrics), for reporting
locally collected metrics.
- A new parameter line, "RVM" (Remote VoIP Metrics), for reporting
remotely collected metrics communicated to the reporting endpoint
via RTCP Extended Reports, Sender Reports and Receiver Reports.
2.1 Local Connection Options
The local connection option (LCO) parameter, "xrm/mcr", is an optional
parameter with one of the following three values:
- "off": Disables the reporting of metrics via this package AND the
"east-west" communication of metrics via the RTCP XR VoIP metrics
block
- "on": Enables the reporting of metrics via this package AND the
"east-west" communication of metrics via the RTCP XR VoIP metrics
block. Whether this "east-west" communication actually takes
place also depends on the peer endpoint's capabilities.
- "negotiate": Disables the reporting of metrics via this package.
However, the endpoint is required to communicate the VoIP metrics
block in the "east-west" direction if the remote end requests it.
For example,
L: a:PCMU, xrm/mcr: on
assigns a value of "on" to the "mcr" LCO.
In CreateConnection commands, the xrm/mcr LCO value defaults to
"negotiate". In ModifyConnection commands, the xrm/mcr LCO value
defaults to its current value for the connection. Thus, if
LocalConnectionOptions are either omitted or the xrm/mcr LCO is not
included in a ModifyConnection command, the previous xrm/mcr LCO value
for the connection is retained.
An MGCP endpoint supporting this package SHALL always use SDP to
request the VoIP metrics block from the remote device if the value of
the "xrm/mcr" LCO is set to "on". However, even if the value of value
of the "xrm/mcr" LCO is "on" or "negotiate", the endpoint SHALL NOT
send the VoIP metrics block in RTCP Extended Reports (XR) unless the
remote device has requested this block via SDP signaling. Thus, for
MGCP endpoints supporting this package, the permission in [RFC 3611] to
send RTCP XR blocks in the absence of the "rtcp-xr" SDP attribute is
revoked.
Note that the value of the "xrm/mcr" LCO does not affect the collection
or reporting of connection parameters in the connection parameters line
Kumar et al Informational Page 5
MGCP RTCP-XR Package 6/14/2005
(P: line) as defined in the base MGCP specification [RFC 3435]. Nor
does it affect the sending of RTCP Sender Reports (SR) and Receiver
Reports (RR). An endpoint supporting this package MUST continue to
include the connection parameters (P:) line in an audit connection
response where this data is requested, in a delete connection response
and in a gateway-initiated delete connection. There can be overlap if
equivalent parameters are also reported via this package in procedures
for the deletion and audit of connections. There is no overlap in the
case of modify connection responses since these do not include the
connection parameters line.
2.1.1 Responses to the xrm/mcr local connection option
This section details the endpoint's response to each of the xrm/mcr LCO
values.
2.1.1.1 Response to a value of "off"
On receiving this value, the endpoint MUST erase any local or remote
VoIP metric data previously collected for the connection, and MUST
instruct the far-end device to stop sending RTCP XR VoIP Metrics Report
Blocks. The endpoint MUST ignore an SDP request for metrics and MUST
NOT transmit local metrics to the peer device. The local endpoint
MUST NOT report XR metrics upon receiving or initiating a
DeleteConnection sequence and MUST NOT report XR metrics when
responding to a ModifyConnection command or an AuditConnection
command.
2.1.1.2 Response to a value of "on"
On receiving this value in a CreateConnection or ModifyConnection
command, if not already doing so, the endpoint MUST:
- Start collecting/calculating the metrics which it will expose to
the Call Agent via this package.
- Instruct the far-end device to start sending the VoIP Metrics
block in RTCP Extended Reports by including an "rtcp-xr"
attribute with a value of "voip-metrics" in the SDP.
- Report local and remote metrics via the XRM/LVM and XRM/RVM lines
defined below in the response to DeleteConnection that targets a
single connection, in the response to a ModifyConnection when
these metrics are requested, in the response to an
AuditConnection when these metrics are audited, and when sending
a DeleteConnection command for a single connection.
2.1.1.3 Response to a value of "negotiate"
On receiving this value, the endpoint disables the "northbound"
reporting of metrics, via this package, to the call agent. Also, it
sets an internal flag to indicate that it will respond positively to
SDP requests by the remote peer device to send the VoIP metrics block
in RTCP Extended Reports.
Kumar et al Informational Page 6
MGCP RTCP-XR Package 6/14/2005
2.1.2 Impact of the xrm/mcr LCO on VoIP metrics block exchange
This section details the concepts introduced in the previous section
regarding the use of the xrm/mcr local connection option to govern the
endpoint's behavior regarding the negotiation, via SDP, of the VoIP
metrics block in RTCP extended reports [RFC 3611].
RFC 3611 adds a new SDP attribute called "rtcp-xr" that can be used by
an endpoint to ask the remote device to send RTCP Extended Reports.
This attribute is encoded as follows:
rtcp-xr:<xr-format>
This rtcp-xr attribute can be used as either a session-level or media-
level attribute. See [RFC 3611] for more information. Only one of the
xr-format values, voip-metrics, is within the scope of this package.
For an endpoint supporting this package, the inclusion of the voip-
metrics value in an rtcp-xr attribute line in its SDP local session
descriptions SHALL be per the following rules:
- The voip-metrics value SHALL be included if the xrm/mcr LCO is
set to "on".
- The voip-metrics value SHALL NOT be included if the xrm/mcr LCO
is set to "off" or "negotiate".
The inclusion or exclusion of any other xr-format values (denoting
other RTCP XR blocks) in the rtcp-xr SDP attribute line is independent
of the xrm/mcr LCO. This is not addressed by this package.
The response of an endpoint supporting this package to the receipt from
a remote peer of an SDP remote session description with an rtcp-xr
attribute line that has voip-metrics as one of its values (or its only
value) shall be as follows:
- The endpoint MUST send RTCP Extended Reports with the VoIP
metrics block to the remote peer if the xrm/mcr LCO is "on" or
"negotiate".
- The endpoint SHALL NOT send RTCP Extended Reports with the VoIP
metrics block to the remote peer if the xrm/mcr LCO is "off".
Regardless of the value of the xrm/mcr LCO, an endpoint supporting this
package SHALL NOT send RTCP Extended Reports with the VoIP metrics
block to the remote peer if any of the following is true:
- The rtcp-xr attribute is not included in the SDP remote session
description.
- The rtcp-xr attribute is included in the SDP remote session
description but "voip-metrics" is not one of its values. This
includes the case in which the attribute has an empty parameter
list.
[RFC 3611] allows endpoints that uses SDP (e.g. MGCP endpoints) to
exchange RTCP Extended Reports without prior SDP signaling, which is
Kumar et al Informational Page 7
MGCP RTCP-XR Package 6/14/2005
optional. This allowance is rescinded for endpoints supporting this
package which MUST implement the SDP signalling specified in this
section.
2.2 MGCP Protocol Procedures
2.2.1 DeleteConnection Procedures
These procedures refer to call agent-initiated delete connection
commands that are targeted at a specific connection ID and to gateway-
initiated delete connection commands. They do not apply to call agent-
initiated delete connection commands that are targeted at all
connections associated with a call, an endpoint, an endpoint group or a
gateway. In the latter case, the XRM/LVM and XRM/RVM lines (described
in detail below) SHALL NOT be returned.
Endpoints supporting this package MUST report local metrics in the
XRM/LVM parameter line in delete connection responses and in gateway-
initiated delete connection commands if and only if the local
connection option xrm/mcr is set to "on".
Endpoints supporting this package MUST report remote metrics, if
available, in the XRM/RVM parameter line in delete connection responses
and in gateway-initiated delete connection commands if and only if the
local connection option xrm/mcr is set to "on".
We do not define a mechanism for suppressing metrics reporting in
response to a delete connection command that is targeted at a specific
connection ID. In situations (such as a switchover)where the call agent
needs to delete connections without retaining any records of the
connections, it can use the version of the delete connection procedure
that targets all connections associated with a call, an endpoint, an
endpoint group or a gateway [RFC 3435]. No metrics are returned in
response to this version of the delete connection command.
2.2.2 AuditConnection Procedures
This package defines two new RequestedInfo values to be used with an
AuditConnection (AUCX). These allow a call agent to explicitly request
that the endpoint return the current values of either the local or
remote metrics. The request does not reset the values. When one or
both of these RequestedInfo values are included in an AUCX command, the
endpoint MUST return the appropriate metric values if available. The
two new RequestedInfo values are:
XRM/LVM Return the local voice metric values.
XRM/RVM Return the remote voice metric values.
The rules in the MGCP base specification [RFC 3435] for handling audits
of unsupported parameters and parameters for which an endpoint has no
values MUST be followed. As a result:
- If an endpoint that does not understand the XRM/LVM or XRM/RVM
parameter is audited for that parameter, it MUST NOT generate an
Kumar et al Informational Page 8
MGCP RTCP-XR Package 6/14/2005
error. Instead, the parameter MUST be omitted from the audit
response. Since this rule is based on the MGCP base
specification, it also applies to endpoints that do not support
this package.
- If an endpoint that does not have values for the XRM/LVM or
XRM/RVM parameter is audited for that parameter, it MUST NOT
generate an error. Instead, the parameter MUST be included in the
audit response with an empty value.
2.2.3 ModifyConnection Procedures
This package defines a new MGCP parameter, the MediaMetricsOption
("MMO") that may be optionally included in a ModifyConnection command
on an "XRM/MMO" line. This parameter is forbidden in all other MGCP
commands and responses. It can have one of the following four values:
- "REP" (report). This option commands the endpoint to report local
and remote metrics via this package. Local and remote session
parameters MAY also be reported.
- "RES" (reset). This option commands the endpoint to reset the
local and remote metrics.
- "RR" (report and reset). Local and remote metrics are first
reported and then reset. Local and remote session parameters MAY also
be reported.
- "NULL". No metrics (local or remote) are reset or reported. This
value is equivalent to omitting the "XRM/MMO" line in the
ModifyConnection command. Of course, it is more efficient and,
therefore, preferable to omit the XRM/MMO line than to use it with an
explicit value of "NULL".
Note that the XRM/MMO parameter is specific to a ModifyConnection
command and its value does not persist following the end of a
ModifyConnection procedure. Therefore, this package does not define a
RequestedInfo value for auditing the XRM/MMO parameter.
Also note that metrics are not reported in response to a "REP" or "RR"
value of the XRM/MMO parameter if the value of the XRM/MCR local
connection option is "off" or "negotiate".
When the value of the XRM/MMO parameter is REP or RR, then the
available metrics are reported, as applicable, in the XRM/LVM and
XRM/RVM lines defined below. In order to comply with the ABNF rules in
[RFC 3435], the connection parameters line (the P: line) SHALL NOT be
included in a ModifyConnection response. However, metrics equivalent to
the connection parameters (Table 2) can be included in the XRM/LVM and
XRM/RVM lines.
The metrics that are reset and/or reported in response to the XRM/MMO
parameter include metrics associated with RTCP extended reports (Table
1) and metrics associated with RTCP sender reports and receiver reports
(Table 2).
During reset, all metrics are either set to zero or to an unknown
value, with the exception of session parameters that continue to apply
Kumar et al Informational Page 9
MGCP RTCP-XR Package 6/14/2005
to the new configuration. Examples of metrics being set to an unknown
value at the various R factors and MOS estimates, which are set to 127.
An example of a session parameter which may remain unchanged is the IP
address of the endpoint.
The MMO parameter is needed to handle situations in which the call
agent invokes a feature that alters the media stream in a manner that
renders previous metrics values inapplicable to the new situation.
Examples are call transfer and call pick-up.
2.3 The LVM and RVM Lines for reporting Local And Remote Metrics
The "XRM/LVM" and "XRM/RVM" lines are for the reporting of local and
remote metrics respectively. For example, an endpoint that is recording
local metrics and has received remote metrics returns the following
lines in a DLCX response:
XRM/LVM: PLC=1, JBA=2, JBR=7 ...
XRM/RVM: PLC=0, JBA=0, JBR=3 ...
The parameters that may be reported in an XRM/LVM or XRM/RVM line fall
into the following categories:
- Parameters based on the VoIP metrics block [RFC 3611]. These are
listed in Table 1.
- Parameters based on Sender Reports and Receiver Reports [RFC
3550]. These are listed in Table 2.
- Parameters that describe the session. These are listed in Table
3. Many of these are based on SDP parameters such as those
specified in RFC 2327, RFC 2198, RFC 2733 etc.
Although Tables 1-3 include top-level definitions of these parameters,
some of their technical details may need to gleaned from the
references. For instance, the meaning of "standard" vs. "enhanced"
packet loss concealment must be obtained from [RFC 3611].
Note that the rationale for allowing the reporting of parameters based
on RTCP Sender Reports and Receiver Reports (Table 2) in the XRM/LVM
and XRM/RVM lines is two-fold:
- The connection parameters line (the P: line) in the MGCP base
protocol [RFC 3435] does not address remote metrics,
- The ABNF for packet loss in RFC 3435 is inconsistent with its RFC
3550-based textual definition of packet loss.
Note that the latency metric in the connection parameters line (the P:
line) is not included in Table 2 since it is already included in the
RTCP XR VoIP metrics block as the round trip delay. RTCP XR [RFC 3611]
allows any method for its computation, including methods based on [RFC
3550] or on the DLRR report block in [RFC 3611].
Kumar et al Informational Page 10
MGCP RTCP-XR Package 6/14/2005
2.3.1 Rules for the inclusion of XRM/LVM and XRM/RVM parameters
In general, inclusion of a parameter from Tables 1-3 in the XRM/LVM or
XRM/RVM lines is subject to:
- The availability of the parameter.
- Local policy regarding its inclusion.
The following rules apply only to endpoints supporting this package:
DLCX/MDCX/AUCX rule for XRM/LVM: This rule applies to: (i) Endpoint
responses to call agent-initiated delete connection commands that are
targeted at a specific connection ID, (ii) Endpoint-initiated delete
connection commands, (iii) Endpoint responses to modify connection
commands that request session metrics via the XRM/MMO line, (iv)
Endpoint responses to audit connection commands that include "XRM/LVM"
in the RequestedInfo list. In each of these contexts, the XRM/LVM line
MUST be included by an endpoint supporting this package. Further, this
endpoint MUST compute at least one metric from the VoIP metrics block
(Table 1) and report it in the XRM/LVM line. All other parameters
(Tables 2 and 3) are completely optional. Their inclusion depends on
local policy. The endpoint MUST omit all parameters that are not
computed locally rather than include them with dummy values (e.g. 127
for the various MOS parameters).
DLCX/MDCX rule for XRM/RVM: This rule applies to: (i) Endpoint
responses to call agent-initiated delete connection commands that are
targeted at a specific connection ID, (ii) Endpoint-initiated delete
connection commands, (iii) Endpoint responses to modify connection
commands that request session metrics via the XRM/MMO line. In each of
these contexts, the XRM/RVM line MUST be included if the remote peer
sends VoIP metrics blocks [RFC 3611] in RTCP Extended Reports. If the
remote device indicates that a particular VoIP metrics block parameter
is unavailable by sending a dummy value, then the dummy value MUST be
reported or the parameter MUST be omitted from the XRM/RVM: line. For
example, the dummy value of 127, if used, indicates that the signal
level, noise level, residual echo return loss, the various R factors
and MOS estimates are unavailable. If the VoIP metrics block is not
received from the remote device, the endpoint MAY omit the XRM/RVM line
even if it has non-VoIP metrics block parameters to report in the
XRM/RVM line, such as metrics communicated via RTCP Sender Reports (SR)
and Receiver Reports (RR). The endpoint MAY, of course, include the
XRM/RVM line with known non-VoIP metrics block parameters (Tables 2 and
3) when the VoIP metrics block is not communicated by the remote end.
If the remote device indicates that a particular Sender/Receiver Report
parameter is unavailable by assigning it a dummy value (such as an
inter-arrival jitter of 0), the endpoint MAY either omit it in the
XRM/RVM line or assign it a dummy value.
AUCX rule for XRM/RVM: This rule applies to endpoint responses to audit
connection commands that include "XRM/RVM" in the RequestedInfo list.
In this context, the XRM/RVM line MUST be included even if no VoIP
metrics blocks are received in RTCP extended reports from the remote
device. This line MAY, however, be empty if no data pertaining to RTCP
Kumar et al Informational Page 11
MGCP RTCP-XR Package 6/14/2005
XR VoIP metrics block (Table 1) is provided by the remote device.
Alternately, the local endpoint MAY include other known remote
parameters (Tables 2 and 3) in the XRM/RVM line. If the remote device
sends the VoIP metrics block in RTCP Extended Reports and indicates
that a particular parameter is unavailable by sending a dummy value,
then the dummy value MUST be reported or the parameter MUST be omitted
from the XRM/RVM: line. If the remote device indicates that a
particular Sender/Receiver Report parameter is unavailable by assigning
it a dummy value (such as an inter-arrival jitter of 0), the endpoint
MAY either omit it in the XRM/RVM line or assign it a dummy value.
Rule for disallowed values: An endpoint receiving a disallowed value in
the VoIP metrics block MAY omit it in the XRM/RVM line. For example,
RFC 3611 does not allow a value of 60 in the 8-bit MOS-LQ field in the
VoIP metrics block.
2.3.2 XRM/LVM and XRM/RVM parameter values
Note that the metrics formats used by the call agent to store and
report metrics might be different from the formats used in this
package. For instance, the media gateway controller can convert the
binary representation [RFC 3611] of network packet loss into a fixed-
point percentage. Thus, an NLR value of 20 (Table 1) might be stored or
displayed as 7.81%.
The procedures for communicating voice quality metrics in the XRM/LVM
and XRM/RVM lines are invoked at the end of a call or at the end of a
call phase (such as when a call transfer is invoked). Therefore, the
metrics used in these lines are, except when otherwise noted, averages
from the start of metrics computation. The term "start of metrics
computation" in Tables 1-3 SHALL be understood to mean:
- The start of the session if no metrics reset occurs.
- The last metrics reset, if there are any metrics resets. These
include resets commanded by the call agent or performed autonomously by
the endpoint.
It is recommended that the unstable or indeterminate periods at the
start and end of a call be factored out of metrics computation. The
duration of these guard bands is left to the implementation.
Kumar et al Informational Page 12
MGCP RTCP-XR Package 6/14/2005
TABLE 1: PARAMETERS BASED ON THE RTCP XR VOIP METRICS BLOCK
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Network | NLR |The proportion of packets lost |
|packet loss | |since the start of metrics |
|rate | |computation expressed as an 8-bit |
| | |binary fraction obtained by |
| | |dividing the number of packets lost|
| | |in the transmission path by the |
| | |total number of packets expected by|
| | |the receiver, multiplying this |
| | |value by 256 and taking the integer|
| | |portion of the result. Computed |
| | |after taking any loss mitigation |
| | |due to FEC and/or redundancy into |
| | |account. |
---------------------------------------------------------
|Jitter |JDR |The proportion of the packets |
|buffer | |discarded by the receiving |
|discard | |jitter buffer since the start of |
|rate | |metrics computation expressed as an|
| | |8-bit binary fraction obtained by |
| | |dividing the number of packets |
| | |discarded by the jitter buffer |
| | |by the total number of packets |
| | |expected by the receiver, |
| | |multiplying this value by 256 |
| | |and taking the integer portion |
| | |of the result. Computed |
| | |after taking any loss mitigation |
| | |due to FEC and/or redundancy into |
| | |account. |
---------------------------------------------------------
Kumar et al Informational Page 13
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Burst loss | BLD |The average proportion (since the |
|density | |start of metrics computation) of |
| | |lost and discarded packets |
| | |occurring during burst periods |
| | |expressed as an 8 bit |
| | |binary fraction obtained by |
| | |dividing the sum of the number of |
| | |packets detected as lost during |
| | |burst periods and the number of |
| | |packets discarded by the jitter |
| | |buffer during burst periods by |
| | |the total number of packets |
| | |expected by the receiver, |
| | |multiplying this value by 256 |
| | |and taking the integer portion |
| | |of the result. Computed |
| | |after taking any loss mitigation |
| | |due to FEC and/or redundancy into |
| | |account. |
---------------------------------------------------------
|Gap loss | GLD |The average proportion (since the |
|density | |start of metrics computation) of |
| | |lost and discarded packets |
| | |occurring during gap periods |
| | |expressed as an 8 bit binary |
| | |fraction obtained by |
| | |dividing the sum of the number of |
| | |packets detected as lost during |
| | |gap periods and the number of |
| | |packets discarded by the jitter |
| | |buffer during gap periods by |
| | |the total number of packets |
| | |expected by the receiver, |
| | |multiplying this value by 256 |
| | |and taking the integer portion |
| | |of the result. Computed |
| | |after taking any loss mitigation |
| | |due to FEC and/or redundancy into |
| | |account. |
---------------------------------------------------------
|Burst |BD |The average duration of the burst |
|duration | |periods, in milliseconds. Computed |
| | |from the start of metrics |
| | |computation. Bursts are determined |
| | |after taking any loss mitigation |
| | |due to FEC and/or redundancy into |
| | |account. |
---------------------------------------------------------
Kumar et al Informational Page 14
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Gap |GD |The average duration of the gap |
|duration | |periods, in milliseconds. Computed |
| | |from the start of metrics |
| | |computation. Bursts are determined |
| | |after taking any loss mitigation |
| | |due to FEC and/or redundancy into |
| | |account. |
---------------------------------------------------------
|Round trip |RTD |The round trip delay, in |
|network | |milliseconds, between the RTP |
|delay | |interfaces of the local and |
| | |remote call endpoints. Valid |
| | |values MUST be greater than or |
| | |equal to 0 milliseconds. This |
| | |could be computed on the basis of |
| | |RFC 3550, or the DLRR report |
| | |block in [RFC 3611] or any other |
| | |valid method. The average of all |
| | |measurements since the start |
| | |metrics computation SHOULD be used.|
---------------------------------------------------------
|End system |ESD |The end system (endpoint) delay, in|
|delay | |milliseconds, comprising the |
| | |encode, decode and jitter buffer |
| | |delay. Valid values MUST be |
| | |greater than or equal to 0 |
| | |milliseconds. The average of all |
| | |measurements since the start |
| | |metrics computation SHOULD be used.|
---------------------------------------------------------
Kumar et al Informational Page 15
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Signal |SL |The ratio of the average signal |
|level | |level to a 0 dBm0 reference, |
| | |expressed in dB. This is |
| | |expressed as an integer with an |
| | |optional negative ("-") sign. |
| | |When the sign is omitted, a |
| | |positive value is assumed. |
| | |Typical values should generally |
| | |be between -15 and -20. This value |
| | |is averaged over an interval e.g. |
| | |the RTCP transmission interval. |
| | |This metric shall be averaged |
| | |from the start of metrics |
| | |computation |
---------------------------------------------------------
|Noise |NL |The ratio of the silent period |
|level | |average background noise level to |
| | |a 0 dBm0 reference, in dB. This |
| | |is expressed as an integer with |
| | |an optional negative sign. Apart |
| | |from the value of 127 (parameter |
| | |unavailable), a hidden negative |
| | |sign SHALL be assumed for all other|
| | |positive values. Thus, NL=20 and |
| | |NL=-20 SHALL both imply a noise |
| | |level of 20 dB below the 0 dBm0 |
| | |reference. Omitting the "-" sign |
| | |is strongly discouraged. This value|
| | |is averaged over an interval e.g. |
| | |the RTCP transmission interval. |
| | |The metric shall be averaged from |
| | |the start of metrics computation. |
---------------------------------------------------------
|Residual |RERL |The echo return loss after the |
|echo return | |effects of echo cancellation, in |
|loss | |dB. This value is expressed as |
| | |an integer with an optional |
| | |negative sign. Apart from the value|
| | |of 127 (parameter unavailable), a |
| | |hidden negative sign SHALL be |
| | |assumed for all other positive |
| | |values. Thus, RERL=23 and RERL=-23 |
| | |SHALL both imply 23 dB below the |
| | |0 dBm0 reference. Omitting the "-" |
| | |sign is strongly discouraged. This |
| | |metric shall be averaged from the |
| | |start of metrics computation. |
---------------------------------------------------------
Kumar et al Informational Page 16
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Minimum gap |GMN | The gap/burst transition |
|threshold | | threshold; the recommended value |
| | | is 16. Values in the range 1 ы |
| | | 255 are permitted. |
---------------------------------------------------------
|R factor |RCQ | A value representing the |
|(Conver- | | conversational quality of |
|-sational | | the RTP session; |
|quality) | | calculated as per ITU-T |
| | | Recommendation G.107. Valid |
| | | values are greater than 0 and |
| | | less than or equal to 120. This |
| | | parameter is computed from the |
| | | start of metrics computation. |
---------------------------------------------------------
|R factor |RLQ | A value representing the |
|(Listening | | listening quality of |
|quality) | | the RTP session; |
| | | calculated as per ITU-T |
| | | Recommendation G.107. Valid |
| | | values are greater than 0 and |
| | | less than or equal to 120. This |
| | | parameter is computed from the |
| | | start of metrics computation. |
---------------------------------------------------------
|External |XRCQ | A value representing the effects |
|R factor | | of any call segment carried over |
| | | a network segment external to |
| | | the one on which the endpoint |
| | | resides; calculated as per ITU-T |
| | | Recommendation G.107. Valid |
| | | values are greater than 0 and |
| | | less than or equal to 120. This |
| | | parameter is computed from the |
| | | start of metrics computation. |
---------------------------------------------------------
|Estimated |MLQ | An estimated receiving end |
|MOS-LQ | | Listening Quality MOS. The |
| | | nominal range of MOS scores is |
| | | 1-5. Before being expressed in |
| | | MGCP, the MOS score is |
| | | multiplied by 10 and any |
| | | fractional part is truncated. |
| | | This results in an integer with |
| | | valid values in the range 10 - 50.|
| | | This parameter is computed from |
| | | the start of metrics computation. |
---------------------------------------------------------
Kumar et al Informational Page 17
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Estimated |MCQ | An estimated receiving end |
|MOS-CQ | | Conversational Quality MOS. The |
| | | nominal range of MOS scores is |
| | | 1-5. Before being expressed in |
| | | MGCP, the MOS score is |
| | | multiplied by 10 and any |
| | | fractional part is truncated. |
| | | This results in an integer with |
| | | valid values in the range 10 - 50.|
| | | This parameter is averaged from |
| | | the start of metrics computation. |
---------------------------------------------------------
|Packet loss |PLC | The type of packet loss |
|concealment | | concealment algorithm in use; |
|type | | should be one of the following |
| | | enumeration values: |
| | | 0 - Unspecified |
| | | 1 - Disabled |
| | | 2 - Enhanced |
| | | 3 - Standard |
---------------------------------------------------------
|Jitter |JBA | The adaptability of the jitter |
|Buffer | | buffer. Should be one of the |
|Adaptability| | following enumeration values: |
| | | 0 - Unknown |
| | | 1 - Reserved |
| | | 2 - Non-adaptive |
| | | 3 - Adaptive |
---------------------------------------------------------
|Jitter |JBR | The jitter buffer adjustment |
|Buffer | | rate. Value is between 0 and |
|Rate | | 15. |
---------------------------------------------------------
|Jitter |JBF | Count of jitter buffer overflow |
|Buffer | | and underflow events since the |
|Anomalous | | start of metrics computation. |
|Events | | |
---------------------------------------------------------
|Nominal |JBN | Current nominal delay in |
|jitter | | milliseconds that corresponds to |
|buffer | | the nominal jitter buffer delay |
|delay | | for packets that arrive exactly |
| | | on time. The last computed value |
| | | is used. |
---------------------------------------------------------
Kumar et al Informational Page 18
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Maximum |JBM | Current maximum delay in |
|jitter | | milliseconds that corresponds to |
|buffer | | the earliest arriving packet |
|delay | | that would not be discarded. In |
| | | simple queue implementations, |
| | | this may correspond to the |
| | | nominal jitter buffer delay. In |
| | | adaptive jitter buffer |
| | | implementations, this value may |
| | | dynamically vary up to the |
| | | absolute maximum jitter buffer |
| | | delay (see below). The last |
| | | computed value is used. |
---------------------------------------------------------
|Absolute |JBS | Absolute maximum delay in |
|maximum | | milliseconds that an adaptive |
|jitter | | jitter buffer can reach under |
|buffer | | worst case conditions. This is |
|delay | | a configured parameter. For fixed |
| | | jitter buffers, this must be set |
| | | to the maximum jitter buffer |
| | | delay. |
---------------------------------------------------------
|MOS-LQ |MLES | Algorithm used to estimate the |
|Estimation | | the MOS-LQ metric, MLQ. This |
|Algorithm | | is expressed as a human-readable |
| | | character string with an |
| | | unrestricted set of values. |
---------------------------------------------------------
|MOS-CQ |MCES | Algorithm used to estimate the |
|Estimation | | the MOS-CQ metric, MCQ. This |
|Algorithm | | is expressed as a human-readable |
| | | character string with an |
| | | unrestricted set of values. |
---------------------------------------------------------
|R-factor |RFES | Algorithm(s) used to estimate the |
|Estimation | | the one or more R-factors |
|Algorithm(s)| | reported. This is expressed as a |
| | | human-readable character string |
| | | with an unrestricted set of |
| | | values. This string may contain |
| | | separate descriptions for the RCQ,|
| | | RLQ and XRCQ algorithms. |
---------------------------------------------------------
Kumar et al Informational Page 19
MGCP RTCP-XR Package 6/14/2005
Unavailable parameters are simply omitted in the XRM/LVM line. In the
XRM/RVM line, the following parameters from Table 1 can be assigned a
value of 127 indicating that the parameter is not available (equivalent
to omitting it):
- R factor,
- External R factor,
- Estimated MOS-LQ,
- Estimated MOS-CQ.
TABLE 2: PARAMETERS BASED ON RTCP SENDER AND RECEIVER REPORTS
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Packets sent |PS | The number of packets that were |
| | | were sent on the connection since|
| | | the start of metrics computation.|
| | | Does not include any FEC packets |
| | | sent on a different SSRC or port.|
---------------------------------------------------------
|Octets sent |OS | The number of payload octets that|
| | | were sent out on the connection |
| | | since the start of metrics |
| | | computation. Header and padding |
| | | octets are not included. Nor are |
| | | octets in redundant or FEC |
| | | payloads/packets. |
---------------------------------------------------------
|Packets |PR | The number of packets that were |
|received | | were received on the connection |
| | | since the start of metrics |
| | | computation. Does not include any|
| | | FEC packets received on a |
| | | different SSRC or port. |
---------------------------------------------------------
|Octets |OR | The number of payload octets that|
|received | | were received on the |
| | | connection since the start of |
| | | metrics computation. Header and |
| | | padding octets are not included. |
| | | Nor are octets in redundant or |
| | | FEC payloads/packets. |
---------------------------------------------------------
Kumar et al Informational Page 20
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Packets |PL | The total number of media packets|
|lost | | that have been lost since the |
| | | beginning of metrics computation.|
| | | This is defined to be the number |
| | | of packets expected less the |
| | | number of packets actually |
| | | received, where the number of |
| | | packets received includes any |
| | | which are late or duplicates. |
| | | Thus packets that arrive late are|
| | | not counted as lost, and the loss|
| | | may be negative if there are |
| | | duplicates. This metric does not |
| | | take any loss mitigation due to |
| | | redundancy or FEC into account. |
---------------------------------------------------------
|Inter- |IAJ | Per [RFC 3550], the inter-arrival|
|arrival | | jitter is defined to be |
|jitter | | the mean deviation (smoothed |
| | | absolute value) of the difference|
| | | in packet spacing at the |
| | | the receiver compared to the |
| | | sender for a pair of packets. |
| | | This metric is averaged from the |
| | | start of computation and is |
| | | expressed in milliseconds. |
| | | The corresponding connection |
| | | parameter in [RFC 3435] is JI. |
---------------------------------------------------------
Kumar et al Informational Page 21
MGCP RTCP-XR Package 6/14/2005
TABLE 3: SESSION DESCRIPTION PARAMETERS
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|SSRC |SSRC | SSRC of the measured stream. |
| | | If it changes due to a collision,|
| | | the last value is used. |
| | | Represented as the decimal |
| | | equivalent of a 32-bit word. |
---------------------------------------------------------
|Source IP |IPAS | The source IP address for |
|address | | the stream under measurement |
---------------------------------------------------------
|Source IP |IPTS | This indicates whether the source|
|address type | | IP address is IP version 4 or 6. |
---------------------------------------------------------
|Destination |IPAD | The destination IP address for |
|IP address | | the stream under measurement. |
---------------------------------------------------------
|Destination |IPTD | This indicates whether the |
|IP address | | destination IP address is |
|type | | IP version 4 or 6. |
---------------------------------------------------------
|Source |RTUS | The source RTP/UDPTL port for |
|RTP/UDPTL | | the stream under measurement. |
|port | | |
---------------------------------------------------------
|Destination |RTUD | The destination RTP/UDPTL port |
|RTP/UDPTL | | for the stream under measurement|
|port | | |
---------------------------------------------------------
|Source |RTCS | The source RTCP port for |
|RTCP port | | the stream under measurement. |
---------------------------------------------------------
|Destination |RTCD | The destination RTCP port for |
|RTCP port | | the stream under measurement. |
---------------------------------------------------------
|Codec |VCD | The last voice or voice band data|
|(voice or | | codec used. This is expressed |
|voice band | | as a character string |
|data) | | corresponding to a MIME subtype |
| | | from [IANA RTP] (e.g. " G726-40")|
| | | or as an experimental codec name |
| | | starting with "X-". |
---------------------------------------------------------
|Secondary |VCDS | In the case of RFC 2198 |
|codec | | redundancy, the secondary codec |
|(voice or | | used. Semantics identical to |
|voice band | | primary codec. (See VCD parameter|
|data) | | above.) |
---------------------------------------------------------
Kumar et al Informational Page 22
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Media |MMOD | This indicates whether the |
|Mode | | the media carried by the session |
| | | is audio ("a"), voice band data |
| | | ("v"), fax relay ("f"), modem |
| | | relay ("m") or text relay ("t"). |
| | | The last mode is indicated by |
| | | this parameter. Audio and text |
| | | relay packets may be interleaved |
| | | in the text relay mode. |
| | | Voice band data, fax relay, modem|
| | | relay and text relay are defined |
| | | in [ITU V.152], [ITU T.38], |
| | | [ITU V.150.1] and [ITU V.151] |
| | | respectively. All of these media,|
| | | with the exception of modem |
| | | relay, can be transported via |
| | | RTP. |
---------------------------------------------------------
|Sample rate |SMPL | The rate at which media is |
|(voice or | | is sampled (samples per second) |
|voice band | | for the last voice or voice band |
|data) | | data codec used. |
---------------------------------------------------------
|Codec frame |FRSZ | The number of octets in a codec |
|size | | frame for the last voice or |
|(voice or | | voice band data codec. |
|voice band | | |
|data) | | |
---------------------------------------------------------
|RTP payload |PLSZ | The number of octets in a the RTP|
|size | | packet payload for the |
|(voice or | | last voice or voice band data |
|voice band | | codec used. |
|data) | | |
---------------------------------------------------------
|Packetization|PKRT | The number of RTP packets per |
|rate | | second for the last voice or |
|(voice or | | voice band data codec used. |
|voice band | | |
|data) | | |
---------------------------------------------------------
Kumar et al Informational Page 23
MGCP RTCP-XR Package 6/14/2005
---------------------------------------------------------
| Parameter | Code | Value |
| | | |
---------------------------------------------------------
|Silence |SSUP | This indicates whether silence |
|Suppression | | suppression, also known as Voice |
|State | | Activity Detection (VAD)is |
| | | enabled. The last value is used. |
| | | It is assumed that silence |
| | | suppression is accompanied by |
| | | comfort noise generation. |
---------------------------------------------------------
|Echo |ECAN | This indicates whether echo |
|Cancellation | | cancellation is enabled. The last|
|State | | value is used. |
---------------------------------------------------------
|Redundancy |VRED | This indicates whether |
|State | | redundancy [RFC 2198] was used |
|(voice or | | for the last voice or voice band |
|voice band | | data codec. |
|data). | | |
---------------------------------------------------------
|FEC State |VFEC | This indicates whether |
|(voice or | | Forward Error Correction |
|voice band | | [RFC 2733] was used for the last |
|data). | | voice or voice band data codec. |
| | | RFC 2733 FEC may be used in |
| | | conjunction with RFC 2198 |
| | | redundancy. |
---------------------------------------------------------
2.3.3 Procedures for the resetting of metrics
In addition to responding to relevant XRM/MMO values, endpoints
supporting this package reset VQ metrics on media transitions such as a
transition from voice to voice band data. An event to report an
autonomous reset to the call agent with the set of metrics values prior
to the reset was considered unnecessary. This is because the
significant epoch of a call is generally following, not preceding,
media mode shifts such as a voice to voice band data transition. In
such cases, the preceding epochs are transient in nature and are not
associated with the transfer of the actual data.
Also, as a rule an SSRC change SHOULD NOT reset VQ metrics. This is
consistent with the base MGCP protocol [RFC 3435]. SSRC can occur due
to rare collision events [RFC 3550].
The values assigned on reset to metrics and to related parameters are
described in the earlier section on ModifyConnection Procedures.
2.3.4 Impact redundancy and FEC on packet loss computations
The packet loss and discard parameters based on the RTCP XR VoIP
metrics block [RFC 3611] are computed after taking redundancy and FEC
Kumar et al Informational Page 24
MGCP RTCP-XR Package 6/14/2005
into account. Thus, the following parameters from Table 1 SHALL be
computed after taking the effect of redundancy (e.g. RFC 2198) and/or
FEC (e.g. RFC 2733) into account:
- Network packet loss rate, NLR
- Jitter buffer discard rate, JDR
- Burst loss density, BLD, and burst duration, BD
- Gap loss density, GLD, and gap duration, GD
By contrast, the packet receipt and packet loss parameters based on
RTCP Sender Reports (SR) and Receiver Reports (RR) do not take
redundancy or FEC into account. They are meant to be indicative of
impairments "on the wire" than in end-to-end service. Thus, the packets
lost (PL) parameter in Table 2 does not take into account any loss
mitigation due to redundancy (e.g. RFC 2198) or FEC (e.g. RFC 2733)
into account.
2.3.5 Parameter Extension Mechanism
The XRM/LVM and XRM/RVM lines MAY include vendor extension parameters
that begin with an "X-". An MGCP entity that receives an extension
parameter in these lines MUST ignore it if it cannot understand it.
Since these parameters introduce an unmanaged name space, there is a
potential for name clashing. Vendors are consequently encouraged to
include some vendor specific string, e.g. vendor name or stock ticker
symbol, in their vendor extensions. For example, if Acme Widgets, a
fictional company, wishes to use metric "ABC", it is preferable to use
the name "X-acmewidgets-ABC" rather than "X-ABC".
Vendors may register new metrics in an IANA registry of MGCP names of
VoIP metrics. The "X-" prefix is not germane to a metric following
registration.
2.3.6 Grammar for VoIP metrics parameters
The following describes the ABNF encoding [RFC 2234] for the parameters
defined in this package. Per MGCP conventions, all parameters defined
in this package are case-insensitive.
The standard tokens SP, WSP, ALPHA, DIGIT, HEXDIG etc. are per RFC
2234.
MediaMetricsOption = "XRM/MMO:" *WSP ("REP"/"RES"/"RR")
RemoteVoIPMetrics = "XRM/LVM:" *WSP [VoIPMetric *("," *WSP
VoIPMetric)]
; zero or more local metrics
; zero metrics are permitted in AUCX responses
RemoteVoIPMetrics = "XRM/RVM:" *WSP [VoIPMetric *("," *WSP
VoIPMetric)]
; zero or more remote metrics
Kumar et al Informational Page 25
MGCP RTCP-XR Package 6/14/2005
VoIPMetric = NetworkPacketLossRate
/ JitterBufferDiscardRate
/ BurstLossDensity
/ GapLossDensity
/ BurstDuration
/ GapDuration
/ RoundTripNetworkDelay
/ EndSystemDelay
/ SignalLevel
/ NoiseLevel
/ ResidualEchoReturnLoss
/ MinimumGapThreshold
/ RFactor-CQ
/ RFactor-LQ
/ ExternalRFactor
/ EstimatedMOS-LQ
/ EstimatedMOS-CQ
/ PacketLossConcealmentType
/ JitterBufferAdaptability
/ JitterBufferRate
/ JitterBufferNominal
/ JitterBufferMax
/ JitterBufferAbsMax
/ MOSLQEstimationAlgorithm
/ MOSLQEstimationAlgorithm
/ RfacorEstimationAlgorithms
/ InterArrivalJitter
/ PacketsSent
/ OctetsSent
/ PacketsReceived
/ OctetsReceived
/ PacketsLost
/ SSRC
/ SourceIPAddress
/ SourceIPAddressType
/ DestinationIPAddress
/ DestinationIPAddressType
/ SourceRTPPort
/ DestinationRTPPort
/ SourceRTCPPort
/ DestinationRTCPPort
/ VoiceOrVBDprimaryCodec
/ VoiceOrVBDsecondaryCodec
/ MaxCharacterRate
/ MediaMode
/ SampleRate
/ CodecFrameSize
/ RTPpayloadSize
/ PacketizationRate
/ SilenceSuppression
/ EchoCancellation
/ RFC2198RedundancyForVoiceOrVBD
/ RFC2733FECforVoiceOrVBD
/ UnregisteredExtension
Kumar et al Informational Page 26
MGCP RTCP-XR Package 6/14/2005
/ RegisteredExtension
NetworkPacketLossRate = "NLR=" 1*3(DIGIT) ;0-255
JitterBufferDiscardRate = "JDR=" 1*3(DIGIT) ;0-255
BurstLossDensity = "BLD=" 1*3(DIGIT) ; 0-255
GapLossDensity = "GLD=" 1*3(DIGIT) ; 0-255
BurstDuration = "BD=" 1*5(DIGIT) ; 0-65535
GapDuration = "GD=" 1*5(DIGIT) ; 0-65535
MinimumGapThreshold = "GMN=" 1*3(DIGIT) ; 1-255
RoundTripNetworkDelay = "RTD=" 1*4(DIGIT) ;
EndSystemDelay = "ESD=" 1*4(DIGIT) ;
SignalLevel = "SL=" ["-"] 1*3(DIGIT) ;-128 to 127
NoiseLevel = "NL=" ["-"] 1*3(DIGIT) ;-128 to 127
ResidualEchoReturnLoss = "RERL=" ["-"] 1*3(DIGIT)
;0-127
RFactor-CQ = "RCQ=" 1*3(DIGIT)
;0-120, or 127
RFactor-LQ = "RLQ=" 1*3(DIGIT)
;0-120, or 127
ExternalRFactor = "XRF=" 1*3(DIGIT) ;0-120, or 127
EstimatedMOS-LQ = "MLQ=" 1*3(DIGIT) ; 10-50, or 127
EstimatedMOS-CQ = "MCQ=" 1*3(DIGIT) ; 10-50, or 127
PacketLossConcealmentType= "PLC=" ("0" / "1" / "2" / "3")
JitterBufferAdaptability = "JBA=" ("0" / "1" / "2" / "3")
JitterBufferRate = "JBR=" 1*2(DIGIT) ;0-15
JitterBufferNominal = "JBN=" 1*5(DIGIT) ;0-65535
JitterBufferMax = "JBM=" 1*5(DIGIT) ;0-65535
JitterBufferAbsMax = "JBS=" 1*5(DIGIT) ;0-65535
MOSLQEstimationAlgorithm = "MLES=" ALPHA 1*127 (permittedchar)
;first character must be alphabetic
MOSCQEstimationAlgorithm = "MES=" ALPHA 1*127 (permittedchar)
Kumar et al Informational Page 27
MGCP RTCP-XR Package 6/14/2005
;first character must be alphabetic
RfactorAlgorithms = "RFES=" ALPHA 1*127 (permittedchar)
;first character must be alphabetic
InterArrivalJitter = "IAJ=" 1*3(DIGIT) ;
PacketsSent = "PS=" 1*9(DIGIT);
OctetsSent = "OS=" 1*9(DIGIT);
PacketsReceived = "PR=" 1*9(DIGIT);
OctetsReceived = "OR=" 1*9(DIGIT);
PacketsLost = "PL=" ["-"] 1*9(DIGIT);
SSRC = "SSRC=" 1*10 (DIGIT); 0-4,294,967,296
SourceIPAddressType = "IPTS=" ("IvP4" / "IPv6")
DestinationIPAddressType = "IPTD=" ("IvP4" / "IPv6")
SourceIPAddress = "IPAS=" (IPv4address / IPv6address)
; IPv4address and IPv6address defined in RFC 3261
DestinationIPAddress = "IPAD=" (IPv4address / IPv6address)
; IPv4address and IPv6address defined in RFC 3261
SourceRTPPort = "RTUS=" 1*5(DIGIT) ;1024-65535 inclusive
DestinationRTPPort = "RTUD=" 1*5(DIGIT)
;1024-65535 inclusive
SourceRTCPPort = "RTCS=" 1*5(DIGIT) ;1024-65535 inclusive
DestinationRTCPPort = "RTCD=" 1*5(DIGIT)
;1024-65535 inclusive
VoiceOrVBDprimaryCodec = "VCD=" ALPHA 1*31 (permittedchar)
;first character must be alphabetic
VoiceOrVBDsecondaryCodec = "VCDS=" ALPHA 1*31 (permittedchar)
;first character must be alphabetic
MaxCharacterRate = "CPS=" 1*2 (DIGIT)
MediaMode = "MMOD=" "a" / "v" / "f" / "m" / "t" / ALPHA
; audio, voice band data, fax relay, modem relay, text relay
; the token ALPHA is to permit additional future definitions
SampleRate = "SMPL=" 1*7 (DIGIT)
CodecFrameSize = "FRSZ=" 1*3 (DIGIT)
RTPpayloadSize = "PLSZ=" 1*3 (DIGIT)
PacketizationRate = "PKRT=" 1*5 (DIGIT)
SilenceSuppression = "SSUP=" ("on" / "off")
EchoCancellation = "ECAN=" ("on" / "off")
RFC2198RedundancyForVoiceOrVBD = "VRED=" ("on" / "off")
RFC2733FECforVoiceOrVBD = "VFEC=" ("on" / "off")
UnregisteredExtension = "X-" ExtensionName "=" ExtensionVal
RegisteredExtension = ExtensionName "=" ExtensionVal
ExtensionName = 1*32 (ALPHA)
ExtensionVal = 1*32 (alphanum)
;More precise definition in extension specifications
alphanum = ALPHA / DIGIT
permittedchar = alphanum / permittedspecialchar
permittedspecialchar = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")" / SP
Kumar et al Informational Page 28
MGCP RTCP-XR Package 6/14/2005
2.3.7 Applicability of VoIP metrics to Voice Band Data
For the definition of Voice Band Data, see [ITU V.152].
RTCP is required in conjunction with any RTP session [RFC 3550].
However, the various blocks in RTCP-XR, such as the VoIP metrics block,
are not. They must be negotiated at session establishment.
The parameters from the RTCP XR VoIP metrics block (Table 1) and the
RTCP Sender/Receiver Reports (Table 2) are applicable to Voice Band
Data. So are the session description parameters (Table 3). However,
note that the utility of the following parameters might be limited for
Voice Band Data:
- There is no correlation of the various MOS scores and R factors
with the end-users' perspective of the quality of the data or fax
transmission. Therefore, most implementations will send dummy MOS
scores (a value of 127) and R-factors (a value of 127)in RTCP
Extended Reports, omit them in the XRM/LVM line and either omit
them or assign them dummy values in the XRM/RVM line. Some
implementations may elect to use the MOS scores and R factors as
approximate (albeit poor) indicators of the degree of channel
impairment.
- For some Voice Band Data sessions, echo cancellation is turned
off. For others, it is turned on. If echo cancellation is off,
then RERL reverts to the Echo Return Loss of the hybrid
transformer or acoustic coupling path. However, some
implementations might not measure this parameter in the absence
of an active echo canceller. In such cases, this parameter will
be omitted in the XRM/LVM and XRM/RVM lines, or set to a dummy
value (127) in the XRM/RVM line.
- Many voice band data sessions [ITU V.152] use fixed-length jitter
buffers. If this is the case, then this will be reflected in the
JBA parameter (set to "non-adaptive"), the JBR parameter (set to
0) and the JBS parameter (set to JBM).
3. Call Flow Examples
The following examples are partial call flows for the case where the
XRM/mcr local connection option is set to "on". Only one endpoint's
perspective is shown. In this example, the remote endpoint sends voice
metrics to this endpoint via RTCP Extended Reports, Sender Reports and
Receiver Reports.
Note that these are call flow examples and not examples of typical
metrics values. These values have not been derived from real-world
situations and, therefore, do not necessarily have the right numeric
relationship between themselves.
Kumar et al Informational Page 29
MGCP RTCP-XR Package 6/14/2005
3.1 Metrics Reporting during Call agent-initiated Delete Connection
Step 1:
The Call Agent issues a CreateConnection command to the endpoint
instructing it to use PCMU media encoding and to invoke RTCP XR metric
collection, responding and reporting:
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, xrm/mcr: on
M: recvonly
Step 2:
The endpoint acknowledges the command and includes the rtxp-xr
attribute set to "voip-metrics":
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 3:
The endpoint receives a ModifyConnection command containing an LCO with
no xrm/mcr parameter, which indicates that the endpoint should continue
to use the previously received value of "on". Since the received SDP
also contains the rtcp-xr attribute with a value of "voip-metrics", it
is safe to assume that both ends will exchange the VoIP metrics block
in RTCP Extended Reports (XR).
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
L: a:PCMU;G728
M: sendrecv
I:1
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 4082 RTP/AVP 0
a=rtcp-xr:voip-metrics
Kumar et al Informational Page 30
MGCP RTCP-XR Package 6/14/2005
Step 4:
The endpoint acknowledges the command and, since VoIP metrics
collection/reporting is still "on", includes the rtxp-xr attribute set
to "voip-metrics":
200 1001 OK
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 5:
The Call Agent eventually issues a DeleteConnection:
DLCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
Step 6:
The endpoint acknowledges the command and returns the standard MGCP
connection parameters along with the XRM/LVM line and the XRM/RVM line.
This endpoint elects to include the remote equivalents of the
connection parameters on XRM/RVM line. Note that the remote end has
indicated that the ITU G.107 specification has been used to compute the
R-factors and that a proprietary algorithm, "Acme Widgets 233", has
been used to compute MOS-LQ. The remote end has not indicated the
algorithm used to compute MOS-CQ, which is on of the metrics that it
has communicated via an RTCP extended report. Also note that new lines
shown here are for document formatting reasons only.
250 1100 OK
P: PS=5000, OS=200000, PR=6000, OR=340000, PL=800,
JI=27, LA=180
XRM/LVM: NLR=28, JDR=14, BLD=128, GLD=10,
BD=55, GD=1000, RTD=180,ESD=30, SL=-15, NL=-20,
RERL=-23, GMN=16, RCQ=63, RLQ=61, XRCQ=65, MLQ=33, MCQ=31, PLC=3,
JBA=3, JBR=8, JBN=40, JBM=80, JBS=120, SSRC=27513888,
IPAD=128.96.41.1, RTPD=3456, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000,
PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180,
ESD=23, SL=-16, NL=-25, RERL=-23, GMN=16, RCQ=80, RLQ=82,
XRCQ=77, MLQ=37, MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60,
JBS=100, MLES=Acme widgets 233, RFES=ITU G.107,PS=6800,
OS=272000, PR=4900, OR=196000, IAJ=15, SSRC=832829,
IPAD=128.96.63.25, RTPD=4082, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000,
PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
Kumar et al Informational Page 31
MGCP RTCP-XR Package 6/14/2005
3.2 Metrics Reporting during Gateway-initiated Delete Connection
Step 1:
The Call Agent issues a CreateConnection command to the endpoint
instructing it to use PCMU media encoding and to invoke RTCP XR metric
collection and reporting:
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, xrm/mcr: on
M: recvonly
Step 2:
The endpoint acknowledges the command and includes the rtxp-xr
attribute set to "voip-metrics":
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 3:
The Endpoint issues a DeleteConnection command including the connection
parameters along with the XRM/LVM line and the XRM/RVM line:
DLCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
E: 900 ы Hardware error
P: PS=5000, OS=200000, PR=6000, OR=340000, PL=800,
JI=27, LA=180
XRM/LVM: NLR=28, JDR=14, BLD=128, GLD=10,
BD=55, GD=1000, RTD=180,ESD=30, SL=-15, NL=-20,
RERL=-23, GMN=16, RCQ=63, XRCQ=65, MLQ=33, MCQ=31, PLC=3, JBA=3,
JBR=8, JBN=40, JBM=80, JBS=120, SSRC=27513888, IPAD=128.96.41.1,
RTPD=3456, VCD=PCMU, VPT=0, SMPL=8000,
PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180,
ESD=23, SL=-16, NL=-25, RERL=-23, GMN=16, RCQ=80, XRCQ=77,
MLQ=37, MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60, JBS=100,
PS=6800, OS=272000, PR=4900, OR=196000, IAJ=15, SSRC=832829,
IPAD=128.96.63.25, RTPD=4082, VCD=PCMU, VPT=0, SMPL=8000,
PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
Kumar et al Informational Page 32
MGCP RTCP-XR Package 6/14/2005
Note that the RLQ parameter is not included in the XRM/LVM or the
XRM/RVM lines. This is just an example of allowed parameter omission.
This example could have very well been constructed with the RLQ
parameter.
Step 4:
The Call Agent acknowledges the command:
200 1100 OK
3.3 Metrics Reporting during Audit Connection
Step 1:
The Call Agent issues a CreateConnection command to the endpoint
instructing it to use PCMU media encoding and to invoke RTCP XR metric
collection, responding and reporting:
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, xrm/mcr: on
M: recvonly
Step 2:
The endpoint acknowledges the command and includes the rtxp-xr
attribute set to "voip-metrics":
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 3:
The endpoint receives a ModifyConnection command containing an LCO with
no xrm/mcr parameter, which indicates that the endpoint should continue
to use the previously received value of "on". Since the received SDP
also contains the rtcp-xr attribute with a value of "voip-metrics", it
is safe to assume that both ends will exchange the VoIP metrics block
in RTCP Extended Reports (XR).
Kumar et al Informational Page 33
MGCP RTCP-XR Package 6/14/2005
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
L: a:PCMU;G728
M: sendrecv
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 4082 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 4:
The endpoint acknowledges the command and, since VoIP metrics
collection/reporting is still "on", includes the rtxp-xr attribute set
to "voip-metrics":
200 1001 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 5:
The Call Agent eventually issues a AuditConnection that requests the
XRM/LVM and XRM/RVM lines but not the P (connection parameters) line:
AUCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
F: XRM/LVM, XRM/RVM
Step 6:
The endpoint acknowledges the command and returns the XRM/LVM line and
the XRM/RVM line. This endpoint elects to include the local and remote
equivalents of the connection parameters in the XRM/LVM and XRM/RVM
line. Also note that new lines shown here are for document formatting
reasons only.
Kumar et al Informational Page 34
MGCP RTCP-XR Package 6/14/2005
200 1100 OK
XRM/LVM: NLR=28, JDR=14, BLD=128, GLD=10,
BD=55, GD=1000, RTD=180,ESD=30, SL=-15, NL=-20,
RERL=-23, GMN=16, RCQ=63, RLQ=61, XRCQ=65, MLQ=33, MCQ=31, PLC=3,
JBA=3, JBR=8, JBN=40, JBM=80, JBS=120, PS=5000, OS=200000,
PR=6000, OR=340000, PL=800, IAJ=27, SSRC=27513888,
IPAD=128.96.41.1, RTPD=3456, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000,
PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180,
ESD=23, SL=-16, NL=-25, RERL=-23, GMN=16, RCQ=80, RLQ=82,
XRCQ=77, MLQ=37, MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60,
JBS=100, PS=6800, OS=272000, PR=4900, OR=196000, IAJ=15,
SSRC=832829, IPAD=128.96.63.25, RTPD=4082, VCD=PCMU, VPT=0,
MMOD=a, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
3.4 Metrics Reporting during Modify Connection
Step 1:
The Call Agent issues a CreateConnection command to the endpoint
instructing it to use PCMU media encoding and to invoke RTCP XR metric
collection, responding and reporting:
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, xrm/mcr: on
M: recvonly
Step 2:
The endpoint acknowledges the command and includes the rtxp-xr
attribute set to "voip-metrics":
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 3:
The endpoint receives a ModifyConnection command containing an LCO with
no xrm/mcr parameter, which indicates that the endpoint should continue
to use the previously received value of "on". Since the received SDP
also contains the rtcp-xr attribute with a value of "voip-metrics", it
is safe to assume that both ends will exchange the VoIP metrics block
in RTCP Extended Reports (XR).
Kumar et al Informational Page 35
MGCP RTCP-XR Package 6/14/2005
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
L: a:PCMU;G728
M: sendrecv
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 4082 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 4:
The endpoint acknowledges the command and, since VoIP metrics
collection/reporting is still "on", includes the rtxp-xr attribute set
to "voip-metrics":
200 1001 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=rtcp-xr:voip-metrics
Step 5:
The Call Agent eventually issues a ModifyConnection with the XRM/MMO
line requesting that local and remote metrics be reset and reported.
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
I: 1
L: a:PCMU;G728
M: sendrecv
XRM/MMO: RR
Step 6:
The endpoint acknowledges the command and returns the XRM/LVM line and
the XRM/RVM line. The endpoint does not include the connection
parameters line since this would violate [RFC 3435]. Instead, it
includes the local and remote equivalents of the connection parameters
in the XRM/LVM and XRM/RVM line. Also note that new lines shown here
are for document formatting reasons only.
Kumar et al Informational Page 36
MGCP RTCP-XR Package 6/14/2005
200 1001 OK
XRM/LVM: NLR=28, JDR=14, BLD=128, GLD=10,
BD=55, GD=1000, RTD=180,ESD=30, SL=-15, NL=-20,
RERL=-23, GMN=16, RCQ=63, RLQ=61, XRCQ=65, MLQ=33, MCQ=31, PLC=3,
JBA=3, JBR=8, JBN=40, JBM=80, JBS=120, PS=5000, OS=200000,
PR=6000, OR=340000, PL=800, IAJ=27, SSRC=27513888,
IPAD=128.96.41.1, RTPD=3456, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000,
PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180,
ESD=23, SL=-16, NL=-25, RERL=-23, GMN=16, RCQ=80, RLQ=82,
XRCQ=77, MLQ=37, MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60,
JBS=100, PS=6800, OS=272000, PR=4900, OR=196000, IAJ=15,
SSRC=832829, IPAD=128.96.63.25, RTPD=4082, VCD=PCMU, VPT=0,
MMOD=a, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off
4. Security Considerations
This package inherits the security considerations of the base MGCP
protocol. A possible new security issue involves a remote device
placing extra burden on a local endpoint by requesting metric
collection on that local endpoint. This threat can be mitigated by the
call agent specifically prohibiting the generation of local metrics
using the local connection option: xrm/mcr: off.
5. IANA Considerations
5.1 Package Registration
The IANA is hereby requested to register the following MGCP package:
Package Title Name Version
------------- ---- -------
RTCP XR metrics XRM 0
5.2. Extension Registration
The IANA is requested to create a registry of MGCP names of vendor-
specified VoIP metrics. These metrics MAY be used in the XRM/LVM and
XRM/RVM lines defined in this package. Such a metric SHALL be described
in a specification ("source document") approved by an accredited
standards organization such as the IETF or ITU. This document MAY be
informative and MAY address more than one metric. It MUST include:
- Contact name, email address and telephone number.
- Metric name, as an alphabetic character string
- Description of and ABNF notation for the permitted
range of values,
- A functional description of the metric i.e. what it
measures and how it is to be used,
- Optionally, the measurement algorithm and any IPR statements
associated with it.
Kumar et al Informational Page 37
MGCP RTCP-XR Package 6/14/2005
6. Changes from earlier drafts
6.1 Changes from the -00 version to the -01 version
Most changes from the -00 version to the -01 version of this draft are
backwards compatible, with the exception described below.
6.1.1 Changes that are not backwards compatible
There are two naming inconsistencies in the -00 draft between the table
of metrics and the ABNF. In the table of metrics, the R-factor and the
external R-factor were named NSR and XSR, while in the ABNF they were
named RF and XRF. There is no way to rectify this in a backwards
compatible manner. We changed these names in the -01 draft to "RCQ" for
the R-factor and "XRCQ" so as to not favor either of the earlier names.
6.1.2 Changes that are backwards compatible
All new features in this package are optional.
The following changes from the -00 version of this draft to the -01
version are backwards compatible:
- Inclusion of statistics from the RTCP sender and receiver reports,
with the exception of latency which is already present in the RTCP XR
VoIP metrics block. The reporting of these statistics via this package
is optional.
- Inclusion of session description parameters based on the ones defined
in RFC 2327, RFC 2198 etc. This included media description parameters
such as codec type.
- Inclusion of a modify connection procedure for the reporting and
resetting of voice quality metrics.
- Clarification of whether an XR or SR/RR metrics is a running
average/cumulative value or the last computed value. For the SR/RR
metrics, these rules are inherited from connection parameters in [RFC
3435].
- Inclusion of a new G.107-based parameter, RLQ, for indicating the
listening quality of a VoIP session.
- Clarification of the use of a negative sign in conjunction with the
noise level (NL) and residual echo return loss (RERL).
- Inclusion of a new parameter, MLES, for indicating the algorithm used
to estimate the MOS-LQ metric.
- ABNF correction for requiring at least one metric in the XRM/LVM
line.
Kumar et al Informational Page 38
MGCP RTCP-XR Package 6/14/2005
- Inclusion of a mechanism for defining vendor extension metrics that
can be used in this package, and a mechanism for optionally registering
these metrics with the IANA.
6.2 Changes from the -01 version to the -02 version
All changes from the -01 version of this draft to the -02 version are
backwards compatible. These are:
- Included the impact of redundancy (e.g. RFC 2198) and FEC (e.g.
RFC 2733) on packet loss computation.
- Corrections of errors and typos in the ABNF.
6.3 Potential future updates
- Add list of acronyms
All changes from the -01 version of this draft to the -02 version are
backwards compatible.
7. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC 3435] F. Andreasen, B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", January 2003.
[RFC 3611] T. Friedman, R. Caceres, A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", November 2003.
[RFC 3550] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", July 2003.
[RFC 2327] M.Handley and V. Jacobson, "SDP: Session Description
Protocol", April 1998.
[RFC 3660] B.Foster and F.Andreasen, "Basic Media Gateway Control
Protocol (MGCP) Packages", December 2003.
[RFC 2234] D.Crocker and P.Overell, "Augmented BNF for Syntax
Specifications: ABNF", November 1997.
[RFC 3261] J.Rosenberg, H.Schulzrinne, G.Camarillo, A.Johnston,
J.Peterson, R.Sparks, M.Handley, E.Schooler, "SIP: Session Initiation
Protocol", June 2002.
[RFC 2198] C.Perkins, I.Kouvelas, O.Hodson, V.Hardman, M.Handley,
J.C.Balot, A.Vega-Garcia and S. Fosse-Parisis, "RTP Payload for
Redundant Audio Data", September 1997.
[RFC 2733] J.Rosenberg, H.Schulzrinne, "An RTP Payload format for
Generic Forward Error Correction", December 1999.
[IANA RTP] http://www.iana.org/assignments/media-types/audio/.
Kumar et al Informational Page 39
MGCP RTCP-XR Package 6/14/2005
[US-ASCII] Coded Character Set--7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[ITU V.152] Procedures for supporting Voice-Band Data over IP Networks,
ITU V.152, pre-published draft, January 2005.
8. Acknowledgments
Contributors to this document include Alan Clark, Joe Stone, Flemming
Andreasen, Robert Biskner, Michael Ramalho, Paul Jones, Steve White,
David Ensign and the PacketCable NCS Specification Team.
9. Copyright Statement
"Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Kumar et al Informational Page 40