summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7160.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7160.txt')
-rw-r--r--doc/rfc/rfc7160.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7160.txt b/doc/rfc/rfc7160.txt
new file mode 100644
index 0000000..74c26c0
--- /dev/null
+++ b/doc/rfc/rfc7160.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Petit-Huguenin
+Request for Comments: 7160 Impedance Mismatch
+Updates: 3550 G. Zorn, Ed.
+Category: Standards Track Network Zen
+ISSN: 2070-1721 April 2014
+
+
+ Support for Multiple Clock Rates in an RTP Session
+
+Abstract
+
+ 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.
+
+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. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ 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, as 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 are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 1]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+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 . . . . . . . . . . . . . . . . . 13
+
+1. Introduction
+
+ 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
+ [RFC3551]).
+
+ 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. [RFC3550] 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.
+
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 2]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+ This creates three problems:
+
+ o The method used to calculate the RTP timestamp field in an RTP
+ packet is underspecified.
+
+ o 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.
+
+ o 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.
+
+ Table 1 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 | [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 1
+
+ Section 3 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.
+
+ Section 4 and its subsections recommend a unique algorithm that
+ modifies RFC 3550. These sections are normative.
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 3]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+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].
+
+ In addition, this document uses the following terms:
+
+ Clock rate 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.
+
+ 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
+
+ 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.
+
+3.1. Different SSRC
+
+ 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.
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 4]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+3.2. Same SSRC
+
+ 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.
+
+3.2.1. Monotonic Timestamps
+
+ This method of calculating the RTP timestamp ensures that the value
+ increases monotonically. The formula used by this method is as
+ follows:
+
+ timestamp = previous_timestamp
+ + (current_capture_time - previous_capture_time)
+ * current_clock_rate
+
+ 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 Table 2 (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:
+
+ 1. current_capture_time = (current_timestamp - previous_timestamp) /
+ current_clock_rate + previous_capture_time
+
+ 2. transit = current_clock_rate * (arrival_time -
+ current_capture_time)
+
+ 3. 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.
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 5]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+3.2.2. Non-monotonic Timestamps
+
+ An alternate way of generating the RTP timestamps is to use the
+ following formula:
+
+ timestamp = capture_time * clock_rate
+
+ With this formula, the jitter calculation is correct but the RTP
+ timestamp values are no longer increasing monotonically as shown in
+ Table 3 (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).
+
+4. Recommendations
+
+ The following subsections describe behavioral recommendations for RTP
+ senders (with and without RTCP) and RTP receivers.
+
+4.1. RTP Sender (with RTCP)
+
+ 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 [RFC6051] MAY be used
+ to accelerate the synchronization.
+
+4.2. RTP Sender (without RTCP)
+
+ An RTP Sender with RTCP turned off (i.e., having set the RTP Sender
+ and RTP Receiver bandwidth modifiers [RFC3556] 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:
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 6]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+ Each time the clock rate changes, the start_offset and capture_start
+ values are calculated with the following formulas:
+
+ start_offset += (capture_time - capture_start) * previous_clock_rate
+ capture_start = capture_time
+
+ For the first RTP packet, the values are initialized with the
+ following values:
+
+ start_offset = random_initial_offset
+ capture_start = capture_time
+
+ After eventually updating these values, the RTP timestamp is
+ calculated with the following formula:
+
+ timestamp = (capture_time - capture_start) * clock_rate
+ + start_offset
+
+ 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 Table 4 (Appendix A).
+
+4.3. RTP Receiver
+
+ An RTP Receiver MUST calculate the jitter using the following
+ formula:
+
+ D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j)
+ - (arrival_time_i * clock_rate_i - timestamp_i)
+
+ An RTP Receiver MUST be able to handle a compound RTCP packet with
+ multiple SR packets.
+
+5. Security Considerations
+
+ When the algorithm described in Section 4.1 is used, the security
+ considerations described in RFC 3550 apply.
+
+ The algorithm described in Section 4.2 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.
+
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 7]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+6. Acknowledgements
+
+ 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 Table 4 of
+ Appendix A.
+
+ 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.
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 8]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 9]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+Appendix A. Example Values
+
+ 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. | 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 10]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+ +-------+-------+-----------+---------+---------+--------+----------+
+ | 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 11]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+ +-------+-------+-----------+---------+---------+--------+----------+
+ | 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
+
+ An alternate way of fixing the issue with using multiple clock rates
+ was proposed by Wenger and Perkins [AVT-VAR-RATE]. This document
+ proposed to define a unified clock rate, but the proposal was
+ rejected at IETF 61.
+
+Appendix C. Behavior of Legacy Implementations
+
+C.1. libccrtp 2.0.2
+
+ This library uses the formula described in Section 3.2.2.
+
+ Note that this library uses gettimeofday(2) which is not guaranteed
+ to increment monotonically (e.g., 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.
+
+ Note that in some environments this library uses gettimeofday(2),
+ which is not guaranteed to increment monotonically.
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 12]
+
+RFC 7160 Multiple Clock Rates April 2014
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petit-Huguenin & Zorn Standards Track [Page 13]
+