Internet DRAFT - draft-clark-avt-rtcpxr-bis
draft-clark-avt-rtcpxr-bis
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]
