GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7272

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7272.txt · Last modified: 2014/07/01 01:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki