RFC 7160
Support for Multiple Clock Rates in an RTP Session
RFC 7160: Support for Multiple Clock Rates in an RTP Session 🎀
Okay bestie, let's get into this one! 💖 RFC 7160 was written by M. Petit-Huguenin (from Impedance Mismatch) and G. Zorn, Ed. (from Network Zen) and published in April 2014 as a Standards Track document ✨. It's part of the IETF stream, and its ISSN is 2070-1721. The big news is that it updates RFC 3550, which means it changes parts of the core RTP spec 👑. It doesn't obsolete anything.
Abstract ✨
This doc clears up the RTP spec on how you're supposed to use different clock rates inside one RTP session 🦋. It also gives guidance so that legacy RTP implementations using multiple clock rates can still talk to implementations that use the algorithm described here 🫶. And yes, it updates RFC 3550 🌸.
Status of This Memo
This is an Internet Standards Track document 💅.
This document is a product of the Internet Engineering Task Force (IETF) 🌈. It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🧚.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7160 💜.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🔥.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 🙈.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . 4
3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Monotonic Timestamps . . . . . . . . . . . . . . . . 5
3.2.2. Non-monotonic Timestamps . . . . . . . . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . 6
4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 6
4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Example Values . . . . . . . . . . . . . . . . . . . 10
Appendix B. Using a Fixed Clock Rate . . . . . . . . . . . . . . 12
Appendix C. Behavior of Legacy Implementations . . . . . . . . . 12
C.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . 12
C.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 12
C.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . 13
C.4. Android RTP Stack 4.0.3 . . . . . . . . . . . . . . . . . 131. Introduction ✨
Okay so, the clock rate is a parameter of the payload format. RTP and RTCP (RTP Control Protocol) identify it by the payload type value 🦋. It's often the same as the sampling rate, but not always. The G722 and MPA audio codecs are the classic examples of that difference [RFC3551] 🎧.
An RTP sender can switch between payloads during the lifetime of an RTP session. Since clock rates are defined by the payload format, the clock rate can also change in the middle of a session 😭. Schulzrinne, et al. [RFC3550] lists using multiple clock rates as one of the reasons not to use different payloads on the same Synchronization Source (SSRC) 🙈. The problem is that people didn't always follow that advice. Some RTP implementations change the payload on the same SSRC even when the payloads use different clock rates 💀.
This creates three problems 💅:
- The method used to calculate the RTP timestamp field in an RTP packet is underspecified.
- When the same SSRC is used for different clock rates, it's hard to tell which clock rate was used for the RTP timestamp field in an RTCP Sender Report (SR) packet.
- When the same SSRC is used for different clock rates, it's hard to tell which clock rate was used for the interarrival jitter field in an RTCP Receiver Report (RR) packet.
Table 1 is a non-exhaustive list of fields in RTCP packets that use a clock rate as their unit 🌈:
+---------------------+------------------+------------+
| Field name | RTCP packet type | Reference |
+---------------------+------------------+------------+
| RTP timestamp | SR | [RFC3550] |
| | | |
| Interarrival jitter | RR | [RFC3550] |
| | | |
| min_jitter | XR Summary Block | [RFC3611] |
| | | |
| max_jitter | XR Summary Block | [RFC3611] |
| | | |
| mean_jitter | XR Summary Block | [RFC3611] |
| | | |
| dev_jitter | XR Summary Block | [RFC3611] |
| | | |
| Interarrival jitter | IJ | [RFC5450] |
| | | |
| RTP timestamp | SMPTETC | [RFC5484] |
| | | |
| Jitter | RSI Jitter Block | [RFC5760] |
| | | |
| Median jitter | RSI Stats Block | [RFC5760] |
+---------------------+------------------+------------+
Table 1Section 3 and its subsections try to list all the algorithms we know were being used in existing RTP implementations when this was written. Those sections are not normative 🫧. Section 4 and its subsections recommend one unique algorithm that modifies RFC 3550. Those sections are normative 👑.
2. Terminology 🎀
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 RFC 2119 [RFC2119] 💖.
Here are the extra terms this doc uses 🧚:
Clock rate : The multiplier used to convert a wallclock value in seconds into an equivalent RTP timestamp value (without the fixed random offset). RFC 3550 uses a bunch of different terms, like "clock frequency", "media clock rate", "timestamp unit", "timestamp frequency", and "RTP timestamp clock rate", as synonyms for clock rate. Fun, right? 🙃
RTP Sender : A logical network element that sends RTP packets, sends RTCP SR packets, and receives RTCP reception report blocks 📡.
RTP Receiver : A logical network element that receives RTP packets, receives RTCP SR packets, and sends RTCP reception report blocks 📥.
3. Legacy RTP 🦕
These sections describe the different ways legacy RTP implementations behave when multiple clock rates are used. "Legacy RTP" means RFC 3550 without the modifications this document introduces 🕰️.
3.1. Different SSRC 🌸
One way to manage multiple clock rates is to use a different SSRC for each clock rate. Then there's no ambiguity about which clock rate the fields in the RTCP packets are using, which is super clean ✨. This also seems to be the original intent of RTP, as you can deduce from points 2 and 3 of Section 5.2 of RFC 3550 🔍.
BUT (and this is a big but) changing the SSRC can be a problem for implementations that were only designed for unicast IP addresses, where having multiple SSRCs is treated as a corner case 😬. Lip synchronization can also be a problem in the gap between the start of the new stream and the first RTCP SR packet 👄.
3.2. Same SSRC 🦋
The simplest way to manage multiple clock rates is to use the same SSRC for all of the payload types, no matter their clock rates 💅.
Unfortunately, there's no clear definition of how the RTP timestamp should be calculated in this case 💀. The next subsections present the algorithms that are currently in use.
3.2.1. Monotonic Timestamps 📈
This method of calculating the RTP timestamp makes sure the value increases monotonically. The formula is:
timestamp = previous_timestamp
+ (current_capture_time - previous_capture_time)
* current_clock_rateThe problem with this method is that the jitter calculation on the receiving side gives an invalid result during the transition between two clock rates, as shown in Table 2 (Appendix A) 😵. Here's the setup: capture and arrival times are measured in seconds, starting from the beginning of the capture of the first packet. The clock rate is measured in Hz. The RTP timestamp doesn't include the random offset. And the transit, jitter, and average jitter all use the clock rate as a unit 🧠.
To calculate the correct transit time on the receiving side, you can use these formulas 🔧:
current_capture_time = (current_timestamp - previous_timestamp) / current_clock_rate + previous_capture_timetransit = current_clock_rate * (arrival_time - current_capture_time)previous_capture_time = current_capture_time
The main problem with this method, on top of the fact that the jitter calculation described in RFC 3550 can't be used, is that it depends on the previous RTP packets. Those can get reordered or lost in the network 🌪️.
3.2.2. Non-monotonic Timestamps 🌙
An alternate way to generate RTP timestamps is this formula:
timestamp = capture_time * clock_rateWith this formula, the jitter calculation is correct, but the RTP timestamp values no longer increase monotonically, as shown in Table 3 (Appendix A) 🫠. RFC 3550 says that "[t]he sampling instant MUST be derived from a clock that increments monotonically . . .", but it doesn't say the RTP timestamp has to increment monotonically 🤓.
The upside of this method is that it works with the jitter calculation described in RFC 3550, as long as the correct clock rates are used. Based on a survey done at SIPit26 and a survey of open source implementations (see Appendix C), it looks like most implementations are doing this 🎉.
4. Recommendations 💜
The following subsections describe behavioral recommendations for RTP senders (with and without RTCP) and RTP receivers 🫶.
4.1. RTP Sender (with RTCP) 💖
okay bestie, if your RTP sender has RTCP turned on, it MUST use a different SSRC for each different clock rate 🎀 and if the clock rate switches back to a value that already showed up earlier in the RTP stream, the sender MUST send an RTCP BYE and MUST use a new SSRC. no cap, that's the whole vibe 💅
to speed up lip sync ✨ the next compound RTCP packet the RTP sender sends MUST contain multiple SR packets. the first SR has the mapping for the current clock rate, and the SR packet(s) after it have the mappings for the other clock rates seen during the last period. it's giving teamwork 🫶
the RTP extension from Perkins & Schierl [RFC6051] MAY be used to make the synchronization even faster 🚀
4.2. RTP Sender (without RTCP) 🦋
this one is for senders with RTCP turned off 🌸 (so the RTP Sender and RTP Receiver bandwidth modifiers [RFC3556] are set to 0). these senders SHOULD use a different SSRC for each different clock rate, but they MAY also keep the same SSRC across different clock rates, as long as the RTP timestamp is calculated the way I'm about to show you. it's a whole thing, but it's lowkey iconic 👑
every time the clock rate changes, start_offset and capture_start get updated like this:
start_offset += (capture_time - capture_start) * previous_clock_rate
capture_start = capture_timefor the very first RTP packet, the values start out like this:
start_offset = random_initial_offset
capture_start = capture_timeafter updating those values (if needed), the RTP timestamp is calculated with this formula:
timestamp = (capture_time - capture_start) * clock_rate
+ start_offsetquick reminder: in all of these formulas, capture_start is the first instant that the new timestamp rate is used 🧚 and the output of this method is shown in Table 4 (Appendix A) 🍓
4.3. RTP Receiver 🌈
RTP Receivers MUST calculate the jitter with this formula, no skipping allowed 💀
D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j)
- (arrival_time_i * clock_rate_i - timestamp_i)and an RTP Receiver MUST be able to handle a compound RTCP packet that has multiple SR packets ✨ receivers really have to keep up, periodt 💅
5. Security Considerations 🔥
okay this part is serious, so read it carefully 🙈
when the algorithm from Section 4.1 is used, the security considerations described in RFC 3550 apply 💜
the algorithm from Section 4.2 is brand new, so its security properties were NOT looked at in RFC 3550 😭 the RTP timestamp still starts from a random value like before, but the timestamp value depends on the current and previous clock rates. this may or may not introduce a security vulnerability in the protocol. nobody knows yet, so keep your eyes open 👀
6. Acknowledgements 🫶
huge thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu, Jonathan Lennox, Barry Leiba, David Harrington, Stephen Farrell, Spencer Dawkins, Wassim Haddad, and Magnus Westerlund for the comments, suggestions, and questions that made this document better 💖
thanks to Bo Burman, who provided the values in Table 4 of Appendix A 🍓
and thanks to Robert Sparks and the attendees of SIPit 26 for the survey on multiple clock rates interoperability 🎀
7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.7.2. Informative References
[AVT-VAR-RATE]
Wenger, S. and C. Perkins, "RTP Timestamp Frequency for
Variable Rate Audio Codecs", Work in Progress, October
2004.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
3556, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC
5484, March 2009.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.Appendix A. Example Values 🧾
the tables below show the timestamp and jitter values you get when the different methods from the text are used 🦋
the values are purely exemplary, illustrative, and non-normative, so they're just here to help you vibe with the math ✨
+-------+-------+-----------+---------+---------+--------+----------+
| Capt. | Clock | RTP | Arrival | Transit | Jitter | Average |
| time | rate | timestamp | time | | | jitter |
+-------+-------+-----------+---------+---------+--------+----------+
| 0 | 8000 | 0 | 0.1 | 800 | | |
| | | | | | | |
| 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| | | | | | | |
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| | | | | | | |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| | | | | | | |
| 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 |
| | | | | | | |
| 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 |
| | | | | | | |
| 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 |
| | | | | | | |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 |
| | | | | | | |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 2: Monotonic Timestamps
+-------+-------+-----------+---------+---------+--------+----------+
| Capt. | Clock | RTP | Arrival | Transit | Jitter | Average |
| time | rate | timestamp | time | | | jitter |
+-------+-------+-----------+---------+---------+--------+----------+
| 0 | 8000 | 0 | 0.1 | 800 | | |
| | | | | | | |
| 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| | | | | | | |
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| | | | | | | |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| | | | | | | |
| 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 |
| | | | | | | |
| 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 |
| | | | | | | |
| 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 |
| | | | | | | |
| 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 |
| | | | | | | |
| 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 3: Non-monotonic Timestamps
+-------+-------+-----------+---------+---------+--------+----------+
| Capt. | Clock | RTP | Arrival | Transit | Jitter | Average |
| time | rate | timestamp | time | | | jitter |
+-------+-------+-----------+---------+---------+--------+----------+
| 0 | 8000 | 0 | 0.1 | 800 | | |
| | | | | | | |
| 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| | | | | | | |
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| | | | | | | |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| | | | | | | |
| 0.08 | 16000 | 640 | 0.18 | 1600 | 0 | 0 |
| | | | | | | |
| 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 |
| | | | | | | |
| 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 |
| | | | | | | |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 0 | 0 |
| | | | | | | |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 4: Recommended Method for RTP Sender (without RTCP)Appendix B. Using a Fixed Clock Rate 🎀
there was another way to fix the multiple clock rate problem, proposed by Wenger and Perkins [AVT-VAR-RATE] 💭 that doc wanted to define one unified clock rate, but the proposal got rejected at IETF 61 💀 oof
Appendix C. Behavior of Legacy Implementations 🕰️
C.1. libccrtp 2.0.2
this library uses the formula described in Section 3.2.2 🍓
be careful here though: it uses gettimeofday(2), which is NOT guaranteed to increment monotonically (for example, when the clock is adjusted by NTP) 😬
C.2. libmediastreamer0 2.6.0
this library (which uses the oRTP library) uses the formula described in Section 3.2.2 🌸
in some environments it also uses gettimeofday(2), which is not guaranteed to increment monotonically 👀
C.3. libpjmedia 1.0
this library uses the formula described in Section 3.2.2 💜
C.4. Android RTP Stack 4.0.3
this library changes the SSRC each time the format changes, as described in Section 3.1 📱
Authors' Addresses 💌
Marc Petit-Huguenin
Impedance Mismatch
EMail: petithug@acm.org
Glen Zorn (editor)
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 8-1000-4155
EMail: glenzorn@gmail.com📦 where this page comes from
- ietf: rfc7160 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms