idnits 2.17.1 draft-williams-avtcore-clksrc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2012) is 4434 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) -- Looks like a reference, but probably isn't: 'XXX' on line 210 ** Obsolete normative reference: RFC 4566 (ref. '3') (Obsoleted by RFC 8866) == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-idms-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Core A. Williams 3 Maintenance Audinate 4 Internet-Draft R. van Brandenburg 5 Intended status: Standards Track TNO 6 Expires: August 31, 2012 K. Gross 7 AVA Networks 8 February 28, 2012 10 RTP Clock Source Signalling 11 draft-williams-avtcore-clksrc-00 13 Abstract 15 NTP timestamps are used by several RTP protocols for synchronisation 16 and statistical measurement. This memo specificies SDP signalling 17 identifying NTP timestamp clock sources and SDP signalling 18 identifying the media clock sources in a multimedia session. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [1]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 31, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5 64 4.1. Equivalent Timestamp Clocks . . . . . . . . . . . . . . . 5 65 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 6 66 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 6 67 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8 68 4.5. Other Reference Clocks . . . . . . . . . . . . . . . . . . 8 69 4.6. Traceable Reference Clocks . . . . . . . . . . . . . . . . 8 70 4.7. Synchronisation Confidence . . . . . . . . . . . . . . . . 8 71 4.8. SDP Signalling of Timestamp Clock Source . . . . . . . . . 9 72 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11 73 5. Timescales, UTC TAI and leap seconds . . . . . . . . . . . . . 12 74 6. Media Clock Source Signalling . . . . . . . . . . . . . . . . 13 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 RTP protocols use NTP format timestamps to facilitate media stream 86 synchronisation and for providing estimates of round trip time (RTT) 87 and other statistical parameters. 89 Information about media clock timing exchanged in NTP format 90 timestamps may come from a clock which is synchronised to a global 91 time reference, but this cannot be assumed nor is there a 92 standardised mechanism available to indicate that timestamps are 93 derived from a common reference clock. Therefore, RTP 94 implementations typically assume that NTP timestamps are taken using 95 unsynchronised clocks and must compensate for absolute time 96 differences and rate differences. Without a shared reference clock, 97 RTP can time align flows from the same source at a given receiver 98 using relative timing, however tight synchronisation between two or 99 more different receivers (possibly with different network paths) or 100 between two or more senders is not possible. 102 High performance AV systems often use a reference media clock 103 distributed to all devices in the system. The reference media clock 104 is often distinct from the the reference clock used to provide 105 timestamps. A reference media clock may be provided along with a 106 audio or video signal interface, or via a dedicated clock signal 107 (e.g. genlock [9] or audio word clock [10]. If sending and receiving 108 media clocks are known to be synchronised to a common reference 109 clock, performance can improved by minimising buffering and avoiding 110 rate conversion. 112 This specification defines SDP signalling of timestamp clock sources 113 and media reference clock sources. 115 2. Applications 117 Timestamp clock source and reference media clock signalling benefit 118 applications requiring synchronised media capture or playout and low 119 latency operation. 121 Exmaples include, but are not limited to: 123 Social TV RTCP for inter-destination media synchronization [4] 124 defines social TV as the combination of media content consumption 125 by two or more users at different devices and locations and real- 126 time communication between those users. An example of Social TV, 127 is when two or more users are watching the same television 128 broadcast at different devices and locations, while communicating 129 with each other using text, audio and/or video. A skew in the 130 media play-out of the two or more users can have adverse effects 131 on their experience. A well-known use case here is one friend 132 experiencing a goal in a football match well before or after other 133 friend(s). 135 Video Walls A video wall consists of multiple computer monitors, 136 video projectors, or television sets tiled together contiguously 137 or overlapped in order to form one large screen. Each of the 138 screens reproduces a portion of the larger picture. In some 139 implementations, each screen may be individually connected to the 140 network and receive its portion of the overall image from a 141 network-connected video server or video scaler. Screens are 142 refreshed at 60 hertz (every 16-2/3 milliseconds) or potentially 143 faster. If the refresh is not synchronized, the effect of 144 multiple screens acting as one is broken. 146 Netwoked Audio Networked loudspeakers, amplifiers and analogue I/O 147 devices transmitting or receiving audio signals via RTP can be 148 connected to various parts of a building or campus network. Such 149 situations can for example be found in large conference rooms, 150 legislative chambers, classrooms (especially those supporting 151 distance learning) and other large-scale environments such as 152 stadiums. Since humans are more susceptible to differences in 153 audio delay, this use case needs even more accuracy than the video 154 wall use case. Depending on the exact application, the need for 155 accuracy can then be in the range of microseconds [11]. 157 Sensor Arrays Sensor arrays contain many synchronised measurement 158 elements producing signals which are then combined to form an 159 overall measurement. Accurate capture of the phase relationships 160 between the various signals arriving at each element of the array 161 is critically important for proper operation. Examples include 162 towed or fixed sonar arrays, seismic arrays and phased arrays. 164 3. Definitions 166 The definitions of streams, sources and levels of information in SDP 167 descriptions follow the definitions found in Source-Specific Media 168 Attributes in the Session Description Protocol (SDP) [2]. 170 multimedia session A set of multimedia senders and receivers as well 171 as the data streams flowing from senders to receivers. The 172 Session Description Protocol (SDP) [3] describes multimedia 173 sessions. 175 media stream An RTP session potentially containing more than one RTP 176 source. SDP media descriptions beginning with an "m"-line define 177 the parameters of a media stream. 179 media source A media source is single stream of RTP packets, 180 identified by an RTP SSRC. 182 session-level Session-level information applies to an entire 183 multimedia session. In an SDP description, session-level 184 information appears before the first "m"-line. 186 media-level Media-level information applies to a single media stream 187 (RTP session). In an SDP description, media-level information 188 appears after each "m"-line. 190 source-level Source-level information applies to a single stream of 191 RTP packets, identified by an RTP SSRC Source-Specific Media 192 Attributes in the Session Description Protocol (SDP) [2] defines 193 how source-level information is included into an SDP session 194 description. 196 traceable time A clock is considered to provide traceable time if it 197 can be proven to be synchronised to a global time reference. GPS 198 XXX is commonly used to provide a traceable time reference. Some 199 network time synchronisation protocols (e.g. XXX PTP) can 200 explicitly indicate that the master clock is providing a traceable 201 time reference over the network. 203 4. Timestamp Reference Clock Source Signalling 205 The NTP timestamps used by RTP are taking by reading a local clock at 206 the sender or receiver. This local clock may be synchronised to 207 another clock (time source) by some means or it may be 208 unsynchronised. A variety of methods are available to synchronise 209 local clocks to a reference time source, including network time 210 protocols (e.g. NTP [5]) and radio clocks like GPS [XXX]. 212 The following sections describe and define SDP signalling indicating 213 whether and how the local timestamping clock in an RTP sender/ 214 receiver is synchronised to a reference clock. 216 4.1. Equivalent Timestamp Clocks 218 Two or more local clocks that are sufficiently synchronised will 219 produce timestamps for a given event which are effectively identical 220 for the purposes of RTP. A local clock in one RTP sender/receiver 221 can be considered equivalent to a local clock in another RTP sender/ 222 receiver providing they are sufficiently synchronised such that 223 timestamps produced by one clock are indistinguishable from 224 timestamps produced by the other. The timestamps produced by 225 equivalent local clocks in two or more RTP senders/receivers 226 receivers can be directly compared. 228 One or more local clocks are equivalent if they are synchronised to a 229 single master clock via a network time protocol (e.g. XXX NTP, 230 802.1AS, IEEE1588v2). 232 One or more local clocks are equivalent if they are synchronised to 233 any member of a set of master clocks provided that the set of master 234 clocks are synchronised. 236 One or more local clocks are equivalent if they are synchronised to a 237 clock master providing a global time reference (e.g. XXX GPS, 238 Gallileo). Some network time protocols (e.g. XXX PTP) may allow 239 master clocks to explicitly indicate that they are "traceable" back 240 to a global time reference. 242 4.2. Identifying NTP Reference Clocks 244 A single NTP server is identified by identified by hostname (or IP 245 address) and an optional port number. If the port number is not 246 indicated, it is assumed to be the standard NTP port (123) XXX. 248 Two or more NTP servers may be listed to indicate that they are 249 interchangeable. RTP senders/receivers can use any of the listed NTP 250 servers to govern a local clock that is equivalent to a local clock 251 slaved to a difference server. 253 XXX Question: Does NTP carry traceability information? Or is this 254 implicit somehow in the stratum? Apparently there are some bits in 255 the leap seconds functionality which talk about "tracking".. 257 4.3. Identifying PTP Reference Clocks 259 The IEEE1588 Precision Time Protocol (PTP) family of clock 260 synchronisation protocols provide a shared reference clock in an 261 network - typically a LAN. IEEE1588 provides sub-microsecond 262 synchronisation between devices on a LAN and typically locks within 263 seconds at startup. With support from Ethernet switches, IEEE1588 264 protocols can achieve nanosecond timing accuracy in LANs. Network 265 interface chips and cards supporting hardware time-stamping of timing 266 critical protocol messages are also available. 268 When using IEEE1588 clock synchronisation, networked AV systems can 269 achieve sub 1 microsecond time alignment accuracy when rendering AV 270 signals and can support latencies less than 1ms through a gigabit 271 LAN. 273 Three flavours of IEEE1588 are in use today: 275 o IEEE 1588-2002 [6]: the original "Standard for a Precision Clock 276 Synchronization Protocol for Networked Measurement and Control 277 Systems". This is often called IEEE1588v1 or PTPv1. 279 o IEEE 1588-2008 [7]: the second version of the "Standard for a 280 Precision Clock Synchronization Protocol for Networked Measurement 281 and Control Systems". This is a revised version of the original 282 IEEE1588-2002 standard and is often called IEEE1588v2 or PTPv2. 284 o IEEE 802.1AS [8]: "Timing and Synchronization for Time Sensitive 285 Applications in Bridged Local Area Networks". This is a Layer-2 286 only profile of IEEE 1588-2008 for use in Audio/Video Bridged 287 LANs. 289 Each IEEE1588 clock is identified by a globally unique EUI-64 called 290 a "ClockIdentity". A slave clock using one of the IEEE1588 family of 291 network time protocols acquires the ClockIdentity/EUI-64 of the 292 grandmaster clock that is the ultimate source of timing information. 293 A master clock which is itself slaved to another master clock passes 294 the grand master clock identity through to its slaves. 296 Several instances of the IEEE1588v1/v2 protocol may operate 297 independently on a single network, forming distinct PTP network 298 protocol domains each of which may have a different master clock. As 299 the IEEE1588 standards have developed, the definition of PTP domains 300 has changed. IEEE1588v1 identifies protocol subdomains by a textual 301 name and IEEE1588v2 identifies protocol domains using a numeric 302 domain number. 802.1AS is a Layer2 profile of IEEE1588v2 supporting a 303 single numeric clock domain (0). This specification assumes that an 304 IEEE1588 clock master for multiple domains will provide the same 305 timing information to all domains or that each clock domain has a 306 different master. In other words, this specification assumes that a 307 timing domain can be uniquely identified using the ClockIdentity of 308 the grandmaster clock alone. 310 The PTP family of protocols employ a distributed election protocol 311 called the "Best Master Clock Algorithm (BMCA) to determine the 312 active clock master. The clock master choices available to BMCA can 313 be restricted or favourably biased by setting stratum values, 314 preffered master clock bits, or other parameters to influence the 315 election process. In some systems it may be desirable to limit the 316 number of possible PTP clock masters to avoid re-signalling timestamp 317 clock sources when the clock master changes. 319 4.4. Identifying Global Reference Clocks 321 Global reference clocks provide a source of tracable time, typically 322 via a hardware radio receiver interface. Examples include GPS and 323 Gallileo. Apart from the name of the reference clock system, no 324 further identification is required. 326 4.5. Other Reference Clocks 328 At the time of writing, it is common for RTP senders/receivers not to 329 synchronise their local timestamp clock to a master. An 330 unsynchronised clock such as a quartz oscillator is identified as a 331 "local" reference clock. 333 In some systems, all RTP senders/receivers may use a timetsamp clock 334 synchronised to a reference clock that is not provided by one of the 335 methods listed above. Examples may include the reference time 336 information provided by digital television or cellular services. 337 These sources are identified as "private" reference clocks. All RTP 338 senders/receivers in a session using a private reference clock are 339 assumed to have a mechanism outside this specification confirming 340 that their local timestamp clocks are equivalent. 342 4.6. Traceable Reference Clocks 344 A timestamp clock source may be labelled "traceable" if it is known 345 to be sourced from a global time reference such as TAI or UTC XXX. 346 Providing adjustments are made for differing time bases, timestamps 347 taken using a clocks synchronised to a traceable time source can be 348 directly compared even if the clocks are synchronised to different 349 servers or via different mechanisms. Any traceable timestamp clock 350 source can be considered equivalent to another traceable timestamp 351 clock source and the timestamps may be directly compared. 353 Since any NTP or PTP server providing traceable time can be 354 considered equivalent, it is not necessary to identify traceable time 355 servers by protocol address. 357 4.7. Synchronisation Confidence 359 Network time protocols periodically exchange timestamped messages 360 between servers and clients. Assuming RTP sender/receiver clocks are 361 based on commonly available quartz crystal hardware, tight 362 synchronisation requires frequent exchange of synchronisation 363 messages. 365 Unfortunately, in some implementations, it is not possible to control 366 the frequency of synchronisation messages nor is it possible to 367 discover when the last sychronisation message occured. In order to 368 provide a measure of confidence that the timestamp clock is 369 sufficiently synchronised, an optional timestamp may be included in 370 the SDP clock source signalling. In addition, the frequency of 371 synchronisation message may also optionally be provided. 373 The optional timestamp and synchronisation frequency parameters 374 provide an indication of synchronisation quality to the receiver of 375 those parameters. If the synchronisation confidence timestamp is far 376 from the timestamp clock at the receiver of the parameters, it can be 377 assumed that synchronisation has not occured recently or the 378 timestamp reference clock source is wrongly configured or cannot be 379 contacted. In this case, the receiver can take action to prevent 380 unsynchronised playout or may fall back to assuming that the 381 timestamp clocks are not synchronised. 383 Synchronisation frequency is expressed as an 8-bit excess-127 field 384 which is the base 2 logarithm of the frequency in HZ. The 385 synchronisation frequencies represented by this field range from 386 2^-127 Hz to 2^+128 Hz. The field value of 127 corresponds to an 387 update frequency of 1 Hz. 389 4.8. SDP Signalling of Timestamp Clock Source 391 Specification of the timestamp reference clock source may at all 392 levels of an SDP description (see level definitions (Section 3) 393 earlier in this document for more information). 395 Timestamp clock source signalling included at session-level provides 396 default parameters for all RTP sessions and sources in the session 397 description. More specific signalling included at the media-level 398 overrides default session-level signalling. Further, source-level 399 signalling overrides timestamp clock source signalling at the 400 enclosing media-level and session-level. 402 If timestamp clock source signalling is included anywhere in an SDP 403 description, it must be properly defined for all levels in the 404 description. This may simply be achieved by providing default 405 signalling at the session level. 407 Timestamp reference clock parameters may be repeated at a given level 408 (i.e. for a session or source) to provide information about 409 additional servers or clock sources. If the attribute is repeated at 410 a given level, all clocks described at that level are assumed to be 411 equivalent. Traceable clock sources MUST NOT be mixed with clock 412 sources having explicit addresses for a given source or session. 413 Unless synchronisation confidence information is available for each 414 of the reference clocks listed at a given level, it SHOULD only be 415 included with the first reference clock source attribute at that 416 level. 418 Note that clock source parameters may change from time to time, for 419 example, as a result of a PTP clock master election. The SIP XXX 420 protocol supports re-signalling of updated SDP information, however 421 other protocols may require additional notification mechanisms. 423 timestamp-refclk = "a=ts-refclk:" clksrc SP [sync-confidence] CRLF 425 clksrc = ntp / ptp / gps / gal / local / private 427 ntp = "ntp=" ntp-server-addr 428 ntp-server-addr = host [ ":" port ] 429 ntp-server-addr =/ "traceable" ) 431 ptp = "ptp=" ptp-version ":" ptp-gmid 432 ptp-version = "IEEE1588-2002" 433 ptp-version =/ "IEEE1588-2008" 434 ptp-version =/ "IEEE802.1AS-2011" 435 ptp-gmid = EUI64 436 ptp-gmid =/ "traceable" 438 gps = "gps" 439 gal = "gal" 440 local = "local" 441 private = "private" [ ":" "traceable" ] 443 sync-confidence = sync-timestamp [SP sync-frequency] 445 sync-timestamp = sync-date SP sync-time SP sync-UTCoffset 447 sync-date = 4DIGIT "-" 2DIGIT "-" 2DIGIT 448 ; yyyy-mm-dd (e.g., 1982-12-02) 450 sync-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT 451 ; 00:00:00.000 - 23:59:59.999 453 sync-UTCoffset = ( "+" / "-" ) 2DIGIT ":" 2DIGIT 454 ; +HH:MM or -HH:MM 456 sync-frequency = 2HEXDIG 457 ; If N is the field value, HZ=2^(N-127) 459 host = hostname / IPv4address / IPv6reference 460 hostname = *( domainlabel "." ) toplabel [ "." ] 461 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 462 domainlabel = alphanum 463 =/ alphanum *( alphanum / "-" ) alphanum 465 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 466 IPv6reference = "[" IPv6address "]" 467 IPv6address = hexpart [ ":" IPv4address ] 468 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 469 hexseq = hex4 *( ":" hex4) 470 hex4 = 1*4HEXDIG 472 port = 1*DIGIT 474 EUI-64 = 7(HEXDIG "-") 2HEXDIG 476 Figure 1: Timestamp Reference Clock Source Signalling 478 4.8.1. Examples 480 Figure 2 shows an example SDP description with a timestamp reference 481 clock source defined at the session-level. 483 v=0 484 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 485 s=SDP Seminar 486 i=A Seminar on the session description protocol 487 u=http://www.example.com/seminars/sdp.pdf 488 e=j.doe@example.com (Jane Doe) 489 c=IN IP4 224.2.17.12/127 490 t=2873397496 2873404696 491 a=recvonly 492 a=ts-refclk:ntp=traceable 493 m=audio 49170 RTP/AVP 0 494 m=video 51372 RTP/AVP 99 495 a=rtpmap:99 h263-1998/90000 497 Figure 2: Timestamp reference clock defintion at the session level 499 Figure 3 shows an example SDP description with timestamp reference 500 clock definitions at the media-level overriding the session-level 501 defaults. Note that the synchronisation confidence timestamp appears 502 on the first attribute at the media-level only. 504 v=0 505 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 506 s=SDP Seminar 507 i=A Seminar on the session description protocol 508 u=http://www.example.com/seminars/sdp.pdf 509 e=j.doe@example.com (Jane Doe) 510 c=IN IP4 224.2.17.12/127 511 t=2873397496 2873404696 512 a=recvonly 513 a=ts-refclk:local 514 m=audio 49170 RTP/AVP 0 515 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 516 a=ts-refclk:ntp=198.51.100.22 517 m=video 51372 RTP/AVP 99 518 a=rtpmap:99 h263-1998/90000 519 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 521 Figure 3: Timestamp reference clock definition at the media-level 523 Figure 4 shows an example SDP description with a timestamp reference 524 clock definition at the source-level overriding the session-level 525 default. 527 v=0 528 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 529 s=SDP Seminar 530 i=A Seminar on the session description protocol 531 u=http://www.example.com/seminars/sdp.pdf 532 e=j.doe@example.com (Jane Doe) 533 c=IN IP4 224.2.17.12/127 534 t=2873397496 2873404696 535 a=recvonly 536 a=ts-refclk:local 537 m=audio 49170 RTP/AVP 0 538 m=video 51372 RTP/AVP 99 539 a=rtpmap:99 h263-1998/90000 540 a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 542 Figure 4: Timestamp reference clock signalling at the source level 544 5. Timescales, UTC TAI and leap seconds 546 RTP implementation is simplified by using a clock reference with a 547 timescale which does not include leap seconds. IEEE 1588, GPS and 548 other TAI (Inernational Atomic Time) references do not include leap 549 seconds. NTP time, operating system clocks and other UTC 550 (Coordinated Universal Time) references include leap seconds (though 551 the ITU is studying a proposal which could eventually eliminate leap 552 seconds from UTC). 554 Leap seconds are potentially scheduled at the end of the last day of 555 December and June each year. NTP inserts a leap second at the 556 beginning of the last second of the day. This results in the clock 557 freezing for one second immediately prior to the last second of the 558 affected day. Most system clocks insert the leap second at the end 559 of the last second. This results in repetition of the last second of 560 the day. Generating or using timestamps during the entire last 561 second of a day on which a leap second has been scheduled should 562 therefore be avoided. Note that the period to be avoided has a real- 563 time duration of two seconds. 565 It is also important that all participants correctly implement leap 566 seconds and have a working communications channel to receive 567 notification of leap second scheduling. Without prior knowledge of 568 leap second schedule, NTP servers and clients may be offset by 569 exactly one second with respect to their UTC reference. This 570 potential discrepancy begins when a leap second occurs and ends when 571 all participants receive a time update from a server or peer (which, 572 depending on the operating system and/or implementation, could be 573 anywhere from a few minutes to a week). Such a long-lived 574 discrepancy can be particularly disruptive to RTP operation. 576 Apart from the long-lived discrepancy due to dependence on both 577 timing (e.g. NTP) updates and leap seconds scheduling updates, there 578 is also the potential for a short-lived timing discontinuity having 579 an effect on RTP playout timing (even though leap seconds are quite 580 rare). 582 If a timescale with leap seconds is used for RTP: 584 o RTP Senders using a leap-second-bearing reference must not 585 generate sender reports (SR) containing an originating NTP 586 timestamp in the vicinity of a leap second. Receivers should 587 ignore timestamps in any such reports inadvertently generated. 589 o Receivers working to a leap-second-bearing reference must be 590 careful to take leap seconds into account if a leap second occurs 591 between the time a RTP packet is originated and when it is to be 592 presented. 594 6. Media Clock Source Signalling 596 A timestamp clock source (ie media clock is locked to a reference 597 clock like NTP, GPS, etc) Reference clock source.. 599 An RTP session.. This should be an SSRC within an RTP session. 600 Include IP address and port. 602 An IEEE 1722 stream, identified by a Stream ID. 604 7. IANA Considerations 606 The SDP attribute "ts-clksrc" defined by this document is registered 607 with the IANA registry of SDP Parameters as follows: 609 SDP Attribute ("att-field"): 611 Attribute name: ts-refclk 613 Long form: Timestamp reference clock source 615 Type of name: att-field 617 Type of attribute: session, media and source level 619 Subject to charset: no 621 Purpose: See sections 1-4 of this document 623 Reference: This document 625 Values: see this document and registrations below 627 The attribute has an extensible parameter field and therefore a 628 registry for these parameters is required. This document creates an 629 IANA registry called the Timestamp Reference Clock Source Parameters 630 Registry. It contains the six parameters defined in Figure 1: "ntp", 631 "ptp", "gps", "gal", "local", "private". 633 8. Acknowledgements 635 9. References 637 9.1. Normative References 639 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 640 Levels", BCP 14, RFC 2119, March 1997. 642 [2] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media 643 Attributes in the Session Description Protocol (SDP)", RFC 5576, 644 June 2009. 646 [3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 647 Description Protocol", RFC 4566, July 2006. 649 9.2. Informative References 651 [4] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., 652 Montagud, M., and K. Gross, "RTCP for inter-destination media 653 synchronization", draft-ietf-avtcore-idms-02 (work in progress), 654 October 2011. 656 [5] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 657 Protocol Version 4: Protocol and Algorithms Specification", 658 RFC 5905, June 2010. 660 [6] Institute of Electrical and Electronics Engineers, "1588-2002 - 661 IEEE Standard for a Precision Clock Synchronization Protocol for 662 Networked Measurement and Control Systems", IEEE Std 1588-2002, 663 2002, 664 . 666 [7] Institute of Electrical and Electronics Engineers, "1588-2008 - 667 IEEE Standard for a Precision Clock Synchronization Protocol for 668 Networked Measurement and Control Systems", IEEE Std 1588-2008, 669 2008, 670 . 672 [8] "Timing and Synchronization for Time-Sensitive Applications in 673 Bridged Local Area Networks", 674 . 676 URIs 678 [9] 680 [10] 682 [11] 685 Appendix A. An Appendix 686 Authors' Addresses 688 Aidan Williams 689 Audinate 690 Level 1, 458 Wattle St 691 Ultimo, NSW 2007 692 Australia 694 Phone: +61 2 8090 1000 695 Fax: +61 2 8090 1001 696 Email: aidan.williams@audinate.com 697 URI: http://www.audinate.com/ 699 Ray van Brandenburg 700 TNO 701 Brassersplein 2 702 Delft, 703 The Netherlands 705 Phone: +31 88 86 63609 706 Fax: 707 Email: ray.vanbrandenburg@tno.nl 708 URI: 710 Kevin Gross 711 AVA Networks 713 Phone: 714 Fax: 715 Email: 716 URI: