summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6798.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6798.txt')
-rw-r--r--doc/rfc/rfc6798.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc6798.txt b/doc/rfc/rfc6798.txt
new file mode 100644
index 0000000..4d84510
--- /dev/null
+++ b/doc/rfc/rfc6798.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Clark
+Request for Comments: 6798 Telchemy
+Category: Standards Track Q. Wu
+ISSN: 2070-1721 Huawei
+ November 2012
+
+
+ RTP Control Protocol (RTCP) Extended Report (XR) Block
+ for Packet Delay Variation Metric Reporting
+
+Abstract
+
+ This document defines an RTP Control Protocol (RTCP) Extended Report
+ (XR) block that allows the reporting of packet delay variation
+ metrics for a range of RTP applications.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6798.
+
+Copyright Notice
+
+ Copyright (c) 2012 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.
+
+
+
+
+
+
+
+Clark & Wu Standards Track [Page 1]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Packet Delay Variation Metrics Block .......................3
+ 1.2. RTCP and RTCP XR Reports ...................................3
+ 1.3. Performance Metrics Framework ..............................3
+ 1.4. Applicability ..............................................3
+ 2. Terminology .....................................................3
+ 2.1. Requirements Language ......................................3
+ 2.2. Notations ..................................................4
+ 3. Packet Delay Variation Metrics Block ............................4
+ 3.1. Report Block Structure .....................................5
+ 3.2. Definition of Fields in PDV Metrics Block ..................5
+ 3.3. Guidance on Use of PDV Metrics .............................8
+ 3.4. Examples of Use ............................................9
+ 4. SDP Signaling ...................................................9
+ 5. IANA Considerations ............................................10
+ 5.1. New RTCP XR Block Type Value ..............................10
+ 5.2. New RTCP XR SDP Parameter .................................10
+ 5.3. Contact Information for Registrations .....................11
+ 5.4. New Registry of PDV Types .................................11
+ 6. Security Considerations ........................................11
+ 7. Contributors ...................................................12
+ 8. Acknowledgments ................................................12
+ 9. References .....................................................12
+ 9.1. Normative References ......................................12
+ 9.2. Informative References ....................................13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark & Wu Standards Track [Page 2]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+1. Introduction
+
+1.1. Packet Delay Variation Metrics Block
+
+ This document defines a new block type to augment those defined in
+ [RFC3611], for use in a range of RTP applications.
+
+ The new block type provides information on Packet Delay Variation
+ (PDV) using one of several standard metrics, for example, Mean
+ Absolute Packet Delay Variation 2 (MAPDV2) (Clause 6.2.3.2 of
+ [G.1020]) or 2-point PDV (Clause 6.2.4 of [Y.1540]).
+
+ The metrics belong to the class of transport metrics defined in
+ [MONARCH].
+
+1.2. RTCP and RTCP XR 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 architectures [MONARCH] provides guidelines for reporting
+ block format using RTCP XR. The XR block described in this document
+ is in accordance with the guidelines in [RFC6390] and [MONARCH].
+
+1.4. Applicability
+
+ These metrics are applicable to a wide range of RTP applications in
+ which the application streams are sensitive to delay variation
+ [RFC5481]. For example, applications could use the measurements of
+ these metrics to help adjust the size of adaptive jitter buffers to
+ improve performance. Network managers can use these metrics to
+ compare actual delay variation to targets (i.e., a numerical
+ objective or Service Level Agreement) to help ensure the quality of
+ real-time application performance.
+
+2. Terminology
+
+2.1. Requirements Language
+
+ 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].
+
+
+
+Clark & Wu Standards Track [Page 3]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+2.2. Notations
+
+ This report block makes use of binary fractions. The terminology
+ used is
+
+ Numeric formats S X:Y
+
+ where S indicates a two's complement signed representation, X
+ the number of bits prior to the decimal place, and Y the number
+ of bits after the decimal place.
+
+ Hence, 8:8 represents an unsigned number in the range 0.0 to
+ 255.996 with a granularity of 0.0039. S7:8 represents the
+ range -127.996 to +127.996. 0:16 represents a proper binary
+ fraction with range as follows:
+
+ 0.0 to 1 - 1/65536 = 0.9999847
+
+ however, note that use of flag values at the top of the numeric
+ range slightly reduces this upper limit. For example, if the
+ 16-bit values 0xfffe and 0xffff are used as flags for "over-
+ range" and "unavailable" conditions, a 0:16 quantity has a
+ range as follows:
+
+ 0.0 to 1 - 3/65536 = 0.9999542
+
+3. Packet Delay Variation Metrics Block
+
+ Metrics in this block report on packet delay variation in the stream
+ arriving at the RTP system. The measurement of these metrics is made
+ at the receiving end of the RTP stream. Instances of this metric
+ block refer by synchronization source (SSRC) to the separate
+ auxiliary Measurement Information Block [RFC6776], which contains
+ measurement intervals. This metric block relies on the measurement
+ interval given by the value of the "Measurement Duration (Interval)"
+ field in the Measurement Information Block to indicate the span of
+ the report and MUST be sent in the same compound RTCP packet as the
+ Measurement Information Block. If the measurement interval is not
+ received for this metric block, this metric block MUST be discarded.
+
+
+
+
+
+
+
+
+
+
+
+
+Clark & Wu Standards Track [Page 4]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+3.1. Report Block Structure
+
+ PDV metrics block:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BT=15 | I |pdvtyp |Rsv| block length=4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSRC of Source |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pos PDV Threshold/Peak | Pos PDV Percentile |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Neg PDV Threshold/Peak | Neg PDV Percentile |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Mean PDV | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Report Block Structure
+
+3.2. Definition of Fields in PDV Metrics Block
+
+ Block type (BT): 8 bits
+
+ A Packet Delay Variation Metrics Block is identified by the
+ constant 15.
+
+ Interval Metric flag (I): 2 bit
+
+ This field is used to indicate whether the Packet Delay Variation
+ metrics are Sampled, Interval, or Cumulative metrics [MONARCH],
+ that is, whether the reported values apply to the most recent
+ measurement interval duration between successive metrics reports
+ (I=10) (the Interval Duration), or they apply to the accumulation
+ period characteristic of cumulative measurements (I=11) (the
+ Cumulative Duration), or they are a sampled instantaneous value
+ (I=01) (Sampled Value). The value I=00 is reserved and MUST NOT
+ be used. If the value I=00 is received, then the XR block MUST be
+ ignored by the receiver.
+
+ Packet Delay Variation Metric Type (pdvtyp): 4 bits
+
+ Packet Delay Variation Metric Type is of type enumerated and is
+ interpreted as an unsigned, 4-bit integer. This field is used to
+ identify the Packet Delay Variation Metric Type used in this
+ report block, according to the following code:
+
+
+
+
+
+Clark & Wu Standards Track [Page 5]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+ bits 014-011
+
+ 0: MAPDV2, Clause 6.2.3.2 of [G.1020],
+
+ 1: 2-point PDV, Clause 6.2.4 of [Y.1540].
+
+ Rsv: 2 bits
+
+ This field is reserved for future definition. In the absence of
+ such a definition, the bits in this field MUST be set to zero and
+ ignored by the receiver.
+
+ block length: 16 bits
+
+ The length of this report block is in 32-bit words, minus one.
+ For the Packet Delay Variation Metrics Block, the block length is
+ equal to 4.
+
+ SSRC of source: 32 bits
+
+ This field is as defined in Section 4.1 of [RFC3611].
+
+ Positive PDV Threshold/Peak: 16 bits
+
+ This field is associated with the Positive PDV percentile and
+ expressed in milliseconds with numeric format S11:4. The term
+ "Positive" represents that the packets are arriving later than the
+ expected time.
+
+ If the measured value is less than -2047.9375 (the value that
+ would be coded as 0x8001), the value 0x8000 SHOULD be reported to
+ indicate an over-range negative measurement. If the measured
+ value is greater than +2047.8125 (the value that would be coded as
+ 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an over-
+ range positive measurement. If the measurement is unavailable,
+ the value 0x7FFF MUST be reported.
+
+ Positive PDV Percentile: 16 bits
+
+ This field indicates the percentages of packets in the RTP stream
+ for which individual packet delays were less than the Positive PDV
+ Threshold. It is expressed in numeric format 8:8 with values from
+ 0 to 100th percentile.
+
+ If the measurement is unavailable, the value 0xFFFF MUST be
+ reported.
+
+
+
+
+
+Clark & Wu Standards Track [Page 6]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+ Negative PDV Threshold/Peak: 16 bits
+
+ This field is associated with the Negative PDV percentile and
+ expressed in milliseconds with numeric format S11:4. The term
+ "Negative" represents that the packets are arriving earlier than
+ the expected time.
+
+ If the measured value is more negative than -2047.9375 (the value
+ that would be coded as 0x8001), the value 0x8000 SHOULD be
+ reported to indicate an over-range negative measurement. If the
+ measured value is more positive than +2047.8125 (the value that
+ would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to
+ indicate an over-range positive measurement. If the measurement
+ is unavailable, the value 0x7FFF MUST be reported.
+
+ Negative PDV Percentile: 16 bits
+
+ This field indicates the percentages of packets in the RTP stream
+ for which individual packet delays were more than the Negative PDV
+ Threshold. It is expressed in numeric format 8:8 with values from
+ 0 to 100th percentile.
+
+ If the measurement is unavailable, the value 0xFFFF MUST be
+ reported.
+
+ If the PDV Type indicated is 2-point PDV and the Positive and
+ Negative PDV percentiles are set to 100.0, then the Positive and
+ Negative Threshold/Peak PDV values are the peak values measured
+ during the reporting interval (which may be from the start of the
+ call for cumulative reports). In this case, the difference
+ between the Positive and Negative Threshold/Peak values defines
+ the range of 2-point PDV.
+
+ Mean PDV: 16 bits
+
+ The mean PDV value of data packets is expressed in milliseconds
+ with Numeric format S11:4 format.
+
+ For MAPDV2, this value is generated according to Clause 6.2.3.2 of
+ [G.1020]. For interval reports, the MAPDV2 value is reset at the
+ start of the interval.
+
+ For 2-point PDV, the value reported is the mean of per-packet
+ 2-point PDV values. This metric indicates the arrival time of the
+ first media packet of the session with respect to the mean of the
+ arrival times of every packet of the session. A single value of
+ the metric (for a single session) may not be useful by itself, but
+ its average over a number of sessions may be useful in diagnosing
+
+
+
+Clark & Wu Standards Track [Page 7]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+ media delay at session startup. For example, this might occur if
+ media packets are often delayed behind signaling packets due to
+ head-of-line blocking.
+
+ If the measured value is more negative than -2047.9375 (the value
+ that would be coded as 0x8001), the value 0x8000 SHOULD be
+ reported to indicate an over-range negative measurement. If the
+ measured value is more positive than +2047.8125 (the value that
+ would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to
+ indicate an over-range positive measurement. If the measurement
+ is unavailable, the value 0x7FFF MUST be reported.
+
+ Reserved: 16 bits
+
+ These bits are reserved for future definition. They MUST be set
+ to zero by the sender and ignored by the receiver.
+
+3.3. Guidance on Use of PDV Metrics
+
+ This subsection provides informative guidance on when it might be
+ appropriate to use each of the PDV metric types.
+
+ MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous
+ (per-packet) delay when compared to the short-term moving average
+ delay. This metric could be useful in determining residual
+ impairment when an RTP end system uses an adaptive de-jitter buffer
+ that tracks the average delay variation, provided that the averaging
+ behavior of the adaptive algorithm is similar to that of the MAPDV2
+ algorithm.
+
+ 2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
+ variation with respect to a defined reference packet transfer delay.
+ Note that the reference packet is generally selected as the packet
+ with minimum delay based on the most common criterion (see Sections 1
+ and 5.1 of [RFC5481]). In an RTP context, the two "points" are at
+ the sender (the synchronization source that applies RTP timestamps)
+ and at the receiver. The value of this metric for the packet with
+ index j is identical to the quantity D(i,j) defined in Section 6.4.1
+ of [RFC3550], and the packet index i should be set equal to the index
+ of the reference packet for the metric in practice. The metric
+ includes the effect of the frequency offsets of clocks in both the
+ sender and receiver end systems, so it is useful mainly in networks
+ where synchronization is distributed. As well as measuring packet
+ delay variation in such networks, it may be used to ensure that
+ synchronization is effective, for example, where the network carries
+ ISDN data traffic over RTP [RFC4040]. The metric is likely to be
+ useful in networks that use fixed de-jitter buffering, because it may
+ be used to determine the length of the required de-jitter buffer, or
+
+
+
+Clark & Wu Standards Track [Page 8]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+ to determine if network performance has deteriorated such that
+ existing de-jitter buffers are too small to accommodate the observed
+ delay variation.
+
+3.4. Examples of Use
+
+ (a) To report MAPDV2 [G.1020]:
+
+ Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
+ Threshold = 50.0 (note this implies -50 ms); Neg PDV Percentile
+ = 98.4; PDV type = 0 (MAPDV2)
+
+ causes average MAPDV2 to be reported in the Mean PDV field.
+
+ Note that implementations either may fix the reported
+ percentile and calculate the associated PDV level or may fix a
+ threshold PDV level and calculate the associated percentile.
+ From a practical implementation perspective, it is simpler to
+ use the second of these approaches (except of course in the
+ extreme case of the 100th percentile).
+
+ (b) To report 2-point PDV [Y.1540]:
+
+ Pos PDV Threshold = 60 (note this implies +60 ms); Pos PDV
+ Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile =
+ 0; PDV type = 1 (2-point PDV)
+
+ causes 2-point PDV to be reported in the Mean PDV field.
+
+ 2-point PDV, according to [Y.1540] is the difference in delay
+ between the current packet and the referenced packet of the
+ stream. If the sending and receiving clocks are not
+ synchronized, this metric includes the effect of relative
+ timing drift.
+
+4. SDP Signaling
+
+ [RFC3611] defines the use of the Session Description Protocol (SDP)
+ [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used
+ without prior signaling.
+
+ 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.
+
+
+
+
+
+
+
+Clark & Wu Standards Track [Page 9]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+ xr-format =/ xr-pdv-block
+
+ xr-pdv-block = "pkt-dly-var" [ "," pdvtype ] [ "," nspec "," pspec ]
+
+ pdvtype = "pdv=" ( "0" ; MAPDV2 ITU-T G.1020
+ / "1" ; 2-point PDV ITU-T Y.1540
+ / 1*2DIGIT ) ;Value 2~15 are valid and
+ ;reserved for future use
+ nspec = ("nthr=" fixpoint) ; negative PDV threshold (ms)
+ / ("npc=" fixpoint ) ; negative PDV percentile
+ pspec = ("pthr=" fixpoint) ; positive PDV threshold (ms)
+ / ("ppc=" fixpoint) ; positive PDV percentile
+
+ fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal
+ DIGIT = <as defined in Section 3.4 of [RFC5234]>
+
+ When SDP is used in offer/answer, a system sending SDP may request a
+ specific type of PDV measurement. In addition, they may state a
+ specific percentile or threshold value and expect to receive the
+ corresponding threshold or percentile metric, respectively. The
+ system receiving the SDP SHOULD send the PDV metrics requested, but
+ if the metric is not available, the system receiving the SDP MUST
+ send the metric block with the flag value indicating that the metric
+ is unavailable.
+
+5. 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].
+
+5.1. New RTCP XR Block Type Value
+
+ This document assigns the block type value 15 in the IANA "RTCP XR
+ Block Type" registry to the "Packet Delay Variation Metrics Block".
+
+5.2. New RTCP XR SDP Parameter
+
+ This document also registers a new parameter "pkt-dly-var" in the
+ "RTCP XR SDP Parameters" registry.
+
+
+
+
+
+
+
+
+
+
+
+Clark & Wu Standards Track [Page 10]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+5.3. Contact Information for Registrations
+
+ The contact information for the registrations is:
+
+ Qin Wu (sunseawq@huawei.com)
+
+ 101 Software Avenue, Yuhua District
+ Nanjing, Jiangsu 210012
+ China
+
+5.4. New Registry of PDV Types
+
+ This document creates a new registry to be called "RTCP XR PDV block
+ - PDV type" as a sub-registry of the "RTP Control Protocol Extended
+ Reports (RTCP XR) Block Type Registry". Policies for this new
+ registry are as follows:
+
+ o The information required to support an assignment is an
+ unambiguous definition of the new metric, covering the base
+ measurements and how they are processed to generate the reported
+ metric. This should include the units of measurement, how values
+ of the metric are reported in the three 16-bit fields "Pos PDV
+ Threshold/Peak", "Neg PDV Threshold/Peak", and "Mean PDV" within
+ the report block, and how the metric uses the two 16-bit fields
+ "Pos PDV Percentile" and "Neg PDV Percentile".
+
+ o The review process for the registry is "Specification Required" as
+ described in Section 4.1 of [RFC5226].
+
+ o Entries in the registry are unsigned 4-bit integers. The valid
+ range is 0 to 15 corresponding to the 4-bit field "pdvtyp" in the
+ block. Values are to be recorded in decimal.
+
+ o Initial assignments are as follows:
+
+ * 0: MAPDV2, Clause 6.2.3.2 of [G.1020],
+
+ * 1: 2-point PDV, Clause 6.2.4 of [Y.1540],
+
+ * 2-15: Reserved for future use.
+
+6. Security Considerations
+
+ It is believed that this proposed RTCP XR block introduces no new
+ security considerations beyond those described in [RFC3611]. This
+ block does not provide per-packet statistics so the risk to
+ confidentiality documented in Section 7, paragraph 3, of [RFC3611]
+ does not apply.
+
+
+
+Clark & Wu Standards Track [Page 11]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+7. Contributors
+
+ Geoff Hunt wrote the initial version of this document.
+
+8. Acknowledgments
+
+ The authors gratefully acknowledge reviews and feedback provided by
+ Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor,
+ Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi,
+ Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz,
+ Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi
+ Raviraj, Albrecht Schwarz, Tom Taylor, Hideaki Yamada, Jing Zhao,
+ Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn, Shida Schubert,
+ Benoit Claise, Adrian Farrel, and Pete Resnick.
+
+9. References
+
+9.1. Normative References
+
+ [G.1020] ITU-T Rec. G. 1020, "Performance parameter definitions for
+ quality of speech and other voiceband applications
+ utilizing IP networks", July 2006.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
+ Protocol Extended Reports (RTCP XR)", RFC 3611,
+ November 2003.
+
+ [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s
+ Transparent Call", RFC 4040, April 2005.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+
+
+
+
+Clark & Wu Standards Track [Page 12]
+
+RFC 6798 RTCP XR Packet Delay Variation November 2012
+
+
+ [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information
+ Reporting Using a Source Description (SDES) Item and an
+ RTCP Extended Report (XR) Block", RFC 6776, October 2012.
+
+ [Y.1540] ITU-T Rec. Y.1540, "IP packet transfer and availability
+ performance parameters", November 2007.
+
+9.2. Informative References
+
+ [MONARCH] Wu, W., Hunt, G., and P. Arden, "Guidelines for Use of the
+ RTP Monitoring Framework", Work in Progress,
+ September 2012.
+
+ [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
+ Applicability Statement", RFC 5481, March 2009.
+
+ [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
+ Performance Metric Development", BCP 170, RFC 6390,
+ October 2011.
+
+Authors' Addresses
+
+ Alan Clark
+ Telchemy Incorporated
+ 2905 Premiere Parkway, Suite 280
+ Duluth, GA 30097
+ USA
+
+ EMail: alan.d.clark@telchemy.com
+
+
+ Qin Wu
+ Huawei
+ 101 Software Avenue, Yuhua District
+ Nanjing, Jiangsu 210012
+ China
+
+ EMail: sunseawq@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark & Wu Standards Track [Page 13]
+