Internet Engineering Task D.Auerbach Force R.Kumar Cisco Systems D. Hancock CableLabs B. Hare Arris Internet Draft January 28, 2005 Document:draft-auerbach-mgcp-rtcpxr-00.txt Category: Informational Media Gateway Control Protocol VoIP RTCP-XR Metrics Package draft-auerbach-mgcp-rtcpxr-00.txt 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 gateway. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", MGCP RTCP-XR Package 1/28/2005 and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 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 AuditConnection procedures 2.3 New MGCP Parameters 2.3.1 Parameter Values 2.3.2 Grammar for VoIP metrics parameters 2.4 VoIP Metrics Negotiation 2.5 Implementation Considerations 2.5.1 Inter-working Considerations 3. Call Flow Examples 3.1 Call agent initiated DLCX 3.2 Gateway initiated DLCX 4. Security Considerations 5. IANA Considerations6. Normative References 7. Acknowledgments 1. Introduction This document defines a Media Gateway Control Protocol (MGCP) [RFC3435] 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. In addition to the parameters in the RTCP-XR VoIP metrics block, this document includes the inter-arrival jitter as defined in RFC 3550. The purpose of this inclusion is the alignment of MGCP-based VoIP metrics reporting with SIP. Note that the MGCP ConnectionParameters structure [RFC3435] allows the reporting of the local, but not the remote, version of this parameter. To report the remote version of inter-arrival jitter, this package may be used. 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 connected device as specified in RFC 3611. The term "reporting" refers to the process of reporting the accumulated local Auerbach, Kumar et al Informational Page 2 MGCP RTCP-XR Package 1/28/2005 and remote VoIP metric data for the connection to the Call Agent in either a DeleteConnection 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 endpoint 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, or 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 collect VoIP metrics by the remote endpoint via SDP signaling. The Call Agent can inhibit the collection and responding to remote endpoints by specifically turning off the collection/responding function. The VoIP metrics data that is reported to the Call Agent when the connection is deleted 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. This package is designed to provide an accurate measure of voice quality for basic 2-way call connections, where metrics are accumulated over the life of the connection and reported to the Call Agent when the connection is deleted. The package does not make any special provisions for mid- call path reconfiguration events that could affect voice quality. For example, if a ModifyConnection command changes the remote endpoint of a connection, the single metrics report generated when the connection is subsequently deleted would not provide any means to compare the metrics before and after the remote endpoint was changed. 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 and 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. Auerbach, Kumar et al Informational Page 3 MGCP RTCP-XR Package 1/28/2005 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 the gateway. 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 gateway 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 Auerbach, Kumar et al Informational Page 4 MGCP RTCP-XR Package 1/28/2005 MUST ignore an SDP request for metrics and MUST NOT transmit local metrics to the peer endpoint. The local endpoint MUST NOT report XR metrics upon receiving or initiating a DeleteConnection sequence and MUST NOT report XR metrics when responding to an AuditConnection command. 2.1.1.2 On Procedure 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 AuditConnection when the metric parameters are audited, and when sending a DeleteConnection command. The endpoint MUST omit the remote metrics from the report if no remote metrics were received from the remote endpoint. 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 endpoint are allowed. The local does not send this information until it is requested to do so by the remote endpoint. 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. Auerbach, Kumar et al Informational Page 5 MGCP RTCP-XR Package 1/28/2005 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 may be returned by the AuditConnection response (when the audit is requested). 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: 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. For example, the meaning of ææstandardÆÆ vs. ææenhancedÆÆ packet loss concealment must be gleaned from RFC 3611. 2.3.1 Parameter Values Unlike RTCP, parameter fields in MGCP are expressed in a text rather than a fixed binary format. Therefore, it is not necessary to stipulate upper bounds for numeric parameters in MGCP. However, the upper bounds specified in RFC 3611 still apply. Note that upper bounds in RFC 3611 are sometimes dictated by regularity in field size (e.g. increments of 8) rather than by the actual range of parameter values. For example, although a numeric value of 65,535 ms can be expressed as a 16-bit field, a viable RTP connection will never have a round trip delay with this value. Auerbach, Kumar et al Informational Page 6 MGCP RTCP-XR Package 1/28/2005 --------------------------------------------------------- | Parameter | Code | Value | | | | | --------------------------------------------------------- |Network | NLR |The proportion of packets lost | |packet loss | |since the start of transmission | |rate | |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 | |transmission 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 of lost and | |density | |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 7 MGCP RTCP-XR Package 1/28/2005 --------------------------------------------------------- | Parameter | Code | Value | | | | | --------------------------------------------------------- |Gap loss | GLD |The average proportion of lost and | |density | |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. | --------------------------------------------------------- |Gap |GD |The average duration of the gap | |duration | |periods, in milliseconds. | --------------------------------------------------------- |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. | --------------------------------------------------------- |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. | --------------------------------------------------------- |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. | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 8 MGCP RTCP-XR Package 1/28/2005 --------------------------------------------------------- | Parameter | Code | Value | | | | | --------------------------------------------------------- |Noise |NL | The ratio of the silent period | |level | | average background noise level to | | | | a 0 dBm0 reference, in dB. No sign| | | | is necessary since valid values | | | | MUST be less than or equal to | | | | 0 dB. Thus, NL=20 implies a noise | | | | level of 20 dB below the 0 dBm0 | | | | reference. | --------------------------------------------------------- |Residual |RERL | The echo return loss after the | |echo return | | effects of echo cancellation, in | |loss | | dB. No sign is necessary since | | | | valid values MUST be greater | | | | than or equal to 0 dB. | --------------------------------------------------------- |Minimum gap |GMN | The gap/burst transition | |threshold | | threshold; the recommended value | | | | is 16. Values in the range 1 - | | | | 255 are permitted. | --------------------------------------------------------- |R factor |NSR | A value representing the | | | | receiving end call quality for | | | | the RTP packet stream; | | | | calculated as per ITU-T | | | | Recommendation G.107. Valid | | | | values are greater than 0 and | | | | less than or equal to 100. | --------------------------------------------------------- |External |XSR | 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 100. | --------------------------------------------------------- |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.| --------------------------------------------------------- Auerbach, Kumar et al Informational Page 9 MGCP RTCP-XR Package 1/28/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.| --------------------------------------------------------- |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. | --------------------------------------------------------- |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). | --------------------------------------------------------- Auerbach, Kumar et al Informational Page 10 MGCP RTCP-XR Package 1/28/2005 --------------------------------------------------------- | Parameter | Code | Value | | | | | --------------------------------------------------------- |Absolute |JBS | Absolute maximum delay in | |maximum | | milliseconds that an adaptive | |jitter | | jitter buffer can reach under | |buffer | | worst case conditions. For fixed | |delay | | jitter buffers, this must be set | | | | to the maximum jitter buffer | | | | delay. | --------------------------------------------------------- |Inter- |IAJ | Per RFC 3550, the interarrival | |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 provided in | | | | milliseconds. | --------------------------------------------------------- 2.3.2 Grammar for VoIP metrics parameters The following describes the ABNF encoding for the local and remote metrics parameters. LocalVoIPMetrics = "XRM/LVM:" 0*WSP [VoIPMetric 0*("," 0*WSP VoIPMetric)] RemoteVoIPMetrics = "XRM/RVM:" 0*WSP [VoIPMetric 0*("," 0*WSP VoIPMetric)] VoIPMetric = NetworkPacketLossRate / JitterBufferDiscardRate / BurstLossDensity / GapLossDensity / BurstDuration / GapDuration / RoundTripNetworkDelay / EndSystemDelay / SignalLevel / NoiseLevel / ResidualEchoReturnLoss / MinimumGapThreshold / RFactor / ExternalRFactor / EstimatedMOS-LQ / EstimatedMOS-CQ / PacketLossConcealmentType / JitterBufferAdaptive / JitterBufferRate Auerbach, Kumar et al Informational Page 11 MGCP RTCP-XR Package 1/28/2005 / JitterBufferNominal / JitterBufferMax / JitterBufferAbsMax / InterArrivalJitter 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*5(DIGIT) ;0-65535 EndSystemDelay = "ESD=" 1*5(DIGIT) ;0-65535 SignalLevel = "SL=" ["-"] 1*3(DIGIT) ;-128 to 127 NoiseLevel = "NL=" ["-"] 1*3(DIGIT) ;-128 to 127 ResidualEchoReturnLoss = "RERL=" 1*3(DIGIT) ;0-127 RFactor = "RF=" 1*3(DIGIT) ;0-100, or 127 ExternalRFactor = "XRF=" 1*3(DIGIT) ;0-100, 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") 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 InterArrivalJitter = "IAJ=" 1*5(DIGIT) ;0-65535 2.4 VoIP Metrics Negotiation Auerbach, Kumar et al Informational Page 12 MGCP RTCP-XR Package 1/28/2005 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 endpoint 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 in PacketCable. Other options MAY be provided. When multiple options are provided they MUST be separated by a SPACE. 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 extended VoIP metrics reports to the far end via RTCP. Other xr-format options defined in RFC3611 that are received MAY be ignored. 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 gateway (via SDP) A local request from the controlling call agent (via a CreateConnection or ModifyConnection) The gateway MUST report the metrics during a DeleteConnection or AuditConnection (where VoIP metrics parameters are audited) sequence if the most recent Auerbach, Kumar et al Informational Page 13 MGCP RTCP-XR Package 1/28/2005 CreateConnection or ModifyConnection enabled metric reporting (xrm/mcr: on). If a VoIP metric is not computed locally, it MUST be omitted in the XRM/LVM: line. However, an endpoint supporting the XRM package MUST compute and report at least one VoIP metric from the table above. If the remote end indicates that a particular RTCP-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. If the remote end does not provide any remote VoIP metrics data, then the gateway response to a request for metrics data is based on the triggering command as follows: - DeleteConnection: the XRM/RVM: parameter MUST be omitted, - AuditConnection: the XRM/RVM: parameter MUST be included as an empty parameter. 3. Call Flow Examples The following examples are partial call flows for the local part of a call that is invoking the RTCP-XR feature. 3.1 Call agent initiated DLCX 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: recvonly 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 14 MGCP RTCP-XR Package 1/28/2005 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". Also, the received SDP contains no rtcp-xr parameter, which indicates that the remote endpoint does not want to receive RTCP XR reports from this endpoint. Note that the absence of the rtcp-xr attribute in the received SDP does not signal the remote endpoint's willingness or ability to honor a previous rtcp-xr "voip- metrics" request it received from this endpoint. MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 L: a:PCMU,G728 M: recvonly v=0 o=- 4723891 7428910 IN IP4 128.96.63.25 s=- c=IN IP4 128.96.63.25 t=0 0 m=audio 3456 RTP/AVP 8 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 8 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: Auerbach, Kumar et al Informational Page 15 MGCP RTCP-XR Package 1/28/2005 The gateway acknowledges the command and returns the standard MGCP connection parameters along with the RTCP-XR parameters (note that new-lines shown here are for document formatting reasons only): 250 1100 OK P: PS=1000, OS=60000, PR=800, OR=50000, PL=10, JI=27, LA=48 XRM/LVM: NLR=128, JDR=40, BLD=33, GLD=10, BD=55, GD=45, RTD=1000,ESD=1000, SL=-15, NL=20, RERL=23, GMN=80, RF=19, XRF=19, MLQ=19, MCQ=22, PLC=1, JBA=2, JBR=8, JBN=40, JBM=80, JBS=120, IAJ=10 XRM/RVM: NLR=128, JDR=40, BLD=33, GLD=10, BD=55, GD=45, RTD=1000, ESD=1000, SL=-16, NL=25, RERL=23, GMN=80, RF=19, XRF=19, MLQ=19, MCQ=22, PLC=1, JBA=0, JBR=8, JBN=30, JBM=60, JBS=100, IAJ=15 3.2 Gateway initiated DLCX 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: recvonly 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 issues a DeleteConnection command including the connection parameters and the RTCP metrics: DLCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0 Auerbach, Kumar et al Informational Page 16 MGCP RTCP-XR Package 1/28/2005 C: 1 I: 1 E: 900 - - Hardware error P: PS=1000, OS=60000, PR=800, OR=50000, PL=10, JI=27, LA=48 XRM/LVM: NLR=128, JDR=40, BLD=33, GLD=10, BD=55, GD=45, RTD=1000, ESD=1000, SL=-10, NL=20, RERL=23, GMN=80, RF=19, XRF=19, MLQ=19, MCQ=22, PLC=1, JBA=2, JBR=8, JBN=40, JBM=80, JBS=120 XRM/RVM: NLR=128, JDR=40, BLD=33, GLD=10, BD=55, GD=45, RTD=1000,ESD=1000, SL=-17, NL=21, RERL=23, GMN=80, RF=19, XRF=19, MLQ=19,MCQ=22, PLC=1, JBA=0, JBR=8, JBN=30, JBM=60, JBS=100 Note that the IAJ 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 IAJ parameter. Step 4: The Call Agent acknowledges the command: 200 1100 OK 4. Security Considerations This package inherits the security considerations of the base MGCP protocol. A possible new security issue involves a remote endpoint 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 The IANA is hereby requested to register the following MGCP package: Package Title Name Version ------------- ---- ------- RTCP-XR metrics XRM 0 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Auerbach, Kumar et al Informational Page 17 MGCP RTCP-XR Package 1/28/2005 [RFC3435] F. Andreasen, B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [RFC3611] T. Friedman, R. Caceres, A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. 7. Acknowledgments Contributors to this document include Flemming Andreasen, David Ensign, and the PacketCable NCS Specification Team. 8. Author's Addresses David Auerbach Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 dea@cisco.com Rajesh Kumar Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 rkumar@cisco.com 8. Full 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." Auerbach, Kumar et al Informational Page 18