doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc7272.txt b/doc/rfc/rfc7272.txt
new file mode 100644
index 0000000..e318df9
--- /dev/null
+++ b/doc/rfc/rfc7272.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                R. van Brandenburg
+Request for Comments: 7272                                   H. Stokking
+Category: Standards Track                                O. van Deventer
+ISSN: 2070-1721                                                      TNO
+                                                              F. Boronat
+                                                             M. Montagud
+                                                                     UPV
+                                                                K. Gross
+                                                            AVA Networks
+                                                               June 2014
+
+
+             Inter-Destination Media Synchronization (IDMS)
+                 Using the RTP Control Protocol (RTCP)
+
+Abstract
+
+   This document defines a new RTP Control Protocol (RTCP) Packet Type
+   and an RTCP Extended Report (XR) Block Type to be used for achieving
+   Inter-Destination Media Synchronization (IDMS).  IDMS is the process
+   of synchronizing playout across multiple media receivers.  Using the
+   RTCP XR IDMS Report Block defined in this document, media playout
+   information from participants in a synchronization group can be
+   collected.  Based on the collected information, an RTCP IDMS Settings
+   Packet can then be sent to distribute a common target playout point
+   to which all the distributed receivers, sharing a media experience,
+   can synchronize.
+
+   Typical use cases in which IDMS is useful are social TV, shared
+   service control (i.e., applications where two or more geographically
+   separated users are watching a media stream together), distance
+   learning, networked video walls, networked loudspeakers, etc.
+
+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/rfc7272.
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 1]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.1.  Applicability of RTCP to IDMS . . . . . . . . . . . . . .   3
+     2.2.  IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Inter-Destination Media Synchronization (IDMS) Use Cases  . .   4
+   4.  Overview of IDMS Operation  . . . . . . . . . . . . . . . . .   5
+   5.  Architecture for Inter-Destination Media Synchronization  . .   7
+     5.1.  Media Synchronization Application Server (MSAS) . . . . .   7
+     5.2.  Synchronization Client (SC) . . . . . . . . . . . . . . .   8
+     5.3.  Communication between MSAS and SCs  . . . . . . . . . . .   8
+   6.  RTCP XR IDMS Report Block . . . . . . . . . . . . . . . . . .   8
+   7.  RTCP Packet Type for IDMS (IDMS Settings Packet)  . . . . . .  11
+   8.  Timing and NTP Considerations . . . . . . . . . . . . . . . .  13
+   9.  On the Use of Presentation Timestamps . . . . . . . . . . . .  14
+   10. SDP Signaling for RTCP IDMS Settings Packet . . . . . . . . .  15
+   11. SDP Rules . . . . . . . . . . . . . . . . . . . . . . . . . .  16
+     11.1.  Offer/Answer Rules . . . . . . . . . . . . . . . . . . .  16
+     11.2.  Declarative Cases  . . . . . . . . . . . . . . . . . . .  17
+   12. Security Considerations . . . . . . . . . . . . . . . . . . .  17
+   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
+     13.1.  RTCP IDMS Packet Type  . . . . . . . . . . . . . . . . .  18
+     13.2.  RTCP XR IDMS Report Block  . . . . . . . . . . . . . . .  19
+     13.3.  RTCP-IDMS SDP Attribute  . . . . . . . . . . . . . . . .  19
+     13.4.  IDMS XR Block SPST Registry  . . . . . . . . . . . . . .  19
+     13.5.  Contact Information for Registrations  . . . . . . . . .  20
+   14. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  20
+   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
+     15.1.  Normative References . . . . . . . . . . . . . . . . . .  21
+     15.2.  Informative References . . . . . . . . . . . . . . . . .  21
+
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 2]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+1.  Introduction
+
+   IDMS refers to the playout of media streams at two or more
+   geographically distributed locations in a time-synchronized manner.
+   It can be applied to both unicast and multicast media streams and can
+   be applied to any type and/or combination of streaming media, such as
+   audio, video, and text (subtitles).  [Ishibashi2006] and
+   [Boronat2009] provide an overview of technologies and algorithms for
+   IDMS.
+
+   Inter-Destination Media Synchronization (IDMS) requires the exchange
+   of information on media arrival and presentation times among
+   participants in an IDMS session.  It may also require signaling for
+   the initiation and maintenance of IDMS sessions and groups of
+   receivers.
+
+   The presented RTCP specification for IDMS is independent of the
+   synchronization algorithm employed, which is out of scope of this
+   document.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Rationale
+
+2.1.  Applicability of RTCP to IDMS
+
+   Currently, a large share of real-time applications make use of RTP
+   and RTCP [RFC3550].  RTP provides end-to-end network transport
+   functions suitable for applications requiring real-time data
+   transport, such as audio, video, or data, over multicast or unicast
+   network services.  The timestamps, sequence numbers, and payload
+   (content) type identification mechanisms provided by RTP packets are
+   very useful for reconstructing the original media timing and the
+   original order of packets and for detecting packet loss at the
+   receiver.
+
+   The data transport is augmented by a control protocol (RTCP) to allow
+   monitoring of the data delivery in a manner that is scalable to large
+   groups and to provide minimal control and identification
+   functionality.  RTP receivers and senders provide reception quality
+   feedback by sending out RTCP receiver report (RR) and sender report
+   (SR) packets [RFC3550], respectively, which may be augmented by
+   extended report (XR) blocks [RFC3611].
+
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 3]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   IDMS involves the collection, summarization, and distribution of RTP
+   packet arrival and presentation times.  As information on RTP packet
+   arrival times and presentation times can be considered reception
+   quality feedback information, RTCP is well suited for carrying out
+   IDMS.
+
+2.2.  IDMS and ETSI
+
+   A first version of IDMS for use with RTP/RTCP was standardized by
+   ETSI Telecommunications and Internet converged Services and Protocols
+   for Advanced Networking (TISPAN) in [TS183063], resulting in an IANA
+   registration for an RTCP XR Block Type.  This work was then brought
+   as input to the IETF AVTCORE WG for further standardization,
+   leveraging the RTP/RTCP expertise present in the AVTCORE WG.  This
+   document is the result of that effort.
+
+   Although the IDMS protocol described in this document has evolved
+   significantly from the version that was originally specified by ETSI
+   TISPAN, it is still backwards compatible with the ETSI version.  As
+   such, it had been decided in ETSI to update the TS 183 063 document
+   to reference this document as the normative specification of IDMS.
+   This update can be found in newer versions of TS 183 063 (i.e.,
+   versions higher than 3.5.2).  In accordance, this document proposes
+   to update the IANA registration for the RTCP XR IDMS Report Block to
+   point to this document.  Finally, this document proposes an IANA
+   registry for Synchronization Packet Sender Type (SPST) values,
+   allowing the registration of extensions to this document.
+
+3.  Inter-Destination Media Synchronization (IDMS) Use Cases
+
+   There is a large number of use cases in which IDMS might be useful.
+   This section will highlight some of them.  It should be noted that
+   this section is in no way meant to be exhaustive.
+
+   A first usage scenario for IDMS is social TV.  Social TV is the
+   combination of media content consumption by two or more users at
+   different devices and locations combined with real-time communication
+   between those users.  An example of social TV is when two or more
+   users are watching the same television broadcast at different devices
+   and locations, while communicating with each other using text, audio,
+   and/or video.  A skew in their media playout processes can have
+   adverse effects on their experience.  A well-known use case here is
+   one friend experiencing a goal in a football match well before or
+   after another friend(s).
+
+   Another potential use case for IDMS is a networked video wall.  A
+   video wall consists of multiple computer monitors, video projectors,
+   or television sets tiled together contiguously or overlapped in order
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 4]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   to form one large screen.  Each of the screens reproduces a portion
+   of the larger picture.  In some implementations, each screen may be
+   individually connected to the network and receive its portion of the
+   overall image from a network-connected video server or video scaler.
+   Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
+   potentially faster.  If the refresh is not synchronized, the effect
+   of multiple screens acting as one is broken, with users noticing
+   tearing effects and no longer perceiving a single image.
+
+   A third usage scenario is that of networked loudspeakers in which two
+   or more speakers are connected to the network individually.  Such
+   situations can, for example, be found in large conference rooms,
+   legislative chambers, classrooms (especially those supporting
+   distance learning), and other large-scale environments such as
+   stadiums.  Since humans are more sensitive to differences in audio
+   delay compared to video delay, this use case needs even more accuracy
+   than the video wall use case.  Depending on the exact application,
+   the need for accuracy can then be in the range of microseconds.
+
+4.  Overview of IDMS Operation
+
+   This section provides a brief example of how the RTCP functionality
+   is used for achieving IDMS.  The section is tutorial in nature and
+   does not contain any normative statements.
+
+             Alice's  . . . . . . .tv:abc.com . . . . . . . Bob's
+        TV (Sync Client)         (Sync Server)      Laptop (Sync Client)
+               |                       |                          |
+               |      Media Session    |                          |
+               |<=====================>|                          |
+               |            Invite(URL, SyncGroupId)              |
+               |------------------------------------------------->|
+               |                       |   Media Session Setup    |
+               |                       |<========================>|
+               |                       |                          |
+               |                 Call Setup                       |
+               |<================================================>|
+               |                       |                          |
+               |       RTP Packets     |        RTP Packets       |
+               |<----------------------|------------------------->|
+               |  RR + XR IDMS Report  |                          |
+               |---------------------->|    RR + XR IDMS Report   |
+               |                       |<-------------------------|
+               |   RTCP IDMS Settings  |    RTCP IDMS Settings    |
+               |<----------------------|------------------------->|
+               |                       |                          |
+
+                  Figure 1: Example of a Typical IDMS Session
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 5]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   Alice is watching TV in her living room.  At some point, she sees
+   that Bob's favorite team is playing football.  She sends him an
+   invite to watch the program together.  Embedded in the invitation is
+   the link to the media server and a unique sync-group identifier.
+
+   Bob, who is also at home, receives the invite on his laptop.  He
+   accepts Alice's invitation, and the RTP client on his laptop sets up
+   a session with the media server.  A Voice over IP (VoIP) connection
+   to Alice's TV is also set up, so that Alice and Bob can talk while
+   watching the game together.
+
+   As is common with RTP, both the RTP client in Alice's TV as well as
+   the one in Bob's laptop send periodic RTCP RRs to the media server.
+   However, in order to make sure Alice and Bob see the events in the
+   football game at the same time, their clients also periodically send
+   an RTCP XR IDMS Report Block to the Sync Server function of the media
+   server.  Included in the RTCP XR IDMS Report Blocks are timestamps on
+   when both Alice and Bob received (and, optionally, when they played
+   out) a particular RTP packet.
+
+   The Sync Server function in the media server calculates a reference
+   client from the received RTCP XR IDMS Report Blocks (e.g., by
+   selecting the most lagged client as the reference for IDMS).  It then
+   sends an RTCP IDMS Settings Packet containing the playout information
+   of this reference client to the sync clients of both Alice and Bob.
+
+   In this case, Bob's connection has the longest delay and the
+   reference client, therefore, includes a delay similar to the one
+   experienced by Bob.  Upon reception of this information, Alice's RTP
+   client can choose what to do with this information.  In this case, it
+   decreases its playout rate temporarily until the playout time matches
+   with the reference client playout (and, thus, matches Bob's playout).
+   Another option for Alice's TV would be to simply pause playback until
+   it catches up.  The exact implementation of the synchronization
+   algorithm is up to the client.
+
+   Upon reception of the RTCP IDMS Settings Packet, Bob's client does
+   not have to do anything since it is already synchronized to the
+   reference client (since it is based on Bob's delay).  Note that other
+   synchronization algorithms may introduce even more delay than the one
+   experienced by the most delayed client, e.g., to account for delay
+   variations, for new clients joining an existing synchronization
+   group, etc.
+
+   For this functionality to work correctly, it is necessary that the
+   wallclocks of the receivers are synchronized with each other.  While
+   Alice and Bob both report when they receive, and optionally when they
+
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 6]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   playout, certain RTP packets, in order to correlate their reports to
+   each other, it is necessary that their wallclocks are synchronized.
+
+5.  Architecture for Inter-Destination Media Synchronization
+
+   The architecture for IDMS, which is based on a sync-maestro
+   architecture [Boronat2009], is diagrammed below.  In this particular
+   case, the Synchronization Client (SC) and Media Synchronization
+   Application Server (MSAS) entities are shown as additional
+   functionality for the RTP receiver and sender, respectively.
+
+      +-----------------------+        +-----------------------+
+      |                       |  SR +  |                       |
+      |      RTP Receiver     |  RTCP  |      RTP Sender       |
+      |                       |  IDMS  |                       |
+      |  +-----------------+  | <----- |  +-----------------+  |
+      |  |                 |  |        |  |                 |  |
+      |  | Synchronization |  |        |  |      Media      |  |
+      |  |     Client      |  |        |  | Synchronization |  |
+      |  |      (SC)       |  |        |  |   Application   |  |
+      |  |                 |  |        |  |      Server     |  |
+      |  |                 |  | RR+XR  |  |      (MSAS)     |  |
+      |  |                 |  | -----> |  |                 |  |
+      |  +-----------------+  |        |  +-----------------+  |
+      |                       |        |                       |
+      +-----------------------+        +-----------------------+
+
+                  Figure 2: IDMS Architecture Diagram
+
+5.1.  Media Synchronization Application Server (MSAS)
+
+   An MSAS collects RTP packet arrival times and presentation times from
+   one or more SCs in a synchronization group by receiving RTCP XR IDMS
+   reports.  The MSAS summarizes and distributes this information to the
+   SCs in the synchronization group as synchronization settings via the
+   RTCP IDMS Settings Packet messages, e.g., by determining the SC with
+   the most lagged playout and using its reported RTP packet arrival
+   time and presentation time as a summary.
+
+   It should be noted that while the diagram above shows the MSAS as
+   part of the RTP sender, this is not necessary.  For example, an MSAS
+   might also be implemented as an independent function in the network
+   or in a master/slave type of architecture where one of the SC devices
+   also acts as an MSAS.  Wherever the MSAS is implemented, it is
+   important that the MSAS has access to the RTP stream to which the XR
+   reports apply, so that it is able to correlate the RTCP XR IDMS
+   reports coming from different SCs.
+
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 7]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+5.2.  Synchronization Client (SC)
+
+   An SC reports on RTP packet arrival times and presentation times of a
+   media stream.  It can receive IDMS Settings Packets containing
+   summaries of such information and use that to adjust its playout
+   buffer.  The SC sends RTCP XR IDMS reports to the MSAS.
+
+5.3.  Communication between MSAS and SCs
+
+   Two different message types are used for the communication between
+   MSAS and SCs.  For the SC->MSAS message containing the arrival and
+   playout information of a particular client, an RTCP XR IDMS Report
+   Block is used (see Section 6).  For the MSAS->SC message containing
+   the synchronization settings instructions, a new RTCP IDMS Settings
+   Packet is defined (see Section 7).
+
+6.  RTCP XR IDMS Report Block
+
+   This section specifies a new RTCP XR Block Type, the RTCP XR IDMS
+   Report Block, for reporting IDMS information to an MSAS.  In
+   particular, it is used to provide feedback information on arrival
+   times and presentation times of RTP packets.  Its definition is based
+   on [RFC3550] and [RFC3611].
+
+   In most cases, a single RTP receiver will only be part of a single
+   IDMS session, i.e., it will report on arrival and presentation times
+   of RTP packets from a single RTP stream in a certain synchronization
+   group.  In some cases, however, an RTP receiver may be a member of
+   multiple synchronization groups for the same RTP stream, e.g.,
+   watching a single television program simultaneously with different
+   groups.  In even further cases, a receiver may wish to synchronize
+   different RTP streams at the same time, either as part of the same
+   synchronization group or as part of multiple synchronization groups.
+   These are all valid scenarios for IDMS and will require multiple
+   reports by an SC.
+
+   This document does not define new rules for when to send RTCP
+   reports, but uses the existing rules specified in [RFC3550] for
+   sending RTCP reports.  When the RTCP reporting timer allows an SC to
+   send an IDMS report, the SC SHOULD report on an RTP packet received
+   during the period since the last RTCP XR IDMS Report Block was sent.
+   Because of RTP timestamp rollover, there is ambiguity in mapping RTP
+   timestamps to NTP timestamps.  The recommendation to report on recent
+   RTP packets serves to manage this ambiguity.  For more details on
+   which packet to report on, see below under "Packet Received RTP
+   timestamp".
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 8]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+    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=12     | SPST  |Resrv|P|         block length=7        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     PT      |               Resrv                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Media Stream Correlation Identifier              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     SSRC of media source                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Packet Received NTP timestamp, most significant word     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Packet Received NTP timestamp, least significant word    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Packet Received RTP timestamp                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Packet Presented NTP timestamp                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The RTCP XR IDMS Report Block consists of 8 32-bit words, with the
+   following fields:
+
+   Block Type (BT): 8 bits.  It identifies the block format.  Its value
+   is set to 12.
+
+   Synchronization Packet Sender Type (SPST): 4 bits.  This field
+   identifies the role of the packet sender for this specific Extended
+   Report.  It can have the following values, as enumerated in a
+   registry maintained by IANA (see Section 13.4):
+
+      SPST=0 Reserved for future use.
+
+      SPST=1 The packet sender is an SC.  It uses this XR to report
+      synchronization status information.  Timestamps relate to the SC
+      input.
+
+      SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]).
+
+      SPST=5-15 Unassigned.
+
+   Reserved bits (Resrv): 3 bits.  These bits are reserved for future
+   definition.  In the absence of such a definition, the bits in this
+   field MUST be set to zero at transmission and MUST be ignored by the
+   receiver.
+
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                    [Page 9]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   Packet Presented NTP timestamp flag (P): 1 bit.  Bit set to 1 if the
+   Packet Presented NTP timestamp field contains a value, 0 if it is
+   empty.  If this flag is set to 0, then the Packet Presented NTP
+   timestamp SHALL be ignored by the receiver.
+
+   Block Length: 16 bits.  This field indicates the length of the block
+   in 32-bit words minus one and is set to 7, as this RTCP XR IDMS Block
+   Report has a fixed length.
+
+   Payload Type (PT): 7 bits.  This field identifies the format of the
+   media payload, according to [RFC3551].  This is the payload type of
+   the RTP packet reported upon.  The PT field is needed in the case
+   where the MSAS is neither the media server nor a receiver of the
+   media stream, i.e., it is implemented as a third-party entity.  In
+   such cases, the MSAS needs the PT to determine the rate of
+   advancement of the timestamps of the RTP media stream to be able to
+   relate reports from different SCs on different RTP timestamp values.
+
+   Reserved bits (Resrv): 25 bits.  These bits are reserved for future
+   use and SHALL be set to 0 at transmission and MUST be ignored by the
+   receiver.
+
+   Media Stream Correlation Identifier: 32 bits.  This identifier is
+   used to correlate synchronized media streams.  The value 0 (all bits
+   are set "0") indicates that this field is empty.  The value 2^32-1
+   (all bits are set "1") is reserved for future use.  If the RTCP
+   Packet Sender is an SC (SPST=1), then the Media Stream Correlation
+   Identifier field contains the Synchronization Group Identifier
+   (SyncGroupId) to which the report applies.
+
+   Synchronization Source (SSRC): 32 bits.  The SSRC of the media source
+   is set to the value of the SSRC identifier carried in the RTP header
+   [RFC3550] of the RTP packet to which the XR IDMS relates.
+
+   Packet Received NTP timestamp: 64 bits.  This timestamp reflects the
+   wallclock time at the moment of arrival of the first octet of the RTP
+   packet to which the XR IDMS relates.  It is formatted based on the
+   NTP timestamp format as specified in [RFC5905].  See Section 8 for
+   more information on how this field is used.
+
+   Packet Received RTP timestamp: 32 bits.  This timestamp has the value
+   of the RTP timestamp carried in the RTP header [RFC3550] of the RTP
+   packet to which the XR IDMS relates.  Several consecutive RTP packets
+   will have equal timestamps if they are (logically) generated at once,
+   e.g., belong to the same video frame.  It may well be the case that
+   one receiver reports on the first RTP packet that has a certain RTP
+   timestamp, and a second receiver reports on the last RTP packet that
+   has that same RTP timestamp.  This would lead to an error in the
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 10]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   synchronization algorithm due to the faulty interpretation of
+   considering both reports to be on the same RTP packet.  When
+   reporting on an RTP packet, which is one of several consecutive RTP
+   packets having equal timestamps, an SC SHOULD report on the RTP
+   packet it received with the lowest sequence number.  Note that
+   'lowest sequence number' here is meant to be the first in the
+   sequence of RTP packets just received, not from an earlier time
+   before the last wrap around of RTP timestamps (unless this wrap
+   around occurs during the sequence with equal RTP timestamps).
+
+   Packet Presented NTP timestamp: 32 bits.  This timestamp reflects the
+   wallclock time at the moment the rendered media unit (e.g., video
+   frame or audio sample) contained in the first byte of the associated
+   RTP packet is presented to the user.  It is based on the time format
+   used by NTP and consists of the least significant 16 bits of the NTP
+   seconds part and the most significant 16 bits of the NTP fractional
+   second part.  If no Packet Presented NTP timestamp is available, this
+   field SHALL be set to 0 and be considered empty, and the Packet
+   Presented NTP timestamp flag (P) SHALL be set to 0.  With regards to
+   NTP epoch and rollover, the value of the Packet Presented NTP
+   timestamp is considered to always be greater than the Packet Received
+   NTP timestamp and to be within 2^16 seconds of it.  Presented in this
+   context means the moment the data is played out to the user of the
+   system, i.e., sound played out through speakers, video images being
+   displayed on some display, etc.  The accuracy resulting from the
+   synchronization algorithm will only be as good as the accuracy with
+   which the SCs can determine the delay between receiving packets and
+   presenting them to the end user.  If no presentation timestamps are
+   reported by SCs, the ability to accurately synchronize playout may be
+   limited.
+
+7.  RTCP Packet Type for IDMS (IDMS Settings Packet)
+
+   This section specifies the RTCP packet type for indicating
+   synchronization settings instructions to the receivers of the RTP
+   media stream.  Its definition is based on [RFC3550].  Synchronization
+   settings take the form of a report referencing a real or hypothetical
+   RTP packet selected or contrived by the MSAS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 11]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P| Resrv   |     PT=211    |             length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     SSRC of packet sender                     |
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |                     SSRC of media source                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Media Stream Correlation Identifier              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Packet Received NTP timestamp, most significant word     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Packet Received NTP timestamp, least significant word    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Packet Received RTP timestamp                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Packet Presented NTP timestamp, most significant word     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Packet Presented NTP timestamp, least significant word    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The first 64 bits form the header of the RTCP packet type, as defined
+   in [RFC3550].  The SSRC of the packet sender identifies the sender of
+   the specific RTCP packet.
+
+   The RTCP IDMS Settings Packet consists of 7 32-bit words, with the
+   following fields:
+
+   PT: 211, as registered by IANA.
+
+   SSRC: 32 bits.  The SSRC of the media source is set to the value of
+   the SSRC identifier of the media source carried in the RTP header
+   [RFC3550] of the RTP packet to which the RTCP IDMS Settings Packet
+   relates.
+
+   Media Stream Correlation Identifier: 32 bits.  This identifier is
+   used to correlate synchronized media streams.  The value 0 (all bits
+   are set "0") indicates that this field is empty.  The value 2^32-1
+   (all bits are set "1") is reserved for future use.  The Media Stream
+   Correlation Identifier contains the SyncGroupId of the group to which
+   this packet is sent.
+
+   Packet Received NTP timestamp: 64 bits.  This timestamp reflects the
+   wallclock time at the reference client at the moment it received the
+   first octet of the RTP packet to which this packet relates.  It can
+   be used by the synchronization algorithm on the receiving SC to
+   adjust its playout timing in order to achieve synchronization, e.g.,
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 12]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   to set the required playout delay.  The timestamp is formatted based
+   on the NTP timestamp format as specified in [RFC5905].  See Section 8
+   for more information on how this field is used.  Because RTP
+   timestamps do wrap around, the sender of this packet MUST use recent
+   values, i.e., choose NTP timestamps that reflect current time and not
+   too far in the future or in the past so as to create ambiguity with
+   regards to RTP timestamp wrap around.
+
+   Packet Received RTP timestamp: 32 bits.  This timestamp has the value
+   of the RTP timestamp carried in the RTP header [RFC3550] of the RTP
+   packet to which the XR IDMS relates.  This SHOULD relate to the first
+   arriving RTP packet containing this particular RTP timestamp, in case
+   multiple consecutive RTP packets contain the same RTP timestamp.
+
+   Packet Presented NTP timestamp: 64 bits.  This timestamp reflects the
+   wallclock time at the reference client at the moment it presented the
+   rendered media unit (e.g., video frame or audio sample) contained in
+   the first octet of the associated RTP packet to the user.  The
+   timestamp is formatted based on the NTP timestamp format as specified
+   in [RFC5905].  If no Packet Presented NTP timestamp is available,
+   this field SHALL be set to 0 and be considered empty.  This field MAY
+   be left empty if none or only one of the receivers reported on
+   presentation timestamps.  Presented here means the moment the data is
+   played out to the user of the system.
+
+   In some use cases (e.g., phased array transducers), the level of
+   control an MSAS might need to have over the exact moment of playout
+   is so precise that a 32-bit Presented timestamp will not suffice.
+   For this reason, this RTCP packet type for IDMS includes a 64-bit
+   Presented Timestamp field.  Since an MSAS will in practice always add
+   some extra delay to the delay reported by the most lagged receiver
+   (to account for packet jitter), it suffices for the RTCP XR IDMS
+   Report Block with which the SCs report on their playout to have a
+   32-bit Presented Timestamp field.
+
+8.  Timing and NTP Considerations
+
+   To achieve IDMS, the different receivers involved need synchronized
+   wallclocks as a common timeline for synchronization.  This
+   synchronized clock is used for reporting the Packet Received NTP
+   timestamp and the Packet Presented NTP timestamp, and for
+   interpretation of these fields in received IDMS Settings Packets.
+   Depending on the synchronization accuracy required, different clock
+   synchronization methods can be used.  For social TV, synchronization
+   accuracy should be achieved on the order of hundreds of milliseconds.
+   In that case, correct use of NTP on receivers will in most situations
+   achieve the required accuracy.  As a guideline, to deal with clock
+   drift of receivers, receivers should synchronize their clocks at the
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 13]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   beginning of a synchronized session.  In case of high required
+   accuracy, the synchronized clocks of different receivers should not
+   drift beyond the accuracy required for the synchronization mechanism.
+   In practice, this can mean that receivers need to synchronize their
+   clocks repeatedly during a synchronization session.
+
+   Because of the stringent synchronization requirements for achieving
+   good audio quality in some use cases, a high accuracy will be needed.
+   In this case, use of the global NTP system may not be sufficient.
+   For improved accuracy, a local NTP server could be set up, or some
+   other more accurate clock synchronization mechanism can be used, such
+   as GPS time or the Precision Time Protocol [IEEE1588-2008].
+
+   [RFC7273] defines a set of Session Description Protocol (SDP)
+   parameters for signaling the clock synchronization source or sources
+   available to and used by the individual receivers.  SCs MAY use
+   [RFC7273] to indicate their clock synchronization source or sources
+   in use and available.  Using these parameters, an SC can indicate
+   which synchronization source is being used at the moment.  An SC can
+   also indicate any other synchronization sources available to it.
+   This allows multiple SCs in an IDMS session to use the same or a
+   similar clock source for their session.
+
+   Applications performing IDMS may or may not be able to choose a
+   synchronization method for the system clock because this may be a
+   system-wide setting that the application cannot change.  How
+   applications deal with this is up to the implementation.  The
+   application might control the system clock, or it might use a
+   separate application clock or even a separate IDMS session clock.  It
+   might also report on the system clock and the synchronization method
+   used, without being able to change it.
+
+   [RFC7164] presents some guidelines on how RTP senders and receivers
+   should deal with leap seconds.  When relying on NTP for clock
+   synchronization, IDMS is particularly sensitive to
+   leap-second-induced timing discrepancies.  It is RECOMMENDED to take
+   the guidelines specified in [RFC7164] into account when implementing
+   IDMS.
+
+9.  On the Use of Presentation Timestamps
+
+   A receiver can report on different timing events, i.e., on packet
+   arrival times and on playout or presentation times.  A receiver SHALL
+   report on arrival times and a receiver MAY report on playout times.
+   RTP packet arrival times are relatively easy to report on.  Normally,
+   the processing and playout of the same media stream by different
+   receivers will take roughly the same amount of time.  Synchronizing
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 14]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   on packet arrival times may lead to some accuracy loss, but it will
+   be adequate for many applications, such as social TV.
+
+   Also, if the receivers are in some way controlled, e.g., having the
+   same buffer settings and decoding and rendering times, high accuracy
+   can be achieved.  However, if all receivers in a synchronization
+   session have the ability to report on and, thus, synchronize on
+   actual presentation times, this will be more accurate.  It is up to
+   the applications and implementations of this RTCP extension whether
+   to implement and use presentation timestamps.
+
+10.  SDP Signaling for RTCP IDMS Settings Packet
+
+   The SDP attribute rtcp-idms is used to signal the use of the RTCP
+   IDMS Settings Packet and the associated RTCP XR IDMS Report Block.
+   It is also used to carry an identifier of the synchronization group
+   to which clients belong or will belong.  The SDP attribute is used as
+   a media-level attribute during session setup.  This means that in
+   case of multiple related streams, IDMS is performed on one of them.
+   The other streams will be synchronized to this reference or master
+   stream using existing inter-stream synchronization (such as lip-sync)
+   solutions, i.e., using sender reports based on a common clock source.
+   Basic guidelines for choosing the media stream for IDMS is to choose
+   audio above video, as humans are most sensitive to degradation in
+   audio synchronization.  When using multi-description or multi-view
+   codecs, the IDMS control should be performed on the base layer.
+
+   This SDP attribute is defined as follows, using Augmented Backus-Naur
+   Form [RFC5234].
+
+   rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF
+
+   sync-grp = "sync-group=" SyncGroupId
+
+   SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294
+
+   DIGIT = %x30-39
+
+   SyncGroupId is a 32-bit unsigned integer and represented in decimal.
+   SyncGroupId identifies a group of SCs for IDMS.  The value
+   SyncGroupId=0 represents an empty SyncGroupId.  The value 4294967295
+   (2^32-1) is reserved for future use.  For a description on the value
+   of SyncGroupId to include, see Section 11.
+
+   The following is an example of the SDP attribute for IDMS.
+
+   a=rtcp-idms:sync-group=42
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 15]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+11.  SDP Rules
+
+11.1.  Offer/Answer Rules
+
+   The SDP usage for IDMS follows the rules defined in [RFC4566] and
+   Section 5 of [RFC3611] on SDP signaling with the exception of what is
+   stated here.  The IDMS usage of RTCP is a loosely coupled
+   collaborative attribute, in the sense that receivers send their
+   status information and, in response, the MSAS asynchronously sends
+   synchronization setting instructions.  The rtcp-idms attribute, thus,
+   indicates the ability to send and receive indicated RTCP messages.
+   This section defines how this SDP attribute should be used with
+   regard to an offer/answer context.
+
+   It is expected that, in most cases, the rtcp-idms attribute will be
+   used in an offer/answer context where receivers will have
+   predetermined, through some means outside the scope of this document,
+   a SyncGroupId before the media session is set up.  However, A sender
+   that assigns a SyncGroupId is also supported for cases, for example,
+   where the MSAS contains group management functionality and is
+   co-located with or otherwise communicates with the sender.  Thus,
+   both senders and receivers can insert the attribute and the
+   SyncGroupId.  Furthermore, the attribute is allowed to be inserted
+   for more than one media stream, allowing an SC to become part of
+   multiple synchronization groups simultaneously.  This effectively
+   couples two (or more) synchronization groups to each other.  If the
+   rtcp-idms attribute is inserted more than once for a particular media
+   session, each SyncGroupId SHALL only be inserted once.
+
+   In order to join an IDMS session, the receiver (the SC) inserts the
+   rtcp-idms attribute as a media-level attribute in the SDP offer.
+   This SDP offer can be an initial offer if the media session is
+   starting as a synchronized session.  The SDP offer can also be an
+   update to an existing media session, converting the session to an
+   IDMS session.  If the receiver has a predetermined SyncGroupId value,
+   it SHOULD use this value for setting the SyncGroupId parameter in the
+   rtcp-idms attribute.  If the receiver does not know the SyncGroupId
+   to be used, it MAY leave the SyncGroupId parameter empty by setting
+   its value to 0.
+
+   The sender SHALL include the rtcp-idms attribute in its answer.  If
+   the value of the SyncGroupId parameter in the offer is not empty (not
+   equal to 0), the sender SHOULD NOT change the SyncGroupId in its
+   answer.  If the SyncGroupId is empty, the sender SHALL include the
+   proper SyncGroupId in its answer.  If the sender receives an offer
+   with the value of the SyncGroupId parameter set to 0, and cannot
+   determine the proper SyncGroupId, it SHALL remove the attribute from
+   its answer.
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 16]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   A sender receiving an SDP offer without the rtcp-idms attribute can
+   also decide that IDMS is applicable to that media session.  In such a
+   case, the sender MAY insert the rtcp-idms attribute, including a non-
+   empty SyncGroupId, as part of its answer.
+
+   A receiver receiving an rtcp-idms attribute as part of the SDP answer
+   from a sender SHALL start sending RTCP XR IDMS reports (following all
+   the normal RTCP rules for sending RTCP XR IDMS Report Blocks) and
+   SHALL be ready to start receiving IDMS Settings.  As usual, if a
+   receiver does not support the attribute (e.g., in case of an MSAS-
+   inserted IDMS attribute), it SHALL ignore the attribute.
+
+   Different updates are applicable to such an IDMS session.  Updates
+   can be sent omitting the rtcp-idms attribute, thereby ending
+   involvement in the synchronization session.  Updates can also be sent
+   including the rtcp-idms attribute, but with a different SyncGroupId.
+   This indicates a switch in the synchronization group.
+
+11.2.  Declarative Cases
+
+   In certain situations, there is no offer/answer context, but only a
+   declarative modus.  In this case, the MSAS just inserts the rtcp-idms
+   attribute and a valid SyncGroupId.  Any receiver receiving the rtcp-
+   idms attribute in such a declarative case SHALL start sending RTCP XR
+   IDMS Report Blocks and SHALL be ready to start receiving RTCP IDMS
+   Settings Packets.
+
+12.  Security Considerations
+
+   The security considerations described in [RFC3611] apply to this
+   document as well.
+
+   The RTCP XR IDMS Report Block defined in this document is used to
+   collect, summarize, and distribute information on packet reception
+   and playout times of streaming media.  The information may be used to
+   orchestrate the media playout at multiple devices.
+
+   Errors in the information, either accidental or malicious, may lead
+   to undesired behavior.  For example, if one device erroneously or
+   maliciously reports a two-hour delayed playout, then another device
+   in the same synchronization group could decide to delay its playout
+   by two hours as well, in order to keep its playout synchronized.  A
+   user would likely interpret this two-hour delay as a malfunctioning
+   service.
+
+
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 17]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   Therefore, the application logic of both SCs and MSASs should check
+   for out-of-bound information.  Differences in playout time exceeding
+   configured limits (e.g., more than ten seconds) could be an
+   indication of such out-of-bound information.
+
+   Apart from checking for out-of-bound information in the endpoints, an
+   IDMS implementation can reduce its vulnerability to attacks by
+   including source authentication and message integrity measures,
+   reducing the potential for man-in-the-middle attacks.  [RFC7201]
+   provides an overview of the security options in RTP environments and
+   includes a set of recommendations for message integrity and source
+   authentication that are applicable to IDMS.  In addition to
+   preventing man-in-the-middle attacks from inserting erroneous IDMS
+   reports, the message confidentiality mechanisms outlined in [RFC7201]
+   also prevent third parties from determining that two or more end
+   hosts are receiving the same stream by looking at the Media Stream
+   Correlation Identifier.
+
+   Apart from attacking an IDMS session directly by sending incorrect
+   IDMS reports, and with it introducing delays for all devices in a
+   synchronization group, another potential vulnerability comes from the
+   clock synchronization method used.  Should an attacker succeed in
+   adjusting an SC's wallclock, that SC will report incorrect IDMS
+   reports.  In order to prevent such clock synchronization attacks, it
+   is recommended to use a secure time synchronization service.
+
+13.  IANA Considerations
+
+   This document defines a new RTCP packet type, the RTCP IDMS Packet
+   (IDMS Settings), within the existing Internet Assigned Numbers
+   Authority (IANA) registry of RTCP Control Packet Types.  This
+   document also defines a new RTCP XR Block Type, the RTCP XR IDMS
+   Report Block, within the existing IANA registry of RTCP Extended
+   Reports (RTCP XR) Block Types.
+
+   Further, this document defines a new SDP attribute "rtcp-idms" within
+   the existing IANA registry of SDP Parameters, which is part of the
+   "att-field (media level only)".  Finally, this document defines a new
+   IANA registry subordinate to the IANA RTCP Extended Reports (RTCP XR)
+   Block Type Registry: the IDMS XR Block SPST Registry.
+
+13.1.  RTCP IDMS Packet Type
+
+   This document assigns the packet type value 211 in the IANA 'RTCP
+   Control Packet types (PT)' registry to the RTCP IDMS Packet (IDMS
+   Settings).
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 18]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+13.2.  RTCP XR IDMS Report Block
+
+   This document updates the assignment of value 12 from the RTCP XR
+   Block Type for reporting IDMS information as per [TS183063] to the
+   RTCP XR IDMS Report Block defined in this document.
+
+   The RTCP XR IDMS Report Block contains an extensible SPST value
+   field; therefore, a new registry for this field is required.  This
+   new registry is defined in Section 13.4.
+
+13.3.  RTCP-IDMS SDP Attribute
+
+   The SDP attribute "rtcp-idms" defined by this document is registered
+   with the IANA registry of SDP Parameters as follows:
+
+      SDP Attribute ("att-field"):
+
+         Attribute name: rtcp-idms
+
+         Long form: RTCP IDMS Parameters
+
+         Type of name: att-field
+
+         Type of attribute: media level
+
+         Subject to charset: no
+
+         Purpose: see Section 10 of this document
+
+         Reference: this document
+
+         Values: see this document
+
+13.4.  IDMS XR Block SPST Registry
+
+   This document defines a new IANA registry subordinate to the IANA
+   RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR
+   Block SPST Registry.
+
+   Initial values for the IDMS XR Block SPST Registry are given below;
+   future assignments are to be made through the Specification Required
+   policy [RFC5226].  The registry is limited to 16 entries (numbered
+   0-15), with 0 being Reserved.  Values 5-15 are available for
+   assignment.
+
+   In accordance with [RFC5226], a Designated Expert will review any
+   applications made to IANA for the registry.  Primary criteria for the
+   Designated Expert to use when reviewing new applications are clarity
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 19]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   of the specification and, due to the relatively small value range of
+   SPST values available, potential overlap in functionality with
+   existing SPST registrations.
+
+   Value           Name                         Reference
+   -----           ----                         ---------
+   1               Synchronization Client       This document, Section 7
+   2               MSAS                         [TS183063]
+   3               SC Prime Input               [TS183063]
+   4               SC Prime Output              [TS183063]
+
+13.5.  Contact Information for Registrations
+
+   The contact information for the registrations is:
+
+   Ray van Brandenburg (ray.vanbrandenburg@tno.nl)
+   Brassersplein 2
+   2612CT, Delft, The Netherlands
+
+14.  Contributors
+
+   The following people have provided substantial contributions to this
+   document: Omar Niamut, Fabian Walraven, Ishan Vaishnavi, and Rufael
+   Mekuria.  In addition, the authors would like to thank Aidan
+   Williams, Colin Perkins, Magnus Westerlund, Roni Even, Peter
+   Musgrave, Ali Begen, Qin Wu, and Rob Koenen for their review comments
+   and contributions to the text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 20]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+15.  References
+
+15.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.
+
+   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
+              Video Conferences with Minimal Control", STD 65, RFC 3551,
+              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.
+
+   [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.
+
+   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
+              Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, June 2010.
+
+   [RFC7273]  Williams, A., Gross, K., van Brandenburg, R., and H.
+              Stokking, "RTP Clock Source Signalling", RFC 7273, June
+              2014.
+
+15.2.  Informative References
+
+   [Boronat2009]
+              Boronat, F., Lloret, J., and M. Garcia, "Multimedia group
+              and inter-stream synchronization techniques: a comparative
+              study", Elsevier Information Systems 34, Pages 108-131,
+              March 2009,
+              <http://www.sciencedirect.com/science/article/pii/
+              S0306437908000525>.
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 21]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+   [IEEE1588-2008]
+              IEEE, "1588-2008 - IEEE Standard for a Precision Clock
+              Synchronization Protocol for Networked Measurement and
+              Control Systems", July 2008,
+              <http://standards.ieee.org/findstds/
+              standard/1588-2008.html>.
+
+   [Ishibashi2006]
+              Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective
+              assessment of fairness among users in multipoint
+              communications", Proceedings of the 2006 ACM SIGCHI
+              international conference on Advances in computer
+              entertainment technology, Article No. 69, June 2006,
+              <http://dl.acm.org/citation.cfm?id=1178905>.
+
+   [RFC7164]  Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC
+              7164, March 2014.
+
+   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
+              Sessions", RFC 7201, April 2014.
+
+   [TS183063] ETSI, "Telecommunications and Internet converged Services
+              and Protocols for Advanced Networking (TISPAN); IMS-based
+              IPTV stage 3 specification", TS 183 063 v3.5.2, March
+              2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 22]
+
+RFC 7272                      RTCP for IDMS                    June 2014
+
+
+Authors' Addresses
+
+   Ray van Brandenburg
+   TNO
+   Brassersplein 2
+   Delft  2612CT
+   The Netherlands
+   Phone: +31-88-866-7000
+   EMail: ray.vanbrandenburg@tno.nl
+
+   Hans Stokking
+   TNO
+   Brassersplein 2
+   Delft  2612CT
+   The Netherlands
+   Phone: +31-88-866-7000
+   EMail: hans.stokking@tno.nl
+
+   M. Oskar van Deventer
+   TNO
+   Brassersplein 2
+   Delft  2612CT
+   The Netherlands
+   Phone: +31-88-866-7000
+   EMail: oskar.vandeventer@tno.nl
+
+   Fernando Boronat
+   Universitat Politecnica de Valencia (UPV)
+   Valencia  46730
+   Spain
+   Phone: +34 962 849 341
+   EMail: fboronat@dcom.upv.es
+
+   Mario Montagud
+   Universitat Politecnica de Valencia (UPV)
+   Valencia  46730
+   Spain
+   Phone: +34 962 849 341
+   EMail: mamontor@posgrado.upv.es
+
+   Kevin Gross
+   AVA Networks
+   Phone: +1-303-447-0517
+   EMail: Kevin.Gross@AVAnw.com
+
+
+
+
+
+
+
+van Brandenburg, et al.      Standards Track                   [Page 23]
+