idnits 2.17.1 draft-brandenburg-avtcore-rtcp-for-idms-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4796 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) == Missing Reference: 'RFC2119' is mentioned on line 182, but not defined == Missing Reference: 'RFC5760' is mentioned on line 336, but not defined == Unused Reference: 'RFC5576' is defined on line 869, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 5968 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio/Video Transport Core Maintenance Working Group R. van Brandenburg 2 Internet Draft H.M. Stokking 3 Intended status: Standards Track M.O. van Deventer 4 Expires: September 2011 O.A. Niamut 5 F.A. Walraven 6 TNO Netherlands 7 I. Vaishnavi 8 CWI Netherlands 9 F. Boronat 10 M. Montagud 11 Universidad Politecnica de Valencia 12 March 7, 2011 14 RTCP for inter-destination media synchronization 15 draft-brandenburg-avtcore-rtcp-for-idms-00.txt 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on September 7, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Abstract 54 This document gives information on an RTCP Packet Type and RTCP XR 55 Block Type including associated SDP parameters for inter-destination 56 media synchronization (IDMS). The RTCP XR Block Type, registered with 57 IANA based on an ETSI specification, is used to collect media play- 58 out information from participants in a group playing-out (watching, 59 listening, etc.) a specific RTP media stream. The RTCP packet type 60 specified by this document is used to distribute a summary of the 61 collected information so that the participants can synchronize play- 62 out. 64 Typical applications for IDMS are social TV, shared service control 65 (i.e. applications where two or more geographically separated users 66 are watching a media stream together), distance learning, network 67 quiz shows, multi-playing online games, etc. 69 Table of Contents 71 1. Introduction.................................................3 72 1.1. Inter-destination Media Synchronization.................3 73 1.2. Applicability of RTCP to IDMS...........................3 74 1.3. Applicability of SDP to IDMS............................4 75 1.4. This document and ETSI TISPAN...........................4 76 2. Terminology..................................................4 77 3. Overview of IDMS operation...................................4 78 4. Inter-destination media synchronization use cases............6 79 5. Architecture for inter-destination media synchronization.....6 80 5.1. Media Synchronization Application Server (MSAS).........7 81 5.2. Synchronization Client (SC).............................7 82 5.3. Communication between MSAS and SCs......................7 83 6. RTCP XR Block Type for IDMS..................................8 84 7. RTCP Packet Type for IDMS...................................10 85 8. Timing and NTP Considerations...............................11 86 9. SDP Parameter for RTCP XR IDMS Block Type...................12 87 10. SDP Parameter for RTCP IDMS Packet Type....................13 88 11. SDP parameter for clock source.............................13 89 12. Compatibility with ETSI TISPAN.............................15 90 13. Operational Considerations.................................16 91 14. Security Considerations....................................16 92 15. IANA Considerations........................................17 93 16. Conclusions................................................18 94 17. References.................................................19 95 17.1. Normative References..................................19 96 17.2. Informative References................................19 97 18. Acknowledgments............................................19 99 1. Introduction 101 1.1. Inter-destination Media Synchronization 103 Inter-destination media synchronization (IDMS) refers to the play-out 104 of media streams at two or more geographically distributed locations 105 in a temporally synchronized manner. It can be applied to both 106 unicast and multicast media streams and can be applied to any type 107 and/or combination of streaming media, such as audio, video and text 108 (subtitles). [Boronat2009] provides an overview of technologies and 109 algorithms for IDMS. 111 IDMS requires the exchange of information on media receipt and 112 playout times. It may also require signaling for the initiation and 113 maintenance of IDMS sessions and groups. 115 The presented RTCP specification for IDMS is independent of the used 116 synchronization algorithm, which is out-of-scope of this document. 118 1.2. Applicability of RTCP to IDMS 120 Currently, most multimedia applications make use of RTP and RTCP 121 [RFC3550]. RTP (Real-time Transport Protocol) provides end-to-end 122 network transport functions suitable for applications requiring real- 123 time data transport, such as audio, video or data, over multicast or 124 unicast network services. The timestamps and sequence number 125 mechanisms provided by RTP are very useful to reconstruct the 126 original media timing, reorder and detect some packet loss at the 127 receiver side. 129 The data transport is augmented by a control protocol (RTCP) to allow 130 monitoring of the data delivery in a manner that is scalable to large 131 multicast networks, and to provide minimal control and identification 132 functionality. 134 RTP receivers and senders provide reception quality feedback by 135 sending out RTCP Receiver Report (RR) and Sender Report (SR) packets 136 [RFC3550] respectively, which may be augmented by eXtended Reports 137 (XR) [RFC3611]. Thus, the feedback reporting features provided by 138 RTCP make QoS monitoring possible and can be used for troubleshooting 139 and fault tolerance management in multicast distribution services 140 such as IPTV. 142 These protocols are intended to be tailored through modification 143 and/or additions in order to include profile-specific information 144 required by particular applications, and the guidelines on doing so 145 are specified in [RFC5968]. 147 IDMS involves the collection, summarizing and distribution of RTP 148 packet arrival and play-out times. As information on RTP packet 149 arrival times and play-out times can be considered reception quality 150 feedback information, RTCP becomes a promising candidate for carrying 151 out IDMS, which may facilitate implementation in typical multimedia 152 applications. 154 1.3. Applicability of SDP to IDMS 156 RTCP XR [RFC3611] defines the Extended Report (XR) packet type for 157 the RTP Control Protocol (RTCP), and defines how the use of XR 158 packets can be signaled by an application using the Session 159 Description Protocol (SDP) [RFC4566]. 161 SDP signaling is used to set up and maintain a synchronization group 162 between Synchronization Clients (SCs). This document describes two 163 SDP parameters for doing this, one for the RTCP XR block type and one 164 for the new RTCP packet type. 166 This document also allows for a receiver to indicate a used clock 167 source for synchronizing the receiver clock used in the IDMS session. 168 This is also done using an SDP parameter, which is described in this 169 document. 171 1.4. This document and ETSI TISPAN 173 ETSI TISPAN [TS 183 063] has specified architecture and protocol for 174 IDMS using RTCP XR exchange and SDP signaling. 176 2. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119] and 181 indicate requirement levels for compliant implementations. 183 3. Overview of IDMS operation 185 This section provides a brief example of how the IDMS RTCP 186 functionality is used. The section is tutorial in nature and does not 187 contain any normative statements. 189 Alice's . . . . . . .tv:abc.com . . . . . . . . . Bob's 190 TV (SC) (MSAS) Laptop (SC) 191 | | | 192 | Media Session | | 193 |<=====================>| | 194 | Invite(URL,Sync-group ID) | 195 |------------------------------------------------->| 196 | | Media Session Set-up | 197 | |<========================>| 198 | | | 199 | Call set-up | 200 |<================================================>| 201 | | | 202 | RTP Packet | RTP Packet | 203 |<----------------------|------------------------->| 204 | RR + IDMS XR | | 205 |---------------------->| RR + IDMS XR | 206 | |<-------------------------| 207 | RTCP IDMS packet | RTCP IDMS packet | 208 |<----------------------|------------------------->| 209 | | | 211 Alice is watching TV in her living room. At some point she sees that 212 a football game of Bob's favorite team is on. She sends him an invite 213 to watch the program together. Embedded in the invitation is the link 214 to the media server and a unique sync-group identifier. 216 Bob, who is also at home, receives the invite on his laptop. He 217 accepts Alice's invitation and the RTP client on his laptop sets up a 218 session to the media server. A VoIP connection to Alice's TV is also 219 set up, so that Alice and Bob can talk while watching the program. 221 As is common with RTP, both the RTP client in Alice's TV as well as 222 the one in Bob's laptop send periodic RTCP Receiver Reports (RR) to 223 the media server. However, in order to make sure Alice and Bob see 224 the events in the football game at the same time, their clients also 225 periodically send an IDMS XR block to the MSAS function of the media 226 server. Included in the XR blocks are timestamps on when both Alice 227 and Bob have received (or played out) a particular RTP packet. 229 The MSAS function in the media server calculates a reference client 230 from the received IDMS XR blocks (e.g. by selecting whichever client 231 received the packet the latest as the reference client). It then 232 sends an RTCP IDMS packet containing the play-out information of this 233 reference client to both Alice and Bob. 235 In this case Bob has the slowest connection and the reference client 236 therefore includes a delay similar to the one experienced by Bob. 237 Upon reception of this information, Alice's RTP client can choose 238 what to do with this information. In this case it decreases its play- 239 out rate temporarily until it matches with the reference client play- 240 out (and thus matches Bob's play-out). Another option for Alice's TV 241 would be to simply pause playback until it catches up. The exact 242 implementation of the synchronization algorithm is up to the client. 244 Upon reception of the reference client RTCP IDMS packet, Bob's client 245 does not have to do anything since it is already synchronized to the 246 reference client (since it is based on Bob's delay). Note that other 247 synchronization algorithms may introduce even more delay than the one 248 experienced by the most delayed client, e.g. to account for delay 249 variations, for new clients joining an existing synchronization 250 group, etc. 252 4. Inter-destination media synchronization use cases 254 Social TV is the combination of media content consumption by two or 255 more users at different devices and locations and real-time 256 communication between those users. 258 An example of Social TV, is when two or more users are watching the 259 same television broadcast at different devices and locations, while 260 communicating with each other using text, audio and/or video. 262 A skew in the media play-out of the two or more users can have 263 adverse effects on their experience. A well-known use case here is 264 one friend experiencing a goal in a football match well before or 265 after other friend(s). Thus IDMS is required to provide play-out 266 synchronization. 268 Another example of Social TV is Shared Service Control, where two or 269 more users experience some content-on-demand together, while sharing 270 the trick-play controls (play, pause, fast forward, rewind) of the 271 content on demand. 273 Similar to the previous use case, without IDMS, differences in play- 274 out speed and the effect of transit delay of trick-play control 275 signals would desynchronize content play-out. 277 5. Architecture for inter-destination media synchronization 279 The architecture for IDMS, which is based on a sync-maestro 280 architecture [Boronat2009], is sketched below. The Synchronization 281 Client (SC) and Media Synchronization Application Server (MSAS) 282 entities are shown as additional functionality for the RTP receiver 283 and sender respectively. 285 It should be noted that a master/slave type of architecture is also 286 supported by having one of the SC devices also act as an MSAS. In 287 this case the MSAS functionality is thus embedded in an RTP receiver 288 instead of an RTP sender. 290 +-----------------------+ +-----------------------+ 291 | | SR + | | 292 | RTP Receiver | RTCP | RTP Sender | 293 | | IDMS | | 294 | +-----------------+ | <----- | +-----------------+ | 295 | | | | | | | | 296 | | Synchronization | | | | Media | | 297 | | Client | | | | Synchronization | | 298 | | (SC) | | | | Application | | 299 | | | | | | Server | | 300 | | | | RR+XR | | (MSAS) | | 301 | | | | -----> | | | | 302 | +-----------------+ | | +-----------------+ | 303 | | | | 304 +-----------------------+ +-----------------------+ 306 5.1. Media Synchronization Application Server (MSAS) 308 An MSAS collects RTP packet arrival times and play-out times from one 309 or more SC(s) in a synchronization group. The MSAS summarizes and 310 distributes this information to the SCs in the synchronization group 311 as synchronization settings, e.g. by determining the SC with the most 312 lagged play-out and using its reported RTP packet arrival time and 313 play-out time as a summary. 315 5.2. Synchronization Client (SC) 317 An SC reports RTP packet arrival times and play-out times of a media 318 stream. It can receive summaries of such information, and use that to 319 adjust its play-out buffer. 321 5.3. Communication between MSAS and SCs 323 Two different message types are used for the communication between 324 MSAS and SCs. For the SC->MSAS message containing the play-out 325 information of a particular client, an RTCP XR Block Type is used 326 (see Section 6). For the MSAS->SC message containing the 327 synchronization settings instructions, a new RTCP Packet Type is 328 defined in Section 7. 330 6. RTCP XR Block Type for IDMS 332 This section describes the RTCP XR Block Type for reporting IDMS 333 information on an RTP media stream. Its definition is based on 334 [RFC3611]. The RTCP XR is used to provide feedback information on 335 receipt times and presentation times of RTP packets to e.g. a Sender 336 [RFC3611], a Feedback Target [RFC5760] or a Third Party Monitor 337 [RFC3611]. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |V=2|P| Resrv | PT=XR=207 | length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | SSRC of packet sender | 345 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 346 | BT=12 | SPST |Resrv|P| block length=7 | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | PT | Resrv | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Media Stream Correlation Identifier | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | SSRC of media source | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Packet Received NTP timestamp, most significant word | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Packet Received NTP timestamp, least significant word | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Packet Received RTP timestamp | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Packet Presented NTP timestamp | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 The first 64 bits form the header of the RTCP XR, as defined in 364 [RFC3611]. The SSRC of packet sender identifies the sender of the 365 specific RTCP packet. 367 The IDMS report block consists of 7 32-bit words, with the following 368 fields: 370 Block Type (BT): 8 bits. It identifies the block format. Its value 371 SHALL be set to 12. 373 Synchronization Packet Sender Type (SPST): 4 bits. This field 374 identifies the role of the packet sender for this specific eXtended 375 Report. It can have the following values: 377 SPST=0 Reserved For future use. 379 SPST=1 The packet sender is an SC. It uses this XR to report 380 synchronization status information. Timestamps relate to the SC 381 input. 383 SPST=2 This setting is reserved in order to preserve compatibility 384 with ETSI TISPAN [TS 183 063]. See section 12. for more information. 386 SPST=3-15 Reserved For future use. 388 Reserved bits (Resrv): 3 bits. These bits are reserved for future 389 definition. In the absence of such a definition, the bits in this 390 field MUST be set to zero and MUST be ignored by the receiver. 392 Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the 393 Packet Presented NTP timestamp field contains a value, 0 if it is 394 empty. If this flag is set to zero, then the Packet Presented NTP 395 timestamp shall not be inspected. 397 Block Length: 16 bits. This field indicates the length of the block 398 in 32 bit words and shall be set to 7, as this RTCP Block Type has a 399 fixed length. 401 Payload Type (PT): 7 bits. This field identifies the format of the 402 media payload, according to [RFC3551]. The media payload is 403 associated with an RTP timestamp clock rate. This clock rate provides 404 the time base for the RTP timestamp counter. 406 Reserved bits (Resrv): 25 bits. These bits are reserved for future 407 use and shall be set to 0. 409 Media Stream Correlation Identifier: 32 bits. This identifier is used 410 to correlate synchronized media streams. The value 0 (all bits are 411 set "0") indicates that this field is empty. The value 2^32-1 (all 412 bits are set "1") is reserved for future use. If the RTCP Packet 413 Sender is an SC (SPST=1), then the Media Stream Correlation 414 Identifier maps on the SyncGroupId to which the SC belongs. 416 SSRC: 32 bits. The SSRC of the media source shall be set to the value 417 of the SSRC identifier carried in the RTP header [RFC3550] of the RTP 418 packet to which the XR relates. 420 Packet Received NTP timestamp: 64 bits. This timestamp reflects the 421 wall clock time at the moment of arrival of the first octet of the 422 RTP packet to which the XR relates. It is formatted based on the NTP 423 timestamp format as specified in [RFC5905]. See section 8 for more 424 information on how this field is set. 426 Packet Received RTP timestamp: 32 bits. This timestamp has the value 427 of the RTP time stamp carried in the RTP header [RFC3550] of the RTP 428 packet to which the XR relates. 430 Packet Presented NTP timestamp: 32 bits. This timestamp reflects the 431 wall clock time at the moment the data contained in the first octet 432 of the associated RTP packet is presented to the user. It is based on 433 the time format used by NTP and consists of the least significant 16 434 bits of the NTP seconds part and the most significant 16 bits of the 435 NTP fractional second part. If this field is empty, then it SHALL be 436 set to 0 and the Packet Presented NTP timestamp flag (P) SHALL be set 437 to 0. 439 7. RTCP Packet Type for IDMS (IDMS report) 441 This section specifies the RTCP Packet Type for indicating 442 synchronization settings instructions to a receiver of the RTP media 443 stream. Its definition is based on [RFC3550]. 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |V=2|P| Resrv | PT=TBD | length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | SSRC of packet sender | 451 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 452 | SSRC of media source | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Media Stream Correlation Identifier | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Packet Received NTP timestamp, most significant word | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Packet Received NTP timestamp, least significant word | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Packet Received RTP timestamp | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Packet Presented NTP timestamp | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 The first 64 bits form the header of the RTCP Packet Type, as defined 466 in [RFC3550]. The SSRC of packet sender identifies the sender of the 467 specific RTCP packet. 469 The RTCP IDMS packet consists of 6 32-bit words, with the following 470 fields: 472 SSRC: 32 bits. The SSRC of the media source shall be set to the value 473 of the SSRC identifier carried in the RTP header [RFC3550] of the RTP 474 packet to which the RTCP IDMS packet relates. 476 Media Stream Correlation Identifier: 32 bits. This identifier is used 477 to correlate synchronized media streams. The value 0 (all bits are 478 set "0") indicates that this field is empty. The value 2^32-1 (all 479 bits are set "1") is reserved for future use. The Media Stream 480 Correlation Identifier maps on the SyncGroupId of the group to which 481 this packet is sent. 483 Packet Received NTP timestamp: 64 bits. This timestamp reflects the 484 wall clock time at the reference client at the moment it received the 485 first octet of the RTP packet to which this packet relates. It can be 486 used by the synchronization algorithm on the receiving SC to set the 487 required playout delay. The timestamp is formatted based on the NTP 488 timestamp format as specified in [RFC5905]. See section 8 for more 489 information on how this field is set. 491 Packet Received RTP timestamp: 32 bits. This timestamp has the value 492 of the RTP time stamp carried in the RTP header [RFC3550] of the RTP 493 packet to which the XR relates. 495 Packet Presented NTP timestamp: 32 bits. This timestamp reflects the 496 wall clock time at the reference client at the moment it presented 497 the data contained in the first octet of the associated RTP packet to 498 the user. It is based on the time format used by NTP and consists of 499 the least significant 16 bits of the NTP seconds part and the most 500 significant 16 bits of the NTP fractional second part. If this field 501 is empty, then it SHALL be set to 0. This field MAY be left empty if 502 none or only one of the receivers reported on presentation 503 timestamps. 505 8. Timing and NTP Considerations 507 To achieve IDMS, the different receivers involved need synchronized 508 clocks as a common timeline for synchronization. Depending on the 509 synchronization accuracy required, different clock synchronization 510 methods can be used. For social TV, synchronization accuracy should 511 be achieved in order of hundreds of milliseconds. In that case, 512 correct use of NTP on receivers will in most situations achieve the 513 required accuracy. As a guideline, to deal with clock drift of 514 receivers, receivers should synchronize their clocks at the beginning 515 of a synchronized session. 517 IDMS may be used for other purposes, such as synchronization of 518 multiple television outputs in a single physical location, or for the 519 synchronization of different networked speakers throughout a house. 521 Because of the stringent synchronization requirements for achieving 522 good audio, a high accuracy will be needed. In this case, NTP usage 523 may not be sufficient. Either a local NTP server could be setup, or 524 some other more accurate clock synchronization mechanism could be 525 used, such as using GPS time or the Precision Time Protocol [IEEE- 526 1588]. 528 In this document, a new SDP parameter is introduced to signal the 529 clock synchronization source or sources used or able to be used (see 530 section 10). An SC can indicate which synchronization source is being 531 used at the moment and the last time the SC synchronized with this 532 source. An SC can also indicate any other synchronization sources 533 available to it. This allows multiple SCs in an IDMS session to use 534 the same or a similar clock synchronization source for their session. 536 Applications performing IDMS may or may not be able to choose a 537 synchronization method for the system clock. How applications deal 538 with this is up to the implementation. The application might control 539 the system clock, or it might use a separate application clock or 540 even a separate IDMS session clock. It might also report on the 541 system clock and the synchronization method used, without being able 542 to change it. 544 9. SDP Parameter for RTCP XR IDMS Block Type 546 The SDP parameter sync-group is used to signal the use of the RTCP XR 547 block for inter-destination media synchronization. It is also used to 548 carry an identifier for the synchronization group to which clients 549 belong or will belong. This SDP parameter extends rtcp-xr-attrib as 550 follows, using Augmented Backus-Naur Form [RFC5234]. 552 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 553 ; Original definition from [RFC3611], section 5.1 555 xr-format =/ grp-sync ; Extending xr-format for inter-destination 556 media synchronization 558 grp-sync = "grp-sync" [",sync-group=" SyncGroupId] 560 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295 562 DIGIT = %x30-39 564 SyncGroupId is a 32-bit unsigned integer in network byte order and 565 represented in decimal. SyncGroupId identifies a group of SCs for 566 IDMS. It maps on the Media Stream Correlation Identifier as described 567 in sections 6 and 7. The value SyncGroupId=0 represents an empty 568 SyncGroupId. The value 4294967295 (2^32-1) is reserved for future 569 use. 571 The following is an example of the SDP attribute for IDMS 573 a=rtcp-xr:grp-sync,sync-group=42 575 10. SDP Parameter for RTCP IDMS Packet Type 577 The SDP parameter rtcp-idms is used to signal the use of the RTCP 578 IDMS Packet Type for IDMS. It is also used to carry an identifier for 579 the synchronization group to which clients belong or will belong. The 580 SDP parameter is used as a media-level attribute during session 581 setup. This SDP parameter is defined as follows, using Augmented 582 Backus-Naur Form [RFC5234]. 584 rtcp-idms = "a=" "rtcp-idms" ":" [sync-grp] CRLF 586 sync-grp = "sync-group=" SyncGroupId 588 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295 590 DIGIT = %x30-39 592 SyncGroupId is a 32-bit unsigned integer in network byte order and 593 represented in decimal. SyncGroupId identifies a group of SCs for 594 IDMS. The value SyncGroupId=0 represents an empty SyncGroupId. The 595 value 4294967295 (2^32-1) is reserved for future use. 597 The following is an example of the SDP attribute for IDMS. 599 a=rtcp-idms:sync-group=42 601 11. SDP parameter for clock source 603 The SDP parameter clocksource is used to signal the source for clock 604 synchronization. This SDP parameter is specified as follows, using 605 Augmented Backus-Naur Form [RFC5234]. 607 clocksource = "a=" "clocksource" ":" source SP [last-synced] CRLF 609 source = local / ntp / gps / gal / ptp 611 local = "local" 613 ntp = "ntp" ["=" ntp-server] 615 ntp-server = host [ ":" port ] 616 host = hostname / IPv4address / IPv6reference 618 hostname = *( domainlabel "." ) toplabel [ "." ] 620 domainlabel = alphanum 622 / alphanum *( alphanum / "-" ) alphanum 624 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 626 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 628 IPv6reference = "[" IPv6address "]" 630 IPv6address = hexpart [ ":" IPv4address ] 632 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 634 hexseq = hex4 *( ":" hex4) 636 hex4 = 1*4HEXDIG 638 port = 1*DIGIT 640 gps = "gps" 642 gal = "gal" 644 ptp = "ptp" ["=" ptp-id] 646 ptp-id = 1*alphanum 648 last-synced = date SP time 650 date = 2DIGIT "-" 2DIGIT "-" 4DIGIT 652 ; day month year (e.g., 02-06-1982) 654 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 656 ; 00:00:00 - 23:59:59 658 alphanum = ALPHA / DIGIT 660 EXAMPLE 662 a=clocksource:ntp=139.63.192.5:123 19-02-2011 21:03:20 663 A client MAY include this attribute multiple times. If multiple time 664 synchronization sources were used in the past, the client MUST only 665 report the 'last synced' parameter on the latest synchronization 666 performed. If a client supports a specific synchronization method, 667 but does not know any sources to use for synchronization, it SHOULD 668 indicate the method without specifying the source. A client MAY 669 indicate itself as source if it is a clock synchronization source, 670 but it SHOULD do so using a publicly reachable address. 672 The parameter can be used as both a session or media level attribute. 673 It will normally be a session level parameter, since it is not 674 directly media-related. In case of IDMS however, it can be used in 675 conjunction with the rtcp-idms SDP parameter, and then it SHOULD be 676 used as a media-level parameter as well. 678 The meaning of 'local' is that no clock synchronization is performed. 680 The 'last synced' parameter is used as an indication for the receiver 681 of the parameter on the accuracy of the clock. If the indicated last 682 synchronization time is very recent, this is an indication that the 683 clock can be trusted to be accurate, given the method of clock 684 synchronization used. If the indicated last synchronization time is 685 longer ago or in the future, either the clock synchronization has 686 been performed long ago, or the clock is synchronized to an incorrect 687 synchronization source. Either way, this shows that the clock used 688 can not be trusted to be accurate. 690 12. Compatibility with ETSI TISPAN 692 As described in section 1.4, ETSI TISPAN has also described a 693 mechanism for IDMS in [TS 183 063]. One of the main differences 694 between the TISPAN document and this document is the fact that the 695 TISPAN solution uses an RTPC XR block for both the SC->MSAS message 696 as well as for the MSAS->SC message (by selecting different SPST- 697 types), while this document specifies a new RTCP Packet Type for the 698 MSAS->SC message. 700 In order to maintain backward-compatibility, the RTCP XR block used 701 for SC->MSAS signaling specified in this document is fully compatible 702 with the TISPAN defined XR block. 704 For the MSAS->SC signaling, it is recommended to use the RTCP IDMS 705 Packet Type defined in this document. The TISPAN XR block with SPST=2 706 MAY be used for purposes of compatibility with the TISPAN solution, 707 but MUST NOT be used if all nodes involved support the new RTCP IDMS 708 Packet Type. 710 The above means that the IANA registry contains two SDP parameters 711 for the MSAS->SC signaling; one for the ETSI TISPAN solution and one 712 for the IETF solution. This also means that if all elements in the 713 SDP negotiation support the IETF solution they SHOULD use the new 714 RTCP IDMS Packet Type. 716 13. Operational Considerations 718 On Echo Cancellation: 720 In the case of social TV: If the two locations have a "side channel" 721 audio conference so the viewers can talk about what they are 722 watching, this may cause an audio problem that will not be solved by 723 just applying IDMS. The audio output of the television of one viewer 724 will pass through the audio conference, and arrive at the second 725 viewer out of sync with the television output of that second viewer. 726 Different methods can be used to deal with this effect, e.g. using 727 directional microphones to prevent this or applying echo cancellation 728 to filter out the unwanted audio signals. 730 On Reception vs. Presentation Timing: 732 A receiver can report on different timing events, i.e. on packet 733 arrival times and on playout times. A receiver SHALL report on 734 arrival times and a receiver MAY report on playout times. RTP packet 735 arrival times are relatively easy to report on. Normally, the 736 processing and play-out of the same media stream by different 737 receivers will take roughly the same amount of time. By synchronizing 738 on packet arrival times, you may loose some accuracy, but it will be 739 adequate for many applications, such as social TV. Also, if the 740 receivers are in some way controlled, e.g. having the same buffer 741 settings and decoding times, high accuracy can be achieved. However, 742 if all receivers in a synchronization session have the ability to 743 report on, and thus synchronize on, actual playout times, or packet 744 presentation times, this may be more accurate. It is up to 745 applications and implementations of this RTCP extension whether to 746 implement and use this. 748 14. Security Considerations 750 The specified RTCP XR Block Type in this document is used to collect, 751 summarize and distribute information on packet reception- and playout 752 -times of streaming media. The information may be used to orchestrate 753 the media play-out at multiple devices. 755 Errors in the information, either accidental or malicious, may lead 756 to undesired behavior. For example, if one device erroneously reports 757 a two-hour delayed play-out, then another device in the same 758 synchronization group could decide to delay its play-out by two hours 759 as well, in order to keep its play-out synchronized. A user would 760 likely interpret this two hour delay as a malfunctioning service. 762 Therefore, the application logic of both Synchronization Clients and 763 Media Synchronization Application Servers should check for 764 inconsistent information. Differences in play-out time exceeding 765 configured limits (e.g. more than ten seconds) could be an indication 766 of such inconsistent information. 768 No new mechanisms are introduced in this document to ensure 769 confidentiality. Encryption procedures, such as those being suggested 770 for a Secure RTP (SRTP) at the time that this document was written, 771 can be used when confidentiality is a concern to end hosts. 773 15. IANA Considerations 775 New RTCP Packet Types and RTCP XR Block Types are subject to IANA 776 registration. For general guidelines on IANA considerations for RTCP 777 XR, refer to [RFC3611]. 779 [TS 183 063] assigns the block type value 12 in the RTCP XR Block 780 Type Registry to "Inter-destination Media Synchronization Block". [TS 781 183 063] also registers the SDP [RFC4566] parameter "grp-sync" for 782 the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 784 Further, this document defines a new RTCP packet type called IDMS 785 report. This new packet type is registered with the IANA registry of 786 RTP parameters, based on the specification in section 7. 788 Further, this document defines a new SDP parameter "rtcp-idms" within 789 the existing IANA registry of SDP Parameters. 791 The SDP attribute "rtcp-idms" defined by this document is registered 792 with the IANA registry of SDP Parameters as follows: 794 SDP Attribute ("att-field"): 796 Attribute name: rtcp-idms 798 Long form: RTCP report block for IDMS 800 Type of name: att-field 802 Type of attribute: media level 804 Subject to charset: no 805 Purpose: see sections 7 and 10 of this document 807 Reference: this document 809 Values: see this document 811 Further, this document defines a new SDP attribute, "clocksource", 812 within the existing IANA registry of SDP Parameters. 814 The SDP attribute "clocksource" defined by this document is 815 registered with the IANA registry of SDP Parameters as follows: 817 SDP Attribute ("att-field"): 819 Attribute name: clocksource 821 Long form: clock synchronization source 823 Type of name: att-field 825 Type of attribute: session level 827 Subject to charset: no 829 Purpose: see sections 8 and 11 of this document 831 Reference: this document 833 Values: see this document and registrations below 835 The attribute has an extensible parameter field and therefore a 836 registry for these parameters is required. This document creates an 837 IANA registry called the Clocksource Source Parameters Registry. It 838 contains the five parameters defined in Section 11: "local", "ntp", 839 "gps", "gal" and "ptp". 841 16. Conclusions 843 This document describes the RTCP XR block type for IDMS, the RTCP 844 IDMS report and the associated SDP parameters for inter-destination 845 media synchronization. It also describes an SDP parameter for 846 indicating which source is used for synchronizing a (systems) (wall) 847 clock. 849 17. References 851 17.1. Normative References 853 [RFC5234] Crocker, D. and Overell, P., "Augmented BNF for Syntax 854 Specifications: ABNF", RFC 5234, January 2008. 856 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 857 Applications", RFC 3550, July 2003. 859 [RFC3551] Schulzrinne, H. and Casner S., "RTP Profile for Audio and 860 Video Conferences with Minimal Control", RFC 3551, July 861 2003 863 [RFC3611] Friedman, T. "RTP Control Protocol Extended Reports (RTCP 864 XR)", RFC 3611, November 2003. 866 [RFC4566] Handley, M., "SDP: Session Description Protocol", RFC 4566, 867 July 2006. 869 [RFC5576] Lennox, J., "Source-Specific Media Attributes in the 870 Session Description Protocol (SDP)", RFC 5576, June 2009. 872 [RFC5905] Mills, D., "Network Time Protocol Version 4: Protocol and 873 Algorithms Specification", RFC 5905, June 2010. 875 [RFC5968] Ott, J., Guidelines on Extending the RTP Control Protocol 876 (RTCP), September 2010. 878 [TS 183 063] ETSI TISPAN, "IMS-based IPTV stage 3 specification", 879 TS 183 063 v3.4.1, June 2010. 881 17.2. Informative References 883 [Boronat2009] Boronat, F., et al, "Multimedia group and inter-stream 884 synchronization techniques: A comparative study", Elsevier 885 Information Systems 34 (2009), pp. 108-131 887 [IEEE-1588] IEEE Standards Association, "1588-2008 - IEEE Standard 888 for a Precision Clock Synchronization Protocol for 889 Networked Measurement and Control Systems", 2008 891 Authors' Addresses 893 Ray van Brandenburg 894 TNO 895 Brassersplein 2, Delft, the Netherlands 897 Phone: +31 88 86 63609 898 Email: ray.vanbrandenburg@tno.nl 900 Hans M. Stokking 901 TNO 902 Brassersplein 2, Delft, the Netherlands 904 Phone: +31 88 86 67278 905 Email: hans.stokking@tno.nl 907 M. Oskar van Deventer 908 TNO 909 Brassersplein 2, Delft, the Netherlands 911 Phone: +31 88 86 67078 912 Email: oskar.vandeventer@tno.nl 914 Omar A. Niamut 915 TNO 916 Brassersplein 2, Delft, the Netherlands 918 Phone: +31 88 86 67218 919 Email: omar.niamut@tno.nl 921 Fabian A. Walraven 922 TNO 923 Brassersplein 2, Delft, the Netherlands 925 Phone: +31 88 86 67722 926 Email: fabian.walraven@tno.nl 928 Ishan Vaishnavi 929 CWI 930 Science Park 123, Amsterdam, the Netherlands 932 Phone: +31 20 592 4323 933 Email: i.vaishnavi@cwi.nl 934 Fernando Boronat 935 IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia 936 C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain 938 Phone: +34 962 849 341 939 Email: fboronat@dcom.upv.es 941 Mario Montagud 942 IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia 943 C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain 945 Phone: +34 962 849 341 946 Email: mamontor@posgrado.upv.es