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