Internet Engineering Task Force A. Clark
Internet-Draft Telchemy Incorporated
Expires: 11th May 2007 A. Pendleton
Nortel
December 2006
RTCP XR - IP Video Metrics Report Blocks
draft-ietf-avt-rtcpxr-video-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 11th May 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines extensions to the RTCP XR extended report
packet type blocks to support the monitoring of video over IP
and the associated audio streams, if present, for IPTV and video
conferencing endpoint reporting.
Clark [Page 1]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 2
3. IP Video Metrics Report Block . . . . . . . . . . . . . . . 5
4. IP Video Metrics Compact Format Block . . . . . . . . . . . 12
5. IP Video Metrics Configuration Block . . . . . . . . . . . . 14
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 17
1. Introduction
This draft defines several new block types to augment those defined
in RFC3611 for use in Quality of Service reporting for video over IP.
The new block types defined in this draft are the IP Video Metrics
Report Block, and the IP Video Metrics Configuration Block. It
is intended to support both the identification of problems affecting
performance and the collection of data that may be useful in
optimizing system configuration.
Video performance may be measured using zero (no) reference, partial
(reduced) reference or full reference. The primary application of
this draft is to support the reporting of real-time, in-service
performance obtained using a zero or partial reference model however
this approach could also be used to support the remote reporting of
metrics from a full reference test.
2. Definitions
2.1 Reporting Endpoint
A report block produced per this draft is produced by the receiving
endpoint of an RTP stream, and relates to the quality of the received
stream and impairments that may affect perceived quality. A single
report block relates to an individual video stream.
2.2 Protocol layering
Packet video may be encapsulated in RTP, MPEG-2 Transport or other
video transport protocols. Some implementations encapsulate one
transport protocol within another, for example MPEG-2 Transport over
RTP.
Clark [Page 2]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
Video transport protocols may be carried over TCP, UDP, Reliable UDP
and may be unicast, multicast or broadcast. Some implementations use
combinations of these, for example multicast transmission with
unicast retransmission. Forward Error Correction (FEC) may also be
used to correct (replace) lost packets.
The video stream comprises a series of I frames, which are intra-
frame encoded, and potentially P and B frames, which are interframe
encoded. The effects of packet loss can vary considerably depending
on the type of frame being impacted.
This draft supports the reporting of metrics related to each layer.
2.2 Cumulative and Interval Metrics
Cumulative metrics relate to the entire duration of the session to
the point at which metrics are determined and reported, and are
typically used to report session quality. Cumulative metrics
generally result in a lower volume of data that may need to be
stored, as each report supersedes earlier reports.
Interval metrics relate to the period since the last Interval report.
Interval data may be easier to correlate with specific network events
for which timing is known, and may also be used as a basis for
threshold crossing alerts.
Note that interval metrics for the start and end of sessions may be
unreliable due to factors such as irregular interval length and the
difficulty in knowing when packet transmission started and ended.
2.3 Metrics related to packet loss distribution
The distribution of lost packets can have a material impact on the
quality of a decoded video stream as packets tend to be lost in
high loss periods or bursts.
The terms Burst and Gap are used in a manner consistent with that of
RTCP XR (RFC3611). A Gap is a period of time between Bursts such
that any lost or discarded packets or frames are separated by some
number of "good" packets or frames. A Burst is a period of time that
fails the test for a Gap, and hence corresponds to a degraded quality
period. The recommended value for Gmin in RFC3611 resulted in a
Burst being a period of time during which the packet loss/discard
rate exceeded 5%. As video is generally more sensitive to packet loss
this report block recommends a larger value for Gmin.
Some video decoders do not properly handle out-of-sequence packets
and may discard them. The term "discarded" is used to relate to
packets that have been discarded due to late arrival or arrival
out-of-sequence.
Burst metrics may be used to identify "worst case" settings for FEC
or peak bandwidth for retransmission based protocols.
Clark [Page 3]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
(i) FEC configuration
The burst loss rate represents the average packet loss rate during
worst case conditions. If the loss rate correctable by FEC is
greater than the burst loss rate, then most bursts of packet loss
should be corrected.
(ii) Peak bandwidth
Each lost packet that occurs during a burst period would potentially
be retransmitted. The peak retransmitted packet rate will therefore
be equivalent to the burst packet loss rate.
The term Loss Period is used in the sense defined by IPPM in RFC3357
and relates to a period of consecutive loss.
2.4 Absolute and Relative MOS scores
The term MOS (Mean Opinion Score) is used in subjective testing and
hence is a range that has a known relationship to "quality". The
term can however be confusing when used with services that are not
similar. For example, should the MOS score associated with a high
definition TV service be the same as that associated with video
displayed on a mobile handset? This can make it hard to understand
what a MOS score such as 3.1 for a mobile service means - is this
the result of degradation or just the result of the smaller display
size?
The term Absolute MOS is used in this draft to indicate a MOS score
that considers image resolution, frame rate, codec and compression
level, the effects of transmission impairments and frame loss
concealment, but not the physical size of the display.
The term Relative MOS is used in this draft to indicate a MOS score
that is expressed relative to the ideal for this codec and image
resolution.
For example, a mobile handset service has an Absolute MOS of 3.1
and a Relative MOS of 4.4. This indicates that the service is close
to ideal for the application but that some degradation is occurring.
2.5 Numeric formats
This report block makes use of binary fractions. The terminology
used is
S X:Y, where S indicates a signed representation,
X the number of bits prior to the decimal place and
Y the number of bits after the decimal place.
Hence 8:8 represents an unsigned number in the range 0.0039 to
255.996.
Clark [Page 4]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
3 Video Metrics Report Block
3.1 Block Description
This block comprises a header and a series of sub-blocks. The
Map field in the header defines which sub-blocks are present.
Header sub-block (Required)
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=N | Map | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Layer Loss Metrics sub-block (Required)
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pre-EC Loss Rate | Post-EC Loss Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of IP packets expected |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP Metrics sub-block (Optional)
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Network PDV | Peak smoothing PDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Rate | Discard Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPEG Transport Metrics sub-block (Optional)
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Video Stream PID | Audio Stream PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Video Stream Loss Rate | Audio Stream Loss Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCR Jitter | Discard Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clark [Page 5]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
Packet Loss/Discard Distribution Metrics Sub-block (Required)
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Duration (ms) | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Duration (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Loss/Disc Proportion | Gap Loss/Disc Proportion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Loss Period | Mean Loss Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Video/Audio Metrics sub-block (Required)
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Full Frame Loss Rate | Interpolated Frame Loss Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSTQ - Transmission Quality | VSCQ - Control Quality |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MOS-A - Audio Quality | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute MOS-V | Relative MOS-V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute MOS-AV | Relative MOS-AV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Video bit rate (bits/sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Audio bit rate (bits/sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A-V Delay (Network I/F) | A-V Delay (Video I/F) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round Trip Delay (media) | Round Trip Delay (control) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Playout Buffer Metrics sub-block (Required)
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Playout Interrupt Count | Mean Playout Interrupt Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Playout buffer size | Mean buffer level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2 Header
Implementations MUST send the Header block within each RTCP XR
Video Metrics report.
3.2.1 Block type
Clark [Page 6]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
Three Video Performance Reporting Metrics blocks are defined
mmm = Video Metrics- Cumulative
mmm+1 = Video Metrics- Interval
mmm+2 = Video Metrics- Alert
The time interval associated with these report blocks is left to the
implementation. Spacing of RTCP reports should be in accordance
with RFC3550 however the specific timing of RTCP XR Video reports may
be determined in response to an internally derived alert such as a
threshold crossing.
3.2.2 Map field
A Map field indicates the optional sub-blocks present in this
report. A 1 indicates that the sub-block is present, and a 0 that
the block is absent. If present, the sub-blocks must be in the
sequence defined in this document.
The bits have the following definitions:
0 RTP Metrics block
1 MPEG Transport Metrics block
2-7 Reserved, set to 0
3.2.3 Block Length
The block length indicates the length of this report in 32 bit
words and includes the header and any extension octets.
3.2.5 Correlation tag
The correlation tag facilitates the correlation of this report
block with other call or session related data or endpoint data.
3.3 IP Layer loss metrics sub-block
The IP Layer loss metrics sub-block MUST be present.
This block provides information on IP packet loss, both before
and after the effects of error correction.
3.3.1 Pre-EC Loss Rate
The proportion of IP packets lost before the effects of error
correction (FEC or retransmission), expressed as a binary fraction
in 0:16 format.
3.3.2 Post-EC Loss Rate
The effective proportion of IP packets after before the effects of
error correction, expressed as a binary fraction in 0:16 format.
3.3.3 Number of IP Packets Expected
The number of IP packets that the receiving system estimates that
it should have received.
3.4 RTP Metrics sub-block
Clark [Page 7]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
If RTP is used for media transport, the RTP Metrics sub-block MUST
be present and if present MUST be indicated in the Map field.
This block provides information on the effects of IP transmission
impairments on the RTP stream.
3.4.1 Source SSRC
The SSRC associated with the RTP stream to which this report block
relates.
3.4.2 Average network PDV
The average delay variation of RTP packets due to the effects of
network congestion and buffering.
3.4.3 Peak smoothing PDV
The peak delay variation due to smoothing of the video packet
transmission rate, either by the sending system or network based
rate control. This should be determined by comparing the variation
in arrival time to the variation in RTP time stamp, and observing
any periodicity in the resulting sequence of delay variations.
3.4.4 Loss Rate
The proportion of RTP packets lost in the network, after the effects
of any error correction or retransmission. This should be determined
by comparing the variation in in RTP time stamp, and removing
any periodicity in the resulting sequence of delay variations.
3.4.5 Discard Rate
The proportion of RTP packets discarded due to out-of-sequence, late
or early arrival.
3.5 MPEG-2 Transport Metrics sub-block
The MPEG-2 Transport Metrics sub-block MUST be present if MPEG
Transport is used, and if present MUST be indicated in the Map
field.
This block contains a number of metrics associated with MPEG
transport stream packets.
3.5.1 Video Stream Program ID
The Program ID (PID) associated with the video stream.
3.5.2 Audio Stream Program ID
The Program ID (PID) associated with the audio stream
3.5.3 Loss Rate
The proportion of MPEG Transport Stream packets lost in the
network, after the effects of any error correction or retransmission.
3.5.4 Discard Rate
Clark [Page 8]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
The proportion of MPEG Transport Stream packets discarded due to
late or early arrival.
3.5.5 PCR Jitter
The average PCR (Program Clock Reference) jitter level in
milliseconds for this MPEG Transport Stream.
3.6 Packet Loss/Discard Distribution Metrics sub-block
The Packet Loss/Discard Distribution Metrics sub-block MUST be
present.
This block contains metrics that describe the time distribution
of lost and discarded packets after the effects of any error
correction.
3.6.1 Burst duration
The duration of bursts of lost and discarded RTP packets
expressed in milliseconds.
3.6.2 Gmin Threshold
The Gmin threshold associated with the definition of bursts and
gaps.
3.6.3 Gap duration
The mean duration of gaps between bursts expressed in milliseconds.
3.6.4 Burst loss/discard proportion
The proportion of frames lost or discarded during burst periods
expressed as a binary fraction.
3.6.5 Gap loss/discard proportion
The proportion of frames lost or discarded during burst periods
expressed as a binary fraction.
3.6.6 Maximum Loss Period
The maximum number of consecutive lost packets during this session.
3.6.7 Mean Loss Period
The mean number of consecutive lost packets during this session.
3.7 Video/Audio Metrics sub-block
The Video/Audio Metrics sub-block MUST be present.
The metrics in this block provide information on the quality of the
video stream.
3.7.1 Full frame packet loss rate
The packet loss rate that affected full or intra-frame encoded
video frames (I frames).
3.7.2 Interpolated frame packet loss rate
Clark [Page 9]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
The packet loss rate that affected interpolated or inter-frame
encoded video frames (B/P frames).
3.7.3 VSTQ - Video Service Transmission Quality
The video service transmission quality expressed as a score in the
range 0.0 to 50.0. This is a codec independent measure of the
ability of the bearer channel to support reliable video.
3.7.4 VSCQ - Video Service Control Plane Quality
The video service control plane (trick play) quality expressed as
a score in the range 0.0 to 50.0. This is a measure that is related
to the performance of the video stream control channel.
3.7.5 MOS-A Audio Quality
The video service audio quality expressed as a score in the range
1.0 to 5.0. This is an audio codec dependant measure that is
related to the subjective quality of the decoded audio stream(s).
(ATIS)
3.7.6 Absolute MOS-V Picture Quality
The absolute picture quality expressed as a score in the range
1.0 to 5.0. This is a codec dependant measure that is related to
the subjective quality of the decoded video stream and considers
the effects of codec, loss, bit rate/ quantization level, image
resolution and frame loss concealment.
3.7.7 Relative MOS-V Picture Quality
Picture quality expressed as a score relative to an ideal picture
with the same configuration.
3.7.8 Absolute MOS-AV Multimedia Quality
The multimedia quality expressed as a score in the range 1.0 to 5.0.
This is a composite audio/video measure that is related to the
overall subjective user experience and considers picture quality,
audio quality and audio/video synchronization.
3.7.9 Relative MOS-AV Multimedia Quality
Multimedia quality expressed as a score relative to an ideal video
and audio with the same configuration.
3.7.10 Video bit rate
The short term average bit rate of the video codec.
3.7.11 Audio bit rate
The short term average bit rate of the audio codec.
3.7.12 Audio-Video Delay (Network Interface)
The relative delay between audio and video measured before the
decoder and expressed in milliseconds
3.7.13 Audio-Video Delay (Video Interface)
The relative delay between audio and video measured after the
decoder and expressed in milliseconds
Clark [Page 10]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
3.7.14 Round Trip Delay (Media)
The round trip delay for the media path, required only for
interactive video sessions.
3.7.15 Round Trip Delay (Control)
The round trip delay for the video control (trick play) path.
3.8 Playout Buffer Metrics sub-block
The Playout Buffer Metrics sub-block MUST be present.
3.8.1 Playout Interruption Count
The number of interruptions in video playout that have occurred due
to playout buffer starvation or excessive packet loss.
3.8.2 Mean Playout Interruption Size
The mean size of interruptions in playout, expressed in multiples of
100 milliseconds
3.8.3 Playout Buffer Size
The playout buffer size, expressed in multiples of 100 milliseconds
3.8.4 Mean Buffer Size
The average playout buffer size expressed in multiples of 100
milliseconds
Clark [Page 11]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
4. RTCP XR Video Metrics - Compact Report Block
4.1 Block description
This block provides a compact alternative to the Video Metrics
report block for bandwidth or MTU size constrained applications.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=N | reserved | block length=9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pre-EC Loss Rate | Post-EC Loss Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Rate | Burst density | Gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst duration | Gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round trip delay | Peak Smoothing Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Jitter |Relative MOS-V | Abs MOS-V |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Relative MOS-AV| Abs MOS-AV | MOS-A | A-V Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Playout Interrupt Count | Mean Playout Interrupt Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Playout buffer size | Mean buffer level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Header
Three Compact Video Report Blocks are defined
mmm+3 = Compact Video Metrics- Cumulative
mmm+4 = Compact Video Metrics- Interval
mmm+5 = Compact Video Metrics- Alert
The time interval associated with these report blocks is left to the
implementation. Spacing of RTCP reports should be in accordance
with RFC3550 however the specific timing of RTCP XR Video reports may
be determined in response to an internally derived alert such as a
threshold crossing.
4.3 Metrics
4.3.1 Pre-EC Loss Rate
Pre-Error Correction Loss Rate is defined in Section 3.3.1.
4.3.2 Post-EC Loss Rate
Clark [Page 12]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
Post-Error Correction Loss Rate is defined in Section 3.3.2.
4.3.3 Discard Rate
Discard Rate is defined in Section 3.4.5.
4.3.4 Burst Density
Burst Density is defined in Sections 3.6.4
4.3.5 Gap Density
Gap Density is defined in Section 3.6.5.
4.3.6 Burst Duration
Burst Duration is defined in Section 3.6.1
4.3.7 Gap Duration
Gap Duration is defined in Section 3.6.3
4.3.8 Round Trip Delay
Round Trip Delay is defined in Section 3.7.14.
4.3.9 Peak Smoothing jitter
Smoothing jitter is defined in section 3.4.3
4.3.10 Average Network Jitter
Average netwwork Jitter is defined in Section 3.4.2.
4.3.11 Relative MOS-V
MOS-V is defined in Section 3.7.7.
4.3.12 Absolute MOS-V
MOS-V is defined in Section 3.7.6.
4.3.13 Relative MOS-AV
MOS-AV is defined in Section 3.7.9.
4.3.14 Absolute MOS-AV
MOS-AV is defined in Section 3.7.8.
4.3.15 MOS-A
MOS-A is defined in Section 3.7.5.
4.3.16 A-V Delay
Audio-Video Delay is defined in Section 3.7.12.
4.3.16 Playout Interrupt count
Playout Interrupt Count is defined in Section 3.8.1.
4.3.15 Playout Interrupt size
Playout Interrupt Size is defined in Section 3.8.2.
4.3.14 Playout buffer size
Playout buffer size is defined in Section 3.8.3.
Clark [Page 13]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
4.3.17 Mean buffer size
Mean playout buffer size is defined in Section 3.8.4.
5. RTCP XR Video Metrics Configuration Block
This block type provides a flexible means to describe the algorithms
used for video quality calculation and other data. This block need
only be exchanged occasionally, for example sent once at the start
of a session.
Header sub-block
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 | Map | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Correlation tag
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm sub-block
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alg type | Descriptor len| Algorithm descriptor... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Algorithm descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1 Header
Implementations MUST send the Header block within each Video Metrics
Configuration report.
5.1.1 Block type
One Video Metrics Configuration block is defined
mmm+6 = Video Metric Configuration Block
The time interval associated with these report blocks is left to the
implementation. Spacing of RTCP reports should be in accordance
with RFC3550 however the specific timing of RTCP XR Video reports may
Clark [Page 14]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
be determined in response to an internally derived alert such as a
threshold crossing.
5.1.2 Map field
A Map field indicates the optional sub-blocks present in this
report. A 1 indicates that the sub-block is present, and a 0 that
the block is absent. If present, the sub-blocks must be in the
sequence defined in this document.
The bits have the following definitions:
0 Correlation Tag
1 Algorithm Descriptor 1
2 Algorithm Descriptor 2
3 Algorithm Descriptor 3
4 Algorithm Descriptor 4
5 Vendor Specific Extension
6-7 Reserved, set to 0
5.1.3 Block Length
The block length indicates the length of this report in 32 bit
words and includes the header and any extension octets.
5.1.4 SSRC
The SSRC of the stream to which this report relates.
5.2 Correlation Tag
The Correlation Tag sub-block MAY be present and if present
MUST be indicated in the map field. This tag facilitates the
correlation of the RTCP XR Video Metrics report blocks
with other session-related data, session-related data or endpoint
data.
An example use case is for an endpoint may convey its version of a
session identifier or a global session identifier via this tag. A
flow measurement tool (sniffer) that is not session-aware can then
forward the RTCP XR reports along with this correlation tag to
network management. Network management can then use this tag to
correlate this report with other diagnostic information such as
session detail records.
The Tag Type indicates the use of the correlation tag. The following
values are defined:
0: IMS Charging Identity (ICID) subfield of the
P-Charging-Vector header specified in RFC 3455.
1: Globally unique ID as specified in ITU-T H.225.0
(Table 20/H.225.0).
2: Conference Identifier, per ITU-T H.225.0
(Table 20/H.225.0).
Clark [Page 15]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
3: SIP Call-ID as defined in RFC 3261.
4: PacketCable Billing Call ID (BCID).
5: Text string using the US-ASCII character set.
6: Octet sting.
7-255: Future growth.
Although the intent of this RFC is to list all currently known
values of usable correlation tags, it is possible that new values
may be defined in the future. An IANA registry of correlation
tags is recommended.
The tag length indicates the overall length of the sub-block in
32 bit words and includes the tag type and length fields.
5.3 Algorithm description
The Algorithm Description sub-block MAY be present however if present
MUST be indicated in the MAP field
The Algorithm descriptor is a bit field which indicates which
algorithm is being described. The bits are defined as:-
Bit 0: MOS-LQ Algorithm
Bit 1: MOS-CQ Algorithm
Bit 2: R-LQ Algorithm
Bit 3: R-CQ Algorithm
Bit 4: Video Monitoring Algorithm
Bit 5: Audio Monitoring Algorithm
Bit 6: Multimedia Monitoring Algorithm
Bit 7: Transmission Quality Monitoring Algorithm
The descriptor length gives the overall length of the descriptor in
32 bit words and includes the algorithm descriptor and length fields.
The 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:
Algorithm descriptor = 0x10 - Video estimation algorithm
Descriptor length = 3 - 3 words
Descriptor = "Alg X" 0x00 - description
6. Summary
This draft defines a full and a compact RTCP XR report block for
video quality reporting. This is intended for in-service monitoring
of video streaming, IPTV and IP videoconferencing services to provide
Clark [Page 16]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
real time performance feedback and support performance management.
7. IANA Considerations
The block type "mmm" will need to be replaced with an IANA assigned
number within those allocated for RTCP XR report blocks (RFC 3611).
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. Acknowledgments
The authors would like to acknowledge Keith Lantz, Kaynam Hedayat,
Satish Kumar for their helpful comments.
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
2905 Premiere Parkway, Suite 280
Duluth, GA 30097
Email: alan@telchemy.com
Amy Pendleton
Nortel
2380 Performance Drive
Richardson, TX 75081
Email: aspen@nortel.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
Clark [Page 17]
draft-ietf-avt-rtcpxr-video-00.txt December 2006
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 [Page 18]
Datatracker
Report a datatracker bug
draft-ietf-avt-rtcpxr-video-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| Replaces | draft-clark-avt-rtcpxr-video | ||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |