doc: Add RFC documents

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]
+