draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07.txt   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08.txt 
INTERNET-DRAFT R. Huang INTERNET-DRAFT R. Huang
Intended Status: Standards Track Huawei Intended Status: Standards Track Huawei
Expires: June 15, 2015 V. Singh Expires: July 8, 2015 V. Singh
Aalto University Aalto University
December 12, 2014 January 4, 2015
RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair
Loss Count Metrics Loss Count Metrics
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08
Abstract Abstract
This document defines an RTP Control Protocol (RTCP) Extended Report This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block that allows reporting of post-repair loss count metrics (XR) Block that allows reporting of post-repair loss count metrics
for a range of RTP applications. for a range of RTP applications.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6
4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 6 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7
6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7
6.3 Contact Information for registrations . . . . . . . . . . . 7 6.3 Contact Information for registrations . . . . . . . . . . . 7
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Metrics Represented Using the Template from RFC 6390 . 8 Appendix A. Metrics Represented Using the Template from RFC 6390 . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1 Introduction 1 Introduction
RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contains RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some
some rough statistics about the data received from the particular rough statistics about the data received from the particular source
source indicated in that block. One of them is the cumulative number indicated in that block. One of them is the cumulative number of
of packets lost, which is called pre- repair loss metric in this packets lost, which is called pre-repair loss metric in this
document. This metric conveys information regarding the total number document. This metric conveys information regarding the total number
of RTP data packets that have been lost since the beginning of the of RTP data packets that have been lost since the beginning of the
RTP session. However, this metric is measured on media stream before RTP session.
any loss repair mechanism, e.g., retransmission [RFC4588] and Forward
Error Correction (FEC) [RFC5109], is applied. Using a repair
mechanism usually results in recovering some or all of the lost
packets. Hence, the sending endpoint cannot assess the performance of
the repair mechanism by observing the change in fraction loss and the
cumulative loss statistics from RTCP SR/RR [RFC3550]. Consequently,
[RFC5725] specifies a post-repair loss Run-length Encoding (RLE) XR
report block to address this issue. The sending endpoint is able to
infer which packets were repaired from the RLE report block, but at
the cost of higher overhead. When applications use multiple XR
blocks, the endpoints may require more concise reporting to save
bandwidth.
This document defines a new XR block type to augment those defined in However, this metric is measured on media stream before any loss
[RFC3611] and complement the report block defined in [RFC5725] for repair mechanism, e.g., retransmission [RFC4588] or Forward Error
use in a range of RTP applications. This new block type reports the Correction (FEC) [RFC5109], is applied. Using a repair mechanism
number of primary source RTP packets that are still lost after usually results in recovering some or all of the lost packets. Hence,
applying one or more loss repair mechanisms. The metrics defined in the sending endpoint cannot assess the performance of the repair
this document are packet level rather than slice/picture level, which mechanism by observing the change in fraction loss and the cumulative
means the partial recovery of a packet will not be regarded as a loss statistics from RTCP SR/RR [RFC3550].
repaired packet. In addition, another metric, repaired loss count,
is also introduced in this report block for calculating the pre- Consequently, [RFC5725] specifies a post-repair loss Run-length
repair loss count during the this range, so that the RTP sender or a Encoding (RLE) XR report block to address this issue. The sending
third-party entity is able to evaluate the effectiveness of the endpoint is able to infer which packets were repaired from the RLE
repair methods used by the system. report block, but the reporting overhead for the packet-by-packet
report block is higher compared to other report blocks.
When applications use multiple XR blocks, the endpoints may require
more concise reporting to save bandwidth. This document defines a new
XR block type to augment those defined in [RFC3611] and complement
the report block defined in [RFC5725] for use in a range of RTP
applications. This new block type reports the post-repair loss count
metric which records the number of primary source RTP packets that
are still lost after applying one or more loss repair mechanisms. In
addition, another metric, repaired loss count, is also introduced in
this report block for calculating the pre-repair loss count during
the this range, so that the RTP sender or a third-party entity is
able to evaluate the effectiveness of the repair methods used by the
system. The metrics defined in this document are packet level rather
than slice/picture level, which means the partial recovery of a
packet will not be regarded as a repaired packet.
The metrics defined in this document belong to the class of The metrics defined in this document belong to the class of
transport-related metrics defined in [RFC6792] and are specified in transport-related metrics defined in [RFC6792] and are specified in
accordance with the guidelines in [RFC6390] and [RFC6792]. These accordance with the guidelines in [RFC6390] and [RFC6792]. These
metrics are applicable to any RTP application, especially those that metrics are applicable to any RTP application, especially those that
use loss repair mechanisms. use loss repair mechanisms.
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 17 skipping to change at page 4, line 21
3 Post-Repair Loss Count Metrics Report Block 3 Post-Repair Loss Count Metrics Report Block
This block reports the number of packets lost after applying repair This block reports the number of packets lost after applying repair
mechanisms to complement the RTCP XR metrics defined in [RFC5725]. mechanisms to complement the RTCP XR metrics defined in [RFC5725].
This packet may be stacked with other RTCP packets to form compound This packet may be stacked with other RTCP packets to form compound
RTCP packets and share the average reporting interval calculated by RTCP packets and share the average reporting interval calculated by
the RTCP method described in [RFC3550]. When comparing this metric the RTCP method described in [RFC3550]. When comparing this metric
with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as
noted in [RFC5725]: Some packets will not be repaired in the current noted in [RFC5725]: Some packets will not be repaired in the current
RTCP interval. Thus it is RECOMMENDED that this report block should RTCP interval, but could be repaired later.
be generated only for those source packets that have no further
chance of being repaired and not for any other packets. This block
needs to specify its own measurement period to avoid ambiguity in
calculating the post-repair loss count. The sequence number range
reported by RTCP SR/RR may contain some sequence numbers of packets
for which repair might still be possible. To avoid the ambiguity, we
use begin sequence number and end sequence number to explicitly
indicate the actual sequence number range that this RTCP XR report
block reports on as the measurement timing. These metrics defined in
this report block are all interval metrics and the measurement of
them is made at the RTP receiver. The relationship between the
metrics in this report block and the pre-repair loss metric of RTCP
XR could be expressed in the following formula:
cumulative number of packets lost = unrepaired loss count + Thus it is RECOMMENDED that this report block should be generated
only for those source packets that have no further chance of being
repaired and not for any other packets. This block needs to specify
its own measurement period to avoid ambiguity in calculating the
post-repair loss count.
The sequence number range reported by RTCP SR/RR may contain some
sequence numbers of packets for which repair might still be possible.
To avoid the ambiguity, we use begin sequence number and end sequence
number to explicitly indicate the actual sequence number range that
this RTCP XR report block reports on as the measurement timing. These
metrics defined in this report block are all interval metrics and the
measurement of them is made at the RTP receiver. The relationship
between the metrics in this report block and the pre-repair loss
metric of RTCP XR could be expressed in the following formula:
cumulative number of packets lost = post-repair loss count +
repaired loss count + to be repaired lost packet repaired loss count + to be repaired lost packet
"cumulative number of packets lost" is the metric from RTCP SR/RR. "cumulative number of packets lost" is the metric from RTCP SR/RR.
"unrepaired loss count" and "repaired loss count" are the metrics "post-repair loss count" and "repaired loss count" are the metrics
defined in this draft. defined in this draft.
The post-repair loss count metrics report block has the following The post-repair loss count metrics report block has the following
format: format:
0 1 2 3 4 0 1 2 3 4
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 0 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 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=PRLR | Reserved | block length = 4 | | BT=PRLR | Reserved | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source | | SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unrepaired loss count | repaired loss count | | post-repair loss count | repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the Post-Repair Loss Count Metrics Report
Block
Block Type (BT): 8 bits Block Type (BT): 8 bits
A Post-Repair Loss Count Metrics Report Block is identified by the A Post-Repair Loss Count Metrics Report Block is identified by the
constant PRLR. constant PRLR.
[Note to RFC Editor: Please replace PRLR with the IANA provided [Note to RFC Editor: Please replace PRLR with the IANA provided
RTCP XR block type for this block.] RTCP XR block type for this block.]
Reserved: 8 bits Reserved: 8 bits
skipping to change at page 5, line 41 skipping to change at page 5, line 45
As defined in Section 4.1 of [RFC3611]. As defined in Section 4.1 of [RFC3611].
begin_seq: 16 bits begin_seq: 16 bits
The first sequence number that this block reports on. The first sequence number that this block reports on.
end_seq: 16 bits end_seq: 16 bits
The last sequence number that this block reports on plus one. The last sequence number that this block reports on plus one.
unrepaired loss count: 16 bits post-repair loss count: 16 bits
Total number of packets finally lost after one or more loss-repair Total number of packets finally lost after applying one or more
methods, e.g., FEC and/or retransmission, during this interval. loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq.
This metric MUST NOT count the lost packets for which repair might This metric MUST NOT count the lost packets for which repair might
still be possible. Note that this metric MUST measure only primary still be possible. Note that this metric MUST measure only primary
source RTP packets. source RTP packets.
repaired loss count: 16 bits repaired loss count: 16 bits
Total number of packets fully repaired after one or more loss- Total number of packets fully repaired after applying one or more
repair methods, e.g., FEC and/or retransmission, during this loss-repair methods, e.g., FEC and/or retransmission, during the
interval. Note that this metric MUST measure only primary source actual sequence number range indicated by begin_seq and end_seq.
RTP packets. Note that this metric MUST measure only primary source RTP
packets.
4 SDP Signaling 4 SDP Signaling
[RFC3611] defines the use of SDP (Session Description Protocol) for [RFC3611] defines the use of SDP (Session Description Protocol) for
signaling the use of RTCP XR blocks. However XR blocks MAY be used signaling the use of RTCP XR blocks. However XR blocks MAY be used
without prior signaling (see section 5 of [RFC3611]). without prior signaling (see section 5 of [RFC3611]).
4.1 SDP rtcp-xr-attrib Attribute Extension 4.1 SDP rtcp-xr-attrib Attribute Extension
This session augments the SDP attribute "rtcp-xr" defined in Section This session augments the SDP attribute "rtcp-xr" defined in Section
skipping to change at page 7, line 30 skipping to change at page 6, line 39
4.2 Offer/Answer Usage 4.2 Offer/Answer Usage
When SDP is used in offer-answer context, the SDP 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 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters
applies. For detailed usage of Offer/Answer for unilateral applies. For detailed usage of Offer/Answer for unilateral
parameters, refer to section 5.2 of [RFC3611]. parameters, refer to section 5.2 of [RFC3611].
5 Security Considerations 5 Security Considerations
It is believed that this RTCP XR block introduces no new security This proposed RTCP XR block introduces no new security considerations
considerations beyond those described in [RFC3611]. This block does beyond those described in [RFC3611]. This block does not provide per-
not provide per-packet statistics, so the risk to confidentially packet statistics, so the risk to confidentiality documented in
documented in Section 7, paragraph 3 of [RFC3611] does not apply. Section 7, paragraph 3 of [RFC3611] does not apply.
An attacker may put incorrect information in the Post-Repair Loss An attacker may put incorrect information in the Post-Repair Loss
Count reports, which will be affect the performance of loss repair Count reports, which will be affect the performance of loss repair
mechanisms. Implementers should consider the guidance in [RFC7202] mechanisms. Implementers should consider the guidance in [RFC7202]
for using appropriate security mechanisms, i.e., where security is a for using appropriate security mechanisms, i.e., where security is a
concern, the implementation should apply encryption and concern, the implementation should apply encryption and
authentication to the report block. For example, this can be achieved authentication to the report block. For example, this can be achieved
by using the AVPF profile together with the Secure RTP profile as by using the AVPF profile together with the Secure RTP profile as
defined in [RFC3711]; an appropriate combination of the two profiles defined in [RFC3711]; an appropriate combination of the two profiles
(an "SAVPF") is specified in [RFC5124]. However, other mechanisms (an "SAVPF") is specified in [RFC5124]. However, other mechanisms
skipping to change at page 8, line 40 skipping to change at page 8, line 4
8.1 Normative References 8.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", RFC "RTP Control Protocol Extended Reports (RTCP XR)",
3611, November 2003. RFC 3611, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
Report Block Type for RTP Control Protocol (RTCP) Extended Report Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", RFC 5725, February 2010. Reports (XRs)", RFC 5725, February 2010.
8.2 Informative References 8.2 Informative References
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
October 2011. October 2011.
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC6709,
September 2012. September 2012.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012. RTP Monitoring Framework", RFC 6792, November 2012.
[RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, April 2014. Security Solution", RFC 7202, April 2014.
Appendix A. Metrics Represented Using the Template from RFC 6390 Appendix A. Metrics Represented Using the Template from RFC 6390
a. Post-Repair RTP Packet Loss Count Metric
a. Unrepaired RTP Packet Loss Count Metric * Metric Name: Post-Repair RTP Packet Loss Count Metric.
* Metric Name: Unrepaired RTP Packet Loss Count Metric
* Metric Description: Total number of RTP packets still lost after * Metric Description: Total number of RTP packets still lost after
loss repair methods are applied. loss repair methods are applied
* Method of Measurement or Calculation: See section 3, Unrepaired * Method of Measurement or Calculation: See section 3, Post-Repair
RTP Packet Loss Count Metric definition. It is directly measured RTP Packet Loss Count Metric definition. It is directly measured
and must be measured for the primary source RTP packets with no and must be measured for the primary source RTP packets with no
further chance of repair. further chance of repair.
* Units of Measurement: This metric is expressed as a 16-bit * Units of Measurement: This metric is expressed as a 16-bit
unsigned integer value. unsigned integer value giving the number of RTP packets.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: This metric relies on the sequence number * Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing. See Section 3, 1st interval to determine measurement timing. See Section 3, 1st
paragraph, for details. paragraph, for details.
* Use and Applications: These metrics are applicable to any RTP * Use and Applications: These metrics are applicable to any RTP
application, especially those that use loss repair mechanisms. See application, especially those that use loss repair mechanisms. See
Section 1 for details. Section 1 for details.
* Reporting Model: See RFC3611. * Reporting Model: See RFC3611.
b. Repaired RTP Packet Loss Count Metric b. Repaired RTP Packet Loss Count Metric
* Metric Name: Repaired RTP Packet Count Metric * Metric Name: Repaired RTP Packet Count Metric.
* Metric Description: The number of RTP packets lost but repaired * Metric Description: The number of RTP packets lost but repaired
after applying loss repair methods. after applying loss repair methods
* Method of Measurement or Calculation: See section 3, Repaired * Method of Measurement or Calculation: See section 3, Repaired
RTP Packet Loss Count Metric definition. It is directly measured RTP Packet Loss Count Metric definition. It is directly measured
and must be measured for the primary source RTP packets with no and must be measured for the primary source RTP packets with no
further chance of repair. further chance of repair.
* Units of Measurement: This metric is expressed as a 16-bit * Units of Measurement: This metric is expressed as a 16-bit
unsigned integer value. unsigned integer value giving the number of RTP packets.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: This metric relies on the sequence number * Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing. See Section 3, 1st interval to determine measurement timing. See Section 3, 1st
paragraph, for details. paragraph, for details.
* Use and Applications: These metrics are applicable to any RTP * Use and Applications: These metrics are applicable to any RTP
application, especially those that use loss repair mechanisms. See application, especially those that use loss repair mechanisms. See
 End of changes. 31 change blocks. 
87 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/