idnits 2.17.1 draft-ietf-avtcore-clksrc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2013) is 4058 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. '2') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6222 (ref. '7') (Obsoleted by RFC 7022) == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-idms-07 -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '20') (Obsoleted by RFC 7826) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 K. Gross 5 Intended status: Standards Track AVA Networks 6 Expires: September 19, 2013 R. van Brandenburg 7 H. Stokking 8 TNO 9 March 18, 2013 11 RTP Clock Source Signalling 12 draft-ietf-avtcore-clksrc-03 14 Abstract 16 NTP format timestamps are used by several RTP protocols for 17 synchronisation and statistical measurements. This memo specifies 18 SDP signalling identifying timestamp reference clock sources and SDP 19 signalling identifying the media clock sources in a multimedia 20 session. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [1]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 19, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5 66 4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 5 67 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 6 68 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 6 69 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 7 70 4.5. Other Reference Clocks . . . . . . . . . . . . . . . . . . 8 71 4.6. Traceable Reference Clocks . . . . . . . . . . . . . . . . 8 72 4.7. SDP Signalling of Timestamp Clock Source . . . . . . . . . 8 73 4.7.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12 75 5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 12 76 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12 77 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 13 78 5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 14 79 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 6. Signalling considerations . . . . . . . . . . . . . . . . . . 17 81 6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18 82 6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 18 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 RTP protocols use NTP format timestamps to facilitate multimedia 93 session synchronisation and for providing estimates of round trip 94 time (RTT) and other statistical parameters. 96 Information about media clock timing exchanged in NTP format 97 timestamps may come from a clock which is synchronised to a global 98 time reference, but this cannot be assumed nor is there a 99 standardised mechanism available to indicate that timestamps are 100 derived from a common reference clock. Therefore, RTP 101 implementations typically assume that NTP timestamps are taken using 102 unsynchronised clocks and must compensate for absolute time 103 differences and rate differences. Without a shared reference clock, 104 RTP can time align flows from the same source at a given receiver 105 using relative timing, however tight synchronisation between two or 106 more different receivers (possibly with different network paths) or 107 between two or more senders is not possible. 109 High performance AV systems often use a reference media clock 110 distributed to all devices in the system. The reference media clock 111 is often distinct from the reference clock used to provide 112 timestamps. A reference media clock may be provided along with an 113 audio or video signal interface, or via a dedicated clock signal 114 (e.g. genlock [9] or audio word clock [10]). If sending and 115 receiving media clocks are known to be synchronised to a common 116 reference clock, performance can improved by minimising buffering and 117 avoiding rate conversion. 119 This specification defines SDP signalling of timestamp clock sources 120 and media reference clock sources. 122 2. Applications 124 Timestamp clock source and reference media clock signalling benefit 125 applications requiring synchronised media capture or playout and low 126 latency operation. 128 Examples include, but are not limited to: 130 Social TV : RTCP for inter-destination media synchronization [11] 131 defines social TV as the combination of media content consumption 132 by two or more users at different devices and locations and real- 133 time communication between those users. An example of Social TV, 134 is where two or more users are watching the same television 135 broadcast at different devices and/or locations, while 136 communicating with each other using text, audio and/or video. A 137 skew in the media playout of the two or more users can have 138 adverse effects on their experience. A well-known use case here 139 is one friend experiencing a goal in a football match well before 140 or after other friends. 142 Video Walls : A video wall consists of multiple computer monitors, 143 video projectors, or television sets tiled together contiguously 144 or overlapped in order to form one large screen. Each of the 145 screens reproduces a portion of the larger picture. In some 146 implementations, each screen or projector may be individually 147 connected to the network and receive its portion of the overall 148 image from a network-connected video server or video scaler. 149 Screens are refreshed at 50 or 60 hertz or potentially faster. If 150 the refresh is not synchronized, the effect of multiple screens 151 acting as one is broken. 153 Networked Audio : Networked loudspeakers, amplifiers and analogue 154 I/O devices transmitting or receiving audio signals via RTP can be 155 connected to various parts of a building or campus network. Such 156 situations can for example be found in large conference rooms, 157 legislative chambers, classrooms (especially those supporting 158 distance learning) and other large-scale environments such as 159 stadiums. Since humans are more susceptible to differences in 160 audio delay, this use case needs even more accuracy than the video 161 wall use case. Depending on the exact application, the need for 162 accuracy can then be in the range of microseconds [21]. 164 Sensor Arrays : Sensor arrays contain many synchronised measurement 165 elements producing signals which are then combined to form an 166 overall measurement. Accurate capture of the phase relationships 167 between the various signals arriving at each element of the array 168 is critically important for proper operation. Examples include 169 towed or fixed sonar arrays, seismic arrays and phased arrays used 170 in radar applications, for instance. 172 3. Definitions 174 The following definitions are used in this draft: 176 media level : Media level information applies to a single SDP media 177 stream. In an SDP description, media-level information appears 178 after each "m"-line. 180 multimedia session : A set of multimedia senders and receivers as 181 well as the data streams flowing from senders to receivers. The 182 Session Description Protocol (SDP) [2] describes multimedia 183 sessions. 185 RTP media stream : A single stream of RTP packets identified by an 186 RTP SSRC. 188 RTP media sender : The device generating an associated RTP media 189 stream 191 SDP media stream : An RTP session potentially containing more than 192 one RTP source. SDP media descriptions beginning with an "m"-line 193 define the parameters of an SDP media stream. 195 session level : Session level information applies to an entire 196 multimedia session. In an SDP description, session-level 197 information appears before the first "m"-line. 199 source level : Source level information applies to a RTP media 200 stream Source-Specific Media Attributes in the Session Description 201 Protocol (SDP) [3] defines how source-level information is 202 included into an SDP session description. 204 traceable time : A clock is considered to provide traceable time if 205 it can be proven to be synchronised to International Atomic Time 206 (TAI). Coordinated Universal Time (UTC) is a time standard 207 synchronized to TAI. UTC is therefore also considered traceable 208 time once leap seconds have been taken unto account. GPS [12] is 209 commonly used to provide a TAI traceable time reference. Some 210 network time synchronisation protocols (e.g. PTP [13], NTP) can 211 explicitly indicate that the master clock is providing a traceable 212 time reference over the network. 214 4. Timestamp Reference Clock Source Signalling 216 The NTP format timestamps used by RTP are taken by reading a local 217 real-time clock at the sender or receiver. This local clock may be 218 synchronised to another clock (time source) by some means or it may 219 be unsynchronised. A variety of methods are available to synchronise 220 local clocks to a reference time source, including network time 221 protocols (e.g. NTP [14], PTP [13]) and radio clocks (e.g. GPS 222 [12]). 224 The following sections describe and define SDP signalling, indicating 225 whether and how the local timestamping clock in an RTP sender/ 226 receiver is synchronised to a reference clock. 228 4.1. Clock synchronization 230 Two or more local clocks that are sufficiently synchronised will 231 produce timestamps for a given RTP event can be used as if they came 232 from the same clock. Providing they are sufficiently synchronised, 233 timestamps produced in one RTP sender or receiver can be directly 234 compared to a local clock in another RTP sender or receiver. 236 The accuracy of synchronisation required is application dependent. 237 See Applications (Section 2) section for a discussion of applications 238 and their corresponding requirements. To serve as a reference clock, 239 clocks must minimally be syntonised (exactly frequency matched) to 240 one another. 242 Sufficient synchronisation can typically be achieving by using a 243 network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to 244 synchronize all devices to a single master clock. 246 Another approach is to use clocks providing a global time reference 247 (e.g. GPS, Galileo). This concept may be used in conjunction with 248 network time protocols as some protocols (e.g. PTP, NTP) allow 249 master clocks to indicate explicitly that they are providing 250 traceable time. 252 4.2. Identifying NTP Reference Clocks 254 A single NTP server is identified by hostname (or IP address) and an 255 optional port number. If the port number is not indicated, it is 256 assumed to be the standard NTP port (123). 258 Two or more NTP servers may be listed at the same level in the 259 session description to indicate that they are interchangeable. RTP 260 senders or receivers can use any of the listed NTP servers to govern 261 a local clock that is equivalent to a local clock slaved to a 262 different server. 264 4.3. Identifying PTP Reference Clocks 266 The IEEE 1588 Precision Time Protocol (PTP) family of clock 267 synchronisation protocols provides a shared reference clock in an 268 network - typically a LAN. IEEE 1588 provides sub-microsecond 269 synchronisation between devices on a LAN and typically locks within 270 seconds at startup. With support from Ethernet switches, IEEE 1588 271 protocols can achieve nanosecond timing accuracy in LANs. Network 272 interface chips and cards supporting hardware time-stamping of timing 273 critical protocol messages are also available. 275 Three flavours of IEEE 1588 are in use today: 277 o IEEE 1588-2002 [15]: the original "Standard for a Precision Clock 278 Synchronization Protocol for Networked Measurement and Control 279 Systems". This is also known as IEEE1588v1 or PTPv1. 281 o IEEE 1588-2008 [13]: the second version of the "Standard for a 282 Precision Clock Synchronization Protocol for Networked Measurement 283 and Control Systems". This is a revised version of the original 284 IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2. 285 IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002. 287 o IEEE 802.1AS [16]: "Timing and Synchronization for Time Sensitive 288 Applications in Bridged Local Area Networks". This is a Layer-2 289 only profile of IEEE 1588-2008 for use in Audio/Video Bridged LANs 290 as described in IEEE 802.1BA-2011 [17]. 292 Each IEEE 1588 clock is identified by a globally unique EUI-64 called 293 a "ClockIdentity". A slave clock using one of the IEEE 1588 family 294 of network time protocols acquires the ClockIdentity/EUI-64 of the 295 grandmaster clock that is the ultimate source of timing information 296 for the network. A boundary clock which is itself slaved to another 297 boundary clock or the grandmaster passes the grandmaster 298 ClockIdentity through to its slaves. 300 Several instances of the IEEE 1588 protocol may operate independently 301 on a single network, forming distinct PTP domains, each of which may 302 have a different grandmaster clock. As the IEEE 1588 standards have 303 developed, the definition of PTP domains has changed. IEEE 1588-2002 304 identifies protocol subdomains by a textual name, but IEEE 1588-2008 305 identifies protocol domains using a numeric domain number. 802.1AS is 306 a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock 307 domain (0). 309 When PTP domains are signalled via SDP, senders and receivers SHOULD 310 check that both grandmaster ClockIdentity and PTP domain match when 311 determining clock equivalence. 313 The PTP protocols employ a distributed election protocol called the 314 "Best Master Clock Algorithm" (BMCA) to determine the active clock 315 master. The clock master choices available to BMCA can be restricted 316 or biased by configuration parameters to influence the election 317 process. In some systems it may be desirable to limit the number of 318 possible PTP clock masters to avoid the need to re-signal timestamp 319 clock sources when the clock master changes. 321 4.4. Identifying Global Reference Clocks 323 Global reference clocks provide a source of traceable time, typically 324 via a hardware radio receiver interface. Examples include GPS and 325 Galileo. Apart from the name of the reference clock system, no 326 further identification is required. 328 4.5. Other Reference Clocks 330 RFC 3550 allows senders and receivers to either use a local wallclock 331 reference for their NTP timestamps or, by setting the timestamp field 332 to 0, to supply no timestamps at all. Both are common practice in 333 embedded RTP implementations. These clocks are identified as "local" 334 and can only be assumed to be equivalent to clocks originating from 335 the same device. 337 In other systems, all RTP senders and receivers may use a timestamp 338 clock synchronised to a reference clock that is not provided by one 339 of the methods listed above. Examples may include the reference time 340 information provided by digital television or cellular services. 341 These sources are identified as "private" reference clocks. All RTP 342 senders and receivers in a session using a private reference clock 343 are assumed to have a mechanism outside this specification for 344 determining whether their timestamp clocks are equivalent. 346 4.6. Traceable Reference Clocks 348 A timestamp clock source may be labelled "traceable" if it is known 349 to be to delivering traceable time. Providing adjustments are made 350 for differing epochs, timezones and leap seconds, timestamps taken 351 using clocks synchronised to a traceable time source can be directly 352 compared even if the clocks are synchronised to different sources or 353 via different mechanisms. 355 Since all NTP and PTP servers providing traceable time can be 356 directly compared, it is not necessary to identify traceable time 357 servers by protocol address or other identifiers. 359 4.7. SDP Signalling of Timestamp Clock Source 361 Specification of the timestamp reference clock source may be at any 362 or all levels (session, media or source) of an SDP description (see 363 level definitions (Section 3) earlier in this document for more 364 information). 366 Timestamp clock source signalling included at session-level provides 367 default parameters for all RTP sessions and sources in the session 368 description. More specific signalling included at the media level 369 overrides default session level signalling. More specific signalling 370 included at the source level overrides default media level 371 signalling. 373 If timestamp clock source signalling is included anywhere in an SDP 374 description, it must be properly defined for all levels in the 375 description. This may simply be achieved by providing default 376 signalling at the session level. 378 Timestamp reference clock parameters may be repeated at a given level 379 (i.e. for a session or source) to provide information about 380 additional servers or clock sources. If the attribute is repeated at 381 a given level, all clocks described at that level are assumed to be 382 equivalent. Traceable time sources MUST NOT be mixed with non- 383 traceable time sources at any given level. 385 Note that clock source parameters may change from time to time, for 386 example, as a result of a PTP clock master election. The SIP [4] 387 protocol supports re-signalling of updated SDP information, however 388 other protocols may require additional notification mechanisms. 390 Figure 1 shows the ABNF [5] grammar for the SDP reference clock 391 source information. 393 timestamp-refclk = "a=ts-refclk:" clksrc CRLF 394 clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext 396 ntp = "ntp=" ntp-server-addr 397 ntp-server-addr = host [ ":" port ] 398 ntp-server-addr =/ "traceable" 400 ptp = "ptp=" ptp-version ":" ptp-server 401 ptp-version = "IEEE1588-2002" 402 ptp-version =/ "IEEE1588-2008" 403 ptp-version =/ "IEEE802.1AS-2011" 404 ptp-version =/ ptp-version-ext 405 ptp-version-ext = token 407 ptp-server = ptp-gmid [":" ptp-domain] / "traceable" 408 ptp-gmid = EUI64 409 ptp-domain = ptp-domain-name / ptp-domain-nmbr 410 ptp-domain-name = "domain-name=" 16ptp-domain-char 411 ptp-domain-char = %x21-7E / %x00 412 ; allowed characters: 0x21-0x7E (IEEE 1588-2002) 413 ptp-domain-nmbr = "domain-nmbr=" %x00-7f 414 ; allowed number range: 0-127 (IEEE 1588-2008) 416 gps = "gps" 417 gal = "gal" 418 local = "local" 419 private = "private" [ ":" "traceable" ] 421 clksrc-ext = token 423 host = hostname / IPv4address / IPv6reference 424 hostname = *( domainlabel "." ) toplabel [ "." ] 425 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 426 domainlabel = alphanum 427 / alphanum *( alphanum / "-" ) alphanum 428 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 429 IPv6reference = "[" IPv6address "]" 430 IPv6address = hexpart [ ":" IPv4address ] 431 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 432 hexseq = hex4 *( ":" hex4) 433 hex4 = 1*4HEXDIG 435 port = 1*DIGIT 437 EUI64 = 7(2HEXDIG "-") 2HEXDIG 439 Figure 1: Timestamp Reference Clock Source Signalling 441 4.7.1. Examples 443 Figure 2 shows an example SDP description with a timestamp reference 444 clock source defined at the session level. 446 v=0 447 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 448 s=SDP Seminar 449 i=A Seminar on the session description protocol 450 u=http://www.example.com/seminars/sdp.pdf 451 e=j.doe@example.com (Jane Doe) 452 c=IN IP4 233.252.0.1/64 453 t=2873397496 2873404696 454 a=recvonly 455 a=ts-refclk:ntp=traceable 456 m=audio 49170 RTP/AVP 0 457 m=video 51372 RTP/AVP 99 458 a=rtpmap:99 h263-1998/90000 460 Figure 2: Timestamp reference clock definition at the session level 462 Figure 3 shows an example SDP description with timestamp reference 463 clock definitions at the media level overriding the session level 464 defaults. Note that the synchronisation confidence timestamp appears 465 on the first attribute at the media level only. 467 v=0 468 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 469 s=SDP Seminar 470 i=A Seminar on the session description protocol 471 u=http://www.example.com/seminars/sdp.pdf 472 e=j.doe@example.com (Jane Doe) 473 c=IN IP4 233.252.0.1/64 474 t=2873397496 2873404696 475 a=recvonly 476 a=ts-refclk:local 477 m=audio 49170 RTP/AVP 0 478 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 479 a=ts-refclk:ntp=198.51.100.22 480 m=video 51372 RTP/AVP 99 481 a=rtpmap:99 h263-1998/90000 482 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 484 Figure 3: Timestamp reference clock definition at the media level 486 Figure 4 shows an example SDP description with a timestamp reference 487 clock definition at the source level overriding the session level 488 default. 490 v=0 491 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 492 s=SDP Seminar 493 i=A Seminar on the session description protocol 494 u=http://www.example.com/seminars/sdp.pdf 495 e=j.doe@example.com (Jane Doe) 496 c=IN IP4 233.252.0.1/64 497 t=2873397496 2873404696 498 a=recvonly 499 a=ts-refclk:local 500 m=audio 49170 RTP/AVP 0 501 m=video 51372 RTP/AVP 99 502 a=rtpmap:99 h263-1998/90000 503 a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 505 Figure 4: Timestamp reference clock signalling at the source level 507 5. Media Clock Source Signalling 509 The media clock source for a stream determines the timebase used to 510 advance the RTP timestamps included in RTP packets. The media clock 511 may be asynchronously generated by the sender, it may be generated in 512 fixed relationship to the reference clock or it may be generated with 513 respect to another stream on the network (which is presumably being 514 received by the sender). 516 5.1. Asynchronously Generated Media Clock 518 In the simplest sender implementation, the sender generates media by 519 sampling audio or video according to a free-running local clock. The 520 RTP timestamps in media packets are advanced according to this media 521 clock and packet transmission is typically timed to regular intervals 522 on this timeline. The sender may or may not include an NTP timestamp 523 in sender reports to allow mapping of this asynchronous media clock 524 to a reference clock. 526 The asynchronously generated media clock is the assumed mode of 527 operation when there is no signalling of media clock source. 528 Alternatively, asynchronous media clock may be explicitly signalled. 530 a=mediaclk:sender 532 5.2. Direct-Referenced Media Clock 534 A media clock may be directly derived from a reference clock. For 535 this case it is required that a reference clock be specified with an 536 a=ts-refclk attribute (Section 4.7). 538 The signalling optionally indicates a media clock offset value. The 539 offset indicates the RTP timestamp value at the epoch (time of 540 origin) of the reference clock. If no offset is signalled, the 541 offset can be inferred at the receiver by examining RTCP sender 542 reports which contain NTP and RTP timestamps which combined define a 543 mapping. 545 A rate modifier may be specified. The modifier is expressed as the 546 ratio of two integers and modifies the rate specified or implied by 547 the media description by this ratio. If omitted, the rate is assumed 548 to be the exact rate specified or implied by the media format. For 549 example, without a rate specification, the media clock for an 8 kHz 550 G.711 audio stream will advance exactly 8000 units for each second 551 advance in the reference clock from which it is derived. 553 The rate modifier is primarily useful for accommodating certain 554 "oddball" audio sample rates associated with NTSC video (see 555 Figure 7). Modified rates are not advised for video streams which 556 generally use a 90 kHz RTP clock regardless of frame rate or sample 557 rate used for embedded audio. 559 a=mediaclk:direct[=] [rate=/] 562 5.3. Stream-Referenced Media Clock 564 A common synchronisation architecture for audio/visual systems 565 involves distributing a reference media clock from a master device to 566 a number of slave devices, typically by means of a cable. Examples 567 include audio word clock distribution and video black burst 568 distribution. In this case, the media clock is locally generated, 569 often by a crystal oscillator and is not locked to a timestamp 570 reference clock. 572 To support this architecture across a network, a master clock 573 identifier is associated with an RTP media stream carrying media 574 clock timing information from a master device. The master clock 575 identifier represents a media clock source in the master device. 576 Slave devices in turn associate the master media clock identifier 577 with streams they transmit, signalling the synchronisation 578 relationship between the master and slave devices. 580 Slave devices recover media clock timing from the clock master 581 stream, using it to synchronise the slave media clock with the 582 master. Timestamps in the master clock RTP media stream are taken 583 using the timestamp reference clock shared by the master and slave 584 devices. The timestamps communicate information about media clock 585 timing (rate, phase) from the master to the slave devices. 587 Timestamps are communicated in the usual RTP fashion via RTCP SRs, or 588 via the RFC6051 [6] header extension. The stream media format may 589 indicate other clock information, such as the nominal rate. 591 Note that slaving of a device media clock to a master device does not 592 affect the usual RTP lip sync / time alignment algorithms. Time 593 aligned playout of two or more RTP sources still relies upon NTP 594 timestamps supplied via RTCP SRs or by the RFC6051 timestamp header 595 extension. 597 In a given system, master clock identifiers must be unique. Such 598 identifiers MAY be manually configured, however 17 octet string 599 identifiers SHOULD be generated according to the "short-term 600 persistent RTCP CNAME" algorithm as described in RFC6222 [7]. 602 A reference stream can be an RTP stream or AVB stream based on the 603 IEEE 1722 [18] standard. 605 An RTP clock master stream SHOULD be identified at the source level 606 by an SSRC and master clock identifier. If master clock identifiers 607 are declared at the media or session level, all RTP sources at or 608 below the level of declaration MUST provide equivalent timing to a 609 slave receiver. 611 a=ssrc: mediaclk:master-id= 614 An RTP media sender indicates that it is slaved to a clock master via 615 a clock master identifier: 617 a=mediaclk:master-id= 619 An RTP media sender indicates that it is slaved to an IEEE 1722 clock 620 master via a stream identifier (an EUI-64): 622 a=mediaclk:IEEE1722= 624 5.4. SDP Signalling of Media Clock Source 626 Specification of the media clock source may be at any or all levels 627 (session, media or source) of an SDP description (see level 628 definitions (Section 3) earlier in this document for more 629 information). 631 Media clock source signalling included at session level provides 632 default parameters for all RTP sessions and sources in the session 633 description. More specific signalling included at the media level 634 overrides default session level signalling. Further, source-level 635 signalling overrides media clock source signalling at the enclosing 636 media level and session level. 638 Media clock source signalling may be present or absent on a per- 639 stream basis. In the absence of media clock source signals, 640 receivers assume an asynchronous media clock generated by the sender. 642 Media clock source parameters may be repeated at a given level (i.e. 643 for a session or source) to provide information about additional 644 clock sources. If the attribute is repeated at a given level, all 645 clocks described at that level are comparable clock sources and may 646 be used interchangeably. 648 Figure 5 shows the ABNF [5] grammar for the SDP media clock source 649 information. 651 mediaclk-master = "a=ssrc:" integer SP clk-master-id 653 clk-master-id = "mediaclk:master-id=" master-id 655 timestamp-mediaclk = "a=mediaclk:" mediaclock 657 mediaclock = sender / refclk / streamid / mediaclock-ext 659 sender = "sender" sender-ext 661 sender-ext = token 663 refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] 665 rate = [ SP "rate=" integer "/" integer ] 667 direct-ext = token 669 streamid = "master-id=" master-id 670 streamid =/ "IEEE1722=" avb-stream-id 671 streamid =/ streamid-ext 673 master-id = EUI48 674 avb-stream-id = EUI64 676 EUI48 = 5(2HEXDIG ":") 2HEXDIG 677 EUI64 = 7(2HEXDIG ":") 2HEXDIG 679 streamid-ext = token 681 mediaclock-ext = token 682 Figure 5: Media Clock Source Signalling 684 5.5. Examples 686 Figure 6 shows an example SDP description 8 channels of 24-bit, 48 687 kHz audio transmitted as a multicast stream. Media clock is derived 688 directly from an IEEE 1588-2008 reference. 690 v=0 691 o=- 1311738121 1311738121 IN IP4 192.0.2.1 692 c=IN IP4 233.252.0.1/64 693 s= 694 t=0 0 695 m=audio 5004 RTP/AVP 96 696 a=rtpmap:96 L24/48000/8 697 a=sendonly 698 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 699 a=mediaclk:direct=963214424 701 Figure 6: Media clock directly referenced to IEEE 1588-2008 703 Figure 7 shows an example SDP description 2 channels of 24-bit, 44056 704 kHz NTSC "pull-down" media clock derived directly from an IEEE 1588- 705 2008 reference clock 707 v=0 708 o=- 1311738121 1311738121 IN IP4 192.0.2.1 709 c=IN IP4 233.252.0.1/64 710 s= 711 t=0 0 712 m=audio 5004 RTP/AVP 96 713 a=rtpmap:96 L24/44100/2 714 a=sendonly 715 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 716 a=mediaclk:direct=963214424 rate=1000/1001 718 Figure 7: "Oddball" sample rate directly referenced to IEEE 1588-2008 720 Figure 8 shows the same 48 kHz audio transmission from Figure 6 with 721 media clock derived from another RTP stream. 723 v=0 724 o=- 1311738121 1311738121 IN IP4 192.0.2.1 725 c=IN IP4 233.252.0.1/64 726 s= 727 t=0 0 728 m=audio 5004 RTP/AVP 96 729 a=rtpmap:96 L24/48000/2 730 a=sendonly 731 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 732 a=mediaclk:master-id=00:60:2b:20:12:1f 734 Figure 8: RTP stream with media clock slaved to a master device 736 Figure 9 shows the same 48 kHz audio transmission from Figure 6 with 737 media clock derived from an IEEE 1722 AVB stream. 739 v=0 740 o=- 1311738121 1311738121 IN IP4 192.0.2.1 741 c=IN IP4 233.252.0.1/64 742 s= 743 t=0 0 744 m=audio 5004 RTP/AVP 96 745 a=rtpmap:96 L24/48000/2 746 a=sendonly 747 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 748 a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F 750 Figure 9: RTP stream with media clock slaved to an IEEE1722 master 751 device 753 6. Signalling considerations 755 Signaling for timestamp clock source (Section 4.7) and media clock 756 source (Section 5.4) is defined to be used either by applications 757 that implement the SDP Offer/Answer model [8] or by applications that 758 use SDP to describe media and transport configurations. 760 A description or offer may include reference clock signalling, media 761 clock signalling or both. If no reference clock is specified, the 762 direct-referenced media clock (Section 5.2) is not allowed. If no 763 media clock is specified, an asynchronous media clock (Section 5.1) 764 is assumed. stream-referenced media clock (Section 5.3) may be used 765 with or without a reference clock specification. If a reference 766 clock is not signalled, the stream may be established as rate 767 synchronized however time synchronisation is not guaranteed. 769 6.1. Usage in Offer/Answer 771 An answer to an offer with direct-referenced media clock and 772 reference clock specification must include the same media clock and 773 reference clock signalling in which case a connection is established 774 using the specified synchronisation. Alternatively the answer may 775 omit both the signals or return only the reference clock 776 specification. In this case, a connection is established assuming an 777 asynchronous media clock. 779 An answer to an offer with media-referenced media clock specification 780 must include the same media clock specification. The answer MUST 781 include the same reference clock signalling or may drop the reference 782 clock signalling. If reference clock signalling is not present in 783 the answer, either due to not being present in the offer or due to 784 being dropped by the answerer, the stream may be established as rate 785 synchronized but not time synchronized. 787 An asynchronous media clock is the default media clock mode. This 788 mode may be explicitly signalled or presumed due to lack of 789 signalling. Asynchronous media clocking does not require reference 790 clock signalling. An offer with asynchronous media clocking MAY 791 include reference clock signalling. Because the asynchronous media 792 clock is the default mode, the answerer is not required to explicitly 793 signal this even if it is explicitly signalled in the offer. 795 6.2. Usage Outside of Offer/Answer 797 SDP can be employed outside of the Offer/Answer context, for instance 798 for multimedia sessions that are announced through the Session 799 Announcement Protocol (SAP) [19], or streamed through the Real Time 800 Streaming Protocol (RTSP) [20]. The signaling model is simpler, as 801 the sender does not negotiate parameters, but the functionality 802 expected from specifying medial clock and reference clock attributes 803 is the same as in Offer/Answer. 805 7. Security Considerations 807 Entities receiving and acting upon an SDP message SHOULD be aware 808 that a session description cannot be trusted unless it has been 809 obtained by an authenticated transport protocol from a known and 810 trusted source. Many different transport protocols may be used to 811 distribute session description, and the nature of the authentication 812 will differ from transport to transport. For some transports, 813 security features are often not deployed. In case a session 814 description has not been obtained in a trusted manner, the endpoint 815 SHOULD exercise care because, among other attacks, the media sessions 816 received may not be the intended ones, the destination where media is 817 sent to may not be the expected one, any of the parameters of the 818 session may be incorrect. 820 Incorrect reference or media clock parameters may cause devices or 821 streams to synchronize to unintended clock sources. Normally this 822 simply results in failure to make a media connection or failure to 823 synchronize once connected. Enough devices fraudulently assigned to 824 a specific clock source (e.g. a particular IEEE 1588 grandmaster) 825 may, however, constitute a successful a denial of service attack on 826 that source. Devices MAY wish to validate the integrity of the clock 827 description through some means before connecting to unfamiliar clock 828 sources. 830 8. IANA Considerations 832 The SDP attribute "ts-refclk" defined by this document is registered 833 with the IANA registry of SDP Parameters as follows: 835 SDP Attribute ("att-field"): 837 Attribute name: ts-refclk 839 Long form: Timestamp reference clock source 841 Type of name: att-field 843 Type of attribute: session, media and source level 845 Subject to charset: no 847 Purpose: See section 4 of this document 849 Reference: This document 851 Values: see this document and registrations below 853 The attribute has an extensible parameter field and therefore a 854 registry for these parameters is required. This document creates an 855 IANA registry called the Timestamp Reference Clock Source Parameters 856 Registry. It contains the six parameters defined in Figure 1: "ntp", 857 "ptp", "gps", "gal", "local", "private". 859 The SDP attribute "mediaclk" defined by this document is registered 860 with the IANA registry of SDP Parameters as follows: 862 SDP Attribute ("att-field"): 864 Attribute name: mediaclk 866 Long form: Media clock source 868 Type of name: att-field 870 Type of attribute: session and media level 872 Subject to charset: no 874 Purpose: See section 5 of this document 876 Reference: This document 878 Values: see this document and registrations below 880 The attribute has an extensible parameter field and therefore a 881 registry for these parameters is required. This document creates an 882 IANA registry called the Media Clock Source Parameters Registry. It 883 contains the three parameters defined in Figure 5: "sender", 884 "direct", "master", "slave" and "IEEE1722". 886 9. References 888 9.1. Normative References 890 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 891 Levels", BCP 14, RFC 2119, March 1997. 893 [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 894 Description Protocol", RFC 4566, July 2006. 896 [3] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media 897 Attributes in the Session Description Protocol (SDP)", 898 RFC 5576, June 2009. 900 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 901 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 902 Session Initiation Protocol", RFC 3261, June 2002. 904 [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax 905 Specifications: ABNF", STD 68, RFC 5234, January 2008. 907 [6] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 908 Flows", RFC 6051, November 2010. 910 [7] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing 911 RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", 912 RFC 6222, April 2011. 914 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 915 Session Description Protocol (SDP)", RFC 3264, June 2002. 917 9.2. Informative References 919 [9] Society of Motion Picture & Television Engineers, "Television 920 and Audio - Synchronization of 59.94- or 50-Hz Related Video 921 and Audio Systems in Analog and Digital Areas - Reference 922 Signals", . 924 [10] Audio Engineering Society, "AES11-2009: AES recommended 925 practice for digital audio engineering - Synchronization of 926 digital audio equipment in studio operations", 927 . 929 [11] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., 930 Montagud, M., and K. Gross, "Inter-destination Media 931 Synchronization using the RTP Control Protocol (RTCP)", 932 draft-ietf-avtcore-idms-07 (work in progress), October 2012. 934 [12] Global Positioning Systems Directorate, "Navstar GPS Space 935 Segment/Navigation User Segment Interfaces", September 2011. 937 [13] Institute of Electrical and Electronics Engineers, "1588-2008 - 938 IEEE Standard for a Precision Clock Synchronization Protocol 939 for Networked Measurement and Control Systems", IEEE Std 1588- 940 2008, 2008, 941 . 943 [14] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time 944 Protocol Version 4: Protocol and Algorithms Specification", 945 RFC 5905, June 2010. 947 [15] Institute of Electrical and Electronics Engineers, "1588-2002 - 948 IEEE Standard for a Precision Clock Synchronization Protocol 949 for Networked Measurement and Control Systems", IEEE Std 1588- 950 2002, 2002, 951 . 953 [16] Institute of Electrical and Electronics Engineers, "Timing and 954 Synchronization for Time-Sensitive Applications in Bridged 955 Local Area Networks", 956 . 959 [17] Institute of Electrical and Electronics Engineers, "Audio Video 960 Bridging (AVB) Systems", 961 . 964 [18] Institute of Electrical and Electronics Engineers, "IEEE 965 Standard for Layer 2 Transport Protocol for Time Sensitive 966 Applications in a Bridged Local Area Network", 967 . 969 [19] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 970 Protocol", RFC 2974, October 2000. 972 [20] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 973 Protocol (RTSP)", RFC 2326, April 1998. 975 URIs 977 [21] 980 Authors' Addresses 982 Aidan Williams 983 Audinate 984 Level 1, 458 Wattle St 985 Ultimo, NSW 2007 986 Australia 988 Phone: +61 2 8090 1000 989 Fax: +61 2 8090 1001 990 Email: aidan.williams@audinate.com 991 URI: http://www.audinate.com/ 993 Kevin Gross 994 AVA Networks 995 Boulder, CO 996 US 998 Email: kevin.gross@avanw.com 999 URI: http://www.avanw.com/ 1000 Ray van Brandenburg 1001 TNO 1002 Brassersplein 2 1003 Delft 2612CT 1004 the Netherlands 1006 Phone: +31-88-866-7000 1007 Email: ray.vanbrandenburg@tno.nl 1009 Hans Stokking 1010 TNO 1011 Brassersplein 2 1012 Delft 2612CT 1013 the Netherlands 1015 Email: hans.stokking@tno.nl