doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc7294.txt b/doc/rfc/rfc7294.txt
new file mode 100644
index 0000000..0d39e75
--- /dev/null
+++ b/doc/rfc/rfc7294.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Clark
+Request for Comments: 7294                                      Telchemy
+Category: Standards Track                                        G. Zorn
+ISSN: 2070-1721                                              Network Zen
+                                                                   C. Bi
+                                                                   STTRI
+                                                                   Q. Wu
+                                                                  Huawei
+                                                               July 2014
+
+
+        RTP Control Protocol (RTCP) Extended Report (XR) Blocks
+        for Concealment Metrics Reporting on Audio Applications
+
+Abstract
+
+   This document defines two RTP Control Protocol (RTCP) Extended Report
+   (XR) blocks that allow the reporting of concealment metrics for audio
+   applications of RTP.
+
+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/rfc7294.
+
+Copyright Notice
+
+   Copyright (c) 2014 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, et al.                Standards Track                    [Page 1]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Loss Concealment and Concealed Seconds Metrics
+           Blocks  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.2.  RTCP and RTCP Extended Reports  . . . . . . . . . . . . .   3
+     1.3.  Performance Metrics Framework . . . . . . . . . . . . . .   4
+     1.4.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     2.1.  Standards Language  . . . . . . . . . . . . . . . . . . .   4
+     2.2.  Notations . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Loss Concealment Metrics Block  . . . . . . . . . . . . . . .   5
+     3.1.  Report Block Structure  . . . . . . . . . . . . . . . . .   5
+     3.2.  Definition of Fields in Loss Concealment Metrics Block  .   5
+   4.  Concealed Seconds Metrics Block . . . . . . . . . . . . . . .   9
+     4.1.  Report Block Structure  . . . . . . . . . . . . . . . . .  10
+     4.2.  Definition of Fields in Concealed Seconds Metrics Block .  10
+   5.  SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . .  14
+     5.1.  SDP rtcp-xr-attrib Attribute Extension  . . . . . . . . .  14
+     5.2.  Offer/Answer Usage  . . . . . . . . . . . . . . . . . . .  14
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
+     6.1.  New RTCP XR Block Type Values . . . . . . . . . . . . . .  14
+     6.2.  New RTCP XR SDP Parameters  . . . . . . . . . . . . . . .  15
+     6.3.  Contact Information for Registrations . . . . . . . . . .  15
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  15
+   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
+   Appendix A.  Metrics Represented Using the Template from RFC 6390  17
+
+1.  Introduction
+
+1.1.  Loss Concealment and Concealed Seconds Metrics Blocks
+
+   At any instant, the audio output at a receiver may be classified as
+   either 'normal' or 'concealed'.  'Normal' refers to playout of audio
+   payload received from the remote end and also includes locally
+   generated signals such as announcements, tones, and comfort noise.
+   'Concealed' refers to playout of locally generated signals used to
+   mask the impact of network impairments or to reduce the audibility of
+   jitter buffer adaptations.
+
+   This document defines two new concealment-related block types to
+   augment those defined in [RFC3611] for use in a range of RTP
+   applications.  These two block types extend the packet loss
+   concealment mechanism defined in Section 4.7.6 of [RFC3611].
+
+
+
+Clark, et al.                Standards Track                    [Page 2]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   The first block type, the Loss Concealment Metrics Block, provides
+   metrics for actions taken by the receiver to mitigate the effect of
+   packet loss and packet discard.  Specifically, the first metric
+   (On-Time Playout Duration) reports the duration of normal playout of
+   data that the receiver obtained from the sender's stream.  A second
+   metric (Loss Concealment Duration) reports the total time during
+   which the receiver played out media data that was manufactured
+   locally, because the sender's data for these periods was not
+   available due to packet loss or discard.  A similar metric (Buffer
+   Adjustment Concealment Duration) reports the duration of playout of
+   locally manufactured data replacing data that is unavailable due to
+   adaptation of an adaptive de-jitter buffer.  Further metrics (Playout
+   Interrupt Count and Mean Playout Interrupt Size) report the number of
+   times normal playout was interrupted and the mean duration of these
+   interruptions.
+
+   Loss Concealment Duration and Buffer Adjustment Concealment Duration
+   are reported separately because buffer adjustment is typically
+   arranged to occur in silence periods, so it may have very little
+   impact on user experience, whilst loss concealment may occur at any
+   time.
+
+   The second block type, the Concealed Seconds Metrics Block, provides
+   metrics for Concealed Seconds, which are measured at the receiving
+   end of the RTP stream.  Specifically, the first metric (Unimpaired
+   Seconds) reports the number of whole seconds occupied only with
+   normal playout of data that the receiver obtained from the sender's
+   stream.  The second metric (Concealed Seconds) reports the number of
+   whole seconds during which the receiver played out any locally
+   generated media data.  A third metric, Severely Concealed Seconds
+   (SCSs), reports the number of whole seconds during which the receiver
+   played out locally generated data to conceal a lost or discarded
+   frame percentage in excess of the configured SCS Threshold.
+
+   These metrics belongs to the class of transport-related terminal
+   metrics defined in [RFC6792].
+
+1.2.  RTCP and RTCP Extended Reports
+
+   The use of RTCP for reporting is defined in [RFC3550].  [RFC3611]
+   defines an extensible structure for reporting using an RTCP Extended
+   Report (XR).  This document defines a new Extended Report block that
+   MUST be used as defined in [RFC3550] and [RFC3611].
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 3]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+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
+   block format using RTCP XR.  The metrics blocks described in this
+   document are in accordance with those guidelines.
+
+1.4.  Applicability
+
+   These metrics are applicable to audio applications of RTP and the
+   audio component of audio/video applications in which the packet loss
+   concealment machinery is contained at the receiving end to mitigate
+   the impact of network impairments to user's perception of media
+   quality.
+
+2.  Terminology
+
+2.1.  Standards 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].
+
+2.2.  Notations
+
+   The report blocks in this document make use of binary fractions.  The
+   following terminology is used:
+
+      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 would represent the
+         range -127.996 to +127.996. 0:16 represents a proper binary
+         fraction with range
+
+         0.0 to 1 - 1/65536 = 0.9999847
+
+         though 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 range
+
+         0.0 to 1 - 3/65536 = 0.9999542
+
+
+
+Clark, et al.                Standards Track                    [Page 4]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+3.  Loss Concealment Metrics Block
+
+   The Loss Concealment Metrics Block is intended to be used as
+   described in this section, in conjunction with information from the
+   Measurement Information Block [RFC6776].  Instances of this metrics
+   block refer by synchronization source (SSRC) 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 and SHOULD be
+   sent in the same compound RTCP packet as the Measurement Information
+   Block.  If the measurement period is not received in the same
+   compound RTCP packet as this metrics block, this metrics block MUST
+   be discarded.
+
+3.1.  Report Block Structure
+
+   The structure of the Loss Concealment Metrics Block is as follows.
+
+     0               1               2               3
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    BT=30      | I |plc|  resv |       block length=6          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         SSRC of Source                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                 On-Time Playout Duration                      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                  Loss Concealment Duration                    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |              Buffer Adjustment Concealment Duration           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    Playout Interrupt Count    |           Reserved            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                 Mean Playout Interrupt Size                   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 1: Loss Concealment Metrics Block
+
+3.2.  Definition of Fields in Loss Concealment Metrics Block
+
+   Block type (BT): 8 bits
+
+      A Loss Concealment Metrics Block is identified by the constant 30.
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 5]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   Interval Metric flag (I): 2 bits
+
+      This field is used to indicate whether the loss concealment
+      metrics are Sampled, Interval, or Cumulative metrics:
+
+         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.
+
+         I=01: Sampled Value - the reported value is a sampled
+         instantaneous value (not allowed in this block).
+
+         I=00: Reserved value - this value is reserved for future use.
+
+      In this document, Loss Concealment metrics can only be measured
+      over definite intervals and cannot be sampled.  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.
+
+   Packet Loss Concealment Method (plc): 2 bits
+
+      This field is used to identify the packet loss concealment method
+      in use at the receiver, according to the following code:
+
+         bits 014-015
+
+            0 = silence insertion
+
+            1 = simple replay, no attenuation
+
+            2 = simple replay, with attenuation
+
+            3 = enhancement
+
+            Other values are reserved.
+
+      Note that the enhancement method (plc=3) for packet loss
+      concealment offers an improved audio quality and better robustness
+      against packet losses [G.711] and is equivalent to "enhanced" in
+      Section 4.7.6 of [RFC3611].
+
+   Reserved (resv): 4 bits
+
+      These bits are reserved.  They MUST be set to zero by senders and
+      ignored by receivers (see [RFC6709], Section 4.2).
+
+
+
+Clark, et al.                Standards Track                    [Page 6]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   block length: 16 bits
+
+      The length of this report block in 32-bit words, minus one.  For
+      the Loss Concealment Metrics Block, the block length is equal to
+      6.
+
+   SSRC of Source: 32 bits
+
+      As defined in Section 4.1 of [RFC3611].
+
+   On-Time Playout Duration: 32 bits
+
+      'On-time playout' is the uninterrupted, in-sequence playout of
+      valid decoded audio information originating from the remote
+      endpoint.  This includes comfort noise during periods of remote
+      talker silence, if Voice Activity Detection (VAD) [VAD] is used,
+      and locally generated or regenerated tones and announcements.
+
+      An equivalent definition is that on-time playout is playout of any
+      signal other than those used for concealment.
+
+      On-time playout duration is expressed in units of RTP timestamp
+      and MUST include both speech and silence intervals, whether VAD is
+      used or not.
+
+      Two values are reserved: a value of 0xFFFFFFFE indicates out of
+      range (that is, a measured value exceeding 0xFFFFFFFD), and a
+      value of 0xFFFFFFFF indicates that the measurement is unavailable.
+
+   Loss Concealment Duration: 32 bits
+
+      The duration, expressed in units of RTP timestamp, of audio
+      playout corresponding to Loss-Type concealment.
+
+      Loss-Type concealment is reactive insertion or deletion of samples
+      in the audio playout stream due to effective frame loss at the
+      audio decoder.  Effective frame loss is the event in which a frame
+      of coded audio is simply not present at the audio decoder when
+      required.  In this case, substitute audio samples are generally
+      formed, at the decoder or elsewhere, to reduce audible impairment.
+
+      Two values are reserved: a value of 0xFFFFFFFE indicates out of
+      range (that is, a measured value exceeding 0xFFFFFFFD), and a
+      value of 0xFFFFFFFF indicates that the measurement is unavailable.
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 7]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   Buffer Adjustment Concealment Duration: 32 bits
+
+      The duration, expressed in units of RTP timestamp, of audio
+      playout corresponding to Buffer Adjustment-Type concealment, if
+      known.
+
+      Buffer Adjustment-Type concealment is proactive or controlled
+      insertion or deletion of samples in the audio playout stream due
+      to jitter buffer adaptation, re-sizing decisions, or re-centering
+      decisions within the endpoint.
+
+      Because this insertion is controlled, rather than occurring
+      randomly in response to losses, it is typically less audible than
+      Loss-Type concealment.  For example, jitter buffer adaptation
+      events may be constrained to occur during periods of talker
+      silence, in which case only silence duration is affected, or
+      sophisticated time-stretching methods for insertion/deletion
+      during favorable periods in active speech may be employed.
+
+      Concealment events that cannot be classified as Buffer Adjustment-
+      Type MUST be classified as Loss-Type.
+
+      Two values are reserved: a value of 0xFFFFFFFE indicates out of
+      range (that is, a measured value exceeding 0xFFFFFFFD), and a
+      value of 0xFFFFFFFF indicates that the measurement is unavailable.
+
+   Playout Interrupt Count: 16 bits
+
+      The number of interruptions to normal playout that occurred during
+      the reporting period.
+
+      Two values are reserved: a value of 0xFFFE indicates out of range
+      (that is, a measured value exceeding 0xFFFD), and a value of
+      0xFFFF indicates that the measurement is unavailable.
+
+   Reserved: 16 bits
+
+      These bits are reserved.  They MUST be set to zero by senders and
+      ignored by receivers (see [RFC6709], Section 4.2).
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 8]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   Mean Playout Interrupt Size: 32 bits
+
+      The mean duration, expressed in units of RTP timestamp, of
+      interruptions to normal playout that occurred during the reporting
+      period.
+
+      Two values are reserved: a value of 0xFFFFFFFE indicates out of
+      range (that is, a measured value exceeding 0xFFFFFFFD), and a
+      value of 0xFFFFFFFF indicates that the measurement is unavailable.
+
+4.  Concealed Seconds Metrics Block
+
+   The Concealed Seconds Metrics Block is intended to be used as
+   described in this section, in conjunction with information from the
+   Measurement Information Block [RFC6776].  It provides a description
+   of potentially audible impairments due to lost and discarded packets
+   at the endpoint, expressed on a time basis analogous to a traditional
+   Public Switched Telephone Network (PSTN) T1/E1 errored seconds
+   metric.  Instances of this metrics block refer by synchronization
+   source (SSRC) to the separate auxiliary Measurement Information Block
+   [RFC6776] that 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
+   and SHOULD be sent in the same compound RTCP packet as the
+   Measurement Information Block.  If the measurement period is not
+   received in the same compound RTCP packet as this metrics block, this
+   metrics block MUST be discarded.
+
+   The following metrics are based on successive one-second intervals as
+   declared by an RTP clock.  This RTP clock does not need to be
+   synchronized to any external time reference.  The starting time of
+   this clock is unspecified.  Note that this implies that the same loss
+   pattern could result in slightly different count values, depending on
+   where the losses occur relative to the particular one-second
+   demarcation points.  For example, two loss events occurring 50 ms
+   apart could result in either one Concealed Second or two, depending
+   on the particular one-second boundaries used.
+
+   The seconds in this sub-block are not necessarily calendar seconds.
+   At the tail end of a session, periods of time of less than one second
+   shall be incorporated into these counts if they exceed 500 ms and
+   shall be disregarded if they are less than 500 ms.
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 9]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+4.1.  Report Block Structure
+
+   The structure of the Concealed Seconds 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=31      | I |plc|  resv |       block length=4          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         SSRC of Source                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                    Unimpaired Seconds                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                    Concealed Seconds                          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Severely Concealed Seconds    | Reserved      | SCS Threshold |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 2: Concealed Seconds Metrics Block
+
+4.2.  Definition of Fields in Concealed Seconds Metrics Block
+
+   Block type (BT): 8 bits
+
+      A Concealed Seconds Metrics Block is identified by the constant
+      31.
+
+   Interval Metric flag (I): 2 bits
+
+      This field is used to indicate whether the Concealed Seconds
+      metrics are Sampled, Interval, or Cumulative metrics:
+
+         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.
+
+         I=01: Sampled Value - the reported value is a sampled
+         instantaneous value (Not allowed in this block).
+
+         I=00: Reserved value - this value is reserved for future use.
+
+      In this document, Concealed Seconds metrics can only be measured
+      over definite intervals and cannot be sampled.  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.
+
+
+
+Clark, et al.                Standards Track                   [Page 10]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   Packet Loss Concealment Method (plc): 2 bits
+
+      This field is used to identify the packet loss concealment method
+      in use at the receiver, according to the following code:
+
+         bits 014-015
+
+            0 = silence insertion
+
+            1 = simple replay, no attenuation
+
+            2 = simple replay, with attenuation
+
+            3 = enhancement
+
+            Other values are reserved.
+
+      Note that the enhancement method (plc=3) for packet loss
+      concealment offers an improved audio quality and a better
+      robustness against packet losses [G.711] and is equivalent to
+      "enhanced" in Section 4.7.6 of [RFC3611].
+
+   Reserved (resv): 4 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 Concealed Seconds Metrics Block, the block length is equal to
+      4.
+
+   SSRC of Source: 32 bits
+
+      As defined in Section 4.1 of [RFC3611].
+
+   Unimpaired Seconds: 32 bits
+
+      A count of the number of Unimpaired Seconds that have occurred.
+
+      An Unimpaired Second is defined as a continuous period of one
+      second during which no frame loss or discard due to late arrival
+      has occurred.  Every second in a session must be classified as
+      either OK or Concealed.
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 11]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+      Normal playout of comfort noise or other silence-concealment
+      signals during periods of talker silence, if VAD is used, shall be
+      counted as Unimpaired Seconds.
+
+      Two values are reserved: a value of 0xFFFFFFFE indicates out of
+      range (that is, a measured value exceeding 0xFFFFFFFD), and a
+      value of 0xFFFFFFFF indicates that the measurement is unavailable.
+
+   Concealed Seconds: 32 bits
+
+      A count of the number of Concealed Seconds that have occurred.
+
+      A Concealed Second is defined as a continuous period of one second
+      during which any frame loss or discard due to late arrival has
+      occurred.
+
+      Equivalently, a Concealed Second is one in which some Loss-Type
+      concealment has occurred.  Buffer Adjustment-Type concealment
+      SHOULD NOT cause Concealed Seconds to be incremented, with the
+      following exception.  An implementation MAY cause Concealed
+      Seconds to be incremented for 'emergency' buffer adjustments made
+      during talkspurts.
+
+      Loss-Type concealment is reactive insertion or deletion of samples
+      in the audio playout stream due to effective frame loss at the
+      audio decoder.  "Effective frame loss" is the event in which a
+      frame of coded audio is simply not present at the audio decoder
+      when required.  In this case, substitute audio samples are
+      generally formed, at the decoder or elsewhere, to reduce audible
+      impairment.
+
+      Buffer Adjustment-Type concealment is proactive or controlled
+      insertion or deletion of samples in the audio playout stream due
+      to jitter buffer adaptation, re-sizing decisions, or re-centering
+      decisions within the endpoint.
+
+      Because this insertion is controlled, rather than occurring
+      randomly in response to losses, it is typically less audible than
+      Loss-Type concealment.  For example, jitter buffer adaptation
+      events may be constrained to occur during periods of talker
+      silence, in which case only silence duration is affected, or
+      sophisticated time-stretching methods for insertion/deletion
+      during favorable periods in active speech may be employed.  For
+      these reasons, Buffer Adjustment-Type concealment MAY be exempted
+      from inclusion in calculations of Concealed Seconds and Severely
+      Concealed Seconds.
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 12]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+      However, an implementation SHOULD include Buffer Adjustment-Type
+      concealment in counts of Concealed Seconds and Severely Concealed
+      Seconds if the event occurs at an 'inopportune' moment, such as an
+      emergency or large, immediate adaptation during active speech or
+      an unsophisticated adaptation during speech without regard for the
+      underlying signal.  In these cases, the assumption of low
+      audibility cannot hold.  In other words, jitter buffer adaptation
+      events that may be presumed to be audible SHOULD be included in
+      Concealed Seconds and Severely Concealed Seconds counts.
+
+      Concealment events that cannot be classified as Buffer Adjustment-
+      Type MUST be classified as Loss-Type.
+
+      For clarification, the count of Concealed Seconds MUST include the
+      count of Severely Concealed Seconds.
+
+      Two values are reserved: a value of 0xFFFFFFFE indicates out of
+      range (that is, a measured value exceeding 0xFFFFFFFD), and a
+      value of 0xFFFFFFFF indicates that the measurement is unavailable.
+
+   Severely Concealed Seconds: 16 bits
+
+      A count of the number of Severely Concealed Seconds.
+
+      A Severely Concealed Second is defined as a non-overlapping period
+      of one second during which the cumulative amount of time that has
+      been subject to frame loss or discard due to late arrival exceeds
+      the SCS Threshold.
+
+      Two values are reserved: a value of 0xFFFE indicates out of range
+      (that is, a measured value exceeding 0xFFFD), and a value of
+      0xFFFF indicates that the measurement is unavailable.
+
+   Reserved: 8 bits
+
+      These bits are reserved.  They MUST be set to zero by senders and
+      ignored by receivers (see [RFC6709], Section 4.2).
+
+   SCS Threshold: 8 bits
+
+      The SCS Threshold is defined as the percentage of packets
+      corresponding to lost or discarded frames that must occur within a
+      one second period in order for the second to be classified as a
+      Severely Concealed Second.  This is expressed in numeric format
+      0:8 and hence can represent a range of 0 to 99.6 percent loss or
+      discard.
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 13]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+      A default threshold of 5 percent effective frame loss (50 ms
+      effective frame loss ) per second is suggested.  This corresponds
+      to an SCS Threshold in hexadecimal of 0x0D.
+
+5.  SDP Signaling
+
+   [RFC3611] defines the use of SDP (Session Description Protocol)
+   [RFC4566] for signaling the use of XR blocks.  XR blocks MAY be used
+   without prior signaling.
+
+5.1.  SDP rtcp-xr-attrib Attribute Extension
+
+   This section augments the SDP attribute "rtcp-xr" [RFC3611] by
+   providing two additional values of "xr-format" to signal the use of
+   the two report blocks defined in this document.
+
+   xr-format =/ xr-conceal-block
+              / xr-conc-sec-block
+
+   xr-conceal-block = "loss-conceal"
+   xr-conc-sec-block = "conc-sec" ["=" thresh]
+
+   thresh      = 1*DIGIT          ; threshold for SCS (ms)
+   DIGIT =     <as defined in Section 3 of [RFC5234]>
+
+5.2.  Offer/Answer Usage
+
+   When SDP is used in Offer/Answer context, the SDP Offer/Answer usage
+   defined in [RFC3611] applies.  Note that "thresh" is declared by the
+   offer.
+
+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 Values
+
+   This document assigns two block type values in the IANA "RTP Control
+   Protocol Extended Reports (RTCP XR) Block Type Registry" under the
+   subregistry "RTCP XR Block Type":
+
+   Name:       LCB
+   Long Name:  Loss Concealment Metrics Block
+   Value       30
+   Reference:  Section 3.1
+
+
+
+
+Clark, et al.                Standards Track                   [Page 14]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   Name:       CSB
+   Long Name:  Concealed Seconds Metrics Block
+   Value       31
+   Reference:  Section 4.1
+
+6.2.  New RTCP XR SDP Parameters
+
+   This document also registers two new parameters in the "RTP Control
+   Protocol Extended Reports (RTCP XR) Session Description Protocol
+   (SDP) Parameters Registry":
+
+   o  "loss-conceal"
+
+   o  "conc-sec"
+
+6.3.  Contact Information for Registrations
+
+   The contact information for the registrations is:
+
+   RAI Area Directors
+
+   rai-ads@tools.ietf.org
+
+7.  Security Considerations
+
+   It is believed that the RTCP XR blocks defined in this document
+   introduce no new security considerations beyond those described in
+   [RFC3611].  These blocks do not provide per-packet statistics, so the
+   risk to confidentiality documented in Section 7, Paragraph 3 of
+   [RFC3611] does not apply.
+
+8.  Contributors
+
+   Geoff Hunt wrote the initial version of this document.
+
+9.  Acknowledgements
+
+   The authors gratefully acknowledge reviews and feedback provided by
+   Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor,
+   Alissa Cooper, Claus Dahm, Randy Ethier, Roni Even, Adrian Farrel,
+   Jim Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones,
+   Rajesh Kumar, Keith Lantz, Alfred C. Morton, Mohamed Mostafa, Amy
+   Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Pete Resnick,
+   Albrecht Schwarz, Meral Shirazipour, Tom Taylor, and Hideaki Yamada.
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 15]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+10.  References
+
+10.1.  Normative References
+
+   [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.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [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.
+
+10.2.  Informative References
+
+   [G.711]    ITU-T, "Pulse Code Modulation (PCM) of Voice Frequencies",
+              ITU-T Recommendation G.711, 1988.
+
+   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
+              Performance Metric Development", BCP 170, RFC 6390,
+              October 2011.
+
+   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
+              Considerations for Protocol Extensions", RFC 6709,
+              September 2012.
+
+   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
+              RTP Monitoring Framework", RFC 6792, November 2012.
+
+   [VAD]      Wikipedia, "Voice activity detection", January 2014,
+              <http://en.wikipedia.org/w/
+              index.php?title=Voice_activity_detection&oldid=593287643>.
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 16]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+Appendix A.  Metrics Represented Using the Template from RFC 6390
+
+   a.  On-Time Playout Duration Metric
+
+       *  Metric Name: On-Time Playout Duration
+
+       *  Metric Description: 'On-time playout' is the uninterrupted,
+          in-sequence playout of valid decoded audio information
+          originating from the remote endpoint.  On-time playout
+          duration is playout duration of any signal other than those
+          used for concealment.
+
+       *  Method of Measurement or Calculation: See Section 3.2, On-Time
+          Playout Duration definition.
+
+       *  Units of Measurement: See Section 3.2, On-Time Playout
+          Duration definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 3rd paragraph.
+
+       *  Measurement Timing: See Section 3, 1st paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+   b.  Loss Concealment Duration Metric
+
+       *  Metric Name: Loss Concealment Duration
+
+       *  Metric Description: The duration of audio playout
+          corresponding to Loss-Type concealment.
+
+       *  Method of Measurement or Calculation: See Section 3.2, Loss
+          Concealment Duration definition.
+
+       *  Units of Measurement: See Section 3.2, Loss Concealment
+          Duration definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 3rd paragraph.
+
+       *  Measurement Timing: See Section 3, 1st paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+
+
+Clark, et al.                Standards Track                   [Page 17]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+       *  Reporting Model: See RFC 3611.
+
+   c.  Buffer Adjustment Concealment Duration Metric
+
+       *  Metric Name: Buffer Adjustment Concealment Duration
+
+       *  Metric Description: The duration of audio playout
+          corresponding to Buffer Adjustment-Type concealment.
+
+       *  Method of Measurement or Calculation: See Section 3.2, Buffer
+          Adjustment Concealment Duration definition.
+
+       *  Units of Measurement: See Section 3.2, Buffer Adjustment
+          Concealment Duration definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 3rd paragraph.
+
+       *  Measurement Timing: See Section 3, 1st paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+   d.  Playout Interrupt Count Metric
+
+       *  Metric Name: Playout Interrupt Count
+
+       *  Metric Description: The number of interruptions to normal
+          playout that occurred during the reporting period.
+
+       *  Method of Measurement or Calculation: See Section 3.2, Playout
+          Interrupt Count definition.
+
+       *  Units of Measurement: See Section 3.2, Playout Interrupt Count
+          definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 3rd paragraph.
+
+       *  Measurement Timing: See Section 3, 1st paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+
+
+
+Clark, et al.                Standards Track                   [Page 18]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   e.  Mean Playout Interrupt Size Metric
+
+       *  Metric Name: Mean Playout Interrupt Size
+
+       *  Metric Description: The mean duration of interruptions to
+          normal playout that occurred during the reporting period.
+
+       *  Method of Measurement or Calculation: See Section 3.2, Playout
+          Interrupt Count definition.
+
+       *  Units of Measurement: See Section 3.2, Playout Interrupt Count
+          definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 3rd paragraph.
+
+       *  Measurement Timing: See Section 3, 1st paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+   f.  Unimpaired Seconds Metric
+
+       *  Metric Name: Unimpaired Seconds
+
+       *  Metric Description: A count of the number of Unimpaired
+          Seconds that have occurred.
+
+       *  Method of Measurement or Calculation: See Section 4.2,
+          Unimpaired Seconds definition.
+
+       *  Units of Measurement: See Section 4.2, Unimpaired Seconds
+          definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 5th paragraph.
+
+       *  Measurement Timing: See Section 4, 1st paragraph for
+          measurement timing and Section 4.2 paragraph for Interval
+          Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 19]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   g.  Concealed Seconds Metric
+
+       *  Metric Name: Concealed Seconds
+
+       *  Metric Description: A count of the number of Concealed Seconds
+          that have occurred.
+
+       *  Method of Measurement or Calculation: See Section 4.2,
+          Concealed Seconds definition.
+
+       *  Units of Measurement: See Section 4.2, Concealed Seconds
+          definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 5th paragraph.
+
+       *  Measurement Timing: See Section 4, 1st paragraph for
+          measurement timing and Section 4.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+   h.  Severely Concealed Seconds Metric
+
+       *  Metric Name: Severely Concealed Seconds
+
+       *  Metric Description: A count of the number of Severely
+          Concealed Seconds that have occurred.
+
+       *  Method of Measurement or Calculation: See Section 4.2,
+          Severely Concealed Seconds definition.
+
+       *  Units of Measurement: See Section 4.2, Severely Concealed
+          Seconds definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 5th paragraph.
+
+       *  Measurement Timing: See Section 4, 1st paragraph for
+          measurement timing and Section 4.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 20]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+   i.  SCS Threshold Metric
+
+       *  Metric Name: SCS Threshold
+
+       *  Metric Description: The amount of time corresponding to lost
+          or discarded frames that must occur within a one-second period
+          in order for the second to be classified as a Severely
+          Concealed Second.
+
+       *  Method of Measurement or Calculation: See Section 4.2, SCS
+          Threshold definition.
+
+       *  Units of Measurement: See Section 4.2, SCS Threshold
+          definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 1.1, 5th paragraph.
+
+       *  Measurement Timing: See Section 4, 1st paragraph for
+          measurement timing and Section 4.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 21]
+
+RFC 7294                   RTCP XR Concealment                 July 2014
+
+
+Authors' Addresses
+
+   Alan Clark
+   Telchemy Incorporated
+   2905 Premiere Parkway, Suite 280
+   Duluth, GA  30097
+   USA
+
+   EMail: alan.d.clark@telchemy.com
+
+
+   Glen Zorn
+   Network Zen
+   77/440 Soi Phoomjit, Rama IV Road
+   Phra Khanong, Khlong Toie
+   Bangkok  10110
+   Thailand
+
+   Phone: +66 (0) 87 502 4274
+   EMail: gwz@net-zen.net
+
+
+   Claire Bi
+   Shanghai Research Institute of China Telecom Corporation Limited
+   No. 1835, South Pudong Road
+   Shanghai  200122
+   China
+
+   EMail: bijy@sttri.com.cn
+
+
+   Qin Wu
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: sunseawq@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 22]
+