RFC7004
Internet Engineering Task Force (IETF) G. Zorn Request for Comments: 7004 Network Zen Category: Standards Track R. Schott ISSN: 2070-1721 Deutsche Telekom
Q. Wu, Ed.
R. Huang
Huawei
September 2013
RTP Control Protocol (RTCP) Extended Report (XR) Blocks
for Summary Statistics Metrics Reporting
Abstract
This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7004.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
3.1.2. Definition of Fields in Loss Summary
3.2.2. Definition of Fields in Burst/Gap Discard
4.1.2. Definition of Fields in Frame Impairment
Appendix A. Metrics Represented Using the Template from RFC 6390 .16
Contents
Introduction
Summary Statistics Metrics
This document defines three new block types to augment those defined in RFC3611 for use in a range of RTP applications:
o Burst/Gap Loss Summary Statistics Block
o Burst/Gap Discard Summary Statistics Block
o Frame Impairment Statistics Summary Block
The first two block types support the reporting of burst/gap loss and burst/gap discard summary statistics including packet loss/discard proportion, mean, and variance and belong to the class of transport- related end-system metrics defined in RFC6792. These two blocks are intended to be used in conjunction with information from the Burst/Gap Loss Metrics Block RFC6958 or Burst/Gap Discard Metrics Block RFC7003, on which these two blocks therefore depend. The metrics in the Burst/Gap Loss Metrics Block and Burst/Gap Discard Metrics Block are consistent with the definitions of "burst", "gap", "loss", and "discard" in RTCP XR RFC3611.
The third block supports the reporting of detailed video statistics for each frame type, including the number of frames received, lost, and discarded of each frame type in the Group of Pictures (GOP) and additional data allowing the calculation of statistical parameters (e.g., the proportion of each frame type impaired by packet loss and discard). The metrics defined in this block belong to the class of application-level metrics defined in RFC6792.
RTCP and RTCP Extended Reports
The use of RTCP for reporting is defined in RFC3550. RFC3611 defined an extensible structure for reporting using an RTCP Extended Report (XR). This document defines a new Extended Report block for use with RFC3550 and RFC3611.
Performance Metrics Framework
The RTP Monitoring Framework RFC6792 provides guidelines for reporting block format using RTCP XR. Metrics described in this document are in accordance with the guidelines in RFC6792.
Applicability
These metrics are applicable to a wide range of RTP applications and reflect transient IP problems that affect user experience. They can be used to form an accurate assessment of users' quality of experience and influence sender strategies to mitigate the problem.
Terminology
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 RFC 2119 RFC2119.
In addition, the following term is defined:
Frame Type
In many cases, a video frame is compressed using different algorithms. Frame type is used to identify different algorithms for video frames. Two frame types used in the different video algorithms are the Key frame and Derived frames. The Key frame is independently coded without prediction from other pictures and used as a reference frame for predicting other pictures. Derived frames are predicatively coded and derived from a Key frame using a prediction algorithm. If there is no video image compression, all frames are Key frames.
Transport-Related End-System Metrics
Burst/Gap Loss Summary Statistics Block
This block extends packet loss and discard metrics defined in Section 4.7.1 of RFC3611. The metrics described here are intended to be used as described in this section, in conjunction with information from the Measurement Information Block RFC6776 (which MUST be present in the same RTCP packet as the Burst/Gap Loss Metrics Block RFC6958) and also with the metric "cumulative number of packets lost" provided in standard RTCP RFC3550. Instances of this metrics block use the synchronization source (SSRC) to refer to the separate auxiliary Measurement Information Block RFC6776, which describes measurement periods in use (see RFC6776, Section 4.2). This metrics block relies on the measurement period in the Measurement Information Block indicating the span of the report and SHOULD be sent in the same compound RTCP packet as the Measurement Information Block. If the measurement period is not received in the same compound RTCP packet as this metrics block, this metrics block MUST be discarded.
The metrics carried in this metrics block provide information relevant to statistical parameters, including Burst Loss Rate, Gap Loss Rate, Burst Duration Mean, and Burst Duration Variance, and are measured at the receiving end of the RTP stream using burst/gap loss metrics defined in RFC6958 and other information that is sent together with this report block.
Report Block Structure
The structure of the Burst/Gap Loss Summary Statistics Block is as follows.
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=17 | I | Reserved | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Loss Rate | Gap Loss Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Duration Mean | Burst Duration Variance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Definition of Fields in Loss Summary Statistics Block
Block Type (BT): 8 bits
A Burst/Gap Loss Summary Statistics Block is identified by the constant 17.
Interval Metric flag (I): 2 bits
This field is used to indicate whether the burst/gap loss summary statistics metrics are Sampled, Interval, or Cumulative metrics:
I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between successive
metrics reports.
I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative measurements.
I=01: Sampled Value - the reported value is a sampled
instantaneous value.
In this document, the value I=00 is the reserved value and MUST NOT be used.
Reserved: 6 bits
This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and ignored by the receiver (see RFC6709, Section 4.2).
Block Length: 16 bits
The constant 3, in accordance with the definition of this field in Section 3 of RFC 3611 RFC3611.
SSRC of Source: 32 bits
As defined in Section 4.1 of RFC 3611 RFC3611.
Burst Loss Rate: 16 bits
The fraction of packets lost during bursts since the beginning of reception, expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing Packets Lost in Bursts by Total Packets Expected in Bursts, multiplying the result of the division by 32768 (0x8000), and keeping only the integer part. The maximum value is thus 0x8000. Representing this as a formula:
integer-part( (Packets Lost in Bursts / Total Packets Expected in Bursts) * 0x8000 )
If the measurement is unavailable, the value 0xFFFF MUST be reported.
Gap Loss Rate: 16 bits
The fraction of packets lost during gaps since the beginning of reception expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing the difference between number of packets lost and Packets Lost in Bursts by the difference between Packets Expected and Total Packets Expected in Bursts, multiplying the result of the division by 32768 (0x8000), and keeping only the integer part. The maximum value is thus 0x8000. Representing this as a formula:
integer-part ( (number of packets lost - Packets Lost in Bursts)/ (Packets Expected - Total Packets Expected in Bursts) * 0x8000 )
where "number of packets lost" is obtained from standard RTCP RFC3550 and Packets Expected is calculated as the difference between "extended last sequence number" and "extended first
sequence number" (Interval or Cumulative) provided in the Measurement Identity and Information Block RFC6776.
If the measurement is unavailable, the value 0xFFFF MUST be reported.
Note that if the metric is to be calculated on an Interval basis, a difference must be taken between the current and preceding values of "cumulative number of packets lost" in RTCP to obtain the "number of packets lost" for the reporting interval.
Burst Duration Mean: 16 bits
The mean burst duration is obtained as the quotient:
mean = Sum of Burst Durations / Number of Bursts
where "Sum of Burst Durations" and "Number of Bursts" is obtained from the RTCP XR Burst/Gap Loss Metrics Block RFC6958.
If the measurement is unavailable, the value 0xFFFF MUST be reported.
Burst Duration Variance: 16 bits
The variance of the burst duration is obtained using the standard result:
var = ( Sum of Squares of Burst Durations - Number of Bursts * mean^2 ) / (Number of Bursts - 1)
where "Sum of Squares of Burst Durations" and "Number of Bursts" is obtained from the RTCP XR Burst/Gap Loss Metrics Block RFC6958.
If the measurement is unavailable, the value 0xFFFF MUST be reported.
Burst/Gap Discard Summary Statistics Block
This block extends packet loss and discard metrics defined in Section 4.7.1 of RFC3611. The metrics described here are intended to be used as described in this section, in conjunction with information from the Measurement Identity Block RFC6776 (which MUST be present in the same RTCP packet as the Burst/Gap Discard Summary Statistics Block).
These metrics provide information relevant to statistical parameters, including Burst Discard Rate and Gap Discard Rate, and are measured at the receiving end of the RTP stream using burst/gap discard metrics defined in RFC7003 and other information that is sent together with this report block.
Instances of this metrics block use the synchronization source (SSRC) to refer to the separate auxiliary Measurement Information block RFC6776 that describes measurement periods in use (see RFC6776, Section 4.2). This metrics block relies on the measurement period in the Measurement Information Block indicating the span of the report and SHOULD be sent in the same compound RTCP packet as the measurement information block. If the measurement period is not received in the same compound RTCP packet as this metrics block, this metrics block MUST be discarded.
Report Block Structure
The structure of the Burst/Gap Discard Summary Statistics Block is as follows.
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=18 | I | Reserved | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Discard Rate | Gap Discard Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Definition of Fields in Burst/Gap Discard Summary Statistics
Block
Block Type (BT): 8 bits
A Burst/Gap Discard Summary Statistics Block is identified by the constant 18.
Interval Metric flag (I): 2 bits
This field is used to indicate whether the burst/gap discard summary statistics metrics are Sampled, Interval, or Cumulative metrics:
I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between successive
metrics reports.
I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative measurements.
I=01: Sampled Value - the reported value is a sampled
instantaneous value.
In this document, the value I=00 is the reserved value and MUST NOT be used.
Reserved: 6 bits
This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and ignored by the receiver (see RFC6709, Section 4.2).
Block Length: 16 bits
The constant 2, in accordance with the definition of this field in Section 3 of RFC 3611 RFC3611.
SSRC of Source: 32 bits
As defined in Section 4.1 of RFC3611 RFC3611.
Burst Discard Rate: 16 bits
The fraction of packets discarded during bursts since the beginning of reception, expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing Packets Discarded in Bursts by Total Packets Expected in Bursts, multiplying the result of the division by 32768 (0x8000), and keeping only the integer part, according to the formula:
integer-part( (Packets Discarded in Bursts / Total Packets Expected in Bursts) * 0x8000 )
If the measurement is unavailable, the value 0xFFFF MUST be reported.
Gap Discard Rate: 16 bits
The fraction of packets discarded during gaps since the beginning of reception expressed as a fixed point number with the binary point immediately after the left-most bit. This value is calculated by dividing the difference between number of packets discarded and Packets Discarded in Bursts by the difference between Packets Expected and Total Packets Expected in Bursts,
multiplying the result of the division by 32768 (0x8000), and keeping only the integer part. The maximum value is thus 0x8000. Representing this as a formula:
integer-part( (number of packets discarded - Packets Discarded in Bursts) /(Packets Expected - Total Packets Expected in Bursts) * 0x8000 )
where "number of packets discarded" is obtained from the RTCP XR Discard Count Block RFC7002 and filled with the sum of packets discarded due to early arrival (DT=1) and packets discarded due to late arrival (DT=2) and Packets Expected is calculated as the difference between "extended last sequence number" and "extended first sequence number" (Interval or Cumulative) provided in the Measurement Information Block RFC6776. In order for the Burst/ Gap Discard Summary Statistics Block to be meaningful, 2 instances of the Discard Count Block with DT=1 and DT=2 MUST be included in the same RTCP XR packet as the Burst/Gap Discard Summary Statistics Block.
If the measurement is unavailable, the value 0xFFFF MUST be reported.
Application-Level Metrics
Frame Impairment Statistics Summary Block
This block extends the statistics summary report mechanism defined in Section 4.6 of RFC3611 and reports statistics on which frame types were affected beyond the information carried in the Statistics Summary Report Block RTCP packet specified in Section 4.6 of RFC3611. Information is measured at the receiving end of the RTP stream and recorded about the number of frames received, lost frames, duplicated frames, and lost partial frames. Such information can be useful for network management and video quality monitoring.
Report Block Structure
The structure of the Frame Impairment Statistics Summary Block is as follows.
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=19 |T| Reserved | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | discarded_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | full_lost_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | partial_lost_frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Definition of Fields in Frame Impairment Statistics Summary
Block
Block Type (BT): 8 bits
A Frame Impairment Statistics Summary Block is identified by the constant 19.
Frame type indicator (T): 1 bit
This field is used to indicate the frame type to be reported. The bit is set to 0 if the full_lost_frames, partial_lost_frames, dup_frames, and discarded_frames fields contain Key frame (reference frame) counts or 1 if they contain Derived frame counts. Note that if both the Key frame and Derivation frame report are sent, they should be sent in the same RTCP compound packet using two Frame Impairment Statistics Summary Blocks.
Reserved: 7 bits
This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and ignored by the receiver (see RFC6709, Section 4.2).
Block Length: 16 bits
The constant 6, in accordance with the definition of this field in Section 3 of RFC 3611 RFC3611.
SSRC of Source: 32 bits
As defined in Section 4.1 of RFC 3611 RFC3611.
begin_seq: 16 bits
As defined in Section 4.1 of RFC 3611 RFC3611.
end_seq: 16 bits
As defined in Section 4.1 of RFC 3611 RFC3611.
Number of discarded frames (discarded_frames): 32 bits
Number of frames discarded in the above sequence number interval.
Number of duplicate frames (dup_frames): 32 bits
Number of duplicate frames received in the above sequence number interval.
Number of full lost frames (full_lost_frames): 32 bits
A frame is either split across multiple packets or carried in only one packet. If the whole frame or all the packets of the frame are lost, this frame is regarded as one full_lost_frame. The full_lost_frames can be inferred from packet(s) that comprise the frame. The full_lost_frames is equivalent to the number of full lost frames in the above sequence number interval.
Number of partial lost frames (partial_lost_frames): 32 bits
When a frame is split across multiple packets and some packets of the frame are lost, this frame is regarded as one partial_lost_frame. The partial_lost_frames can be inferred from packets that comprise the frame. The value of the partial_lost_frames field is equivalent to the number of partial lost frames in the above sequence number interval.
SDP Signaling
RFC 3611 defines the use of SDP (Session Description Protocol) RFC4566 for signaling the use of XR blocks. However, XR blocks MAY be used without prior signaling (see Section 5 of RFC3611).
SDP rtcp-xr Attribute Extension
This section augments the SDP RFC4566 attribute "rtcp-xr" defined in Section 5.1 of RFC3611 by providing three additional values of "xr-format" to signal the use of the report block defined in this document. The ABNF RFC5234 syntax is as follows.
xr-format =/ xr-bglss-block
/ xr-bgdss-block
/ xr-fiss-block
xr-bglss-block = "burst-gap-loss-stat" xr-bgdss-block = "burst-gap-discard-stat" xr-fiss-block = "frame-impairment-stat"
Offer/Answer Usage
When SDP is used in offer/answer context, the SDP Offer/Answer usage defined in RFC3611 for unilateral "rtcp-xr" attribute parameters applies. For detailed usage of Offer/Answer for unilateral parameter, refer to section 5.2 of RFC3611.
IANA Considerations
New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, refer to RFC 3611.
New RTCP XR Block Type Values
This document assigns three new block type values in the "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry":
Name: BGLSS
Long Name: Burst/Gap Loss Summary Statistics Block
Value 17
Reference: Section 3.1
Name: BGDSS
Long Name: Burst/Gap Discard Summary Statistics Block
Value 18
Reference: Section 3.2
Name: FISS
Long Name: Frame Impairment Statistics Summary Block
Value 19
Reference: Section 4.1
New RTCP XR SDP Parameters
This document also registers three new SDP RFC4566 parameters for the "rtcp-xr" attribute in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry":
- "burst-gap-loss-stat"
- "burst-gap-discard-stat"
- "frame-impairment-stat"
Contact Information for Registrations
The contact information for the registrations is:
Qin Wu ([email protected]) 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Security Considerations
The new RTCP XR blocks in this document do not introduce any new security considerations beyond those described in RFC3611.
Acknowledgements
The authors would like to thank Bill Ver Steeg, David R. Oran, Ali Begen, Colin Perkins, Roni Even, Youqing Yang, Wenxiao Yu, Yinliang Hu, Jing Zhao, Ray van Brandenburg, Claire Bi, Dan Romascanu, Alfred Morton, Jr., Klaas Wierenga, Barry Leiba, Robert Sparks, Ralph Droms, and Benoit Claise for their valuable comments and suggestions on this document.
References
Normative References
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC3550 Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
RFC3611 Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
RFC4566 Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
RFC5234 Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
RFC6776 Clark, A. and Q. Wu, "Measurement Identity and Information
Reporting Using a Source Description (SDES) Item and an
RTCP Extended Report (XR) Block", RFC 6776, October 2012.
RFC6958 Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control
Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
Loss Metric Reporting", RFC 6958, May 2013.
RFC7002 Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Discard Count Metric
Reporting", RFC 7002, September 2013.
RFC7003 Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control
Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
Discard Metric Reporting", RFC 7003, September 2013.
Informative References
RFC6390 Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, October 2011.
RFC6709 Carpenter, B., Aboba, B., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, September 2012.
RFC6792 Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012.
Appendix A. Metrics Represented Using the Template from RFC 6390
a. Burst Loss Rate Metric
* Metric Name: RTP Burst Loss Rate
* Metric Description: The fraction of packets lost during bursts
since the beginning of reception for RTP traffic.
* Method of Measurement or Calculation: See Section 3.1.2, Burst
Loss Rate definition.
* Units of Measurement: See Section 3.1.2, Burst Loss Rate
definition.
* Measurement Point(s) with Potential Measurement Domain: See
Section 3.1, 2nd paragraph.
* Measurement Timing: See Section 3.1, 1st paragraph for
measurement timing and Section 3.1.2 for Interval Metric flag.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
b. Gap Loss Rate Metric
* Metric Name: RTP Gap Loss Rate
* Metric Description: The fraction of packets lost during gaps
since the beginning of reception for RTP traffic.
* Method of Measurement or Calculation: See Section 3.1.2, Gap
Loss Rate definition.
* Units of Measurement: See Section 3.1.2, Gap Loss Rate
definition.
* Measurement Point(s) with Potential Measurement Domain: See
Section 3.1, 2nd paragraph.
* Measurement Timing: See Section 3.1, 1st paragraph for
measurement timing and Section 3.1.2 for Interval Metric flag.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
c. Burst Duration Mean Metric
* Metric Name: RTP Burst Duration Mean
* Metric Description: The mean duration of the burst periods
that have occurred since the beginning of reception for RTP
traffic.
* Method of Measurement or Calculation: See Section 3.1.2, Burst
Loss Rate definition.
* Units of Measurement: This metric is expressed in
milliseconds.
* Measurement Point(s) with Potential Measurement Domain: See
Section 3.1, 2nd paragraph.
* Measurement Timing: See Section 3.1, 1st paragraph for
measurement timing and Section 3.1.2 for Interval Metric flag.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
d. Burst Duration Variance Metric
* Metric Name: RTP Burst Duration Variance
* Metric Description: The variance duration of the burst periods
that have occurred since the beginning of reception for RTP
traffic.
* Method of Measurement or Calculation: See Section 3.1.2, Burst
Duration Variance definition.
* Units of Measurement: See Section 3.1.2, Burst Duration
Variance definition.
* Measurement Point(s) with Potential Measurement Domain: See
Section 3.1, 2nd paragraph.
* Measurement Timing: See Section 3.1, 1st paragraph for
measurement timing and Section 3.1.2 for Interval Metric flag.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
e. Burst Discard Rate Metric
* Metric Name: RTP Burst Discard Rate
* Metric Description: The fraction of packets discarded during
bursts since the beginning of reception for RTP traffic.
* Method of Measurement or Calculation: See Section 3.2.2, Burst
Discard Rate definition.
* Units of Measurement: See Section 3.2.2, Burst Discard Rate
definition.
* Measurement Point(s) with Potential Measurement Domain: See
Section 3.2, 2nd paragraph.
* Measurement Timing: See Section 3.2, 3rd paragraph for
measurement timing and Section 3.1.2 for Interval Metric flag.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
f. Gap Discard Rate Metric
* Metric Name: RTP Gap Discard Rate
* Metric Description: The fraction of packets discarded during
gaps since the beginning of reception for RTP traffic.
* Method of Measurement or Calculation: See Section 3.2.2, Gap
Discard Rate definition.
* Units of Measurement: See Section 3.2.2, Gap Discard Rate
definition.
* Measurement Point(s) with Potential Measurement Domain: See
Section 3.2, 2nd paragraph.
* Measurement Timing: See Section 3.2, 3rd paragraph for
measurement timing and Section 3.1.2 for Interval Metric flag.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
g. Number of Discarded Frames Metric
* Metric Name: Number of discarded frames in RTP
* Metric Description: Number of frames discarded in a certain
sequence number interval for RTP traffic.
* Method of Measurement or Calculation: See Section 4.1.2,
Number of discarded frames definition. This metric is
directly measured and can be inferred from packet(s) that
comprise the frame.
* Units of Measurement: This metric is expressed as a 32-bit
unsigned integer value.
* Measurement Point(s) with Potential Measurement Domain: See
Section 4.1, 1st paragraph.
* Measurement Timing: See Section 4.1, Number of discarded
frames definition. This metric relies on the sequence number
interval and RTCP RR packet of RFC3550 to determine
measurement timing.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
h. Number of Duplicate Frames Metric
* Metric Name: Number of duplicate frames in RTP
* Metric Description: Number of frames duplicated in a certain
sequence number interval for RTP traffic.
* Method of Measurement or Calculation: See Section 4.1.2,
Number of duplicate frames definition. This metric is
directly measured and can be inferred from packet(s) that
comprise the frame.
* Units of Measurement: This metric is expressed as a 32-bit
unsigned integer value.
* Measurement Point(s) with Potential Measurement Domain: See
Section 4.1, 1st paragraph.
* Measurement Timing: See Section 4.1, Number of duplicate
frames definition. This metric relies on the sequence number
interval to determine measurement timing.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
i. Number of Full Lost Frames Metric
* Metric Name: Number of full lost frames in RTP
* Metric Description: A frame is either split across multiple
RTP packets or carried in only one RTP packet. If the whole
frame or all the packets of the frame is lost, this frame is
regarded as one full_lost_frame.
* Method of Measurement or Calculation: See Section 4.1.2,
Number of full lost frames definition.
* Units of Measurement: This metric is expressed as a 32-bit
unsigned integer value.
* Measurement Point(s) with Potential Measurement Domain: See
Section 4.1, 1st paragraph.
* Measurement Timing: See Section 4.1, Number of full lost
frames definition. This metric relies on the sequence number
interval to determine measurement timing.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
j. Number of Partial Lost Frames Metric
* Metric Name: Number of partial lost frames in RTP
* Metric Description: When a frame is split across multiple RTP
packets and some RTP packets of the frame are lost, this frame
is regarded as one partial_lost_frame.
* Method of Measurement or Calculation: See Section 4.1.2,
Number of partial lost frames definition.
* Units of Measurement: This metric is expressed as a 32-bit
unsigned integer value.
* Measurement Point(s) with Potential Measurement Domain: See
Section 4.1, 1st paragraph.
* Measurement Timing: See Section 4.1, Number of partial lost
frames definition. This metric relies on the sequence number
interval to determine measurement timing.
* Use and Applications: See Section 1.4.
* Reporting Model: See RFC 3611.
Authors' Addresses
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Phone: +66 (0) 909-201060 EMail: [email protected]
Roland Schott Deutsche Telekom Deutsche-Telekom-Allee 7 Darmstadt 64295 Germany
EMail: [email protected]
Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
EMail: [email protected]
Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China
EMail: [email protected]
