idnits 2.17.1 draft-ietf-avtcore-clksrc-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. -- 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 25, 2014) is 3683 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588-2002' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588-2008' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1722' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1AS-2011' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-08) exists of draft-ietf-avtcore-leap-second-07 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 26, 2014 R. van Brandenburg 7 H. Stokking 8 TNO 9 March 25, 2014 11 RTP Clock Source Signalling 12 draft-ietf-avtcore-clksrc-11 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 [RFC2119]. 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 26, 2014. 45 Copyright Notice 47 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 6 66 4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 6 67 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 7 68 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 7 69 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 9 70 4.5. Private Reference Clocks . . . . . . . . . . . . . . . . . 9 71 4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . . 9 72 4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . . 9 73 4.8. SDP Signalling of Timestamp Reference Clock Source . . . . 10 74 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 75 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 13 76 5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13 77 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 13 78 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 15 79 5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 16 80 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6. Signalling Considerations . . . . . . . . . . . . . . . . . . 20 82 6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 20 83 6.1.1. Indicating Support for Clock Source Signalling . . . . 21 84 6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 21 85 6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 21 86 6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 22 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 23 90 8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 24 91 8.3. Timestamp Reference Clock Source Parameters Registry . . . 24 92 8.4. Media Clock Source Parameters Registry . . . . . . . . . . 25 93 8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 26 94 8.5.1. Source-level Timestamp Reference Clock Attribute . . . 26 95 8.5.2. Source-level Media Clock Attribute . . . . . . . . . . 26 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 102 1. Introduction 104 RTP protocols use NTP format timestamps to facilitate multimedia 105 session synchronisation and for providing estimates of round trip 106 time (RTT) and other statistical parameters. 108 Information about media clock timing exchanged in NTP format 109 timestamps may come from a clock which is synchronised to a global 110 time reference, but this cannot be assumed nor is there a 111 standardised mechanism available to indicate that timestamps are 112 derived from a common reference clock. Therefore, RTP 113 implementations typically assume that NTP timestamps are taken using 114 unsynchronised clocks and must compensate for absolute time 115 differences and rate differences. Without a shared reference clock, 116 RTP can time align flows from the same source at a given receiver 117 using relative timing, however tight synchronisation between two or 118 more different receivers (possibly with different network paths) or 119 between two or more senders is not possible. 121 High performance AV systems often use a reference media clock 122 distributed to all devices in the system. The reference media clock 123 is often distinct from the reference clock used to provide 124 timestamps. A reference media clock may be provided along with an 125 audio or video signal interface, or via a dedicated clock signal 126 (e.g. genlock [SMPTE-318-1999] or audio word clock [AES11-2009]). If 127 sending and receiving media clocks are known to be synchronised to a 128 common reference clock, performance can improved by minimising 129 buffering and avoiding rate conversion. 131 This specification defines SDP signalling of timestamp reference 132 clock sources and media reference clock sources. 134 2. Applications 136 Timestamp reference clock source and media clock signalling benefit 137 applications requiring synchronised media capture or playout and low 138 latency operation. 140 Examples include, but are not limited to: 142 Social TV : RTCP for inter-destination media synchronization 143 [I-D.ietf-avtcore-idms] defines social TV as the combination of 144 media content consumption by two or more users at different 145 devices and locations and real-time communication between those 146 users. An example of Social TV, is where two or more users are 147 watching the same television broadcast at different devices and/or 148 locations, while communicating with each other using text, audio 149 and/or video. A skew in the media playout of the two or more 150 users can have adverse effects on their experience. A well-known 151 use case here is one friend experiencing a goal in a football 152 match well before or after other friends. 154 Video Walls : A video wall consists of multiple computer monitors, 155 video projectors, or television sets tiled together contiguously 156 or overlapped in order to form one large screen. Each of the 157 screens reproduces a portion of the larger picture. In some 158 implementations, each screen or projector may be individually 159 connected to the network and receive its portion of the overall 160 image from a network-connected video server or video scaler. 161 Screens are refreshed at 50 or 60 hertz or potentially faster. If 162 the refresh is not synchronized, the effect of multiple screens 163 acting as one is broken. 165 Networked Audio : Networked loudspeakers, amplifiers and analogue 166 I/O devices transmitting or receiving audio signals via RTP can be 167 connected to various parts of a building or campus network. Such 168 situations can for example be found in large conference rooms, 169 legislative chambers, classrooms (especially those supporting 170 distance learning) and other large-scale environments such as 171 stadiums. Since humans are more susceptible to differences in 172 audio delay, this use case needs even more accuracy than the video 173 wall use case. Depending on the exact application, the need for 174 accuracy can then be in the range of microseconds [Olsen]. 176 Sensor Arrays : Sensor arrays contain many synchronised measurement 177 elements producing signals which are then combined to form an 178 overall measurement. Accurate capture of the phase relationships 179 between the various signals arriving at each element of the array 180 is critically important for proper operation. Examples include 181 towed or fixed sonar arrays, seismic arrays and phased arrays used 182 in radar applications, for instance. 184 3. Definitions 186 The following definitions are used in this draft: 188 media level : Media level information applies to a single SDP media 189 stream. In an SDP description, media-level information appears 190 after each "m"-line. 192 multimedia session : A set of multimedia senders and receivers as 193 well as the data streams flowing from senders to receivers. The 194 Session Description Protocol (SDP) [RFC4566] describes multimedia 195 sessions. 197 RTP media stream : A single stream of RTP packets identified by an 198 RTP SSRC. 200 RTP media sender : The device generating an associated RTP media 201 stream 203 SDP media stream : An RTP session potentially containing more than 204 one RTP source. SDP media descriptions beginning with an "m"-line 205 define the parameters of an SDP media stream. 207 session level : Session level information applies to an entire 208 multimedia session. In an SDP description, session-level 209 information appears before the first "m"-line. 211 source level : Source level information applies to a specific RTP 212 media stream. Source-Specific Media Attributes in the Session 213 Description Protocol (SDP) [RFC5576] defines how source-level 214 information is included into an SDP session description. 216 traceable time : A clock is considered to provide traceable time if 217 it can be proven to be synchronised to International Atomic Time 218 (TAI). Coordinated Universal Time (UTC) is a time standard 219 synchronized to TAI. UTC is therefore also considered traceable 220 time once leap seconds have been taken unto account. GPS 221 [IS-GPS-200F] is commonly used to provide a TAI traceable time 222 reference. Some network time synchronisation protocols (e.g. PTP 223 [IEEE1588-2008], NTP) can explicitly indicate that the master 224 clock is providing a traceable time reference over the network. 226 4. Timestamp Reference Clock Source Signalling 228 The NTP format timestamps used by RTP are taken by reading a local 229 real-time clock at the sender or receiver. This local clock may be 230 synchronised to another clock (time source) by some means or it may 231 be unsynchronised. A variety of methods are available to synchronise 232 local clocks to a reference time source, including network time 233 protocols (e.g. NTP [RFC5905], PTP [IEEE1588-2008]) and radio clocks 234 (e.g. GPS [IS-GPS-200F]). 236 The following sections describe and define SDP signalling, indicating 237 whether and how the local timestamping clock in an RTP sender/ 238 receiver is synchronised to a reference clock. 240 4.1. Clock synchronization 242 Two or more local clocks that are sufficiently synchronised will 243 produce timestamps for a given RTP event can be used as if they came 244 from the same clock. Providing they are sufficiently synchronised, 245 timestamps produced in one RTP sender or receiver can be directly 246 compared to a local clock in another RTP sender or receiver. 248 The accuracy of synchronisation required is application dependent. 249 See Applications (Section 2) section for a discussion of applications 250 and their corresponding requirements. To serve as a reference clock, 251 clocks must minimally be syntonized (exactly frequency matched) to 252 one another. 254 Sufficient synchronisation can typically be achieving by using a 255 network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to 256 synchronize all devices to a single master clock. 258 Another approach is to use clocks providing a global time reference 259 (e.g. GPS, Galileo, GLONASS). This concept may be used in 260 conjunction with network time protocols as some protocols (e.g. PTP, 261 NTP) allow master clocks to indicate explicitly that they are 262 providing traceable time. 264 4.2. Identifying NTP Reference Clocks 266 A single NTP server is identified by hostname (or IP address) and an 267 optional port number. If the port number is not indicated, it is 268 assumed to be the standard NTP port (123). 270 Two or more NTP servers MAY be listed at the same level in the 271 session description to indicate that all of the listed servers 272 deliver the same reference time and may be used interchangeably. RTP 273 senders and receivers are assured proper synchronization regardless 274 of which server they choose and, in support of fault tolerance, may 275 switch servers while streaming. 277 4.3. Identifying PTP Reference Clocks 279 The IEEE 1588 Precision Time Protocol (PTP) family of clock 280 synchronisation protocols provides a shared reference clock in an 281 network - typically a LAN. IEEE 1588 provides sub-microsecond 282 synchronisation between devices on a LAN and typically locks within 283 seconds at startup. With support from Ethernet switches, IEEE 1588 284 protocols can achieve nanosecond timing accuracy in LANs. Network 285 interface chips and cards supporting hardware time-stamping of timing 286 critical protocol messages are also available. 288 Three flavours of IEEE 1588 are in use today: 290 o IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a 291 Precision Clock Synchronization Protocol for Networked Measurement 292 and Control Systems". This is also known as IEEE1588v1 or PTPv1. 294 o IEEE 1588-2008 [IEEE1588-2008]: the second version of the 295 "Standard for a Precision Clock Synchronization Protocol for 296 Networked Measurement and Control Systems". This is a revised 297 version of the original IEEE1588-2002 standard and is also known 298 as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible 299 with IEEE 1588-2002. 301 o IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for 302 Time Sensitive Applications in Bridged Local Area Networks". This 303 is a Layer-2 only profile of IEEE 1588-2008 for use in Audio/Video 304 Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011]. 306 Each IEEE 1588 clock is identified by an EUI-64 called a 307 "ClockIdentity". A slave clock using one of the IEEE 1588 family of 308 network time protocols acquires the ClockIdentity/EUI-64 of the 309 grandmaster clock that is the ultimate source of timing information 310 for the network. A boundary clock which is itself slaved to another 311 boundary clock or the grandmaster passes the grandmaster 312 ClockIdentity through to its slaves. 314 Several instances of the IEEE 1588 protocol may operate independently 315 on a single network, forming distinct PTP domains, each of which may 316 have a different grandmaster clock. As the IEEE 1588 standards have 317 developed, the definition of PTP domains has changed. IEEE 1588-2002 318 identifies protocol subdomains by a textual name, but IEEE 1588-2008 319 identifies protocol domains using a numeric domain number. 802.1AS is 320 a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock 321 domain (0). 323 When PTP domains are signalled via SDP, senders and receivers SHOULD 324 check that both grandmaster ClockIdentity and PTP domain match when 325 determining clock equivalence. 327 Two or more IEEE 1588 clocks MAY be listed at the same level in the 328 session description to indicate that all of the listed clocks are 329 candidate grandmaster clocks for the domain or deliver the same 330 reference time and may be used interchangeably. RTP senders and 331 receivers are assured proper synchronization regardless of which 332 synchronization source they choose and, in support of fault 333 tolerance, may switch reference clock source while streaming. 335 The PTP protocols employ a distributed election protocol called the 336 "Best Master Clock Algorithm" (BMCA) to determine the active clock 337 master. The clock master choices available to BMCA can be restricted 338 or biased by configuration parameters to influence the election 339 process. In some systems it may be desirable to limit the number of 340 possible PTP clock masters to avoid the need to re-signal timestamp 341 reference clock sources when the clock master changes. 343 4.4. Identifying Global Reference Clocks 345 Global reference clocks provide a source of traceable time, typically 346 via a hardware radio receiver interface. Examples include GPS, 347 Galileo and GLONASS. Apart from the name of the reference clock 348 system, no further identification is required. 350 4.5. Private Reference Clocks 352 In other systems, all RTP senders and receivers may use a timestamp 353 reference clock that is not provided by one of the methods listed 354 above. Examples may include the reference time information provided 355 by digital television or cellular services. These sources are 356 identified as "private" reference clocks. All RTP senders and 357 receivers in a session using a private reference clock are assumed to 358 have a mechanism outside this specification for determining whether 359 their timestamp reference clocks are equivalent. 361 4.6. Local Reference Clocks 363 RFC 3550 allows senders and receivers to either use a local wall 364 clock reference for their NTP timestamps or, by setting the timestamp 365 field to 0, to supply no timestamps at all. Both are common practice 366 in embedded RTP implementations. These clocks are identified as 367 "local" and can only be assumed to be equivalent to clocks 368 originating from the same device. 370 4.7. Traceable Reference Clocks 372 A timestamp reference clock source may be labelled "traceable" if it 373 is known to be to delivering traceable time. Providing adjustments 374 are made for differing epochs, timezones and leap seconds, timestamps 375 taken using clocks synchronised to a traceable time source can be 376 directly compared even if the clocks are synchronised to different 377 sources or via different mechanisms. 379 Marking a clock as traceable allows additional information (e.g. IP 380 addresses, PTP master identifiers and the like) to be omitted from 381 the SDP since any traceable clock available at the answerer is 382 considered to be an appropriate timestamp reference clock. For 383 example, an offerer could could specify ts-refclk:ntp=/traceable/ and 384 the answerer could use GPS as a reference clock since GPS is a source 385 of traceable time. 387 4.8. SDP Signalling of Timestamp Reference Clock Source 389 Specification of the timestamp reference clock source may be at any 390 or all levels (session, media or source) of an SDP description (see 391 level definitions (Section 3) earlier in this document for more 392 information). 394 Timestamp reference clock source signalling included at session-level 395 provides default parameters for all RTP sessions and sources in the 396 session description. More specific signalling included at the media 397 level overrides default session level signalling. More specific 398 signalling included at the source level overrides default media level 399 signalling. 401 If timestamp reference clock source signalling is included anywhere 402 in an SDP description, it must be properly defined for all levels in 403 the 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 time sources MUST NOT be mixed with non- 411 traceable time sources at any given level. 413 Note that clock source parameters may change from time to time, for 414 example, as a result of a PTP clock master election. The SIP 415 [RFC3261] protocol supports re-signalling of updated SDP information, 416 however other protocols may require additional notification 417 mechanisms. 419 General forms of usage: 421 session level: a=ts-refclk: 423 media level: a=ts-refclk: 425 source level: a=ssrc: ts-refclk: 427 ABNF [RFC5234] grammar for the timestamp reference clock attribute: 428 ; external references: 429 POS-DIGIT = 430 token = 431 byte-string = 432 DIGIT = 433 HEXDIG = 434 CRLF = 435 hostport = 437 timestamp-refclk = "ts-refclk:" clksrc CRLF 439 clksrc = ntp / ptp / gps / gal / glonass / local / private / clksrc-ext 441 clksrc-ext = clksrc-param-name clksrc-param-value 442 clksrc-param-name = token 443 clksrc-param-value = ["=" byte-string ] 445 ntp = "ntp=" ntp-server-addr 446 ntp-server-addr = hostport / "/traceable/" 448 ptp = "ptp=" ptp-version ":" ptp-server 449 ptp-version = "IEEE1588-2002" 450 / "IEEE1588-2008" 451 / "IEEE802.1AS-2011" 452 / ptp-version-ext 453 ptp-version-ext = token 455 ptp-server = ptp-gmid [":" ptp-domain] 456 / "traceable" 457 ptp-gmid = EUI64 458 ptp-domain = ptp-domain-name / ptp-domain-nmbr 460 ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) 461 ptp-domain-name = "domain-name=" 1*16ptp-domain-char 462 ptp-domain-char = %x21-7E 464 ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) 465 ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts 466 ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 467 ptp-domain-n1 = DIGIT ; 0-9 468 ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 469 ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 470 / "12" %x30-37 ; 120-127 472 gps = "gps" 473 gal = "gal" 474 glonass = "glonass" 475 local = "local" 476 private = "private" [ ":traceable" ] 478 EUI64 = 7(2HEXDIG "-") 2HEXDIG 480 Figure 1: Timestamp Reference Clock Source Signalling 482 4.8.1. Examples 484 Figure 2 shows an example SDP description with a timestamp reference 485 clock source defined at the session level. 487 v=0 488 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 489 s=SDP Seminar 490 i=A Seminar on the session description protocol 491 u=http://www.example.com/seminars/sdp.pdf 492 e=j.doe@example.com (Jane Doe) 493 c=IN IP4 233.252.0.1/64 494 t=2873397496 2873404696 495 a=recvonly 496 a=ts-refclk:ntp=/traceable/ 497 m=audio 49170 RTP/AVP 0 498 m=video 51372 RTP/AVP 99 499 a=rtpmap:99 h263-1998/90000 501 Figure 2: Timestamp reference clock definition at the session level 503 Figure 3 shows an example SDP description with timestamp reference 504 clock definitions at the media level overriding the session level 505 defaults. 507 v=0 508 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 509 s=SDP Seminar 510 i=A Seminar on the session description protocol 511 u=http://www.example.com/seminars/sdp.pdf 512 e=j.doe@example.com (Jane Doe) 513 c=IN IP4 233.252.0.1/64 514 t=2873397496 2873404696 515 a=recvonly 516 a=ts-refclk:local 517 m=audio 49170 RTP/AVP 0 518 a=ts-refclk:ntp=203.0.113.10 519 a=ts-refclk:ntp=198.51.100.22 520 m=video 51372 RTP/AVP 99 521 a=rtpmap:99 h263-1998/90000 522 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 524 Figure 3: Timestamp reference clock definition at the media level 526 Figure 4 shows an example SDP description with a timestamp reference 527 clock definition at the source level overriding the session level 528 default. 530 v=0 531 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 532 s=SDP Seminar 533 i=A Seminar on the session description protocol 534 u=http://www.example.com/seminars/sdp.pdf 535 e=j.doe@example.com (Jane Doe) 536 c=IN IP4 233.252.0.1/64 537 t=2873397496 2873404696 538 a=recvonly 539 a=ts-refclk:local 540 m=audio 49170 RTP/AVP 0 541 m=video 51372 RTP/AVP 99 542 a=rtpmap:99 h263-1998/90000 543 a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 545 Figure 4: Timestamp reference clock signalling at the source level 547 5. Media Clock Source Signalling 549 The media clock source for a stream determines the timebase used to 550 advance the RTP timestamps included in RTP packets. The media clock 551 may be asynchronously generated by the sender, it may be generated in 552 fixed relationship to the reference clock or it may be generated with 553 respect to another stream on the network (which is presumably being 554 received by the sender). 556 5.1. Asynchronously Generated Media Clock 558 In the simplest sender implementation, the sender generates media by 559 sampling audio or video according to a free-running local clock. The 560 RTP timestamps in media packets are advanced according to this media 561 clock and packet transmission is typically timed to regular intervals 562 on this timeline. The sender may or may not include an NTP timestamp 563 in sender reports to allow mapping of this asynchronous media clock 564 to a reference clock. 566 The asynchronously generated media clock is the assumed mode of 567 operation when there is no signalling of media clock source. 568 Alternatively, asynchronous media clock may be explicitly signalled. 570 a=mediaclk:sender 572 5.2. Direct-Referenced Media Clock 574 A media clock may be directly derived from a reference clock. For 575 this case it is required that a reference clock be specified with an 576 a=ts-refclk attribute (Section 4.8). 578 The signalling optionally indicates a media clock offset value. The 579 offset indicates the RTP timestamp value at the epoch (time of 580 origin) of the reference clock. To use the offset, implementations 581 need to compute RTP timestamps from reference clocks. To simplify 582 these calculations, streams utilizing offset signalling SHOULD use a 583 TAI timestamp reference clock to avoid complications introduced by 584 leap seconds. See [I-D.ietf-avtcore-leap-second] for further 585 discussion of leap-second issues in timestamp reference clocks. 587 To compute the RTP timestamp against an IEEE 1588 (TAI-based) 588 reference, the time elapsed between the 00:00:00 1 January 1970 IEEE 589 1588 epoch and the current time must be computed. Between the epoch 590 and 1 January 2013, there were 15,706 days (including extra days 591 during leap years). Since there are no leap seconds in a TAI 592 reference, there are exactly 86,400 seconds during each of these days 593 or a total of 1,356,998,400 seconds from the epoch to 00:00:00 1 594 January 2013. A 90 kHz RTP clock for a video stream would have 595 advanced 122,129,856,000,000 units over this period. With a 596 signalled offset of 0, the RTP clock value modulo the 32-bit unsigned 597 representation in the RTP header would have been 2,460,938,240 at 00: 598 00:00 1 January 2013. If an offset of 23,465 had been signalled, the 599 clock value would have been 2,460,961,705. 601 In order to use an NTP reference, the actual time elapsed between the 602 00:00:00, 1 January 1900 NTP epoch to the current time must be 603 computed. 2,208,988,800 seconds elapsed between the NTP epoch and 00: 604 00:00 1 January 1970 [RFC0868]. Between the beginning of 1970 and 605 2013, there were 15,706 days elapsed (including extra days during 606 leap years) and 25 leap seconds inserted. There is therefore a total 607 of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1 January 608 2013. A 90 kHz RTP clock for a video stream would have advanced 609 320,938,850,250,000 units over this period. With a signalled offset 610 of 0, the RTP clock value modulo the 32-bit unsigned representation 611 would have been 1,714,023,696 at 00:00:00 1 January 2013. 613 If no offset is signalled, the offset can be inferred at the receiver 614 by examining RTCP sender reports which contain NTP and RTP timestamps 615 which combined define a mapping. The NTP/RTP timestamp mapping 616 provided by RTCP SRs takes precedence over that singaled through SDP, 617 however the media clock rate implied by the SRs MUST be consistent 618 with the rate signalled. 620 A rate modifier may be specified. The modifier is expressed as the 621 ratio of two integers and modifies the rate specified or implied by 622 the media description by this ratio. If omitted, the rate is assumed 623 to be the exact rate specified or implied by the media format. For 624 example, without a rate specification, the RTP clock for an 8 kHz 625 G.711 audio stream will advance exactly 8000 units for each second 626 advance in the reference clock from which it is derived. 628 The rate modifier is primarily useful for accommodating certain 629 "oddball" audio sample rates associated with NTSC video (see 630 Figure 7). Modified rates are not advised for video streams which 631 generally use a 90 kHz RTP clock regardless of frame rate or sample 632 rate used for embedded audio. 634 a=mediaclk:direct[=] [rate=/] 637 5.3. Stream-Referenced Media Clock 639 A common synchronisation architecture for audio/visual systems 640 involves distributing a reference media clock from a master device to 641 a number of slave devices, typically by means of a cable. Examples 642 include audio word clock distribution and video black burst 643 distribution. In this case, the media clock is locally generated, 644 often by a crystal oscillator and is not locked to a timestamp 645 reference clock. 647 To support this architecture across a network, a master clock 648 identifier is associated with an RTP media stream carrying media 649 clock timing information from a master device. The master clock 650 identifier represents a media clock source in the master device. 651 Slave devices in turn associate the master media clock identifier 652 with streams they transmit, signalling the synchronisation 653 relationship between the master and the transmitter's media clock. 655 Slave devices recover media clock timing from the clock master 656 stream, using it to synchronise the slave media clock with the 657 master. Timestamps in the master clock RTP media stream are taken 658 using the timestamp reference clock shared by the master and slave 659 devices. The timestamps communicate information about media clock 660 timing (rate, phase) from the master to the slave devices. 661 Timestamps are communicated in the usual RTP fashion via RTCP SRs, or 662 via the RFC6051 [RFC6051] header extension. The stream media format 663 may indicate other clock information, such as the nominal rate. 665 Note that slaving of a device media clock to a master device does not 666 affect the usual RTP lip sync / time alignment algorithms. Time 667 aligned playout of two or more RTP sources still relies upon NTP 668 timestamps supplied via RTCP SRs or by the RFC6051 timestamp header 669 extension. 671 In a given system, master clock identifiers must uniquely identify a 672 single media clock source. Such identifiers MAY be manually 673 configured, however identifiers SHOULD be generated according to the 674 "short-term persistent RTCP CNAME" algorithm as described in RFC7022 675 [RFC7022]. Master clock identifiers not already in base64 format 676 MUST be encoded as a base64 strings when used in SDP. Although the 677 RTCP CNAME algorithm is used to generate the master clock identifier, 678 it is used to tag RTP sources in SDP descriptions and does not appear 679 in RTCP as a CNAME. 681 A reference stream can be an RTP stream or AVB stream based on the 682 IEEE 1722 [IEEE1722] standard. 684 An RTP clock master stream SHOULD be identified at the source level 685 by an SSRC [RFC5576] and master clock identifier. An RTP stream that 686 provides media clock timing directly from a reference media clock 687 (e.g. internal crystal, audio word clock or video blackburst signal) 688 SHOULD tag the stream as a master clock source using the "src:" 689 prefix. If master clock identifiers are declared at the media or 690 session level, all RTP sources at or below the level of declaration 691 MUST provide equivalent timing to a slave receiver. 693 a=ssrc: mediaclk:id=src: sender 695 a=mediaclk:id=src: sender 697 A transmitted RTP stream slaved to media clock master is signalled by 698 including master clock identifier: 700 a=mediaclk:id= sender 702 An RTP media sender indicates that it is slaved to an IEEE 1722 clock 703 master via a stream identifier (an EUI-64): 705 a=mediaclk:IEEE1722= 707 An RTP media sender may gateway IEEE 1722 media clock timing to RTP: 709 a=mediaclk:id=src: IEEE1722= 711 5.4. SDP Signalling of Media Clock Source 713 Specification of the media clock source may be at any or all levels 714 (session, media or source) of an SDP description (see level 715 definitions (Section 3) earlier in this document for more 716 information). 718 Media clock source signalling included at session level provides 719 default parameters for all RTP sessions and sources in the session 720 description. More specific signalling included at the media level 721 overrides default session level signalling. Further, source-level 722 signalling overrides media clock source signalling at the enclosing 723 media level and session level. 725 Media clock source signalling may be present or absent on a per- 726 stream basis. In the absence of media clock source signals, 727 receivers assume an asynchronous media clock generated by the sender. 729 Media clock source parameters may be repeated at a given level (i.e. 730 for a session or source) to provide information about additional 731 clock sources. If the attribute is repeated at a given level, all 732 clocks described at that level are comparable clock sources and may 733 be used interchangeably. 735 General forms of usage: 737 session level: a=mediaclk: 739 media level: a=mediaclk: 741 source level: a=ssrc: mediaclk: 742 ABNF [RFC5234] grammar for the media clock reference attribute: 743 ; external references: 744 integer = 745 token = 746 byte-string = 747 base64 = 748 SP = 749 DIGIT = 750 HEXDIG = 752 media-clksrc = "mediaclk:" [media-clkid SP] mediaclock 754 media-clkid = "id=" [ "src:" ] media-clktag 755 media-clktag = base64 757 mediaclock = sender / direct / ieee1722-streamid / mediaclock-ext 759 mediaclock-ext = mediaclock-param-name mediaclock-param-value 760 mediaclock-param-name = token 761 mediaclock-param-value = [ "=" byte-string ] 763 sender = "sender" 764 direct = "direct" [ "=" 1*DIGIT ] [SP rate] 765 rate = "rate=" integer "/" integer 767 ieee1722-streamid = "IEEE1722=" avb-stream-id 768 avb-stream-id = EUI64 769 EUI64 = 7(2HEXDIG "-") 2HEXDIG 771 Figure 5: Media Clock Source Signalling 773 5.5. Examples 775 Figure 6 shows an example SDP description 8 channels of 24-bit, 48 776 kHz audio transmitted as a multicast stream. Media clock is derived 777 directly from an IEEE 1588-2008 reference. 779 v=0 780 o=- 1311738121 1311738121 IN IP4 192.0.2.1 781 c=IN IP4 233.252.0.1/64 782 s= 783 t=0 0 784 m=audio 5004 RTP/AVP 96 785 a=rtpmap:96 L24/48000/8 786 a=sendonly 787 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 788 a=mediaclk:direct=963214424 790 Figure 6: Media clock directly referenced to IEEE 1588-2008 792 Figure 7 shows an example SDP description 2 channels of 24-bit, 44056 793 kHz NTSC "pull-down" media clock derived directly from an IEEE 1588- 794 2008 reference clock 796 v=0 797 o=- 1311738121 1311738121 IN IP4 192.0.2.1 798 c=IN IP4 233.252.0.1/64 799 s= 800 t=0 0 801 m=audio 5004 RTP/AVP 96 802 a=rtpmap:96 L24/44100/2 803 a=sendonly 804 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 805 a=mediaclk:direct=963214424 rate=1000/1001 807 Figure 7: "Oddball" sample rate directly referenced to IEEE 1588-2008 809 Figure 8 shows the same 48 kHz audio transmission from Figure 6 with 810 media clock derived from another RTP stream. 812 v=0 813 o=- 1311738121 1311738121 IN IP4 192.0.2.1 814 c=IN IP4 233.252.0.1/64 815 s= 816 t=0 0 817 m=audio 5004 RTP/AVP 96 818 a=rtpmap:96 L24/48000/2 819 a=sendonly 820 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 821 a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender 823 Figure 8: RTP stream with media clock slaved to a master 825 Figure 9 shows the same 48 kHz audio transmission from Figure 6 with 826 media clock derived from an IEEE 1722 AVB stream. 828 v=0 829 o=- 1311738121 1311738121 IN IP4 192.0.2.1 830 c=IN IP4 233.252.0.1/64 831 s= 832 t=0 0 833 m=audio 5004 RTP/AVP 96 834 a=rtpmap:96 L24/48000/2 835 a=sendonly 836 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 837 a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F 839 Figure 9: RTP stream with media clock slaved to an IEEE1722 master 840 device 842 6. Signalling Considerations 844 Signalling of timestamp reference clock source (Section 4.8) and 845 media clock source (Section 5.4) is defined to be used either by 846 applications that implement the SDP Offer/Answer model [RFC3264] or 847 by applications that use SDP to describe media and transport 848 configurations. 850 A description SHOULD include both reference clock signalling and 851 media clock signalling. If no reference clock is available, this 852 SHOULD be signalled as a local reference (Section 4.6). 854 When no media clock signalling is present, an asynchronous media 855 clock (Section 5.1) MUST be assumed. When no reference clock 856 signalling is present, a local reference clock (Section 4.6) MUST be 857 assumed. 859 If a reference clock is not signalled or a local reference is 860 specified, the corresponding media clock may be established as rate 861 synchronised with no assurance of time synchronisation. 863 When the description signals a direct-referenced media clock 864 (Section 5.2), reference clock signalling is REQUIRED. Asynchronous 865 and stream-referenced media clocks (Section 5.3) MAY be specified 866 with or without a reference clock signalling. 868 6.1. Usage in Offer/Answer 870 During offer/answer, clock source signalling via SDP uses a 871 declarative model. Supported media and/or reference clocks are 872 specified in the offered SDP description. The answerer may accept or 873 reject the offer in an application-specific way depending on the 874 clocks that are available and the clocks that are offered. For 875 example, an answerer may choose to accept an offer that lacks a 876 common clock by falling back to a lower performance mode of operation 877 (e.g. by assuming reference or media clocks are local rather than 878 shared). Conversely, the answerer may choose to reject the offer 879 when the offered clock specifications indicate that the available 880 reference and/or media clocks are incompatible. 882 While negotiation of reference clock and media clock attributes is 883 not defined in this document, negotiation MAY be accomplished using 884 the capabilities negotiation procedures defined in [RFC5939]. 886 6.1.1. Indicating Support for Clock Source Signalling 888 An offerer or answerer indicates support for media clock signalling 889 by including a reference or media clock specification in the SDP 890 description. An offerer or answerer without specific reference or 891 media clocks to signal SHOULD indicate support for clock source 892 signalling by including a local reference clock (Section 4.6) 893 specification in the SDP description. 895 6.1.2. Timestamp Reference Clock 897 If one or more of the reference clocks specified in the offer are 898 usable by the answerer, the answerer SHOULD respond with an answer 899 containing the subset of reference clock specifications in the offer 900 that are usable by the answerer. If the answerer rejects the offer 901 because the available reference clocks are incompatible, the 902 rejection MUST contain at least one timestamp reference clock 903 specification usable by the answerer so that appropriate information 904 is available for debugging. If no external reference clock is 905 available to the answerer a local reference clock (Section 4.6) 906 specification SHOULD be included in the rejection. 908 In both offers and answers, multiple reference clock specifications 909 indicate equivalent clocks from different sources which may be used 910 interchangeably. RTP senders and receivers are assured proper 911 synchronization regardless of which of the specified sources is 912 chosen and, in support of fault tolerance, may switch clock sources 913 while streaming. 915 6.1.3. Media Clock 917 If the media clock mode specified in the offer is acceptable to the 918 answerer, the answerer SHOULD respond with an answer containing the 919 same media clock specification as the offer. If the answerer rejects 920 the offer because the available reference clocks are incompatible, 921 the rejection MUST contain a media clock specification supported by 922 the answerer so that appropriate information is available for 923 debugging. If no shared media clocks are available to the answerer 924 an asynchronous media clock (Section 5.1) specification SHOULD be 925 included in the rejection. 927 6.2. Usage Outside of Offer/Answer 929 SDP can be employed outside of the Offer/Answer context, for instance 930 for multimedia sessions that are announced through the Session 931 Announcement Protocol (SAP) [RFC2974], or streamed through the Real 932 Time Streaming Protocol (RTSP) [RFC2326]. 934 Devices using published descriptions to join sessions SHOULD assess 935 their synchronization compatibility with the described session based 936 on the clock source signalling and SHOULD NOT attempt to join a 937 session with incompatible reference or media clocks. 939 7. Security Considerations 941 Entities receiving and acting upon an SDP message should note that a 942 session description cannot be trusted unless it has been obtained by 943 an authenticated transport protocol from a known and trusted source. 944 Many different transport protocols may be used to distribute session 945 description, and the nature of the authentication will differ from 946 transport to transport. For some transports, security features are 947 often not deployed. In case a session description has not been 948 obtained in a trusted manner, the endpoint should exercise care 949 because, among other attacks, the media sessions received may not be 950 the intended ones, the destination where media is sent to may not be 951 the expected one, any of the parameters of the session may be 952 incorrect. 954 Incorrect reference or media clock parameters may cause devices or 955 streams to synchronize to unintended clock sources. Normally this 956 simply results in failure to establish a session or failure to 957 synchronize once connected. Enough devices fraudulently assigned to 958 a specific clock source (e.g. a particular IEEE 1588 grandmaster) 959 may, however, constitute a successful denial of service attack on 960 that source. Devices MAY wish to validate the integrity of the clock 961 description through some means before connecting to unfamiliar clock 962 sources. 964 The timestamp reference clocks negotiated by this protocol are used 965 to provide media timing information to RTP. Negotiated timestamp 966 reference clocks should not be relied upon to provide a secure time 967 reference for security critical operations (e.g. the expiration of 968 public key certificates). 970 8. IANA Considerations 972 This document defines two new SDP attributes: 'ts-refclk' and 973 'mediaclk', within the existing Internet Assigned Numbers Authority 974 (IANA) registry of SDP Parameters. 976 This document also defines a new IANA registry subordinate to the 977 IANA SDP Parameters registry: the Media Clock Source Parameters 978 Registry. Within this new registry, this document defines an initial 979 set of three media clock source parameters. Further, this document 980 defines a second new IANA registry subordinate to the IANA SDP 981 Parameters registry: the Timestamp Reference Clock Source Parameters 982 Registry. Within this new registry, this document defines an initial 983 six parameters. 985 8.1. Reference Clock SDP Parameter 987 The SDP attribute "ts-refclk" defined by this document is registered 988 with the IANA registry of SDP Parameters as follows: 990 SDP Attributes ( "att-field (both session and media level)" & 991 "att-field (source level)" ): 993 Attribute name: ts-refclk 995 Long form: Timestamp reference clock source 997 Type of name: att-field 999 Type of attribute: Session, media and source level 1001 Subject to charset: No 1003 Purpose: See section 4 of this document 1005 Reference: This document 1007 Values: See section 8.3 of this document 1009 Figure 10 1011 The attribute has an extensible parameter field and therefore a 1012 registry for these parameters is required. This new registry is 1013 defined in Section 8.3. 1015 8.2. Media Clock SDP Parameter 1017 The SDP attribute "mediaclk" defined by this document is registered 1018 with the IANA registry of SDP Parameters as follows: 1020 SDP Attributes ( "att-field (both session and media level)" & 1021 "att-field (source level)" ): 1023 Attribute name: mediaclk 1025 Long form: Media clock source 1027 Type of name: att-field 1029 Type of attribute: Session, media and source level 1031 Subject to charset: No 1033 Purpose: See section 5 of this document 1035 Reference: This document 1037 Values: See section 8.4 of this document 1039 Figure 11 1041 The attribute has an extensible parameter field and therefore a 1042 registry for these parameters is required. The new registry is 1043 defined in Section 8.4. 1045 8.3. Timestamp Reference Clock Source Parameters Registry 1047 This document creates a new IANA sub-registry called the Timestamp 1048 Reference Clock Source Parameters Registry, subordinate to the IANA 1049 SDP Parameters registry. Each entry in the Timestamp Reference Clock 1050 Source Parameters Registry contains: 1052 Name: Token used in the SDP description (clksrc-param-name) 1054 Long name: Descriptive name for the timestamp reference clock source 1056 Reference: Reference to the document describing the SDP token 1057 (clksrc-param-name) and syntax for the optional value associated 1058 with the token (mediaclock-param-value) 1060 Initial values for the Timestamp Reference Clock Source Parameters 1061 registry are given below. 1063 Future assignments are to be made through the Specification Required 1064 policy [RFC5226]. The Name field in the table corresponds to a new 1065 value corresponding to clksrc-param-name. The Reference must specify 1066 a syntax corresponding to clksrc-param-value. 1068 +---------+--------------------------------+------------------------+ 1069 | Name | Long Name | Reference | 1070 +---------+--------------------------------+------------------------+ 1071 | ntp | Network Time Protocol | This document, section | 1072 | | | 4 | 1073 | ptp | Precision Time Protocol | This document, section | 1074 | | | 4 | 1075 | gps | Global Position System | This document, section | 1076 | | | 4 | 1077 | gal | Galileo | This document, section | 1078 | | | 4 | 1079 | glonass | Global Navigation Satellite | This document, section | 1080 | | System | 4 | 1081 | local | Local Clock | This document, section | 1082 | | | 4 | 1083 | private | Private Clock | This document, section | 1084 | | | 4 | 1085 +---------+--------------------------------+------------------------+ 1087 8.4. Media Clock Source Parameters Registry 1089 This document creates a new IANA sub-registry called the Media Clock 1090 Source Parameters registry, subordinate to the IANA SDP Parameters 1091 registry. Each entry in the Media Clock Source Parameters Registry 1092 contains: 1094 Name: Token used in the SDP description (mediaclock-param-name) 1096 Long name: Descriptive name for the media clock source type 1098 Reference: Reference to the document describing the SDP token 1099 (mediaclock-param-name) and syntax for the optional value 1100 associated with the token (mediaclock-param-value) 1102 Initial values for the Media Clock Source Parameters registry are 1103 given below. 1105 Future assignments are to be made through the Specification Required 1106 policy [RFC5226]. The Name field in the table corresponds to a new 1107 value corresponding to mediaclock-param-name. The Reference must 1108 specify a syntax corresponding to mediaclock-param-value. 1110 +----------+--------------------------------+-----------------------+ 1111 | Name | Long Name | Reference | 1112 +----------+--------------------------------+-----------------------+ 1113 | sender | Asynchronously Generated Media | This document, | 1114 | | Clock | section 5 | 1115 | direct | Direct-Referenced Media Clock | This document, | 1116 | | | section 5 | 1117 | IEEE1722 | IEEE1722 Media Stream | This document, | 1118 | | Identifier | section 5 | 1119 +----------+--------------------------------+-----------------------+ 1121 8.5. Source-level Attributes 1123 [RFC5576] requires new source-level attributes to be registered with 1124 the IANA registry named "att-field (source level)". 1126 8.5.1. Source-level Timestamp Reference Clock Attribute 1128 The source-level SDP attribute "ts-refclk" defined by this document 1129 is registered with the "att-field (source level)" IANA registry of 1130 SDP Parameters according to Figure 10. 1132 8.5.2. Source-level Media Clock Attribute 1134 The source-level SDP attribute "mediaclk" defined by this document is 1135 registered with the "att-field (source level)" IANA registry of SDP 1136 Parameters according to Figure 11. 1138 9. Acknowledgements 1140 The authors would like to thank Magnus Westerlund and Paul Kyzivat 1141 for valuable comments which resulted in important improvements to 1142 this document. 1144 10. References 1146 10.1. Normative References 1148 [IEEE1588-2002] 1149 Institute of Electrical and Electronics Engineers, "1588- 1150 2002 - IEEE Standard for a Precision Clock Synchronization 1151 Protocol for Networked Measurement and Control Systems", 1152 IEEE Std 1588-2002, 2002, . 1155 [IEEE1588-2008] 1156 Institute of Electrical and Electronics Engineers, "1588- 1157 2008 - IEEE Standard for a Precision Clock Synchronization 1158 Protocol for Networked Measurement and Control Systems", 1159 IEEE Std 1588-2008, 2008, . 1162 [IEEE1722] 1163 Institute of Electrical and Electronics Engineers, "IEEE 1164 Standard for Layer 2 Transport Protocol for Time Sensitive 1165 Applications in a Bridged Local Area Network", . 1168 [IEEE802.1AS-2011] 1169 Institute of Electrical and Electronics Engineers, "Timing 1170 and Synchronization for Time-Sensitive Applications in 1171 Bridged Local Area Networks", . 1174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1175 Requirement Levels", BCP 14, RFC 2119, March 1997. 1177 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1178 with Session Description Protocol (SDP)", RFC 3264, 1179 June 2002. 1181 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1182 Description Protocol", RFC 4566, July 2006. 1184 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1185 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1186 May 2008. 1188 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1189 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1191 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1192 Media Attributes in the Session Description Protocol 1193 (SDP)", RFC 5576, June 2009. 1195 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1196 Time Protocol Version 4: Protocol and Algorithms 1197 Specification", RFC 5905, June 2010. 1199 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 1200 Flows", RFC 6051, November 2010. 1202 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1203 "Guidelines for Choosing RTP Control Protocol (RTCP) 1204 Canonical Names (CNAMEs)", RFC 7022, September 2013. 1206 10.2. Informative References 1208 [AES11-2009] 1209 Audio Engineering Society, "AES11-2009: AES recommended 1210 practice for digital audio engineering - Synchronization 1211 of digital audio equipment in studio operations", 1212 . 1214 [I-D.ietf-avtcore-idms] 1215 Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., 1216 Montagud, M., and K. Gross, "Inter-destination Media 1217 Synchronization using the RTP Control Protocol (RTCP)", 1218 draft-ietf-avtcore-idms-13 (work in progress), 1219 August 2013. 1221 [I-D.ietf-avtcore-leap-second] 1222 Gross, K. and R. Brandenburg, "RTP and Leap Seconds", 1223 draft-ietf-avtcore-leap-second-07 (work in progress), 1224 December 2013. 1226 [IEEE802.1BA-2011] 1227 Institute of Electrical and Electronics Engineers, "Audio 1228 Video Bridging (AVB) Systems", . 1231 [IS-GPS-200F] 1232 Global Positioning Systems Directorate, "Navstar GPS Space 1233 Segment/Navigation User Segment Interfaces", 1234 September 2011. 1236 [Olsen] Olsen, D., "Time Accuracy Requirements in Audio Networks", 1237 April 2007, . 1240 [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, 1241 RFC 868, May 1983. 1243 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1244 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1246 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1247 Announcement Protocol", RFC 2974, October 2000. 1249 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1250 A., Peterson, J., Sparks, R., Handley, M., and E. 1251 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1252 June 2002. 1254 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 1255 Capability Negotiation", RFC 5939, September 2010. 1257 [SMPTE-318-1999] 1258 Society of Motion Picture & Television Engineers, 1259 "Television and Audio - Synchronization of 59.94- or 50-Hz 1260 Related Video and Audio Systems in Analog and Digital 1261 Areas - Reference Signals", . 1263 Authors' Addresses 1265 Aidan Williams 1266 Audinate 1267 Level 1, 458 Wattle St 1268 Ultimo, NSW 2007 1269 Australia 1271 Phone: +61 2 8090 1000 1272 Fax: +61 2 8090 1001 1273 Email: aidan.williams@audinate.com 1274 URI: http://www.audinate.com/ 1276 Kevin Gross 1277 AVA Networks 1278 Boulder, CO 1279 US 1281 Email: kevin.gross@avanw.com 1282 URI: http://www.avanw.com/ 1284 Ray van Brandenburg 1285 TNO 1286 Brassersplein 2 1287 Delft 2612CT 1288 the Netherlands 1290 Phone: +31-88-866-7000 1291 Email: ray.vanbrandenburg@tno.nl 1292 Hans Stokking 1293 TNO 1294 Brassersplein 2 1295 Delft 2612CT 1296 the Netherlands 1298 Email: hans.stokking@tno.nl