Internet DRAFT - draft-auerbach-mgcp-rtcpxr

draft-auerbach-mgcp-rtcpxr









            Internet Engineering Task Force                        R.Kumar 
            Internet Draft                                      D.Auerbach 
            Document: draft-auerbach-mgcp-rtcpxr-07         C. Sivachelvan 
            Category: Informational                          Cisco Systems 
            Expires: May 1, 2008                                D. Hancock 
                                                                 CableLabs 
                                                                   B. Hare 
                                                                     Arris 
                                                              Nov. 1, 2007 
                                           
                                           
              RTCP XR VoIP Metrics Package for the Media Gateway Control Protocol 
                           draft-auerbach-mgcp-rtcpxr-07 
             
             
            Status of this Memo 
             
            By submitting this Internet-Draft, each author represents that any 
            applicable patent or other IPR claims of which he or she is aware have 
            been or will be disclosed, and any of which he or she becomes aware 
            will be disclosed, in accordance with Section 6 of BCP 79. 
             
            Internet-Drafts are working documents of the Internet Engineering Task 
            Force (IETF), its areas, and its working groups.  Note that other 
            groups MAY also distribute working documents as Internet-Drafts. 
             
            Internet-Drafts are draft documents valid for a maximum of six months 
            and MAY be updated, replaced, or obsoleted by other documents at any 
            time.  It is inappropriate to use Internet-Drafts as reference material 
            or to cite them other than as "work in progress." 
             
            The list of current Internet-Drafts can be accessed at 
            http://www.ietf.org/ietf/1id-abstracts.txt. 
             
            The list of Internet-Draft Shadow Directories can be accessed at 
            http://www.ietf.org/shadow.html. 
             
            This Internet-Draft will expire on May 1, 2008. 
             
            Abstract 
             
            The main intent of this document is to define a Media Gateway Control 
            Protocol (MGCP) package to control the reporting of metrics supported 
            by the VoIP metrics block in RTCP Extended Reports as specified in [RFC 
            3611]. It also allows the call agent to control whether or not the 
            gateway will request a peer device via SDP to send the VoIP metrics 
            block in RTCP Extended Reports and whether it will respond positively 
            to such requests from the peer device. Besides this primary focus, this 
            MGCP RTCP-XR Package                             4/12/2007 
            package also allows the reporting of metrics defined for RTCP Sender 
            Reports and Receiver Reports [RFC 3550] and the reporting of session 
            description parameters (based on the ones defined in RFC 2327, RFC 2198 
            etc.). 
                                                      
              
             
            Conventions used in this document 
             
            The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
            "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
            document are to be interpreted as described in BCP 14, RFC 2119. 
             
              
                                   Table of Contents 
             
            1. Introduction 
            2. VoIP Metrics Package Definition 
            2.1 Local Connection Options 
            2.1.1 Responses to the xrm/mcr local connection option  
            2.1.1.1 Response to a value of "off" 
            2.1.1.2 Response to a value of "on" 
            2.1.1.3 Response to a value of "negotiate" 
            2.1.2 Impact of the xrm/mcr LCO on VoIP metrics block exchange 
            2.2 MGCP Protocol Procedures 
            2.2.1 DeleteConnection Procedures 
            2.2.2 AuditConnection Procedures 
            2.2.3 ModifyConnection Procedures 
            2.3 The LVM and RVM Lines for reporting Local And Remote Metrics 
            2.3.1 Inclusion/Omission of XRM/LVM and XRM/RVM parameters 
            2.3.2 XRM/LVM and XRM/RVM parameter values 
            2.3.3 Procedures for the resetting of metrics 
            2.3.4 Impact redundancy and FEC on  packet loss computations 
            2.3.5 Parameter Extension Mechanism 
            2.3.6 Formal Syntax of VoIP Metrics Package 
            2.3.7 Impact of media state changes on VoIP metrics 
            2.3.8 Applicability of VoIP metrics to Voice Band Data 
            2.3.9 Applicability of VoIP metrics to Fax Relay and Text Relay 
            3. Call Flow Examples 
            3.1 Metrics Reporting during Call agent-initiated Delete Connection 
            3.2 Metrics Reporting during Gateway-initiated Delete Connection 
            3.3 Metrics Reporting during Audit Connection 
            3.4 Metrics Reporting during Modify Connection 
            4. Security Considerations 
            5. IANA Considerations 
            5.1 Package Registration 
            5.2 Extension Registration 
            6. Changes from earlier drafts 
            Kumar et al            Informational                 Page 2 
            MGCP RTCP-XR Package                             4/12/2007 
            6.1 Changes from the -00 version to the -01 version 
            6.2 Changes from the -01 version to the -02 version 
            6.3 Changes from the -02 version to the -03 version 
            6.4 Changes from the -03 version to the -04 version 
            6.5 Changes from the -04 version to the -05 version 
            6.6 Changes from the -05 version to the -06 version 
            6.7 Potential future updates 
            7. Normative References 
            8. Acknowledgments 
            9. Copyright Statement 
             
            1. Introduction 
             
            This document defines a Media Gateway Control Protocol (MGCP) [RFC 
            3435] package that enables the collection and reporting of metrics that 
            measure the quality of traffic on two-way VoIP connections. This 
            capability is based on and utilizes the VoIP Metrics Block of the RTCP 
            Extended Report as specified in [RFC 3611].  
             
            In accordance with [RFC 3435], the term "gateway" is used to denote the 
            device controlled via MGCP. This is not intended to preclude the use of 
            MGCP or of this package to control devices that are not, in the 
            strictest terms, media gateways. For the purposes of this package, the 
            terms "media gateway", "gateway" and "endpoint" are used 
            interchangeably. Also, the terms "media gateway controller" and "call 
            agent" are used interchangeably.  
             
            In addition to the parameters in the RTCP XR VoIP metrics block, this 
            package allows the collection of statistics defined for RTCP Sender 
            Reports and Receiver Reports [RFC 3550]. The ConnectionParameters 
            structure [RFC 3435] allows the reporting of the local, but not the 
            remote, version of statistics defined for RTCP Sender Reports and 
            Receiver Reports [RFC 3550]. To report both the local and remote 
            versions of these RTP statistics, this package MAY be used. Note that 
            this package does not affect the collection or reporting of connection 
            parameters defined in the base MGCP specification (RFC 3435). Nor does 
            it affect the sending of RTCP Sender Reports (SR) and Receiver Reports 
            (RR). 
             
            This package also includes session description parameters (based on the 
            ones defined in RFC 2327, RFC 2198 etc.). These MAY be reported via 
            this package to obviate the need for call agents to snoop SDP session 
            descriptors. 
             
            This package makes a distinction between collecting, responding and 
            reporting. The term "collecting" refers to the process of calculating 
            and accumulating local metric data and accumulating remote metric data 
            received in RTCP Sender, Receiver and Extended Reports from the remote 
            device.  The term "responding" in the context of this package is 
            limited to the sending of accumulated local metric data via RTCP 
            Kumar et al            Informational                 Page 3 
            MGCP RTCP-XR Package                             4/12/2007 
            Extended Reports to the remote device as specified in [RFC 3611]. Note 
            that this package does not control the communication of session 
            statistics via RTCP Sender Reports (SR) and Receiver Reports (RR). 
            These reports MUST be sent in the manner REQUIRED of all RTP endpoints 
            [RFC 3550]. The term "reporting" refers to the process of reporting the 
            accumulated local and remote metric data for the connection to the Call 
            Agent in either a DeleteConnection, ModifyConnection or AuditConnection 
            command sequence.  
             
            An endpoint will "collect" local session metrics for several reasons: 
             
               - To report metrics in the "northbound" direction via the XRM/LVM 
                 and XRM/RVM parameters specified in this package. 
               - To communicate metrics in the "east-west" direction via RTCP 
                 extended reports, 
               - To report metrics in the "northbound" direction via other 
                 mechanisms such as connection parameters [RFC 3435] and log 
                 transfers not addressed in this document,  
               - To communicate metrics in the "east-west" direction via RTCP 
                 Sender Reports and Receiver Reports. 
             
            The sets of metrics collected for these purposes are not the same. This 
            package is limited to defining the metrics that MAY be reported via the 
            XRM/LVM and XRM/RVM lines. This MAY or MAY not be a superset of the 
            metrics that MAY be communicated via the VoIP metrics block in RTCP 
            extended reports. 
             
            The Call Agent can ask an endpoint to enable or disable the reporting 
            of metrics via this package. Enabling this reporting also enables the 
            "east-west" communication of metrics via the RTCP XR VoIP metrics block 
            from the local endpoint's perspective. Whether this "east-west" 
            communication actually takes place also depends on the peer endpoint's 
            capabilities. When it disables "northbound" reporting via this package, 
            the call agent MAY either disable the "east-west" communication of 
            metrics via the RTCP XR VoIP metrics block, or it MAY require the 
            endpoint to communicate the VoIP metrics block in the "east-west" 
            direction if the remote end requests it. Disabling "northbound" 
            reporting via this package has no impact on the use of RTCP Sender 
            Reports or Receiver Reports. 
             
            Like RTCP-XR [RFC 3611], this package focuses on voice metrics. 
            However, it does examine the relevance of these metrics to other media 
            modes such as voice band data [ITU V.152], fax relay [ITU T.38] and 
            text relay [ITU V.151]. The MGGCP-based reporting of metrics that are 
            unique to the voice band data, fax relay and text relay will need to be 
            defined in other MGCP packages. 
             
            Kumar et al            Informational                 Page 4 
            MGCP RTCP-XR Package                             4/12/2007 
            The metric data reported to the Call Agent via this package when a 
            connection is deleted, modified or audited represents the data that was 
            accumulated/averaged over a computation interval. This package allows 
            this interval to be selected in a flexible manner. This interval MAY 
            encompass the time since the last metrics reset, if any,  or since the 
            start of the session (in the absence of resets). Alternately, this 
            interval MAY consist of a relatively short period (e.g. 5 seconds) 
            prior to metrics capture and reporting. The metrics reset is commanded 
            by the call agent in the case of feature invocations such as call 
            transfer or call pick-up.  
             
            In the case of media mode shifts (such as voice to voice band data), 
            this package allows the resetting of metrics or their seamless 
            continuation in to the new mode. In the case of call agent-controlled 
            media mode shifts, this resetting is controlled by the call agent. In 
            the case of autonomous, endpoint-controlled media mode shifts, this 
            resetting is also under endpoint control.  The preferred behavior, 
            which might not be followed by all endpoints, is for the metrics to be 
            reset.   
             
            Note that, in some implementations, metrics are not reset during media 
            mode shifts. Instead, metrics that are applicable in the new mode 
            continue to be accumulated/averaged as before. Also, for metrics that 
            are not applicable in the new mode, further computation is suspended 
            until when another media mode shift renders these metrics relevant 
            again. 
             
            The VoIP Metrics package definition is provided in Section 2. This 
            includes a detailed description of relevant MGCP protocol procedures, a 
            list of parameters that can be reported via this package, and an 
            analysis of the applicability of these parameters to voice band data, 
            fax relay and text relay. In  Section 3, we provide four call flow 
            examples showing how to use the package.  Security considerations are 
            found in Section 4, followed by the IANA considerations and references. 
            Table 1 lists the metrics based on the VoIP metrics block in RTCP 
            Extended Reports [RFC 3611]. It also includes parameters that address 
            the metrics computation interval and the occurrence of metrics resets 
            since session start. Table 2 lists the metrics based on RTCP Sender 
            Reports and Receiver Reports [RFC 3550]. Note that Table 2 uses the 
            metrics definitions in [RFC 3550] and [RFC 3435] as is, without 
            attempting to improve them by specifying, for instance,  a better 
            method for handling duplicates. Table 3 lists session parameters, most 
            of which are from RFCs which define SDP constructs (e.g. RFC 2327, RFC 
            2198, RFC 2733).  Tables 4, 5 and 6 list the applicability of the 
            metrics and session parameters in Tables 1, 2 and 3 respectively to fax 
            relay. Tables 7, 8 and 9 do the same for text relay.   
             
              
            Kumar et al            Informational                 Page 5 
            MGCP RTCP-XR Package                             4/12/2007 
            2. VoIP Session Metrics Package Definition 
             
            A package is defined for VoIP session  metrics.   
             
            Package Name:    XRM 
            Package Version: 0 
             
            This package defines the following parameters: 
             
            -    A new local connections option, "mcr" (Metrics Reporting) for 
                 enabling and disabling metrics reporting via this package. Note 
                 that metrics collection via MGCP might use other mechanisms (e.g. 
                 the connection parameters in the base MGCP specification, RFC 
                 3435) that are not impacted by this local connection option. 
            -    A new parameter line, "MMO" (Media Metrics Option) that allows 
                 the call agent to request local and remote metrics in a modify 
                 connection response, and/or to reset the local and remote 
                 metrics. 
            -    A new parameter line, "LVM" (Local VoIP Metrics), for reporting  
                 locally collected metrics. 
            -    A new parameter line, "RVM" (Remote VoIP Metrics), for reporting 
                 remotely collected metrics communicated to the reporting endpoint 
                 via RTCP Extended Reports, Sender Reports and Receiver Reports. 
             
            2.1 Local Connection Options 
             
            The local connection option (LCO) parameter, "xrm/mcr", is an OPTIONAL 
            parameter with one of the following  three values: 
             
               - "off": Disables the reporting of metrics via this package AND the 
                 "east-west" communication of metrics via the RTCP XR VoIP metrics 
                 block 
               - "on": Enables the reporting of metrics via this package AND the 
                 "east-west" communication of metrics via the RTCP XR VoIP metrics 
                 block. Whether this "east-west" communication actually takes 
                 place also depends on the peer endpoint's capabilities. 
               - "negotiate": Disables the reporting of metrics via this package. 
                 However, the endpoint is REQUIRED to communicate the VoIP metrics 
                 block in the "east-west" direction if the remote end requests it. 
              
            For example, 
             
            L: a:PCMU, xrm/mcr: on 
             
            assigns a value of "on" to the "mcr" LCO. 
                  
            In CreateConnection commands, the xrm/mcr LCO value defaults to 
            "negotiate".  In ModifyConnection commands, the xrm/mcr LCO value 
            Kumar et al            Informational                 Page 6 
            MGCP RTCP-XR Package                             4/12/2007 
            defaults to its current value for the connection.  Thus, if 
            LocalConnectionOptions are either omitted or the xrm/mcr LCO is not 
            included in a ModifyConnection command, the previous xrm/mcr LCO value 
            for the connection is retained. 
             
            An MGCP endpoint supporting this package SHALL always use SDP to 
            request the VoIP metrics block from the remote device if the value of 
            the "xrm/mcr" LCO is set to "on".  However, even if the value of value 
            of the "xrm/mcr" LCO is "on" or "negotiate", the endpoint SHALL NOT 
            send the VoIP metrics block in RTCP Extended Reports (XR) unless the 
            remote  device has requested this block via SDP signaling. Thus, for 
            MGCP endpoints supporting this package, the permission in [RFC 3611] to 
            send RTCP XR blocks in the absence of the "rtcp-xr" SDP attribute is 
            revoked. 
             
            Note that the value of the "xrm/mcr" LCO does not affect the collection 
            or reporting of connection parameters in the connection parameters line 
            (P: line) as defined in the base MGCP specification [RFC 3435]. Nor 
            does it affect the sending of RTCP Sender Reports (SR) and Receiver 
            Reports (RR). An endpoint supporting this package MUST continue to 
            include the connection parameters (P:) line in an audit connection 
            response where this data is requested, in a delete connection response 
            and in a gateway-initiated delete connection. There can be overlap if 
            equivalent parameters are also reported via this package in procedures 
            for the deletion and audit of connections. There is no overlap in the 
            case of modify connection responses since these do not include the 
            connection parameters line. 
             
            2.1.1  Responses to the xrm/mcr local connection option 
             
            This section details the endpoint's response to each of the xrm/mcr LCO 
            values.  
             
            2.1.1.1     Response to a value of "off" 
             
            On receiving this value, the endpoint MUST erase any local or remote 
            VoIP metric data previously collected for the connection, and MUST 
            instruct the far-end device to stop sending RTCP XR VoIP Metrics Report 
            Blocks.  The endpoint MUST ignore an SDP request for metrics and MUST 
            NOT transmit local metrics to the peer  device.  The local endpoint 
            MUST NOT report XR metrics upon receiving or initiating a 
            DeleteConnection sequence and MUST NOT report XR metrics when 
            responding to a ModifyConnection command or an AuditConnection 
            command.  
             
             
             
             
            Kumar et al            Informational                 Page 7 
            MGCP RTCP-XR Package                             4/12/2007 
            2.1.1.2     Response to a value of "on" 
             
            On receiving this value in a CreateConnection or ModifyConnection 
            command, if not already doing so, the endpoint MUST: 
             
               - Start collecting/calculating the metrics which it will expose to 
                 the Call Agent via this package.  
               - Instruct the far-end device to start sending the VoIP Metrics 
                 block in RTCP Extended Reports by including an "rtcp-xr" 
                 attribute with a value of "voip-metrics" in the SDP.   
               - Report local and remote metrics via the XRM/LVM and XRM/RVM lines 
                 defined below in the response to DeleteConnection that targets a 
                 single connection, in the response to a ModifyConnection when 
                 these metrics are requested, in the response to an 
                 AuditConnection when these metrics are audited, and when sending 
                 a DeleteConnection command for a single connection.    
              
            2.1.1.3     Response to a value of "negotiate" 
             
            On receiving this value, the endpoint disables the "northbound" 
            reporting of metrics, via this package,  to the call agent. Also, it 
            sets an internal flag to indicate that it will respond positively to 
            SDP requests by the remote peer device to send the VoIP metrics block 
            in RTCP Extended Reports. 
             
             
            2.1.2  Impact of the xrm/mcr LCO on VoIP metrics block exchange 
             
            This section details the concepts introduced in the previous section 
            regarding the use of the xrm/mcr local connection option to govern the 
            endpoint's behavior regarding the negotiation, via SDP, of the VoIP 
            metrics block in RTCP extended reports [RFC 3611]. 
             
            RFC 3611 adds a new SDP attribute called "rtcp-xr" that can be used by 
            an endpoint to ask the remote  device to send RTCP Extended Reports. 
            This attribute is encoded as follows:   
             
                 rtcp-xr:<xr-format> 
             
            This rtcp-xr attribute can be used as either a session-level or media-
            level attribute. See [RFC 3611] for more information. Only one of  the 
            xr-format values, voip-metrics,  is within the scope of this package.  
             
            For an endpoint supporting this package, the inclusion of the voip-
            metrics value in an rtcp-xr attribute line in its SDP local session 
            descriptions SHALL  be per the following rules: 
             
            Kumar et al            Informational                 Page 8 
            MGCP RTCP-XR Package                             4/12/2007 
               - The voip-metrics value SHALL be included if the xrm/mcr LCO is 
                 set to "on". 
               - The voip-metrics value SHALL NOT be included if the xrm/mcr LCO 
                 is set to "off" or "negotiate". 
             
            The inclusion or exclusion of any other xr-format values (denoting 
            other RTCP XR blocks) in the rtcp-xr SDP attribute line is independent 
            of the xrm/mcr LCO. This is not addressed by this package. 
             
            The response of an endpoint supporting this package to the receipt from 
            a remote peer of an SDP remote session description with an rtcp-xr 
            attribute line that has voip-metrics as one of its values (or its only 
            value) SHALL be as follows: 
             
               - The endpoint MUST send RTCP Extended Reports with the VoIP 
                 metrics block to the remote peer if the xrm/mcr LCO is "on" or 
                 "negotiate". 
               - The endpoint SHALL NOT send RTCP Extended Reports with the VoIP 
                 metrics block to the remote peer if the xrm/mcr LCO is "off". 
             
            Regardless of the value of the xrm/mcr LCO, an endpoint supporting this 
            package SHALL NOT send RTCP Extended Reports with the VoIP metrics 
            block to the remote peer if any of the following is true: 
             
               - The rtcp-xr attribute is not included in the SDP remote session 
                 description. 
               - The rtcp-xr attribute is included in the SDP remote session 
                 description but "voip-metrics" is not one of its values. This 
                 includes the case in which the attribute has an empty parameter 
                 list. 
             
            [RFC 3611] allows endpoints that uses SDP (e.g. MGCP endpoints) to 
            exchange RTCP Extended Reports without prior SDP signaling, which is 
            OPTIONAL. This allowance is rescinded for endpoints supporting this 
            package which MUST implement the SDP signalling specified in this 
            section.  
             
            2.2 MGCP Protocol Procedures  
             
            2.2.1 DeleteConnection Procedures 
             
            These procedures refer to call agent-initiated delete connection 
            commands that are targeted at a specific connection ID and to gateway-
            initiated delete connection commands. They do not apply to call agent-
            initiated delete connection commands that are targeted at all 
            connections associated with a call, an endpoint, an endpoint group or a 
            gateway. In the latter case, the XRM/LVM and XRM/RVM lines (described 
            in detail below) SHALL NOT be returned. 
            Kumar et al            Informational                 Page 9 
            MGCP RTCP-XR Package                             4/12/2007 
             
            Endpoints supporting this package MUST report local metrics in the 
            XRM/LVM parameter line in delete connection responses and in gateway-
            initiated delete connection commands if and only if the local 
            connection option xrm/mcr is set to "on". 
             
            Endpoints supporting this package MUST report remote metrics, if 
            available, in the XRM/RVM parameter line in delete connection responses 
            and in gateway-initiated delete connection commands if and only if the 
            local connection option xrm/mcr is set to "on". 
              
            We do not define a mechanism for suppressing metrics reporting in 
            response to a delete connection command that is targeted at a specific 
            connection ID. In situations (such as a switchover)where the call agent 
            needs to delete connections without retaining any records of the 
            connections, it can use the version of the delete connection procedure 
            that targets all connections associated with a call, an endpoint, an 
            endpoint group or a gateway [RFC 3435]. No metrics are returned in 
            response to this version of the delete connection command. 
             
            2.2.2 AuditConnection Procedures 
             
            This package defines two new RequestedInfo values to be used with an 
            AuditConnection (AUCX).  These allow a call agent to explicitly request 
            that the endpoint return the current values of either the local or 
            remote metrics. The request does not reset the values.  When one or 
            both of these RequestedInfo values are included in an AUCX command, the 
            endpoint MUST return the appropriate metric values if available.   The 
            two new RequestedInfo values are: 
             
                   XRM/LVM       Return the local voice metric values. 
                   XRM/RVM       Return the remote voice metric values. 
             
             
            The call agent MAY audit the local and remote voice metrics at any 
            time. Some example uses of this capability are: 
             
            - Audits in response to a "quality alert" event notification                    
              [RFC 3660], 
            - Audits in response to an event notification that MAY lead to               
              a media transition e.g. a fax tone event ('ft') or a modem tone  
              event ('mt') [RFC 3660]. 
            - Audits in response to an event notification of a media transition             
              e.g. the start of a gateway-controlled fax procedure  
              {fxr/gwfax(start)} [FAX PKG]. 
             
            A quality alert event notification MAY be sent in response to a metrics 
            threshold crossing by an endpoint supporting the RTP package defined in 
            Kumar et al            Informational                Page 10 
            MGCP RTCP-XR Package                             4/12/2007 
            RFC 3660. When audited within a time window T1 after sending a quality 
            alert, the endpoint SHOULD respond with metrics captured at the time of 
            the threshold crossing rather than metrics captured in response to the 
            associated metrics audit request.  
             
            In the case of events that MAY lead to a media state transition (e.g. 
            voice to voice band data or fax relay), the endpoint SHOULD respond to 
            a metrics audit received within a time window of T1 with metrics 
            captured just prior to the event notification rather than at the time 
            of the audit.  In the case of events that report a media state 
            transition, the endpoint SHOULD respond to a metrics audit received 
            within a time window of T1 with metrics captured just prior to the 
            state transition rather than at the time of the audit. Naturally, the 
            reported values are captured prior to any parameter reset ensuing from 
            the media state change.  
             
            A value of five seconds is RECOMMENDED for the time window, T1, used to 
            associate an event notification with a metrics audit. However, the 
            value of this window depends on the application. Although not 
            RECOMMENDED, an endpoint MAY automatically associate a metrics audit 
            request with a prior relevant event notification, if any, regardless of 
            the time-lag between the two. 
             
            The rules in the MGCP base specification [RFC 3435] for handling audits 
            of unsupported parameters and parameters for which an endpoint has no 
            values MUST be followed. As a result: 
             
               - If an endpoint that does not understand the XRM/LVM or XRM/RVM 
                 parameter is audited for that parameter, it MUST NOT generate an 
                 error. Instead, the parameter MUST be omitted from the audit 
                 response. Since this rule is based on the MGCP base 
                 specification, it also applies to endpoints that do not support 
                 this package. 
               - If an endpoint that does not have values for the XRM/LVM or 
                 XRM/RVM parameter is audited for that parameter, it MUST NOT 
                 generate an error. Instead, the parameter MUST be included in the 
                 audit response with an empty value. 
             
            2.2.3 ModifyConnection Procedures 
             
            This package defines a new MGCP parameter, the MediaMetricsOption 
            ("MMO") that MAY be OPTIONALly included in a ModifyConnection command 
            on an "XRM/MMO" line. This parameter is forbidden in all other MGCP 
            commands and responses. It can have one of the following four values: 
             
            -    "REP" (report). This option commands the endpoint to report local 
            and remote metrics via this package. Local and remote session 
            parameters MAY also be reported. 
            Kumar et al            Informational                Page 11 
            MGCP RTCP-XR Package                             4/12/2007 
            -    "RES" (reset). This option commands the endpoint to reset the 
            local and remote metrics.   
            -    "RR" (report and reset). Local and remote metrics are first 
            reported and then reset. Local and remote session parameters MAY also 
            be reported. 
            -    "NULL". No metrics (local or remote) are reset or reported. This 
            value is equivalent to omitting the "XRM/MMO" line in the 
            ModifyConnection command. Of course, it is more efficient and, 
            therefore, preferable to omit the XRM/MMO line than to use it with an 
            explicit value of "NULL".  
             
            Note that the XRM/MMO parameter is specific to a ModifyConnection 
            command and its value does not persist following the end of a 
            ModifyConnection procedure. Therefore, this package does not define a 
            RequestedInfo value for auditing the XRM/MMO parameter.  
             
            Also note that metrics are not reported in response to a "REP" or "RR" 
            value of the XRM/MMO parameter if the value of the XRM/MCR local 
            connection option is "off" or "negotiate".    
             
            When the value of the XRM/MMO parameter is REP or RR, then the 
            available metrics are reported, as applicable,  in the XRM/LVM and 
            XRM/RVM lines defined below. In order to comply with the ABNF rules in 
            [RFC 3435], the connection parameters line (the P: line) SHALL NOT be 
            included in a ModifyConnection response. However, metrics equivalent to 
            the connection parameters (Table 2) can be included in the XRM/LVM and 
            XRM/RVM lines. 
             
            The metrics that are reset and/or reported in response to the XRM/MMO 
            parameter include metrics associated with RTCP extended reports (Table 
            1) and metrics associated with RTCP sender reports and receiver reports 
            (Table 2).  
             
            See the section titled "Procedures for the resetting of metrics" for 
            the values assigned to metrics on reset. 
             
            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. It is also useful in 
            situations in which the call agent choreographs a media state 
            transition such as from voice to voice band data [ITU V.152] or fax 
            relay [ITU T.38].  
             
            2.3 The LVM and RVM Lines for reporting Local And Remote Metrics 
             
            The "XRM/LVM" and "XRM/RVM" lines are for the reporting of local and 
            remote metrics respectively. For example, an endpoint that is recording 
            Kumar et al            Informational                Page 12 
            MGCP RTCP-XR Package                             4/12/2007 
            local metrics and has received remote metrics returns the following 
            lines in a DLCX response: 
             
                 XRM/LVM: PLC=1, JBA=2, JBR=7 ... 
                 XRM/RVM: PLC=0, JBA=0, JBR=3 ... 
             
            The parameters that MAY be reported in an XRM/LVM or XRM/RVM line fall 
            into the following categories: 
             
               - Parameters that define the metrics computation interval and 
                 indicate whether any metrics resets have occurred since session 
                 start. These are listed in Table 1.  
               - Parameters based on the VoIP metrics block [RFC 3611]. These are 
                 listed in Table 1. 
               - Parameters based on Sender Reports and Receiver Reports [RFC 
                 3550]. These are listed in Table 2. 
               - Parameters that describe the session. These are listed in Table 
                 3. Many of these are based on SDP parameters such as those 
                 specified in RFC 2327, RFC 2198, RFC 2733 etc. 
             
            Although Tables 1-3 include top-level definitions of these parameters, 
            some of their technical details MAY need to gleaned from the 
            references. For instance, the meaning of "standard" vs. "enhanced" 
            packet loss concealment must be obtained from [RFC 3611]. 
             
            Note that the rationale for allowing the reporting of parameters based  
            on RTCP Sender Reports and Receiver Reports (Table 2) in the XRM/LVM 
            and XRM/RVM lines is two-fold: 
             
               - The connection parameters line (the P: line) in the MGCP base 
                 protocol [RFC 3435] does not address remote metrics, 
               - The ABNF for packet loss in RFC 3435 is inconsistent with its RFC 
                 3550-based textual definition of packet loss.  
             
            Note that the latency metric in the connection parameters line (the P: 
            line) is not included in Table 2 since it is already included in the 
            RTCP XR VoIP metrics block as the round trip delay. RTCP XR [RFC 3611] 
            allows any method for its computation, including methods based on [RFC 
            3550]  or on the DLRR report block in [RFC 3611]. 
             
            2.3.1 Inclusion/Omission of XRM/LVM and XRM/RVM parameters 
             
            In general,  the inclusion of a parameter from Tables 1-3 in the 
            XRM/LVM or XRM/RVM lines is subject to: 
             
               - The availability of the parameter. 
               - Local policy regarding its inclusion. 
             
            Kumar et al            Informational                Page 13 
            MGCP RTCP-XR Package                             4/12/2007 
            The following rules apply only to endpoints supporting this package: 
             
            DLCX/MDCX/AUCX rule for XRM/LVM: This rule applies to: (i) Endpoint 
            responses to call agent-initiated delete connection commands that are 
            targeted at a specific connection ID, (ii) Endpoint-initiated delete 
            connection commands, (iii) Endpoint responses to modify connection 
            commands that request session metrics via the XRM/MMO line, (iv) 
            Endpoint responses to audit connection commands that include "XRM/LVM" 
            in the RequestedInfo list. In each of these contexts, the XRM/LVM line 
            MUST be included by an endpoint supporting this package. Further, this 
            endpoint MUST compute at least one metric from the VoIP metrics block 
            (Table 1) and report it in the XRM/LVM line. All other parameters 
            (Tables 2 and 3) are completely OPTIONAL. Their inclusion depends on 
            local policy. The endpoint MUST omit all parameters that are not 
            computed locally rather than include them with dummy values (e.g. 127 
            for the various MOS parameters). 
             
            DLCX/MDCX rule for XRM/RVM: This rule applies to: (i) Endpoint 
            responses to call agent-initiated delete connection commands that are 
            targeted at a specific connection ID, (ii) Endpoint-initiated delete 
            connection commands, (iii) Endpoint responses to modify connection 
            commands that request session metrics via the XRM/MMO line. In each of 
            these contexts, the XRM/RVM line MUST be included if the remote peer 
            sends VoIP metrics blocks [RFC 3611] in RTCP Extended Reports. If the 
            remote  device indicates that a particular VoIP metrics block parameter 
            is unavailable by sending a dummy value, then the dummy value MUST be 
            reported  or the parameter MUST be omitted from the XRM/RVM: line. For 
            example, the dummy value of 127, if used,  indicates that the signal 
            level, noise level, residual echo return loss, the various R-factors 
            and MOS estimates are unavailable. If the VoIP metrics block is not 
            received from the remote device, the endpoint MAY omit the XRM/RVM line 
            even if it has non-VoIP metrics block parameters to report in the 
            XRM/RVM line, such as metrics communicated via RTCP Sender Reports (SR) 
            and Receiver Reports (RR). The endpoint MAY, of course, include the 
            XRM/RVM line with known non-VoIP metrics block parameters (Tables 2 and 
            3) when the VoIP metrics block is not communicated by the remote end. 
            If the remote device indicates that a particular Sender/Receiver Report 
            parameter is unavailable by assigning it a dummy value (such as an 
            inter-arrival jitter of 0), the endpoint MAY either omit it in the 
            XRM/RVM line or assign it a dummy value. 
             
            AUCX rule for XRM/RVM: This rule applies to endpoint responses to audit 
            connection commands that include "XRM/RVM" in the RequestedInfo list. 
            In this context, the XRM/RVM line MUST be included even if no VoIP 
            metrics blocks are received in RTCP extended reports from the remote 
            device. This line MAY, however, be empty if no data pertaining to RTCP 
            XR VoIP metrics block (Table 1) is provided by the remote  device. 
            Alternately, the local endpoint MAY include other known remote 
            Kumar et al            Informational                Page 14 
            MGCP RTCP-XR Package                             4/12/2007 
            parameters  (Tables 2 and 3) in the XRM/RVM line. If the remote device 
            sends the VoIP metrics block in RTCP Extended Reports and indicates 
            that a particular parameter is unavailable by sending a dummy value, 
            then the dummy value MUST be reported  or the parameter MUST be omitted 
            from the XRM/RVM: line. If the remote device indicates that a 
            particular Sender/Receiver Report parameter is unavailable by assigning 
            it a dummy value (such as an inter-arrival jitter of 0), the endpoint 
            MAY either omit it in the XRM/RVM line or assign it a dummy value. 
             
            Rule for disallowed values: An endpoint receiving a disallowed value in 
            the VoIP metrics block MAY omit it in the XRM/RVM line. For example, 
            RFC 3611 does not allow a value of 60 in the 8-bit MOS-LQ field in the 
            VoIP metrics block. 
              
            2.3.2 XRM/LVM and XRM/RVM parameter values 
             
            The metrics used in the XRM/LVM and XRM/RVM lines (Tables 1-3) are, 
            except when otherwise noted, cumulative/average values over a 
            computation interval. This interval MAY be indicated via the OPTIONAL 
            computation interval (CMPI) parameter in Table 1. The CMPI parameter 
            indicates the period of time over which the XRM/LVM and XRM/RVM 
            parameters are computed. When the CMPI parameter is omitted, the 
            computation interval SHALL be defined as the period from the last 
            metrics reset (if any) up to the time of metrics reporting. If the CMPI 
            parameter is omitted and there has been no metrics reset, then the 
            computation interval SHALL be defined as the period from the start of 
            the session up to the time of metrics reporting. 
             
            The procedures for communicating voice quality metrics in the XRM/LVM 
            and XRM/RVM lines are invoked at one of the following instances: 
             
            - the DeleteConnection procedures are invoked end of a session, 
             
            - the ModifyConnection procedures are invoked end of a call phase,  
              such as when a call transfer is invoked or when the call agent  
              effects a media state transition (e.g. voice to voice band data) 
               
            - the AuditConnection procedures MAY be invoked whenever the call  
              agent needs a snapshot of the metrics. For instance, these  
              procedures MAY be invoked in response to event notifications from  
              the endpoint. Examples from RFC 3660 of such event notifications  
              are tone events ('ft' and 'mt') and quality alerts ('qa'). 
             
            The general use is to not use the CMPI parameter for these procedures 
            and to reports metrics accumulated/averaged from the start of the 
            session or from the time of the last metrics reset, as applicable. One 
            exception where an explicit computation interval, conveyed via CMPI, is 
            RECOMMENDED is when the XRM/RVM lines are communicated in response to 
            Kumar et al            Informational                Page 15 
            MGCP RTCP-XR Package                             4/12/2007 
            an audit connection that is associated per Section 2.2.2 with a quality 
            alert ('qa') event. In this case, the metrics values of interest are 
            those that pertain to some short interval (e.g. 1-5 seconds) 
            immediately before the threshold crossing occurrence. 
             
            The OPTIONAL Reset Occurrences ("ROC") parameter is useful in 
            indicating whether a prior reset of metrics has occurred. Although some 
            resets are commanded by the call agent via ModifyConnection procedures, 
            the endpoint is not precluded from autonomously resetting its  VoIP 
            metrics. For example, the endpoint MAY reset its metrics when it 
            changes the mode of a media stream (e.g. from voice to voice band 
            data). Since such autonomous resets are not universally implemented, it 
            is beneficial to explicitly indicate their occurrence. For example, 
            ROC=1 in conjunction with an omitted CMPI parameter indicates that the 
            reported metrics have been accumulated/averaged for just the current 
            call phase and not for the entire call duration. 
             
            It is RECOMMENDED that the unstable or indeterminate periods at the 
            start and end of a call or call phase be factored out of metrics 
            computation. The duration of these guard bands is left to the 
            implementation. 
             
            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%. 
             
              
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 16 
            MGCP RTCP-XR Package                             4/12/2007 
            TABLE 1: PARAMETERS BASED ON THE RTCP XR VOIP METRICS BLOCK 
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |Computation | CMPI |The period, in milliseconds, from  | 
            |Interval    |      |the start of metrics computation to| 
            |            |      |the time of metrics capture for    | 
            |            |      |reporting purposes. This parameter | 
            |            |      |MAY be omitted. A value of 0 is    | 
            |            |      |equivalent to its omission.        | 
            |            |      |Expressed as an integer number.    | 
            --------------------------------------------------------- 
            |Reset       | ROC  |Whether the metrics have been      | 
            |Occurrences |      |one or more times since session    | 
            |            |      |start. Expressed as a boolean with | 
            |            |      |"1" indicating one or more resets  | 
            |            |      |and "0" indicating the absence of  | 
            |            |      |of resets. These resets MAY be     | 
            |            |      |commanded by the call agent, or    | 
            |            |      |autonomously triggered by the      | 
            |            |      |endpoint. This parameter is        | 
            |            |      |OPTIONAL and MAY be omitted. Its   | 
            |            |      |omission does not imply anything   | 
            |            |      |regarding the occurrence of        | 
            |            |      |metrics resets.                    | 
            ---------------------------------------------------------  
            |Network     | NLR  |The proportion of packets lost     | 
            |packet loss |      |since the start of metrics         | 
            |rate        |      |computation expressed as an 8-bit  | 
            |            |      |binary fraction obtained by        | 
            |            |      |dividing the number of packets lost| 
            |            |      |in the transmission path by the    | 
            |            |      |total number of packets expected by| 
            |            |      |the receiver, multiplying this     | 
            |            |      |value by 256 and taking the integer| 
            |            |      |portion of the result. Computed    | 
            |            |      |after taking any loss mitigation   | 
            |            |      |due to FEC and/or redundancy into  | 
            |            |      |account. The numbers of duplicated | 
            |            |      |packets and discarded packets do   | 
            |            |      |not enter into this calculation.   |    
            --------------------------------------------------------- 
                               
            Kumar et al            Informational                Page 17 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |Jitter      |JDR   |The proportion of the packets      | 
            |buffer      |      |discarded by the receiving         | 
            |discard     |      |jitter buffer since the start of   | 
            |rate        |      |metrics computation expressed as an| 
            |            |      |8-bit binary fraction obtained by  | 
            |            |      |dividing the number of packets     | 
            |            |      |discarded by the jitter buffer     | 
            |            |      |by the total number of packets     | 
            |            |      |expected by the receiver,          | 
            |            |      |multiplying this value by 256      | 
            |            |      |and taking the integer portion     | 
            |            |      |of the result. Computed            | 
            |            |      |after taking any loss mitigation   | 
            |            |      |due to FEC and/or redundancy into  | 
            |            |      |account. The number  of duplicate  | 
            |            |      |packet discards does not enter     | 
            |            |      |into this calculation.             |                         
            --------------------------------------------------------- 
            |Burst loss  | BLD  |The average proportion (since the  | 
            |density     |      |start of metrics computation) of   |  
            |            |      |lost and discarded packets         | 
            |            |      |occurring during burst periods     | 
            |            |      |expressed as an 8 bit              | 
            |            |      |binary fraction obtained by        |   
            |            |      |dividing the sum of the number of  | 
            |            |      |packets detected as lost during    | 
            |            |      |burst periods and the number of    | 
            |            |      |packets discarded by the jitter    | 
            |            |      |buffer during burst periods by     | 
            |            |      |the total number of packets        | 
            |            |      |expected by the receiver,          |                     
            |            |      |multiplying this value by 256      | 
            |            |      |and taking the integer portion     | 
            |            |      |of the result.  Computed           | 
            |            |      |after taking any loss mitigation   | 
            |            |      |due to FEC and/or redundancy into  | 
            |            |      |account. Duplicate packet discards | 
            |            |      |are excluded from this computation.|                 
            --------------------------------------------------------- 
             
             
             
             
             
            Kumar et al            Informational                Page 18 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | 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.  Computed           | 
            |            |      |after taking any loss mitigation   | 
            |            |      |due to FEC and/or redundancy into  | 
            |            |      |account. Duplicate packet discards | 
            |            |      |are excluded from this computation.|                   
            --------------------------------------------------------- 
            |Burst       |BD    |The average duration of the burst  | 
            |duration    |      |periods, in milliseconds. Computed | 
            |            |      |from the start of metrics          | 
            |            |      |computation. Bursts are determined | 
            |            |      |after taking any loss mitigation   | 
            |            |      |due to FEC and/or redundancy into  | 
            |            |      |account.                           | 
            --------------------------------------------------------- 
            |Gap         |GD    |The average duration of the gap    | 
            |duration    |      |periods, in milliseconds. Computed | 
            |            |      |from the start of metrics          | 
            |            |      |computation. Bursts are determined | 
            |            |      |after taking any loss mitigation   | 
            |            |      |due to FEC and/or redundancy into  | 
            |            |      |account.                           | 
            --------------------------------------------------------- 
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 19 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |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   of  | 
            |            |      |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.| 
            --------------------------------------------------------- 
            |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 metric SHALL be averaged      | 
            |            |      |from the start of metrics          | 
            |            |      |computation. A value of 127        |                        
            |            |      |indicates that the parameter is    | 
            |            |      |unavailable.                       | 
            --------------------------------------------------------- 
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 20 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |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 without | 
            |            |      |a +ve or -ve sign. No sign is      | 
            |            |      |necessary since this value MUST be | 
            |            |      |equal to or less than 0 dB. A value| 
            |            |      |of 127 indicates that the parameter| 
            |            |      |is unavailable. A +ve or -ve sign, | 
            |            |      |if used, SHALL be ignored.         | 
            |            |      |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    | 
            |            |      |a positive integer without a       |  
            |            |      |negative sign. A value of 127      | 
            |            |      |indicates that the parameter is    | 
            |            |      |unavailable. Thus, RERL=23         | 
            |            |      |indicates an echo loss of 23 dB    | 
            |            |      |after factoring in any echo        | 
            |            |      |cancellation. This metric SHALL be | 
            |            |      |averaged from the start of metrics | 
            |            |      |computation.                       | 
            --------------------------------------------------------- 
            |Minimum gap |GMN   | The gap/burst transition          | 
            |threshold   |      | threshold; the RECOMMENDED value  | 
            |            |      | is 16. Values in the range 1 -                                                       -    | 
            |            |      | 255 are permitted.                | 
            --------------------------------------------------------- 
             
             
             
             
             
             
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 21 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |R-factor    |NSR   | Conversational quality            | 
            |(Conversat- |      | R-factor for the "inner segment", | 
            |-ional      |      | of the call, which is the VoIP    |  
            |quality)    |      | session on which                  | 
            |            |      | the endpoint resides. This value  | 
            |            |      | represents the conversational     | 
            |            |      | quality of the RTP session        |  
            |            |      | calculated per ITU G.107. Valid   | 
            |            |      | values are greater than 0 and     | 
            |            |      | less than or equal to 120. A      | 
            |            |      | value of 127 indicates that the   | 
            |            |      | parameter is unavailable. This    | 
            |            |      | parameter is computed from the    | 
            |            |      | start of metrics computation.     |   
            |            |      | When the term 'R-factor' is used  | 
            |            |      | without further qualification,    | 
            |            |      | this parameter is implied.        |       
            --------------------------------------------------------- 
            |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. A      | 
            |            |      | value of 127 indicates that the   | 
            |            |      | parameter is unavailable.  This   | 
            |            |      | parameter is computed from the    | 
            |            |      | start of metrics computation.     | 
            --------------------------------------------------------- 
            |External    |XSR   | Listening quality R-factor for an | 
            |R-factor    |      | "external segment" which is any   | 
            |            |      | call segment external to the VoIP | 
            |            |      | session on which the endpoint     | 
            |            |      | resides. This value is            | 
            |            |      | calculated per ITU-T              | 
            |            |      | Recommendation G.107.  Valid      | 
            |            |      | values are greater than 0 and     |         
            |            |      | less than or equal to 120. A      | 
            |            |      | value of 127 indicates that the   | 
            |            |      | parameter is unavailable. This    | 
            |            |      | parameter is computed from the    | 
            |            |      | start of metrics computation.     | 
            --------------------------------------------------------- 
            Kumar et al            Informational                Page 22 
            MGCP RTCP-XR Package                             4/12/2007 
             
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |Estimated   |MLQ   | An estimated  receiving end       | 
            |MOS-LQ      |      | listening quality MOS. The        | 
            |            |      | nominal range of MOS scores is    | 
            |            |      | 1-5. Before being expressed in    | 
            |            |      | MGCP, the MOS score is            | 
            |            |      | multiplied by 10 and any          | 
            |            |      | fractional part is truncated.     | 
            |            |      | This results in an integer with   | 
            |            |      | valid values in the range 10 - 50.| 
            |            |      | A value of 127 indicates that     | 
            |            |      | the parameter is unavailable.     | 
            |            |      | This parameter is computed from   | 
            |            |      | the start of metrics computation. | 
            --------------------------------------------------------- 
            |Estimated   |MCQ   | An estimated receiving end        | 
            |MOS-CQ      |      | conversational quality MOS. The   | 
            |            |      | nominal range of MOS scores is    | 
            |            |      | 1-5. Before being expressed in    | 
            |            |      | MGCP, the MOS score is            | 
            |            |      | multiplied by 10 and any          | 
            |            |      | fractional part is truncated.     | 
            |            |      | This results in an integer with   | 
            |            |      | valid values in the range 10 - 50.|  
            |            |      | A value of 127 indicates that     | 
            |            |      | the parameter is unavailable.     | 
            |            |      | 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                | 
            --------------------------------------------------------- 
             
             
             
             
             
             
            Kumar et al            Informational                Page 23 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |Jitter      |JBA   | The adaptability of the jitter    | 
            |Buffer      |      | buffer.  Should be one of the     | 
            |Adaptability|      | following enumeration values:     | 
            |            |      |       0 - Unknown                 | 
            |            |      |       1 - Reserved                | 
            |            |      |       2 - Non-adaptive            | 
            |            |      |       3 - Adaptive                | 
            --------------------------------------------------------- 
            |Jitter      |JBR   | The jitter buffer adjustment      | 
            |Buffer      |      | rate.  Value is between 0 and     | 
            |Rate        |      | 15.                               | 
            --------------------------------------------------------- 
            |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.                          | 
            --------------------------------------------------------- 
            |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.                            | 
            --------------------------------------------------------- 
             
             
            Kumar et al            Informational                Page 24 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter  | Code | Value                             | 
            |            |      |                                   | 
            --------------------------------------------------------- 
            |MOS-LQ      |MLES  | Algorithm used to estimate the    | 
            |Estimation  |      | the MOS-LQ metric, MLQ. This      | 
            |Algorithm   |      | is expressed as a human-readable  | 
            |            |      | character string with an          | 
            |            |      | unrestricted set of values.       | 
            --------------------------------------------------------- 
            |MOS-CQ      |MCES  | Algorithm used to estimate the    | 
            |Estimation  |      | the MOS-CQ metric, MCQ. This      | 
            |Algorithm   |      | is expressed as a human-readable  | 
            |            |      | character string with an          | 
            |            |      | unrestricted set of values.       | 
            --------------------------------------------------------- 
            |R-factor    |RFES  | Algorithm(s) used to estimate     | 
            |Estimation  |      | the one or more R-factors         | 
            |Algorithm(s)|      | reported. This is expressed as a  | 
            |            |      | human-readable character string   | 
            |            |      | with an unrestricted set of       | 
            |            |      | values. This string MAY contain   | 
            |            |      | separate descriptions for the     | 
            |            |      | algorithms pertaining to the      | 
            |            |      | R-factors NSR, MLQ and XSR        | 
            |            |      | described above.                  | 
            --------------------------------------------------------- 
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 25 
            MGCP RTCP-XR Package                             4/12/2007 
            TABLE 2: PARAMETERS BASED ON RTCP SENDER AND RECEIVER REPORTS 
            --------------------------------------------------------- 
            | Parameter   | Code | Value                            | 
            |             |      |                                  | 
            --------------------------------------------------------- 
            |Packets sent |PS    | The number of packets that were  | 
            |             |      | were sent on the connection since| 
            |             |      | the start of metrics computation.| 
            |             |      | Does not include any FEC packets | 
            |             |      | sent on a different SSRC or port.| 
            --------------------------------------------------------- 
            |Octets sent  |OS    | The number of payload octets that| 
            |             |      | were sent out on the connection  | 
            |             |      | since the start of metrics       | 
            |             |      | computation. Header and padding  | 
            |             |      | octets are not included. Nor are | 
            |             |      | octets in redundant or FEC       | 
            |             |      | payloads/packets.                | 
            --------------------------------------------------------- 
            |Packets      |PR    | The number of packets that were  | 
            |received     |      | were received on the connection  | 
            |             |      | since the start of metrics       | 
            |             |      | computation. Does not include any| 
            |             |      | FEC packets received on a        | 
            |             |      | different SSRC or port.          | 
            --------------------------------------------------------- 
            |Octets       |OR    | The number of payload octets that| 
            |received     |      | were received on the             | 
            |             |      | connection since the start of    | 
            |             |      | metrics computation. Header and  | 
            |             |      | padding octets are not included. | 
            |             |      | Nor are octets in redundant or   | 
            |             |      | FEC payloads/packets.            | 
            --------------------------------------------------------- 
            Kumar et al            Informational                Page 26 
            MGCP RTCP-XR Package                             4/12/2007 
             
            --------------------------------------------------------- 
            | Parameter   | Code | Value                            | 
            |             |      |                                  | 
            --------------------------------------------------------- 
            |Packets      |PL    | The total number of media packets| 
            |lost         |      | that have been lost since the    | 
            |             |      | beginning of metrics computation.| 
            |             |      | This is defined to be the number | 
            |             |      | of packets expected less the     | 
            |             |      | number of packets actually       | 
            |             |      | received, where the number of    | 
            |             |      | packets received includes any    | 
            |             |      | which are late or duplicates.    | 
            |             |      | Thus packets that arrive late are| 
            |             |      | not counted as lost, and the loss| 
            |             |      | MAY be negative if there are     | 
            |             |      | duplicates. This metric does not | 
            |             |      | take any loss mitigation due to  | 
            |             |      | redundancy or FEC into account.  | 
            --------------------------------------------------------- 
            |Inter-       |IAJ   | Per [RFC 3550], the inter-arrival| 
            |arrival      |      | jitter is defined to be          | 
            |jitter       |      | the mean deviation (smoothed     | 
            |             |      | absolute value) of the difference|               
            |             |      | in packet spacing at the         | 
            |             |      | the receiver compared to the     |                
            |             |      | sender for a pair of packets.    | 
            |             |      | This metric is averaged from the | 
            |             |      | start of computation and is      | 
            |             |      | expressed in milliseconds.       | 
            |             |      | The corresponding connection     | 
            |             |      | parameter in  [RFC 3435] is JI.  | 
            --------------------------------------------------------- 
             
             
             
             
             
             
             
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 27 
            MGCP RTCP-XR Package                             4/12/2007 
            TABLE 3: SESSION DESCRIPTION PARAMETERS 
            --------------------------------------------------------- 
            | Parameter   | Code | Value                            | 
            |             |      |                                  | 
            --------------------------------------------------------- 
            |SSRC         |SSRC  | SSRC of the measured stream.     | 
            |             |      | If it changes due to a collision,| 
            |             |      | the last value is used.          | 
            |             |      | Represented as the decimal       | 
            |             |      | equivalent of a 32-bit word.     | 
            --------------------------------------------------------- 
            |Source IP    |IPAS  | The source IP address for        | 
            |address      |      | the stream under measurement     | 
            --------------------------------------------------------- 
            |Source IP    |IPTS  | This indicates whether the source| 
            |address type |      | IP address is IP version 4 or 6. |  
            --------------------------------------------------------- 
            |Destination  |IPAD  | The destination IP address for   | 
            |IP address   |      | the stream under measurement.    | 
            --------------------------------------------------------- 
            |Destination  |IPTD  | This indicates whether the       | 
            |IP address   |      | destination IP address is        | 
            |type         |      | IP version 4 or 6.               |  
            --------------------------------------------------------- 
            |Source       |RTUS  | The source RTP/UDPTL port for    | 
            |RTP/UDPTL    |      | the stream under measurement.    | 
            |port         |      |                                  | 
            --------------------------------------------------------- 
            |Destination  |RTUD  | The destination RTP/UDPTL port   | 
            |RTP/UDPTL    |      | for the stream under measurement| 
            |port         |      |                                  | 
            --------------------------------------------------------- 
            |Source       |RTCS  | The source RTCP port for         | 
            |RTCP port    |      | the stream under measurement.    |  
            --------------------------------------------------------- 
            |Destination  |RTCD  | The destination RTCP port for    | 
            |RTCP port    |      | the stream under measurement.    |  
            --------------------------------------------------------- 
            |Codec        |VCD   | The last voice or voice band data|  
            |(voice or    |      | codec used. This is expressed    | 
            |voice band   |      | as a character string            | 
            |data)        |      | corresponding to a MIME subtype  | 
            |             |      | from [IANA RTP] (e.g. " G726-40")| 
            |             |      | or as an experimental codec name | 
            |             |      | starting with "X-".              | 
            --------------------------------------------------------- 
             
             
            Kumar et al            Informational                Page 28 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter   | Code | Value                            | 
            |             |      |                                  | 
            --------------------------------------------------------- 
            |Secondary    |VCDS  | In the case of RFC 2198          | 
            |codec        |      | redundancy, the secondary codec  | 
            |(voice or    |      | used. Semantics identical to     | 
            |voice band   |      | primary codec. (See VCD parameter|                 
            |data)        |      | above.)                          | 
            --------------------------------------------------------- 
            |Media        |MMOD  | This indicates whether the       | 
            |Mode         |      | the media carried by the session | 
            |             |      | is audio ("a"), voice band data  | 
            |             |      | ("v"), fax relay ("f"), modem    | 
            |             |      | relay ("m") or text relay ("t"). | 
            |             |      | The last mode is indicated by    | 
            |             |      | this parameter. Audio and text   |  
            |             |      | relay packets MAY be interleaved | 
            |             |      | in the text relay mode.          | 
            |             |      | Voice band data, fax relay, modem| 
            |             |      | relay and text relay are defined | 
            |             |      | in [ITU V.152], [ITU T.38],      | 
            |             |      | [ITU V.150.1] and [ITU V.151]    | 
            |             |      | respectively. All of these media,| 
            |             |      | with the exception of modem      | 
            |             |      | relay, can be transported via    | 
            |             |      | RTP.                             |       
            --------------------------------------------------------- 
            |Sample rate  |SMPL  | The rate at which media is       | 
            |(voice or    |      | is sampled (samples per second)  | 
            |voice band   |      | for the last voice or voice band | 
            |data)        |      | data codec used.                 | 
            --------------------------------------------------------- 
            |Codec frame  |FRSZ  | The number of octets in a codec  | 
            |size         |      | frame for the last voice or      |                      
            |(voice or    |      | voice band data codec.           | 
            |voice band   |      |                                  | 
            |data)        |      |                                  | 
            --------------------------------------------------------- 
            |RTP payload  |PLSZ  | The number of octets in a the RTP| 
            |size         |      | packet payload for the           | 
            |(voice or    |      | last voice or voice band data    | 
            |voice band   |      | codec used.                      | 
            |data)        |      |                                  | 
            --------------------------------------------------------- 
             
             
             
            Kumar et al            Informational                Page 29 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter   | Code | Value                            | 
            |             |      |                                  | 
            --------------------------------------------------------- 
            |Packetization|PKRT  | The number of RTP packets per    | 
            |rate         |      | second for the last voice or     | 
            |(voice or    |      | voice band data codec used.      | 
            |voice band   |      |                                  | 
            |data)        |      |                                  | 
            --------------------------------------------------------- 
            |Silence      |SSUP  | This indicates whether silence   | 
            |Suppression  |      | suppression, also known as Voice | 
            |State        |      | Activity Detection (VAD)is       | 
            |             |      | enabled. The last value is used. |  
            |             |      | It is assumed that silence       | 
            |             |      | suppression is accompanied by    | 
            |             |      | comfort noise generation.        |                   
            --------------------------------------------------------- 
            |Echo         |ECAN  | This indicates whether echo      | 
            |Cancellation |      | cancellation is enabled. The last| 
            |State        |      | value is used.                   | 
            --------------------------------------------------------- 
            |Redundancy   |VRED  | This indicates whether           |  
            |State        |      | redundancy [RFC 2198] was used   |      
            |(voice or    |      | for the last voice or voice band |  
            |voice band   |      | data codec.                      | 
            |data).       |      |                                  | 
            --------------------------------------------------------- 
            |FEC State    |VFEC  | This indicates whether           | 
            |(voice or    |      | Forward Error Correction         | 
            |voice band   |      | [RFC 2733] was used for the last | 
            |data).       |      | voice or voice band data codec.  | 
            |             |      | RFC 2733 FEC MAY be used in      | 
            |             |      | conjunction with RFC 2198        |  
            |             |      | redundancy.                      | 
            --------------------------------------------------------- 
            |SSRC of the  |FSRC  | SSRC of the received FEC stream, | 
            |received FEC |      | if any. If it changes due to a   | 
            |stream       |      | collision, the last value is     | 
            |             |      | used. Represented as the decimal | 
            |             |      | equivalent of a 32-bit word.     | 
            --------------------------------------------------------- 
             
             
             
             
             
             
            Kumar et al            Informational                Page 30 
            MGCP RTCP-XR Package                             4/12/2007 
            --------------------------------------------------------- 
            | Parameter   | Code | Value                            | 
            |             |      |                                  | 
            --------------------------------------------------------- 
            |Destination  |IPAF  | The destination IP address for   | 
            |IP address   |      | the FEC stream received with the | 
            |for FEC      |      | RTP media stream. Identical to   |  
            |             |      | IPAD (above) if the FEC stream   |                               
            |             |      | is sent to the same              | 
            |             |      | IP address as the media          | 
            |             |      | stream under measurement. In     | 
            |             |      | either case, the IP address type | 
            |             |      | is per the IPTD parameter above. |                 
            --------------------------------------------------------- 
            |Destination  |RTFD  | The destination RTP port for any | 
            |RTP port     |      | FEC stream received with the RTP | 
            |for FEC      |      | media stream. Identical to       |  
            |             |      | RTUD (above) if the FEC stream   |                               
            |             |      | is sent to the same              | 
            |             |      | RTP port as the media            | 
            |             |      | stream under measurement.        | 
            --------------------------------------------------------- 
             
            2.3.3 Procedures for the resetting of metrics 
             
            The metrics associated with the XRM/LVM and XRM/RVM lines MAY be 
            reset/reinitialized in response to the XRM/MMO parameter in a 
            ModifyConnection command from the call agent, or autonomously by the 
            endpoint when a media state transition (e.g. from voice to voice band 
            data) occurs. 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 impact of reset depends on the semantics of each individual 
            parameter. In general, the following actions are taken during metrics 
            reset: 
             
            - All counters are set to 0. 
            - Measurements that are not counts are set to an unknown value.  
              For example, 127 indicates an unknown value for the signal level,  
              noise level, RERL, the various R-factors and MOS estimates. 
              Further, any computations of the average, minimum and maximum  
              values associated with these measurements are restarted. 
            - The Reset Occurrences (ROC) parameter is not changed. 
            - Configuration parameters such as the absolute maximum jitter  
              buffer delay and session-related parameters (Table 3) reflect current  
              values.  
             
            Kumar et al            Informational                Page 31 
            MGCP RTCP-XR Package                             4/12/2007 
            2.3.4 Impact redundancy and FEC on  packet loss computations 
             
            The packet loss and discard parameters based on the RTCP XR VoIP 
            metrics block [RFC 3611] are computed after taking redundancy and FEC 
            into account. Thus, the following parameters from Table 1 SHALL be 
            computed after taking the effect of redundancy (e.g. RFC 2198) and/or 
            FEC (e.g. RFC 2733) into account: 
             
               - Network packet loss rate, NLR 
               - Jitter buffer discard rate, JDR 
               - Burst loss density, BLD, and burst duration, BD 
               - Gap loss density, GLD, and gap duration, GD 
             
            By contrast, the packet receipt and packet loss parameters based on 
            RTCP Sender Reports (SR) and Receiver Reports (RR) do not take 
            redundancy or FEC into account. They are meant to be indicative of 
            impairments "on the wire" than in end-to-end service. Thus, the packets 
            lost (PL) parameter in Table 2 does not take into account any loss 
            mitigation due to redundancy (e.g. RFC 2198) or FEC (e.g. RFC 2733) 
            into account.  
              
            2.3.5 Parameter Extension Mechanism 
             
            The XRM/LVM and XRM/RVM lines MAY include vendor extension parameters 
            that begin with an "X-". An MGCP entity that receives an extension 
            parameter in these lines MUST ignore it if it cannot understand it.  
             
            Since these parameters introduce an unmanaged name space, there is a 
            potential for name clashing. Vendors are consequently encouraged to 
            include some vendor specific string, e.g. vendor name or stock ticker 
            symbol, in their vendor extensions. For example, if Acme Widgets, a 
            fictional company, wishes to use metric "ABC", it is preferable to use 
            the name "X-acmewidgets-ABC" rather than  "X-ABC". 
             
            Vendors MAY register new metrics in an IANA registry of  MGCP names of 
            VoIP metrics. The "X-" prefix is not germane to a metric following 
            registration. 
             
            2.3.6 Formal Syntax of VoIP Metrics Package   
             
            The following describes the ABNF encoding [RFC 2234] for the parameters 
            defined in this package. Per MGCP conventions,  all parameters defined 
            in this package are case-insensitive.  
             
            The standard tokens SP, WSP, ALPHA, DIGIT, HEXDIG etc. are per RFC 
            2234.  
             
            MediaMetricsOption = "XRM/MMO:" *WSP ("REP"/"RES"/"RR") 
            Kumar et al            Informational                Page 32 
            MGCP RTCP-XR Package                             4/12/2007 
             
            RemoteVoIPMetrics = "XRM/LVM:" *WSP [VoIPMetric *("," *WSP  
                                VoIPMetric)] 
                           ; zero or more local metrics 
                           ; zero metrics are permitted in AUCX responses 
             
            RemoteVoIPMetrics = "XRM/RVM:" *WSP [VoIPMetric *("," *WSP  
                                VoIPMetric)] 
                           ; zero or more remote metrics 
             
            VoIPMetric = ComputationInterval 
                              / ResetOccurrences 
                              / NetworkPacketLossRate 
                           / JitterBufferDiscardRate  
                           / BurstLossDensity 
                           / GapLossDensity 
                           / BurstDuration 
                           / GapDuration 
                           / RoundTripNetworkDelay 
                           / EndSystemDelay 
                           / SignalLevel 
                           / NoiseLevel 
                           / ResidualEchoReturnLoss 
                           / MinimumGapThreshold 
                           / RFactor-CQ 
                           / RFactor-LQ 
                           / ExternalRFactor 
                           / EstimatedMOS-LQ 
                           / EstimatedMOS-CQ 
                           / PacketLossConcealmentType  
                           / JitterBufferAdaptability 
                           / JitterBufferRate 
                           / JitterBufferNominal 
                           / JitterBufferMax 
                           / JitterBufferAbsMax 
                           / MOSLQEstimationAlgorithm 
                              / MOSLQEstimationAlgorithm 
                              / RfacorEstimationAlgorithms 
                           / InterArrivalJitter 
                           / PacketsSent 
                           / OctetsSent 
                           / PacketsReceived 
                           / OctetsReceived 
                           / PacketsLost 
                           / SSRC 
                           / SourceIPAddress 
                           / SourceIPAddressType 
                           / DestinationIPAddress 
            Kumar et al            Informational                Page 33 
            MGCP RTCP-XR Package                             4/12/2007 
                           / DestinationIPAddressType 
                           / SourceRTPPort 
                           / DestinationRTPPort 
                           / SourceRTCPPort 
                           / DestinationRTCPPort 
                           / VoiceOrVBDprimaryCodec 
                           / VoiceOrVBDsecondaryCodec 
                         / MaxCharacterRate 
                          / MediaMode 
                           / SampleRate 
                           / CodecFrameSize 
                           / RTPpayloadSize 
                           / PacketizationRate 
                           / SilenceSuppression 
                           / EchoCancellation 
                           / RFC2198RedundancyForVoiceOrVBD 
                           / RFC2733FECforVoiceOrVBD  
                           / FECstreamSSRC 
                           / FECDestinationIPAddress 
                           / FECDestinationRTPPort                     
                           / UnregisteredExtension 
                           / RegisteredExtension                  
                            
            ComputationInterval           = "CMPI" = 1*20(DIGIT);  
             
            ResetOccurrences              = "ROC"  = "0"/"1";  
             
            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)  
            Kumar et al            Informational                Page 34 
            MGCP RTCP-XR Package                             4/12/2007 
                                       ; 0 to 127, indicates dB below 0 dBm0 
             
            ResidualEchoReturnLoss      = "RERL="  1*3(DIGIT) ;0-127 
             
            RFactor-CQ                = "NSR=" 1*3(DIGIT)  
                                                         ;0-120, or 127 
             
            RFactor-LQ                = "RLQ=" 1*3(DIGIT)  
                                                         ;0-120, or 127 
            ExternalRFactor       = "XRF=" 1*3(DIGIT) ;0-120, or 127 
             
            EstimatedMOS-LQ  = "MLQ=" 1*3(DIGIT) ; 10-50, or 127 
             
            EstimatedMOS-CQ  = "MCQ=" 1*3(DIGIT) ; 10-50, or 127 
             
            PacketLossConcealmentType= "PLC=" ("0" / "1" / "2" / "3") 
             
            JitterBufferAdaptability     = "JBA=" ("0" / "1" / "2" / "3") 
             
            JitterBufferRate      = "JBR=" 1*2(DIGIT) ;0-15 
             
            JitterBufferNominal         = "JBN=" 1*5(DIGIT) ;0-65535  
             
            JitterBufferMax       = "JBM=" 1*5(DIGIT) ;0-65535 
             
            JitterBufferAbsMax          = "JBS=" 1*5(DIGIT) ;0-65535 
             
            MOSLQEstimationAlgorithm = "MLES=" ALPHA 1*127 (permittedchar) 
                                     ;first character must be alphabetic 
            MOSCQEstimationAlgorithm = "MCES=" ALPHA 1*127 (permittedchar) 
                                     ;first character must be alphabetic 
            RfactorAlgorithms = "RFES=" ALPHA 1*127 (permittedchar) 
                                     ;first character must be alphabetic 
            InterArrivalJitter = "IAJ=" 1*3(DIGIT) ;  
            PacketsSent     = "PS=" 1*9(DIGIT);  
            OctetsSent      = "OS=" 1*9(DIGIT); 
            PacketsReceived = "PR=" 1*9(DIGIT); 
            OctetsReceived  = "OR=" 1*9(DIGIT); 
            PacketsLost     = "PL=" ["-"] 1*9(DIGIT); 
            SSRC = "SSRC=" 1*10 (DIGIT); 0-4,294,967,296 
            SourceIPAddressType = "IPTS=" ("IPv4" / "IPv6") 
            DestinationIPAddressType = "IPTD=" ("IPv4" / "IPv6") 
            SourceIPAddress = "IPAS=" (IPv4address / IPv6address) 
                      ; IPv4address and IPv6address defined in RFC 3261 
            DestinationIPAddress = "IPAD=" (IPv4address / IPv6address) 
                      ; IPv4address and IPv6address defined in RFC 3261 
            SourceRTPPort = "RTUS=" 1*5(DIGIT) ;1024-65535 inclusive 
            DestinationRTPPort = "RTUD=" 1*5(DIGIT)  
            Kumar et al            Informational                Page 35 
            MGCP RTCP-XR Package                             4/12/2007 
                      ;1024-65535 inclusive 
            SourceRTCPPort = "RTCS=" 1*5(DIGIT) ;1024-65535 inclusive 
            DestinationRTCPPort = "RTCD=" 1*5(DIGIT)  
                      ;1024-65535 inclusive 
            VoiceOrVBDprimaryCodec = "VCD=" ALPHA 1*31 (permittedchar) 
                                ;first character must be alphabetic 
            VoiceOrVBDsecondaryCodec = "VCDS=" ALPHA 1*31 (permittedchar) 
                                ;first character must be alphabetic 
            MaxCharacterRate = "CPS=" 1*2 (DIGIT) 
            MediaMode = "MMOD=" "a" / "v" / "f" / "m" / "t" / ALPHA 
              ; audio, voice band data, fax relay, modem relay, text relay 
              ; the token ALPHA is to permit additional future definitions 
            SampleRate = "SMPL=" 1*7 (DIGIT) 
            CodecFrameSize = "FRSZ=" 1*3 (DIGIT) 
            RTPpayloadSize = "PLSZ=" 1*3 (DIGIT) 
            PacketizationRate = "PKRT=" 1*5 (DIGIT) 
            SilenceSuppression = "SSUP=" ("on" / "off") 
            EchoCancellation = "ECAN=" ("on" / "off") 
            RFC2198RedundancyForVoiceOrVBD = "VRED=" ("on" / "off") 
            RFC2733FECforVoiceOrVBD = "VFEC=" ("on" / "off") 
            FECstreamSSRC = "FSRC=" 1*10 (DIGIT); 0-4,294,967,296 
            FECDestinationIPAddress = "IPAF=" (IPv4address / IPv6address) 
                      ; IPv4address and IPv6address defined in RFC 3261 
            FECDestinationRTPPort = "RTFD=" 1*5(DIGIT)  
                                    ;1024-65535 inclusive 
            UnregisteredExtension = "X-" ExtensionName "=" ExtensionVal 
            RegisteredExtension = ExtensionName "=" ExtensionVal 
            ExtensionName = 1*32 (ALPHA) 
            ExtensionVal = 1*32 (alphanum) 
                 ;More precise definition in extension specifications 
             
            alphanum  =  ALPHA / DIGIT 
            permittedchar  =  alphanum / permittedspecialchar 
            permittedspecialchar = "-" / "_" / "." / "!" / "~" / "*" /  
                                     "'" / "(" / ")" / SP 
             
            2.3.7 Impact of media state changes on VoIP metrics  
             
            The RECOMMENDED endpoint behavior when the media state changes (e.g. 
            from voice to voice band data or vice versa) is to reset/reinitialize 
            the parameters in Tables 1, 2 and 3. Section 2.3.3 describes the 
            procedures for this resetting/reinitialization. 
             
            However, it is recognized that some endpoints MAY continue to 
            accumulate or average parameters across media state changes. For 
            example, an endpoint MAY continue to accumulate parameters such as 
            packet loss rate (NLR) and to average parameters such as round trip 
            delay (RTD)across transitions between voice and voice band data. If 
            metrics computation is carried over from one media state to another, 
            Kumar et al            Informational                Page 36 
            MGCP RTCP-XR Package                             4/12/2007 
            then metrics and parameters that do not apply to the new state (such as 
            MOS-LQ in the case of fax relay)SHOULD be placed in a suspended state 
            until another state transition (such as fax relay to voice in the case 
            of MOS-LQ) renders them applicable again. If any reporting activity 
            occurs during their suspension, the last applicable value SHOULD be 
            conveyed. 
             
            If the session is initially established in a mode for which some of the 
            metrics and parameters in Tables 1-3 do not apply, then these 
            parameters MUST be omitted or dummied out (per the rules in Section 
            2.3.1) for any reporting while they are inapplicable. For example, if 
            an endpoint uses this package to convey the metrics for a session that 
            is currently in the T.38 fax relay mode in which it was initially 
            established, then the MOS-LQ parameter MUST be omitted or dummied out 
            (by setting it to 127). 
             
            2.3.8 Applicability of VoIP metrics to Voice Band Data 
             
            For the definition of voice band data, see [ITU V.152]. Voice band data 
            sessions are RTP sessions. RTCP is REQUIRED in conjunction with any RTP 
            session [RFC 3550]. However, the various blocks in RTCP-XR, such as the 
            VoIP metrics block, are not. They must be negotiated at session 
            establishment. 
             
            Also note that, since this document is focused on voice, it lacks key 
            voice band data metrics.  
             
            The parameters from the RTCP XR VoIP metrics block (Table 1) and the 
            RTCP Sender/Receiver Reports (Table 2) MAY be applied to voice band 
            data. The session description parameters (Table 3) are also applicable 
            to voice band data.  
             
            Note that the utility of the various MOS scores and R-factors might be 
            limited for voice band data since there is no correlation of the 
            various MOS scores and R-factors with the end-users' perspective of the 
            quality of the modem or fax transmission.  Notwithstanding, some 
            implementations MAY elect to use the MLQ metric as an indicator of the 
            transmission quality of voice band data channel.  
                
            For some voice band data sessions, echo cancellation is turned off. For 
            others, it is turned on. If echo cancellation is off, then RERL reverts 
            to the Echo Return Loss of the hybrid transformer or acoustic coupling 
            path. However, some implementations might not measure this parameter in 
            the absence of an active echo canceller. In such cases, this parameter 
            will be omitted in the XRM/LVM and XRM/RVM lines, or set to a dummy 
            value (127) in the XRM/RVM line. 
             
            Kumar et al            Informational                Page 37 
            MGCP RTCP-XR Package                             4/12/2007 
            Many voice band data sessions [ITU V.152] use fixed-length jitter 
            buffers. If this is the case, then this will be reflected in the JBA 
            parameter (set to "non-adaptive"), the JBR parameter (set to 0) and the 
            JBS parameter (set to JBM).   
             
            2.3.9 Applicability of VoIP metrics to Fax Relay and Text Relay 
                
            Since this document is focused on voice, it lacks key metrics related 
            to fax [ITU T.38], text [ITU V.151] and modem [ITU V.150.1] relay. 
            Other specifications such as [FAX PKG] will address in a 
            comprehensive manner the reporting via MGCP of the metrics 
            that pertain to the various relay modes. 
             
            However, it is instructive to examine how the parameters defined in 
            this document apply to various relay mechanisms. Tables 4, 5 and 6 
            examine the relevance of the metrics and session parameters listed in 
            Tables 1, 2 and 3 to fax relay [ITU T.38]. Tables 7, 8 and 9 examine 
            the relevance of the metrics and session parameters listed in Tables 1, 
            2 and 3 to text relay [ITU V.151].    
             
            Note that the basic definitions of parameters from Tables 1, 2, and 3 
            are not repeated in Tables 4 through 9. All that these tables address 
            is the applicability of these parameters to fax relay and text relay. 
            Parameters from Tables 1, 2 and 3 that are not relevant to fax relay 
            are not listed in Tables 4, 5 and 6. Similarly, parameters from Tables 
            1, 2 and 3 that are not relevant to text relay are not listed in Tables 
            7, 8 and 9.   
             
            Relay sessions (fax or text) get established in two ways. In the first 
            case, the session is established as a fax or text relay session during 
            call set-up. In the second case, it is established as an audio session 
            which is transitioned, at  media gateways, to fax relay or text relay 
            on the receipt of certain tones or stimuli. A variant of this second 
            case involves a transition from audio to voice band data and 
            subsequently to fax relay or text relay.    
             
            RTCP is REQUIRED in conjunction with any RTP session [RFC 3550]. This 
            includes RTP-based fax relay and RTP-based text relay.  However, the 
            various blocks in RTCP-XR, such as the VoIP metrics block, are not. 
            They must be negotiated at session establishment. Note that, in 
            contrast to RTP-based relay sessions, RTCP is not applicable to non-RTP 
            relay such as UDTPL-based fax relay [ITU T.38]. 
             
            Note that burst parameters (burst loss density, gap loss density, burst 
            duration, gap duration and the minimum gap threshold) are not germane 
            to relay mechanisms (such as fax relay or text relay) since such relay 
            streams are not continuous for significant periods of time. Any burst 
            characterization is, therefore, likely to be deceptive.  
            Kumar et al            Informational                Page 38 
            MGCP RTCP-XR Package                             4/12/2007 
             
            Also note that the various R-factors and MOS scores in Table 1 are not 
            applicable to baseband data transmission such as fax relay or data 
            relay. 
             
            TABLE 4: PARAMETERS FROM TABLE 1 THAT ARE APPLICABLE TO FAX RELAY 
            +-----------------+-----------------------------------------------+ 
            |  PARAMETER      |          APPLICABILITY TO FAX RELAY           | 
            | from Table 1    |                                               |     
            +-----------------+-----------------------------------------------+ 
            |Network packet   |Loss refers to fax relay packets which MAY be  | 
            |loss rate(NLR)   |UDPTL or RTP [ITU T.38]. Computed after FEC    | 
            |                 |and/or redundancy processing. As described     | 
            |                 |in [ITU T.38], the FEC and redundancy          | 
            |                 |schemes applicable to UDPTL fax relay and RTP  | 
            |                 |fax relay are different.                       | 
            +-----------------+-----------------------------------------------+ 
            |Jitter buffer    |Discards refer to fax relay packets which MAY  | 
            |discard rate     |be UDPTL or RTP [ITU T.38]. Computed after FEC | 
            |(JDR)            |and/or redundancy processing. As described     | 
            |                 |in [ITU T.38], the FEC and redundancy          | 
            |                 |schemes applicable to UDPTL fax relay and RTP  | 
            |                 |fax relay are different.                       | 
            +-----------------+-----------------------------------------------+ 
            |Round trip       |Not very useful for fax relay sessions. Can be | 
            |network delay    |computed using RTCP for RTP-based fax relay.   | 
            |(RTD)            |There is no standard mechanism for round-trip  | 
            |                 |delay computation in the case of UDPTL-based   | 
            |                 |fax relay.                                     | 
            ------------------------------------------------------------------- 
            |End system delay | Not very useful for fax relay sessions.       |               
            |(ESD)            |                                               | 
            +-----------------+-----------------------------------------------+ 
              
             
             
             
             
             
             
             
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 39 
            MGCP RTCP-XR Package                             4/12/2007 
             
            TABLE 5: PARAMETERS FROM TABLE 2 THAT ARE APPLICABLE TO FAX RELAY 
            +-----------------+-----------------------------------------------+ 
            |  PARAMETER      |          APPLICABILITY TO FAX RELAY           | 
            | from Table 2    |                                               |     
            +-----------------+-----------------------------------------------+ 
            |Packets sent     |Refers to fax relay packets, which MAY be UDPTL| 
            |(PS)             |or RTP. Does not include any RTP FEC packets   | 
            |                 |sent on a different SSRC or port.              | 
            +-----------------+-----------------------------------------------+ 
            |Octets sent      |Refers only to T.4 image octets in             | 
            |(OS)             |primary UDPTL/RTP payloads/packets. Octets in  | 
            |                 |redundant/FEC payloads/packets are not counted.| 
            +-----------------+-----------------------------------------------+ 
            |Packets          |Refers to fax relay packets, which MAY be UDPTL| 
            |Received         |or RTP. Does not include any RTP FEC packets   |                     
            |(PR)             |received on a different SSRC or port.          |                     
            +-----------------+-----------------------------------------------+ 
            |Octets received  |Refers only to T.4 image octets in             | 
            |(OR)             |primary UDPTL/RTP payloads/packets. Octets in  | 
            |                 |redundant/FEC payloads/packets are not      | 
            |                 |counted.                                       | 
            +-----------------+-----------------------------------------------+ 
            |Packets lost     |Refers to lost UDPTL/RTP fax relay packets     | 
            |(PL)             |without taking into account any loss mitigation| 
            |                 |due to redundancy or FEC. As described         | 
            |                 |in [ITU T.38], the FEC and redundancy          | 
            |                 |schemes applicable to UDPTL fax relay and RTP  | 
            |                 |fax relay are different.                       | 
            +-----------------+-----------------------------------------------+ 
              
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
             
               
            Kumar et al            Informational                Page 40 
            MGCP RTCP-XR Package                             4/12/2007 
            TABLE 6: PARAMETERS FROM TABLE 3 THAT ARE APPLICABLE TO FAX RELAY 
            +-----------------+-----------------------------------------------+ 
            |  PARAMETER      |          APPLICABILITY TO FAX RELAY           | 
            | from Table 3    |                                               |     
            +-----------------+-----------------------------------------------+ 
            |SSRC             |Not applicable to UDPTL-based fax relay. For   | 
            |(SSRC)           |RTP-based fax relay, this is the SSRC of the   | 
            |                 |RTP fax relay stream.                          | 
            +-----------------+-----------------------------------------------+ 
            |Source IP address| Applicable to fax relay sessions.             | 
            |(IPAS)           |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Source IP address| Applicable to fax relay sessions.             | 
            |type (IPTS)      |                                               |                     
            +-----------------+-----------------------------------------------+ 
            |Destination IP   | Applicable to fax relay sessions.             | 
            |address (IPAD)   |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Destination IP   | Applicable to fax relay sessions.             | 
            |address type     |                                               |   
            |(IPTD)           |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Source RTP/UDPTL | Applicable to fax relay sessions.             | 
            |port (RTUS)      |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Destination      | Applicable to fax relay sessions.             | 
            |RTP/UDPTL port   |                                               | 
            |(RTUD)           |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Source RTCP      | Applicable to RTP-based fax relay sessions.   | 
            |port (RTCS)      |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Destination RTCP | Applicable to RTP-based fax relay sessions.   | 
            |port (RTCD)      |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Media Mode (MMOD)| Applicable to fax relay sessions.             | 
            +-----------------+-----------------------------------------------+ 
            |SSRC of received |Applicable to RTP-based fax relay if FEC is    | 
            |FEC stream       |used in conjunction with it.                   |  
            |(FSRC)           |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Destination IP   |Applicable to RTP-based fax relay if FEC is    | 
            |address for FEC  |used in conjunction with it.                   |  
            |(IPAF)           |                                               | 
            +-----------------+-----------------------------------------------+ 
             
             
             
            Kumar et al            Informational                Page 41 
            MGCP RTCP-XR Package                             4/12/2007 
            +-----------------+-----------------------------------------------+ 
            |  PARAMETER      |          APPLICABILITY TO FAX RELAY           | 
            | from Table 3    |                                               |     
            +-----------------+-----------------------------------------------+ 
            |Destination RTP  |Applicable to RTP-based fax relay if FEC is    | 
            |port for FEC     |used in conjunction with it.                   |  
            |(RTFD)           |                                               | 
            +-----------------+-----------------------------------------------+ 
             
            TABLE 7: PARAMETERS FROM TABLE 1 THAT ARE APPLICABLE TO TEXT RELAY 
            +-----------------+-----------------------------------------------+ 
            |  PARAMETER      |          APPLICABILITY TO TEXT RELAY          | 
            | from Table 1    |                                               |     
            +-----------------+-----------------------------------------------+ 
            |Network packet   |Packet loss is computed for a stream of packets| 
            |loss rate(NLR)   |sharing an SSRC and, therefore, the same       | 
            |                 |sequence number space. This is either a        | 
            |                 |stream of RTP-based text relay packets or an   | 
            |                 |interleaved stream of audio and text relay     | 
            |                 |packets. This loss rate is computed after FEC  | 
            |                 |and/or redundancy processing.                  | 
            +-----------------+-----------------------------------------------+ 
            |Jitter buffer    |The discard rate is computed for a stream of   | 
            |discard rate     |packets sharing an SSRC and, therefore, the    | 
            |(JDR)            |same sequence number space. This is either a   | 
            |                 |stream of RTP-based text relay packets or an   | 
            |                 |interleaved stream of audio and text relay     | 
            |                 |packets. This loss rate is computed after FEC  | 
            |                 |and/or redundancy processing.                  | 
            +-----------------+-----------------------------------------------+ 
            |Round trip       |Applicable to text relay sessions.             | 
            |network delay    |                                               | 
            |(RTD)            |                                               | 
            +-----------------+-----------------------------------------------+ 
            |End system delay |Applicable to text relay sessions.             | 
            |(ESD)            |                                               | 
            +-----------------+-----------------------------------------------+ 
             
             
             
             
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 42 
            MGCP RTCP-XR Package                             4/12/2007 
            TABLE 8: PARAMETERS FROM TABLE 2 THAT ARE APPLICABLE TO TEXT RELAY 
            +-----------------+-----------------------------------------------+ 
            |  PARAMETER      |          APPLICABILITY TO TEXT RELAY           | 
            | from Table 2    |                                               |     
            +-----------------+-----------------------------------------------+ 
            |Packets sent     |Refers to text relay packets. If these packets | 
            |(PS)             |share an SSRC with an interleaved audio stream,| 
            |                 |it refers to the composite stream. Does not    | 
            |                 |include any FEC packets sent on a different    | 
            |                 |SSRC or port.                                  | 
            +-----------------+-----------------------------------------------+ 
            |Octets sent      |Refers only to payload octets in primary RTP   |             
            |(OS)             |payloads/packets. Payload octets include text  | 
            |                 |octets and audio octets sent with the same     | 
            |                 |SSRC. Octets in redundant or FEC               | 
            |                 |payloads/packets are not counted.              |                     
            +-----------------+-----------------------------------------------+ 
            |Packets received |Refers to text relay packets. If these packets | 
            |(PR)             |share an SSRC with an interleaved audio stream,| 
            |                 |it refers to the composite stream. Does not    | 
            |                 |include any FEC packets received on a different| 
            |                 |SSRC or port.                                  | 
            +-----------------+-----------------------------------------------+ 
            |Octets received  |Refers only to payload octets in primary RTP   |             
            |(OR)             |payloads/packets. Payload octets include text  | 
            |                 |octets and audio octets received with the same | 
            |                 |SSRC. Octets in redundant or FEC               | 
            |                 |payloads/packets are not counted.              |                     
            +-----------------+-----------------------------------------------+ 
            |Packets lost     |Refers to text relay packets. If these packets | 
            |(PL)             |share an SSRC with an interleaved audio stream,| 
            |                 |it refers to the composite stream. Does not    | 
            |                 |take into account any loss mitigation due to   | 
            |                 |due to redundancy or FEC.                      | 
            +-----------------+-----------------------------------------------+  
             
             
             
             
             
             
             
             
             
             
             
             
             
            Kumar et al            Informational                Page 43 
            MGCP RTCP-XR Package                             4/12/2007 
            TABLE 9: PARAMETERS FROM TABLE 3 THAT ARE APPLICABLE TO TEXT RELAY 
            +-----------------+-----------------------------------------------+ 
            |  PARAMETER      |          APPLICABILITY TO TEXT RELAY          | 
            | from Table 3    |                                               |     
            +-----------------+-----------------------------------------------+ 
            |SSRC             |Applicable to text relay sessions and sessions | 
            |(SSRC)           |with interleaved text relay and audio packets. |         
            +-----------------+-----------------------------------------------+ 
            |Source IP        |Applicable to text relay sessions and sessions | 
            |address (IPAS)   |with interleaved text relay and audio packets. |                     
            +-----------------+-----------------------------------------------+ 
            |Source IP address|Applicable to text relay sessions and sessions | 
            |type (IPTS)      |with interleaved text relay and audio packets. |                     
            +-----------------+-----------------------------------------------+ 
            |Destination IP   |Applicable to text relay sessions and sessions | 
            |address (IPAD)   |with interleaved text relay and audio packets. |                     
            +-----------------+-----------------------------------------------+ 
            |Destination IP   |Applicable to text relay sessions and sessions | 
            |address type     |with interleaved text relay and audio packets. |  
            |(IPTD)           |                                               |                     
            +-----------------+-----------------------------------------------+ 
            |Source RTP/UDPTL |Applicable to text relay sessions and sessions | 
            |port(RTUS)       |with interleaved text relay and audio packets. |  
            +-----------------+-----------------------------------------------+ 
            |Destination      |Applicable to text relay sessions and sessions | 
            |RTP/UDPTL port   |with interleaved text relay and audio packets. |  
            |(RTUD)           |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Source RTCP      |Applicable to text relay sessions and sessions | 
            |port (RTCS)      |with interleaved text relay and audio packets. | 
            +-----------------+-----------------------------------------------+ 
            |Destination RTCP |Applicable to text relay sessions and sessions | 
            |port (RTCD)      |with interleaved text relay and audio packets. | 
            +-----------------+-----------------------------------------------+ 
            |Media Mode       |Applicable to text relay sessions and sessions | 
            |(MMOD)           |with interleaved text relay and audio packets. | 
            +-----------------+-----------------------------------------------+ 
            |SSRC of received |Applicable if FEC is used.                     | 
            |FEC stream (FSRC)|                                               | 
            +-----------------+-----------------------------------------------+ 
            |Destination IP   |Applicable if FEC is used.                     | 
            |address for FEC  |                                               |  
            |(IPAF)           |                                               | 
            +-----------------+-----------------------------------------------+ 
            |Destination RTP  |Applicable if FEC is used.                     | 
            |port for FEC     |                                               | 
            |(RTFD)           |                                               | 
            +-----------------+-----------------------------------------------+ 
            Kumar et al            Informational                Page 44 
            MGCP RTCP-XR Package                             4/12/2007 
            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  Metrics Reporting during Call agent-initiated Delete Connection 
             
            Step 1: 
            The Call Agent issues a CreateConnection command to the endpoint 
            instructing it to use PCMU media encoding and to invoke RTCP XR metric 
            collection, responding and reporting: 
             
                 CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 L: a:PCMU, xrm/mcr: on 
                 M: recvonly 
             
            Step 2: 
             
            The endpoint acknowledges the command and includes the rtxp-xr 
            attribute set to "voip-metrics": 
             
                 200 1000 OK 
                 I:1 
             
                 v=0  
                 o=- 25678 753849 IN IP4 128.96.41.1  
                 s=-  
                 c=IN IP4 128.96.41.1  
                 t=0 0  
                 m=audio 3456 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
            Step 3: 
             
            The endpoint receives a ModifyConnection command containing an LCO with 
            no xrm/mcr parameter, which indicates that the endpoint SHOULD continue 
            to use the previously received value of "on". Since the received SDP 
            also contains the rtcp-xr attribute with a value of "voip-metrics", it 
            Kumar et al            Informational                Page 45 
            MGCP RTCP-XR Package                             4/12/2007 
            is safe to assume that both ends will exchange the VoIP metrics block 
            in RTCP Extended Reports (XR). 
             
             
                 MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 I: 1 
                 L: a:PCMU;G728 
                 M: sendrecv 
                  I:1 
             
             
                 v=0  
                 o=- 4723891 7428910 IN IP4 128.96.63.25 
                 s=-  
                 c=IN IP4 128.96.63.25  
                 t=0 0  
                 m=audio 4082 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
            Step 4: 
             
            The endpoint acknowledges the command and, since VoIP metrics 
            collection/reporting is still "on", includes the rtxp-xr attribute set 
            to "voip-metrics": 
             
                 200 1001 OK 
             
                 v=0  
                 o=- 25678 753849 IN IP4 128.96.41.1  
                 s=-  
                 c=IN IP4 128.96.41.1  
                 t=0 0  
                 m=audio 3456 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
            Step 5: 
             
            The Call Agent eventually issues a DeleteConnection: 
             
                 DLCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 I: 1 
             
            Step 6: 
             
            The endpoint acknowledges the command and returns the standard MGCP 
            connection parameters along with the XRM/LVM line and the XRM/RVM line. 
            Kumar et al            Informational                Page 46 
            MGCP RTCP-XR Package                             4/12/2007 
            This endpoint elects to include the remote equivalents of the 
            connection parameters on XRM/RVM line. Note that the remote end has 
            indicated that the ITU G.107 specification has been used to compute the 
            R-factors and that a proprietary algorithm, "Acme Widgets 233", has 
            been used to compute MOS-LQ. The remote end has not indicated the 
            algorithm used to compute MOS-CQ, which is on of the metrics that it 
            has communicated via an RTCP extended report. Also note that new lines 
            shown here are for document formatting reasons only. 
             
                 250 1100 OK 
                 P: PS=5000, OS=200000, PR=6000, OR=340000, PL=800,  
                 JI=27, LA=180  
                 XRM/LVM: NLR=28, JDR=14, BLD=128, GLD=10,  
                 BD=55, GD=1000, RTD=180,ESD=30, SL=-15, NL=20,  
                 RERL=23, GMN=16, NSR=63, RLQ=61, XSR=65, MLQ=33, MCQ=31, PLC=3, 
                 JBA=3, JBR=8, JBN=40, JBM=80, JBS=120, SSRC=27513888, 
                 IPAD=128.96.41.1, RTPD=3456, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000,  
                 PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off 
                 XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180, 
                 ESD=23, SL=-16, NL=25, RERL=23, GMN=16, NSR=80, RLQ=82, XSR=77, 
                 MLQ=37, MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60, JBS=100, 
                 MLES=Acme widgets 233, RFES=ITU G.107,PS=6800, OS=272000, 
                 PR=4900, OR=196000, IAJ=15, SSRC=832829, IPAD=128.96.63.25, 
                 RTPD=4082, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000, PKRT=200, SSUP=on, 
                 ECAN=on, VRED=off, VFEC=off 
              
            3.2 Metrics Reporting during Gateway-initiated Delete Connection 
             
            Step 1: 
             
            The Call Agent issues a CreateConnection command to the endpoint 
            instructing it to use PCMU media encoding and to invoke RTCP XR metric 
            collection and reporting: 
             
                 CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 L: a:PCMU, xrm/mcr: on 
                 M: recvonly 
             
             
            Step 2: 
             
            The endpoint acknowledges the command and includes the rtxp-xr 
            attribute set to "voip-metrics": 
             
                 200 1000 OK 
                 I:1 
             
            Kumar et al            Informational                Page 47 
            MGCP RTCP-XR Package                             4/12/2007 
                 v=0  
                 o=- 25678 753849 IN IP4 128.96.41.1  
                 s=-  
                 c=IN IP4 128.96.41.1  
                 t=0 0  
                 m=audio 3456 RTP/AVP 0  
                 a=rtcp-xr:voip-metrics 
             
            Step 3: 
             
            The Endpoint issues a DeleteConnection command including the connection 
            parameters along with the XRM/LVM line and the XRM/RVM line: 
             
                 DLCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 I: 1 
                 E: 900 -                       - Hardware error 
                 P: PS=5000, OS=200000, PR=6000, OR=340000, PL=800,  
                 JI=27, LA=180  
                 XRM/LVM: NLR=28, JDR=14, BLD=128, GLD=10,  
                 BD=55, GD=1000, RTD=180,ESD=30, SL=-15, NL=20,  
                 RERL=23, GMN=16, NSR=63, XSR=65, MLQ=33, MCQ=31, PLC=3, JBA=3, 
                 JBR=8, JBN=40, JBM=80, JBS=120, SSRC=27513888, IPAD=128.96.41.1, 
                 RTPD=3456, VCD=PCMU, VPT=0, SMPL=8000,  
                 PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off 
                 XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180, 
                 ESD=23, SL=-16, NL=25, RERL=23, GMN=16, NSR=80, XSR=77, MLQ=37, 
                 MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60, JBS=100, PS=6800, 
                 OS=272000, PR=4900, OR=196000, IAJ=15, SSRC=832829, 
                 IPAD=128.96.63.25, RTPD=4082, VCD=PCMU, VPT=0, SMPL=8000, 
                 PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off 
                        
            Note that the RLQ parameter is not included in the XRM/LVM or the 
            XRM/RVM lines. This is just an example of allowed parameter omission. 
            This example could have very well been constructed with the RLQ 
            parameter. 
             
            Step 4: 
             
            The Call Agent acknowledges the command: 
             
                 200 1100 OK 
             
            3.3 Metrics Reporting during Audit Connection 
             
             
             
             
            Kumar et al            Informational                Page 48 
            MGCP RTCP-XR Package                             4/12/2007 
            Step 1: 
             
            The Call Agent issues a CreateConnection command to the endpoint 
            instructing it to use PCMU media encoding and to invoke RTCP XR metric 
            collection, responding and reporting: 
             
                 CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 L: a:PCMU, xrm/mcr: on 
                 M: recvonly 
             
            Step 2: 
             
            The endpoint acknowledges the command and includes the rtxp-xr 
            attribute set to "voip-metrics": 
             
                 200 1000 OK 
                 I:1 
             
                 v=0  
                 o=- 25678 753849 IN IP4 128.96.41.1  
                 s=-  
                 c=IN IP4 128.96.41.1  
                 t=0 0  
                 m=audio 3456 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
             
            Step 3: 
             
            The endpoint receives a ModifyConnection command containing an LCO with 
            no xrm/mcr parameter, which indicates that the endpoint SHOULD continue 
            to use the previously received value of "on". Since the received SDP 
            also contains the rtcp-xr attribute with a value of "voip-metrics", it 
            is safe to assume that both ends will exchange the VoIP metrics block 
            in RTCP Extended Reports (XR). 
             
                 MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 I: 1 
                 L: a:PCMU;G728 
                 M: sendrecv 
             
             
                 v=0  
                 o=- 4723891 7428910 IN IP4 128.96.63.25 
                 s=-  
                 c=IN IP4 128.96.63.25  
            Kumar et al            Informational                Page 49 
            MGCP RTCP-XR Package                             4/12/2007 
                 t=0 0  
                 m=audio 4082 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
             
            Step 4: 
             
            The endpoint acknowledges the command and, since VoIP metrics 
            collection/reporting is still "on", includes the rtxp-xr attribute set 
            to "voip-metrics": 
             
                 200 1001 OK 
                 I:1 
             
                 v=0  
                 o=- 25678 753849 IN IP4 128.96.41.1  
                 s=-  
                 c=IN IP4 128.96.41.1  
                 t=0 0  
                 m=audio 3456 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
            Step 5: 
             
            The Call Agent eventually issues a AuditConnection that requests the 
            XRM/LVM and XRM/RVM lines but not the P (connection parameters) line: 
             
                 AUCX 1100 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 I: 1 
                 F: XRM/LVM, XRM/RVM 
             
             
            Step 6: 
             
            The endpoint acknowledges the command and returns the XRM/LVM line and 
            the XRM/RVM line. This endpoint elects to include the local and remote 
            equivalents of the connection parameters in the XRM/LVM and XRM/RVM 
            line. Also note that new lines shown here are for document formatting 
            reasons only. 
                  
                 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, NSR=63, RLQ=61, XSR=65, MLQ=33, MCQ=31, PLC=3, 
                 JBA=3, JBR=8, JBN=40, JBM=80, JBS=120, PS=5000, OS=200000, 
                 PR=6000, OR=340000, PL=800, IAJ=27, SSRC=27513888, 
                 IPAD=128.96.41.1, RTPD=3456, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000,  
            Kumar et al            Informational                Page 50 
            MGCP RTCP-XR Package                             4/12/2007 
                 PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off 
                 XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180, 
                 ESD=23, SL=-16, NL=25, RERL=23, GMN=16, NSR=80, RLQ=82, XSR=77, 
                 MLQ=37, MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60, JBS=100, 
                 PS=6800, OS=272000, PR=4900, OR=196000, IAJ=15, SSRC=832829, 
                 IPAD=128.96.63.25, RTPD=4082, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000, 
                 PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off 
             
            3.4 Metrics Reporting during Modify Connection 
             
            Step 1: 
             
            The Call Agent issues a CreateConnection command to the endpoint 
            instructing it to use PCMU media encoding and to invoke RTCP XR metric 
            collection, responding and reporting: 
             
                 CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 L: a:PCMU, xrm/mcr: on 
                 M: recvonly 
             
            Step 2: 
             
            The endpoint acknowledges the command and includes the rtxp-xr 
            attribute set to "voip-metrics": 
             
                 200 1000 OK 
                 I:1 
             
                 v=0  
                 o=- 25678 753849 IN IP4 128.96.41.1  
                 s=-  
                 c=IN IP4 128.96.41.1  
                 t=0 0  
                 m=audio 3456 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
             
             
            Step 3: 
             
            The endpoint receives a ModifyConnection command containing an LCO with 
            no xrm/mcr parameter, which indicates that the endpoint SHOULD continue 
            to use the previously received value of "on". Since the received SDP 
            also contains the rtcp-xr attribute with a value of "voip-metrics", it 
            is safe to assume that both ends will exchange the VoIP metrics block 
            in RTCP Extended Reports (XR). 
             
            Kumar et al            Informational                Page 51 
            MGCP RTCP-XR Package                             4/12/2007 
             
                 MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 I: 1 
                 L: a:PCMU;G728 
                 M: sendrecv 
             
             
                 v=0  
                 o=- 4723891 7428910 IN IP4 128.96.63.25 
                 s=-  
                 c=IN IP4 128.96.63.25  
                 t=0 0  
                 m=audio 4082 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
             
            Step 4: 
             
            The endpoint acknowledges the command and, since VoIP metrics 
            collection/reporting is still "on", includes the rtxp-xr attribute set 
            to "voip-metrics": 
             
                 200 1001 OK 
                 I:1 
             
                 v=0  
                 o=- 25678 753849 IN IP4 128.96.41.1  
                 s=-  
                 c=IN IP4 128.96.41.1  
                 t=0 0  
                 m=audio 3456 RTP/AVP 0 
                 a=rtcp-xr:voip-metrics 
             
            Step 5: 
             
            The Call Agent eventually issues a ModifyConnection with the XRM/MMO 
            line requesting that local and remote metrics be reset and reported.  
             
                 MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0  
                 C: 1 
                 I: 1 
                 L: a:PCMU;G728 
                 M: sendrecv 
                 XRM/MMO: RR 
             
             
             
            Kumar et al            Informational                Page 52 
            MGCP RTCP-XR Package                             4/12/2007 
            Step 6: 
             
            The endpoint acknowledges the command and returns the XRM/LVM line and 
            the XRM/RVM line. The endpoint does not include the connection 
            parameters line since this would violate [RFC 3435]. Instead, it 
            includes the local and remote equivalents of the connection parameters 
            in the XRM/LVM and XRM/RVM line. Also note that new lines shown here 
            are for document formatting reasons only. 
             
                 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, NSR=63, RLQ=61, XSR=65, MLQ=33, MCQ=31, PLC=3, 
                 JBA=3, JBR=8, JBN=40, JBM=80, JBS=120, PS=5000, OS=200000, 
                 PR=6000, OR=340000, PL=800, IAJ=27, SSRC=27513888, 
                 IPAD=128.96.41.1, RTPD=3456, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000,  
                 PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off 
                 XRM/RVM: NLR=6, JDR=2, BLD=50, GLD=3, BD=20, GD=6000, RTD=180, 
                 ESD=23, SL=-16, NL=25, RERL=23, GMN=16, NSR=80, RLQ=82, XSR=77, 
                 MLQ=37, MCQ=35, PLC=3, JBA=3, JBR=8, JBN=30, JBM=60, JBS=100, 
                 PS=6800, OS=272000, PR=4900, OR=196000, IAJ=15, SSRC=832829, 
                 IPAD=128.96.63.25, RTPD=4082, VCD=PCMU, VPT=0, MMOD=a, SMPL=8000, 
                 PKRT=200, SSUP=on, ECAN=on, VRED=off, VFEC=off 
             
             
            4. Security Considerations 
             
            This package inherits the security considerations of the base MGCP 
            protocol.  A possible new security issue involves a remote  device 
            placing extra burden on a local endpoint by requesting metric 
            collection on that local endpoint.  This threat can be mitigated by the 
            call agent specifically prohibiting the generation of local metrics 
            using the local connection option: xrm/mcr: off. 
             
            5. IANA Considerations 
             
            5.1 Package Registration 
             
            The IANA is hereby requested to register the following MGCP package: 
                
              Package Title         Name     Version   
              -------------         ----     -------     
              RTCP XR metrics       XRM        0 
             
            5.2. Extension Registration 
             
            The IANA is requested to create a registry of MGCP names of vendor-
            specified VoIP metrics.  These metrics MAY be used in the XRM/LVM and 
            Kumar et al            Informational                Page 53 
            MGCP RTCP-XR Package                             4/12/2007 
            XRM/RVM lines defined in this package. Such a metric SHALL be described 
            in a specification ("source document") approved by an accredited 
            standards  organization such as the IETF or ITU.  This document MAY be 
            informative and MAY address more than one metric. It MUST include: 
             
            - Contact name, email address and telephone number. 
            - Metric name, as an alphabetic character string 
            - Description of and ABNF notation for the permitted  
                 range of values,  
            - A functional description of the metric i.e. what it  
                 measures and how it is to be used, 
            - Optionally, the measurement algorithm and any IPR statements 
                 associated with it. 
             
            6. Changes from earlier drafts 
             
            6.1 Changes from the -00 version to the -01 version 
             
            All changes from the -00 version to the -01 version of this draft are 
            backwards compatible. All new features in the 01 version are OPTIONAL. 
             
            Note that the -00 version was incorporated into the PacketCable 1.5 
            specifications.  
             
            Changes from the -00 version to the -01 version are: 
             
            - Inclusion of statistics from the RTCP sender and receiver reports, 
            with the exception of latency which is already present in the RTCP XR 
            VoIP metrics block. The reporting of these statistics via this package 
            is OPTIONAL. 
             
            - Inclusion of session description parameters based on the ones defined 
            in RFC 2327, RFC 2198 etc. This included media description parameters 
            such as codec type.  
             
            - Inclusion of a modify connection procedure for the reporting and 
            resetting of voice quality metrics. 
             
            - Clarification of cumulative vs. interval metrics. 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. 
             
            - Inclusion of a new parameter, MLES, for indicating the algorithm used 
            to estimate the MOS-LQ metric. 
             
            Kumar et al            Informational                Page 54 
            MGCP RTCP-XR Package                             4/12/2007 
            - 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. 
             
            6.2 Changes from the -01 version to the -02 version 
             
            All changes from the -01 version of this draft to the -02 version are 
            backwards compatible. These are: 
             
            -    Included the impact of redundancy (e.g. RFC 2198) and FEC (e.g. 
            RFC 2733) on packet loss computation. 
            -    Corrections of errors and typos in the ABNF. 
             
            6.3 Changes from the -02 version to the -03 version 
             
            All changes from the -02 version of this draft to the -03 version are 
            backwards compatible. These are: 
             
               - Added the parameters FSRC, IPAF and RTFD to Table 3 to fully 
                 cover the case in which an RFC 2733 FEC is used.  
               - Added section 2.3.9 on the applicability to fax relay and text 
                 relay of the VoIP metrics and session parameters reported via 
                 this package. 
             
            6.4 Changes from the -03 version to the -04 version 
             
            All changes from the -03 version of this draft to the -04 version are 
            backwards compatible. These are: 
             
               - Clarification that metrics MAY be reset during media mode shifts, 
                 and that this is the preferred behavior. 
               - Clarified how an audit connection MAY be associated with a 
                 preceding event notification. This is based on temporal 
                 proximity. Included recommendation to report the metrics captured 
                 just prior to the event. 
               - Included two new parameters that MAY be OPTIONALly reported: the 
                 computation interval (CMPI) and the number of reset occurrences 
                 (ROC). 
               - Included section 2.3.7 describing the impact of media state 
                 changes on VoIP metrics. 
             
            6.5 Changes from the -04 version to the -05 version 
            Spelling errors.  

            6.6 Changes from the -05 version to the -06 version 
            Formatting. 
 
            6.7 Changes from the -06 version to the -07 version 
            Formatting.

            6.8 Potential future updates 
            -    Add list of acronyms 
             
             
            Kumar et al            Informational                Page 55 
            MGCP RTCP-XR Package                             4/12/2007 
            7. Normative References 
              
            [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 
            Requirement Levels", BCP 14, March 1997. 
             
            [RFC 3435] F. Andreasen, B. Foster, "Media Gateway Control Protocol 
            (MGCP) Version 1.0", January 2003. 
             
            [RFC 3611] T. Friedman, R. Caceres, A. Clark, "RTP Control Protocol 
            Extended Reports (RTCP XR)", November 2003. 
             
            [RFC 3550] H. Schulzrinne, S.  Casner, R. Frederick and V. Jacobson, 
            "RTP: A Transport Protocol for Real-Time Applications", July 2003. 
             
            [RFC 2327] M.Handley and V. Jacobson, "SDP: Session Description 
            Protocol", April 1998. 
             
            [RFC 3660] B.Foster and F.Andreasen, "Basic Media Gateway Control 
            Protocol (MGCP) Packages", December 2003. 
             
            [RFC 2234] D.Crocker and P.Overell, "Augmented BNF for Syntax 
            Specifications: ABNF", November 1997.  
             
            [RFC 3261] J.Rosenberg, H.Schulzrinne, G.Camarillo, A.Johnston, 
            J.Peterson, R.Sparks, M.Handley, E.Schooler, "SIP: Session Initiation 
            Protocol", June 2002. 
             
            [RFC 2198] C.Perkins, I.Kouvelas, O.Hodson, V.Hardman, M.Handley, 
            J.C.Balot, A.Vega-Garcia and S. Fosse-Parisis, "RTP Payload for 
            Redundant Audio Data", September 1997. 
             
            [RFC 2733] J.Rosenberg, H.Schulzrinne, "An RTP Payload format for 
            Generic Forward Error Correction", December 1999. 
             
            [IANA RTP]  http://www.iana.org/assignments/media-types/audio/. 
             
            [US-ASCII]     Coded Character Set--7-Bit American Standard Code for 
            Information Interchange, ANSI X3.4-1986. 
             
            [ITU V.152] Procedures for supporting Voice-Band Data over IP Networks, 
            ITU V.152, January 2005.  
             
            [FAX PKG] draft-andreasen-mgcp-fax-04.txt, Media Gateway Control 
            Protocol Fax Package, F. Andreasen. 
             
            [RFC 4103] RTP Payload for Text Conversation, Gunnar Hellstrom and Paul 
            Jones. 
             
            Kumar et al            Informational                Page 56 
            MGCP RTCP-XR Package                             4/12/2007 
            [ITU V.150.1] Modem-over-IP networks: Procedures for the end-to-end 
            connection of V-series DCEs, ITU V.150.1, January 2003. 
             
            [ITU V.151] Procedures for the end-to-end connection of analogue PSTN 
            text telephones over an IP network utilizing Text Relay, 
            Telecommunications Industries Association (TIA) Technical Draft TR-
            30.1/05-03-006, Tampa, FL,  Feb 28 - March4, 2005. 
             
            [ITU T.140]  Protocol for multimedia application text conversation,  
            February 1998. Also, addendum 1, February 2000. 
             
            [RFC 2793] G. Hellstrom, RTP Payload for Text Conversation. Also, its 
            upcoming successor documents: G. Hellstrom and P. Jones, draft-ietf-
            avt-rfc2793bis-09, and G. Hellstrom and P. Jones, draft-ietf-avt-audio-
            t140c-00. 
             
            [ITU T.35] Procedure for the allocation of ITU-T defined codes for non-
            standard facilities, February 2000. 
             
            [ITU T.38] Procedures for real-time Group 3 facsimile communication 
            over IP networks, September 2005. 
             
            [ITU P.VTQ] Add a reference when ITU P.VTQ becomes a standard for MOS-
            LQ. 
              
            8. Acknowledgments 
             
            Contributors to this document include Alan Clark, Joe Stone, Flemming 
            Andreasen, Robert Biskner, Michael Ramalho, Paul Jones, Steve White, 
            Kevin Connor, Jim Frauenthal, Tom Hock, Prakash Bhat, David Ensign and 
            the PacketCable NCS Specification Team.   
             
            9. Copyright Statement 
             
            Copyright (C) The IETF Trust (2007). 

            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, THE IETF TRUST AND 
            THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
            OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
            INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
            WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

            Kumar et al            Informational                Page 57