idnits 2.17.1 draft-ietf-avtcore-idms-04.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 71 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 22, 2012) is 4357 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-williams-avtcore-clksrc-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. 'TS183063' -- No information found for draft-gross-leap-seconds - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCore R. van Brandenburg 3 Internet-Draft H. Stokking 4 Intended status: Standards Track O. van Deventer 5 Expires: November 23, 2012 TNO 6 F. Boronat 7 M. Montagud 8 Universitat Politecnica de 9 Valencia 10 K. Gross 11 AVA Networks 12 May 22, 2012 14 RTCP for inter-destination media synchronization 15 draft-ietf-avtcore-idms-04 17 Abstract 19 This document gives information on an RTCP Packet Type and RTCP XR 20 Block Type including associated SDP parameters for Inter-Destination 21 Media Synchronization (IDMS). The RTCP XR Block Type, registered 22 with IANA based on an ETSI specification, is used to collect media 23 playout information from participants in a group playing-out 24 (watching, listening, etc.) a specific RTP media stream. The RTCP 25 packet type specified by this document is used to distribute a common 26 target playout point to which all the distributed receivers, sharing 27 a media experience, can synchronize. 29 Typical use cases in which IDMS is usefull are social TV, shared 30 service control (i.e. applications where two or more geographically 31 separated users are watching a media stream together), distance 32 learning, networked video walls, networked loudspeakers, etc. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 23, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Inter-Destination Media Synchronization . . . . . . . . . 4 69 1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4 70 1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 5 71 1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . 5 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 5 74 4. Inter-Destination Media Synchronization use cases . . . . . . 7 75 5. Architecture for Inter-Destination Media Synchronization . . . 8 76 5.1. Media Synchronization Application Server (MSAS) . . . . . 8 77 5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 9 78 5.3. Communication between MSAS and SCs . . . . . . . . . . . . 9 79 6. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9 80 7. RTCP Packet Type for IDMS (IDMS report) . . . . . . . . . . . 11 81 8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13 82 9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 14 83 10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 15 84 11. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 15 85 12. On the use of presentation timestamps . . . . . . . . . . . . 16 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 16. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 92 17.2. Informative References . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 1.1. Inter-Destination Media Synchronization 99 Inter-Destination Media Synchronization (IDMS) refers to the playout 100 of media streams at two or more geographically distributed locations 101 in a time synchronized manner. It can be applied to both unicast and 102 multicast media streams and can be applied to any type and/or 103 combination of streaming media, such as audio, video and text 104 (subtitles).[Ishibashi2006] and [Boronat2009] provide an overview of 105 technologies and algorithms for IDMS. 107 IDMS requires the exchange of information on media receipt and 108 playout times among participants in an IDMS session. It may also 109 require signaling for the initiation and maintenance of IDMS sessions 110 and groups of receivers. 112 The presented RTCP specification for IDMS is independent of the used 113 synchronization algorithm, which is out-of-scope of this document. 115 1.2. Applicability of RTCP to IDMS 117 Currently, a large share of real-time applications make use of RTP 118 and RTCP [RFC3550]. RTP provides end-to-end network transport 119 functions suitable for applications requiring real-time data 120 transport, such as audio, video or data, over multicast or unicast 121 network services. The timestamps, sequence numbers, and payload 122 (content) type identification mechanisms provided by RTP packets are 123 very useful for reconstructing the original media timing, and for 124 reordering and detecting packet loss at the client side. 126 The data transport is augmented by a control protocol (RTCP) to allow 127 monitoring of the data delivery in a manner that is scalable to large 128 multicast networks, and to provide minimal control and identification 129 functionality. RTP receivers and senders provide reception quality 130 feedback by sending out RTCP Receiver Report (RR) and Sender Report 131 (SR) packets [RFC3550], respectively, which may be augmented by 132 eXtended Reports (XR) [RFC3611]. Both RTP and RTCP are intended to 133 be tailored through modifications in order to include profile- 134 specific information required by particular applications, and the 135 guidelines on doing so are specified in [RFC5868]. 137 IDMS involves the collection, summarizing and distribution of RTP 138 packet arrival and playout times. As information on RTP packet 139 arrival times and playout times can be considered reception quality 140 feedback information, RTCP is well suited for carrying out IDMS, 141 which may facilitate the implementation and deployment in typical 142 multimedia applications. 144 1.3. Applicability of SDP to IDMS 146 RTCP XR [RFC3611] defines the Extended Report (XR) packet type for 147 the RTP Control Protocol (RTCP), and defines how the use of XR 148 packets can be signaled by an application using the Session 149 Description Protocol (SDP) [RFC4566]. 151 SDP signaling is used to set up and maintain a synchronization group 152 between Synchronization Clients (SCs). This document describes two 153 SDP parameters for doing this, one for the RTCP XR block type and one 154 for the new RTCP packet type. 156 1.4. This document and ETSI TISPAN 158 ETSI TISPAN [TS183063] has specified architecture and protocol for 159 IDMS using RTCP XR exchange and SDP signaling. For more information 160 on how this document relates to [TS183063], see Section 11. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119] and 167 indicate requirement levels for compliant implementations. 169 3. Overview of IDMS operation 171 This section provides a brief example of how the RTCP functionality 172 is used for achieving IDMS. The section is tutorial in nature and 173 does not contain any normative statements. 175 Alice's . . . . . . .tv:abc.com . . . . . . . . . Bob's 176 TV (Sync Client) (Sync Server) Laptop (Sync Client) 177 | | | 178 | Media Session | | 179 |<=====================>| | 180 | Invite(URL,Sync-group ID) | 181 |------------------------------------------------->| 182 | | Media Session Set-up | 183 | |<========================>| 184 | | | 185 | Call set-up | 186 |<================================================>| 187 | | | 188 | RTP Packet | RTP Packet | 189 |<----------------------|------------------------->| 190 | RR + IDMS XR | | 191 |---------------------->| RR + IDMS XR | 192 | |<-------------------------| 193 | RTCP IDMS packet | RTCP IDMS packet | 194 |<----------------------|------------------------->| 195 | | | 197 Alice is watching TV in her living room. At some point she sees that 198 a football game of Bob's favorite team is on. She sends him an 199 invite to watch the program together. Embedded in the invitation is 200 the link to the media server and a unique sync-group identifier. 202 Bob, who is also at home, receives the invite on his laptop. He 203 accepts Alice's invitation and the RTP client on his laptop sets up a 204 session to the media server. A VoIP connection to Alice's TV is also 205 set up, so that Alice and Bob can talk while watching the game 206 together. 208 As is common with RTP, both the RTP client in Alice's TV as well as 209 the one in Bob's laptop send periodic RTCP Receiver Reports (RR) to 210 the media server. However, in order to make sure Alice and Bob see 211 the events in the football game at (approximately) the same time, 212 their clients also periodically send an IDMS XR block to the sync 213 server function of the media server. Included in the XR blocks are 214 timestamps on when both Alice and Bob received (or played out) a 215 particular RTP packet. 217 The sync server function in the media server calculates a reference 218 client from the received IDMS XR blocks (e.g. by selecting whichever 219 client received the packet the latest as the reference client). It 220 then sends an RTCP IDMS packet containing the playout information of 221 this reference client to the sync clients of both Alice and Bob. 223 In this case Bob has the slowest connection and the reference client 224 therefore includes a delay similar to the one experienced by Bob. 225 Upon reception of this information, Alice's RTP client can choose 226 what to do with this information. In this case it decreases its 227 playout rate temporarily until it matches with the reference client 228 playout (and thus matches Bob's playout). Another option for Alice's 229 TV would be to simply pause playback until it catches up. The exact 230 implementation of the synchronization algorithm is up to the client. 232 Upon reception of the reference client RTCP IDMS packet, Bob's client 233 does not have to do anything since it is already synchronized to the 234 reference client (since it is based on Bob's delay). Note that other 235 synchronization algorithms may introduce even more delay than the one 236 experienced by the most delayed client, e.g. to account for delay 237 variations, for new clients joining an existing synchronization 238 group, etc. 240 4. Inter-Destination Media Synchronization use cases 242 There are a large number of use cases imaginable in which IDMS might 243 be useful. This section will highlight some of them. It should be 244 noted that this section is in no way meant to be exhaustive. 246 A first usage scenario for IDMS is Social TV. Social TV is the 247 combination of media content consumption by two or more users at 248 different devices and locations and real-time communication between 249 those users. An example of Social TV, is when two or more users are 250 watching the same television broadcast at different devices and 251 locations, while communicating with each other using text, audio 252 and/or video. A skew in their media playout processes can have 253 adverse effects on their experience. A well-known use case here is 254 one friend experiencing a goal in a football match well before or 255 after other friend(s). 257 Another potential use case for IDMS is a networked video wall. A 258 video wall consists of multiple computer monitors, video projectors, 259 or television sets tiled together contiguously or overlapped in order 260 to form one large screen. Each of the screens reproduces a portion 261 of the larger picture. In some implementations, each screen may be 262 individually connected to the network and receive its portion of the 263 overall image from a network-connected video server or video scaler. 264 Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or 265 potentially faster. If the refresh is not synchronized, the effect 266 of multiple screens acting as one is broken. 268 A third usage scenario is that of the networked loudspeakers, in 269 which two or more speakers are connected to the network individually. 271 Such situations can for example be found in large conference rooms, 272 legislative chambers, classrooms (especially those supporting 273 distance learning) and other large-scale environments such as 274 stadiums. Since humans are more susceptible to differences in audio 275 delay, this use case needs even more accuracy than the video wall use 276 case. Depending on the exact application, the need for accuracy can 277 then be in the range of microseconds. 279 5. Architecture for Inter-Destination Media Synchronization 281 The architecture for IDMS, which is based on a sync-maestro 282 architecture [Boronat2009], is sketched below. The Synchronization 283 Client (SC) and Media Synchronization Application Server (MSAS) 284 entities are shown as additional functionality for the RTP receiver 285 and sender respectively. 287 It should be noted that a master/slave type of architecture is also 288 supported by having one of the SC devices also act as an MSAS. In 289 this case the MSAS functionality is thus embedded in an RTP receiver 290 instead of an RTP sender. 292 +-----------------------+ +-----------------------+ 293 | | SR + | | 294 | RTP Receiver | RTCP | RTP Sender | 295 | | IDMS | | 296 | +-----------------+ | <----- | +-----------------+ | 297 | | | | | | | | 298 | | Synchronization | | | | Media | | 299 | | Client | | | | Synchronization | | 300 | | (SC) | | | | Application | | 301 | | | | | | Server | | 302 | | | | RR+XR | | (MSAS) | | 303 | | | | -----> | | | | 304 | +-----------------+ | | +-----------------+ | 305 | | | | 306 +-----------------------+ +-----------------------+ 308 5.1. Media Synchronization Application Server (MSAS) 310 An MSAS collects RTP packet arrival times and playout times from one 311 or more SC(s) in a synchronization group. The MSAS summarizes and 312 distributes this information to the SCs in the synchronization group 313 as synchronization settings, e.g. by determining the SC with the most 314 lagged playout and using its reported RTP packet arrival time and 315 playout time as a summary. 317 5.2. Synchronization Client (SC) 319 An SC reports on RTP packet arrival times and playout times of a 320 media stream. It can receive summaries of such information, and use 321 that to adjust its playout buffer. 323 5.3. Communication between MSAS and SCs 325 Two different message types are used for the communication between 326 MSAS and SCs. For the SC->MSAS message containing the play-out 327 information of a particular client, an RTCP XR Block Type is used 328 (see Section 6). For the MSAS->SC message containing the 329 synchronization settings instructions, a new RTCP Packet Type is 330 defined (see Section 7). 332 6. RTCP XR Block Type for IDMS 334 This section describes the RTCP XR Block Type for reporting IDMS 335 information on an RTP media stream. Its definition is based on 336 [RFC3611]. The RTCP XR is used to provide feedback information on 337 receipt times and presentation times of RTP packets to e.g. a Sender 338 [RFC3611], a Feedback Target [RFC5760] or a Third Party Monitor 339 [RFC3611]. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 |V=2|P| Resrv | PT=XR=207 | length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | SSRC of packet sender | 347 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 348 | BT=12 | SPST |Resrv|P| block length=7 | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | PT | Resrv | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Media Stream Correlation Identifier | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | SSRC of media source | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Packet Received NTP timestamp, most significant word | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Packet Received NTP timestamp, least significant word | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Packet Received RTP timestamp | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Packet Presented NTP timestamp | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 The first 64 bits form the header of the RTCP XR, as defined in 366 [RFC3611]. The SSRC of packet sender identifies the sender of the 367 specific RTCP packet. 369 The IDMS report block consists of 8 32-bit words, with the following 370 fields: 372 Block Type (BT): 8 bits. It identifies the block format. Its value 373 SHALL be set to 12. 375 Synchronization Packet Sender Type (SPST): 4 bits. This field 376 identifies the role of the packet sender for this specific eXtended 377 Report. It can have the following values: 379 SPST=0 Reserved For future use. 381 SPST=1 The packet sender is an SC. It uses this XR to report 382 synchronization status information. Timestamps relate to the SC 383 input. 385 SPST=2 This setting is reserved in order to preserve compatibility 386 with ETSI TISPAN [TS183063]. See Section 11 for more information. 388 SPST=3-15 Reserved For future use. 390 Reserved bits (Resrv): 3 bits. These bits are reserved for future 391 definition. In the absence of such a definition, the bits in this 392 field MUST be set to zero and MUST be ignored by the receiver. 394 Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the 395 Packet Presented NTP timestamp field contains a value, 0 if it is 396 empty. If this flag is set to zero, then the Packet Presented NTP 397 timestamp SHALL be ignored. 399 Block Length: 16 bits. This field indicates the length of the block 400 in 32 bit words minus one and SHALL be set to 7, as this RTCP Block 401 Type has a fixed length. 403 Payload Type (PT): 7 bits. This field identifies the format of the 404 media payload, according to [RFC3551]. The media payload is 405 associated with an RTP timestamp clock rate. This clock rate 406 provides the time base for the RTP timestamp counter. 408 Reserved bits (Resrv): 25 bits. These bits are reserved for future 409 use and SHALL be set to 0. 411 Media Stream Correlation Identifier: 32 bits. This identifier is 412 used to correlate synchronized media streams. The value 0 (all bits 413 are set "0") indicates that this field is empty. The value 2^32-1 414 (all bits are set "1") is reserved for future use. If the RTCP 415 Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then the Media 416 Stream Correlation Identifier maps on the Synchronization Group 417 Identifier (SyncGroupId) to which the report applies. 419 SSRC: 32 bits. The SSRC of the media source SHALL be set to the 420 value of the SSRC identifier carried in the RTP header [RFC3550] of 421 the RTP packet to which the XR relates. 423 Packet Received NTP timestamp: 64 bits. This timestamp reflects the 424 wall clock time at the moment of arrival of the first octet of the 425 RTP packet to which the XR relates. It is formatted based on the NTP 426 timestamp format as specified in [RFC5905]. See Section 8 for more 427 information on how this field is used. 429 Packet Received RTP timestamp: 32 bits. This timestamp has the value 430 of the RTP timestamp carried in the RTP header [RFC3550] of the RTP 431 packet to which the XR relates. Several consecutive RTP packets will 432 have equal timestamps if they are (logically) generated at once, 433 e.g., belong to the same video frame. It may well be the case that 434 one receiver reports on the first RTP packet having a certain RTP 435 timestamp and a second receiver reports on the last RTP packet having 436 that same RTP timestamp. This would lead to an error in the 437 synchronization algorithm due to the faulty interpretation of 438 considering both reports to be on the same RTP packet. To solve 439 this, an SC SHOULD report on RTP packets in which a certain RTP 440 timestamp shows up for the first time. 442 Packet Presented NTP timestamp: 32 bits. This timestamp reflects the 443 wall clock time at the moment the data contained in the first octet 444 of the associated RTP packet is presented to the user. It is based 445 on the time format used by NTP and consists of the least significant 446 16 bits of the NTP seconds part and the most significant 16 bits of 447 the NTP fractional second part. If this field is empty, then it 448 SHALL be set to 0 and the Packet Presented NTP timestamp flag (P) 449 SHALL be set to 0. Presented here means the moment the data is 450 played out to the user of the system, i.e. sound played out through 451 speakers, video images being displayed on some display, etc. The 452 accuracy resulting from the synchronization algorithm will only be as 453 good as the accuracy with which the receivers can determine the delay 454 between receiving packets and presenting them to the end-user. 456 7. RTCP Packet Type for IDMS (IDMS report) 458 This section specifies the RTCP Packet Type for indicating 459 synchronization settings instructions to the receivers of the RTP 460 media stream. Its definition is based on [RFC3550]. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 |V=2|P| Resrv | PT=TBD | length | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | SSRC of packet sender | 468 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 469 | SSRC of media source | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Media Stream Correlation Identifier | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Packet Received NTP timestamp, most significant word | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Packet Received NTP timestamp, least significant word | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Packet Received RTP timestamp | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Packet Presented NTP timestamp, most significant word | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Packet Presented NTP timestamp, least significant word | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 The first 64 bits form the header of the RTCP Packet Type, as defined 485 in [RFC3550]. The SSRC of packet sender identifies the sender of the 486 specific RTCP packet. 488 The RTCP IDMS packet consists of 7 32-bit words, with the following 489 fields: 491 SSRC: 32 bits. The SSRC of the media source SHALL be set to the 492 value of the SSRC identifier carried in the RTP header [RFC3550] of 493 the RTP packet to which the RTCP IDMS packet relates. 495 Media Stream Correlation Identifier: 32 bits. This identifier is 496 used to correlate synchronized media streams. The value 0 (all bits 497 are set "0") indicates that this field is empty. The value 2^32-1 498 (all bits are set "1") is reserved for future use. The Media Stream 499 Correlation Identifier maps on the SyncGroupId of the group to which 500 this packet is sent. 502 Packet Received NTP timestamp: 64 bits. This timestamp reflects the 503 wall clock time at the reference client at the moment it received the 504 first octet of the RTP packet to which this packet relates. It can 505 be used by the synchronization algorithm on the receiving SC to 506 adjust its playout timing in order to achieve synchronization, e.g. 507 to set the required playout delay. The timestamp is formatted based 508 on the NTP timestamp format as specified in [RFC5905]. See Section 8 509 for more information on how this field is used. 511 Packet Received RTP timestamp: 32 bits. This timestamp has the value 512 of the RTP timestamp carried in the RTP header [RFC3550] of the RTP 513 packet to which the XR relates. This SHOULD relate to the first 514 arriving RTP packet containing this particular RTP timestamp, in case 515 multiple RTP packets contain the same RTP timestamp. 517 Packet Presented NTP timestamp: 64 bits. This timestamp reflects the 518 wall clock time at the reference client at the moment it presented 519 the data contained in the first octet of the associated RTP packet to 520 the user. The timestamp is formatted based on the NTP timestamp 521 format as specified in [RFC5905]. If this field is empty, then it 522 SHALL be set to 0. This field MAY be left empty if none or only one 523 of the receivers reported on presentation timestamps. Presented here 524 means the moment the data is played out to the user of the system. 526 In some use cases (e.g. phased array transducers), the level of 527 control an MSAS might need to have over the exact moment of playout 528 is so precise that a 32bit Presented Timestamp will not suffice. For 529 this reason, this RTCP Packet Type for IDMS includes a 64bit 530 Presented Timestamp field. Since an MSAS will in practice always add 531 some extra delay to the delay reported by the most lagged receiver 532 (to account for packet jitter), it suffices for the IDMS XR Block 533 Type with which the SCs report on their playout to have a 32bit 534 Presented Timestamp field. 536 8. Timing and NTP Considerations 538 To achieve IDMS, the different receivers involved need synchronized 539 clocks as a common timeline for synchronization. Depending on the 540 synchronization accuracy required, different clock synchronization 541 methods can be used. For social TV, synchronization accuracy should 542 be achieved on the order of hundreds of milliseconds. In that case, 543 correct use of NTP on receivers will in most situations achieve the 544 required accuracy. As a guideline, to deal with clock drift of 545 receivers, receivers should synchronize their clocks at the beginning 546 of a synchronized session. In case of high required accuracy, the 547 synchronized clocks of different receivers should not drift beyond 548 the accuracy required for the synchronization mechanism. In 549 practice, this can mean that receivers need to synchronize their 550 clocks repeatedly during a synchronization session. 552 Because of the stringent synchronization requirements for achieving 553 good audio in some use cases, a high accuracy will be needed. In 554 this case, use of the global NTP system may not be sufficient. For 555 improved accuracy, a local NTP server could be set up, or some other 556 more accurate clock synchronization mechanism can be used, such as 557 GPS time or the Precision Time Protocol [IEEE-1588]. 559 [I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters 560 for signaling the clock synchronization source or sources available 561 to and used by the individual receivers. Using these paramenters, an 562 SC can indicate which synchronization source is being used at the 563 moment, the last time the SC synchronized with this source and the 564 synchronization frequency. An SC can also indicate any other 565 synchronization sources available to it. This allows multiple SCs in 566 an IDMS session to use the same or a similar clock source for their 567 session. 569 Applications performing IDMS may or may not be able to choose a 570 synchronization method for the system clock, because this may be a 571 system-wide setting which the application cannot change. How 572 applications deal with this is up to the implementation. The 573 application might control the system clock, or it might use a 574 separate application clock or even a separate IDMS session clock. It 575 might also report on the system clock and the synchronization method 576 used, without being able to change it. 578 [I-D.draft-gross-leap-second] presents some guidelines on how RTP 579 senders and receivers should deal with leap seconds. When relying on 580 NTP for clock synchronization, IDMS is particularly sensitive to leap 581 second induced timing discrepancies. It is therefore recommended to 582 take the guideline specified in [I-D.draft-gross-leap-second] into 583 account when implementing IDMS. 585 9. SDP Parameter for RTCP XR IDMS Block Type 587 The SDP parameter sync-group is used to signal the use of the RTCP XR 588 block for IDMS. It is also used to carry an identifier of the 589 synchronization group to which clients belong or will belong. This 590 SDP parameter extends rtcp-xr-attrib as follows, using Augmented 591 Backus-Naur Form [RFC5234]. 593 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 594 ; Original definition from [RFC3611], section 5.1 596 xr-format =/ grp-sync ; Extending xr-format for Inter-Destination 597 Media Synchronization 599 grp-sync = "grp-sync" [",sync-group=" SyncGroupId] 601 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295 602 DIGIT = %x30-39 604 SyncGroupId is a 32-bit unsigned integer represented in decimal. 605 SyncGroupId identifies a group of SCs for IDMS. It maps on the Media 606 Stream Correlation Identifier as described in Section 6 and 607 Section 7. The value SyncGroupId=0 represents an empty SyncGroupId. 608 The value 4294967295 (2^32-1) is reserved for future use. 610 The following is an example of the SDP attribute for IDMS 612 a=rtcp-xr:grp-sync,sync-group=42 614 10. SDP Parameter for RTCP IDMS Packet Type 616 The SDP parameter rtcp-idms is used to signal the use of the RTCP 617 IDMS Packet Type for IDMS. It is also used to carry an identifier of 618 the synchronization group to which clients belong or will belong. 619 The SDP parameter is used as a media-level attribute during session 620 setup. This SDP parameter is defined as follows, using Augmented 621 Backus-Naur Form [RFC5234]. 623 rtcp-idms = "a=" "rtcp-idms" ":" [sync-grp] CRLF 625 sync-grp = "sync-group=" SyncGroupId 627 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295 629 DIGIT = %x30-39 631 SyncGroupId is a 32-bit unsigned integer and represented in decimal. 632 SyncGroupId identifies a group of SCs for IDMS. The value 633 SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 634 (2^32-1) is reserved for future use. 636 The following is an example of the SDP attribute for IDMS. 638 a=rtcp-idms:sync-group=42 640 11. Compatibility with ETSI TISPAN 642 As described in Section 1.4, ETSI TISPAN has also described a 643 mechanism for IDMS in [TS183063]. One of the main differences 644 between the TISPAN document and this document is the fact that the 645 TISPAN solution uses an RTPC XR block for both the SC->MSAS message 646 and the MSAS->SC message (by selecting different SPST-types), while 647 this document specifies a new RTCP Packet Type for the MSAS->SC 648 message. The message from MSAS to SC is not in any way a report on 649 how a receiver sees a session, and therefore a separate RTCP packet 650 type is more appropriate than the XR block solution chosen in ETSI 651 TISPAN. 653 In order to maintain backward-compatibility, the RTCP XR block used 654 for SC->MSAS signaling specified in this document is fully compatible 655 with the TISPAN defined XR block. 657 For the MSAS->SC signaling, it is recommended to use the RTCP IDMS 658 Packet Type defined in this document. The TISPAN XR block with 659 SPST=2 MAY be used for purposes of compatibility with the TISPAN 660 solution, but MUST NOT be used if all nodes involved support the new 661 RTCP IDMS Packet Type. 663 The above means that the IANA registry contains two SDP parameters 664 for the MSAS->SC signaling; one for the ETSI TISPAN solution and one 665 for the IETF solution. This also means that if all elements in the 666 SDP negotiation support the IETF solution they SHOULD use the new 667 RTCP IDMS Packet Type. 669 12. On the use of presentation timestamps 671 A receiver can report on different timing events, i.e. on packet 672 arrival times and on playout times. A receiver SHALL report on 673 arrival times and a receiver MAY report on playout times. RTP packet 674 arrival times are relatively easy to report on. Normally, the 675 processing and playout of the same media stream by different 676 receivers will take roughly the same amount of time. It can suffice 677 for many applications, such as social TV, to synchronize on packet 678 arrival times. Also, if the receivers are in some way controlled, 679 e.g. having the same buffer settings and decoding times, high 680 accuracy can be achieved. However, if all receivers in a 681 synchronization session have the ability to report on, and thus 682 synchronize on packet presented times, this may be more accurate. It 683 is up to applications and implementations of this RTCP extension 684 whether to implement and use this. 686 13. Security Considerations 688 The specified RTCP XR Block Type in this document is used to collect, 689 summarize and distribute information on packet reception- and 690 playout-times of streaming media. The information may be used to 691 orchestrate the media playout at multiple devices. 693 Errors in the information, either accidental or malicious, may lead 694 to undesired behavior. For example, if one device erroneously 695 reports a two-hour delayed playout, then another device in the same 696 synchronization group could decide to delay its playout by two hours 697 as well, in order to keep its playout synchronized. A user would 698 likely interpret this two hour delay as a malfunctioning service. 700 Therefore, the application logic of both Synchronization Clients and 701 Media Synchronization Application Servers should check for 702 inconsistent information. Differences in playout time exceeding 703 configured limits (e.g. more than ten seconds) could be an indication 704 of such inconsistent information. 706 No new mechanisms are introduced in this document to ensure 707 confidentiality. Encryption procedures, such as those being 708 suggested for a Secure RTP (SRTP) at the time that this document was 709 written, can be used when confidentiality is a concern to end hosts. 711 14. IANA Considerations 713 New RTCP Packet Types and RTCP XR Block Types are subject to IANA 714 registration. For general guidelines on IANA considerations for RTCP 715 XR, refer to [RFC3611]. 717 [TS 183 063] assigns the block type value 12 in the RTCP XR Block 718 Type Registry to "Inter-Destination Media Synchronization Block". 719 [TS183063] also registers the SDP [RFC4566] parameter "grp-sync" for 720 the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 722 Further, this document defines a new RTCP packet type called IDMS 723 report. This new packet type is registered with the IANA registry of 724 RTP parameters, based on the specification in Section 10. 726 Further, this document defines a new SDP parameter "rtcp-idms" within 727 the existing IANA registry of SDP Parameters. 729 The SDP attribute "rtcp-idms" defined by this document is registered 730 with the IANA registry of SDP Parameters as follows: 732 SDP Attribute ("att-field"): 734 Attribute name: rtcp-idms 735 Long form: RTCP report block for IDMS 737 Type of name: att-field 739 Type of attribute: media level 741 Subject to charset: no 743 Purpose: see sections 7 and 10 of this document 745 Reference: this document 747 Values: see this document 749 15. Contributors 751 The following people have participated as co-authors or provided 752 substantial contributions to this document: Omar Niamut, Fabian 753 Walraven, Ishan Vaishnavi, Rufael Mekuria. 755 16. Conclusions 757 This document describes the RTCP XR block type for IDMS, the RTCP 758 IDMS report and the associated SDP parameters for Inter-Destination 759 Media Synchronization. 761 17. References 763 17.1. Normative References 765 [I-D.draft-williams-avtcore-clksrc] 766 Williams, A., van Brandenburg, R., Stokking, H., and K. 767 Gross, "RTP Clock Source Signalling, 768 draft-williams-avtcore-clksrc-00", March 2012. 770 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 771 Requirement Levels, RFC 2119", March 1997. 773 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 774 Jacobson, "RTP: A Transport Protocol for Real-Time 775 Applications, RFC3550", July 2003. 777 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 778 Video conferences with Minimal Control, RFC3551", 779 July 2003. 781 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 782 "RTP Control Protocol Extended Reports (RTCP XR), 783 RFC3611", November 2003. 785 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 786 Description Protocol, RFC4566", July 2006. 788 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 789 Specifications, RFC5234", January 2008. 791 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 792 Protocol (RTCP) Extensions for Single-Source Multicast 793 Sessions with Unicast Feedback, RFC5760", February 2010. 795 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 796 "Network Time Protocol Version 4: Protocol and Algorithms 797 Specifications, RFC5905", February 2010. 799 [TS183063] 800 "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1", 801 June 2010. 803 17.2. Informative References 805 [Boronat2009] 806 Boronat, F., Lloret, J., and M. Garcia, "Multimedia group 807 and inter-stream synchronization techniques: a comparative 808 study, Elsevier Information Systems 34 (2009), pp. 108- 809 131". 811 [I-D.draft-gross-leap-second] 812 Gross, K. and R. Brandenburg, van, "RTP and Leap Seconds, 813 draft-gross-leap-seconds-01". 815 [IEEE-1588] 816 "1588-2008 - IEEE Standard for a Precision Clock 817 Synchronization Protocol for Networked Measurement and 818 Control Systems", 2008. 820 [Ishibashi2006] 821 Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective 822 Assessment of Fairness among users in multipoint 823 communications, Proceedings of the 2006 ACM SIGCHI 824 internation conference on Advances in computer 825 entertainment technology, 2006". 827 [RFC5868] Ott, J. and C. Perkins, "Guidelines for Extending the RTP 828 Control Protocol (RTCP), RFC5968", September 2010. 830 Authors' Addresses 832 Ray van Brandenburg 833 TNO 834 Brassersplein 2 835 Delft 2612CT 836 the Netherlands 838 Phone: +31-88-866-7000 839 Email: ray.vanbrandenburg@tno.nl 841 Hans Stokking 842 TNO 843 Brassersplein 2 844 Delft 2612CT 845 the Netherlands 847 Phone: +31-88-866-7000 848 Email: hans.stokking@tno.nl 850 M. Oskar van Deventer 851 TNO 852 Brassersplein 2 853 Delft 2612CT 854 the Netherlands 856 Phone: +31-88-866-7000 857 Email: oskar.vandeventer@tno.nl 859 Fernando Boronat 860 Universitat Politecnica de Valencia 861 IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia, C/ Paraninfo, 1, Grao de Gandia 862 Valencia 46730 863 Spain 865 Phone: +34 962 849 341 866 Email: fboronat@dcom.upv.es 867 Mario Montagud 868 Universitat Politecnica de Valencia 869 IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia, C/ Paraninfo, 1, Grao de Gandia 870 Valencia 46730 871 Spain 873 Phone: +34 962 849 341 874 Email: mamontor@posgrado.upv.es 876 Kevin Gross 877 AVA Networks 879 Phone: +1-303-447-0517 880 Email: Kevin.Gross@AVAnw.com