Internet Engineering Task Force M. Montagud, Ed. Internet-Draft F. Boronat Intended status: Standards Track UPV Expires: August 13, 2015 H. Stokking TNO February 9, 2015 Early Event-Driven (EED) RTCP Feedback for Rapid IDMS draft-montagud-avtcore-eed-rtcp-idms-00 Abstract RFC 7272 defines two RTCP messages to enable Inter-Destination Media Synchronization (IDMS). However, if such RTCP messages are exchanged using the Regular RTCP reporting rules specified in RFC 3550, unacceptable delays can be originated when exchanging the synchronization information conveyed into RTCP packets. Accordingly, this document proposes Early Event-Driven (EED) RTCP reporting rules and messages to enable higher interactivity, dynamism, flexibility and accuracy when using RTP/RTCP for IDMS. Such IDMS extensions are targeted at providing faster reaction on dynamic situations, such as out-of-sync situations and channel change delays, as well as a finer granularity for synchronizing media-related events, while still adhering to the RTCP bandwidth bounds specified in RFC 3550. Besides, a new RTP/AVPF transport layer feedback message is proposed to allow the request of re-IDMS setting instructions (e.g., in case of RTCP packet loss) as well as rapid accommodation of latecomers in on-going sessions. Finally, this document also discusses various situations in which the reporting of Reduced-Size RTCP packets (RFC 3556) can be applicable and beneficial for IDMS. 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/. 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 August 13, 2015. Montagud, et al. Expires August 13, 2015 [Page 1] Internet-Draft EED RTCP for IDMS February 2015 Copyright Notice Copyright (c) 2015 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. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. RTP/RTCP for IDMS (RFC 7272) . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background: RTCP Reporting Rules . . . . . . . . . . . . . . 7 3.1. Regular RTCP Feedback (RFC 3550) . . . . . . . . . . . . 7 3.2. Early RTCP Feedback (RFC 4585) . . . . . . . . . . . . . 9 3.3. Rapid Synchronization of RTP Flows (RFC 6051) . . . . . . 10 3.4. SDP Modifiers for RTCP Bandwidth (RFC 3556) . . . . . . . 11 4. Early Event-Driven (EED) RTCP Feedback for IDMS . . . . . . . 12 4.1. Immediate Initial RTCP IDMS Settings . . . . . . . . . . 12 4.2. Dynamic EED Reporting of IDMS Settings . . . . . . . . . 13 4.3. Rapid (Re-)Synchronization Request . . . . . . . . . . . 16 4.4. Reduction of Channel Change Delays . . . . . . . . . . . 18 5. Reduced-Size RTCP Reporting for IDMS . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Montagud, et al. Expires August 13, 2015 [Page 2] Internet-Draft EED RTCP for IDMS February 2015 1. Introduction RTP (Real-Time Transport Protocol) and RTCP (RTP Control Protocol) protocols provide support for both intra-media and inter-media synchronization [RFC3550]. Moreover, [RFC7272] extends the RTP/RTCP capabilities to also enable Inter-Destination Media Synchronization (IDMS). However, if the proposed RTCP messages for IDMS in [RFC7272] are exchanged using the Regular RTCP reporting rules specified in [RFC3550], this can lead to unnaceptable performance in some delay- sensitive applications requiring stringent synchronization requirements [Montagud2012]. This is because the RTCP packets are exchanged in a pre-scheduled and inflexible manner, uniquely based on preserving the allowed traffic bounds specified in [RFC3550]. There is no support for timely feedback that would allow to repair or to manage dynamic events of interest close to their occurrence. Accordingly, there may be a variable time lag (from few seconds to several minutes in large-scale environments) between detecting an event (e.g., an out-of-sync situation) and being able to send an appropriate RTCP packet to handle it. Moreover, the RTCP reports may even not be received at the target side, since RTCP is sent over UDP, which does not provide a reliable control channel. This document proposes further extensions to RTP/RTCP to allow for a more strategic and efficient usage of the RTCP channel for IDMS. In particular, the RTCP extensions from [RFC4585] and [RFC6051] encourage the specification of novel RTCP reporting rules and messages, which in conjunction we call Early Event-Driven (EED) RTCP Feedback for IDMS, to enable higher interactivity, dynamism, flexibility and accuracy when using RTP/RTCP for IDMS. Such IDMS extensions are backward compatible with the solution specified in [RFC7272], while still adhering to the RTCP traffic bounds specified in [RFC3550]. More specifically, the proposed EED RTCP Feedback for IDMS provides the following key benefits: i) earlier correction of out-of-sync situations; ii) higher granularity for synchronizing the presentation of dynamically triggered media-related events (e.g., to ensure that important pieces of media content are simultaneously watched by all the users); iii) ability of dynamically requesting IDMS setting instructions (e.g., in case of RTCP packet loss); iv) dynamic and rapid accommodation of latecomers in on-going sessions; and v) reduction of channel-change (i.e., zapping) delays. Additionally, this document also discusses various situations in which the reporting of Reduced-Size RTCP packets [RFC3556] can be applicable and beneficial for IDMS. Montagud, et al. Expires August 13, 2015 [Page 3] Internet-Draft EED RTCP for IDMS February 2015 The proposed RTCP extensions for IDMS in this document are applicable to and can have a potentially high impact on a wide spectrum of scenarios with demanding IDMS characteristics [Montagud2012], such as Social TV, multi-party conferencing, and synchronous e-learning. A preliminary evaluation of such proposals can be found in [Montagud2013]. 1.1. RTP/RTCP for IDMS (RFC 7272) IDMS refers to the playout of media streams at two or more geographically distributed locations in a time-synchronized manner. A large number of applications requiring IDMS can be found in [Montagud2012]. Some relevant examples are: Social TV, multi-party conferencing, networked loudspeakers and networked multi-player games. [RFC7272] extends the RTP/RTCP mechanisms to exchange useful feedback information for IDMS between Synchronization Clients (SC) and a centralized Media Synchronization Application Server (MSAS). First, an RTCP XR block for IDMS, called "IDMS report", is defined to enable the SCs to report on packet reception and/or presentation times for a specific RTP stream. Second, a new RTCP IDMS packet type, called "IDMS Settings packet", is defined to allow the MSAS the transmission of IDMS setting instructions to the distributed SCs, based on the collected IDMS timings from them. This IDMS Settings packet will provide a common target playout point, referred to a specific RTP packet (concretely, to its generation timestamp) to which all the SCs belonging to a specific synchronization group (identified by the SyncGroupId field, specified in [RFC7272]) must synchronize. Besides, a new Session Description Protocol (SDP) parameter, called "rtcp-idms", is defined to notify about the usage of the above IDMS messages and to manage the group membership, thus allowing the co- existence of various independent groups of users in IDMS-enabled sessions. Figure 1 shows the architectural solution for IDMS adopted in [RFC7272], wich is based on a sync-maestro scheme [Montagud2012]. In this particular case, the SCs are co-located with RTP Receivers and the MSAS is co-located with the RTP Sender (although it could be co- located with an SC or with a third-party entity). The MSAS is responsible for collecting the IDMS reports from all the SCs belonging to a specific group, computing the delay differences among them and, if needed, sending IDMS Settings packets to make them to enforce the required adjustments to achieve IDMS. Although other architectural solutions are feasible, such as a distributed or a master/slave scheme [Montagud2012], this document also focuses on the sync-maestro scheme. Montagud, et al. Expires August 13, 2015 [Page 4] Internet-Draft EED RTCP for IDMS February 2015 +-----------------------+ +-----------------------+ | | | | | RTP Sender | | RTP Receiver | | | RTCP RR + | | | +-----------------+ | XR for IDMS | +-----------------+ | | | | | <-------------- | | | | | | Media | | | | | | | | Synchronization | | | | Synchronization | | | | Application | | | | Client | | | | Server | | RTCP SR + | | (SC) | | | | (MSAS) | | IDMS Settings | | | | | | | | --------------> | | | | | +-----------------+ | | +-----------------+ | | | | | +-----------------------+ +-----------------------+ Figure 1: IDMS Architecture 2. 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]. The terminology defined in "RTP: A Transport Protocol for Real-Time Applications" [RFC3550], "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585], "Rapid Synchronisation of RTP Flows" [RFC6051], and in "RTCP for Inter-Destination Media Synchronization" [RFC7272], apply. The naming convention for RTCP is sometimes confusing. Below is a list of RTCP related terms and their meaning. Those concepts were defined in [RFC3550], [RFC4585], and [RFC5506], but refreshed here for a better understanding of this document: o RTCP packet: There are different types of RTCP packets, each one reporting on a specific metric or event of interest. It consists of a fixed header part followed by structured fields or elements depending on the information conveyed in that RTCP packet type. o Regular RTCP mode: Mode of operation in which no preferred transmission of feedback messages is allowed. Instead, RTCP packets are sent following the rules specified in [RFC3550]. o Regular RTCP packet: RTCP packet that is sent using Regular RTCP mode. Montagud, et al. Expires August 13, 2015 [Page 5] Internet-Draft EED RTCP for IDMS February 2015 o Event: An observation that is (potentially) of interest to the participants of a media session and thus useful to be reported by means of an RTCP feedback message in a timely fashion. o Regular RTCP packet: RTCP packet that is sent using Regular RTCP mode. o Early RTCP mode: Mode of operation in which a participant is capable of reporting events of interest in a timely fashion (i.e., close to their occurrence). o Early RTCP packet: RTCP packet that is transmitted earlier than the scheduled transmission time when following the reporting rules specified in [RFC3550]. In [RFC4585], Early RTCP packets may be sent either as "Immediate Feedback" or as "Early RTCP" modes, depending on the group size. In the context of this document, Early RTCP packets are sent by the MSAS, which is a single centralized entity. Therefore, no dithering interval is needed to avoid feedback implosion, and RTCP packets can be sent in an "Immediate Feedback" mode. Sending an Early RTCP packet is also referred to as sending Early Feedback in this document. o Compound RTCP packet: A collection of two or more RTCP packets. In [RFC3550], it is mandatory to send RTCP packets as compound packets including at least an RTCP RR or SR packet, followed by an SDES packet with the CNAME item for the transmitting source identifier. Often the term "compound" is left out, so the interpretation of RTCP packet is therefore dependent on the context. o Minimal compound RTCP packet: A compound RTCP packet that contains only mandatory information, such as encryption prefix (if necessary), exactly one RTCP RR or SR packet, exactly one SDES packet with the CNAME item, and possible additional Feedback Messages [RFC4585] that must be sent as an Early RTCP packet. o (Full) Compound RTCP packet: A compound RTCP packet that conforms to the requirements on minimal compound RTCP packets and contains any additional number of RTCP packets (additional RRs, further SDES items, etc.). RTCP compound packets are typically sent when using Regular RTCP Feedback [RFC3550], although they may be also sent when using Early RTCP Feedback [RFC4585]. o Reduced-Size RTCP packet: It only contains one or more RTCP packets, being much smaller than (minimal and full) compound RTCP packets [RFC3550]. Such RTCP packets are sent when using Early RTCP Feedback, but must not be sent when using Regular RTCP Feedback. The full definition is in Section 4.1 of [RFC5506]. Montagud, et al. Expires August 13, 2015 [Page 6] Internet-Draft EED RTCP for IDMS February 2015 Besides, the definition of three key concepts will help understanding (the proposed IDMS extensions in) this document:. o Inter-Stream Synchronization Delay (or Latency): It refers to the time difference between the instant at which a user joins an on- going multimedia session, probably involving different media (e.g., audio and video, or when using layered and/or multi- description media) carried in separate streams, and the instant at which these correlated streams can be presented to that user in a synchronized manner. It is defined in [RFC6051]. o IDMS Delay (or Latency): It refers to the time difference between the instant at which an IDMS-related event occurs (e.g., a user joins an on-going session or an out-of-sync situation is detected) and the instant at which the IDMS Setting instructions to handle/ repair such event have been received and processed at the target side/s or SCs. o Latecomer: In multi-party multimedia services, users may join and leave the session quite frequently. A user who joins a session in progress is usually called a latecomer (or late joiner) [RFC6051]. 3. Background: RTCP Reporting Rules In this section, an overview of the RTCP reporting rules is provided. This is important to help understanding the benefits of the RTCP reporting rules and reports proposed in this document. 3.1. Regular RTCP Feedback (RFC 3550) During the media session's lifetime, the participants of an RTP Session (i.e., senders and receivers) regularly exchange RTCP reports (typically conveyed into compound RTCP packets) to inform mainly about QoS (Quality of Service) statistics, either in a unicast or multicast way (depending on the specific networked environment). On the one hand, a low frequency of RTCP feedback reporting can lead to faulty behavior due to outdated statistics. On the other hand, excessive reports can be redundant and cause unnecessary control traffic, probably leading to potential congestion situations. Also, if the RTCP packets were exchanged at a constant rate, the control traffic would grow linearly with the number of participants. Accordingly, a trade-off between up-to-date information and the amount of control traffic must be met. This would allow an application to (automatically) scale over session sizes ranging from few participants to tens of thousands. Montagud, et al. Expires August 13, 2015 [Page 7] Internet-Draft EED RTCP for IDMS February 2015 The total amount of control traffic added by RTCP should be limited to a small (so that the primary function of media data transport is not impaired) and known (so that each participant can independently calculate its share) fraction of the allocated RTP session bandwidth. A fraction of 5 % is recommended in [RFC3550]. In such process, media senders are given special consideration to allow a more frequent report exchange of their RTCP statistics, some of which are indeed very relevant for multimedia synchronization. In particular, if the proportion of senders constitute less than one quarter of the session membership, this percentage is further divided into two parts, where 25 % must be dedicated to active senders and the remaining can be consumed by receivers. Otherwise, the RTCP bandwidth is equally shared between senders and receivers. Based on the above aspects, the RTCP report interval is dynamically and locally computed in each RTP entity, every time an RTCP packet is sent, according to the available session bandwidth, the average size of all received and sent RTCP packets, the number of participants in the session, their role (senders or receivers), as well as the unicast or multicast nature of the session (see Section 6.2 of [RFC3550] for further details). This (deterministically) calculated RTCP report interval should also have a lower bound to avoid having bursts (cumpling) of RTCP packets when the number of participants is small and the law of large numbers is not helping to smooth out the traffic overhead. This would also help to avoid excessive frequent reports during transient outages like a network partition. The recommended value in [RFC3550] for that fixed minimum interval is 5 s. Besides, a delay should be imposed to each participant before sending the first RTCP packet upon joining the session. This allows a quicker convergence of the RTCP report interval to the correct value. This initial delay may be set to half the minimum RTCP report interval (i.e., 2.5 s) in multicast sessions, whilst it may be set to zero in unicast sessions. In some cases (e.g. if the data rate is high and the application demands more frequent RTCP reports), an implementation may scale the minimum RTCP interval to a smaller value given by 360 divided by the session bandwidth (in kbps). This yields to an interval smaller than 5 s when the session bandwidth becomes greater than 72 kbps. In multicast sessions, only active senders may use that reduced minimum interval, whilst in unicast sessions it also may be used by receivers. In the above cases, however, the minimum interval of 5 s must be still taken into account during the membership accounting procedure to not prematurely time out participants (who can indeed be using it) because of inactivity. Montagud, et al. Expires August 13, 2015 [Page 8] Internet-Draft EED RTCP for IDMS February 2015 After that, the interval between RTCP packets is varied randomly over the range [0.5, 1.5] times that RTCP report interval to prevent floods of RTCP reports (i.e., to avoid that all RTCP packets are sent and received almost at the same time, in every report interval). Additionally, "timer reconsideration" algorithms are introduced to allow for a more rapid adaptation of the RTCP report interval in large-scale sessions, where the membership can largely vary (e.g., many receivers join and leave the session quite frequently). To compensate for the fact that the "timer reconsideration" algorithms converge to a lower value than the intended average RTCP bandwidth, the (randomized) report interval is finally divided by e-3/2=1.21828. 3.2. Early RTCP Feedback (RFC 4585) In [RFC4585], further RTCP reporting mechanisms are specified to enable receivers to provide, statistically, more immediate RTCP feedback to the senders. This Early RTCP Feedback profile, which is known as RTP Audio-Visual Profile with Feedback (RTP/AVPF), allows for short-term adaptation and efficient feedback-based repairing mechanisms to be implemented, while maintaining the RTCP bandwidth constraints and preserving scalability to large groups. The RTCP report interval specified in [RFC3550] is denoted as Regular RTCP interval in [RFC4585]. In addition, [RFC4585] enables to send RTCP reports earlier that the next scheduled Regular RTCP transmission time if a receiver detects the need to inform about media stream related events (e.g., picture or slice loss) close to their occurrence. [NOTE] A feedback suppression mechanism is adopted, in which receivers wait for a random dithering interval to avoid feedback implosion (i.e., lots of receivers reporting on the same event). The reporting rules for Regular RTCP packets in [RFC4585] are similar than the ones in [RFC3550]. However, the recommended minimum RTCP report interval of 5 s in [RFC3550] is dropped in [RFC4585]. Instead, an optional attribute, called "trr-int", is specified as an offset parameter (in ms) to the computed Regular RTCP Report interval. Note that providing "trr-int" as an independent variable is intended to restrain from sending too frequent Regular RTCP packets (i.e., saving RTCP bandwidth) while enabling higher flexibility to transmit Early RTCP packets (i.e., using the saved RTCP bandwidth) in response to dynamic events. This could not be achieved by reducing the overall RTCP bandwidth, because the frequency of Early RTCP packets would be affected as well. Values between 4 and 5 s for "trr-int" Montagud, et al. Expires August 13, 2015 [Page 9] Internet-Draft EED RTCP for IDMS February 2015 are recommended to assure interworking with RTP entities only using Regular RTCP Feedback. However, as "trr-int" is an optional attribute, it may be set to zero (default value) if a specific application would benefit from a higher frequency of Regular RTCP packets. In such a case, the only difference between the RTCP timing rules from [RFC3550] and [RFC4585] for transmitting Regular RTCP packets resides in the minimum value for the report interval, which is dropped in [RFC4585]. In order to preserve the RTCP traffic bounds, only one Early RTCP packet can be transmitted between two consecutive Regular RTCP packets (i.e. receivers cannot send two consecutive Early RTCP packets). After sending an Early RTCP packet, the RTCP reporting engine must schedule the transmission time for the next RTCP packet by skipping the next Regular RTCP interval. Furthermore, [RFC4585] defines a small number of general-purpose feedback messages as well as a format for codec- and application- specific feedback information for transmission in the RTCP payloads. 3.3. Rapid Synchronization of RTP Flows (RFC 6051) When using RTP streaming, the inter-stream synchronization delay can greatly increase in certain scenarios, especially in large multicast groups or when Multipoint Conference Units (MCU) are involved in the media delivery process. This increase of delay can be inacceptable and annoying to users, resulting in an overall poor Qualilty of Experience (QoE). The aim of [RFC6051] is to minimize the inter-stream synchronization delay when using RTP/RTCP-based streaming. The motivation is that a receiver cannot synchronize playout of the incoming media streams until compound RTCP packets, including a Source Description or SDES packet (including the media source identification) and a Sender Report or SR (including timing correlation parameters), are received for all the involved RTP senders in a multimedia session. In most implementations, media data will not be played out (watched or listened) until inter-stream synchronization is (initially) achieved. If there is no packet loss, this gives an expected delay equal to the average time for receiving the first RTCP packet from the RTP Session with the longest RTCP report interval. This delay is even more problematic if an RTCP SR packet from one of the involved RTP sessions is lost. [NOTE] Note that the inter-stream synchronization delay depends on the specific instant at which a user joins the multimedia session or each RTP session (e.g., the user may first receive the RTCP packets from the RTP session with the longest RTCP interval), as well as on Montagud, et al. Expires August 13, 2015 [Page 10] Internet-Draft EED RTCP for IDMS February 2015 the impact of the randomization processes in all the involved RTP sessions. In [RFC6051], three backward compatible extensions to the RTP/RTCP protocols are proposed to reduce the inter-stream synchronization delay. First, the RTCP timing rules are updated to allow Single Source Multicast (SSM) senders [RFC5760] the immediate transmission of an initial compound RTCP packet upon joining each RTP session in a multimedia session (in parallel with the initial RTP packets). The rationale for not allowing the transmission of immediate RTCP packets to SSM receivers is to avoid feedback implosion in case that many receivers join the session almost simultaneously ("flash crowd" effect). This is clearly not an issue for SSM senders, since there can be at most one sender. Likewise, feedback implosion is a concern for Any Source Multicast (ASM) sessions, so [RFC6051] does not propose changes to the RTCP timing rules in these kinds of multicast environments. Second, a new RTP/AVPF transport layer feedback message (this type of RTCP messages is defined in [RFC4585]), called RTCP-SR-REQ, is defined to allow requesting the generation of an Early RTCP SR packet from the media sender. This enables rapid (re-)synchronization in case that an RTCP SR has not been received for a long period (e.g. due to packet loss or in sessions with large RTCP reporting intervals). Likewise, this enables latecomers to achieve inter-stream synchronization as soon as possible upon joining the session. Finally, new RTP header extensions are defined to enable the inclusion of metadata (in particular, NTP-based timestamps) in RTP data packets for in-band synchronization, thus avoiding the need for receiving RTCP SR packets before streams can be synchronized. These RTP header extensions do not eliminate the need for RTCP SR messages, but both mechanisms must be used for the synchronization control process. The use of RTCP SR packets for inter-stream synchronization allows backwards compatibility, but also provides higher robustness in the presence of middle boxes (e.g., RTP translators) that might strip RTP header extensions. An accurate and rapid inter-stream synchronization is especially relevant when using layered, multi-description and multi-view media encodings. This is because all the individual RTP streams need to be synchronized before starting the decoding processes. 3.4. SDP Modifiers for RTCP Bandwidth (RFC 3556) In some applications, it may be appropriate to specify the RTCP bandwidth independently of the allocated RTP session bandwidth. Accordingly, [RFC3556] defines two additional Session Description Protocol (SDP) attributes to specify modifiers for the RTCP bandwidth for senders and receivers. Montagud, et al. Expires August 13, 2015 [Page 11] Internet-Draft EED RTCP for IDMS February 2015 On the one hand, using a separate parameter allows rate-adaptive applications to set an RTCP bandwidth consistent with a "typical" data bandwidth that is lower than the maximum bandwidth specified by the session bandwidth parameter. This allows the RTCP bandwidth to be kept under 5% of the session bandwidth when the rate has been adapted downward, e.g. based on the stability of the network conditions. On the other hand, there may be applications that send data at very low rates, but need to communicate quite frequent RTCP information. These applications may need to specify an RTCP bandwidth that is higher than 5% of the data bandwidth. If any of the SDP attributes for the RTCP bandwidth modifiers are omitted, the default value for that parameter is the one specified in the RTP profile in use for the session. [RFC3556] does not impose limits on the values that may be specified for both RTCP bandwidth modifiers, other than that they must be non-negative. However, the RTP specification and the appropriate RTP profile may specify limits. 4. Early Event-Driven (EED) RTCP Feedback for IDMS This section introduces the EED RTCP reporting mechanisms proposed in this document to enable higher flexibility, dynamism, interactivity and accuracy when using RTP/RTCP for IDMS, with a sync-maestro architecture. 4.1. Immediate Initial RTCP IDMS Settings [RFC6051] relaxes the timing rules for unicast and layered sessions so that SSM senders are allowed to transmit an initial compound RTCP packet (containing an RTCP SR packet and an RTCP SDES packet with a CNAME item) immediately on joining each RTP session in a multimedia session, in parallel with the initial RTP data packets. Hence, the inter-stream synchronization delay is significantly reduced, provided that the initial RTCP packet is not lost. The same rationale for reducing the inter-stream synchronization delay in [RFC6051] can also be extrapolated to IDMS. In such a case, it would also be desirable the transmission of a nearly-immediate RTCP IDMS Settings packet by the MSAS upon establishing a multimedia session. [NOTE]: Note that in this document, the terms (nearly-)immediate, close-to-instant and Early are used as synonymous. This is because the MSAS is a single centralized entity in the media session, and the Early RTCP packets can be sent immediately by this entity without requiring a contention algorithm, as required for receivers in [RFC4585]. Montagud, et al. Expires August 13, 2015 [Page 12] Internet-Draft EED RTCP for IDMS February 2015 If the MSAS is integrated within the RTP Server, it MUST send the IDMS Settings packet in parallel with the initial RTP data packets. If the Sync Manager is co-located within a SC or a third party entity (that also needs to be an RTP receiver for that session), it MUST send the IDMS Settings packet as soon as it receives the initial RTP data packets from the RTP Sender. In either case, as the MSAS is a single centralized RTP entity, it is also allowed to transmit Early RTCP packets [RFC6051]. This way, the SCs can start consuming the media in a synchronized manner earlier, thus ensuring a reduction of the IDMS Delay. This mechanism is purely a local change to the MSAS that can be implemented as a configurable option, as stated in [RFC6051]. 4.2. Dynamic EED Reporting of IDMS Settings During the media session's lifetime, if Regular RTCP Feedback is used, the MSAS may have to wait a nearly-complete RTCP reporting interval to be able to send a new compound RTCP packet (including an IDMS Settings packet) after detecting an out-of-sync situation, which might potentially take several seconds (up to 5 s or even more) [RFC3550]. This is illustrated in Figure 2. In such a case, if an event (e.g. out-of-sync situation) is detected just after the transmission of an RTCP packet (at instant t_r1), the next RTCP packet cannot be sent until the next randomized (over the scheduled transmission instant, t_d2) RTCP transmission time (at instant t_r2). The figure shows the worst case, in which the randomized RTCP report interval at that moment is near the upper limit, i.e.:. (t_r2 - t_r1) = 1.5 * (t_d2 - t_r1) Montagud, et al. Expires August 13, 2015 [Page 13] Internet-Draft EED RTCP for IDMS February 2015 R A N D O M I N T E R V A L S --> [0.5;1.5]*[t_d(n)- t_d(n-1)] ____/\____ ____/\____ ____/\____ / \ / \ / \ t_r1 t_r2 t_r3 | | | | | | |-------(---&-|-+-o-)----(-----|----+)----#-(---+-|-----)------> | | | | | | | Time | Event | Event is | Event is | | Occurs | Detected | Handled or | t_d0 t_d1 t_d2 Repaired t_d3 \_____ _____/ \_____ _____/ \_____ _____/ \/ \/ \/ S C H E D U L E D R T C P R E P O R T I N T E R V A L S \______ ______/\________ _________/\____ ____/ \/ \/ \/ R A N D O M I Z E D R T C P R E P O R T I N T E R V A L S \_ _/\______ _______/\_ _/ \/ \/ \/ DD M S A S AD D E L A Y \_____________ ____________/ \/ I D M S D E L A Y (R E G U L A R R T C P I N T E R V A L) Figure 2: Regular RTCP Timing Rules Legend ------- & Event Occurs O Event is detected # Event is handled/repaired ( ) Random Interval | t_d(n): Scheduled (Deterministic) RTCP Transmission Times + t_r(n): Real (Randomized) RTCP Transmission Times X RTCP Transmission Restriction (Cancellation) DD Detection Delay AD Adjustment Delay Figure 3: Legend Therefore, the contribution of the MSAS delay (i.e., the time interval since an event is detected and an IDMS Settings packet to handle or to repair it is transmitted) to the total IDMS Delay becomes a serious barrier for those use cases requiring stringent Montagud, et al. Expires August 13, 2015 [Page 14] Internet-Draft EED RTCP for IDMS February 2015 synchronization levels (e.g., networked loudspeakers, or networked games) [Montagud2012]. Accordingly, the MSAS is also allowed to dynamically send Early RTCP IDMS Settings packets once detecting events throughout the duration of the media session. This is illustrated in Figure 4. In such a case, an RTCP IDMS Settings packet is sent just after the detection of an event, despite that this moment moment is earlier than the next regular RTCP transmission time. Consequently, the IDMS Delay is significantly reduced, mainly due to the fact that the MSAS delay has been minimized (due to the inmediate transmission of the IDMS Settings packet). R A N D O M I N T E R V A L S --> [0.5;1.5]*[t_d(n)- t_d(n-1)] ____/\____ ____/\____ ____/\____ / \ / \ / \ t_r1 t_r2 Skipped t_r3 | | Handled | | | | | | | |-------(---&-|-+-o+)----(#----|----x)------(---+-|-----)------> | | | | | | Time | Event | Event is | | | Occurs | Detected | | t_d0 t_d1 t_d2 t_d3 \_____ _____/ \_____ _____/ \_____ _____/ \/ \/ \/ S C H E D U L E D R T C P R E P O R T I N T E R V A L S \______ ______/|_ _|\____________ ____________/ \/ | \/ E V E N T ? D R I V E N R T C P R E P O R T I N T E R V A L S |_| | M S A S D E L A Y \_____ _____/ \/ I D M S D E L A Y (E E D R T C P I N T E R V A L) Figure 4: Early Event-Driven (EED) RTCP Timing Rules Note that if "trr-int" is set to zero, only one Early RTCP packet can be transmitted between two consecutive Regular RTCP packets to preserve the RTCP traffic bounds [RFC3550]. It means that an Early RTCP packet can only be sent if the previous transmitted RTCP packet was a Regular RTCP packet. Hence, after sending an Early RTCP packet, the RTCP reporting engine MUST schedule the sending time for Montagud, et al. Expires August 13, 2015 [Page 15] Internet-Draft EED RTCP for IDMS February 2015 the next RTCP packet by delaying (i.e., skipping) one more Regular RTCP report interval, as in [RFC4585]. In case of high frequency of events, setting an offset value for the Regular RTCP report interval, by means of using the "trr-int" attribute, can help to save RTCP bandwidth (by restraining the transmission of too frequent Regular RTCP packets) while being able to use the (saved) bandwidth when events occur. This is out of scope of this document. Therefore, the proposed EED RTCP reporting rules are based on the fact that not all the feedback reports from the MSAS are of equal importance. This means that some feedback reports from the MSAS need to be reported in a timely fashion. The dynamic EED reporting of IDMS Settings packets is also be very useful to provide playout hints for specific events that must be presented to all the involved users in a fine-grained synchronized way with the piece of content they refer to. Those events can be media-related events whose timing can be known in advance (e.g., commercials, start of the match in a sports event...), but the events' timing could be even unknown (e.g., a goal in a football match...) or dynamically triggered by either operators (e.g., a TV quiz show, in-game actions, interesting scenes...) or users (e.g., shared service control, interactive instant messaging...). Therefore, the use of EED RTCP Feedback for IDMS implies an interaction between the application-layer (through which operator or user generated events are triggered) and the transport/control layer (i.e., RTP/RTCP protocols) in order to translate the high-level (i.e., content-based or action-based) events into lower level calls (i.e., transmission of Early RTCP packets), as well as their alignment in terms of timelines. These are not severe issues, since the MSAS will be co-located with the Media Sender in most implementations. However, this differs from the use of Regular RTCP Feedback for IDMS, in which the IDMS adjustments are purely based on packet-level timestamps. 4.3. Rapid (Re-)Synchronization Request If the initial compound RTCP packet (including an SR, SDES and IDMS Settings packets) is lost, the affected SCs will not be able to synchronize the media playout until the report interval has passed, and the next RTCP packet can be sent. This is undesirable. [RFC6051] defines a new RTP/AVPF transport layer feedback message to request the generation of an Early RTCP SR, allowing rapid inter- stream (re-)synchronization. Montagud, et al. Expires August 13, 2015 [Page 16] Internet-Draft EED RTCP for IDMS February 2015 A similar mechanism is proposed in this document to be applied for IDMS purposes. A new RTP/AVPF transport layer feedback message [RFC4585], called RTCP-IDMS-REQ, is introduced to request the rapid generation (and transmission) of an RTCP IDMS Settings packet by the MSAS (see Figure 5). 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| FMT=TBD | PT=RTPFB=205 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of media source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media Stream Correlation Identifier (SyncGroupId) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (TBD: To Be Determined) Figure 5: RTCP-IDMS-REQ Feedback Message The Payload Type (PT) of this type of RTCP message should be 205, as specified in [RFC4585], the Frame Message Type (FMT) MUST be assigned by IANA (Internet Assigned Numbers Authority), and its length must be equal to 3. The SSRC of the packet sender MUST indicate the SC sending the packet, while the SSRC of the media source field MUST indicate the source of the media stream the SC (who sends this RTCP- IDMS-REQ) is unable to synchronize. In contrast to the RTCP-SR-REQ feedback message defined in [RFC6051], in which the Feedback Control Information (FCI) part is kept empty, in the RTCP-IDMS-REQ it must carry the SyncGroupId (specified in [RFC7272]) to which the sender of this message belongs. Once a new RTCP-IDMS-REQ is received by the MSAS, it MUST generate an Early RTCP IDMS Settings packet as soon as possible, while complying with the Early RTCP feedback rules. This mechanism can also be employed if a SC has not received RTCP IDMS Settings in a (configurable) long time interval. The RTCP-IDMS- REQ packet MAY be repeated once per RTCP reporting interval if no RTCP IDMS Settings packet is forthcoming. Likewise, the MSAS MAY ignore RTCP-IDMS-REQ packets if its regular schedule for RTCP transmission will allow the SC to synchronize within a reasonable time interval. Montagud, et al. Expires August 13, 2015 [Page 17] Internet-Draft EED RTCP for IDMS February 2015 Although this mechanism is similar to the one in [RFC6051] to request rapid RTCP SRs, it is especially necessary since, in most implementations,the IDMS Settings packets will not be regularly sent in each RTCP report interval, as RTCP SRs, but only when the detected asynchrony exceeds an allowable threshold.. When using SSM sessions with unicast feedback, it is possible that the feedback target and the MSAS are not co-located. If a feedback target receives an RTCP-IDMS-REQ feedback message in such a case, the request SHOULD be forwarded to the MSAS. However, the mechanism to be used for forwarding such requests is not defined in this document. If the feedback target provides a network management interface, it might be useful to provide a log of which SCs send RTCP-IDMS-REQ feedback packets and which do not, since the later will experience slower stream synchronization. 4.4. Reduction of Channel Change Delays The participation and support of latecomers are key issues to enable dynamic IDMS-enabled sessions. One widely applicability of the RTCP- IDMS-REQ messages is the dynamic and rapid accommodation of latecomers. Once a latecomer joins an IDMS-enabled session, it MUST send an RTCP- IDMS-REQ to the MSAS of that session. Then, the MSAS MUST generate an Early RTCP IDMS Settings packet to rapidly bring the latecomer up- to-date, thus minimizing the IDMS Delay experienced by that latecomer (i.e. the time interval between joining and acquiring IDMS). Immediately after receiving the RTCP IDMS Settings packet, the latecomer will begin to play out the media stream in a time synchronized way with the other SCs, thus becoming an additional member in the IDMS-enabled session, as shown in Figure 5. This will prevent from both long annoying startup delays and initial playout inconsistencies. Montagud, et al. Expires August 13, 2015 [Page 18] Internet-Draft EED RTCP for IDMS February 2015 MSAS i-th SC j-th SC k-th SC (Media Sender) (Latecomer) | | | | | :::::: Media Session Set-up :::::: | | (see Section 3 in [RFC7272]) | | ... ... ... | |RTCP IDMS Packet | | | |---------------->|---------------->| | |===> | | | |===> RTP Packets | | | |===> | | | | ... ... ... | | RR + IDMS XR | | | |<++++++++++++++++| | | | | RR + IDMS XR | | |<++++++++++++++++|+++++++++++++++++| | |RTCP IDMS Packet |RTCP IDMS Packet | | |---------------->|---------------->| | | ... ... x t0 k-th SC | | | RTCP AVPF | joins | | | IDMS-REQ Packet | t2 x<****************|*****************|*****************x t1 | | | | |RTCP IDMS Packet | | | t3 x---------------->|---------------->|---------------->x t4 | | | | IDMS Settings | | | | reception | ... | | | | x t5: In Sync! | | | RR + IDMS XR | |<++++++++++++++++|+++++++++++++++++|+++++++++++++++++x | ... | Figure 6: IDMS Operation and Rapid Accommodation of Latecomers The timing diagram for the RTCP exchange processes is illustrated in Figure 6. It can be seen that, if enabling EED RTCP Feedback for IDMS, the IDMS delay (which is the time interval between joining and acquiring IDMS, represented by (t5 - t0) in Figure 6) for the latecomer (k-th SC) can be significantly reduced, mainly due to the fact that the MSAS delay ((t3 - t2) in Figure 6) can be minimized. Although the above discussion has been focused for latecomers, it is also applicable for reducing channel change (i.e., zapping) delays in IDMS-enable sessions, which is currently a hot research topic in the IPTV area. Concretely, the relevance of channel change delays and their variability in IDMS-sensitive services is threefold. First, as Montagud, et al. Expires August 13, 2015 [Page 19] Internet-Draft EED RTCP for IDMS February 2015 for inter-stream synchronization, the required time to receive the IDMS setting instructions must not contribute to further increase the channel change delays. Second, apart from the magnitudes of channel change delays, their variability (i.e., the delay variation for each user) will also impact the IDMS performance. Third, when a group of users are watching IPTV together and they (simultaneously) change (or must change) to another channel, any playout time differences among them will also influence the resulting delay. Therefore, in this context, the use of EED RTCP Feedback for IDMS is very beneficial because: i) it significantly reduces the time needed to receive the initial RTCP IDMS Settings packet; and ii) it enables the compensation of the delay differences when changing channels. Two additional mechanisms could contribute to further reduce the IDMS Delay. The first one consists of employing priority mechanisms for the transport of RTCP messages, e.g., by adopting a Differentiated Services (DiffServ) policy. This would help to decrease the Round Trip Time (RTT) delays and the loss probability for RTCP packets (out of the scope of this document). The second one is based on the transmission of Early RTCP-IDMS-REQ messages by latecomers upon joining the session. According to [RFC6051], the delay since joining and sending an RTCP-IDMS-REQ message ((t1-t0) in Figure 6) should not be reduced to avoid flooding of requests at specific time instants (e.g., at the time a broadcasted sport event begins). Although we initially adhere to this standard compliant rule in this document, we believe that it should be discussed within the AVTCORE WG if this flash crowd effect is a real limiting issue in real SSM scenarios (e.g., networked quiz shows, gaming, IPTV, etc.). Our initial assumption is that the upstream bandwidth availability by the SCs (which is not used for other purposes) and the aggregation and re- distribution mechanisms by Feedback Targets [RFC5760] do not entail a real constraint for allowing the transmission of Early RTCP-IDMS-REQ by the SCs. Moreover, it is assumed in [RFC6051] that all SCs switch channels simultaneously, but even though using automated procedures (e.g., through notifications via the Electronic Program Guides in IPTV), this would not be a matter of a few seconds, but most probably of minutes. 5. Reduced-Size RTCP Reporting for IDMS RTCP SR and RR contain relevant QoS statistics usable for monitoring of the media stream transmission and thus enable media adaptation. The regular transmission of these RTCP packets becomes very useful to infer trends between successive reports due to the dynamic nature of the conveyed information. Likewise, the tracking of the session size thanks to that regular reports warrants bounded RTCP traffic bandwidth. Moreover, compound RTCP packets are useful to establish and maintain multimedia synchronization. Due to the above issues, Montagud, et al. Expires August 13, 2015 [Page 20] Internet-Draft EED RTCP for IDMS February 2015 the regular transmission of compound RTCP packets must be maintained throughout the RTP session's lifetime. However, [RFC5506] defines certain changes to the RTCP reporting rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF profile [RFC4585]. The motivation is that, in some cases, it is more useful to report certain events of interest the more frequently or the sooner as possible to enable short-term adaptation, rather than sending full compound RTCP packets including periodic statistics. In low bitrate links (e.g. radio access technologies), there are some benefits of reporting Reduced-Size RTCP packets. First, if channels conditions are poor, smaller RTCP packets are much more likely to be successfully transmitted than larger compound RTCP packets, and they will also introduce lower traffic overhead. The last issue is critical, as those messages are likely to occur when channel conditions are poor (e.g., for reporting picture or slice loss). Second, the serialization time when transmitting small size RTCP packets is shorter than when transmitting full (larger) RTCP compound packets. Third, when the bandwidth availability is scarce, smaller RTCP packets will enable more frequent feedback messages. In high bitrate environments, the above issues are not real limitations, but using Reduced-Size RTCP packets may also be beneficial to reduce the processing delay and complexity of RTCP packets. Independently of the link type, additional benefits with sending feedback in small Reduced-Size RTCP packets can be cited. For instance, when using Early RTCP Feedback [RFC4585], receivers typically need to send frequent event-driven feedback messages. In such cases, if using Reduced-Sized RTCP packets, the risk that the RTCP bandwidth becomes too high during periods of heavy feedback signaling is reduced. More details about use cases for, benefits of and issues with Reduced-Size RTP reporting can be found in [RFC5506]. Accordingly, the use of Reduced-Size RTCP packets MAY also be beneficial when enabling the EED RTCP reporting rules for IDMS proposed in this document. [RFC5506] specifies that in Immediate Feedback mode, as it is the case of RTCP IDMS Settings packets, all feedback messages may be sent as Reduced-Size RTCP packets. However, it is also stated that Reduced-Size RTCP packets shall not be sent until at least one compound RTCP packet has been transmitted. Montagud, et al. Expires August 13, 2015 [Page 21] Internet-Draft EED RTCP for IDMS February 2015 This implies that if the use of non-compound RTCP packets [RFC5506] has been previously negotiated between the participants in an IDMS- enabled session, both the RTCP-IDMS-REQ and the RTCP IDMS Settings packets MAY be sent as non-compound RTCP packets, but only if a compound RTCP packet has been already sent by the senders of those feedback messages. The Reduced-Size RTCP reporting features do not apply to the first IDMS Settings packet, which SHOULD be sent in parallel with the initial RTP data packets (Section 4.1). In such a case, SCs would also be benefited by the reception of a compound RTCP packet including SR and SDES packets. This is also the case when a latecomer sends an Early RTCP-IDMS-REQ. Here, the media sender and the MSAS would also need an SDES packet from that latecomer for membership accounting. However, the use of Reduced-Size RTCP reporting MAY be beneficial when an RTCP-IDMS-REQ is sent by an active SC that has not received an RTCP IDMS Settings packet for a long period, requesting re- synchronization setting instructions. Moreover, Reduced-Size RTCP reporting MAY be especially useful for Dynamic EED transmission of IDMS Settings packets (Section 4.2), e.g. immediately after detecting an out-of-sync situation, or when a specific media event is targeted to be simultaneously presented in all the SCs. Reduced-Size RTCP packets can become substantially smaller than compound packets. A compound packet is forced to contain both an RR or an SR and an SDES with at least the CNAME item. The RR containing a report block for a single source is 32 bytes, and an SR is 52 bytes. Both may be larger if they contain report blocks for multiple sources. The SDES packet containing a CNAME item will be 10 bytes plus the CNAME string length. Here, it is reasonable that the CNAME string is at least 10 bytes to get a decent collision resistance. If the recommended form of user@host is used, then most strings will be longer than 20 characters. Additionally, for IDMS purposes: i) SCs will regularly send RTCP XR blocks for IDMS, which consist of 10 32-bit words (40 bytes); ii) the MSAS will send RTCP IDMS Settings packets, which consists of 9 32-bit words (36 bytes). Therefore, Reduced-Size RTCP packets can become at least 70-80 bytes smaller than RTCP compound packets, thus reducing the mean RTCP packet size, decreasing sporadic traffic peaks, reducing the transmission delay, and increasing the overall RTCP feedback frequency. Montagud, et al. Expires August 13, 2015 [Page 22] Internet-Draft EED RTCP for IDMS February 2015 6. Security Considerations This document does not impose security considerations, beyond the ones described in [RFC3550], [RFC4585], [RFC6051], and [RFC7272]. 7. IANA Considerations This document defines a new RTP/AVPF transport layer feedback message [RFC4585], called RTCP-IDMS-REQ, whose FMT Value needs to be assigned by IANA.. 8. Contributors Authors would like to thank the co-authors of [RFC7272] for their collaboration on specifying the RTCP extensions for IDMS, which are starting point of this work. 9. Conclusions This document proposes Early Event-Driven RTCP reporting rules to enable higher interactivity, dynamism and accuracy when using RTP/ RTCP for IDMS. 10. References 10.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. [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. Montagud, et al. Expires August 13, 2015 [Page 23] Internet-Draft EED RTCP for IDMS February 2015 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [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. [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010. [RFC7272] van Brandenburg, R., Stokking, H., van Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter- Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, June 2014. 10.2. Informative References [Montagud2012] Montagud, M., Boronat, F., Stokking, H., and R. van Brandenburg, ""Inter-Destination Multimedia Synchronization; Schemes, Use Cases and Standardization", Multimedia Systems Journal (Springer), 18(6), pp. 459-482", November 2012, . [Montagud2013] Montagud, M., Boronat, F., and H. Stokking, ""Early Event- Driven (EED) RTCP Feedback for Rapid IDMS", The 21st ACM International Conference on Multimedia (ACM MM 2013), Barcelona (Spain)", October 2013, . [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", RFC 5968, September 2010. Authors' Addresses Montagud, et al. Expires August 13, 2015 [Page 24] Internet-Draft EED RTCP for IDMS February 2015 Mario Montagud (editor) Universitat Politecnica de Valencia C/ Paraninf, 1 Grau de Gandia, Valencia 46730 Spain Phone: +34 962 849 341 Email: mamontor@upv.es Fernando Boronat Universitat Politecnica de Valencia C/ Paraninf, 1 Grau de Gandia, Valencia 46730 Spain Phone: +34 962 849 341 Email: fboronat@dcom.upv.es Hans Stokking TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 Email: hans.stokking@tno.nl Montagud, et al. Expires August 13, 2015 [Page 25]