idnits 2.17.1 draft-stokking-avtcore-idms-for-iptv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7272], [RFC5760]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 101 has weird spacing: '...ronment and...' -- The document date (October 27, 2014) is 3462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Stokking 3 Internet-Draft O. van Deventer 4 R. van Brandenburg 5 Intended status: Informational TNO 6 Expires: April 30, 2015 F. Boronat 7 M. Montagud 8 Universitat Politecnica de 9 Valencia 10 October 27, 2014 12 Inter-Destination Media Synchronizaton for IPTV Environments 13 draft-stokking-avtcore-idms-for-iptv-00.txt 15 Abstract 17 [RFC7272] describes the use of RTCP for the purpose of Inter- 18 Destination Media Synchronization (IDMS) between Synchronization 19 Clients (SCs) and an Media Synchronization Application Server (MSAS). 20 This document extends that work for application in the area of IPTV. 21 First, RTCP can be used according to the single source multicast 22 (SSM) principles from [RFC5760] in the IPTV application area. This 23 document specifies the use of a feedback target for collecting and 24 possibly summarizing IDMS reports. For this, the document defines 2 25 new sub-report blocks for the use of IDMS according to the SSM 26 principles. Alternatively, the MSAS can be co-located with the 27 Feedback Target, for synchronizing small groups of receivers. 28 Secondly, in an IPTV environment, different viewers may receive the 29 same content, but in non-identical streams. The IDMS solution 30 presented in [RFC7272] will no longer work in such a case. This 31 document provides a solution for this. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 30, 2015. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. IDMS in an IPTV environment . . . . . . . . . . . . . . . 3 72 1.1.1. IDMS for Single Source Multicast . . . . . . . . . . . 3 73 1.1.2. IDMS for different streams providing the same 74 content . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. IDMS report aggregation in SSM session . . . . . . . . . . . . 5 76 2.1. IDMS Packet Received Sub-Report Block . . . . . . . . . . 5 77 2.2. IDMS Packet Presented Sub-Report Block . . . . . . . . . . 7 78 3. IDMS with separate synchronization server with unicast 79 synchronization settings . . . . . . . . . . . . . . . . . . . 7 80 4. IDMS in case of multiple RTP streams . . . . . . . . . . . . . 8 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 84 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 The Real-time Transport Protocol (RTP) provides a real-time transport 90 mechanism suitable for unicast and multicast communication between 91 multimedia applications. An important component of the RTP protocol 92 is the control channel, defined as the RTP Control Protocol (RTCP). 93 RTP and RTCP have been extended in numerous RFCs. Two such 94 extensions are the extensions for Single-Source Multicast (SSM) 95 Sessions with Unicast Feedback in [RFC5760] and the use of RTCP for 96 Inter-Destination Media Synchronization (IDMS) in [RFC7272]. 98 This Internet draft provides a number of extensions on the use of 99 RTCP for IDMS in an IPTV environment. The IPTV environment has a 100 number of characteristics that are currently not dealt with 101 [RFC7272]. The introduction discusses the IPTV environment and 102 identifies various gaps in the current IDMS solution. The next 103 sections discuss solution directions for dealing with these gaps. 104 The purpose of this Internet Draft is to build upon [RFC7272] so that 105 the IDMS solution can be applied in an IPTV specific environment. 107 1.1. IDMS in an IPTV environment 109 An IPTV environment has specific characteristics, which [RFC7272] 110 does not deal with properly. These characteristics are: 112 o Single Source Multicast (SSM, [RFC5760]) setting with a large 113 number of viewers. 115 o Different receivers may receive different versions of the same 116 content, i.e. they receive non-identical streams, e.g. different 117 unicast streams, different encoded streams, streams from different 118 media senders. 120 1.1.1. IDMS for Single Source Multicast 122 The first characteristic of IPTV is the large-scale Single Source 123 Multicast (SSM) setting. Regular linear television is offered using 124 SSM. Such SSM sessions have a large number of viewers, often in the 125 millions, which requires a highly scalable approach. Applying IDMS 126 to such an SSM session can be done in two ways: 128 1. Synchronize all receivers. In this case, [RFC7272] does not 129 offer the scalability to synchronize all viewers in such large-scale 130 sessions. In such a case each receiver contains a synchronization 131 client (SC) which communicates with the Media Synchronization 132 Application Server (MSAS).[RFC5760] offers a unicast feedback system 133 using feedback targets (FTs) to collect and possibly aggregate RTCP 134 reports of groups of receivers. IDMS can be performed using this 135 same feedback system, providing more scalability. Section 2 of this 136 document specifies how to accomplish this. 138 2. Synchronize independent groups of receivers, depending on the 139 application. Use cases for synchronization, such as social TV or 140 such as multiple receivers in a single physical location, require 141 only a limited number of receivers to be synchronized together. For 142 example, when millions of viewers watch the same television show, 143 only specific groups of users viewing the show together would have to 144 be synchronized, and only within their own group. [RFC5760] 145 describes a system that provides all receivers with the same 146 information. If only a limited subset of the receivers are 147 synchronized together, not all receivers need to receive the same 148 synchronization instructions. Section 3 of this document provides a 149 unicast way of sending synchronization instructions to receivers, 150 which requires the MSAS to be co-located with the Feedback Target. 152 The choice between options 1 and 2 depends on a number of factors. 153 If only a limited number of receivers use a service that requires 154 IDMS, it is inefficient to synchronize all viewers. Also, playout 155 timing differences between various receivers can be relatively large 156 due to e.g. variable propagation delays. If that is the case, and 157 every receiver is synchronizing to the slowest receiver, a lot of 158 buffering needs to be done. This is not efficient, and also 159 significantly increases channel changing delays. In these cases, it 160 makes sense to use option 2. If on the other hand many viewers use 161 synchronization sensitive services, and playout timing differences 162 are relatively small, it may make sense to synchronize all receivers 163 by using option 1. 165 1.1.2. IDMS for different streams providing the same content 167 Different viewers may watch the same content, but use a different 168 media stream in an IPTV environment. An example of this is when one 169 viewer receives an High Definition (HD) stream and another viewer 170 receives an Standard Definition (SD) stream. Another example is when 171 multiple receivers view the same video-on-demand, receiving this 172 using different unicast streams. Services such as social TV, where 173 different viewers remotely view media content together, require 174 synchronization of these different streams. The IDMS solution is 175 based on RTP timestamps. For different streams, these timestamps are 176 not aligned, i.e. there is no relation between the timestamps in one 177 stream and the timestamps in another stream, because of the different 178 random offset of the RTP timestamps, as well as potential clock skew. 179 Because of this, the MSAS cannot determine proper synchronization 180 instructions. 182 There are two possible solution directions for this problem. 184 The first is to have the media source output the different streams 185 with the same timing. The NTP timestamp in the RTP packets will then 186 be synchronous, i.e. IDMS can be based on this NTP timestamp analogue 187 to inter-stream synchronization (lip-sync). This does require the 188 MSAS to be informed on the RTP/NTP relationships of the various 189 streams. This information is available in the RTCP SRs of the 190 various streams. If the MSAS is part of the media source, this is 191 implicitly available. If this is not the case, the MSAS should 192 receive these SRs somehow. This document presents various options to 193 achieve this. 195 The other solution for this problem, is to have the media source 196 determine and signal the relationship between the various RTP 197 timestamps of the various streams. Again, if the MSAS is part of 198 with the media source, then this information is locally available. 199 If the MSAS is a separate entity, the media source can sent this 200 information to the MSAS. Section 4 of this document shows how that 201 is done. 203 2. IDMS report aggregation in SSM session 205 [RFC5760] describes how to use Feedback Targets (FTs) or the 206 Distribution Source (DS)for summarizing RTCP packets from receivers, 207 using the Receiver Summary Information (RSI) Packet. This section 208 describes two new sub-report blocks, to be used in those RSI packets. 209 One sub-report block is for summarizing reported RTP packet received 210 timestamps, the other is for summarizing reported RTP packet 211 presented timestamps. 213 A feedback target or distribution source MUST only summarize IDMS 214 information from SCs, if they belong to the same synchronization 215 group, i.e. when the reports from the receivers contain the same 216 Media Stream Correlation Identifier [RFC7272]. If at least one of 217 the receivers in a certain synchronization group reports on both 218 packet received timestamps and packet presented timestamps, a 219 feedback target or distribution source SHOULD also include packet 220 presented timestamps. If all receivers report on packet presented 221 timestamps, a feedback target or distribution source MUST include 222 packet presented timestamps. If a feedback target or distribution 223 source summarizes the packet received timestamps, it SHOULD also 224 summarize the packet presented timestamps. 226 2.1. IDMS Packet Received Sub-Report Block 228 To summarize the packet received timestamps in the IDMS information 229 from SCs, a feedback target or distribution source can use the 230 following sub-report block. The name of this sub-report block is 231 "IDMS Received", the long name is "IDMS Packet Received NTP 232 Timestamp". 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | SRBT=TBD | Length | NDB | MF | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Packet Received RTP timestamp | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | PT | Resrv | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Media Stream Correlation Identifier | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Packet Received NTP Timestamp - Minimum Distribution Value | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Packet Received NTP Timestamp - Maximum Distribution Value | 249 | | 250 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 251 | Distribution Buckets | 252 | ... | 253 | ... | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 1: IDMS Packet Received Sub-Report Block 258 Sub-Report Block Type (SRBT): 8 bits, TBD upon IANA registration. 260 Length: 8 bits, the length of the sub-report in 32-bit words, as 261 defined in RFC 5760. 263 Number of Distribution Buckets (NDB): 12 bits, as defined in RFC 264 5760, except for the calculation of the size of each bucket. Since 265 the header is longer than the sub-report blocks defined in RFC 5760, 266 the size of each bucket can be calculated using the formula ((length 267 * 4) - 32) * 8 / NDB number of bits. 269 Multiplicative Factor (MF): 4 bits, as defined in [RFC5760]. 271 Packet Received RTP Timestamp: 32 bits, as defined in [RFC7272]. 273 Payload Type (PT): 7 bits, as defined in [RFC7272]. 275 Reserved Bits (Resrv): 25 bits, as defined in [RFC7272]. 277 Media Stream Correlation Identifier: 32 bits, as defined in 278 [RFC7272]. 280 Packet Received NTP timestamp - Minimum Distribution Value: 64 bits, 281 as defined in [RFC7272]. 283 Packet Received NTP Timestamp - Maximum Distribution Value: 64 bits, 284 as defined in [RFC7272]. 286 Distribution Buckets: each bucket has ((Length * 4) - 28) * 8 / NDB 287 bits. 289 The whole sub-report block contains only a single packet received RTP 290 timestamp value. Since various receivers will normally report on 291 different packet received RTP timestamps, a feedback target MUST 292 recalculate all packet received NTP timestamps to match the single 293 packet received RTP timestamp. This will give an overview of the 294 packet received times of all receivers for that specific RTP 295 timestamp. This recalculation is necessary for all reported 296 timestamps: minimum, maximum and those in the distribution buckets. 298 2.2. IDMS Packet Presented Sub-Report Block 300 To summarize the packet presented timestamps in the IDMS information 301 from SCs, a feedback target or distribution source can use the 302 following sub-report block. The name of this sub-report block is 303 "IDMS Presented", the long name is "IDMS Packet Presented NTP 304 Timestamp". 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | SRBT=TBD | Length | NDB | MF | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Packet Received RTP timestamp | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | PT | Resrv | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Media Stream Correlation Identifier | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Packet Presented NTP Timestamp - Minimum Distribution Value | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Packet Presented NTP Timestamp - Maximum Distribution Value | 320 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 321 | Distribution Buckets | 322 | ... | 323 | ... | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 2: IDMS Packet Presented Sub-Report Block 328 Sub-Report Block Type (SRBT): 8 bits, TBD upon IANA registration. 330 Length: 8 bits, the length of the sub-report in 32-bit words, as 331 defined in RFC 5760. 333 Number of Distribution Buckets (NDB): 12 bits, as defined in RFC 334 5760, except for the calculation of the size of each bucket. Since 335 the header is longer than of the sub-report blocks defined in RFC 336 5760, the size of each bucket can be calculated using the formula 337 ((length * 4) - 28) * 8 / NDB number of bits. 339 Multiplicative Factor (MF): 4 bits, as defined in [RFC5760]. 341 Packet Received RTP Timestamp: 32 bits, as defined in [RFC7272]. 343 Payload Type (PT): 7 bits, as defined in [RFC7272]. 345 Reserved Bits (Resrv): 25 bits, as defined in [RFC7272]. 347 Media Stream Correlation Identifier: 32 bits, as defined in 348 [RFC7272]. 350 Packet Presented NTP timestamp - Minimum Distribution Value: 32 bits, 351 as defined in [RFC7272]. 353 Packet Presented NTP Timestamp - Maximum Distribution Value: 32 bits, 354 as defined in [RFC7272]. 356 Distribution Buckets: each bucket has ((Length * 4) - 28) * 8 / NDB 357 bits. 359 The whole sub-report block contains only a single packet received RTP 360 timestamp value. Since various receivers will report on different 361 packet presented NTP timestamps, a feedback target MUST recalculate 362 all packet presented NTP timestamps to match the single packet 363 received RTP timestamp. This is true for all reported timestamps: 364 minimum, maximum and those in the distribution buckets. 366 3. IDMS with separate MSAS with unicast synchronization settings 368 The second alternative for IDMS in a large-scale SSM context is to 369 synchronize small groups of receivers that need to be synchronized 370 with each other because of the service requirements. Different 371 groups may still receive the same RTP streams, but can be 372 synchronized independent of each other. In that case, each group 373 MUST receive its own synchronization settings instructions in the 374 form of IDMS Settings Packets as defined in [RFC7272]. Normally the 375 Receiver Reports (RRs) or the Received Summary Information (RSI) is 376 sent to all receivers. But, since different groups of receivers may 377 need different synchronization settings instructions, these 378 instructions cannot be multicast. As it happens, multicasting all 379 instructions would lead to a situation where all receivers would 380 receive a multitude of different settings instructions. They would 381 have to find their own instructions based on the MSCI of their group, 382 which is possible. But, with a large number of groups, this would be 383 highly inefficient. This is why a unicast method is taken here. 385 To unicast the instructions to the various SCs, the MSAS needs to 386 directly receive the IDMS reports from the various SCs. This means 387 the MSAS MUST be co-located with the feedback target. When supplying 388 SCs with the unicast address to which they should sent their reports, 389 different SCs in the same synchronization group MUST be allocated the 390 same feedback target. Also, because the synchronization information 391 is no longer relevant upstream of the MSAS, the feedback target 392 SHOULD terminate these RTCP blocks and not forward them or summarize 393 them. 395 How the receivers receive the unicast address of the feedback target 396 is out of scope of this draft. [RFC5760] only defines pre- 397 configuration for this. Alternatively, the RTCP-attribute as 398 specified in [RFC3605] can be used on the session level to provide 399 receivers of a shared session with the unicast address of the MSAS, 400 similar to how this is done in [TS183063]. 402 Synchronization settings instructions MUST be sent by the MSAS to the 403 source IP addresses of the received synchronization information, 404 using the same destination port as the received synchronization 405 information. 407 4. IDMS in case of multiple RTP streams 409 IDMS is based on various receivers reporting on the packet received 410 times or packet presentation times. This document describes 411 situations in which the MSAS is not part of the media source. If all 412 receivers receive the exact same RTP streams, e.g. in case of 413 multiple receivers of a single multicast streams, this will work 414 fine. The MSAS can relate the various received IDMS information. 415 Even if different receivers report on different RTP timestamps, the 416 MSAS can calculate the timing differences between clients by 417 extrapolation using the RTP clock frequency derived from the reported 418 payload type. 420 However, when the MSAS is not co-located with the media source and 421 the receivers receive the same content in different RTP streams, an 422 MSAS cannot perform the necessary calculations for achieving 423 synchronization. To perform these calculations, there has to exist 424 some common timeline in the reports by the various receivers. To 425 determine a common timeline, the MSAS needs some kind of information 426 correlating the RTP timestamps in the various streams. This section 427 provides two alternatives for this. 429 The first alternative is to use the RTCP Sender Reports that belong 430 to the various RTP streams. In these SRs, the RTP timestamps are 431 linked to the employed wallclock time. This is normally used for 432 intra- and inter-media synchronization. The media sources need to 433 ensure that the same part of the content in different streams 434 corresponds to the same wallclock time (NTP timestamp in the SR). 435 This way the SRs of the various RTP streams can be used to establish 436 a common timeline between those RTP streams. The easiest way to send 437 the SR to the MSAS is by having the receiver append it to its report 438 blocks. Another option is to have the MSAS act as a third party 439 monitor, as described in [RFC3550]. 441 The second alternative is that the media source sends information on 442 the correlation of the various timestamps to the MSAS. This can be 443 done by using the IDMS report block from [RFC7272], using the 444 Synchronization Packet Sender Types (SPST) 3 and 4, as specified in 445 [TS183063] Annex W, and registered with IANA in the IDMS XR Block 446 SPST Registry. These SPSTs are normally used for synchronization in 447 case a transcoder is changing the media stream such that the RTP 448 timestamps also change. In this case, synchronization would be 449 impossible between users receiving the original stream and users 450 receiving the transcoded version. A transcoder can link an incoming 451 RTP timestamps (SPST=3) to an outgoing RTP timestamp (SPST=4), and 452 thus enable correlating the timelines. These SPSTs 3 and 4 can also 453 be used if one source sends out two version of the same content, 454 linking the timestamps of one stream to those of the other stream. 456 5. IANA Considerations 458 This document defines two new RSI Sub-Report Blocks, the "IDMS 459 Received" and the "IDMS Presented". Based on the specification in 460 section 2, these two sub-report blocks are added to the IANA registry 461 for Sub-Report Block Type (SRBT) Values for the RSI Packet, as part 462 of the RTP parameters registration. 464 6. Security Considerations 466 The content of this ID does not pose any security risks above or 467 beyond those mentioned in [RFC5760] and [RFC7272]. 469 7. Acknowledgements 471 8. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 477 Jacobson, "RTP: A Transport Protocol for Real-Time 478 Applications", STD 64, RFC 3550, July 2003. 480 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 481 in Session Description Protocol (SDP)", RFC 3605, October 482 2003. 484 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 485 Protocol (RTCP) Extensions for Single-Source Multicast 486 Sessions with Unicast Feedback", RFC 5760, February 2010. 488 [RFC7272] Brandenburg, R. van, Stokking, H., Deventer, O. van, 489 Boronat, F., Montagud, M., Gross, K., "Inter-Destination 490 Media Synchronization (IDMS) Using the RTP Control 491 Protocol (RTCP)", RFC 7272, June 2014. 493 [TS183063] ETSI, "Telecommunications and Internet converged Services 494 and Protocols for Advanced Networking (TISPAN); IMS-based 495 IPTV stage 3 specification", TS 183 063 v3.6.1, August 496 2014. 498 Authors' Addresses 500 Hans Stokking 501 TNO 502 Brassersplein 2 503 Delft, 2292CH 504 The Netherlands 506 Phone: 0031-(0)88-86 67 278 507 Fax: 508 Email: hans.stokking@tno.nl 509 URI: 511 Oskar van Deventer 512 TNO 513 Brassersplein 2 514 Delft, 2292CH 515 The Netherlands 517 Phone: 0031-(0)88-86 67 078 518 Fax: 519 Email: oskar.vandeventer@tno.nl 520 URI: 522 Ray van Brandenburg 523 TNO 524 Brassersplein 2 525 Delft, 2292CH 526 The Netherlands 528 Phone: 0031-(0)88-86 63 609 529 Fax: 530 Email: ray.vanbrandenburg@tno.nl 531 URI: 533 Fernando Boronat 534 Universitat Politecnica de Valencia 535 IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia 536 (UPV), C/ Paraninfo, 1, Grao de Gandia Valencia, 46730 537 Spain 539 Phone: +34 962 849 341 540 Fax: 542 Email: fboronat@dcom.upv.es 543 URI: 545 Mario Montagud 546 Universitat Politecnica de Valencia 547 IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia 548 (UPV), C/ Paraninfo, 1, Grao de Gandia Valencia, 46730 549 Spain 551 Phone: +34 962 849 341 552 Fax: 553 Email: mamontor@posgrado.upv.es 554 URI: