Network Working Group H. Stokking Internet-Draft O. van Deventer R. van Brandenburg Intended status: Informational TNO Expires: April 30, 2015 F. Boronat M. Montagud Universitat Politecnica de Valencia October 27, 2014 Inter-Destination Media Synchronizaton for IPTV Environments draft-stokking-avtcore-idms-for-iptv-00.txt Abstract [RFC7272] describes the use of RTCP for the purpose of Inter- Destination Media Synchronization (IDMS) between Synchronization Clients (SCs) and an Media Synchronization Application Server (MSAS). This document extends that work for application in the area of IPTV. First, RTCP can be used according to the single source multicast (SSM) principles from [RFC5760] in the IPTV application area. This document specifies the use of a feedback target for collecting and possibly summarizing IDMS reports. For this, the document defines 2 new sub-report blocks for the use of IDMS according to the SSM principles. Alternatively, the MSAS can be co-located with the Feedback Target, for synchronizing small groups of receivers. Secondly, in an IPTV environment, different viewers may receive the same content, but in non-identical streams. The IDMS solution presented in [RFC7272] will no longer work in such a case. This document provides a solution for this. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Stokking, et al. Expires April 30, 2015 [Page 1] Internet-Draft idms for iptv October 27, 2014 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2015. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. IDMS in an IPTV environment . . . . . . . . . . . . . . . 3 1.1.1. IDMS for Single Source Multicast . . . . . . . . . . . 3 1.1.2. IDMS for different streams providing the same content . . . . . . . . . . . . . . . . . . . . . . . 4 2. IDMS report aggregation in SSM session . . . . . . . . . . . . 5 2.1. IDMS Packet Received Sub-Report Block . . . . . . . . . . 5 2.2. IDMS Packet Presented Sub-Report Block . . . . . . . . . . 7 3. IDMS with separate synchronization server with unicast synchronization settings . . . . . . . . . . . . . . . . . . . 7 4. IDMS in case of multiple RTP streams . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Stokking, et al. Expires April 30, 2015 [Page 2] Internet-Draft idms for iptv October 27, 2014 1. Introduction The Real-time Transport Protocol (RTP) provides a real-time transport mechanism suitable for unicast and multicast communication between multimedia applications. An important component of the RTP protocol is the control channel, defined as the RTP Control Protocol (RTCP). RTP and RTCP have been extended in numerous RFCs. Two such extensions are the extensions for Single-Source Multicast (SSM) Sessions with Unicast Feedback in [RFC5760] and the use of RTCP for Inter-Destination Media Synchronization (IDMS) in [RFC7272]. This Internet draft provides a number of extensions on the use of RTCP for IDMS in an IPTV environment. The IPTV environment has a number of characteristics that are currently not dealt with [RFC7272]. The introduction discusses the IPTV environment and identifies various gaps in the current IDMS solution. The next sections discuss solution directions for dealing with these gaps. The purpose of this Internet Draft is to build upon [RFC7272] so that the IDMS solution can be applied in an IPTV specific environment. 1.1. IDMS in an IPTV environment An IPTV environment has specific characteristics, which [RFC7272] does not deal with properly. These characteristics are: o Single Source Multicast (SSM, [RFC5760]) setting with a large number of viewers. o Different receivers may receive different versions of the same content, i.e. they receive non-identical streams, e.g. different unicast streams, different encoded streams, streams from different media senders. 1.1.1. IDMS for Single Source Multicast The first characteristic of IPTV is the large-scale Single Source Multicast (SSM) setting. Regular linear television is offered using SSM. Such SSM sessions have a large number of viewers, often in the millions, which requires a highly scalable approach. Applying IDMS to such an SSM session can be done in two ways: 1. Synchronize all receivers. In this case, [RFC7272] does not offer the scalability to synchronize all viewers in such large-scale sessions. In such a case each receiver contains a synchronization client (SC) which communicates with the Media Synchronization Application Server (MSAS).[RFC5760] offers a unicast feedback system using feedback targets (FTs) to collect and possibly aggregate RTCP reports of groups of receivers. IDMS can be performed using this Stokking, et al. Expires April 30, 2015 [Page 3] Internet-Draft idms for iptv October 27, 2014 same feedback system, providing more scalability. Section 2 of this document specifies how to accomplish this. 2. Synchronize independent groups of receivers, depending on the application. Use cases for synchronization, such as social TV or such as multiple receivers in a single physical location, require only a limited number of receivers to be synchronized together. For example, when millions of viewers watch the same television show, only specific groups of users viewing the show together would have to be synchronized, and only within their own group. [RFC5760] describes a system that provides all receivers with the same information. If only a limited subset of the receivers are synchronized together, not all receivers need to receive the same synchronization instructions. Section 3 of this document provides a unicast way of sending synchronization instructions to receivers, which requires the MSAS to be co-located with the Feedback Target. The choice between options 1 and 2 depends on a number of factors. If only a limited number of receivers use a service that requires IDMS, it is inefficient to synchronize all viewers. Also, playout timing differences between various receivers can be relatively large due to e.g. variable propagation delays. If that is the case, and every receiver is synchronizing to the slowest receiver, a lot of buffering needs to be done. This is not efficient, and also significantly increases channel changing delays. In these cases, it makes sense to use option 2. If on the other hand many viewers use synchronization sensitive services, and playout timing differences are relatively small, it may make sense to synchronize all receivers by using option 1. 1.1.2. IDMS for different streams providing the same content Different viewers may watch the same content, but use a different media stream in an IPTV environment. An example of this is when one viewer receives an High Definition (HD) stream and another viewer receives an Standard Definition (SD) stream. Another example is when multiple receivers view the same video-on-demand, receiving this using different unicast streams. Services such as social TV, where different viewers remotely view media content together, require synchronization of these different streams. The IDMS solution is based on RTP timestamps. For different streams, these timestamps are not aligned, i.e. there is no relation between the timestamps in one stream and the timestamps in another stream, because of the different random offset of the RTP timestamps, as well as potential clock skew. Because of this, the MSAS cannot determine proper synchronization instructions. There are two possible solution directions for this problem. Stokking, et al. Expires April 30, 2015 [Page 4] Internet-Draft idms for iptv October 27, 2014 The first is to have the media source output the different streams with the same timing. The NTP timestamp in the RTP packets will then be synchronous, i.e. IDMS can be based on this NTP timestamp analogue to inter-stream synchronization (lip-sync). This does require the MSAS to be informed on the RTP/NTP relationships of the various streams. This information is available in the RTCP SRs of the various streams. If the MSAS is part of the media source, this is implicitly available. If this is not the case, the MSAS should receive these SRs somehow. This document presents various options to achieve this. The other solution for this problem, is to have the media source determine and signal the relationship between the various RTP timestamps of the various streams. Again, if the MSAS is part of with the media source, then this information is locally available. If the MSAS is a separate entity, the media source can sent this information to the MSAS. Section 4 of this document shows how that is done. 2. IDMS report aggregation in SSM session [RFC5760] describes how to use Feedback Targets (FTs) or the Distribution Source (DS)for summarizing RTCP packets from receivers, using the Receiver Summary Information (RSI) Packet. This section describes two new sub-report blocks, to be used in those RSI packets. One sub-report block is for summarizing reported RTP packet received timestamps, the other is for summarizing reported RTP packet presented timestamps. A feedback target or distribution source MUST only summarize IDMS information from SCs, if they belong to the same synchronization group, i.e. when the reports from the receivers contain the same Media Stream Correlation Identifier [RFC7272]. If at least one of the receivers in a certain synchronization group reports on both packet received timestamps and packet presented timestamps, a feedback target or distribution source SHOULD also include packet presented timestamps. If all receivers report on packet presented timestamps, a feedback target or distribution source MUST include packet presented timestamps. If a feedback target or distribution source summarizes the packet received timestamps, it SHOULD also summarize the packet presented timestamps. 2.1. IDMS Packet Received Sub-Report Block To summarize the packet received timestamps in the IDMS information from SCs, a feedback target or distribution source can use the following sub-report block. The name of this sub-report block is "IDMS Received", the long name is "IDMS Packet Received NTP Stokking, et al. Expires April 30, 2015 [Page 5] Internet-Draft idms for iptv October 27, 2014 Timestamp". 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=TBD | Length | NDB | MF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Received RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PT | Resrv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media Stream Correlation Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Received NTP Timestamp - Minimum Distribution Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Received NTP Timestamp - Maximum Distribution Value | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Distribution Buckets | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IDMS Packet Received Sub-Report Block Sub-Report Block Type (SRBT): 8 bits, TBD upon IANA registration. Length: 8 bits, the length of the sub-report in 32-bit words, as defined in RFC 5760. Number of Distribution Buckets (NDB): 12 bits, as defined in RFC 5760, except for the calculation of the size of each bucket. Since the header is longer than the sub-report blocks defined in RFC 5760, the size of each bucket can be calculated using the formula ((length * 4) - 32) * 8 / NDB number of bits. Multiplicative Factor (MF): 4 bits, as defined in [RFC5760]. Packet Received RTP Timestamp: 32 bits, as defined in [RFC7272]. Payload Type (PT): 7 bits, as defined in [RFC7272]. Reserved Bits (Resrv): 25 bits, as defined in [RFC7272]. Media Stream Correlation Identifier: 32 bits, as defined in [RFC7272]. Stokking, et al. Expires April 30, 2015 [Page 6] Internet-Draft idms for iptv October 27, 2014 Packet Received NTP timestamp - Minimum Distribution Value: 64 bits, as defined in [RFC7272]. Packet Received NTP Timestamp - Maximum Distribution Value: 64 bits, as defined in [RFC7272]. Distribution Buckets: each bucket has ((Length * 4) - 28) * 8 / NDB bits. The whole sub-report block contains only a single packet received RTP timestamp value. Since various receivers will normally report on different packet received RTP timestamps, a feedback target MUST recalculate all packet received NTP timestamps to match the single packet received RTP timestamp. This will give an overview of the packet received times of all receivers for that specific RTP timestamp. This recalculation is necessary for all reported timestamps: minimum, maximum and those in the distribution buckets. 2.2. IDMS Packet Presented Sub-Report Block To summarize the packet presented timestamps in the IDMS information from SCs, a feedback target or distribution source can use the following sub-report block. The name of this sub-report block is "IDMS Presented", the long name is "IDMS Packet Presented NTP Timestamp". Stokking, et al. Expires April 30, 2015 [Page 7] Internet-Draft idms for iptv October 27, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT=TBD | Length | NDB | MF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Received RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PT | Resrv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media Stream Correlation Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Presented NTP Timestamp - Minimum Distribution Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Presented NTP Timestamp - Maximum Distribution Value | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Distribution Buckets | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IDMS Packet Presented Sub-Report Block Sub-Report Block Type (SRBT): 8 bits, TBD upon IANA registration. Length: 8 bits, the length of the sub-report in 32-bit words, as defined in RFC 5760. Number of Distribution Buckets (NDB): 12 bits, as defined in RFC 5760, except for the calculation of the size of each bucket. Since the header is longer than of the sub-report blocks defined in RFC 5760, the size of each bucket can be calculated using the formula ((length * 4) - 28) * 8 / NDB number of bits. Multiplicative Factor (MF): 4 bits, as defined in [RFC5760]. Packet Received RTP Timestamp: 32 bits, as defined in [RFC7272]. Payload Type (PT): 7 bits, as defined in [RFC7272]. Reserved Bits (Resrv): 25 bits, as defined in [RFC7272]. Media Stream Correlation Identifier: 32 bits, as defined in [RFC7272]. Packet Presented NTP timestamp - Minimum Distribution Value: 32 bits, as defined in [RFC7272]. Packet Presented NTP Timestamp - Maximum Distribution Value: 32 bits, Stokking, et al. Expires April 30, 2015 [Page 8] Internet-Draft idms for iptv October 27, 2014 as defined in [RFC7272]. Distribution Buckets: each bucket has ((Length * 4) - 28) * 8 / NDB bits. The whole sub-report block contains only a single packet received RTP timestamp value. Since various receivers will report on different packet presented NTP timestamps, a feedback target MUST recalculate all packet presented NTP timestamps to match the single packet received RTP timestamp. This is true for all reported timestamps: minimum, maximum and those in the distribution buckets. 3. IDMS with separate MSAS with unicast synchronization settings The second alternative for IDMS in a large-scale SSM context is to synchronize small groups of receivers that need to be synchronized with each other because of the service requirements. Different groups may still receive the same RTP streams, but can be synchronized independent of each other. In that case, each group MUST receive its own synchronization settings instructions in the form of IDMS Settings Packets as defined in [RFC7272]. Normally the Receiver Reports (RRs) or the Received Summary Information (RSI) is sent to all receivers. But, since different groups of receivers may need different synchronization settings instructions, these instructions cannot be multicast. As it happens, multicasting all instructions would lead to a situation where all receivers would receive a multitude of different settings instructions. They would have to find their own instructions based on the MSCI of their group, which is possible. But, with a large number of groups, this would be highly inefficient. This is why a unicast method is taken here. To unicast the instructions to the various SCs, the MSAS needs to directly receive the IDMS reports from the various SCs. This means the MSAS MUST be co-located with the feedback target. When supplying SCs with the unicast address to which they should sent their reports, different SCs in the same synchronization group MUST be allocated the same feedback target. Also, because the synchronization information is no longer relevant upstream of the MSAS, the feedback target SHOULD terminate these RTCP blocks and not forward them or summarize them. How the receivers receive the unicast address of the feedback target is out of scope of this draft. [RFC5760] only defines pre- configuration for this. Alternatively, the RTCP-attribute as specified in [RFC3605] can be used on the session level to provide receivers of a shared session with the unicast address of the MSAS, similar to how this is done in [TS183063]. Stokking, et al. Expires April 30, 2015 [Page 9] Internet-Draft idms for iptv October 27, 2014 Synchronization settings instructions MUST be sent by the MSAS to the source IP addresses of the received synchronization information, using the same destination port as the received synchronization information. 4. IDMS in case of multiple RTP streams IDMS is based on various receivers reporting on the packet received times or packet presentation times. This document describes situations in which the MSAS is not part of the media source. If all receivers receive the exact same RTP streams, e.g. in case of multiple receivers of a single multicast streams, this will work fine. The MSAS can relate the various received IDMS information. Even if different receivers report on different RTP timestamps, the MSAS can calculate the timing differences between clients by extrapolation using the RTP clock frequency derived from the reported payload type. However, when the MSAS is not co-located with the media source and the receivers receive the same content in different RTP streams, an MSAS cannot perform the necessary calculations for achieving synchronization. To perform these calculations, there has to exist some common timeline in the reports by the various receivers. To determine a common timeline, the MSAS needs some kind of information correlating the RTP timestamps in the various streams. This section provides two alternatives for this. The first alternative is to use the RTCP Sender Reports that belong to the various RTP streams. In these SRs, the RTP timestamps are linked to the employed wallclock time. This is normally used for intra- and inter-media synchronization. The media sources need to ensure that the same part of the content in different streams corresponds to the same wallclock time (NTP timestamp in the SR). This way the SRs of the various RTP streams can be used to establish a common timeline between those RTP streams. The easiest way to send the SR to the MSAS is by having the receiver append it to its report blocks. Another option is to have the MSAS act as a third party monitor, as described in [RFC3550]. The second alternative is that the media source sends information on the correlation of the various timestamps to the MSAS. This can be done by using the IDMS report block from [RFC7272], using the Synchronization Packet Sender Types (SPST) 3 and 4, as specified in [TS183063] Annex W, and registered with IANA in the IDMS XR Block SPST Registry. These SPSTs are normally used for synchronization in case a transcoder is changing the media stream such that the RTP timestamps also change. In this case, synchronization would be impossible between users receiving the original stream and users Stokking, et al. Expires April 30, 2015 [Page 10] Internet-Draft idms for iptv October 27, 2014 receiving the transcoded version. A transcoder can link an incoming RTP timestamps (SPST=3) to an outgoing RTP timestamp (SPST=4), and thus enable correlating the timelines. These SPSTs 3 and 4 can also be used if one source sends out two version of the same content, linking the timestamps of one stream to those of the other stream. 5. IANA Considerations This document defines two new RSI Sub-Report Blocks, the "IDMS Received" and the "IDMS Presented". Based on the specification in section 2, these two sub-report blocks are added to the IANA registry for Sub-Report Block Type (SRBT) Values for the RSI Packet, as part of the RTP parameters registration. 6. Security Considerations The content of this ID does not pose any security risks above or beyond those mentioned in [RFC5760] and [RFC7272]. 7. Acknowledgements 8. 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. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. [RFC7272] Brandenburg, R. van, Stokking, H., Deventer, O. van, Boronat, F., Montagud, M., Gross, K., "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, June 2014. [TS183063] ETSI, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification", TS 183 063 v3.6.1, August Stokking, et al. Expires April 30, 2015 [Page 11] Internet-Draft idms for iptv October 27, 2014 2014. Authors' Addresses Hans Stokking TNO Brassersplein 2 Delft, 2292CH The Netherlands Phone: 0031-(0)88-86 67 278 Fax: Email: hans.stokking@tno.nl URI: Oskar van Deventer TNO Brassersplein 2 Delft, 2292CH The Netherlands Phone: 0031-(0)88-86 67 078 Fax: Email: oskar.vandeventer@tno.nl URI: Ray van Brandenburg TNO Brassersplein 2 Delft, 2292CH The Netherlands Phone: 0031-(0)88-86 63 609 Fax: Email: ray.vanbrandenburg@tno.nl URI: Fernando Boronat Universitat Politecnica de Valencia IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia Valencia, 46730 Spain Phone: +34 962 849 341 Fax: Stokking, et al. Expires April 30, 2015 [Page 12] Internet-Draft idms for iptv October 27, 2014 Email: fboronat@dcom.upv.es URI: Mario Montagud Universitat Politecnica de Valencia IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia Valencia, 46730 Spain Phone: +34 962 849 341 Fax: Email: mamontor@posgrado.upv.es URI: Stokking, et al. Expires April 30, 2015 [Page 13]