Audio/Video Transport Working Group H.M. Stokking Internet Draft M.O. van Deventer Intended status: Informational O.A. Niamut Expires: July 2011 F.A. Walraven R. van Brandenburg TNO Netherlands I. Vaishnavi CWI Netherlands F. Boronat M. Montagud Universidad Politecnica de Valencia January 13, 2011 RTCP XR Block Type for inter-destination media synchronization draft-brandenburg-avt-rtcp-for-idms-03.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 14, 2011. Copyright Notice Copyright (c) 2011 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 Brandenburg Expires July 13, 2011 [Page 1] Internet-Draft RTCP for IDMS January 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document gives information on an RTCP XR Block Type and associated SDP parameter for inter-destination media synchronization (IDMS). The RTCP Block Type, registered with IANA based on an ETSI specification, is used to collect media play-out information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream and to distribute a summary of the collected information so that the participants can synchronize play- out. Typical applications for inter-destination media synchronization are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, network quiz shows, multi-playing online games, etc. Table of Contents 1. Introduction...................................................3 1.1. Inter-destination Media Synchronization...................3 1.2. Applicability of RTCP to IDMS.............................3 1.3. Applicability of SDP to IDMS..............................4 1.4. This document and ETSI TISPAN.............................4 2. Terminology....................................................4 3. Overview of IDMS operation.....................................4 4. Inter-destination media synchronization use cases..............6 5. Architecture for inter-destination media synchronization.......6 5.1. Media Synchronization Application Server (MSAS)...........7 5.2. Synchronization Client (SC)...............................7 6. RTCP XR Block Type for IDMS....................................7 7. SDP parameter for IDMS........................................10 8. Operational considerations....................................10 9. Security Considerations.......................................12 10. IANA Considerations..........................................12 11. Conclusions..................................................12 12. References...................................................13 12.1. Normative References....................................13 12.2. Informative References..................................13 13. Acknowledgments..............................................13 Brandenburg Expires July 13, 2011 [Page 2] Internet-Draft RTCP for IDMS January 2011 1. Introduction 1.1. Inter-destination Media Synchronization Inter-destination media synchronization (IDMS) refers to the play-out of media streams at two or more geographically distributed locations in a temporally 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). [Boronat2009] provides an overview of technologies and algorithms for IDMS. IDMS requires the exchange of information on media receipt and playout times. It may also require signaling for the initiation and maintenance of IDMS sessions and groups. The presented RTCP-XR specification for IDMS is independent of the used synchronization algorithm, which is out-of-scope of this document. 1.2. Applicability of RTCP to IDMS Currently, most multimedia applications make use of RTP and RTCP [RFC3550]. RTP (Real-time Transport Protocol) 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 and sequence number mechanisms provided by RTP are very useful to reconstruct the original media timing, reorder and detect some packet loss at the receiver side. 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 multicast networks, 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 Reports (XR) [RFC3611]. Thus, the feedback reporting features provided by RTCP make QoS monitoring possible and can be used for troubleshooting and fault tolerance management in multicast distribution services, such as IPTV. These protocols are intended to be tailored through modification and/or additions in order to include profile-specific information required by particular applications, and the guidelines on doing so are specified in [RFC5968]. Brandenburg Expires July 13, 2011 [Page 3] Internet-Draft RTCP for IDMS January 2011 IDMS involves the collection, summarizing and distribution of RTP packet arrival and play-out times. As information on RTP packet arrival times and play-out times can be considered reception quality feedback information, RTCP becomes a promising candidate for carrying out IDMS, which may facilitate implementation in typical multimedia applications. 1.3. Applicability of SDP to IDMS RTCP XR [RFC3611] defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application using the Session Description Protocol (SDP) [RFC4566]. SDP signaling is used to set up and maintain a synchronization group between Synchronization Clients (SCs). 1.4. This document and ETSI TISPAN ETSI TISPAN [TS 183 063] has specified architecture and protocol for IDMS using RTCP XR exchange and optional SDP signaling. This internet draft is an excerpt of the IDMS part of that specification. 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] and indicate requirement levels for compliant implementations. 3. Overview of IDMS operation This section provides a brief example of how the IDMS RTCP XR block is used. The section is tutorial in nature and does not contain any normative statements. Brandenburg Expires July 13, 2011 [Page 4] Internet-Draft RTCP for IDMS January 2011 Alice's . . . . . . . abc.com . . . . . . . . . . Bob's TV (SC) (MSAS) Laptop (SC) | | | | Media Session | | |<=====================>| | | Invite(URL,Sync-group ID) | |------------------------------------------------->| | | Media Session Set-up | | |<========================>| | | | | Call set-up | |<================================================>| | | | | RTP Packet | RTP Packet | |<----------------------|------------------------->| | RR + IDMS XR | | |---------------------->| RR + IDMS XR | | |<-------------------------| | IDMS XR | IDMS XR | |<----------------------|------------------------->| | | | Alice is watching TV in her living room. At some point she sees that a football game of Bob's favorite team is on. 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 to the media server. A VoIP connection to Alice's TV is also set up, so that Alice and Bob can talk while watching the program. 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 Receiver Reports (RR) 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 IDMS XR block to the MSAS function of the media server. Included in the XR blocks are timestamps on when both Alice and Bob have received a particular RTP packet. The MSAS function in the media server calculates a reference client from the received IDMS XR blocks (e.g. by selecting whichever client received the packet the latest as the reference client). It then sends the IDMS XR block of this reference client to both Alice and Bob. Brandenburg Expires July 13, 2011 [Page 5] Internet-Draft RTCP for IDMS January 2011 In this case Bob has the slowest connection 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 play- out rate temporally until it matches with the reference client play- out(and thus matches Bob's play-out). 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 reference client XR block, 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 then the most delay client, e.g. to account for delay variations, for new clients joining an existing synchronization group, etc. 4. Inter-destination media synchronization use cases Social TV is the combination of media content consumption by two or more users at different devices and locations and 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 the media play-out of the two or more users 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 other friend(s).Thus IDMS is required to provide play-out synchronization. Another example of Social TV is Shared Service Control, where two or more users experience some content-on-demand together, while sharing the trick-play controls (play, pause, fast forward, rewind) of the content on demand. Similar to the previous use case, without IDMS, differences in play- out speed and the effect of transit delay of trick-play control signals would desynchronize content play-out. 5. Architecture for inter-destination media synchronization The architecture for IDMS, which is based around a sync-maestro architecture [Boronat2009], is sketched below. The Synchronization Client (SC) and Media Synchronization Application Server (MSAS) entities are shown as additional functionality for the RTP receiver and sender respectively. Brandenburg Expires July 13, 2011 [Page 6] Internet-Draft RTCP for IDMS January 2011 It should be noted that a master/slave type of architecture is also supported by having one of the SC devices also act as an MSAS. In this case the MSAS functionality is thus embedded in an RTP receiver instead of an RTP sender. +-----------------------+ +-----------------------+ | | | | | Receiver | | Sender | | | SR+XR | | | +-----------------+ | <----- | +-----------------+ | | | | | | | | | | | Synchronization | | | | Media | | | | Client | | | | Synchronization | | | | (SC) | | | | Application | | | | | | | | Server | | | | | | RR+XR | | (MSAS) | | | | | | -----> | | | | | +-----------------+ | | +-----------------+ | | | | | +-----------------------+ +-----------------------+ 5.1. Media Synchronization Application Server (MSAS) An MSAS collects RTP packet arrival times and play-out times from one or more SC(s) in a synchronization group. The MSAS summarizes and distributes this information to the SCs in the synchronization group, e.g. by determining the SC with the most lagged play-out and using its reported RTP packet arrival time and play-out time as a summary. 5.2. Synchronization Client (SC) An SC reports RTP packet arrival times and play-out times of a media stream. It can receive summaries of such information, and use that to adjust its play-out buffer. 6. RTCP XR Block Type for IDMS This section specifies the RTCP XR Block Type for reporting inter- destination media synchronization information on an RTP media stream. Its definition is based on [RFC3611]. The RTCP XR is used to provide feedback information on receipt times and presentation times of RTP packets to e.g. a Sender [RFC3611], a Feedback Target [RFC5760] or a Third Party Monitor [RFC3611]. The block can also be used to indicate synchronization settings instructions to a receiver of the RTP media stream. Brandenburg Expires July 13, 2011 [Page 7] Internet-Draft RTCP for IDMS January 2011 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=XR=207 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 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 first 64 bits form the header of the RTCP XR, as defined in [RFC3611]. The SSRC of packet sender identifies the sender of the specific RTCP packet. The IDMS report block consists of 7 32-bit words, with the following fields: Block Type (BT): 8 bits. It identifies the block format. Its value SHALL be set to 12. Synchronization Packet Sender Type (SPST): 4 bits. This field indentifies the role of the packet sender for this specific eXtended Report. It can have the following values: 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 The packet sender is an MSAS. It uses this XR to report synchronization settings instructions. Timestamps relate to the input of a virtual SC, which acts as reference to which the SCs belonging to this session are synchronized. Brandenburg Expires July 13, 2011 [Page 8] Internet-Draft RTCP for IDMS January 2011 SPST=3-15 Reserved For future use. 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 and MUST be ignored by the receiver. Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the Packet Presented NTP timestamp contains a value, 0 if it is empty. If this flag is set to zero, then the Packet Presented NTP timestamp shall not be inspected. Block Length: 16 bits. This shall be set to 7, as this RTCP Block Type has a fixed length. Payload Type (PT): 7 bits. This field identifies the format of the media payload, according to [RFC3551]. The media payload is associated with an RTP timestamp clock rate. This clock rate provides the time base for the RTP timestamp counter. Reserved bits (Resrv): 25 bits. These bits are reserved for future use and shall be set to 0. 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 or an MSAS (SPST=1 or SPST=2), then the Media Stream Correlation Identifier maps on the SyncGroupId. SSRC: 32 bits. The SSRC of the media source shall be set to the value of the SSRC identifier carried in the RTP header [RFC3550] of the RTP packet to which the XR relates. Packet Received NTP timestamp: 64 bits. This NTP timestamp [RFC5905] is the arrival wall clock time of the first octet of the RTP packet to which the XR relates. For SPST=2 it relates to a virtual SC to which the other SCs in the synchronization group may synchronize. SCs SHALL be globally time-synchronized (e.g. by using NTP, GPS or other solutions). Packet Received RTP timestamp: 32 bits. This timestamp has the value of the RTP time stamp carried in the RTP header [RFC3550] of the RTP packet to which the XR relates. Packet Presented NTP timestamp: 32 bits. This timestamp reflects the NTP time when the data contained in the first octet of the associated RTP packet is presented to the user. It consists of the least significant 16 bits of the NTP seconds part and the most significant Brandenburg Expires July 13, 2011 [Page 9] Internet-Draft RTCP for IDMS January 2011 16 bits of the NTP fractional second part. If this field is empty, then it SHALL be set to 0 and the Packet Presented NTP timestamp flag (P) SHALL be set to 0. 7. SDP parameter for IDMS The SDP parameter sync-group is used to signal the use of the RTCP XR block for inter-destination media synchronization. It is also used to carry an identifier for the synchronization group to which clients belong or will belong. This SDP parameter extends rtcp-xr-attrib as follows, using Augmented Backus-Naur Form [RFC5234]. rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF ; Original definition from [RFC3611], section 5.1 xr-format =/ grp-sync ; Extending xr-format for inter-destination media synchronization grp-sync = "grp-sync" [",sync-group=" SyncGroupId] SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295 DIGIT = %x30-39 SyncGroupId is a 32-bit unsigned integer in network byte order and represented in decimal. SyncGroupId identifies a group of SCs for inter-destination media synchronization. It maps on the Media Stream Correlation Identifier of Annex W.1 [TS 183 063] for SPST=1 and SPST=2. The value SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 (2^32-1) is reserved for future use. The following is an example of the SDP attribute for inter- destination media synchronization. a=rtcp-xr:grp-sync,sync-group=42 8. Operational considerations On the use of NTP: To achieve inter-destination synchronization, the different receivers involved need synchronized clocks as a common timeline for synchronization. Depending on the synchronization accuracy required, different clock synchronization methods can be used. For social TV, synchronization accuracy should be achieved in order of hunderds of ms. In that case, correct use of NTP on receivers will in most situations achieve the required accuracy. As a guideline, to deal Brandenburg Expires July 13, 2011 [Page 10] Internet-Draft RTCP for IDMS January 2011 with clock drift of receivers, receivers should synchronize their clocks at the beginning of a synchronized session. Inter-destination synchronization may be used for other purposes, such as synchronization of multiple television outputs in a single physical location, or for the synchronization of different networked speakers throughout a house. Because of the stringent synchronization requirements for achieving good audio, a high accuracy will be needed. In this case, NTP usage may not be sufficient. Either a local NTP server could be setup, or some other more accurate clock synchronization mechanism could be used, such as using GPS time or the Precision Time Protocol [IEEE-1588]. On Echo Cancellation: In the case of social TV, if the two locations have a "side channel" audio conference so the watchers can talk about what they are watching, this may cause an audio problem that will not be solved by just applying inter-destination media synchronization. The audio output of the television of one watcher will pass through the audio conference, and arrive at the second watcher out of sync with the television output of that second watcher. Different methods can be used to deal with this effect, e.g. using directional microphones to prevent this or applying echo cancellors to filter out the unwanted audio signals. On reception vs presentation timing: A receiver can report on different timing events, i.e. on packet arrival times and on play-out times. A receiver SHALL report on arrival times and a receiver MAY report on play-out times. RTP packet arrival times are relatively easy to report on. Normally, the processing and play-out of the same media stream by different receivers will take roughly the same amount of time. By synchronizing on packet arrival times, you may loose some accuracy, 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 times, high accuracy can be achieved. But, if all receivers in a synchronization session have the ability to report on, and thus synchronize on, actual play-out times, this may be more accurate. It is up to applications and implementations of this RTCP extension whether to implement and use this. On control vs reporting: Note that the use of RTCP in this way, is still a form of reporting. This is e.g. comparable with inter-media synchronization (i.e. lip- sync) described in RFC 3550. The timestamp pairs in RTCP SR packets Brandenburg Expires July 13, 2011 [Page 11] Internet-Draft RTCP for IDMS January 2011 on different but related RTP streams can be used by a receiver to achieve inter-media synchronization, by supplying a relation to a single reference clock. A receiver is not obliged to present multiple stream in synchronization, it is the application that is enabled to do so. Inter-destination media synchronization is similar in this respect: it does not mandate the synchronization, but it does enable applications to do so. 9. Security Considerations The specified RTCP XR Block Type in this document is used to collect, summarize and distribute information on packet-receptionion times and play-out times of streaming media. The information may be used to orchestrate the media play-out at multiple devices. Errors in the information, either accidental or malicious, may lead to undesired behavior. For example, if one device erroneously reports a two-hour delayed play-out, then another device in the same synchronization group could decide to delay its play-out by two hours as well, in order to keep its play-out synchronized. A user would likely interpret this two hour delay as a malfunctioning service. Therefore, the application logic of both Synchronization Clients and Media Synchronization Application Servers should check for inconsistent information. Differences in play-out time exceeding configured limits (e.g. more than ten seconds) could be an indication of such inconsistent information. No new mechanisms are introduced in this document to ensure confidentiality. Encryption procedures, such as those being suggested for a Secure RTP (SRTP) at the time that this document was written, can be used when confidentiality is a concern to end hosts. 10. IANA Considerations New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, refer to [RFC3611]. [TS 183 063] assigns the block type value 12 in the RTCP XR Block Type Registry to "Inter-destination Media Synchronization Block". [TS 183 063] also registers the SDP [RFC4566] parameter "grp-sync" for the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 11. Conclusions This document gives information on the RTCP XR and the associated SDP parameter for inter-destination media synchronization. Brandenburg Expires July 13, 2011 [Page 12] Internet-Draft RTCP for IDMS January 2011 12. References 12.1. Normative References [RFC5234] Crocker, D. and Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and Casner S., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003 [RFC3611] Friedman, T. "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC4566] Handley, M., "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5576] Lennox, J., "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [RFC5905] Mills, D., "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC5968] Ott, J., Guidelines on Extending the RTP Control Protocol (RTCP), September 2010. [TS 183 063] ETSI TISPAN, "IMS-based IPTV stage 3 specification", TS 183 063 v3.4.1, June 2010. 12.2. Informative References [Boronat2009] Boronat, F., et al, "Multimedia group and inter-stream synchronization techniques: A comparative study", Elsevier Information Systems 34 (2009), pp. 108-131 [IEEE-1588] IEEE Standards Association, "1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", 2008 13. Acknowledgments The authors thank TNO and KPN for each partially funding the work behind this internet draft. Brandenburg Expires July 13, 2011 [Page 13] Internet-Draft RTCP for IDMS January 2011 Authors' Addresses Hans M. Stokking TNO Brassersplein 2, Delft, the Netherlands Phone: +31 88 86 67278 Email: hans.stokking@tno.nl M. Oskar van Deventer TNO Brassersplein 2, Delft, the Netherlands Phone: +31 88 86 67078 Email: oskar.vandeventer@tno.nl Omar A. Niamut TNO Brassersplein 2, Delft, the Netherlands Phone: +31 88 86 67218 Email: omar.niamut@tno.nl Fabian A. Walraven TNO Brassersplein 2, Delft, the Netherlands Phone: +31 88 86 67722 Email: fabian.walraven@tno.nl Ray van Brandenburg TNO Brassersplein 2, Delft, the Netherlands Phone: +31 88 86 63609 Email: ray.vanbrandenburg@tno.nl Ishan Vaishnavi CWI Science Park 123, Amsterdam, the Netherlands Phone: +31 20 592 4323 Email: i.vaishnavi@cwi.nl Brandenburg Expires July 13, 2011 [Page 14] Internet-Draft RTCP for IDMS January 2011 Fernando Boronat IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain Phone: +34 962 849 341 Email: fboronat@dcom.upv.es Mario Montagud IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain Phone: +34 962 849 341 Email: mamontor@posgrado.upv.es Brandenburg Expires July 13, 2011 [Page 15]