]> Impedance Mismatch

petithug@acm.org

Network Zen

227/358 Thanon Sanphawut Bang Na Bangkok 10260 Thailand +66 (0) 8-1000-4155 glenzorn@gmail.com

This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550.

The clock rate is a parameter of the payload format as identified in RTP and RTCP (RTP Control Protocol) by the payload type value. It is often defined as being the same as the sampling rate but that is not always the case (see, for example, the G722 and MPA audio codecs ). An RTP sender can switch between different payloads during the lifetime of an RTP session and because clock rates are defined by payload format, it is possible that the clock rate will also vary during an RTP session. Schulzrinne, et al.  lists using multiple clock rates as one of the reasons to not use different payloads on the same Synchronization Source (SSRC). Unfortunately, this advice has not always been followed and some RTP implementations change the payload in the same SSRC, even if the different 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 is difficult to know what 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 is difficult to know what clock rate was used for the interarrival jitter field in an RTCP Receiver Report (RR) packet. contains a non-exhaustive list of fields in RTCP packets that uses a clock rate as a unit: Field name RTCP packet type Reference RTP timestamp SR Interarrival jitter RR min_jitter XR Summary Block max_jitter XR Summary Block mean_jitter XR Summary Block dev_jitter XR Summary Block Interarrival jitter IJ RTP timestamp SMPTETC Jitter RSI Jitter Block Median jitter RSI Stats Block and its subsections try to list all of the algorithms known to be used in existing RTP implementations at the time of writing. These sections are not normative. and its subsections recommend a unique algorithm that modifies RFC 3550. These sections are normative.

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 . In addition, this document uses the following terms: The multiplier used to convert from a wallclock value in seconds to an equivalent RTP timestamp value (without the fixed random offset). Note that RFC 3550 uses various terms like "clock frequency", "media clock rate", "timestamp unit", "timestamp frequency", and "RTP timestamp clock rate" as synonymous to clock rate. A logical network element that sends RTP packets, sends RTCP SR packets, and receives RTCP reception report blocks. A logical network element that receives RTP packets, receives RTCP SR packets, and sends RTCP reception report blocks.

The following sections describe the various ways in which legacy RTP implementations behave when multiple clock rates are used. "Legacy RTP" refers to RFC 3550 without the modifications introduced by this document.

One way of managing multiple clock rates is to use a different SSRC for each different clock rate, as in this case there is no ambiguity on the clock rate used by fields in the RTCP packets. This method also seems to be the original intent of RTP as can be deduced from points 2 and 3 of Section 5.2 of RFC 3550. On the other hand, changing the SSRC can be a problem for some implementations designed to work only with unicast IP addresses, where having multiple SSRCs is considered a corner case. Lip synchronization can also be a problem in the interval between the beginning of the new stream and the first RTCP SR packet.

The simplest way to manage multiple clock rates is to use the same SSRC for all of the payload types regardless of the clock rates. Unfortunately, there is no clear definition on how the RTP timestamp should be calculated in this case. The following subsections present the algorithms currently in use.

This method of calculating the RTP timestamp ensures that the value increases monotonically. The formula used by this method is as follows:

The 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 (Appendix A). The capture and arrival time are measured in seconds, starting at the beginning of the capture of the first packet; clock rate is measured in Hz; the RTP timestamp does not include the random offset; and the transit, jitter, and average jitter use the clock rate as a unit. Calculating the correct transit time on the receiving side can be done by using the following formulas: current_capture_time = (current_timestamp - previous_timestamp) / current_clock_rate + previous_capture_time transit = current_clock_rate * (arrival_time - current_capture_time) previous_capture_time = current_capture_time The main problem with this method, in addition to the fact that the jitter calculation described in RFC 3550 cannot be used, is that it is dependent on the previous RTP packets, which can be reordered or lost in the network.

An alternate way of generating the RTP timestamps is to use the following formula:

With this formula, the jitter calculation is correct but the RTP timestamp values are no longer increasing monotonically as shown in (Appendix A). RFC 3550 states that "[t]he sampling instant MUST be derived from a clock that increments monotonically . . .", but it does not say that the RTP timestamp must increment monotonically. The advantage with this method is that it works with the jitter calculation described in RFC 3550, as long as the correct clock rates are used. It seems that this is what most implementations are using (based on a survey done at SIPit26 and on a survey of open source implementations, see Appendix C).

The following subsections describe behavioral recommendations for RTP senders (with and without RTCP) and RTP receivers.

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. To accelerate lip synchronization, the next compound RTCP packet sent by the RTP sender MUST contain multiple SR packets, the first one containing the mapping for the current clock rate and the subsequent SR packet(s) containing the mapping for the other clock rates seen during the last period. The RTP extension defined by Perkins & Schierl MAY be used to accelerate the synchronization.

An RTP Sender with RTCP turned off (i.e., having set the RTP Sender and RTP Receiver bandwidth modifiers to 0) 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 as explained below: Each time the clock rate changes, the start_offset and capture_start values are calculated with the following formulas:

For the first RTP packet, the values are initialized with the following values:

After eventually updating these values, the RTP timestamp is calculated with the following formula:

Note that in all the formulas, capture_start is the first instant that the new timestamp rate is used. The output of the above method is exemplified in (Appendix A).

An RTP Receiver MUST calculate the jitter using the following formula:

An RTP Receiver MUST be able to handle a compound RTCP packet with multiple SR packets.

When the algorithm described in is used, the security considerations described in RFC 3550 apply. The algorithm described in is new and so its security properties were not considered in RFC 3550. Although the RTP timestamp is initialized with a random value like before, the timestamp value depends on the current and previous clock rates; this may or may not introduce a security vulnerability in the protocol.

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 comments, suggestions, and questions that helped to improve this document. Thanks to Bo Burman, who provided the values in of Appendix A. Thanks to Robert Sparks and the attendees of SIPit 26 for the survey on multiple clock rates interoperability.

&rfc2119; &rfc3550; &rfc3551; &rfc3556; &rfc3611; &rfc5450; &rfc5484; &rfc5760; &rfc6051; This memo discusses the problems of audio codecs with variable external sampling rates. Historically, for audio codecs, the RTP timestamp frequency was chosen to match the sampling rate of the audio codec. However, this choice is nowadays more difficult to justify, because of the advent of audio codecs (and, even more important, practical use cases) that support multiple sample rates and the switch between the sample rates during the lifetime of an RTP session. This Internet draft addresses the problem by suggesting that RTP Payload RFCs for such codecs to utilize a single, high, unified RTP timestamp frequency.

The following tables illustrate the timestamp and jitter values produced when the various methods discussed in the text are used. The values shown are purely exemplary, illustrative, and non-normative. Capt. time Clock rate RTP timestamp Arrival time Transit Jitter Average 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 Capt. time Clock rate RTP timestamp Arrival time Transit Jitter Average 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 Capt. time Clock rate RTP timestamp Arrival time Transit Jitter Average 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

An alternate way of fixing the issue with using multiple clock rates was proposed by Wenger and Perkins . This document proposed to define a unified clock rate, but the proposal was rejected at IETF 61.

This library uses the formula described in . Note that this library uses gettimeofday(2) which is not guaranteed to increment monotonically (e.g., when the clock is adjusted by NTP).

This library (which uses the oRTP library) uses the formula described in . Note that in some environments this library uses gettimeofday(2), which is not guaranteed to increment monotonically.

This library uses the formula described in .

This library changes the SSRC each time the format changes, as described in .