Internet Engineering Task Force A. Clark Internet-Draft Telchemy Incorporated Expires: January 8, 2005 A. Pendleton Nortel Networks R. Kumar Cisco Systems July 2005 RTCP XR - New Parameter Extensions draft-clark-avt-rtcpxr-bis-00 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 December 8, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides suggested extensions to the extended report (XR) packet type blocks for the RTP control protocol (RTCP) for voice over IP (VoIP) monitoring. Additionally, new block types will be defined for other media types such as video. Clark, Pendleton, Kumar Expires January 8, 2006 [Page 1] Internet-Draft RTCP XR - New Parameter Extensions July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. High Resolution VoIP Metrics Report Blocks . . . . . . . . . 2 4. Voice Quality Metric Algorithm Report Block . . . . . . . . . 8 5. Modem/ Fax Metric Report Blocks . . . . . . . . . . . . . . . 9 6. Video Metrics Report Block . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . .10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .10 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .10 10. Informative References . . . . . . . . . . . . . . . . . . . .10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . Intellectual Property and Copyright Statements . . . . . . . . 1. Introduction This draft proposes several new block types to augment those defined in RFC3611 for use in Quality of Service reporting for multimedia applications. The block types described include: - High resolution VoIP performance metrics blocks - Modem/ Fax performance metrics blocks - Video performance metrics blocks 2. Requirements 3. High Resolution VoIP Metrics Report Blocks For certain types of VoIP service it is desirable to report VoIP performance metrics to a higher resolution than provided in the RFC3611 VoIP Metrics block or RFC3550 Receiver Reports. The report blocks described in this section provide both interval based and cumulative metrics with a higher resolution than that provided in the RFC3611 VoIP metrics report block. Clark, Pendleton, Kumar Expires January 8, 2006 [Page 2] Internet-Draft RTCP XR - New Parameter Extensions July 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=N | Extended | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss percentage | Discard percentage | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Loss/Disc Percentage | Gap Loss/Disc Percentage | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Round Trip Delay | End System Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Delay | Mean PDV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max PDV |PDV Percentile | Jitter Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signal level | noise level | RERL | Metric Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R-LQ Ext In | R-LQ Ext Out | R-LQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R-CQ | MOS-LQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MOS-CQ | Payload Type | Media Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JB config | Gmin | JB nominal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JB maximum | JB abs max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Desc | Descriptor Len| Sample Rate | Frames per Pkt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Size (octets) | Frame size (mS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload descriptor (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T.35 Country Code | T.35/IANA Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID Src | Reserved | Extension Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor specific extension data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clark, Pendleton, Kumar Expires January 8, 2006 [Page 3] Internet-Draft RTCP XR - New Parameter Extensions July 2005 3.2 Header Four additional blocks are defined Block types: HR VoIP Metrics - Cumulative - Locally Generated HR VoIP Metrics - Cumulative - Relayed from Remote Endpoint HR VoIP Metrics - Interval - Locally Generated HR VoIP Metrics - Interval - Relayed from Remote Endpoint An extension octet indicates that the block contains a vendor specific extension field. A value of 0 indicates no extension, a value of 1 indicates a T.35 Vendor ID and a value of 2 indicates a proprietary format. The block length indicates the length of this report in 32 bit words and includes any extension octets. Note that variable length fields have been appended to this block to allow systems that cannot accomodate variable length RTCP payloads to ignore these fields. 3.3 Correlation tag A correlation tag has been added to facilitate the correlation of this payload with other call or session related data or endpoint data. 3.4 Loss/ Discard Metrics The definitions of loss, discard, burst and gap are identical to those defined in RFC3611 however the resolution of the reported metrics is extended to 16 bit for loss/ discard and 32 bit for durations. Loss/ discard rates are reported as percentages in 8:8 format (i.e. 1.3% = 01 4C). 3.5 Delay Metrics Delay metrics are essentially as per RFC3611 however a new External Network Delay parameter has been added (in RFC3611 this could be optionally included in End System Delay). This parameter is intended to indicate external network round trip delay through cellular, satellite or other types of network with significant delay impact. 3.6 PDV/Jitter Metrics Jitter metrics defined are: (i) Mean PDV - for cumulative reports this is a running average of PDV and for interval reports this is an interval average (ii) Max PDV - the maximum PDV associated with the PDV percentile Clark, Pendleton, Kumar Expires January 8, 2006 [Page 4] Internet-Draft RTCP XR - New Parameter Extensions July 2005 (iii)PDV Percentile - the percentage of time on the call during which PDV was below Max PDV (iv) PDV type - indicates PPDV (0), MAPDV (1), Y.1540 (2) For example:- (a) To report PPDV (RFC3550): Mean PDV = PPDV Max PDV = Undefined (FF FF) PDV Percentile = Undefined (FF) PDV type = 0 PPDV (b) To report 95th percentile MAPDV (G.1020): Mean PDV = average MAPDV Max PDV = Max MAPDV PDV Percentile = 95 PDV type = 1 MAPDV Note that implementations may either fix the reported percentile and calculate the associated PDV level OR may fix a threshold PDV level and calculate the associated percentile. 3.7 Analog Signal Parameters The definitions of Signal, Noise and RERL are as described in RFC3611 however it is permitted to include assumed values if measured values are not present. The Metric Status byte indicates which are measured and which are assumed values. 3.8 Metric Status Indicates the source of analog parameter values used in call quality calculation: Bit Description Value = 0 Value = 1 Source 0 Local signal level assumed measured (a) 1 Remote signal level assumed measured (b) 2 Local noise level assumed measured (a) 3 Remote noise level assumed measured (b) 4 Local echo level assumed measured (c) 5 Remote echo level assumed measured (d) 6,7 Reserved Clark, Pendleton, Kumar Expires January 8, 2006 [Page 5] Internet-Draft RTCP XR - New Parameter Extensions July 2005 (a) Measured on the incoming decoded VoIP stream prior to level shifts applied in the endpoint (b) Measured by the remote endpoint for the decoded VoIP stream and reported to this endpoint through RTCP XR or equivalent or measured by this endpoint for the outgoing encoded VoIP stream. (c) Measured in the incoming line/ trunk/ handset direction at this endpoint after the effects of echo cancellation (d) Measured in the incoming line/ trunk/ handset direction at the remote endpoint after the effects of echo cancellation and reported to this endpoint through RTCP XR or equivalent. 3.9 Call Quality Metrics R factor has been split into R-LQ and R-CQ to be consistent with the SIP draft. Both R and MOS have been extended to 8:8 notation to give higher resolution. External R has been split into R-LQ External In and R-LQ External Out however since these are likely to be estimated values 8 bit resolution was maintained. R-LQ External In - measured by this endpoint for incoming connection on "other" side of this endpoint R-LQ External Out - copied from RTCP XR message received from remote endpoint on "other" side of this endpoint e.g. PhoneA <---> Bridge <----> Phone B In XR message from Bridge to Phone A:- - R-LQ = quality for PhoneA ----> Bridge path - R-LQ-ExtIn = quality for Bridge <---- PhoneB path - R-LQ-ExtOut = quality for Bridge -----> PhoneB path This allows PhoneA to assess (i) received quality from the combination of R-LQ measured at A and R-LQ-ExtIn reported by the Bridge to A Clark, Pendleton, Kumar Expires January 8, 2006 [Page 6] Internet-Draft RTCP XR - New Parameter Extensions July 2005 (ii) remote endpoint quality from the combination of R-LQ reported by the Bridge and R-LQ-ExtOut reported by the Bridge 3.10 Configuration parameters These parameters are as defined in RFC3611 3.11 Payload and Media Types The RTP Payload type field and an indication of the type of media. RTP Payload type - as per RFC3551 and http://www.iana.org/assignments/rtp-parameters Media type - 0 = No media present 1 = Narrowband audio 2 = Wideband audio 3 = Fax Relay (T.38) 4 = Voiceband data (V.152) 5 = Modem Relay (V.150.1) 6 = Text Relay (V.151) 7 = Video 3.12 Extended payload description field Field that provides additional payload parameters including sample rate, frames per packet and frame size in octets and milliseconds and can be extended to incorporate a text description of the payload type. For example, the default descriptor length of 2 (words) indicates that the basic parameters are supplied, 3 would indicate that 4 additional bytes of text description are present.... 3.13 Vendor Extension field One or more vendor specific extension blocks may be added. Each has the form Vendor ID, Block Length, Extended Parameters and the block length is defined as including these extension header and extended parameter octets but does not include any subsequent vendor specific extension blocks. This would allow an implementation to skip over a vendor specific extension that it did not understand. The Vendor ID is structured as a Country Code (T.35) followed by a Vendor ID: (i) The first octet of the T.35 County Code contains either a country code from Annex A of ITU Recommendation T.35 followed by 0x00 or an escape code of 0xFF followed by a country code from Annex B of T.35. Clark, Pendleton, Kumar Expires January 8, 2006 [Page 7] Internet-Draft RTCP XR - New Parameter Extensions July 2005 (ii) For a T.35 Vendor ID the ID is allocated by the country or administration referenced by the Country Code. This field is padded with leading zeros if necessary. (iii) The Vendor ID Source field indicates the source of the Vendor ID definition. A value of 1 indicates that the source is a national or regional administration recognized by the ITU. A value of 3 indicates that the vendor ID is an IANA enterprise number. (http://www.iana.org/assignments/enterprise-numbers) 4. Voice Quality Metric Algorithm Block This block type provides a flexible means to describe the algorithms used for call quality calculation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | reserved | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correlation tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CQ descriptor | Descriptor len| CQ Algorithm descriptor... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... CQ Algorithm Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CQ descriptor | Descriptor len| CQ Algorithm descriptor... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... CQ Algorithm Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T.35 Country Code | T.35/IANA Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID SRC | Reserved | Extension Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor specific extension data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1 Header The indicated block type is N The block length indicates the length of this report in 32 bit words and includes any extension octets. 4.2 Correlation tag The correlation tag facilitates the correlation of this payload with other call or session related data or endpoint data. 4.3 Algorithm description The CQ descriptor is a bit field which indicates which algorithm is being described. The bits are defined as:- Clark, Pendleton, Kumar Expires January 8, 2006 [Page 8] Internet-Draft RTCP XR - New Parameter Extensions July 2005 Bit 0: MOS-LQ Algorithm Bit 1: MOS-CQ Algorithm Bit 2: R-LQ Algorithm Bit 3: R-CQ Algorithm The descriptor length gives the overall length of the descriptor in 32 bit words and includes the CQ descriptor and length fields. The CQ algorithm descriptor is a text field that contains the description or name of the algorithm. If the algorithm name is shorter than the length of the field then the trailing octets must be set to 0x00. For example, an implementation may report: CQ descriptor = 0x0F - all algorithms Descriptor length = 3 - 3 words Descriptor = "Alg X" 0x00 - description 4.4 Vendor Extension field One or more vendor specific extension blocks may be added. Each has the form Vendor ID, Block Length, Extended Parameters and the block length is defined as including these extension header and extended parameter octets but does not include any subsequent vendor specific extension blocks. This would allow an implementation to skip over a vendor specific extension that it did not understand. The Vendor ID is structured as Country Code (T.35) followed by Vendor ID: (i) The first octet of the T.35 County Code contains either a country code from Annex A of ITU Recommendation T.35 followed by 0x00 or an escape code of 0xFF followed by a country code from Annex B of T.35. (ii) For a T.35 Vendor ID the ID is allocated by the country or administration referenced by the Country Code. This field is padded with leading zeros if necessary. [Add IANA reference] (iii) The Vendor ID Source field indicates the source of the Vendor ID definition. A value of 1 indicates that the source is a national or regional administration recognized by the ITU. A value of 3 indicates that the vendor ID is an IANA enterprise number. (http://www.iana.org/assignments/enterprise-numbers) 5. Modem/ Fax Metrics Report Blocks Clark, Pendleton, Kumar Expires January 8, 2006 [Page 9] Internet-Draft RTCP XR - New Parameter Extensions July 2005 6. Video Metrics Report Block Burst duration for diff frames Burst duration for full frames Video Quality Metric Video Quality Algorithm 7. IANA Considerations 8. Security Considerations RTCP reports can contain sensitive information since they can provide information about the nature and duration of a session established between two endpoints. As a result, any third party wishing to obtain this information should be properly authenticated and the information transferred securely. 9. Contributors 10. Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [3] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. Authors' Addresses Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 Email: alan@telchemy.com Amy Pendleton Nortel Networks 2380 Performance Drive Richardson, TX 75081 Email: aspen@nortelnetworks.com Rajesh Kumar Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Email: rkumar@cisco.com Clark, Pendleton, Kumar Expires January 8, 2006 [Page 10] Internet-Draft RTCP XR - New Parameter Extensions July 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Clark, Pendleton, Kumar Expires January 8, 2006 [Page 11]