idnits 2.17.1 draft-ietf-avtcore-clksrc-05.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 (July 14, 2013) is 3939 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 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6222 (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 (Obsoleted by RFC 7826) Summary: 3 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: January 15, 2014 R. van Brandenburg 7 H. Stokking 8 TNO 9 July 14, 2013 11 RTP Clock Source Signalling 12 draft-ietf-avtcore-clksrc-05 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 January 15, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . 9 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 . . . . . . . . . . . . . . 14 78 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14 79 5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 15 80 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19 82 6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19 83 6.1.1. Indicating Support for Clock Source Signalling . . . . 20 84 6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20 85 6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20 86 6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22 90 8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 22 91 8.3. Timestamp Reference Clock Source Parameters Registry . . . 23 92 8.4. Media Clock Source Parameters Registry . . . . . . . . . . 24 93 8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 24 94 8.5.1. Source-level Reference Clock Attribute . . . . . . . . 24 95 8.5.2. Source-level Media Clock Attribute . . . . . . . . . . 24 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 RTP protocols use NTP format timestamps to facilitate multimedia 104 session synchronisation and for providing estimates of round trip 105 time (RTT) and other statistical parameters. 107 Information about media clock timing exchanged in NTP format 108 timestamps may come from a clock which is synchronised to a global 109 time reference, but this cannot be assumed nor is there a 110 standardised mechanism available to indicate that timestamps are 111 derived from a common reference clock. Therefore, RTP 112 implementations typically assume that NTP timestamps are taken using 113 unsynchronised clocks and must compensate for absolute time 114 differences and rate differences. Without a shared reference clock, 115 RTP can time align flows from the same source at a given receiver 116 using relative timing, however tight synchronisation between two or 117 more different receivers (possibly with different network paths) or 118 between two or more senders is not possible. 120 High performance AV systems often use a reference media clock 121 distributed to all devices in the system. The reference media clock 122 is often distinct from the reference clock used to provide 123 timestamps. A reference media clock may be provided along with an 124 audio or video signal interface, or via a dedicated clock signal 125 (e.g. genlock [SMPTE-318-1999] or audio word clock [AES11-2009]). If 126 sending and receiving media clocks are known to be synchronised to a 127 common reference clock, performance can improved by minimising 128 buffering and avoiding rate conversion. 130 This specification defines SDP signalling of timestamp reference 131 clock sources and media reference clock sources. 133 2. Applications 135 Timestamp reference clock source and media clock signalling benefit 136 applications requiring synchronised media capture or playout and low 137 latency operation. 139 Examples include, but are not limited to: 141 Social TV : RTCP for inter-destination media synchronization 142 [I-D.ietf-avtcore-idms] defines social TV as the combination of 143 media content consumption by two or more users at different 144 devices and locations and real-time communication between those 145 users. An example of Social TV, is where two or more users are 146 watching the same television broadcast at different devices and/or 147 locations, while communicating with each other using text, audio 148 and/or video. A skew in the media playout of the two or more 149 users can have adverse effects on their experience. A well-known 150 use case here is one friend experiencing a goal in a football 151 match well before or after other friends. 153 Video Walls : A video wall consists of multiple computer monitors, 154 video projectors, or television sets tiled together contiguously 155 or overlapped in order to form one large screen. Each of the 156 screens reproduces a portion of the larger picture. In some 157 implementations, each screen or projector may be individually 158 connected to the network and receive its portion of the overall 159 image from a network-connected video server or video scaler. 160 Screens are refreshed at 50 or 60 hertz or potentially faster. If 161 the refresh is not synchronized, the effect of multiple screens 162 acting as one is broken. 164 Networked Audio : Networked loudspeakers, amplifiers and analogue 165 I/O devices transmitting or receiving audio signals via RTP can be 166 connected to various parts of a building or campus network. Such 167 situations can for example be found in large conference rooms, 168 legislative chambers, classrooms (especially those supporting 169 distance learning) and other large-scale environments such as 170 stadiums. Since humans are more susceptible to differences in 171 audio delay, this use case needs even more accuracy than the video 172 wall use case. Depending on the exact application, the need for 173 accuracy can then be in the range of microseconds [1]. 175 Sensor Arrays : Sensor arrays contain many synchronised measurement 176 elements producing signals which are then combined to form an 177 overall measurement. Accurate capture of the phase relationships 178 between the various signals arriving at each element of the array 179 is critically important for proper operation. Examples include 180 towed or fixed sonar arrays, seismic arrays and phased arrays used 181 in radar applications, for instance. 183 3. Definitions 185 The following definitions are used in this draft: 187 media level : Media level information applies to a single SDP media 188 stream. In an SDP description, media-level information appears 189 after each "m"-line. 191 multimedia session : A set of multimedia senders and receivers as 192 well as the data streams flowing from senders to receivers. The 193 Session Description Protocol (SDP) [RFC4566] describes multimedia 194 sessions. 196 RTP media stream : A single stream of RTP packets identified by an 197 RTP SSRC. 199 RTP media sender : The device generating an associated RTP media 200 stream 202 SDP media stream : An RTP session potentially containing more than 203 one RTP source. SDP media descriptions beginning with an "m"-line 204 define the parameters of an SDP media stream. 206 session level : Session level information applies to an entire 207 multimedia session. In an SDP description, session-level 208 information appears before the first "m"-line. 210 source level : Source level information applies to a RTP media 211 stream Source-Specific Media Attributes in the Session Description 212 Protocol (SDP) [RFC5576] defines how source-level information is 213 included into an SDP session description. 215 traceable time : A clock is considered to provide traceable time if 216 it can be proven to be synchronised to International Atomic Time 217 (TAI). Coordinated Universal Time (UTC) is a time standard 218 synchronized to TAI. UTC is therefore also considered traceable 219 time once leap seconds have been taken unto account. GPS 220 [IS-GPS-200F] is commonly used to provide a TAI traceable time 221 reference. Some network time synchronisation protocols (e.g. PTP 222 [IEEE1588-2008], NTP) can explicitly indicate that the master 223 clock is providing a traceable time reference over the network. 225 4. Timestamp Reference Clock Source Signalling 227 The NTP format timestamps used by RTP are taken by reading a local 228 real-time clock at the sender or receiver. This local clock may be 229 synchronised to another clock (time source) by some means or it may 230 be unsynchronised. A variety of methods are available to synchronise 231 local clocks to a reference time source, including network time 232 protocols (e.g. NTP [RFC5905], PTP [IEEE1588-2008]) and radio clocks 233 (e.g. GPS [IS-GPS-200F]). 235 The following sections describe and define SDP signalling, indicating 236 whether and how the local timestamping clock in an RTP sender/ 237 receiver is synchronised to a reference clock. 239 4.1. Clock synchronization 241 Two or more local clocks that are sufficiently synchronised will 242 produce timestamps for a given RTP event can be used as if they came 243 from the same clock. Providing they are sufficiently synchronised, 244 timestamps produced in one RTP sender or receiver can be directly 245 compared to a local clock in another RTP sender or receiver. 247 The accuracy of synchronisation required is application dependent. 248 See Applications (Section 2) section for a discussion of applications 249 and their corresponding requirements. To serve as a reference clock, 250 clocks must minimally be syntonised (exactly frequency matched) to 251 one another. 253 Sufficient synchronisation can typically be achieving by using a 254 network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to 255 synchronize all devices to a single master clock. 257 Another approach is to use clocks providing a global time reference 258 (e.g. GPS, Galileo). This concept may be used in conjunction with 259 network time protocols as some protocols (e.g. PTP, NTP) allow 260 master clocks to indicate explicitly that they are providing 261 traceable time. 263 4.2. Identifying NTP Reference Clocks 265 A single NTP server is identified by hostname (or IP address) and an 266 optional port number. If the port number is not indicated, it is 267 assumed to be the standard NTP port (123). 269 Two or more NTP servers MAY be listed at the same level in the 270 session description to indicate that all of the listed servers 271 deliver the same reference time and may be used interchangeably. RTP 272 senders and receivers are assured proper synchronization regardless 273 of which server they choose and, in support of fault tolerance, may 274 switch servers while streaming. 276 4.3. Identifying PTP Reference Clocks 278 The IEEE 1588 Precision Time Protocol (PTP) family of clock 279 synchronisation protocols provides a shared reference clock in an 280 network - typically a LAN. IEEE 1588 provides sub-microsecond 281 synchronisation between devices on a LAN and typically locks within 282 seconds at startup. With support from Ethernet switches, IEEE 1588 283 protocols can achieve nanosecond timing accuracy in LANs. Network 284 interface chips and cards supporting hardware time-stamping of timing 285 critical protocol messages are also available. 287 Three flavours of IEEE 1588 are in use today: 289 o IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a 290 Precision Clock Synchronization Protocol for Networked Measurement 291 and Control Systems". This is also known as IEEE1588v1 or PTPv1. 293 o IEEE 1588-2008 [IEEE1588-2008]: the second version of the 294 "Standard for a Precision Clock Synchronization Protocol for 295 Networked Measurement and Control Systems". This is a revised 296 version of the original IEEE1588-2002 standard and is also known 297 as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible 298 with IEEE 1588-2002. 300 o IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for 301 Time Sensitive Applications in Bridged Local Area Networks". This 302 is a Layer-2 only profile of IEEE 1588-2008 for use in Audio/Video 303 Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011]. 305 Each IEEE 1588 clock is identified by a globally unique EUI-64 called 306 a "ClockIdentity". A slave clock using one of the IEEE 1588 family 307 of network time protocols acquires the ClockIdentity/EUI-64 of the 308 grandmaster clock that is the ultimate source of timing information 309 for the network. A boundary clock which is itself slaved to another 310 boundary clock or the grandmaster passes the grandmaster 311 ClockIdentity through to its slaves. 313 Several instances of the IEEE 1588 protocol may operate independently 314 on a single network, forming distinct PTP domains, each of which may 315 have a different grandmaster clock. As the IEEE 1588 standards have 316 developed, the definition of PTP domains has changed. IEEE 1588-2002 317 identifies protocol subdomains by a textual name, but IEEE 1588-2008 318 identifies protocol domains using a numeric domain number. 802.1AS is 319 a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock 320 domain (0). 322 When PTP domains are signalled via SDP, senders and receivers SHOULD 323 check that both grandmaster ClockIdentity and PTP domain match when 324 determining clock equivalence. 326 Two or more IEEE 1588 clocks MAY be listed at the same level in the 327 session description to indicate that all of the listed clocks are 328 candidate grandmaster clocks for the domain or deliver the same 329 reference time and may be used interchangeably. RTP senders and 330 receivers are assured proper synchronization regardless of which 331 synchronization source they choose and, in support of fault 332 tolerance, may switch refence clock source while streaming. 334 The PTP protocols employ a distributed election protocol called the 335 "Best Master Clock Algorithm" (BMCA) to determine the active clock 336 master. The clock master choices available to BMCA can be restricted 337 or biased by configuration parameters to influence the election 338 process. In some systems it may be desirable to limit the number of 339 possible PTP clock masters to avoid the need to re-signal timestamp 340 reference clock sources when the clock master changes. 342 4.4. Identifying Global Reference Clocks 344 Global reference clocks provide a source of traceable time, typically 345 via a hardware radio receiver interface. Examples include GPS and 346 Galileo. Apart from the name of the reference clock system, no 347 further identification is required. 349 4.5. Private Reference Clocks 351 In other systems, all RTP senders and receivers may use a timestamp 352 reference clock that is not provided by one of the methods listed 353 above. Examples may include the reference time information provided 354 by digital television or cellular services. These sources are 355 identified as "private" reference clocks. All RTP senders and 356 receivers in a session using a private reference clock are assumed to 357 have a mechanism outside this specification for determining whether 358 their timestamp reference clocks are equivalent. 360 4.6. Local Reference Clocks 362 RFC 3550 allows senders and receivers to either use a local wallclock 363 reference for their NTP timestamps or, by setting the timestamp field 364 to 0, to supply no timestamps at all. Both are common practice in 365 embedded RTP implementations. These clocks are identified as "local" 366 and can only be assumed to be equivalent to clocks originating from 367 the same device. 369 4.7. Traceable Reference Clocks 371 A timestamp reference clock source may be labelled "traceable" if it 372 is known to be to delivering traceable time. Providing adjustments 373 are made for differing epochs, timezones and leap seconds, timestamps 374 taken using clocks synchronised to a traceable time source can be 375 directly compared even if the clocks are synchronised to different 376 sources or via different mechanisms. 378 Since all NTP and PTP servers providing traceable time can be 379 directly compared, it is not necessary to identify traceable time 380 servers by protocol address or other identifiers. 382 4.8. SDP Signalling of Timestamp Reference Clock Source 384 Specification of the timestamp reference clock source may be at any 385 or all levels (session, media or source) of an SDP description (see 386 level definitions (Section 3) earlier in this document for more 387 information). 389 Timestamp reference clock source signalling included at session-level 390 provides default parameters for all RTP sessions and sources in the 391 session description. More specific signalling included at the media 392 level overrides default session level signalling. More specific 393 signalling included at the source level overrides default media level 394 signalling. 396 If timestamp reference clock source signalling is included anywhere 397 in an SDP description, it must be properly defined for all levels in 398 the description. This may simply be achieved by providing default 399 signalling at the session level. 401 Timestamp reference clock parameters may be repeated at a given level 402 (i.e. for a session or source) to provide information about 403 additional servers or clock sources. If the attribute is repeated at 404 a given level, all clocks described at that level are assumed to be 405 equivalent. Traceable time sources MUST NOT be mixed with non- 406 traceable time sources at any given level. 408 Note that clock source parameters may change from time to time, for 409 example, as a result of a PTP clock master election. The SIP 410 [RFC3261] protocol supports re-signalling of updated SDP information, 411 however other protocols may require additional notification 412 mechanisms. "refclk-sl" is used to describe a reference clock at the 413 source level. "refclk" is used to describe a reference clock at 414 session or media levels. 416 Figure 1 shows the ABNF [RFC5234] grammar for the SDP reference clock 417 source information. 419 refclk-sl = "a=ssrc:" integer SP timestamp-refclk 421 timestamp-refclk = "a=ts-refclk:" clksrc CRLF 422 clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext 424 ntp = "ntp=" ntp-server-addr 425 ntp-server-addr = host [ ":" port ] 426 ntp-server-addr =/ "traceable" 428 ptp = "ptp=" ptp-version ":" ptp-server 429 ptp-version = "IEEE1588-2002" 430 ptp-version =/ "IEEE1588-2008" 431 ptp-version =/ "IEEE802.1AS-2011" 432 ptp-version =/ ptp-version-ext 433 ptp-version-ext = token 435 ptp-server = ptp-gmid [":" ptp-domain] / "traceable" 436 ptp-gmid = EUI64 437 ptp-domain = ptp-domain-name / ptp-domain-nmbr 438 ptp-domain-name = "domain-name=" 16ptp-domain-char 439 ptp-domain-char = %x21-7E / %x00 440 ; allowed characters: 0x21-0x7E (IEEE 1588-2002) 441 ptp-domain-nmbr = "domain-nmbr=" %x00-7f 442 ; allowed number range: 0-127 (IEEE 1588-2008) 444 gps = "gps" 445 gal = "gal" 446 local = "local" 447 private = "private" [ ":" "traceable" ] 449 clksrc-ext = token 451 host = hostname / IPv4address / IPv6reference 452 hostname = *( domainlabel "." ) toplabel [ "." ] 453 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 454 domainlabel = alphanum 455 / alphanum *( alphanum / "-" ) alphanum 456 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 457 IPv6reference = "[" IPv6address "]" 458 IPv6address = hexpart [ ":" IPv4address ] 459 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 460 hexseq = hex4 *( ":" hex4) 461 hex4 = 1*4HEXDIG 463 port = 1*DIGIT 465 EUI64 = 7(2HEXDIG "-") 2HEXDIG 466 Figure 1: Timestamp Reference Clock Source Signalling 468 4.8.1. Examples 470 Figure 2 shows an example SDP description with a timestamp reference 471 clock source defined at the session level. 473 v=0 474 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 475 s=SDP Seminar 476 i=A Seminar on the session description protocol 477 u=http://www.example.com/seminars/sdp.pdf 478 e=j.doe@example.com (Jane Doe) 479 c=IN IP4 233.252.0.1/64 480 t=2873397496 2873404696 481 a=recvonly 482 a=ts-refclk:ntp=traceable 483 m=audio 49170 RTP/AVP 0 484 m=video 51372 RTP/AVP 99 485 a=rtpmap:99 h263-1998/90000 487 Figure 2: Timestamp reference clock definition at the session level 489 Figure 3 shows an example SDP description with timestamp reference 490 clock definitions at the media level overriding the session level 491 defaults. 493 v=0 494 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 495 s=SDP Seminar 496 i=A Seminar on the session description protocol 497 u=http://www.example.com/seminars/sdp.pdf 498 e=j.doe@example.com (Jane Doe) 499 c=IN IP4 233.252.0.1/64 500 t=2873397496 2873404696 501 a=recvonly 502 a=ts-refclk:local 503 m=audio 49170 RTP/AVP 0 504 a=ts-refclk:ntp=203.0.113.10 505 a=ts-refclk:ntp=198.51.100.22 506 m=video 51372 RTP/AVP 99 507 a=rtpmap:99 h263-1998/90000 508 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 510 Figure 3: Timestamp reference clock definition at the media level 512 Figure 4 shows an example SDP description with a timestamp reference 513 clock definition at the source level overriding the session level 514 default. 516 v=0 517 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 518 s=SDP Seminar 519 i=A Seminar on the session description protocol 520 u=http://www.example.com/seminars/sdp.pdf 521 e=j.doe@example.com (Jane Doe) 522 c=IN IP4 233.252.0.1/64 523 t=2873397496 2873404696 524 a=recvonly 525 a=ts-refclk:local 526 m=audio 49170 RTP/AVP 0 527 m=video 51372 RTP/AVP 99 528 a=rtpmap:99 h263-1998/90000 529 a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 531 Figure 4: Timestamp reference clock signalling at the source level 533 5. Media Clock Source Signalling 535 The media clock source for a stream determines the timebase used to 536 advance the RTP timestamps included in RTP packets. The media clock 537 may be asynchronously generated by the sender, it may be generated in 538 fixed relationship to the reference clock or it may be generated with 539 respect to another stream on the network (which is presumably being 540 received by the sender). 542 5.1. Asynchronously Generated Media Clock 544 In the simplest sender implementation, the sender generates media by 545 sampling audio or video according to a free-running local clock. The 546 RTP timestamps in media packets are advanced according to this media 547 clock and packet transmission is typically timed to regular intervals 548 on this timeline. The sender may or may not include an NTP timestamp 549 in sender reports to allow mapping of this asynchronous media clock 550 to a reference clock. 552 The asynchronously generated media clock is the assumed mode of 553 operation when there is no signalling of media clock source. 554 Alternatively, asynchronous media clock may be explicitly signalled. 556 a=mediaclk:sender 558 5.2. Direct-Referenced Media Clock 560 A media clock may be directly derived from a reference clock. For 561 this case it is required that a reference clock be specified with an 562 a=ts-refclk attribute (Section 4.8). 564 The signalling optionally indicates a media clock offset value. The 565 offset indicates the RTP timestamp value at the epoch (time of 566 origin) of the reference clock. If no offset is signalled, the 567 offset can be inferred at the receiver by examining RTCP sender 568 reports which contain NTP and RTP timestamps which combined define a 569 mapping. 571 A rate modifier may be specified. The modifier is expressed as the 572 ratio of two integers and modifies the rate specified or implied by 573 the media description by this ratio. If omitted, the rate is assumed 574 to be the exact rate specified or implied by the media format. For 575 example, without a rate specification, the media clock for an 8 kHz 576 G.711 audio stream will advance exactly 8000 units for each second 577 advance in the reference clock from which it is derived. 579 The rate modifier is primarily useful for accommodating certain 580 "oddball" audio sample rates associated with NTSC video (see 581 Figure 7). Modified rates are not advised for video streams which 582 generally use a 90 kHz RTP clock regardless of frame rate or sample 583 rate used for embedded audio. 585 a=mediaclk:direct[=] [rate=/] 588 5.3. Stream-Referenced Media Clock 590 A common synchronisation architecture for audio/visual systems 591 involves distributing a reference media clock from a master device to 592 a number of slave devices, typically by means of a cable. Examples 593 include audio word clock distribution and video black burst 594 distribution. In this case, the media clock is locally generated, 595 often by a crystal oscillator and is not locked to a timestamp 596 reference clock. 598 To support this architecture across a network, a master clock 599 identifier is associated with an RTP media stream carrying media 600 clock timing information from a master device. The master clock 601 identifier represents a media clock source in the master device. 602 Slave devices in turn associate the master media clock identifier 603 with streams they transmit, signalling the synchronisation 604 relationship between the master and slave devices. 606 Slave devices recover media clock timing from the clock master 607 stream, using it to synchronise the slave media clock with the 608 master. Timestamps in the master clock RTP media stream are taken 609 using the timestamp reference clock shared by the master and slave 610 devices. The timestamps communicate information about media clock 611 timing (rate, phase) from the master to the slave devices. 612 Timestamps are communicated in the usual RTP fashion via RTCP SRs, or 613 via the RFC6051 [RFC6051] header extension. The stream media format 614 may indicate other clock information, such as the nominal rate. 616 Note that slaving of a device media clock to a master device does not 617 affect the usual RTP lip sync / time alignment algorithms. Time 618 aligned playout of two or more RTP sources still relies upon NTP 619 timestamps supplied via RTCP SRs or by the RFC6051 timestamp header 620 extension. 622 In a given system, master clock identifiers must be unique. Such 623 identifiers MAY be manually configured, however 17 octet string 624 identifiers SHOULD be generated according to the "short-term 625 persistent RTCP CNAME" algorithm as described in RFC6222 [RFC6222]. 627 A reference stream can be an RTP stream or AVB stream based on the 628 IEEE 1722 [IEEE1722] standard. 630 An RTP clock master stream SHOULD be identified at the source level 631 by an SSRC [RFC5576] and master clock identifier. If master clock 632 identifiers are declared at the media or session level, all RTP 633 sources at or below the level of declaration MUST provide equivalent 634 timing to a slave receiver. 636 a=ssrc: mediaclk:master-id= 639 An RTP media sender indicates that it is slaved to a media clock 640 master via a clock master identifier: 642 a=mediaclk:master-id= 644 An RTP media sender indicates that it is slaved to an IEEE 1722 clock 645 master via a stream identifier (an EUI-64): 647 a=mediaclk:IEEE1722= 649 5.4. SDP Signalling of Media Clock Source 651 Specification of the media clock source may be at any or all levels 652 (session, media or source) of an SDP description (see level 653 definitions (Section 3) earlier in this document for more 654 information). 656 Media clock source signalling included at session level provides 657 default parameters for all RTP sessions and sources in the session 658 description. More specific signalling included at the media level 659 overrides default session level signalling. Further, source-level 660 signalling overrides media clock source signalling at the enclosing 661 media level and session level. 663 Media clock source signalling may be present or absent on a per- 664 stream basis. In the absence of media clock source signals, 665 receivers assume an asynchronous media clock generated by the sender. 667 Media clock source parameters may be repeated at a given level (i.e. 668 for a session or source) to provide information about additional 669 clock sources. If the attribute is repeated at a given level, all 670 clocks described at that level are comparable clock sources and may 671 be used interchangeably. 673 Figure 5 shows the ABNF [RFC5234] grammar for the SDP media clock 674 source information. "mediaclk-master" is used to declare a master 675 media clock reference at the source level. "timestamp-mediaclk-sl" is 676 a media clock description used at the source level. "timestamp- 677 mediaclk" is a media clock description at the session or media level. 679 mediaclk-master = "a=ssrc:" integer SP clk-master-id 681 clk-master-id = "mediaclk:master-id=" master-id 683 timestamp-mediaclk-sl = "a:ssrc" integer SP timestamp-mediaclk 685 timestamp-mediaclk = "a=mediaclk:" mediaclock 687 mediaclock = sender / refclk / streamid / mediaclock-ext 689 sender = "sender" sender-ext 691 sender-ext = token 693 refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] 695 rate = [ SP "rate=" integer "/" integer ] 697 direct-ext = token 699 streamid = "master-id=" master-id 700 streamid =/ "IEEE1722=" avb-stream-id 701 streamid =/ streamid-ext 703 master-id = EUI48 704 avb-stream-id = EUI64 706 EUI48 = 5(2HEXDIG ":") 2HEXDIG 707 EUI64 = 7(2HEXDIG ":") 2HEXDIG 709 streamid-ext = token 711 mediaclock-ext = token [SP byte-string] 713 Figure 5: Media Clock Source Signalling 715 5.5. Examples 717 Figure 6 shows an example SDP description 8 channels of 24-bit, 48 718 kHz audio transmitted as a multicast stream. Media clock is derived 719 directly from an IEEE 1588-2008 reference. 721 v=0 722 o=- 1311738121 1311738121 IN IP4 192.0.2.1 723 c=IN IP4 233.252.0.1/64 724 s= 725 t=0 0 726 m=audio 5004 RTP/AVP 96 727 a=rtpmap:96 L24/48000/8 728 a=sendonly 729 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 730 a=mediaclk:direct=963214424 732 Figure 6: Media clock directly referenced to IEEE 1588-2008 734 Figure 7 shows an example SDP description 2 channels of 24-bit, 44056 735 kHz NTSC "pull-down" media clock derived directly from an IEEE 1588- 736 2008 reference clock 738 v=0 739 o=- 1311738121 1311738121 IN IP4 192.0.2.1 740 c=IN IP4 233.252.0.1/64 741 s= 742 t=0 0 743 m=audio 5004 RTP/AVP 96 744 a=rtpmap:96 L24/44100/2 745 a=sendonly 746 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 747 a=mediaclk:direct=963214424 rate=1000/1001 749 Figure 7: "Oddball" sample rate directly referenced to IEEE 1588-2008 751 Figure 8 shows the same 48 kHz audio transmission from Figure 6 with 752 media clock derived from another RTP stream. 754 v=0 755 o=- 1311738121 1311738121 IN IP4 192.0.2.1 756 c=IN IP4 233.252.0.1/64 757 s= 758 t=0 0 759 m=audio 5004 RTP/AVP 96 760 a=rtpmap:96 L24/48000/2 761 a=sendonly 762 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 763 a=mediaclk:master-id=00:60:2b:20:12:1f 765 Figure 8: RTP stream with media clock slaved to a master device 767 Figure 9 shows the same 48 kHz audio transmission from Figure 6 with 768 media clock derived from an IEEE 1722 AVB stream. 770 v=0 771 o=- 1311738121 1311738121 IN IP4 192.0.2.1 772 c=IN IP4 233.252.0.1/64 773 s= 774 t=0 0 775 m=audio 5004 RTP/AVP 96 776 a=rtpmap:96 L24/48000/2 777 a=sendonly 778 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 779 a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F 781 Figure 9: RTP stream with media clock slaved to an IEEE1722 master 782 device 784 6. Signalling Considerations 786 Signaling of timestamp reference clock source (Section 4.8) and media 787 clock source (Section 5.4) is defined to be used either by 788 applications that implement the SDP Offer/Answer model [RFC3264] or 789 by applications that use SDP to describe media and transport 790 configurations. 792 A description SHOULD include both reference clock signalling and 793 media clock signalling. If no reference clock is avaialble, this 794 SHOULD be signalled as a local reference (Section 4.6). 796 When no media clock signalling is present, an asynchronous media 797 clock (Section 5.1) MUST be assumed. When no reference clock 798 signalling is present, a local reference clock (Section 4.6) MUST be 799 assumed. 801 If a reference clock is not signalled or a local reference is 802 specified, the corresponding media clock may be established as rate 803 synchronised with no assurance of time synchronisation. 805 When the description signals a direct-referenced media clock 806 (Section 5.2), reference clock signalling is REQUIRED. Asynchronous 807 and stream-referenced media clocks (Section 5.3) MAY be specified 808 with or without a reference clock signalling. 810 6.1. Usage in Offer/Answer 812 During offer/answer, clock source signalling via SDP uses a 813 declarative model. Supported media and/or reference clocks are 814 specified in the offered SDP description. The answerer may accept or 815 reject the offer in an application-specific way depending on the 816 clocks that are available and the clocks that are offered. For 817 example, an answerer may choose to accept an offer that lacks a 818 common clock by falling back to a lower performance mode of operation 819 (e.g. by assuming reference or media clocks are local rather than 820 shared). Conversely, the answerer may choose to reject the offer 821 when the offered clock specifications indicate that the available 822 reference and/or media clocks are incompatible. 824 While negotiation of reference clock and media clock attributes is 825 not defined in this document, negotiation MAY be accomplished using 826 the capabilities negotiation procedures defined in [RFC5939]. 828 6.1.1. Indicating Support for Clock Source Signalling 830 An offerer or answerer indicates support for media clock signalling 831 by including a reference or media clock specification in the SDP 832 description. An offerer or answerer without specific reference or 833 media clocks to signal SHOULD indicate support for clock source 834 signalling by including a local reference clock (Section 4.6) 835 specification in the SDP description. 837 6.1.2. Timestamp Reference Clock 839 If one or more of the reference clocks specified in the offer are 840 usable by the answerer, the answerer SHOULD respond with an answer 841 containing the subset of reference clock specifications in the offer 842 that are usable by the answerer. If the answerer rejects the offer 843 because the available reference clocks are incompatible, the 844 rejection MUST contain at least one timestamp reference clock 845 specification usable by the answerer. If no external reference clock 846 is available to the answerer a local reference clock (Section 4.6) 847 specification SHOULD be included in the rejection. 849 In both offers and answers, multiple reference clock specifications 850 indicate equivalent clocks from different sources which may be used 851 interchangeably. RTP senders and receivers are assured proper 852 synchronization regardless of which of the specified sources is 853 chosen and, in support of fault tolerance, may switch clock sources 854 while streaming. 856 6.1.3. Media Clock 858 If the media clock mode specified in the offer is acceptable to the 859 answerer, the answerer SHOULD respond with an answer containing the 860 same media clock specification as the offer. If the answerer rejects 861 the offer because the available reference clocks are incompatible, 862 the rejection MUST contain a media clock specification supported by 863 the answerer. If no shared media clocks are available to the 864 answerer an asynchronous media clock (Section 5.1) specification 865 SHOULD be included in the rejection. 867 6.2. Usage Outside of Offer/Answer 869 SDP can be employed outside of the Offer/Answer context, for instance 870 for multimedia sessions that are announced through the Session 871 Announcement Protocol (SAP) [RFC2974], or streamed through the Real 872 Time Streaming Protocol (RTSP) [RFC2326]. 874 Devices using published descriptions to join sessions SHOULD assess 875 their synchronization compatiblity with the described session based 876 on the clock source signaling and SHOULD NOT attempt to join a 877 session with incompatible reference or media clocks. 879 7. Security Considerations 881 Entities receiving and acting upon an SDP message SHOULD be aware 882 that a session description cannot be trusted unless it has been 883 obtained by an authenticated transport protocol from a known and 884 trusted source. Many different transport protocols may be used to 885 distribute session description, and the nature of the authentication 886 will differ from transport to transport. For some transports, 887 security features are often not deployed. In case a session 888 description has not been obtained in a trusted manner, the endpoint 889 SHOULD exercise care because, among other attacks, the media sessions 890 received may not be the intended ones, the destination where media is 891 sent to may not be the expected one, any of the parameters of the 892 session may be incorrect. 894 Incorrect reference or media clock parameters may cause devices or 895 streams to synchronize to unintended clock sources. Normally this 896 simply results in failure to establish a session or failure to 897 synchronize once connected. Enough devices fraudulently assigned to 898 a specific clock source (e.g. a particular IEEE 1588 grandmaster) 899 may, however, constitute a successful a denial of service attack on 900 that source. Devices MAY wish to validate the integrity of the clock 901 description through some means before connecting to unfamiliar clock 902 sources. 904 8. IANA Considerations 906 This document defines two new SDP attributes: 'ts-refclk' and 907 'mediaclk', within the existing Internet Assigned Numbers Authority 908 (IANA) registry of SDP Parameters. 910 This document also defines a new IANA registry subordinate to the 911 IANA SDP Parameters registry: the Media Clock Source Parameters 912 Registry. Within this new registry, this document defines an initial 913 set of three media clock source parameters. Further, this document 914 defines a second new IANA registry subordinate to the IANA SDP 915 Parameters registry: the Timestamp Reference Clock Source Parameters 916 Registry. Within this new registry, this document defines an initial 917 six parameters. 919 8.1. Reference Clock SDP Parameter 921 The SDP attribute "ts-refclk" defined by this document is registered 922 with the IANA registry of SDP Parameters as follows: 924 SDP Attribute ("att-field (both session and media level)"): 926 Attribute name: ts-refclk 928 Long form: Timestamp reference clock source 930 Type of name: att-field 932 Type of attribute: Session, media and source level 934 Subject to charset: No 936 Purpose: See section 4 of this document 938 Reference: This document 940 Values: See section 8.3 of this document 942 Figure 10 944 The attribute has an extensible parameter field and therefore a 945 registry for these parameters is required. This new registry is 946 defined in Section 8.3. 948 8.2. Media Clock SDP Parameter 950 The SDP attribute "mediaclk" defined by this document is registered 951 with the IANA registry of SDP Parameters as follows: 953 SDP Attribute ("att-field (both session and media level)"): 955 Attribute name: mediaclk 957 Long form: Media clock source 959 Type of name: att-field 961 Type of attribute: session and media level 963 Subject to charset: No 965 Purpose: See section 5 of this document 967 Reference: This document 969 Values: See section 8.4 of this document 971 Figure 11 973 The attribute has an extensible parameter field and therefore a 974 registry for these parameters is required. The new registry is 975 defined in Section 8.4. 977 8.3. Timestamp Reference Clock Source Parameters Registry 979 This document creates a new IANA sub-registry called the Timestamp 980 Reference Clock Source Parameters Registry, subordinate to the IANA 981 SDP Parameters registry. 983 Initial values for the Timestamp Reference Clock Source Parameters 984 registry are given below; future assignments are to be made through 985 the Specification Required policy [RFC5226]. 987 +---------+-------------------------+--------------------------+ 988 | Value | Long Name | Reference | 989 +---------+-------------------------+--------------------------+ 990 | ntp | Network Time Protocol | This document, section 4 | 991 | ptp | Precision Time Protocol | This document, section 4 | 992 | gps | Global Position System | This document, section 4 | 993 | gal | Galileo | This document, section 4 | 994 | local | Local Clock | This document, section 4 | 995 | private | Private Clock | This document, section 4 | 996 +---------+-------------------------+--------------------------+ 998 8.4. Media Clock Source Parameters Registry 1000 This document creates a new IANA sub-registry called the Media Clock 1001 Source Parameters registry, subordinate to the IANA SDP Parameters 1002 registry. 1004 Initial values for the Media Clock Source Parameters registry are 1005 given below; future assignments are to be made through the 1006 Specification Required policy [RFC5226]. 1008 +-----------+-------------------------------+-----------------------+ 1009 | Value | Long Name | Reference | 1010 +-----------+-------------------------------+-----------------------+ 1011 | sender | Asynchronously Generated | This document, | 1012 | | Media Clock | section 5 | 1013 | direct | Direct-Referenced Media Clock | This document, | 1014 | | | section 5 | 1015 | master-id | Media Clock Master Identifier | This document, | 1016 | | | section 5 | 1017 | IEEE1722 | IEEE1722 Media Stream | This document, | 1018 | | Identifier | section 5 | 1019 +-----------+-------------------------------+-----------------------+ 1021 8.5. Source-level Attributes 1023 [RFC5576] requires new source-level attributes to be registered with 1024 the IANA registry named "att-field (source level)". 1026 8.5.1. Source-level Reference Clock Attribute 1028 The source-level SDP attribute "ts-refclk" defined by this document 1029 is registered with the "att-field (source level)" IANA registry of 1030 SDP Parameters according to Figure 10. 1032 8.5.2. Source-level Media Clock Attribute 1034 The source-level SDP attribute "mediaclk" defined by this document is 1035 registered with the "att-field (source level)" IANA registry of SDP 1036 Parameters according to Figure 11. 1038 The source-level SDP attribute "master-id" defined by this document 1039 is registered with the IANA registry of SDP Parameters as follows: 1041 SDP Attribute ("att-field (source level)"): 1043 Attribute name: master-id 1045 Long form: Media clock source 1047 Type of name: att-field 1049 Type of attribute: source level 1051 Subject to charset: No 1053 Purpose: See section 5 of this document 1055 Reference: This document 1057 Values: EUI48 1059 Figure 12 1061 9. References 1063 9.1. Normative References 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, March 1997. 1068 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1069 A., Peterson, J., Sparks, R., Handley, M., and E. 1070 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1071 June 2002. 1073 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1074 with Session Description Protocol (SDP)", RFC 3264, 1075 June 2002. 1077 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1078 Description Protocol", RFC 4566, July 2006. 1080 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1081 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1082 May 2008. 1084 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1085 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1087 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1088 Media Attributes in the Session Description Protocol 1089 (SDP)", RFC 5576, June 2009. 1091 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 1092 Capability Negotiation", RFC 5939, September 2010. 1094 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 1095 Flows", RFC 6051, November 2010. 1097 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 1098 Choosing RTP Control Protocol (RTCP) Canonical Names 1099 (CNAMEs)", RFC 6222, April 2011. 1101 9.2. Informative References 1103 [AES11-2009] 1104 Audio Engineering Society, "AES11-2009: AES recommended 1105 practice for digital audio engineering - Synchronization 1106 of digital audio equipment in studio operations", 1107 . 1109 [I-D.ietf-avtcore-idms] 1110 Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., 1111 Montagud, M., and K. Gross, "Inter-destination Media 1112 Synchronization using the RTP Control Protocol (RTCP)", 1113 draft-ietf-avtcore-idms-07 (work in progress), 1114 October 2012. 1116 [IEEE1588-2002] 1117 Institute of Electrical and Electronics Engineers, "1588- 1118 2002 - IEEE Standard for a Precision Clock Synchronization 1119 Protocol for Networked Measurement and Control Systems", 1120 IEEE Std 1588-2002, 2002, . 1123 [IEEE1588-2008] 1124 Institute of Electrical and Electronics Engineers, "1588- 1125 2008 - IEEE Standard for a Precision Clock Synchronization 1126 Protocol for Networked Measurement and Control Systems", 1127 IEEE Std 1588-2008, 2008, . 1130 [IEEE1722] 1131 Institute of Electrical and Electronics Engineers, "IEEE 1132 Standard for Layer 2 Transport Protocol for Time Sensitive 1133 Applications in a Bridged Local Area Network", . 1136 [IEEE802.1AS-2011] 1137 Institute of Electrical and Electronics Engineers, "Timing 1138 and Synchronization for Time-Sensitive Applications in 1139 Bridged Local Area Networks", . 1142 [IEEE802.1BA-2011] 1143 Institute of Electrical and Electronics Engineers, "Audio 1144 Video Bridging (AVB) Systems", . 1147 [IS-GPS-200F] 1148 Global Positioning Systems Directorate, "Navstar GPS Space 1149 Segment/Navigation User Segment Interfaces", 1150 September 2011. 1152 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1153 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1155 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1156 Announcement Protocol", RFC 2974, October 2000. 1158 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1159 Time Protocol Version 4: Protocol and Algorithms 1160 Specification", RFC 5905, June 2010. 1162 [SMPTE-318-1999] 1163 Society of Motion Picture & Television Engineers, 1164 "Television and Audio - Synchronization of 59.94- or 50-Hz 1165 Related Video and Audio Systems in Analog and Digital 1166 Areas - Reference Signals", . 1168 URIs 1170 [1] 1173 Authors' Addresses 1175 Aidan Williams 1176 Audinate 1177 Level 1, 458 Wattle St 1178 Ultimo, NSW 2007 1179 Australia 1181 Phone: +61 2 8090 1000 1182 Fax: +61 2 8090 1001 1183 Email: aidan.williams@audinate.com 1184 URI: http://www.audinate.com/ 1186 Kevin Gross 1187 AVA Networks 1188 Boulder, CO 1189 US 1191 Email: kevin.gross@avanw.com 1192 URI: http://www.avanw.com/ 1194 Ray van Brandenburg 1195 TNO 1196 Brassersplein 2 1197 Delft 2612CT 1198 the Netherlands 1200 Phone: +31-88-866-7000 1201 Email: ray.vanbrandenburg@tno.nl 1203 Hans Stokking 1204 TNO 1205 Brassersplein 2 1206 Delft 2612CT 1207 the Netherlands 1209 Email: hans.stokking@tno.nl