Internet Engineering Task Force D.Auerbach Internet Draft R.Kumar Document: draft-auerbach-mgcp-rtcpxr-01 C. Sivalchelvan Category: Informational Cisco Systems Expires: November 2, 2005 D. Hancock CableLabs B. Hare Arris May 2, 2005 RTCP XR VoIP Metrics Package for the Media Gateway Control Protocol draft-auerbach-mgcp-rtcpxr-01 Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we am aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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 This document defines a Media Gateway Control Protocol (MGCP) package to control the collection of metrics supported by RTCP Extended Report as specified in [RFC 3611]. The package allows for the call agent to enable or disable the collection of these metrics. It also allows the call agent to control whether or not the gateway will respond to remote requests for metric collection from a peer device. MGCP RTCP-XR Package 5/1/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 LocalConnectionOptions 2.1.1 Endpoint Procedures 2.1.1.1 Off Procedure 2.1.1.2 On Procedure 2.1.1.3 Negotiate Procedure 2.2 MGCP Reporting Procedures 2.2.1 DeleteConnection Procedures 2.2.2 AuditConnection Procedures 2.2.3 ModifyConnection Procedures 2.2.4 Procedures for the reporting of SR and RR metrics 2.2.5 Procedures for the resetting of VQ metrics 2.3 New MGCP Parameters 2.3.1 Parameter Values 2.3.2 Parameter Extension Mechanism 2.3.3 Grammar for VoIP metrics parameters 2.4 VoIP Metrics Negotiation 2.5 Implementation Considerations 3. Call Flow Examples 3.1 Call agent initiated Delete Connection 3.2 Gateway initiated Delete Connection 3.3 Audit Connection 3.4 Modify Connection 4. Security Considerations 5. IANA Considerations 5.1 Package Registration 5.2 Extension Registration 6. Changes from draft-auerbach-mgcp-rtcpxr-00 7. Potential changes to future versions of this internet draft 8. Normative References 9. Acknowledgments 10. 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 voice traffic on VoIP connections. This capability is based on and utilizes the VoIP Metrics Block of the RTCP Extended Report as specified in [RFC 3611]. Auerbach, Kumar et al Informational Page 2 MGCP RTCP-XR Package 5/1/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. In addition to the parameters in the RTCP XR VoIP metrics block, this package includes the RTP statistics (such as inter-arrival jitter) defined for the Sender Report and Receiver Report in [RFC 3550]. The MGCP ConnectionParameters structure [RFC 3435] allows the reporting of the local, but not the remote, version of these statistics. To report both the local and remote versions of these RTP statistics, this package may be used. 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 per [RFC 2327]. 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 VoIP metrics data and accumulating remote VoIP metrics data received in RTCP XR packets from the remote device. The term "responding" is the sending of the accumulated local metrics data in RTCP XR packets to the remote device as specified in [RFC 3611]. The term "reporting" refers to the process of reporting the accumulated local and remote VoIP metric data for the connection to the Call Agent in either a DeleteConnection, ModifyConnection or AuditConnection command sequence. The Call Agent can ask a local endpoint to enable (or disable) VoIP metrics reporting for a connection in the CreateConnection or ModifyConnection command. When VoIP metrics reporting is enabled, the local endpoint will use SDP signaling as specified in [RFC 3611] to ask the remote device to start transmitting RTCP XR VoIP metrics data for the remote end of the connection. The local endpoint will accumulate a local and remote copy of the VoIP metrics data to be reported to the Call Agent when the connection is: ¸ deleted, ¸ modified (and the metrics data is requested), ¸ audited (and the metrics data is requested). An endpoint will collect local VoIP metric data for two separate reasons; when VoIP metrics reporting is enabled by the Call Agent via connection command, or when requested to Auerbach, Kumar et al Informational Page 3 MGCP RTCP-XR Package 5/1/2005 collect VoIP metrics by the remote device via SDP signaling. The Call Agent can inhibit the collection and responding to remote devices by specifically turning off the collection/responding function. The VoIP metrics data that is reported to the Call Agent when the connection is deleted, modified or audited represents the data that was accumulated since: ¸ the endpoint started collecting originally on the connection, whether collecting was initiated by a Call Agent request or by SDP signaling. ¸ the last connection modification where the Call Agent requested a reset of the metrics. An MGCP endpoint supporting this package shall always use SDP to request the VoIP metrics block from the remote device if VoIP metrics reporting is enabled by the Call Agent. However, such an endpoint SHALL NOT send the VoIP metrics block in RTCP Extended Reports (XR) unless the remote device has requested this block via SDP signaling. For MGCP endpoints supporting this package, this revokes the permission in [RFC 3611] to send RTCP XR blocks in the absence of the "rtcp-xr" SDP attribute. This package is designed to provide an accurate measurement of voice quality for two way connections. Metrics are collected from the start of the connection. If the connection is modified due to feature invocations, such as call transfer or call pick-up, this package allows the options of reporting and resetting these metrics as part of the connection modification procedures. Note that this package does not affect the reporting of other MGCP statistics as defined in the base protocols. The VoIP Metrics package definition is provided in Section 2. In Section 3, we provide two call flow examples showing how to use it. Security considerations are found in Section 4, followed by the IANA considerations and references. 2. VoIP Metrics Package Definition A package is defined for VoIP Metrics. The package defines new localconnectionoptions, and connection parameters as detailed below. Package Name: XRM Package Version: 0 2.1 LocalConnectionOptions This package defines a new LocalConnectionOptions (LCO) parameter to enable and disable VoIP Metrics reporting at Auerbach, Kumar et al Informational Page 4 MGCP RTCP-XR Package 5/1/2005 the local endpoint. This is an optional parameter with a default value of "negotiate". The Call Agent supplies this LCO parameter to instruct the endpoint to enable or disable the collection and reporting of RTCP XR Metrics for the target connection. The new parameter is the metric collection (and) report parameter and is encoded as "mcr". The parameter can have one of the following three values: ¸ off - disable VoIP metrics collecting, reporting and responding (encoded as "off"). ¸ on - enable VoIP metrics collecting, reporting and responding (encoded as "on"). ¸ negotiate - allow VoIP metrics collecting and responding if requested but disable VoIP reporting (encoded as "negotiate"). The following example shows how to use this parameter to turn VoIP metrics collection, reporting and responding on: L: xrm/mcr:on 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. Note that this LCO directly controls the reporting of XR metrics to the Call Agent and may control the collection of metrics. The collection of metrics is also dependent on a possible request from a peer device as indicated in the RemoteConnectionDescriptor. 2.1.1 Endpoint Procedures This section describes the endpoint procedures for each of the xrm/mcr parameter values. 2.1.1.1 Off Procedure 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 On Procedure Auerbach, Kumar et al Informational Page 5 MGCP RTCP-XR Package 5/1/2005 On receiving this value, if not already doing so, the endpoint MUST start calculating local VoIP Metrics data for the connection, and MUST instruct the far-end device to start sending VoIP Metrics data for the connection by including an "rtcp-xr" attribute with a value of "voip- metrics" in the SDP. The endpoint MUST report local and remote VoIP metrics in the response to DeleteConnection, 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. The endpoint MUST omit the remote metrics from the report if no remote metrics were received from the remote device. 2.1.1.3 Negotiate Procedure On receiving this value, the endpoint does nothing except to set an internal flag to indicate that SDP request for local metrics to be sent to a remote peer device are allowed. The local endpoint does not send this information until it is requested to do so by the remote device. 2.2 MGCP Reporting Procedures 2.2.1 DeleteConnection Procedures Endpoints supporting this package MUST report local metrics in the XRM/LVM parameter line (defined below) in delete connection responses and in gateway-initiated delete connection commands. Endpoints supporting this package MUST report remote metrics, if available, in the XRM/RVM parameter line (defined below) in delete connection responses and in gateway-initiated delete connection commands. Metrics reported in the XRM/LVM and XRM/RVM lines in a DeleteConnection Procedure are from the set of metrics associated with RTCP extended reports (Table 1) and, optionally, from the set of metrics associated with RTCP sender reports and receiver reports (Table 2). The reporting of these metrics is subject to: (1) The availability of the metric, (2) Policy regarding the inclusion of metrics related to RTCP sender reports and receiver reports on the XRM/LVM and XRM/RVM lines. The reporting of session parameters in the XRM/LVM and XRM/RVM lines in a DeleteConnection Procedure is optional. Auerbach, Kumar et al Informational Page 6 MGCP RTCP-XR Package 5/1/2005 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 request info values are included in an AUCX command, the endpoint MUST return the appropriate metric values if available. The two new request info values are: XRM/LVM Return the local voice metric values. XRM/RVM Return the remote voice metric values. If an endpoint is queried about a parameter it does not understand, the endpoint MUST NOT generate an error; instead the parameter MUST be omitted from the audit response. If an endpoint is queried about a parameter it does support, but has no value for, the endpoint MUST NOT generate an error; instead the parameter MUST be included in the audit response with an empty parameter value. Metrics reported in the XRM/LVM and XRM/RVM lines in an AuditConnection Procedure are from the set of metrics associated with RTCP extended reports (Table 1) and, optionally, from the set of metrics associated with RTCP sender reports and receiver reports (Table 2). The reporting of these metrics is subject to: (1) The availability of the metric, (2) Policy regarding the inclusion of metrics related to RTCP sender reports and receiver reports on the XRM/LVM and XRM/RVM lines. The reporting of session parameters in the XRM/LVM and XRM/RVM lines in an AuditConnection Procedure is optional. 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 three 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. Auerbach, Kumar et al Informational Page 7 MGCP RTCP-XR Package 5/1/2005 The metrics reporting mechanisms in this package are the XRM/LVM and XRM/RVM lines defined below. In addition, the connection parameters line (the P line) may also be used. Regardless of the use of the P: line, 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 with RTCP sender reports and receiver reports (Table 2). The reporting of these metrics is subject to: (1) The availability of the metric, (2) Policy regarding the inclusion of metrics related to RTCP sender reports and receiver reports on the XRM/LVM and XRM/RVM lines. During reset, all metrics are set to zero with the exception of signal level, noise level, residual echo return loss, all R factors and all MOS estimates. These are set to 127. Configuration parameters and session parameters are unaffected. 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.2.4 Procedures for the reporting of SR and RR metrics This primary purpose of this package is to specify the collection and reporting of metrics in the VoIP metrics block of RTCP Extended Reports. It allows the optional inclusion of RTP statistics (such as inter-arrival jitter) defined for the Sender Report and Receiver Report in [RFC 3550] in order to compensate for the fact that the MGCP base protocol [RFC 3435] does not specify connection parameters to be used for reporting remote metrics in the P: line. Also, there is an inconsistency in the MGCP base protocol [RFC 3435] between the textual definition of packet loss, which it allows to be negative due to duplicates in conformance with [RFC 3550] , and its ABNF syntax. This inconsistency is corrected in this package. Note that the latency metric 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]. Enabling or disabling VoIP metrics reporting via the xrm/mcr local connection option will not affect the collection or reporting of connection parameters in the P: line as defined in the base MGCP specification (RFC 3435). Auerbach, Kumar et al Informational Page 8 MGCP RTCP-XR Package 5/1/2005 Nor will 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. Note that setting the MediaMetricsOption ("MMO") parameter in a ModifyConnection command to "RES" (reset) or "RR" (report and reset) resets the value of the RTCP metrics as well as the RTCP XR metrics. The locally computed versions of the RTCP metrics are normally reported in the connection parameters line. 2.2.5 Procedures for the resetting of VQ metrics In addition to responding to relevant XRM/MMO values, endpoints supporting this package may reset VQ metrics for several other reasons such as a transition from voice to voiceband 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 voiceband data transition. 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 are described in an earlier section. 2.3 New MGCP Parameters Two new MGCP parameters are defined to support VoIP metrics reporting; one for reporting local metrics data, and one for reporting remote metrics data. They are returned in the DeleteConnection sequence and, if requested, are returned in the ModifyConnection and AuditConnection responses. Local metrics are included in the "XRM/LVM" line. Remote metrics are included in the XRM/RVM line. As an example, for a gateway that is recording local metrics and has received remote metrics, a DLCX will result in the following additional lines being returned in the response: Auerbach, Kumar et al Informational Page 9 MGCP RTCP-XR Package 5/1/2005 XRM/LVM: PLC=1, JBA=2, JBR=7 à XRM/RVM: PLC=0, JBA=0, JBR=3 à For the detailed semantics of these parameters, see the description of the VoIP Metrics Report block in [RFC 3611], the description of the Sender Report and Receiver Report in [RFC 3550] and the description of connection/session parameters in [RFC 2327]. For example, the meaning of ææstandardÆÆ vs. ææenhancedÆÆ packet loss concealment must be gleaned from [RFC 3611]. 2.3.1 Parameter Values The parameters listed below are from one of the following sources; 1. The VoIP metrics block in [RFC 3611] (Table 1). 2. The Sender Report and Receiver Report in [RFC 3550] (Table 2). These leverage the definition of connection parameters in [RFC 3435] without attempting to improve them by, for instance, specifying a different method for handling duplicates. 3. Session description per [RFC 2327] (Table 3). This information is not needed in applications where the call agent is cognizant of the local and remote SDP session descriptors. Note that the session parameters in the XRM/RVM line, like those in the XRM/LVM line are known locally rather than reported by the remote device. 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, 2 and 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. Auerbach, Kumar et al Informational Page 10 MGCP RTCP-XR Package 5/1/2005 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. 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. | --------------------------------------------------------- |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. | --------------------------------------------------------- |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. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 11 MGCP RTCP-XR Package 5/1/2005 --------------------------------------------------------- | Parameter | Code | Value | | | | | --------------------------------------------------------- |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 | --------------------------------------------------------- |Burst |BD |The average duration of the burst | |duration | |periods, in milliseconds. Computed | | | |from the start of metrics | | | |computation. | --------------------------------------------------------- |Gap |GD |The average duration of the gap | |duration | |periods, in milliseconds. Computed | | | |from the start of metrics | | | |computation. | --------------------------------------------------------- |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.| --------------------------------------------------------- Auerbach, Kumar et al Informational Page 12 MGCP RTCP-XR Package 5/1/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. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 13 MGCP RTCP-XR Package 5/1/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 | | | | 0-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. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 14 MGCP RTCP-XR Package 5/1/2005 --------------------------------------------------------- | Parameter | Code | Value | | | | | --------------------------------------------------------- |Estimated |MCQ | An estimated receiving end | |MOS-CQ | | Conversational Quality MOS. The | | | | nominal range of MOS scores is | | | | 0-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 | |Adaptive | | 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. | --------------------------------------------------------- |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. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 15 MGCP RTCP-XR Package 5/1/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 is | |Algorithm | | is expressed as a human-readable | | | | character string with an | | | | unrestricted set of values. | --------------------------------------------------------- Unavailable parameters are simply omitted in the XRM/LVM line. In the XRM/LVM 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. Auerbach, Kumar et al Informational Page 16 MGCP RTCP-XR Package 5/1/2005 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.| --------------------------------------------------------- |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. | --------------------------------------------------------- |Packets |PR | The number of packets that were | |Received | | were received on the connection | | | | since the start of metrics | | | | computation. | --------------------------------------------------------- |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. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 17 MGCP RTCP-XR Package 5/1/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. | --------------------------------------------------------- |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. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 18 MGCP RTCP-XR Package 5/1/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 RTP |RTPS | The source RTP port for | |port | | the stream under measurement | --------------------------------------------------------- |Destination |RTPD | The destination RTP port for | |RTP port | | the stream under measurement | --------------------------------------------------------- |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 |CDC | The last RTP codec used. This is | | | | expressed as a character string | | | | corresponding to the MIME subtype| | | | in [IANA RTP] or an experimental | | | | codec name starting with "X-". | --------------------------------------------------------- |Payload type |PT | The last RTP payload type used. | --------------------------------------------------------- |Voiceband |VBD | This indicates whether the | |Data | | measured RTP stream carried | | | | voiceband data (modem or | | | | facsimile passthrough). The last | | | | state is indicated. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 19 MGCP RTCP-XR Package 5/1/2005 --------------------------------------------------------- | Parameter | Code | Value | | | | | --------------------------------------------------------- |Sample rate |SMPL | The rate at which media is | | | | is sampled (samples per second) | | | | for the last codec used. | --------------------------------------------------------- |RTP payload |FRSZ | The number of octets in a the RTP| |frame size | | packet payload ("frame") for the | | | | last codec used. | --------------------------------------------------------- |Packetization|PKRT | The number of RTP packets per | |rate | | second. | --------------------------------------------------------- |Silence |SSUP | This indicates whether silence | |Suppression | | suppression is enabled. The last | | | | value is used. | --------------------------------------------------------- |Echo |ECAN | This indicates whether echo | |Cancellation | | cancellation is enabled. The last| | | | value is used. | --------------------------------------------------------- |Redundancy |REDN | This indicates whether [RFC 2198]| |(RFC 2198) | | redundancy was used. The last | | | | state is used. | --------------------------------------------------------- |Forward |FEC | This indicates whether [RFC 2733]| |Error | | Forward Error Correction was | |[RFC 2733] | | used. The last state is used. | --------------------------------------------------------- 2.3.2 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-acmewidgetsABC" 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. Auerbach, Kumar et al Informational Page 20 MGCP RTCP-XR Package 5/1/2005 2.3.3 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. MediaMetricsOption = "XRM/MMO:" *WSP ("REP"/"RES"/"RR") LocalVoIPMetrics = "XRM/LVM:" *WSP VoIPMetric *("," *WSP VoIPMetric) ;one or more local metric RemoteVoIPMetrics = "XRM/RVM:" *WSP [VoIPMetric *("," *WSP VoIPMetric)]; zero or more remote metrics VoIPMetric = NetworkPacketLossRate / JitterBufferDiscardRate / BurstLossDensity / GapLossDensity / BurstDuration / GapDuration / RoundTripNetworkDelay / EndSystemDelay / SignalLevel / NoiseLevel / ResidualEchoReturnLoss / MinimumGapThreshold / RFactor-CQ / RFactor-LQ / ExternalRFactor / EstimatedMOS-LQ / EstimatedMOS-CQ / PacketLossConcealmentType / JitterBufferAdaptive / JitterBufferRate / JitterBufferNominal / JitterBufferMax / JitterBufferAbsMax / MOSLQEstimationAlgorithm / InterArrivalJitter / PacketsSent / OctetsSent / PacketsReceived / OctetsReceived / PacketsLost / SSRC / SourceIPAddress / SourceIPAddressType / DestinationIPAddress / DestinationIPAddressType / SourceRTPPort / DestinationRTPPort / SourceRTCPPort Auerbach, Kumar et al Informational Page 21 MGCP RTCP-XR Package 5/1/2005 / DestinationRTCPPort / Codec / PayloadType / VoicebandData / SampleRate / RTPpayloadFrameSize / PacketizationRate / SilenceSuppression / EchoCancellation / RFC2198Redundancy / RFC2733FEC / UnregisteredExtension / 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") Auerbach, Kumar et al Informational Page 22 MGCP RTCP-XR Package 5/1/2005 JitterBufferAdaptive = "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=" 1*32 (permittedchar) 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 = "RTPS=" 1*5(DIGIT) ;1024-65535 inclusive DestinationRTPPort = "RTPD=" 1*5(DIGIT) ;1024-65535 inclusive SourceRTCPPort = "RTCS=" 1*5(DIGIT) ;1024-65535 inclusive DestinationRTCPPort = "RTCD=" 1*5(DIGIT) ;1024-65535 inclusive Codec = "CDC=" 1*32 (permittedchar) PayloadType = "PT=" 1*3 (DIGIT); 0-127 VoicebandData = "VBD=" ("on" / "off") SampleRate = "SMPL=" 1*7 (DIGIT) RTPpayloadFrameSize = "FRSZ=" 1*3 (DIGIT) PacketizationRate = "PKRT=" 1*5 (DIGIT) SilenceSuppression = "SSUP=" ("on" / "off") EchoCancellation = "ECAN=" ("on" / "off") RFC2198Redundancy = "REDN=" ("on" / "off") RFC2733FEC = "FEC=" ("on" / "off") UnregisteredExtension = "X=" ExtensionName "=" ExtensionVal RegisteredExtension = ExtensionName "=" ExtensionVal ExtensionName = 1*10 (ALPHA) ExtensionVal = 1*10 (alphanum) ;More precise definition in extension specifications alphanum = ALPHA / DIGIT permittedchar = alphanum / permittedspecialchar permittedspecialchar = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" Auerbach, Kumar et al Informational Page 23 MGCP RTCP-XR Package 5/1/2005 2.4 VoIP Metrics Negotiation RFC 3611 adds a new SDP attribute called "rtcp-xr" that can be used by a local endpoint of a connection to ask the remote device to send RTCP XR reports for its locally collected metrics data. This attribute is encoded as follows: rtcp-xr: This rtcp-xr attribute can be used as either a session- level or media-level attribute. Only the voip-metrics xr- format option is mandated by this package. Other options MAY be provided. See [RFC 3611] for more information on the use of this attribute parameter. Send: The rtcp-xr:voip-metrics parameter MUST be sent in accordance with [RFC 3611] when voip-metrics is configured to be "on" via the Local Connection Options. When present, the parameter MAY appear as either a session- level or media-level attribute. This attribute parameter MUST NOT be sent when VoIP metrics is configured to be "off" or "negotiate". The endpoint MAY send other xr- format options independent of the VoIP Metrics LCO which are defined in [RFC 3611]. Receive: When the voip-metrics xr-format is received via this attribute parameter, the endpoint MUST include extended voip-metrics reports to the far end via RTCP as defined in [RFC 3611] unless the Call Agent has explicitly instructed the endpoint not to do so by configuring the VoIP metrics Local Connection Option to be "off". If the attribute parameter is not received, received but missing the voip-metrics option, or received but blank, i.e. no xr- format provided, then the endpoint MUST NOT include the VoIP metrics block in RTCP Extended Reports to the far end. Thus, the allowance in [RFC 3611] for endpoints that use SDP to exchange RTCP Extended Reports without prior SDP signaling is rescinded for MGCP endpoints supporting this package. 2.5 Implementation Considerations As explained in the introduction, an endpoint or gateway must draw the distinction between collecting RTCP XR voice quality metrics, responding to peer requests for metrics and reporting the metrics to the local call agent. The collection of metrics can be triggered by one or both of the following: A remote request from a peer device (via SDP) A local request from the controlling call agent (via a CreateConnection or ModifyConnection Auerbach, Kumar et al Informational Page 24 MGCP RTCP-XR Package 5/1/2005 The gateway MUST report the metrics in the response to a DeleteConnection, 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 if the most recent CreateConnection or ModifyConnection enabled metric reporting (xrm/mcr: on). Individual metrics from RTCP XR VoIP metrics block (Table 1) MUST be omitted in the XRM/LVM: line if not computed locally. However, an endpoint supporting the XRM package MUST compute and report at least one metric from Table 1 above. All other parameters (Table 2 and 3) are completely optional and may be omitted in the XRM/LVM: line regardless of whether the are known or not. If the remote device indicates that a particular RTCP SR/RR or XR 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. Assigning a dummy value to a parameter indicates that a value is not available for this parameter. For parameters based on RTCP SR and RR (Table 2), this value is 0. For parameters based on RTCP XR (Table 1), this is also 0, with the following exceptions: ¸ signal level, noise level, residual echo return loss, the various R factors and MOS estimates all have a dummy value of 127. ¸ the minimum gap threshold MUST have a non-zero value [RFC 3611]if the RTCP XR metrics block is present. If the remote device does not provide any data pertaining to RTCP XR VoIP metrics block (Table 1), then the local endpoint MAY omit the XRM/RVM: line in DeleteConnection sequences and in ModifyConnection sequences (where metrics are requested). Alternately, it MAY include this line with any available metrics reported via RTCP Sender Reports or Receiver Reports (Table 2) or with one or more session parameters (Table 3). If XRM/RVM information is requested via an AuditConnection, then an XRM/RVM MUST be included in the response. This line MAY, however, be empty if no data pertaining to RTCP XR VoIP metrics block (Table 1) is provided by the remote device. Alternately, the local endpoint MAY include this line with any available metrics reported via RTCP Sender Reports or Receiver Reports (Table 2) or with one or more session parameters (Table 3). Auerbach, Kumar et al Informational Page 25 MGCP RTCP-XR Package 5/1/2005 An endpoint receiving a disallowed value in an RTCP Sender Report, Receiver Report or Extended Report MUST ignore it. Regardless of the MGCP procedure involved, the parameter MUST be omitted in the XRM/RVM line. An example of a disallowed value is any value other than 127 or 0-100 for an R-factor. 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. 3.1 Call agent initiated Delete Connection Step 1: The Call Agent issues a CreateConnection command to the gateway 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: sendrecv Step 2: The gateway 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 gateway receives a ModifyConnection command containing an LCO with no xrm/mcr parameter, which indicates that the Auerbach, Kumar et al Informational Page 26 MGCP RTCP-XR Package 5/1/2005 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 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 gateway 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 DeleteConnection: DLCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 I: 1 Step 6: The gateway acknowledges the command and returns the standard MGCP connection parameters along with the XRM/LVM line and the XRM/RVM line. This gateway elects to include the remote equivalents of the connection parameters on XRM/RVM line. Also note that new lines shown here are for document formatting reasons only. Auerbach, Kumar et al Informational Page 27 MGCP RTCP-XR Package 5/1/2005 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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=off 3.2 Gateway initiated Delete Connection Step 1: The Call Agent issues a CreateConnection command to the gateway 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: sendrecv Step 2: The gateway 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 Auerbach, Kumar et al Informational Page 28 MGCP RTCP-XR Package 5/1/2005 Step 3: The Gateway 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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=off 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 Audit Connection Step 1: The Call Agent issues a CreateConnection command to the gateway 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: sendrecv Auerbach, Kumar et al Informational Page 29 MGCP RTCP-XR Package 5/1/2005 Step 2: The gateway 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 gateway 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 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 gateway 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=- Auerbach, Kumar et al Informational Page 30 MGCP RTCP-XR Package 5/1/2005 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 F: XRM/LVM, XRM/RVM Step 6: The gateway acknowledges the command and returns the XRM/LVM line and the XRM/RVM line. This gateway elects to include the local and remote equivalents of the connection parameters on the XRM/LVM and XRM/RVM line. Also note that new lines shown here are for document formatting reasons only. 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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=off 3.4 Modify Connection Step 1: The Call Agent issues a CreateConnection command to the gateway 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: sendrecv Auerbach, Kumar et al Informational Page 31 MGCP RTCP-XR Package 5/1/2005 Step 2: The gateway 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 gateway 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 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 gateway 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 Auerbach, Kumar et al Informational Page 32 MGCP RTCP-XR Package 5/1/2005 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 L: a:PCMU,G728 M: sendrecv XRM/MMO: RR Step 6: The gateway acknowledges the command and returns the XRM/LVM line and the XRM/RVM line. Although it could have also included the connection parameters line, it does not do so. This gateway elects to include the local and remote equivalents of the connection parameters on the XRM/LVM and XRM/RVM line. Also note that new lines shown here are for document formatting reasons only. 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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=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, CDC=PCMU, PT=0, VBD=off, SMPL=8000, PKRT=200, SSUP=on, ECAN=on, REDN=off, FEC=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 Auerbach, Kumar et al Informational Page 33 MGCP RTCP-XR Package 5/1/2005 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. ¸ Description of and ABNF notation for the alphabetic character string that denotes the metric, ¸ 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. 6. Changes from draft-auerbach-mgcp-rtcpxr-00 Most changes from the -00 version of this draft are backwards compatible, with the exception described below. 6.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. Auerbach, Kumar et al Informational Page 34 MGCP RTCP-XR Package 5/1/2005 6.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 per RFC 2327. 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. ¸ 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. 7. Potential changes to future versions of this internet draft ¸ Reporting of key variable components of the R factor, in addition to the R factor metrics already listed, so that a fair comparison can be made between endpoints which use different E-model coefficients. 8. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. Auerbach, Kumar et al Informational Page 35 MGCP RTCP-XR Package 5/1/2005 [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/. 9. Acknowledgments Contributors to this document include Alan Clark, Flemming Andreasen, Robert Biskner, Michael Ramalho, David Ensign and the PacketCable NCS Specification Team. 10. 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, Auerbach, Kumar et al Informational Page 36 MGCP RTCP-XR Package 5/1/2005 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." Auerbach, Kumar et al Informational Page 37