diff options
Diffstat (limited to 'doc/rfc/rfc8015.txt')
| -rw-r--r-- | doc/rfc/rfc8015.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc8015.txt b/doc/rfc/rfc8015.txt new file mode 100644 index 0000000..2b433a1 --- /dev/null +++ b/doc/rfc/rfc8015.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Singh +Request for Comments: 8015 callstats.io +Category: Standards Track C. Perkins +ISSN: 2070-1721 University of Glasgow + A. Clark + Telchemy + R. Huang + Huawei + November 2016 + + + RTP Control Protocol (RTCP) Extended Report (XR) Block + for Independent Reporting of Burst/Gap Discard Metrics + +Abstract + + This document defines an RTP Control Protocol (RTCP) Extended Report + (XR) block that allows the reporting of burst/gap discard metrics + independently of the burst/gap loss metrics for use 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 7841. + + 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/rfc8015. + + + + + + + + + + + + + + + + + +Singh, et al. Standards Track [Page 1] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +Copyright Notice + + Copyright (c) 2016 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Independent Burst/Gap Discard Metrics Block . . . . . . . 3 + 1.2. RTCP and RTCP Extended Reports . . . . . . . . . . . . . 4 + 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 + 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Independent Burst/Gap Discard Metrics Block . . . . . . . . . 5 + 3.1. Report Block Structure . . . . . . . . . . . . . . . . . 6 + 3.2. Definition of Fields in the Independent Burst/Gap Discard + Metrics Block . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3. Derived Metrics Based on the Reported Metrics . . . . . . 8 + 4. Considerations for Voice-over-IP Applications . . . . . . . . 9 + 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. SDP rtcp-xr Attribute Extension . . . . . . . . . . . . . 9 + 5.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . 9 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . 10 + 6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 10 + 6.3. Contact Information for Registrations . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Appendix A. Metrics Represented Using the Template from RFC 6390 13 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + + + + + + + +Singh, et al. Standards Track [Page 2] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +1. Introduction + +1.1. Independent Burst/Gap Discard Metrics Block + + This document defines a new block type that extends the metrics + defined in [RFC7003]. The new block type reports the proportion of + packets discarded in a burst by the de-jitter buffer at the receiver. + The number of packets discarded depends on the de-jitter buffer + algorithm implemented by the endpoint. + + The new report block defined in this document is different from the + one defined in [RFC7003]. The metrics in [RFC7003] depend on the + metrics in the burst/gap loss metric defined in [RFC6958]. + Consequently, an endpoint that sends a Burst/Gap Discard Metrics + Block [RFC7003] also needs to send a Burst/Gap Loss Metrics Block + [RFC6958]. The combined usage is useful when an endpoint observes + correlated packet losses and discard. However, when the burst of + packet losses and discards do not occur simultaneously, the + application could prefer to send a concise report block that just + reports the burst/gap of discarded packets. The report block in this + document provides the complete information and does not require + additional report blocks. That is, this block reports the total + number of packets discarded, the total burst duration, and the total + number of bursts. All of these metrics are missing in [RFC7003]. + + This block provides information on transient network issues. Burst/ + gap metrics are typically used in cumulative reports; however, they + can also be used in interval reports (see the Interval Metric flag in + Section 3.2). The variation in the number of packet discards in a + burst affects the user experience. Based on the metrics reported in + the block, the sending endpoint can change the packetization + interval, vary the bitrate, etc. The report can additionally be used + for diagnostics [RFC6792]. The metric belongs to the class of + transport-related end-system metrics defined in [RFC6792]. + + The definitions of "burst", "gap", "loss", and "discard" are + consistent with the definitions in [RFC3611]. To accommodate a range + of de-jitter buffer algorithms and packet discard logic that can be + used by implementers, the method used to distinguish between bursts + and gaps uses an equivalent method to that defined in Section 4.7.2 + of [RFC3611]. Note that reporting the specific de-jitter buffer + algorithm and/or the packet discard logic is out of the scope of this + document. + + + + + + + + +Singh, et al. Standards Track [Page 3] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +1.2. 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]. + +1.3. Performance Metrics Framework + + The Performance Metrics Framework [RFC6390] provides guidance on the + definition and specification of performance metrics. The RTP + Monitoring Framework [RFC6792] provides guidelines for reporting the + block format using RTCP XR. The metrics block described in this + document is in accordance with the guidelines in [RFC6390] and + [RFC6792]. + +1.4. Applicability + + These metrics are applicable to a range of RTP applications that + contain de-jitter buffers at the receiver to smooth variation in + packet-arrival time and don't use stream repair means, e.g., Forward + Error Correction (FEC) [FLEX_FEC] and/or retransmission [RFC4588]. + +2. 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 terms are defined: + + Received, Lost, and Discarded + + A packet is regarded as "lost" if it fails to arrive within an + implementation-specific time window. A packet that arrives within + this time window but is too early to be played out, too late to be + played out, or thrown away before playout due to packet + duplication or redundancy is be recorded as "discarded". A packet + SHALL NOT be regarded as "discarded" if it arrives within this + time window but is dropped during decoding by some higher-layer + decoder, e.g., due to a decoding error. Each packet is classified + as one of "received" (or "OK"), "discarded", or "lost". The + metric "cumulative number of packets lost" defined in [RFC3550] + reports a count of packets lost from the media stream (single + synchronization source (SSRC) within a single RTP session). + Similarly, the metric "number of packets discarded" defined in + [RFC7002] reports a count of packets discarded from the media + stream (single SSRC within a single RTP session) arriving at the + + + +Singh, et al. Standards Track [Page 4] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + + receiver. Another metric, defined in [RFC5725], is available to + report on packets that are not recovered by any repair techniques + that are in use. Note that the term "discard" defined here builds + on the "discard" definition in [RFC3611] but extends the concept + to take into account packet duplication and reports different + types of discard counts [RFC7002]. + + Bursts and Gaps + + The terms "burst" and "gap" are used in a manner consistent with + that of RTCP XR [RFC3611]. RTCP XR views an RTP stream as being + divided into bursts, which are periods during which the discard + rate is high enough to cause noticeable quality degradation + (generally a discard rate over 5 percent), and gaps, which are + periods during which discarded packets are infrequent, and hence + quality is generally acceptable. + +3. Independent Burst/Gap Discard Metrics Block + + Metrics in this block report on burst/gap discard in the stream + arriving at the RTP system. Measurements of these metrics are made + at the receiving end of the RTP stream. 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. + Senders MUST send this block in the same compound RTCP packet as the + Measurement Information Block. Receivers MUST verify that the + measurement period is received in the same compound RTCP packet as + this metrics block. If not, this metrics block MUST be discarded. + + + + + + + + + + + + + + + + + + + +Singh, et al. Standards Track [Page 5] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +3.1. Report Block Structure + + The structure of the Independent Burst/Gap Discard Metrics 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=35 | I | resv | Block Length = 5 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SSRC of Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Threshold | Sum of Burst Durations (ms) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packets Discarded in Bursts | Number of | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bursts | Total Packets Expected in Bursts | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Discard Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Report Block Structure + +3.2. Definition of Fields in the Independent Burst/Gap Discard Metrics + Block + + Block Type (BT): 8 bits + + An Independent Burst/Gap Discard Metrics Block is identified by + the constant 35. + + Interval Metric flag (I): 2 bits + + This field is used to indicate whether the burst/gap discard + metrics are Sampled, Interval, or Cumulative metrics [RFC6792]: + + 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. + + In this document, burst/gap discard metrics can only be measured + over definite intervals and cannot be sampled. Also, the value + I=00 is reserved for future use. Senders MUST NOT use the values + I=00 or I=01. If a block is received with I=00 or I=01, the + receiver MUST discard the block. + + + +Singh, et al. Standards Track [Page 6] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + + Reserved (resv): 6 bits + + These bits are reserved. They MUST be set to zero by senders and + ignored by receivers (see [RFC6709], Section 4.2). + + Block Length: 16 bits + + The length of this report block in 32-bit words, minus one. For + the Independent Burst/Gap Discard Metrics Block, the block length + is equal to 5. The block MUST be discarded if the block length is + set to a different value. + + SSRC of Source: 32 bits + + As defined in Section 4 of [RFC3611]. + + Threshold: 8 bits + + The Threshold is equivalent to Gmin in [RFC3611], i.e., the number + of successive packets that have to be received prior to, and + following, a discarded packet in order for that discarded packet + to be regarded as part of a gap. Note that the Threshold is set + in accordance with the Gmin calculation defined in Section 4.7.2 + of [RFC3611]. + + Sum of Burst Durations (ms): 24 bits + + The total duration of bursts of discarded packets in the period of + the report (Interval or Cumulative). + + The measured value is an unsigned value. If the measured value + exceeds 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate + an over-range measurement. If the measurement is unavailable, the + value 0xFFFFFF MUST be reported. + + Packets Discarded in Bursts: 24 bits + + The total number of packets discarded during discard bursts, as + defined in Section 3.2 of [RFC7002]. + + + + + + + + + + + + +Singh, et al. Standards Track [Page 7] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + + Number of Bursts: 16 bits + + The number of discard bursts in the period of the report (Interval + or Cumulative). + + The measured value is an unsigned value. If the measured value + exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an + over-range measurement. If the measurement is unavailable, the + value 0xFFFF MUST be reported. + + Total Packets Expected in Bursts: 24 bits + + The total number of packets expected during the discard bursts + (that is, the sum of received packets and lost packets). The + metric is defined in [RFC7003]. + + Discard Count: 32 bits + + Number of packets discarded over the period (Interval or + Cumulative) covered by this report, as defined in Section 3.2 of + [RFC7002]. + +3.3. Derived Metrics Based on the Reported Metrics + + The metrics described here are intended to be used in conjunction + with information from the Measurement Information Block [RFC6776]. + + These metrics provide the following information relevant to + statistical parameters (depending on cumulative of interval + measures), for example: + + o The average discarded burst size, which can be calculated by + dividing the metric "Packets Discarded in Bursts" by the "Number + of Bursts". + + o The average burst duration, which can be calculated by dividing + the metric "Sum of Burst Durations (ms)" by the "Number of + Bursts". + + + + + + + + + + + + + +Singh, et al. Standards Track [Page 8] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +4. Considerations for Voice-over-IP Applications + + This metrics block is applicable to a broad range of RTP + applications. Where the metric is used with a Voice-over-IP (VoIP) + application and the stream repair means is not available, the + following considerations apply. + + RTCP XR views a call as being divided into bursts, which are periods + during which the discard rate is high enough to cause noticeable call + quality degradation (generally a discard rate over 5 percent) and + gaps, which are periods during which discarded packets are + infrequent, and hence call quality is generally acceptable. + + If voice activity detection is used, the burst/gap duration is + determined as if silence packets had been sent, i.e., a period of + silence in excess of Gmin packets will terminate a burst condition. + + The RECOMMENDED value for the threshold Gmin in [RFC3611] results in + a burst being a period of time during which the call quality is + degraded to a similar extent to a typical pulse code modulation (PCM) + severely errored second. + +5. SDP Signaling + + [RFC3611] defines the use of SDP (Session Description Protocol) + [RFC4566] for signaling the use of XR blocks. XR blocks can be used + without prior signaling. + +5.1. SDP rtcp-xr Attribute Extension + + This section augments the SDP [RFC4566] attribute "rtcp-xr" defined + in [RFC3611] by providing an additional value 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-ind-bgd-block + + xr-ind-bgd-block = "ind-burst-gap-discard" + +5.2. 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 in Offer/Answer for unilateral + parameters, refer to Section 5.2 of [RFC3611]. + + + + + + +Singh, et al. Standards Track [Page 9] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +6. IANA Considerations + + New block types for RTCP XR are subject to IANA registration. For + general guidelines on IANA considerations for RTCP XR, refer to + [RFC3611]. + +6.1. New RTCP XR Block Type Value + + This document assigns the block type value 35 in the IANA "RTP + Control Protocol Extended Reports (RTCP XR) Block Type Registry" to + the "Independent Burst/Gap Discard Metrics Block". + +6.2. New RTCP XR SDP Parameter + + This document also registers a new parameter "ind-burst-gap-discard" + in the "RTP Control Protocol Extended Reports (RTCP XR) Session + Description Protocol (SDP) Parameters Registry". + +6.3. Contact Information for Registrations + + The contact information for the registrations is: + + ART Area Directors <art-ads@ietf.org> + +7. Security Considerations + + This block does not provide per-packet statistics, so the risk to + confidentiality documented in Section 7, paragraph 3 of [RFC3611] + does not apply. However, the gap indicated within this block could + be used to detect the timing of other events on the path between the + sender and receiver. For example, a competing multimedia stream + might cause a discard burst for the duration of the stream, allowing + the receiver of this block to know when the competing stream was + active. This risk is not a significant threat since the only + information leaked is the timing of the discard, not the cause. + + Where this is a concern, the implementation SHOULD apply encryption + and authentication to this report block. For example, this can be + achieved by using the Audio-Visual Profile with Feedback (AVPF) + profile together with the Secure RTP profile, as defined in + [RFC3711]; an appropriate combination of those two profiles ("SAVPF") + is specified in [RFC5124]. Besides this, it is believed that this + RTCP XR block introduces no new security considerations beyond those + described in [RFC3611]. + + + + + + + +Singh, et al. Standards Track [Page 10] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + 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. + Jacobson, "RTP: A Transport Protocol for Real-Time + 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., + "RTP Control Protocol Extended Reports (RTCP XR)", + 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. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + <http://www.rfc-editor.org/info/rfc3711>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <http://www.rfc-editor.org/info/rfc4566>. + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for + Real-time Transport Control Protocol (RTCP)-Based Feedback + (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 + Report Block Type for RTP Control Protocol (RTCP) Extended + Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February + 2010, <http://www.rfc-editor.org/info/rfc5725>. + + [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, + DOI 10.17487/RFC6776, October 2012, + <http://www.rfc-editor.org/info/rfc6776>. + + + +Singh, et al. Standards Track [Page 11] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + + [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, DOI 10.17487/RFC7003, + September 2013, <http://www.rfc-editor.org/info/rfc7003>. + +8.2. Informative References + + [FLEX_FEC] + Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP + Payload Format for Flexible Forward Error Correction + (FEC)", Work in Progress, draft-ietf-payload-flexible-fec- + scheme-03, October 2016. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + DOI 10.17487/RFC4588, July 2006, + <http://www.rfc-editor.org/info/rfc4588>. + + [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New + Performance Metric Development", BCP 170, RFC 6390, + DOI 10.17487/RFC6390, October 2011, + <http://www.rfc-editor.org/info/rfc6390>. + + [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, + DOI 10.17487/RFC6709, September 2012, + <http://www.rfc-editor.org/info/rfc6709>. + + [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use + of the RTP Monitoring Framework", RFC 6792, + DOI 10.17487/RFC6792, November 2012, + <http://www.rfc-editor.org/info/rfc6792>. + + [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP + Control Protocol (RTCP) Extended Report (XR) Block for + Burst/Gap Loss Metric Reporting", RFC 6958, + DOI 10.17487/RFC6958, May 2013, + <http://www.rfc-editor.org/info/rfc6958>. + + [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol + (RTCP) Extended Report (XR) Block for Discard Count Metric + Reporting", RFC 7002, DOI 10.17487/RFC7002, September + 2013, <http://www.rfc-editor.org/info/rfc7002>. + + + + + + + + +Singh, et al. Standards Track [Page 12] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +Appendix A. Metrics Represented Using the Template from RFC 6390 + + a. Threshold Metric + + * Defined in item a of Appendix A of [RFC7003]. + + b. Sum of Burst Durations (ms) + + * Metric Name: Sum of Burst Durations with Discarded RTP + Packets. + + * Metric Description: The total duration of bursts of discarded + RTP packets in the period of the report. + + * Method of Measurement or Calculation: See Section 3.2, Sum of + Burst Durations definition. + + * Units of Measurement: See Section 3.2, Sum of Burst Durations + definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3, first paragraph. + + * Measurement Timing: See Section 3, second paragraph for + measurement timing and Section 3.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See [RFC3611]. + + c. Packets Discarded in Bursts Metric + + * Defined in item b of Appendix A of [RFC7003]. + + d. Number of Bursts + + * Metric Name: Number of discard bursts in RTP. + + * Metric Description: The total number of bursts with discarded + RTP packets in the period of the report. + + * Method of Measurement or Calculation: See Section 3.2, Number + of Bursts definition. + + * Units of Measurement: See Section 3.2 for the Number of Bursts + definition. + + + + + +Singh, et al. Standards Track [Page 13] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3, first paragraph. + + * Measurement Timing: See Section 3, second paragraph for + measurement timing and Section 3.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See [RFC3611]. + + e. Total Packets Expected in Bursts Metric + + * Defined in item c of Appendix A of [RFC7003]. + + f. Discard Count + + * Defined in Appendix A of [RFC7002]. + +Acknowledgments + + The authors would like to thank Ben Campbell, Stephen Farrell, Paul + Kyzivat, Shucheng LIU, Jan Novak, and Dan Romascanu for providing + valuable feedback on this document. + +Contributors + + Qin Wu, Rachel Huang, and Alan Clark wrote RFC 7003, which this + document extends. + + + + + + + + + + + + + + + + + + + + + + + +Singh, et al. Standards Track [Page 14] + +RFC 8015 RTCP XR Burst/Gap Discard November 2016 + + +Authors' Addresses + + Varun Singh + CALLSTATS I/O Oy + Runeberginkatu 4c A 4 + Helsinki 00100 + Finland + + Email: varun@callstats.io + URI: https://www.callstats.io/about + + + Colin Perkins + University of Glasgow + School of Computing Science + Glasgow G12 8QQ + United Kingdom + + Email: csp@csperkins.org + + + Alan Clark + Telchemy Incorporated + 2905 Premiere Parkway, Suite 280 + Duluth, GA 30097 + United States of America + + Email: alan.d.clark@telchemy.com + + + Rachel Huang + Huawei Technologies Co., Ltd. + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + + Email: Rachel@huawei.com + + + + + + + + + + + + + + +Singh, et al. Standards Track [Page 15] + |