Support for Multiple Clock Rates in an RTP Session
updates
- rfc-3550 — RTP: A Transport Protocol for Real-Time Applications
Extracted elements (16)
A proposal to define a single unified fixed clock rate for all payloads (Wenger and Perkins, AVT-VAR-RATE) was considered as an alternative solution but was rejected at IETF 61. The approach chosen instead mandates different SSRCs per clock rate when RTCP is in use.
The monotonic timestamp approach (timestamp increments based on elapsed time * current clock rate) produces incorrect jitter calculations at clock rate transitions because the receiver cannot determine the capture time without depending on previous potentially-lost or reordered packets.
The non-monotonic timestamp approach (timestamp = capture_time * clock_rate) produces correct jitter calculations but yields non-monotonically increasing timestamps. RFC 3550 requires the sampling clock to increment monotonically but does not require the RTP timestamp itself to increment monotonically, making this approach technically compliant. Survey data from SIPit26 and open source implementations showed this is the most common legacy approach.
Using a different SSRC for each clock rate was the original intent of RTP (per RFC 3550 Section 5.2), as it avoids ambiguity about which clock rate applies to RTCP fields. However, changing SSRC can be a problem for implementations designed for unicast addresses where multiple SSRCs are a corner case, and lip synchronization may be disrupted before the first RTCP SR is received.
Legacy RTP implementations (libccrtp 2.0.2, libmediastreamer0 2.6.0, libpjmedia 1.0) use the non-monotonic timestamp formula (timestamp = capture_time * clock_rate). Some of these use gettimeofday(2) which is not guaranteed to increment monotonically, e.g., when the clock is adjusted by NTP.
The Android RTP Stack 4.0.3 changes the SSRC each time the payload format changes (the different-SSRC approach described in Section 3.1), which aligns with the recommended behavior for senders with RTCP.
An RTP Receiver MUST be able to handle a compound RTCP packet with multiple SR packets.
An RTP Receiver MUST calculate the jitter using the formula D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) - (arrival_time_i * clock_rate_i - timestamp_i), which correctly handles multiple clock rates.
An RTP Sender with RTCP turned off SHOULD use a different SSRC for each different clock rate but MAY use different clock rates on the same SSRC as long as the RTP timestamp is calculated using the start_offset/capture_start formula defined in this section.
An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST be used if the clock rate switches back to a value already seen in the RTP stream.
The RTP extension defined by Perkins & Schierl (RFC 6051) MAY be used to accelerate synchronization when an RTP sender with RTCP changes clock rates.
To accelerate lip synchronization, the next compound RTCP packet sent by the RTP sender MUST contain multiple SR packets: the first containing the mapping for the current clock rate and subsequent SR packets containing mappings for other clock rates seen during the last period.
Clock rate is the multiplier used to convert from a wallclock value in seconds to an equivalent RTP timestamp value (without the fixed random offset). RFC 3550 uses synonymous terms including 'clock frequency', 'media clock rate', 'timestamp unit', 'timestamp frequency', and 'RTP timestamp clock rate'.
For an RTP Sender without RTCP, when the clock rate changes the start_offset and capture_start are updated as: start_offset += (capture_time - capture_start) * previous_clock_rate; capture_start = capture_time. The RTP timestamp is then: timestamp = (capture_time - capture_start) * clock_rate + start_offset.
RTCP packets contain multiple fields measured in clock-rate units, including: RTP timestamp in SR packets, interarrival jitter in RR packets, min/max/mean/dev_jitter in XR Summary Blocks (RFC 3611), interarrival jitter in IJ packets (RFC 5450), RTP timestamp in SMPTETC packets (RFC 5484), and jitter fields in RSI blocks (RFC 5760).
When the Section 4.1 algorithm (different SSRC per clock rate) is used, the security considerations of RFC 3550 apply unchanged. The Section 4.2 algorithm (same SSRC, without RTCP) is new: although the RTP timestamp is initialized with a random value, it depends on current and previous clock rates, which may introduce a security vulnerability not analyzed in RFC 3550.