draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11.txt   rfc7509.txt 
INTERNET-DRAFT R. Huang Internet Engineering Task Force (IETF) R. Huang
Intended Status: Standards Track Huawei Request for Comments: 7509 Huawei
Expires: August 23, 2015 V. Singh Category: Standards Track V. Singh
Aalto University ISSN: 2070-1721 Aalto University
February 19, 2015 May 2015
RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair RTP Control Protocol (RTCP) Extended Report (XR)
Loss Count Metrics for Post-Repair Loss Count Metrics
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11
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 metric for (XR) block that allows reporting of a post-repair loss count metric
a range of RTP applications. In addition, another metric, repaired for a range of RTP applications. In addition, another metric,
loss count, is also introduced in this report block for calculating repaired loss count, is also introduced in this report block for
the pre-repair loss count when needed so that the RTP sender or a calculating the pre-repair loss count when needed, so that the RTP
third-party entity is able to evaluate the effectiveness of the sender or a third-party entity is able to evaluate the effectiveness
repair methods used by the system. of the repair methods used by the system.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7509.
Copyright and License Notice Copyright Notice
Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................3
3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 3. Post-Repair Loss Count Metrics Report Block .....................3
3.1 Report Block Structure . . . . . . . . . . . . . . . . . . 4 3.1. Report Block Structure .....................................4
3.2 Example Usage . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Example Usage ..............................................5
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. SDP Signaling ...................................................6
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 7 4.1. SDP rtcp-xr-attrib Attribute Extension .....................6
4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 7 4.2. Offer/Answer Usage .........................................7
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations .........................................7
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations .............................................7
6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7 6.1. New RTCP XR Block Type Value ...............................7
6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 8 6.2. New RTCP XR SDP Parameter ..................................7
6.3 Contact Information for registrations . . . . . . . . . . . 8 6.3. Contact Information for Registrations ......................7
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References ......................................................8
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References .......................................8
8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References .....................................9
8.2 Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Metrics Represented Using the Template from RFC 6390 ..10
Appendix A. Metrics Represented Using the Template from RFC 6390 . 9 Acknowledgments ...................................................11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses ................................................11
1 Introduction 1. Introduction
RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some RTCP Sender Reports (SRs) / Receiver Reports (RRs) [RFC3550] contain
rough statistics about the data received from the particular source some rough statistics about the data received from the particular
indicated in that block. One of them is the cumulative number of source indicated in that block. One of them is the cumulative number
packets lost, which is called pre-repair loss metric in this of packets lost, which is called the 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. RTP session.
However, this metric is measured on media stream before any loss However, this metric is measured on the media stream before any loss-
repair mechanism, e.g., retransmission [RFC4588] or Forward Error repair mechanism, e.g., retransmission [RFC4588] or Forward Error
Correction (FEC) [RFC5109], is applied. Using a repair mechanism Correction (FEC) [RFC5109], is applied. Using a repair mechanism
usually results in recovering some or all of the lost packets. Hence, usually results in recovering some or all of the lost packets. The
the sending endpoint cannot assess the performance of the repair recovery process does not reduce the values reported by the two loss
mechanism by observing the change in fraction loss and the cumulative metrics in RTCP RR [RFC3550] -- namely, the fraction lost and the
loss statistics from RTCP SR/RR [RFC3550]. cumulative loss. Hence, the sending endpoint cannot infer the
performance of the repair mechanism based on the aforementioned
metrics in [RFC3550].
Consequently, [RFC5725] specifies a post-repair loss Run-length Consequently, [RFC5725] specifies a post-repair loss Run-Length
Encoding (RLE) XR report block to address this issue. The sending Encoding (RLE) XR report block to address this issue. The sending
endpoint is able to infer which packets were repaired from the RLE endpoint is able to infer which packets were repaired from the RLE
report block, but the reporting overhead for the packet-by-packet report block, but the reporting overhead for the packet-by-packet
report block is higher compared to other report blocks. report block is higher compared to other report blocks.
When applications use multiple XR blocks, the endpoints may require When applications use multiple XR blocks, the endpoints may require
more concise reporting to save bandwidth. This document defines a new more concise reporting to save bandwidth. This document defines a
XR block type to augment those defined in [RFC3611] and complement new XR block type to augment those defined in [RFC3611] and
the report block defined in [RFC5725] for use in a range of RTP complement the report block defined in [RFC5725] for use in a range
applications. This new block type reports the post-repair loss count of RTP applications. This new block type reports the post-repair
metric which records the number of primary source RTP packets that loss count metric, which records the number of primary source RTP
are still lost after applying one or more loss repair mechanisms. In packets that are still lost after applying one or more loss-repair
addition, another metric, repaired loss count, is also introduced in mechanisms. In addition, another metric, repaired loss count, is
this report block for calculating the pre-repair loss count during also introduced in this report block for calculating the pre-repair
this range, so that the RTP sender or a third-party entity is able to loss count during this range, so that the RTP sender or a third-party
evaluate the effectiveness of the repair methods used by the system. entity is able to evaluate the effectiveness of the repair methods
The metrics defined in this document are packet level rather than used by the system. The metrics defined in this document are packet
slice/picture level, which means the partial recovery of a packet level rather than slice/picture level; this means the partial
will not be regarded as a repaired packet. 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
primary source RTP packet: The original RTP packet sent from the RTP primary source RTP packet: The original RTP packet sent from the RTP
sender for the first time. A lost primary source RTP packet may be sender for the first time. A lost primary source RTP packet may
repaired by some other RTP packets used in repair mechanisms like FEC be repaired by some other RTP packets used in repair mechanisms
or retransmission. like FEC or retransmission.
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 (e.g., FEC). It complements the RTCP XR metrics defined mechanisms (e.g., FEC). It complements the RTCP XR metrics defined
in [RFC5725]. As noted in [RFC5725], ambiguity may occur when in [RFC5725]. As noted in [RFC5725], ambiguity may occur when
comparing this metric with pre-repair loss metric reported in an RTCP comparing this metric with a pre-repair loss metric reported in an
SR/RR, i.e., some packets were not repaired in the current RTCP RTCP SR/RR, i.e., some packets were not repaired in the current RTCP
interval, but they may be repaired later. Therefore, this block uses interval, but they may be repaired later. Therefore, this block uses
a begin sequence number and an end sequence number to explicitly a begin sequence number and an end sequence number to explicitly
indicate the actual sequence number range reported by this RTCP XR. indicate the actual sequence number range reported by this RTCP XR.
Accordingly, only packets that have no further chance of being Accordingly, only packets that have no further chance of being
repaired and that have been repaired are included in this report repaired and that have been repaired are included in this report
block. block.
3.1 Report Block Structure 3.1. Report Block Structure
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=33 | Reserved | Block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source | | SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| post-repair loss count | repaired loss count | | Post-repair loss count | Repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 33.
[Note to RFC Editor: Please replace PRLR with the IANA provided
RTCP XR block type for this block.]
Reserved: 8 bits Reserved: 8 bits
These bits are reserved for future use. They MUST be set to zero These bits are reserved for future use. They MUST be set to zero
by senders and ignored by receivers (see [RFC6709], Section 4.2). by senders and ignored by receivers (see Section 4.2 of
[RFC6709]).
block length: 16 bits Block length: 16 bits
This field is in accordance with the definition in [RFC3611]. In This field is in accordance with the definition in [RFC3611]. In
this report block, it MUST be set to 4. The block MUST be this report block, it MUST be set to 4. The block MUST be
discarded if the block length is set to a different value. discarded if the block length is set to a different value.
SSRC of source: 32 bits SSRC of source: 32 bits
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. It can The first sequence number that this block reports on. It can
remain fixed when calculating metrics over several RTCP reporting remain fixed when calculating metrics over several RTCP reporting
intervals. intervals.
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.
post-repair loss count: 16 bits Post-repair loss count: 16 bits
Total number of packets finally lost after applying one or more Total number of packets finally lost after applying one or more
loss-repair methods, e.g., FEC and/or retransmission, during the loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq. 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
source RTP packets. primary source RTP packets.
repaired loss count: 16 bits Repaired loss count: 16 bits
Total number of packets fully repaired after applying one or more Total number of packets fully repaired after applying one or more
loss-repair methods, e.g., FEC and/or retransmission, during the loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq. actual sequence number range indicated by begin_seq and end_seq.
Note that this metric MUST measure only primary source RTP Note that this metric MUST measure only primary source RTP
packets. packets.
3.2 Example Usage 3.2 Example Usage
The metrics defined in this report block are all measured at the RTP The metrics defined in this report block are all measured at the RTP
receiver. However, the receiving endpoint can report the metrics in receiver. However, the receiving endpoint can report the metrics in
two different ways: two different ways:
1. Cumulative report 1) Cumulative report
In this case, implementations may set begin_seq to the first packet In this case, implementations may set begin_seq to the first packet
in the RTP session and it will remain fixed across all reports. in the RTP session, and it will remain fixed across all reports.
Hence, the "post-repair loss count" and "repaired loss count", Hence, the "Post-repair loss count" and "Repaired loss count",
respectively will correspond to "cumulative post-repair loss count" respectively, will correspond to "Cumulative post-repair loss count"
and "cumulative repaired loss count" in this case. These cumulative and "Cumulative repaired loss count" in this case. These cumulative
metrics when combined with the cumulative loss metrics reported in an metrics when combined with the cumulative loss metrics reported in an
RTCP RR (pre-repair) assists in calculating the still to be repaired RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired
lost packets: lost packets":
still to be repaired lost packet = cumulative number of packets Still-to-be-repaired lost packets =
lost - cumulative post-repair loss count - cumulative repaired Cumulative number of packets lost -
loss count Cumulative post-repair loss count -
Cumulative repaired loss count
2. Interval report 2) Interval report
Some implementations may align the begin_seq and end_seq number with Some implementations may align the begin_seq and end_seq number with
the highest sequence numbers of consecutive RTCP RRs (RTCP interval). the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
This is NOT RECOMMENDED as packets that are not yet repaired in this This is NOT RECOMMENDED as packets that are not yet repaired in this
current RTCP interval and may be repaired in the subsequent intervals current RTCP interval and may be repaired in the subsequent intervals
will not be reported. It is illustrated in the following example: will not be reported. An interval report is illustrated in the
following example:
Interval A: The extended highest sequence number received in RTCP Interval A: The extended highest sequence number received in RTCP
RR is 20. Begin_seq is 10 and end_seq is 20. RR is 20. Begin_seq is 10 and end_seq is 20.
Interval B: The extended highest sequence number received in RTCP Interval B: The extended highest sequence number received in RTCP
RR is 30. Begin_seq is 20 and end_seq is 30. RR is 30. Begin_seq is 20 and end_seq is 30.
If packets 17 and 19 are lost and not yet repaired in interval A and If packets 17 and 19 are lost and not yet repaired in interval A and
subsequently repaired in interval B, they will not then be reported subsequently repaired in interval B, they will not be reported
because their sequence numbers do not belong in the interval B. because their sequence numbers do not belong in interval B.
Therefore, if implementations want these packets to be reported as Therefore, if implementations want these packets to be reported as
repaired, they MUST NOT align the begin_seq and end_seq to the RTCP repaired, they MUST NOT align the begin_seq and end_seq to the RTCP
intervals. intervals.
Alternatively, implementations may choose the begin_seq and end_seq Alternatively, implementations may choose the begin_seq and end_seq
numbers that cover several RTCP intervals. Additionally, the reported numbers that cover several RTCP intervals. Additionally, the
range of sequence numbers may overlap with the previous report reported range of sequence numbers may overlap with the previous
blocks, so that the packets that were not yet repaired in one report blocks, so that the packets that were not yet repaired in one
interval but were subsequently repaired or deemed unrepairable were interval, but were subsequently repaired or deemed unrepairable, were
reported in subsequent intervals. reported in subsequent intervals.
In this case, the "cumulative number of packets lost" cannot be In this case, the "Cumulative number of packets lost" cannot be
easily compared with the post-repair metrics. However, the sending easily compared with the post-repair metrics. However, the sending
endpoint can calculate the efficiency of the error resilience endpoint can calculate the efficiency of the error resilience
algorithm using the post-repair and repaired lost count, algorithm using the post-repair and repaired loss count,
respectively. respectively.
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
5.1 of [RFC3611] by providing an additional value of "xr-format" to 5.1 of [RFC3611] by providing an additional value of "xr-format" to
signal the use of the report block defined in this document. signal the use of the report block defined in this document. The
ABNF [RFC5234] syntax is as follows.
xr-format =/ xr-prlr-block xr-format =/ xr-prlr-block
xr-prlr-block = "post-repair-loss-count" xr-prlr-block = "post-repair-loss-count"
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 the unilateral "rtcp-xr" attribute
applies. For detailed usage of Offer/Answer for unilateral parameters applies. For detailed usage of Offer/Answer for
parameters, refer to section 5.2 of [RFC3611]. unilateral parameters, refer to Section 5.2 of [RFC3611].
5 Security Considerations 5. Security Considerations
This proposed RTCP XR block introduces no new security considerations This proposed RTCP XR block introduces no new security considerations
beyond those described in [RFC3611]. This block does not provide per- beyond those described in [RFC3611]. This block does not provide
packet statistics, so the risk to confidentiality documented in per-packet statistics, so the risk to confidentiality 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 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
by using the AVPF profile together with the Secure RTP profile as achieved by using the AVPF profile together with the Secure RTP
defined in [RFC3711]; an appropriate combination of the two profiles profile as defined in [RFC3711]; an appropriate combination of the
(an "SAVPF") is specified in [RFC5124]. However, other mechanisms two profiles (an "SAVPF") is specified in [RFC5124]. However, other
also exist (documented in [RFC7201]) and might be more suitable. mechanisms also exist (documented in [RFC7201]) and might be more
suitable.
6 IANA Considerations 6. IANA Considerations
New block types for RTCP XR are subject to IANA registration. For New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to general guidelines on IANA considerations for RTCP XR, refer to
[RFC3611]. [RFC3611].
6.1 New RTCP XR Block Type value 6.1. New RTCP XR Block Type Value
This document assigns the block type value PRLR in the IANA "RTP
This document assigns the block type value 33 in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
the "Post-Repair Loss Count Metrics Report Block". the "Post-Repair Loss Count Metrics Report Block".
[Note to RFC Editor: please replace PRLR with the IANA provided RTCP 6.2. New RTCP XR SDP Parameter
XR block type for this block.]
6.2 New RTCP XR SDP Parameter
This document also registers a new parameter "post-repair-loss-count" This document also registers a new parameter "post-repair-loss-count"
in the "RTP Control Protocol Extended Reports (RTCP XR) Session in the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry". Description Protocol (SDP) Parameters Registry".
6.3 Contact Information for registrations 6.3. Contact Information for Registrations
The contact information for the registration is :
RAI Area Directors <rai-ads@tools.ietf.org>
7 Acknowledgments
The author would like to thank Roni Even, Colin Perkins, and Qin Wu The contact information for the registrations is:
for giving valuable comments and suggestions. RAI Area Directors <rai-ads@ietf.org>
8 References 7. References
8.1 Normative References 7.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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[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)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, November 2003. RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>.
[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, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[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, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[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, DOI 10.17487/RFC5725, February
2010, <http://www.rfc-editor.org/info/rfc5725>.
8.2 Informative References 7.2. Informative References
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>.
[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. DOI 10.17487/RFC6390, October 2011,
<http://www.rfc-editor.org/info/rfc6390>.
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC6709, Considerations for Protocol Extensions", RFC 6709, DOI
September 2012. 10.17487/RFC6709, September 2012,
<http://www.rfc-editor.org/info/rfc6709>.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
RTP Monitoring Framework", RFC 6792, November 2012. of the RTP Monitoring Framework", RFC 6792,
DOI 10.17487/RFC6792, November 2012,
<http://www.rfc-editor.org/info/rfc6792>.
[RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
[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, DOI 10.17487/RFC7202, April
2014, <http://www.rfc-editor.org/info/rfc7202>.
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. Post-Repair RTP Packet Loss Count Metric
* Metric Name: Post-Repair RTP Packet Loss Count Metric. * Metric Name: Post-Repair RTP Packet Loss Count Metric.
* Metric Description: Total number of RTP packets still lost after * Metric Description: Total number of RTP packets still lost
loss repair methods are applied after loss-repair methods are applied.
* Method of Measurement or Calculation: See section 3.1, Post- * Method of Measurement or Calculation: See the "Post-repair
Repair RTP Packet Loss Count Metric definition. It is directly loss count" definition in Section 3.1. It is directly
measured and must be measured for the primary source RTP packets measured and must be measured for the primary source RTP
with no further chance of repair. packets with no 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 giving the number of RTP packets. 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, 3rd interval to determine measurement timing. See the Cumulative
paragraph, for details. and Interval reports defined in Section 3.2.
* 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.
Section 1 for details. See Section 1 for details.
* Reporting Model: See RFC3611. * Reporting Model: See RFC 3611.
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
after applying loss repair methods repaired after applying loss-repair methods.
* Method of Measurement or Calculation: See section 3.1, Repaired * Method of Measurement or Calculation: See the "Repaired loss
RTP Packet Loss Count Metric definition. It is directly measured count" in Section 3.1. It is directly measured and must be
and must be measured for the primary source RTP packets with no measured for the primary source RTP packets with no further
further chance of repair. 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 giving the number of RTP packets. 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, 3rd interval to determine measurement timing. See the Cumulative
paragraph, for details. and Interval reports defined in Section 3.2.
* 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.
Section 1 for details. See Section 1 for details.
* Reporting Model: See RFC3611. * Reporting Model: See RFC 3611.
Acknowledgments
The authors would like to thank Roni Even, Colin Perkins, and Qin Wu
for giving valuable comments and suggestions.
Authors' Addresses Authors' Addresses
Rachel Huang Rachel Huang
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing 210012 Nanjing 210012
China China
EMail: rachel.huang@huawei.com EMail: rachel.huang@huawei.com
Varun Singh Varun Singh
Aalto University Aalto University
School of Electrical Engineering School of Electrical Engineering
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: varun@comnet.tkk.fi EMail: varun@comnet.tkk.fi
URI: http://www.netlab.tkk.fi/~varun/ URI: http://www.netlab.tkk.fi/~varun/
 End of changes. 104 change blocks. 
242 lines changed or deleted 255 lines changed or added

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