doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc7244.txt b/doc/rfc/rfc7244.txt
new file mode 100644
index 0000000..4fa80a5
--- /dev/null
+++ b/doc/rfc/rfc7244.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         H. Asaeda
+Request for Comments: 7244                                          NICT
+Category: Standards Track                                          Q. Wu
+ISSN: 2070-1721                                                 R. Huang
+                                                                  Huawei
+                                                                May 2014
+
+
+        RTP Control Protocol (RTCP) Extended Report (XR) Blocks
+         for Synchronization Delay and Offset Metrics Reporting
+
+Abstract
+
+   This document defines two RTP Control Protocol (RTCP) Extended Report
+   (XR) blocks that allow the reporting of initial synchronization delay
+   and synchronization offset metrics for use in a range of RTP
+   applications.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 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/rfc7244.
+
+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.
+
+
+
+
+
+Asaeda, et al.               Standards Track                    [Page 1]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Synchronization Delay and Offset Metrics Reporting Blocks ..2
+      1.2. RTCP and RTCP XR Reports ...................................3
+      1.3. Performance Metrics Framework ..............................3
+      1.4. Applicability ..............................................3
+   2. Terminology .....................................................4
+      2.1. Standards Language .........................................4
+   3. RTP Flow Initial Synchronization Delay Report Block .............4
+      3.1. Metric Block Structure .....................................5
+      3.2. Definition of Fields in RTP Flow Initial
+           Synchronization Delay Metrics Block ........................5
+   4. RTP Flow Synchronization Offset Metrics Block ...................6
+      4.1. Metric Block Structure .....................................7
+      4.2. Definition of Fields in RTP Flow General
+           Synchronization Offset Metrics Block .......................7
+   5. SDP Signaling ...................................................9
+      5.1. SDP rtcp-xr-attrib Attribute Extension .....................9
+      5.2. Offer/Answer Usage .........................................9
+   6. IANA Considerations .............................................9
+   7. Security Considerations ........................................10
+   8. Acknowledgements ...............................................10
+   9. References .....................................................10
+      9.1. Normative References ......................................10
+      9.2. Informative References ....................................11
+   Appendix A. Metrics Represented Using the Template from RFC 6390 ..12
+
+1.  Introduction
+
+1.1.  Synchronization Delay and Offset Metrics Reporting Blocks
+
+   This document defines two new block types to augment those defined in
+   [RFC3611], for use in a range of RTP applications.
+
+   The first new block type supports reporting of the Initial
+   Synchronization Delay to establish a multimedia session.  Information
+   is recorded about the time difference between the start of RTP
+   sessions and the time the RTP receiver acquires all components of RTP
+   sessions in the multimedia session [RFC6051].
+
+   The second new block type supports reporting of the relative
+   synchronization offset time of two arbitrary streams (e.g., between
+   audio and video streams), with the same RTCP CNAME included in RTCP
+   Source description items (SDES) packets [RFC3550].
+
+   These metrics belong to the class of transport-level metrics defined
+   in [RFC6792].
+
+
+
+Asaeda, et al.               Standards Track                    [Page 2]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+1.2.  RTCP and RTCP XR Reports
+
+   The use of RTCP for reporting is defined in [RFC3550].  [RFC3611]
+   defined an extensible structure for reporting -- the RTCP Extended
+   Report (XR).  This document defines a new Extended Report block for
+   use with [RFC3550] and [RFC3611].
+
+1.3.  Performance Metrics Framework
+
+   "Guidelines for Considering New Performance Metric Development"
+   [RFC6390] provides guidance on the definition and specification of
+   performance metrics.  "Guidelines for Use of the RTP Monitoring
+   Framework" [RFC6792] provides guidance for reporting block format
+   using RTCP XR.  The metrics block described in this document is in
+   accordance with the guidelines in [RFC6390] and [RFC6792].
+
+1.4.  Applicability
+
+   When joining each session in layered video sessions [RFC6190] or the
+   multimedia session, a receiver may not synchronize playout across the
+   multimedia session or layered video session until RTCP Sender Report
+   (SR) packets have been received on all components of RTP sessions.
+   The components of RTP sessions are per-media-type RTP sessions for
+   the multimedia sessions or per-layer RTP sessions for the layered
+   video sessions.  For multicast sessions, the Initial Synchronization
+   Delay metric varies with the session bandwidth, the number of
+   members, and the number of senders in the session.  The RTP Flow
+   Initial Synchronization Delay Metrics Block defined in this document
+   can be used to report such a metric, i.e., the Initial
+   Synchronization Delay to receive all the RTP streams belonging to the
+   same multimedia session or layered video session.  In the absence of
+   packet loss, the Initial Synchronization Delay is equal to the
+   average time taken to receive the first RTCP packet in the RTP
+   session with the longest RTCP reporting interval.  In the presence of
+   packet loss, the media synchronization should rely on the in-band
+   mapping of RTP and NTP-format timestamps [RFC6051] or wait until the
+   reporting interval has passed, and the next RTCP SR packet is sent.
+
+   Receivers of the RTP Flow Initial Synchronization Delay Metrics Block
+   could use this metric to compare with targets (i.e., Service Level
+   Agreement or thresholds of the system) to help ensure the quality of
+   real-time application performance.
+
+   In an RTP multimedia session, there can be an arbitrary number of
+   streams carried in different RTP sessions, with the same RTCP CNAME.
+   These streams may be not synchronized with each other.  For example,
+   one audio stream and one video stream belong to the same session, and
+   the audio stream is transmitted lagging behind the video stream for
+
+
+
+Asaeda, et al.               Standards Track                    [Page 3]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+   multiple tens of milliseconds [TR-126].  The RTP Flow Synchronization
+   Offset block can be used to report such synchronization offset
+   between video and audio streams.  This block is also applied to the
+   case where an RTP session can contain media streams with media from
+   multiple media types.  The metrics defined in the RTP Flow
+   Synchronization Offset Metrics Block can be used by the network
+   manager for troubleshooting and dealing with user-experience issues.
+
+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].
+
+   In addition, the following terms are defined:
+
+   Initial Synchronization Delay:
+
+      A multimedia session comprises a set of concurrent RTP sessions
+      among a common group of participants, using one RTP session for
+      each media type.  The Initial Synchronization Delay is the average
+      time for the receiver to synchronize all components of a
+      multimedia session [RFC6051].
+
+   Synchronization Offset:
+
+      Synchronization between two media streams must be maintained to
+      ensure satisfactory Quality of Experience (QoE).  Two media
+      streams can be of the same or different media types belonging to
+      one RTP session, or of different media types belonging to one
+      multimedia session.  The Synchronization Offset is the relative
+      time difference of the two media streams that need to be
+      synchronized.
+
+3.  RTP Flow Initial Synchronization Delay Metrics Block
+
+   This block is sent by RTP receivers and reports the Initial
+   Synchronization Delay beyond the information carried in the standard
+   RTCP packet format.  Information is recorded about the time
+   difference between the start of the multimedia session and the time
+   when the RTP receiver acquires all components of RTP sessions
+   [RFC6051] measured at the receiving end of the RTP stream.
+
+   This block needs to be exchanged only occasionally, for example, sent
+   once at the start of the RTP session.
+
+
+
+
+Asaeda, et al.               Standards Track                    [Page 4]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+3.1.  Metric Block Structure
+
+   The RTP Flow Initial Synchronization Delay Metrics Block has the
+   following format:
+
+       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=27     |   Reserved    |         Block length=2        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      SSRC of Source                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               Initial Synchronization Delay                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 1: Report Block Structure
+
+3.2.  Definition of Fields in RTP Flow Initial Synchronization Delay
+      Metrics Block
+
+   Block type (BT): 8 bits
+
+      The RTP Flow Initial Synchronization Delay Metrics Block is
+      identified by the constant 27.
+
+   Reserved: 8 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 constant 2, in accordance with the definition of this field in
+      Section 3 of RFC 3611 [RFC3611].
+
+   SSRC of source: 32 bits
+
+      The SSRC of the media source SHALL be set to the value of the SSRC
+      identifier carried in any arbitrary component of RTP sessions
+      belonging to the same multimedia session.
+
+   Initial Synchronization Delay: 32 bits
+
+      The average delay, expressed in units of 1/65536 seconds, from the
+      beginning of the multimedia session [RFC6051] to the time when
+      RTCP packets are received on all of the component RTP sessions.
+      It is recommended that the beginning of the multimedia session is
+
+
+
+Asaeda, et al.               Standards Track                    [Page 5]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+      chosen as the time when the receiver has joined the first RTP
+      session of the multimedia session.  The value of the Initial
+      Synchronization Delay is calculated based on received RTCP SR
+      packets or the RTP header extension containing the in-band mapping
+      of RTP and NTP-format timestamps [RFC6051].  If there is no packet
+      loss, the Initial Synchronization Delay is expected to be equal to
+      the average time taken to receive the first RTCP packet in the RTP
+      session with the longest RTCP reporting interval or to the average
+      time taken to receive the first RTP header extension containing
+      the in-band mapping of RTP and NTP-format timestamps.
+
+      If the measurement is unavailable, the value of this field with
+      all bits set to 1 MUST be reported.
+
+4.  RTP Flow Synchronization Offset Metrics Block
+
+   In the RTP multimedia sessions or one RTP session, there can be an
+   arbitrary number of media streams and each media stream (e.g., audio
+   stream or video stream) is sent in a separate RTP stream.  In case of
+   one RTP session, each media stream or each medium uses a different
+   SSRC.  The receiver correlates these media streams that need to be
+   synchronized by means of the RTCP CNAME contained in the RTCP Source
+   Description (SDES) packets [RFC3550].
+
+   This block is sent by RTP receivers and reports the synchronization
+   offset of two arbitrary RTP streams that need to be synchronized in
+   the RTP multimedia session.  Information is recorded about the
+   relative average time difference between two arbitrary RTP streams
+   (the reporting stream and the reference stream) with the same CNAME
+   and measured at the receiving end of the RTP stream.  In order to
+   tell what the offset of the reporting stream is relative to, the
+   block for the reference stream with synchronization offset of zero
+   should be reported.
+
+   Instances of this block refer by synchronization source (SSRC) to the
+   separate auxiliary Measurement Information block [RFC6776], which
+   describes measurement periods in use (see Section 4.2 of [RFC6776]).
+   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 block, this block MUST be
+   discarded.
+
+
+
+
+
+
+
+
+Asaeda, et al.               Standards Track                    [Page 6]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+4.1.  Metric Block Structure
+
+   The RTP Flow General Synchronization Offset Metrics Block has the
+   following format:
+
+       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=28      | I | Reserved  |         Block length=3        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        SSRC of source                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Synchronization Offset, most significant word         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Synchronization Offset, least significant word        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 2: Report Block Structure
+
+4.2.  Definition of Fields in RTP Flow General Synchronization Offset
+      Metrics Block
+
+   Block type (BT): 8 bits
+
+      The RTP Flow General Synchronization Offset Metrics Block is
+      identified by the constant 28.
+
+   Interval Metric Flag (I): 2 bits
+
+      This field is used to indicate whether the Burst/Gap Discard
+      Summary Statistics 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.
+
+      In this document, the value I=00 is the reserved value and MUST
+      NOT be used.  If the value I=00 is received, then the XR block
+      MUST be ignored by the receiver.
+
+
+
+
+
+
+Asaeda, et al.               Standards Track                    [Page 7]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+   Reserved: 6 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
+      MUST be ignored by the receiver.
+
+   Block length: 16 bits
+
+      The constant 3, in accordance with the definition of this field in
+      Section 3 of RFC 3611 [RFC3611].
+
+   SSRC of Source: 32 bits
+
+      The SSRC of the media source SHALL be set to the value of the SSRC
+      identifier of the reporting RTP stream to which the XR relates.
+
+   Synchronization Offset: 64 bits
+
+      The synchronization offset of the reporting RTP stream relative to
+      the reference stream with the same CNAME.  The calculation of
+      Synchronization Offset is similar to the Difference D calculation
+      in the RFC 3550.  That is to say, if Si is the NTP timestamp from
+      the reporting RTP packet i, Ri is the time of arrival in NTP
+      timestamp units for reporting RTP packet i, Sj is the NTP
+      timestamp from the reference RTP packet j, and Rj is the time of
+      arrival in NTP timestamp units for reference RTP packet j, then
+      the value of the Synchronization Offset D may be expressed as
+
+         D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
+
+      If in-band delivery of NTP-format timestamps is supported
+      [RFC6051], Si and Sj should be obtained directly from the RTP
+      packets where NTP timestamps are available.  If not, Si and Sj
+      should be calculated from their corresponding RTP timestamps.  The
+      value of the Synchronization Offset is represented using a 64-bit
+      signed NTP-format timestamp as defined in [RFC5905], which is a
+      64-bit signed fixed-point number with the integer part in the
+      first 32 bits and the fractional part in the last 32 bits.  A
+      positive value of the Synchronization Offset means that the
+      reporting stream leads before the reference stream, while a
+      negative one means the reporting stream lags behind the reference
+      stream.  The Synchronization Offset of zero means the stream is
+      the reference stream.
+
+      If the measurement is unavailable, the value of this field with
+      all bits set to 1 MUST be reported.
+
+
+
+
+
+Asaeda, et al.               Standards Track                    [Page 8]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+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
+
+   Using the Augmented Backus-Naur Form (ABNF) [RFC5234], two new
+   parameters are defined for the two report blocks defined in this
+   document to be used with SDP [RFC4566].  They have the following
+   syntax within the "rtcp-xr" attribute [RFC3611]:
+
+   xr-format =/ xr-rfisd-block
+             / xr-rfso-block
+
+   xr-rfisd-block = "rtp-flow-init-syn-delay"
+   xr-rfso-block = "rtp-flow-syn-offset"
+
+   Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description
+   and the full syntax of the "rtcp-xr" attribute.
+
+5.2.  Offer/Answer Usage
+
+   When SDP is used in the offer/answer context, the SDP Offer/Answer
+   usage defined in [RFC3611] applies.
+
+6.  IANA Considerations
+
+   New report block types for RTCP XR are subject to IANA registration.
+   For general guidelines on IANA allocations for RTCP XR, refer to
+   Section 6.2 of [RFC3611].
+
+   This document assigns two new block type values in the RTCP XR Block
+   Type Registry:
+
+      Name:       RFISD
+      Long Name:  RTP Flow Initial Synchronization Delay
+      Value       27
+      Reference:  Section 3
+
+      Name:       RFSO
+      Long Name:  RTP Flow Synchronization Offset
+      Value       28
+      Reference:  Section 4
+
+
+
+
+
+
+Asaeda, et al.               Standards Track                    [Page 9]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+   This document also registers two new SDP [RFC4566] parameters for the
+   "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry:
+
+      *  "rtp-flow-init-syn-delay "
+      *  "rtp-flow-syn-offset"
+
+   The contact information for the registrations is:
+         RAI Area Directors <rai-ads@tools.ietf.org>
+
+7.  Security Considerations
+
+   When using Secure RTP [RFC3711], or other media-layer security,
+   reporting accurate synchronization offset information can expose some
+   details about the timing of the cryptographic operations that are
+   used to protect the media.  There is a possibility that this timing
+   information might enable a side-channel attack on the encryption. For
+   environments where this attack is a concern, implementations need to
+   take care to ensure cryptographic processing and media compression
+   take the same amount of time irrespective of the media content, to
+   avoid the potential attack.
+
+   Besides this, it is believed that this RTCP XR block introduces no
+   new security considerations beyond those described in [RFC3611].
+
+8.  Acknowledgements
+
+   The authors would like to thank Bill Ver Steeg, David R. Oran, Ali
+   Begen, Colin Perkins, Roni Even, Kevin Gross, Jing Zhao, Fernando
+   Boronat Segui, Mario Montagud Climent, Youqing Yang, Wenxiao Yu,
+   Yinliang Hu, Jonathan Lennox, and Stephen Farrel for their valuable
+   comments and suggestions on this document.
+
+9.  References
+
+9.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.
+
+
+
+
+
+Asaeda, et al.               Standards Track                   [Page 10]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [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.
+
+   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
+              Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, June 2010.
+
+   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
+              Flows", RFC 6051, November 2010.
+
+   [RFC6190]  Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
+              "RTP Payload Format for Scalable Video Coding", RFC 6190,
+              May 2011.
+
+   [RFC6776]  Wu, Q., "Measurement Identity and information Reporting
+              using SDES item and XR Block", RFC 6776, August 2012.
+
+9.2.  Informative References
+
+   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
+              Performance Metric Development", RFC 6390, October 2011.
+
+   [RFC6792]  Wu, Q., "Guidelines for Use of the RTP Monitoring
+              Framework", RFC 6792, November 2012.
+
+   [TR-126]   Broadband Forum, "Triple-play Services Quality of
+              Experience (QoE) Requirements", Technical Report TR-126,
+              December 2006.
+
+   [Y.1540]   ITU-T, "IP packet transfer and availability performance
+              parameters", ITU-T Recommendation Y.1540, November 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asaeda, et al.               Standards Track                   [Page 11]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+Appendix A.  Metrics Represented Using the Template from RFC 6390
+
+   a.  Initial Synchronization Delay Metric
+
+       *  Metric Name: RTP Initial Synchronization Delay
+
+       *  Metric Description: See the definition of "Initial
+          Synchronization Delay" in Section 2.1.
+
+       *  Method of Measurement or Calculation: See the definition of
+          the "Initial Synchronization Delay" field in Section 3.2.
+
+       *  Units of Measurement: See the definition of the "Initial
+          Synchronization Delay" field in Section 3.2.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          the first paragraph of Section 3.
+
+       *  Measurement Timing: See the second paragraph of Section 3.
+
+       *  Use and applications: See Section 1.4.
+
+       *  Reporting model: See RFC 3611.
+
+   b.  Synchronization Offset Metric
+
+       *  Metric Name: RTP Synchronization Offset Delay
+
+       *  Metric Description: See the definition of "Synchronization
+          Offset" in Section 1.2.
+
+       *  Method of Measurement or Calculation: See the definition of
+          the "Synchronization Offset" field in Section 4.2.
+
+       *  Units of Measurement:  See the definition of the
+          "Synchronization Offset" field in Section 4.2.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          the second paragraph of Section 4.
+
+       *  Measurement Timing: See the third paragraph of Section 4.2 for
+          measurement timing and the Interval Metric flag.
+
+       *  Use and applications: See Section 1.4.
+
+       *  Reporting model: See RFC 3611.
+
+
+
+
+
+Asaeda, et al.               Standards Track                   [Page 12]
+
+RFC 7244                    SDO Report Blocks                   May 2014
+
+
+Authors' Addresses
+
+   Hitoshi Asaeda
+   National Institute of Information and Communications Technology
+   4-2-1 Nukui-Kitamachi
+   Koganei, Tokyo  184-8795
+   Japan
+
+   EMail: asaeda@nict.go.jp
+
+
+   Qin Wu
+   Huawei Technologies Co., Ltd.
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: bill.wu@huawei.com
+
+
+   Rachel Huang
+   Huawei Technologies Co., Ltd.
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: Rachel@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asaeda, et al.               Standards Track                   [Page 13]
+