diff options
Diffstat (limited to 'doc/rfc/rfc7272.txt')
| -rw-r--r-- | doc/rfc/rfc7272.txt | 1291 |
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] + |