idnits 2.17.1 draft-ietf-avtcore-clksrc-01.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 7 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 == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4197 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) ** Obsolete normative reference: RFC 4566 (ref. '3') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 6222 (ref. '7') (Obsoleted by RFC 7022) == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-idms-07 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 K. Gross 5 Intended status: Standards Track AVA Networks 6 Expires: April 25, 2013 R. van Brandenburg 7 H. Stokking 8 TNO 9 October 22, 2012 11 RTP Clock Source Signalling 12 draft-ietf-avtcore-clksrc-01 14 Abstract 16 NTP timestamps are used by several RTP protocols for synchronisation 17 and statistical measurement. This memo specifies SDP signalling 18 identifying NTP timestamp clock sources and SDP signalling 19 identifying the media clock sources in a multimedia session. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [1]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5 65 4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 5 66 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 6 67 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 6 68 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 7 69 4.5. Other Reference Clocks . . . . . . . . . . . . . . . . . . 8 70 4.6. Traceable Reference Clocks . . . . . . . . . . . . . . . . 8 71 4.7. Synchronisation Quality . . . . . . . . . . . . . . . . . 8 72 4.8. SDP Signalling of Timestamp Clock Source . . . . . . . . . 9 73 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12 75 5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13 76 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 13 77 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14 78 5.4. Signalling Grammar . . . . . . . . . . . . . . . . . . . . 15 79 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 RTP protocols use NTP format timestamps to facilitate media stream 89 synchronisation and for providing estimates of round trip time (RTT) 90 and other statistical parameters. 92 Information about media clock timing exchanged in NTP format 93 timestamps may come from a clock which is synchronised to a global 94 time reference, but this cannot be assumed nor is there a 95 standardised mechanism available to indicate that timestamps are 96 derived from a common reference clock. Therefore, RTP 97 implementations typically assume that NTP timestamps are taken using 98 unsynchronised clocks and must compensate for absolute time 99 differences and rate differences. Without a shared reference clock, 100 RTP can time align flows from the same source at a given receiver 101 using relative timing, however tight synchronisation between two or 102 more different receivers (possibly with different network paths) or 103 between two or more senders is not possible. 105 High performance AV systems often use a reference media clock 106 distributed to all devices in the system. The reference media clock 107 is often distinct from the reference clock used to provide 108 timestamps. A reference media clock may be provided along with an 109 audio or video signal interface, or via a dedicated clock signal 110 (e.g. genlock [16] or audio word clock [17]). If sending and 111 receiving media clocks are known to be synchronised to a common 112 reference clock, performance can improved by minimising buffering and 113 avoiding rate conversion. 115 This specification defines SDP signalling of timestamp clock sources 116 and media reference clock sources. 118 2. Applications 120 Timestamp clock source and reference media clock signalling benefit 121 applications requiring synchronised media capture or playout and low 122 latency operation. 124 Examples include, but are not limited to: 126 Social TV RTCP for inter-destination media synchronization [8] 127 defines social TV as the combination of media content consumption 128 by two or more users at different devices and locations and real- 129 time communication between those users. An example of Social TV, 130 is where two or more users are watching the same television 131 broadcast at different devices and/or locations, while 132 communicating with each other using text, audio and/or video. A 133 skew in the media playout of the two or more users can have 134 adverse effects on their experience. A well-known use case here 135 is one friend experiencing a goal in a football match well before 136 or after other friends. 138 Video Walls A video wall consists of multiple computer monitors, 139 video projectors, or television sets tiled together contiguously 140 or overlapped in order to form one large screen. Each of the 141 screens reproduces a portion of the larger picture. In some 142 implementations, each screen or projector may be individually 143 connected to the network and receive its portion of the overall 144 image from a network-connected video server or video scaler. 145 Screens are refreshed at 50 or 60 hertz or potentially faster. If 146 the refresh is not synchronized, the effect of multiple screens 147 acting as one is broken. 149 Networked Audio Networked loudspeakers, amplifiers and analogue I/O 150 devices transmitting or receiving audio signals via RTP can be 151 connected to various parts of a building or campus network. Such 152 situations can for example be found in large conference rooms, 153 legislative chambers, classrooms (especially those supporting 154 distance learning) and other large-scale environments such as 155 stadiums. Since humans are more susceptible to differences in 156 audio delay, this use case needs even more accuracy than the video 157 wall use case. Depending on the exact application, the need for 158 accuracy can then be in the range of microseconds [18]. 160 Sensor Arrays Sensor arrays contain many synchronised measurement 161 elements producing signals which are then combined to form an 162 overall measurement. Accurate capture of the phase relationships 163 between the various signals arriving at each element of the array 164 is critically important for proper operation. Examples include 165 towed or fixed sonar arrays, seismic arrays and phased arrays used 166 in radar applications, for instance. 168 3. Definitions 170 The definitions of streams, sources and levels of information in SDP 171 descriptions follow the definitions found in Source-Specific Media 172 Attributes in the Session Description Protocol (SDP) [2]. 174 multimedia session A set of multimedia senders and receivers as well 175 as the data streams flowing from senders to receivers. The 176 Session Description Protocol (SDP) [3] describes multimedia 177 sessions. 179 media stream An RTP session potentially containing more than one RTP 180 source. SDP media descriptions beginning with an "m"-line define 181 the parameters of a media stream. 183 media source A media source is single stream of RTP packets, 184 identified by an RTP SSRC. 186 session level Session level information applies to an entire 187 multimedia session. In an SDP description, session-level 188 information appears before the first "m"-line. 190 media level Media level information applies to a single media stream 191 (RTP session). In an SDP description, media-level information 192 appears after each "m"-line. 194 source level Source level information applies to a single stream of 195 RTP packets, identified by an RTP SSRC Source-Specific Media 196 Attributes in the Session Description Protocol (SDP) [2] defines 197 how source-level information is included into an SDP session 198 description. 200 traceable time A clock is considered to provide traceable time if it 201 can be proven to be synchronised to a global time reference. GPS 202 [9] is commonly used to provide a traceable time reference. Some 203 network time synchronisation protocols (e.g. PTP [10], NTP) can 204 explicitly indicate that the master clock is providing a traceable 205 time reference over the network. 207 4. Timestamp Reference Clock Source Signalling 209 The NTP timestamps used by RTP are taken by reading a local real-time 210 clock at the sender or receiver. This local clock may be 211 synchronised to another clock (time source) by some means or it may 212 be unsynchronised. A variety of methods are available to synchronise 213 local clocks to a reference time source, including network time 214 protocols (e.g. NTP [11]) and radio clocks (e.g. GPS [9]). 216 The following sections describe and define SDP signalling, indicating 217 whether and how the local timestamping clock in an RTP sender/ 218 receiver is synchronised to a reference clock. 220 4.1. Clock synchronization 222 Two or more local clocks that are sufficiently synchronised will 223 produce timestamps for a given RTP event can be used as if they came 224 from the same clock. Providing they are sufficiently synchronised, 225 timestamps produced in one RTP sender or receiver can be directly 226 compared to a local clock in another RTP sender or receiver. 228 The accuracy of synchronization required is application dependent. 229 See Applications (Section 2) section for a discussion of applications 230 and their corresponding requirements. To serve as a reference clock, 231 clocks must minimally be syntonized (exactly frequency matched) to 232 one another. 234 Sufficient synchronization can typically be achieving by using a 235 network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to 236 synchronize all devices to a single master clock. 238 Another approach is to use clocks providing a global time reference 239 (e.g. GPS, Galileo). This concept may be used in conjunction with 240 network time protocols as some protocols (e.g. PTP, NTP) allow 241 master clocks to indicate explicitly that they are "traceable" back 242 to a global time reference. 244 4.2. Identifying NTP Reference Clocks 246 A single NTP server is identified by hostname (or IP address) and an 247 optional port number. If the port number is not indicated, it is 248 assumed to be the standard NTP port (123). 250 Two or more NTP servers may be listed at the same level in the 251 session description to indicate that they are interchangeable. RTP 252 senders or receivers can use any of the listed NTP servers to govern 253 a local clock that is equivalent to a local clock slaved to a 254 different server. 256 4.3. Identifying PTP Reference Clocks 258 The IEEE 1588 Precision Time Protocol (PTP) family of clock 259 synchronisation protocols provides a shared reference clock in an 260 network - typically a LAN. IEEE 1588 provides sub-microsecond 261 synchronisation between devices on a LAN and typically locks within 262 seconds at startup. With support from Ethernet switches, IEEE 1588 263 protocols can achieve nanosecond timing accuracy in LANs. Network 264 interface chips and cards supporting hardware time-stamping of timing 265 critical protocol messages are also available. 267 Three flavours of IEEE 1588 are in use today: 269 o IEEE 1588-2002 [12]: the original "Standard for a Precision Clock 270 Synchronization Protocol for Networked Measurement and Control 271 Systems". This is also known as IEEE1588v1 or PTPv1. 273 o IEEE 1588-2008 [10]: the second version of the "Standard for a 274 Precision Clock Synchronization Protocol for Networked Measurement 275 and Control Systems". This is a revised version of the original 276 IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2. 277 IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002. 279 o IEEE 802.1AS [13]: "Timing and Synchronization for Time Sensitive 280 Applications in Bridged Local Area Networks". This is a Layer-2 281 only profile of IEEE 1588-2008 for use in Audio/Video Bridged LANs 282 as described in IEEE 802.1BA-2011 [14]. 284 Each IEEE 1588 clock is identified by a globally unique EUI-64 called 285 a "ClockIdentity". A slave clock using one of the IEEE 1588 family 286 of network time protocols acquires the ClockIdentity/EUI-64 of the 287 grandmaster clock that is the ultimate source of timing information 288 for the network. A boundary clock which is itself slaved to another 289 boundar clock or the grandmaster passes the grandmaster ClockIdentity 290 through to its slaves. 292 Several instances of the IEEE 1588 protocol may operate independently 293 on a single network, forming distinct PTP domains, each of which may 294 have a different grandmaster clock. As the IEEE 1588 standards have 295 developed, the definition of PTP domains has changed. IEEE 1588-2002 296 identifies protocol subdomains by a textual name, but IEEE 1588-2008 297 identifies protocol domains using a numeric domain number. 802.1AS is 298 a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock 299 domain (0). 301 When PTP domains are signalled via SDP, senders and receivers SHOULD 302 check that both grandmaster ClockIdentity and PTP domain match when 303 determining clock equivalence. 305 The PTP protocols employ a distributed election protocol called the 306 "Best Master Clock Algorithm" (BMCA) to determine the active clock 307 master. The clock master choices available to BMCA can be restricted 308 or biased by configuration parameters to influence the election 309 process. In some systems it may be desirable to limit the number of 310 possible PTP clock masters to avoid the need to re-signal timestamp 311 clock sources when the clock master changes. 313 4.4. Identifying Global Reference Clocks 315 Global reference clocks provide a source of traceable time, typically 316 via a hardware radio receiver interface. Examples include GPS and 317 Galileo. Apart from the name of the reference clock system, no 318 further identification is required. 320 4.5. Other Reference Clocks 322 RFC 3550 allows senders and receivers to either use a local wallclock 323 reference for their NTP timestamps or, by setting the timestamp field 324 to 0, to supply no timstamps at all. Both are common practice in 325 embedded RTP implementations. These clocks are identified as "local" 326 and can only be assumed to be equivalent to clocks originating from 327 the same device. 329 In other systems, all RTP senders and receivers may use a timestamp 330 clock synchronised to a reference clock that is not provided by one 331 of the methods listed above. Examples may include the reference time 332 information provided by digital television or cellular services. 333 These sources are identified as "private" reference clocks. All RTP 334 senders and receivers in a session using a private reference clock 335 are assumed to have a mechanism outside this specification for 336 determining whether their timestamp clocks are equivalent. 338 4.6. Traceable Reference Clocks 340 A timestamp clock source may be labelled "traceable" if it is known 341 to be sourced from a global time reference such as TAI or UTC. 342 Providing adjustments are made for differing time bases, timestamps 343 taken using clocks synchronised to a traceable time source can be 344 directly compared even if the clocks are synchronised to different 345 sources or via different mechanisms. 347 Since all NTP and PTP servers providing traceable time can be 348 directly compared, it is not necessary to identify traceable time 349 servers by protocol address or other identifiers. 351 4.7. Synchronisation Quality 353 Network time protocol services periodically exchange timestamped 354 messages between servers and clients. Assuming RTP device clocks are 355 based on commonly available quartz crystal hardware which is subject 356 to drift, tight synchronisation requires frequent exchange of 357 synchronisation messages. 359 Unfortunately, in some implementations, it is not possible to control 360 the frequency of synchronisation messages nor is it possible to 361 discover when the last synchronisation message occurred. In order to 362 provide a measure of synchronization quality, an optional timestamp 363 may be included in the SDP clock source signalling. In addition, the 364 frequency of synchronisation messages may also be signalled. 366 The optional timestamp and synchronisation frequency parameters 367 provide an indication of synchronisation quality to the receiver of 368 those parameters. If the synchronisation quality timestamp is far 369 from the timestamp clock at the receiver of the parameters, it can be 370 assumed that synchronisation has not occurred recently, the timestamp 371 reference clock source cannot be contacted or the SDP information has 372 not been recently refreshed. To eliminate the latter possiblity, 373 updated SDP information should be retrieved. If the synchronisation 374 quality timestamp is still far from the timestamp clock the receiver 375 can take action to prevent unsynchronised playout or may fall back to 376 assuming that the timestamp clocks are not synchronised. 378 Synchronisation frequency is expressed as a signed (two's-compliment) 379 8-bit field which is the base-2 logarithm of the frequency in Hz. 380 The synchronisation frequencies represented by this field range from 381 2^-128 Hz to 2^+127 Hz. The field value of 0 corresponds to an 382 update frequency of 1 Hz. 384 When multiple reference clocks are specified, a sender or receiver 385 may wish to base selection of the clock used based on most recent or 386 most frequent update as indicated by the synchronization quality 387 signalling. 389 4.8. SDP Signalling of Timestamp Clock Source 391 Specification of the timestamp reference clock source may be at any 392 or all levels (session, media or source) of an SDP description (see 393 level definitions (Section 3) earlier in this document for more 394 information). 396 Timestamp clock source signalling included at session-level provides 397 default parameters for all RTP sessions and sources in the session 398 description. More specific signalling included at the media level 399 overrides default session level signalling. 401 If timestamp clock source signalling is included anywhere in an SDP 402 description, it must be properly defined for all levels in the 403 description. This may simply be achieved by providing default 404 signalling at the session level. 406 Timestamp reference clock parameters may be repeated at a given level 407 (i.e. for a session or source) to provide information about 408 additional servers or clock sources. If the attribute is repeated at 409 a given level, all clocks described at that level are assumed to be 410 equivalent. Traceable clock sources MUST NOT be mixed with non- 411 traceable clock sources at any given level. Unless synchronisation 412 quality information is available for each of the reference clocks 413 listed at a given level, it SHOULD only be included with the first 414 reference clock source attribute at that level. 416 Note that clock source parameters may change from time to time, for 417 example, as a result of a PTP clock master election. The SIP [4] 418 protocol supports re-signalling of updated SDP information, however 419 other protocols may require additional notification mechanisms. 421 Figure 1 shows the ABNF [5] grammar for the SDP reference clock 422 source information. 424 timestamp-refclk = "a=ts-refclk:" clksrc [ SP sync-quality ] CRLF 426 clksrc = ntp / ptp / gps / gal / local / private 428 ntp = "ntp=" ntp-server-addr 429 ntp-server-addr = host [ ":" port ] 430 ntp-server-addr =/ "traceable" ) 432 ptp = "ptp=" ptp-version ":" ptp-server 433 ptp-version = "IEEE1588-2002" 434 ptp-version =/ "IEEE1588-2008" 435 ptp-version =/ "IEEE802.1AS-2011" 436 ptp-server = ptp-gmid [":" ptp-domain] / "traceable" 437 ptp-gmid = EUI64 438 ptp-domain = ptp-domain-name / ptp-domain-nmbr 439 ptp-domain-name = "domain-name=" 16ptp-domain-char 440 ptp-domain-char = %x21-7E / %x00 441 ; allowed characters: 0x21-0x7E (IEEE 1588-2002) 442 ptp-domain-nmbr = "domain-nmbr=" %x00-7f 443 ; allowed number range: 0-127 (IEEE 1588-2008) 445 gps = "gps" 446 gal = "gal" 447 local = "local" 448 private = "private" [ ":" "traceable" ] 450 sync-quality = sync-timestamp [SP sync-frequency] 451 sync-timestamp = sync-date SP sync-time SP sync-UTCoffset 452 sync-date = 4DIGIT "-" 2DIGIT "-" 2DIGIT 453 ; yyyy-mm-dd (e.g., 1982-12-02) 454 sync-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT 455 ; 00:00:00.000 - 23:59:59.999 456 sync-UTCoffset = ( "+" / "-" ) 2DIGIT ":" 2DIGIT 457 ; +HH:MM or -HH:MM 458 sync-frequency = 2HEXDIG 459 ; If N is the field value, HZ=2^(N-127) 461 host = hostname / IPv4address / IPv6reference 462 hostname = *( domainlabel "." ) toplabel [ "." ] 463 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 464 domainlabel = alphanum 465 =/ alphanum *( alphanum / "-" ) alphanum 466 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 467 IPv6reference = "[" IPv6address "]" 468 IPv6address = hexpart [ ":" IPv4address ] 469 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 470 hexseq = hex4 *( ":" hex4) 471 hex4 = 1*4HEXDIG 473 port = 1*DIGIT 475 EUI64 = 7(2HEXDIG "-") 2HEXDIG 477 Figure 1: Timestamp Reference Clock Source Signalling 479 4.8.1. Examples 481 Figure 2 shows an example SDP description with a timestamp reference 482 clock source defined at the session level. 484 v=0 485 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 486 s=SDP Seminar 487 i=A Seminar on the session description protocol 488 u=http://www.example.com/seminars/sdp.pdf 489 e=j.doe@example.com (Jane Doe) 490 c=IN IP4 224.2.17.12/127 491 t=2873397496 2873404696 492 a=recvonly 493 a=ts-refclk:ntp=traceable 494 m=audio 49170 RTP/AVP 0 495 m=video 51372 RTP/AVP 99 496 a=rtpmap:99 h263-1998/90000 498 Figure 2: Timestamp reference clock definition at the session level 500 Figure 3 shows an example SDP description with timestamp reference 501 clock definitions at the media level overriding the session level 502 defaults. Note that the synchronisation confidence timestamp appears 503 on the first attribute at the media level only. 505 v=0 506 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 507 s=SDP Seminar 508 i=A Seminar on the session description protocol 509 u=http://www.example.com/seminars/sdp.pdf 510 e=j.doe@example.com (Jane Doe) 511 c=IN IP4 224.2.17.12/127 512 t=2873397496 2873404696 513 a=recvonly 514 a=ts-refclk:local 515 m=audio 49170 RTP/AVP 0 516 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 517 a=ts-refclk:ntp=198.51.100.22 518 m=video 51372 RTP/AVP 99 519 a=rtpmap:99 h263-1998/90000 520 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 522 Figure 3: Timestamp reference clock definition at the media level 524 Figure 4 shows an example SDP description with a timestamp reference 525 clock definition at the source level overriding the session level 526 default. 528 v=0 529 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 530 s=SDP Seminar 531 i=A Seminar on the session description protocol 532 u=http://www.example.com/seminars/sdp.pdf 533 e=j.doe@example.com (Jane Doe) 534 c=IN IP4 224.2.17.12/127 535 t=2873397496 2873404696 536 a=recvonly 537 a=ts-refclk:local 538 m=audio 49170 RTP/AVP 0 539 m=video 51372 RTP/AVP 99 540 a=rtpmap:99 h263-1998/90000 541 a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 543 Figure 4: Timestamp reference clock signalling at the source level 545 5. Media Clock Source Signalling 547 The media clock source for a stream determines the timebase used to 548 advance the RTP timestamps included in RTP packets. The media clock 549 may be asynchronously generated by the sender, it may be generated in 550 fixed relationship to the reference clock or it may be generated with 551 respect to another stream on the network (which is presumably being 552 received by the sender). 554 5.1. Asynchronously Generated Media Clock 556 In the simplest sender implementation, the sender generates media by 557 sampling audio or video according to a free-running local clock. The 558 RTP timestamps in media packets are advanced according to this media 559 clock and packet transmission is typically timed to regular intervals 560 on this timeline. The sender may or may not include an NTP timestamp 561 in sender reports to allow mapping of this asynchronous media clock 562 to a reference clock. 564 The asynchronously generated media clock is the assumed mode of 565 operation when there is no signalling of media clock source. 566 Alternatively, asynchronous media clock may be explicitly signalled. 568 a=mediaclk:sender 570 5.2. Direct-Referenced Media Clock 572 A media clock may be directly derived from a reference clock. For 573 this case it is required that a reference clock be specified with an 574 a=ts-refclk attribute (Section 4.8). 576 The signalling optionally indicates a media clock offset value. The 577 offset indicates the RTP timestamp value at the epoch (time of 578 origin) of the reference clock. If no offset is signalled, the 579 offset can be inferred at the receiver by examining RTCP sender 580 reports which contain NTP and RTP timestamps which combined define a 581 mapping. 583 A rate modifier may be specified. The modifier is expressed as the 584 ratio of two integers and modifies the rate specified or implied by 585 the media description by this ratio. If omitted, the rate is assumed 586 to be the exact rate specified or implied by the media format. For 587 example, without a rate specification, the media clock for an 8 kHz 588 G.711 audio stream will advance exactly 8000 units for each second 589 advance in the reference clock from which it is derived. 591 The rate modifier is primarily useful for accommodating certain 592 "oddball" audio sample rates associated with NTSC video (see 593 Figure 7). Modified rates are not advised for video streams which 594 generally use a 90 kHz RTP clock regardless of frame rate or sample 595 rate used for embedded audio. 597 a=mediaclk:direct[=] [rate=/] 600 5.3. Stream-Referenced Media Clock 602 A common synchronisation architecture for audio/visual systems 603 involves distributing a reference media clock from a master device to 604 a number of slave devices, typically by means of a cable. Examples 605 include audio word clock distribution and video black burst 606 distribution. In this case, the media clock is locally generated, 607 often by a crystal oscillator and is not locked to a timestamp 608 reference clock. 610 To support this architecture across a network, a master clock 611 identifier is associated with media sources carrying media clock 612 timing information from a master device. The master clock identifier 613 represents a media clock source in the master device. Slave devices 614 in turn associate the master media clock identifer with streams they 615 transmit, signalling the synchronisation relationship between the 616 master and slave devices. 618 Slave devices recover media clock timing from the clock master 619 stream, using it to synchronise the slave media clock with the 620 master. Timestamps in the master clock media stream are taken using 621 the timestamp reference clock shared by the master and slave devices. 622 The timestamps communicate information about media clock timing 623 (rate, phase) from the master to the slave devices. Timestamps are 624 communicated in the usual RTP fashion via RTCP SRs, or via the 625 RFC6051 [6] header extension. The stream media format may indicate 626 other clock information, such as the nominal rate. 628 Note that slaving of a device media clock to a master device does not 629 affect the usual RTP lip sync / time alignment algorithms. Time 630 aligned playout of two or more RTP sources still relies upon NTP 631 timestamps supplied via RTCP SRs or by the RFC6051 timestamp header 632 extension. 634 In a given system, master clock identifiers must be unique. Such 635 identifiers MAY be manually configured, however 17 octet string 636 identifiers SHOULD be generated according to the "short-term 637 persistent RTCP CNAME" algorithm as described in RFC6222 [7]. 639 A reference stream can be an RTP stream or AVB stream based on the 640 IEEE 1722 [15] standard. 642 An RTP clock master stream SHOULD be identified at the source level 643 by an SSRC and master clock identifier. If master clock identifiers 644 are declared at the media or session level, all RTP sources at or 645 below the level of declaration MUST provide equivalent timing to a 646 slave receiver. 648 a=ssrc:12345 mediaclk:master id= 650 An RTP media source indicates that it is slaved to a clock master via 651 a clock master identifier: 653 a=mediaclk:slave id= 655 An RTP media source indicates that it is slaved to an IEEE 1722 clock 656 master via a stream identifier (an EUI-64): 658 a=mediaclk:IEEE1722= 660 5.4. Signalling Grammar 662 Specification of the media clock source may be at any or all levels 663 (session, media or source) of an SDP description (see level 664 definitions (Section 3) earlier in this document for more 665 information). 667 Media clock source signalling included at session level provides 668 default parameters for all RTP sessions and sources in the session 669 description. More specific signalling included at the media level 670 overrides default session level signalling. Further, source-level 671 signalling overrides media clock source signalling at the enclosing 672 media level and session level. 674 Media clock source signalling may be present or absent on a per- 675 stream basis. In the absence of media clock source signals, 676 receivers assume an asynchronous media clock generated by the sender. 678 Media clock source parameters may be repeated at a given level (i.e. 679 for a session or source) to provide information about additional 680 clock sources. If the attribute is repeated at a given level, all 681 clocks described at that level are comparable clock sources and may 682 be used interchangeably. 684 Figure 5 shows the ABNF [5] grammar for the SDP media clock source 685 information. 687 timestamp-mediaclk = "a=mediaclk:" mediaclock 689 mediaclock = refclk / streamid / sender 691 rate = [ SP "rate=" 1*DIGIT "/" 1*DIGIT ] 693 refclk = "direct" [ "=" 1*DIGIT ] rate 695 streamid = "master-id=" clk-master-id 697 streamid =/ "slave-to=" clk-master-id 699 streamid =/ "IEEE1722=" EUI64 701 clk-master-id = EUI48 703 sender = "sender" 705 EUI48 = 5(2HEXDIG ":") 2HEXDIG 706 EUI64 = 7(2HEXDIG ":") 2HEXDIG 708 Figure 5: Media Clock Source Signalling 710 5.5. Examples 712 Figure 6 shows an example SDP description 8 channels of 24-bit, 48 713 kHz audio transmitted as a multicast stream. Media clock is derived 714 directly from an IEEE 1588-2008 reference. 716 v=0 717 o=- 1311738121 1311738121 IN IP4 192.168.1.1 718 c=IN IP4 239.0.0.2/255 719 s= 720 t=0 0 721 m=audio 5004 RTP/AVP 96 722 a=rtpmap:96 L24/48000/8 723 a=sendonly 724 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 725 a=mediaclk:direct=963214424 727 Figure 6: Media clock directly referenced to IEEE 1588-2008 729 Figure 7 shows an example SDP description 2 channels of 24-bit, 44056 730 kHz NTSC "pull-down" media clock derived directly from an IEEE 1588- 731 2008 reference clock 732 v=0 733 o=- 1311738121 1311738121 IN IP4 192.168.1.1 734 c=IN IP4 239.0.0.2/255 735 s= 736 t=0 0 737 m=audio 5004 RTP/AVP 96 738 a=rtpmap:96 L24/44100/2 739 a=sendonly 740 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 741 a=mediaclk:direct=963214424 rate=1000/1001 743 Figure 7: "Oddball" sample rate directly referenced to IEEE 1588-2008 745 Figure 8 shows the same 48 kHz audio transmission from Figure 6 with 746 media clock derived from another RTP stream. 748 v=0 749 o=- 1311738121 1311738121 IN IP4 192.168.1.1 750 c=IN IP4 224.2.228.230/32 751 s= 752 t=0 0 753 m=audio 5004 RTP/AVP 96 754 a=rtpmap:96 L24/48000/2 755 a=sendonly 756 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 757 a=mediaclk:slave id=00:60:2b:20:12:1f 759 Figure 8: RTP stream with media clock slaved to a master device 761 Figure 9 shows the same 48 kHz audio transmission from Figure 6 with 762 media clock derived from an IEEE 1722 AVB stream. 764 v=0 765 o=- 1311738121 1311738121 IN IP4 192.168.1.1 766 c=IN IP4 224.2.228.230/32 767 s= 768 t=0 0 769 m=audio 5004 RTP/AVP 96 770 a=rtpmap:96 L24/48000/2 771 a=sendonly 772 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 773 a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F 775 Figure 9: RTP stream with media clock slaved to an IEEE1722 master 776 device 778 6. IANA Considerations 780 The SDP attribute "ts-refclk" defined by this document is registered 781 with the IANA registry of SDP Parameters as follows: 783 SDP Attribute ("att-field"): 785 Attribute name: ts-refclk 787 Long form: Timestamp reference clock source 789 Type of name: att-field 791 Type of attribute: session, media and source level 793 Subject to charset: no 795 Purpose: See section 4 of this document 797 Reference: This document 799 Values: see this document and registrations below 801 The attribute has an extensible parameter field and therefore a 802 registry for these parameters is required. This document creates an 803 IANA registry called the Timestamp Reference Clock Source Parameters 804 Registry. It contains the six parameters defined in Figure 1: "ntp", 805 "ptp", "gps", "gal", "local", "private". 807 The SDP attribute "mediaclk" defined by this document is registered 808 with the IANA registry of SDP Parameters as follows: 810 SDP Attribute ("att-field"): 812 Attribute name: mediaclk 814 Long form: Media clock source 816 Type of name: att-field 818 Type of attribute: session and media level 820 Subject to charset: no 822 Purpose: See section 6 of this document 824 Reference: This document 826 Values: see this document and registrations below 828 The attribute has an extensible parameter field and therefore a 829 registry for these parameters is required. This document creates an 830 IANA registry called the Media Clock Source Parameters Registry. It 831 contains the three parameters defined in Figure 5: "sender", 832 "direct", "master", "slave" and "IEEE1722". 834 7. References 836 7.1. Normative References 838 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 839 Levels", BCP 14, RFC 2119, March 1997. 841 [2] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media 842 Attributes in the Session Description Protocol (SDP)", 843 RFC 5576, June 2009. 845 [3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 846 Description Protocol", RFC 4566, July 2006. 848 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 849 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 850 Session Initiation Protocol", RFC 3261, June 2002. 852 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 853 Specifications: ABNF", RFC 2234, November 1997. 855 [6] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 856 Flows", RFC 6051, November 2010. 858 [7] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing 859 RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", 860 RFC 6222, April 2011. 862 7.2. Informative References 864 [8] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., 865 Montagud, M., and K. Gross, "Inter-destination Media 866 Synchronization using the RTP Control Protocol (RTCP)", 867 draft-ietf-avtcore-idms-07 (work in progress), October 2012. 869 [9] Global Positioning Systems Directorate, "Navstar GPS Space 870 Segment/Navigation User Segment Interfaces", September 2011. 872 [10] Institute of Electrical and Electronics Engineers, "1588-2008 - 873 IEEE Standard for a Precision Clock Synchronization Protocol 874 for Networked Measurement and Control Systems", IEEE Std 1588- 875 2008, 2008, 876 . 878 [11] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 879 Protocol Version 4: Protocol and Algorithms Specification", 880 RFC 5905, June 2010. 882 [12] Institute of Electrical and Electronics Engineers, "1588-2002 - 883 IEEE Standard for a Precision Clock Synchronization Protocol 884 for Networked Measurement and Control Systems", IEEE Std 1588- 885 2002, 2002, 886 . 888 [13] "Timing and Synchronization for Time-Sensitive Applications in 889 Bridged Local Area Networks", 890 . 893 [14] "Audio Video Bridging (AVB) Systems", 894 . 897 [15] "IEEE Standard for Layer 2 Transport Protocol for Time 898 Sensitive Applications in a Bridged Local Area Network", 899 . 901 URIs 903 [16] 905 [17] 907 [18] 910 Authors' Addresses 912 Aidan Williams 913 Audinate 914 Level 1, 458 Wattle St 915 Ultimo, NSW 2007 916 Australia 918 Phone: +61 2 8090 1000 919 Fax: +61 2 8090 1001 920 Email: aidan.williams@audinate.com 921 URI: http://www.audinate.com/ 923 Kevin Gross 924 AVA Networks 925 Boulder, CO 926 US 928 Email: kevin.gross@avanw.com 929 URI: http://www.avanw.com/ 931 Ray van Brandenburg 932 TNO 933 Brassersplein 2 934 Delft 2612CT 935 the Netherlands 937 Phone: +31-88-866-7000 938 Email: ray.vanbrandenburg@tno.nl 940 Hans Stokking 941 TNO 942 Brassersplein 2 943 Delft 2612CT 944 the Netherlands 946 Phone: 947 Email: stokking@tno.nl