RFC 7273
RTP Clock Source Signalling
RFC 7273: RTP Clock Source Signalling ✨
okay bestie, this one is RFC 7273 from June 2014 🎀. It's a Standards Track document, so it's an actual Internet standard, not just an idea floating around. The authors are A. Williams from Audinate, K. Gross from AVA Networks, R. van Brandenburg, and H. Stokking, both from TNO 💅. It sits in the ISSN 2070-1721 series. The title block doesn't list anything it obsoletes or updates, so it's not replacing or patching any older RFC. Main character energy 🦋
Abstract
okay so the core idea is that NTP format timestamps get used by a bunch of RTP protocols to keep things in sync and to do stats 📊. This doc defines SDP signalling that tells you which reference clock a timestamp came from, plus SDP signalling that tells you which media clock sources are involved in a multimedia session 🧚.
Status of This Memo
this is an Internet Standards Track document 🔥.
it's an official product of the Internet Engineering Task Force (IETF) 🌸. it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. if you want more on Internet Standards, check Section 2 of RFC 5741 💜.
for the current status of this doc, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7273 💖.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date it was published. please actually read these, because they spell out your rights and restrictions for this document 🙈. any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ✨.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5
4.1. Clock Synchronisation . . . . . . . . . . . . . . . . . . 5
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . 6
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . 6
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8
4.5. Private Reference Clocks . . . . . . . . . . . . . . . . 8
4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . 8
4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . 8
4.8. SDP Signalling of Timestamp Reference Clock Source . . . 9
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12
5.1. Asynchronously Generated Media Clock . . . . . . . . . . 12
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . 15
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19
6.1.1. Indicating Support for Clock Source Signalling . . . 20
6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20
6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22
8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 23
8.3. Timestamp Reference Clock Source Parameters Registry . . 23
8.4. Media Clock Source Parameters Registry . . . . . . . . . 24
8.5. Source-Level Attributes . . . . . . . . . . . . . . . . . 25
8.5.1. Source-Level Timestamp Reference Clock Attribute . . 25
8.5.2. Source-Level Media Clock Attribute . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 271. Introduction ✨
RTP protocols lean on NTP format timestamps for multimedia session synchronisation, and to estimate round-trip time (RTT) and other stats 📊.
info about media clock timing that comes over in NTP format timestamps might come from a clock synced to a global time reference, but you can't assume that 🙈. there's also no standard mechanism to say "these timestamps come from a common reference clock." so RTP implementations usually assume the NTP timestamps come from unsynchronised clocks, and they must compensate for absolute time differences and rate differences 💅. without a shared reference clock, RTP can still line up flows from the same source at one receiver using relative timing, but tight sync between two or more different receivers (maybe on different network paths) or between two or more senders is not possible 💔.
high performance AV systems often use a reference media clock that gets distributed to every device in the system 🎀. that reference media clock can be different from the reference clock used for timestamps. a reference media clock can come along with an audio or video signal interface, or through a dedicated clock signal, like genlock [SMPTE-318M-1999] or audio word clock [AES11-2009] 🌸. if the sending and receiving media clocks are known to be synced to a common reference clock, performance can get better by minimising buffering and avoiding rate conversion 🚀.
this spec defines SDP signalling for timestamp reference clock sources and media reference clock sources ✨.
1.1. Requirements Language
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥.
2. Applications 🧚
timestamp reference clock source and media clock signalling are a big deal for apps that need synchronised media capture or playout and low latency operation 💜.
examples include, but aren't limited to, the following 💖:
- Social TV: "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)" [RFC7272] defines social TV as watching media content with two or more users at different devices and locations, while doing real-time communication between those users 📺. for example, two or more users watching the same TV broadcast on different devices and/or in different places while chatting with each other by text, audio, and/or video 🍓. if the media playout for those users is skewed, it can mess with their experience 😭. a classic example is one friend seeing a goal in a football match way before or after the other friends ⚽.
- Video Walls: a video wall is multiple computer monitors, video projectors, or TV sets tiled together contiguously or overlapped to make one big screen 🖥️. each screen shows a portion of the bigger picture 🌈. in some setups, each screen or projector can be connected to the network on its own and get its piece of the image from a network-connected video server or video scaler 🦋. screens refresh at 50 or 60 hertz, or possibly faster ⚡. if the refresh isn't synced, the whole "multiple screens acting as one" effect falls apart 💀.
- Networked Audio: networked loudspeakers, amplifiers, and analogue input/output (I/O) devices that send or receive audio signals over RTP can be hooked up to different parts of a building or campus network 🎤. you'll find these in large conference rooms, legislative chambers, classrooms (especially ones doing distance learning), and other big spaces like stadiums 🏟️. humans are super sensitive to differences in audio delay, so this use case needs even more accuracy than the video wall one 👂. depending on the application, the accuracy needed can be in the range of microseconds [Olsen] 🫶.
- Sensor Arrays: sensor arrays have lots of synced measurement elements, and their signals get combined into one overall measurement 📡. capturing the phase relationships between the signals arriving at each element of the array is critically important for proper operation 🙌. examples are towed or fixed sonar arrays, seismic arrays, and phased arrays used in radar applications, for instance 🛰️.
3. Definitions 💅
the following definitions are used in this document 📝:
- media level: media-level info applies to a single SDP media stream. in an SDP description, media-level info shows up after each
m-line 🎀. - multimedia session: a set of multimedia senders and receivers, plus the data streams flowing from senders to receivers 🌸. SDP [RFC4566] is what describes multimedia sessions 💜.
- RTP media stream: a single stream of RTP packets identified by an RTP Synchronisation Source (SSRC) ✨.
- RTP sender: the device generating an associated RTP media stream 🧚.
- session level: session-level info applies to an entire multimedia session. in an SDP description, session-level info shows up before the first
m-line 👑. - source level: source-level info applies to a specific RTP media stream. "Source-Specific Media Attributes in the Session Description Protocol (SDP)" [RFC5576] defines how source-level info gets included in an SDP session description 🦋.
- traceable time: a clock is considered to provide traceable time if it can be proven to be synchronised to International Atomic Time (TAI) ⏱️. Coordinated Universal Time (UTC) is a time standard synchronised to TAI, so UTC is also considered traceable time once leap seconds have been taken into account 🌈. GPS [IS-GPS-200F] is commonly used to provide a TAI traceable time reference 🛰️. some network time sync protocols (e.g., Precision Time Protocol (PTP) [IEEE1588-2008] and NTP) can explicitly indicate that the master clock is providing a traceable time reference over the network 🔥💖
4. Timestamp Reference Clock Source Signalling ✨
okay so RTP's NTP-format timestamps come from reading a local real-time clock, either at the sender or at the receiver 🕰️. That local clock might be synced to some other clock (the "time source"), or it might not be synced at all 💀. There are loads of ways to sync local clocks to a reference, like network time protocols such as NTP [RFC5905] and PTP [IEEE1588-2008], or radio clocks such as GPS [IS-GPS-200F] 🛰️.
The next sections define the SDP signalling that says whether, and how, the local timestamping clock in an RTP sender or receiver is synced to a reference clock 🎀.
4.1. Clock Synchronisation
Two or more local clocks that are synced well enough will make timestamps for the same RTP event that can be treated as if they came from one clock 🫶. Timestamps made in one RTP sender or receiver can be compared directly with a local clock in another one ✨.
How tight the sync needs to be depends on the app. Check out "Applications" (Section 2) for the apps and what they need 💅. To act as a reference clock, clocks must at minimum be "syntonised" (exactly frequency matched) to one another.
Sufficient sync can usually be achieved by using a network time protocol (e.g., NTP, 802.1AS, and IEEE 1588-2008) to sync all devices to one master clock 🧚.
Another option is clocks that provide a global time reference (e.g., GPS, Galileo, and GLONASS) 🌍. This can be combined with network time protocols, since some of them (e.g., PTP and NTP) let master clocks say explicitly that they're providing traceable time 🔥.
4.2. Identifying NTP Reference Clocks
A single NTP server is identified by a hostname (or IP address) plus an optional port number. If there's no port number, it's assumed to be the standard NTP port (123) 🍓.
Two or more NTP servers MAY be listed at the same level in the session description to say that all of the listed servers deliver the same reference time and can be used interchangeably 👯. RTP senders and receivers are assured proper synchronisation no matter which server they pick, and for fault tolerance they may switch servers while streaming 🛟.
4.3. Identifying PTP Reference Clocks
The Precision Time Protocol (PTP), as standardised in IEEE 1588, gives you a shared reference clock across a network 🌐. IEEE 1588 provides sub-microsecond sync between devices on a LAN and typically locks within seconds at startup ⏱️. With support from Ethernet switches, IEEE 1588 protocols can reach nanosecond timing accuracy in LANs 🤯. Network interface chips and cards that support hardware timestamping of timing-critical protocol messages are also available.
There are three flavours of IEEE 1588 in use today:
- IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". This is also known as IEEE1588v1 or PTPv1.
- IEEE 1588-2008 [IEEE1588-2008]: the second version of the "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". It's a revised version of the original IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002 🙅♀️.
- IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for Time Sensitive Applications in Bridged Local Area Networks". This is a profile of IEEE 1588-2008 that is Layer 2 only, and it's for use in Audio/Video Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011] 🎶.
Each IEEE 1588 clock is identified by a 64-bit Extended Unique Identifier (EUI-64) called a "ClockIdentity" 🪪. A slave clock using one of the IEEE 1588 family of network time protocols acquires the ClockIdentity of the grandmaster clock, which is the ultimate source of timing information for the network 👑. A boundary clock that's itself slaved to another boundary clock, or the grandmaster, passes the grandmaster ClockIdentity through to its slaves 📨.
Several instances of the IEEE 1588 protocol can run independently on a single network, forming distinct PTP domains, and each one may have a different grandmaster clock 🌈. The definition of PTP domains has changed as the IEEE 1588 standards evolved. IEEE 1588-2002 identifies protocol subdomains by a textual name, but IEEE 1588-2008 identifies protocol domains using a numeric domain number 🔢. 802.1AS is a Layer 2 profile of IEEE 1588-2008 and supports a single numeric clock domain (0) 🦋.
When PTP domains are signalled via SDP, senders and receivers SHOULD check that both the grandmaster ClockIdentity and the PTP domain match when they're deciding whether clocks are equivalent 🔍.
Two or more IEEE 1588 clocks MAY be listed at the same level in the session description to say that all of the listed clocks are candidate grandmaster clocks for the domain, or that they deliver the same reference time and can be used interchangeably 🤝. RTP senders and receivers are assured proper synchronisation no matter which synchronisation source they choose, and for fault tolerance they may switch the reference clock source while streaming 💪.
The PTP protocols use a distributed election protocol called the "Best Master Clock Algorithm" (BMCA) to decide which clock is the active clock master 🗳️. The clock master choices available to BMCA can be restricted or biased by configuration parameters to influence the election. In some systems it may be desirable to limit the number of possible PTP clock masters, so you don't have to re-signal timestamp reference clock sources every time the clock master changes 🙃.
4.4. Identifying Global Reference Clocks
Global reference clocks provide a source of traceable time, typically through a hardware radio receiver interface 📡. Examples include GPS, Galileo, and GLONASS. Apart from the name of the reference clock system, no further identification is required 🙌.
4.5. Private Reference Clocks
In other systems, all RTP senders and receivers may use a timestamp reference clock that isn't provided by any of the methods listed above 🤫. Examples include reference time information provided by digital television or cellular services. These sources are identified as "private" reference clocks 🔒. All RTP senders and receivers in a session using a private reference clock are assumed to have a mechanism, outside this specification, for working out whether their timestamp reference clocks are equivalent 🧐.
4.6. Local Reference Clocks
[RFC3550] lets senders and receivers either use a local wallclock reference for their NTP timestamps or, by setting the timestamp field to 0, supply no timestamps at all 🫠. Both are common practice in embedded RTP implementations 🛠️. These clocks are identified as "local", and at best they can be assumed to be equivalent to clocks that originate from the same device 🏠.
4.7. Traceable Reference Clocks
A timestamp reference clock source may be labelled "traceable" if it's known to be delivering traceable time, as long as adjustments are made for differing epochs, timezones, and leap seconds 🗓️. Timestamps taken using clocks synced to a traceable time source can be compared directly, even if the clocks are synced to different sources or through different mechanisms 💫.
Marking a clock as traceable means additional information (e.g., IP addresses, PTP master identifiers, and the like) can be left out of the SDP, because any traceable clock available at the answerer is considered an appropriate timestamp reference clock 😎. For example, an offerer could specify ts-refclk:ntp=/traceable/, and the answerer could use GPS as a reference clock since GPS is a source of traceable time 🥰.
4.8. SDP Signalling of Timestamp Reference Clock Source
The timestamp reference clock source can be specified at any or all levels (session, media, or source) of an SDP description. Check out the level definitions in Section 3 earlier in this document for more info 📚.
Signalling at the session level gives default parameters for all RTP sessions and sources in the session description 🌸. More specific signalling at the media level overrides session-level signalling, and more specific signalling at the source level overrides media-level signalling 🎯.
If timestamp reference clock source signalling is included anywhere in an SDP description, it must be properly defined for all levels in the description. The easy way to do this is to provide default signalling at the session level 🧸.
Timestamp reference clock parameters may be repeated at a given level (i.e., for a session or source) to give information about additional servers or clock sources 📋. If the attribute is repeated at a given level, all clocks described at that level are assumed to be equivalent 👭. Traceable time sources MUST NOT be mixed with non-traceable time sources at any given level 🚫.
Note that clock source parameters may change from time to time, for example as a result of a PTP grandmaster election ⚡. SIP [RFC3261] supports re-signalling of updated SDP information. Other protocols may require additional notification mechanisms 📣.
General forms of usage:
session level: a=ts-refclk:<clksrc>
media level: a=ts-refclk:<clksrc>
source level: a=ssrc:<ssrc-id> ts-refclk:<clksrc>ABNF [RFC5234] grammar for the timestamp reference clock attribute:
; external references:
POS-DIGIT = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
CRLF = <See RFC 5234>
hostport = <See RFC 3261, with revisions from RFC 5954>
timestamp-refclk = "ts-refclk:" clksrc CRLF
clksrc = ntp / ptp / gps / gal / glonass / local / private /
clksrc-ext
clksrc-ext = clksrc-param-name clksrc-param-value
clksrc-param-name = token
clksrc-param-value = ["=" byte-string ]
ntp = "ntp=" ntp-server-addr
ntp-server-addr = hostport / "/traceable/"
ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002"
/ "IEEE1588-2008"
/ "IEEE802.1AS-2011"
/ ptp-version-ext
ptp-version-ext = token
ptp-server = ptp-gmid [":" ptp-domain]
/ "traceable"
ptp-gmid = EUI64
ptp-domain = ptp-domain-name / ptp-domain-nmbr
; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-name = "domain-name=" 1*16ptp-domain-char
ptp-domain-char = %x21-7E
; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
ptp-domain-n1 = DIGIT ; 0-9
ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99
ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119
/ "12" %x30-37 ; 120-127
gps = "gps"
gal = "gal"
glonass = "glonass"
local = "local"
private = "private" [ ":traceable" ]
EUI64 = 7(2HEXDIG "-") 2HEXDIGFigure 1: Timestamp Reference Clock Source Signalling 🧾
4.8.1. Examples ✨
okay bestie, time for the examples 💅 Figure 2 sets a timestamp reference clock source at the session level, so it applies to the whole session 🎀
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:ntp=/traceable/
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000Figure 2: Timestamp Reference Clock Definition at the Session Level
Figure 3 shows timestamp reference clock definitions at the media level, and they override the session-level defaults 🦋
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
a=ts-refclk:ntp=203.0.113.10
a=ts-refclk:ntp=198.51.100.22
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0Figure 3: Timestamp Reference Clock Definition at the Media Level
Figure 4 shows a timestamp reference clock definition at the source level, which overrides the session-level default 🌸
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0Figure 4: Timestamp Reference Clock Signalling at the Source Level
5. Media Clock Source Signalling 🎀
okay so the media clock source for a stream is what sets the timebase that moves the RTP timestamps in your RTP packets forward ⏰ The media clock can be generated asynchronously by the sender, it can be generated in a fixed relationship to the reference clock, or it can be generated relative to another stream on the network (which the sender is presumably receiving) 💜
5.1. Asynchronously Generated Media Clock
the simplest sender out there samples audio or video using a free-running local clock 🦋 The RTP timestamps in the media packets move forward according to this media clock, and packet transmission is usually timed to regular intervals along that timeline ✨ The sender may or may not include an NTP timestamp in its sender reports, which lets this asynchronous media clock be mapped to a reference clock 🌈
an asynchronous media clock is the assumed mode whenever the media clock source isn't signalled 💅 You can also signal it explicitly, though:
a=mediaclk:sender5.2. Direct-Referenced Media Clock
a media clock can be derived straight from a reference clock 🧚 For this case, a reference clock has to be specified with an a=ts-refclk attribute (Section 4.8) 🔥
the signalling can optionally include a media clock offset value 💖 The offset is the RTP timestamp value at the epoch (time of origin) of the reference clock 🌸 To use the offset, implementations need to compute RTP timestamps from reference clocks 🙈 To make that math easier, streams using offset signalling SHOULD use a TAI timestamp reference clock so they avoid the mess leap seconds cause 💀 Check out [RFC7164] for more on leap-second issues in timestamp reference clocks 📚
okay so for an IEEE 1588 (TAI-based) reference, you have to work out how much time has passed between the 00:00:00 1 January 1970 IEEE 1588 epoch and right now 🕰️ From the epoch to 1 January 2013 there were 15,706 days (including the extra days in leap years) ✨ A TAI reference has no leap seconds, so each of those days is exactly 86,400 seconds, which adds up to 1,356,998,400 seconds from the epoch to 00:00:00 1 January 2013 🎀 A 90 kHz RTP clock for a video stream would have advanced 122,129,856,000,000 units over that period 🦋 With a signalled offset of 0, the RTP clock value modulo the 32-bit unsigned RTP timestamp representation in the RTP header would have been 2,460,938,240 at 00:00:00 1 January 2013 💜 If an offset of 23,465 had been signalled, the clock value would have been 2,460,961,705 🌈
to use an NTP reference, you need the actual time between the 00:00:00 1 January 1900 NTP epoch and right now 😭 There are 2,208,988,800 seconds between the NTP epoch and 00:00:00 1 January 1970 [RFC0868] 🌸 From the beginning of 1970 to 2013 there were 15,706 days (including extra days in leap years) and 25 leap seconds inserted 💅 So the total from the NTP epoch to 00:00:00 1 January 2013 is 3,565,987,225 seconds 🧚 A 90 kHz RTP clock for a video stream would have advanced 320,938,850,250,000 units over this period ✨ With a signalled offset of 0, the RTP clock value modulo the 32-bit unsigned representation would have been 1,714,023,696 at 00:00:00 1 January 2013 🔥
if no offset is signalled, the receiver can infer it by looking at RTCP sender reports that contain both NTP and RTP timestamps, since those two together define a mapping 🫶 The NTP/RTP timestamp mapping from RTCP sender reports (SRs) wins over whatever is signalled through SDP 👑 Even so, the media clock rate implied by the SRs MUST be consistent with the rate that was signalled 🙈
a rate modifier can also be specified 🍓 It's written as the ratio of two integers, and it modifies the rate specified or implied by the media description by that ratio 💜 If it's left out, the rate is assumed to be the exact rate specified or implied by the media format ✨ For example, with no rate specification, the RTP clock for an 8 kHz G.711 audio stream advances exactly 8000 units for every second that passes on the reference clock it's derived from 🦋
the rate modifier is mainly useful for those "oddball" audio sample rates tied to NTSC video (see Figure 7) 🌈 Modified rates aren't advised for video streams, which usually use a 90 kHz RTP clock no matter the frame rate or the sample rate of any embedded audio 💅
a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate denominator>]5.3. Stream-Referenced Media Clock
a common sync setup for audio/visual systems is to send a reference media clock from a master device to a bunch of slave devices, usually over a cable 🎀 Examples are audio word clock distribution and video black burst distribution 🦋 In this setup the media clock is generated locally, often by a crystal oscillator, and it isn't locked to a timestamp reference clock 💜
to make this work across a network, a master clock identifier is attached to an RTP media stream that carries the media clock timing info from a master device 🧚 The master clock identifier stands for a media clock source in the master device ✨ Slave devices then attach the master media clock identifier to the streams they transmit, which signals the sync relationship between the master and the transmitter's media clock 🔥
slave devices pull the media clock timing out of the clock master stream and use it to sync their own media clock with the master 🫶 If there's a common reference clock, the NTP timestamps in the master clock RTP media stream are taken from that shared clock 🌸 Those NTP timestamps carry the media clock timing info (rate and phase) from the master to the slaves 🙈 NTP timestamps go across in the usual RTP way, via RTCP SRs or the [RFC6051] header extension 📚 If there's no shared reference clock available or signalled, a slave can sync to the master's media clock using RTP timestamps alone, as described in Section 5.1 of [RFC3550] 💅
⚠️ heads up: slaving a device's media clock to a master device does not affect RTP inter-media synchronisation 😭 Time-aligned playout of two or more RTP sources still depends on NTP timestamps, supplied either via RTCP SRs or by the RFC 6051 timestamp header extension 💀
in a given system, master clock identifiers MUST uniquely identify a single media clock source 👑 They MAY be configured manually, but identifiers SHOULD be generated with the "short-term persistent RTCP CNAME" algorithm described in [RFC7022] 🎀 Master clock identifiers that aren't already in base64 format MUST be encoded as base64 strings when used in SDP 🌈 Even though the CNAME algorithm generates the master clock identifier, it's used to tag RTP sources in SDP descriptions and doesn't show up in RTCP as a CNAME 🦋
a reference stream can be an RTP stream or an Audio Video Bridging (AVB) stream based on the [IEEE1722] standard 🧚
an RTP clock master stream SHOULD be identified at the source level by an SSRC [RFC5576] and a master clock identifier 🫶 An RTP stream that provides media clock timing straight from a reference media clock (e.g., internal crystal, audio word clock, or video black burst signal) SHOULD tag itself as a master clock source using the "src:" prefix ✨ If master clock identifiers are declared at the media or session level, then all RTP sources at or below that level MUST provide equivalent timing to a slave receiver 💖
a=ssrc:<ssrc> mediaclk:id=src:<media-clktag> sender
a=mediaclk:id=src:<media-clktag> sendera transmitted RTP stream that's slaved to the media clock master gets signalled by including a master clock identifier 💜
a=mediaclk:id=<media-clktag> senderan RTP media sender says it's slaved to an IEEE 1722 clock master through a stream identifier (an EUI-64) 🌸
a=mediaclk:IEEE1722=<StreamID>and an RTP media sender can gateway IEEE 1722 media clock timing to RTP 🔥
a=mediaclk:id=src:<media-clktag> IEEE1722=<StreamID>5.4. SDP Signalling of Media Clock Source ✨
okay so the media clock source can be signalled at the session level, the media level, or the source level of an SDP description 🎀 (check the level definitions in Section 3 earlier in this doc if you want the deets).
session level gives you the defaults for every RTP session and source in the description 💖. then the media level is more specific and overrides the session level 🔥. and source-level signalling overrides both the media level and the session level it's nested in 👑. the most specific one wins, bestie 💅
the attribute can be there or totally missing on any given stream 🦋. if it's missing, receivers just assume the sender is running an asynchronous media clock 🧚
you can also repeat the media clock source parameters at the same level (session or source) to describe extra clock sources 🌸. when that happens, all the clocks described at that level are comparable and can be used interchangeably ✨ literally clock twins 🫶
general forms of usage:
session level: a=mediaclk:<mediaclock>
media level: a=mediaclk:<mediaclock>
source level: a=ssrc:<ssrc-id> mediaclk:<mediaclock>here's the ABNF [RFC5234] grammar for the media clock reference attribute 🌈 the external stuff is defined elsewhere, so the grammar just points to those docs:
; external references:
integer = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
base64 = <See RFC 4566>
SP = <See RFC 5234>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
media-clksrc = "mediaclk:" [media-clkid SP] mediaclock
media-clkid = "id=" [ "src:" ] media-clktag
media-clktag = base64
mediaclock = sender / direct / ieee1722-streamid / mediaclock-ext
mediaclock-ext = mediaclock-param-name mediaclock-param-value
mediaclock-param-name = token
mediaclock-param-value = [ "=" byte-string ]
sender = "sender"
direct = "direct" [ "=" 1*DIGIT ] [SP rate]
rate = "rate=" integer "/" integer
ieee1722-streamid = "IEEE1722=" avb-stream-id
avb-stream-id = EUI64
EUI64 = 7(2HEXDIG "-") 2HEXDIG Figure 5: Media Clock Source Signalling5.5. Examples 🍓
okay here comes the fun part 🎀 Figure 6 is an SDP description for 8 channels of 24-bit, 48 kHz audio sent as a multicast stream 🦋. the media clock comes straight from an IEEE 1588-2008 reference ✨
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/8
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 Figure 6: Media Clock Directly Referenced to IEEE 1588-2008Figure 7 is giving "oddball" energy 🙈 it's an SDP description for 2 channels of 24-bit, 44056 kHz NTSC "pull-down" media clock, derived directly from an IEEE 1588-2008 reference clock 💜
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/44100/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 rate=1000/1001 Figure 7: "Oddball" Sample Rate Directly Referenced to IEEE 1588-2008Figure 8 is the same 48 kHz audio transmission we saw in Figure 6 🌸 except this time the media clock is derived from another RTP stream 🧚
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender Figure 8: RTP Stream with Media Clock Slaved to a MasterFigure 9 is the same 48 kHz audio transmission from Figure 6 again 🦋 this time the media clock is derived from an IEEE 1722 AVB stream ✨
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F Figure 9: RTP Stream with Media Clock Slaved to an
IEEE 1722 Master Device6. Signalling Considerations 💅
okay so signalling the timestamp reference clock source (Section 4.8) and the media clock source (Section 5.4) is meant to be used either by apps that do the SDP Offer/Answer model [RFC3264], or by apps that just use SDP to describe media and transport setups 🎀
a description SHOULD include both reference clock signalling and media clock signalling 🔥 and if there's no reference clock available, it SHOULD be signalled as a local reference (Section 4.6) 🌈
when there's no media clock signalling at all, an asynchronous media clock (Section 5.1) MUST be assumed 🧚 and when there's no reference clock signalling, a local reference clock (Section 4.6) MUST be assumed too 💖
if a reference clock isn't signalled or a local reference is specified, the matching media clock may be set up as rate synchronised, but there's no promise of time synchronisation 🦋 (rate vs time, bestie, they are NOT the same 💀)
when the description signals a direct-referenced media clock (Section 5.2), reference clock signalling is REQUIRED 👑 asynchronous and stream-referenced media clocks (Section 5.3) MAY be specified with or without reference clock signalling 🌸
6.1. Usage in Offer/Answer ✨
during offer/answer, clock source signalling over SDP uses a declarative model 🫶 the supported media and/or reference clocks get listed in the offered SDP description 🎀 the answerer can accept or reject the offer in an application-specific way, depending on which clocks are available and which ones were offered 💅
for example, an answerer might accept an offer that doesn't have a common clock by falling back to a lower-performance mode of operation (like assuming the reference or media clocks are local instead of shared) 🌈 or the answerer might reject the offer if the offered clock specs show the available reference and/or media clocks are incompatible 🔥
negotiation of reference clock and media clock attributes isn't defined in this document 🙈 but negotiation MAY be done using the capabilities negotiation procedures defined in [RFC5939] ✨
6.1.1. Indicating Support for Clock Source Signalling 🦋
an offerer or answerer shows it supports media clock signalling by including a reference or media clock specification in the SDP description 💖 an offerer or answerer that doesn't have specific reference or media clocks to signal SHOULD indicate support for clock source signalling by including a local reference clock (Section 4.6) specification in the SDP description 🧚
6.1.2. Timestamp Reference Clock 🌸
if one or more of the reference clocks in the offer are usable by the answerer, the answerer SHOULD respond with an answer that contains the subset of reference clock specifications from the offer that the answerer can actually use 💜 if the answerer rejects the offer because the available reference clocks are incompatible, the rejection MUST contain at least one timestamp reference clock specification usable by the answerer 🔥 so there's info for diagnostics 🫶 and if the answerer has no external reference clock, a local reference clock (Section 4.6) specification SHOULD be included in the rejection 🎀
in both offers and answers, multiple reference clock specs mean equivalent clocks from different sources that can be used interchangeably 👑 RTP senders and receivers are assured proper synchronisation no matter which of the specified sources gets picked 🌈 and for fault tolerance, they may switch clock sources while streaming 🦋
6.1.3. Media Clock 💅
if the media clock mode in the offer is acceptable to the answerer, the answerer SHOULD respond with an answer containing the same media clock specification as the offer 🍓 if the answerer rejects the offer because the available reference clocks are incompatible, the rejection MUST contain a media clock specification supported by the answerer 🌸 so the diagnostics are useful 🙈 and if there are no shared media clocks available to the answerer, an asynchronous media clock (Section 5.1) specification SHOULD be included in the rejection 🧚
6.2. Usage Outside of Offer/Answer 🌈
SDP isn't only for offer/answer, babe 🫶 it can also be used for multimedia sessions announced through the Session Announcement Protocol (SAP) [RFC2974] or streamed through the Real Time Streaming Protocol (RTSP) [RFC2326] ✨
devices that use published descriptions to join sessions SHOULD assess their synchronisation compatibility with the described session based on the clock source signalling 🔥 and they SHOULD NOT attempt to join a session with incompatible reference or media clocks 🛑💀 (don't be that device, fr fr)
7. Security Considerations 🚨
this part is SERIOUS bestie, no cap 😭 entities that receive and act on an SDP message should note that a session description can't be trusted unless it was obtained by an authenticated transport protocol from a known and trusted source 🔒 lots of different transport protocols can be used to distribute a session description, and the kind of authentication varies from transport to transport 🙈 for some transports, security features often aren't deployed at all 💀 if a session description wasn't obtained in a trusted way, the endpoint should exercise care, because among other attacks, the media sessions received might not be the intended ones, the destination where media gets sent might not be the expected one, and any of the session's parameters might be wrong 😭🚨
incorrect reference or media clock parameters can make devices or streams sync to unintended clock sources 🫠 normally that just means a session fails to get set up, or fails to sync once connected 🙃 but if enough devices get fraudulently assigned to one specific clock source (like a particular IEEE 1588 grandmaster), that can actually be a successful denial-of-service attack on that source 💀 devices MAY wish to validate the integrity of the clock description through some means before connecting to unfamiliar clock sources 🛡️✨
the timestamp reference clocks negotiated by this protocol are used to provide media timing information to RTP 🎀 negotiated timestamp reference clocks should not be relied upon to provide a secure time reference for security-critical operations (for example, the expiration of public key certificates) 🔐 so don't use them for your cert expiry checks, bestie 🙅♀️
8. IANA Considerations 🦋
this document defines two new SDP attributes, "ts-refclk" and "mediaclk", inside the existing Internet Assigned Numbers Authority (IANA) registry of SDP Parameters 🎀
this document also defines a new IANA registry that sits under the IANA SDP Parameters registry: the Media Clock Source Parameters registry 💖 inside this new registry, the document defines an initial set of three media clock source parameters 🌈 and it also defines a second new IANA registry under the IANA SDP Parameters registry: the Timestamp Reference Clock Source Parameters registry 🧚 inside that one, the document defines an initial six parameters 👑✨
8.1. Reference Clock SDP Parameter
okay so the SDP attribute "ts-refclk" from this doc gets registered with the IANA SDP Parameters registry like this 💅✨
SDP Attributes ( "att-field (both session and media level)" &
"att-field (source level)" ):
Attribute name: ts-refclk
Long form: Timestamp reference clock source
Type of name: att-field
Type of attribute: Session, media, and source level
Subject to charset: No
Purpose: See Section 4 of this document
Reference: This document
Values: See Section 8.3 of this documentFigure 10: Reference Clock SDP Parameter IANA Registration
ngl the attribute has an extensible parameter field, so a registry for those parameters is required 🗂️ This new registry is defined in Section 8.3. iykyk 🫶
8.2. Media Clock SDP Parameter
the SDP attribute "mediaclk" from this doc gets the same kind of registration in the IANA SDP Parameters registry 🦋
SDP Attributes ( "att-field (both session and media level)" &
"att-field (source level)" ):
Attribute name: mediaclk
Long form: Media clock source
Type of name: att-field
Type of attribute: Session, media, and source level
Subject to charset: No
Purpose: See Section 5 of this document
Reference: This document
Values: See Section 8.4 of this documentFigure 11: Media Clock SDP Parameter IANA Registration
same energy as before, the attribute has an extensible parameter field, so a registry for these parameters is required. The new registry is defined in Section 8.4. it's giving organised 🎀
8.3. Timestamp Reference Clock Source Parameters Registry
okay this is the big one 🌸 the doc creates a brand new IANA subregistry called the Timestamp Reference Clock Source Parameters registry, which sits under the IANA SDP Parameters registry. Every entry in it has three fields:
Name: the token used in the SDP description (clksrc-param-name)Long name: a descriptive name for the timestamp reference clock sourceReference: a pointer to the document that describes the SDP token (clksrc-param-name) and the syntax for its optional value (mediaclock-param-value)
the initial values for this registry are below 👑
Future assignments are made through the Specification Required policy [RFC5226]. The Name field corresponds to a new value for clksrc-param-name. The Reference must specify a syntax for clksrc-param-value. (no notes on that one, it's just how it works 🙈)
+---------+------------------------------+--------------------------+
| Name | Long Name | Reference |
+---------+------------------------------+--------------------------+
| ntp | Network Time Protocol | This document, Section 4 |
| | | |
| ptp | Precision Time Protocol | This document, Section 4 |
| | | |
| gps | Global Positioning System | This document, Section 4 |
| | | |
| gal | Galileo | This document, Section 4 |
| | | |
| glonass | Global Navigation Satellite | This document, Section 4 |
| | System | |
| | | |
| local | Local Clock | This document, Section 4 |
| | | |
| private | Private Clock | This document, Section 4 |
+---------+------------------------------+--------------------------+8.4. Media Clock Source Parameters Registry
this one is the twin of the last registry 👯♀️ The doc creates a new IANA subregistry called the Media Clock Source Parameters registry, under the IANA SDP Parameters registry. Each entry has:
Name: the token used in the SDP description (mediaclk-param-name)Long name: a descriptive name for the media clock source typeReference: a pointer to the document that describes the SDP token (mediaclk-param-name) and the syntax for its optional value (mediaclk-param-value)
the initial values are below 💜
Future assignments are made through the Specification Required policy [RFC5226]. The Name field corresponds to a new value for mediaclk-param-name. The Reference must specify a syntax for mediaclk-param-value.
+----------+-----------------------------+--------------------------+
| Name | Long Name | Reference |
+----------+-----------------------------+--------------------------+
| sender | Asynchronously Generated | This document, Section 5 |
| | Media Clock | |
| | | |
| direct | Direct-Referenced Media | This document, Section 5 |
| | Clock | |
| | | |
| IEEE1722 | IEEE1722 Media Stream | This document, Section 5 |
| | Identifier | |
+----------+-----------------------------+--------------------------+8.5. Source-Level Attributes
[RFC5576] requires new source-level attributes to be registered with the IANA registry named "att-field (source level)". so yeah, that's the rule for these 🎀
8.5.1. Source-Level Timestamp Reference Clock Attribute
the source-level SDP attribute "ts-refclk" from this doc gets registered with the "att-field (source level)" IANA registry of SDP Parameters, following Figure 10 🌈
8.5.2. Source-Level Media Clock Attribute
the source-level SDP attribute "mediaclk" from this doc gets registered with the "att-field (source level)" IANA registry of SDP Parameters, following Figure 11 ⭐
9. Acknowledgements
big thank-you to Magnus Westerlund and Paul Kyzivat 🫶 their comments led to important improvements in this doc, and the authors wanted that on record 🌸
10. References
10.1. Normative References
here are the normative references, copied out in full 📚
[IEEE1588-2002]
IEEE, "1588-2002 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", October 2002,
<http://standards.ieee.org/findstds/
standard/1588-2002.html>.
[IEEE1588-2008]
IEEE, "1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", July 2008,
<http://standards.ieee.org/findstds/
standard/1588-2008.html>.
[IEEE1722] IEEE, "1722-2001 - IEEE Standard for Layer 2 Transport
Protocol for Time Sensitive Applications in a Bridged
Local Area Network", May 2011,
<http://standards.ieee.org/findstds/
standard/1722-2011.html>.
[IEEE802.1AS-2011]
IEEE, "802.1AS-2011 - IEEE Standard for Local and
Metropolitan Area Networks - Timing and Synchronization
for Time-Sensitive Applications in Bridged Local Area
Networks", February 2011,
<http://standards.ieee.org/findstds/
standard/802.1AS-2011.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013.10.2. Informative References 🔍✨
okay so this is the bonus reading list 📚 these aren't required to implement the spec, but they're where all the background lives. bestie, the audio standards and GPS docs are lowkey iconic 🎧🛰️
- [AES11-2009] Audio Engineering Society, "AES11-2009: AES recommended practice for digital audio engineering - Synchronization of digital audio equipment in studio operations", February 2010,
http://www.aes.org/standards/. - [IEEE802.1BA-2011] IEEE, "802.1BA-2011 - IEEE Standard for Local and metropolitan area networks -- Audio Video Bridging (AVB) Systems", September 2011,
http://standards.ieee.org/findstds/standard/802.1BA-2011.html. - [IS-GPS-200F] Global Positioning Systems Directorate, "Navstar GPS Space Segment/Navigation User Segment Interfaces", IS-GPS-200F , September 2011,
http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf. - [Olsen] Olsen, D., "Time Accuracy Requirements in Audio Networks", April 2007,
http://www.ieee802.org/1/files/public/docs2007/as-dolsen-time-accuracy-0407.pdf. - [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983.
- [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
- [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
- [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, March 2014.
- [RFC7272] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, June 2014.
- [SMPTE-318M-1999] Society of Motion Picture & Television Engineers, "Television and Audio - Synchronization of 59.94- or 50-Hz Related Video and Audio Systems in Analog and Digital Areas - Reference Signals", ST 318:1999,
http://standards.smpte.org/.
Authors' Addresses 🫶🌸
these are the humans who wrote it, so you know exactly who to thank (or tag) 💅
Aidan Williams
Audinate
Level 1, 458 Wattle St
Ultimo, NSW 2007
Australia
Phone: +61 2 8090 1000
Fax: +61 2 8090 1001
EMail: aidan.williams@audinate.com
URI: http://www.audinate.com/
Kevin Gross
AVA Networks
Boulder, CO
US
EMail: kevin.gross@avanw.com
URI: http://www.avanw.com/
Ray van Brandenburg
TNO
Brassersplein 2
Delft 2612CT
The Netherlands
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Hans Stokking
TNO
Brassersplein 2
Delft 2612CT
The Netherlands
EMail: hans.stokking@tno.nl📦 where this page comes from
- ietf: rfc7273 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms