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
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
在RTP会话中支持多个时钟速率
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.
本文件澄清了RTP规范中关于RTP会话中不同时钟速率的使用。它还提供了关于使用多个时钟速率的传统RTP实现如何与使用本文档中描述的算法的RTP实现进行互操作的指导。它更新了RFC3550。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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]).
时钟速率是有效负载类型值在RTP和RTCP（RTP控制协议）中标识的有效负载格式参数。它通常被定义为与采样率相同，但情况并非总是如此（例如，参见G722和MPA音频编解码器[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.
RTP发送方可以在RTP会话的生存期内在不同的有效负载之间切换，并且由于时钟速率由有效负载格式定义，因此时钟速率也可能在RTP会话期间发生变化。Schulzrinne等人[RFC3550]将使用多个时钟频率列为不在同一同步源（SSRC）上使用不同有效负载的原因之一。不幸的是，这一建议并不总是被遵循，一些RTP实现会改变同一SSRC中的有效负载，即使不同的有效负载使用不同的时钟速率。
This creates three problems:
这造成了三个问题：
o The method used to calculate the RTP timestamp field in an RTP packet is underspecified.
o 用于计算RTP数据包中RTP时间戳字段的方法未指定。
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 当相同的SSRC用于不同的时钟速率时，很难知道RTCP发送方报告（SR）数据包中的RTP时间戳字段使用了什么时钟速率。
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.
o 当相同的SSRC用于不同的时钟速率时，很难知道RTCP接收器报告（RR）数据包中的到达间抖动字段使用了什么时钟速率。
Table 1 contains a non-exhaustive list of fields in RTCP packets that uses a clock rate as a unit:
表1包含以时钟速率为单位的RTCP数据包中字段的非详尽列表：
+---------------------+------------------+------------+
| 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] |
+---------------------+------------------+------------+
+---------------------+------------------+------------+
| 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
表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.
第3节及其各小节试图列出在撰写本文时已知的在现有RTP实现中使用的所有算法。这些章节不规范。
Section 4 and its subsections recommend a unique algorithm that modifies RFC 3550. These sections are normative.
第4节及其小节推荐了修改RFC 3550的独特算法。这些章节是规范性的。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
时钟频率用于将以秒为单位的wallclock值转换为等效RTP时间戳值（无固定随机偏移）的乘法器。注意，RFC 3550使用诸如“时钟频率”、“媒体时钟速率”、“时间戳单元”、“时间戳频率”和“RTP时间戳时钟速率”等各种术语作为时钟速率的同义词。
RTP Sender A logical network element that sends RTP packets, sends RTCP SR packets, and receives RTCP reception report blocks.
RTP发送器发送RTP数据包、发送RTCP SR数据包和接收RTCP接收报告块的逻辑网络元件。
RTP Receiver A logical network element that receives RTP packets, receives RTCP SR packets, and sends RTCP reception report blocks.
RTP接收器接收RTP数据包、接收RTCP SR数据包并发送RTCP接收报告块的逻辑网络元件。
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.
以下部分描述了使用多个时钟速率时传统RTP实现的各种行为方式。“传统RTP”指未经本文件修改的RFC 3550。
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.
管理多个时钟速率的一种方法是对每个不同的时钟速率使用不同的SSRC，因为在这种情况下，RTCP数据包中的字段使用的时钟速率没有歧义。从RFC 3550第5.2节第2点和第3点可以推断，该方法似乎也是RTP的初衷。
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.
另一方面，更改SSRC对于一些仅用于单播IP地址的实现来说可能是一个问题，在这种情况下，拥有多个SSRC被视为一种极端情况。在新流的开始和第一个RTCP SR数据包之间的间隔内，Lip同步也可能是一个问题。
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.
管理多个时钟速率的最简单方法是对所有有效负载类型使用相同的SSRC，而不管时钟速率如何。
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.
不幸的是，在这种情况下，对于如何计算RTP时间戳没有明确的定义。以下小节介绍了当前使用的算法。
This method of calculating the RTP timestamp ensures that the value increases monotonically. The formula used by this method is as follows:
这种计算RTP时间戳的方法确保该值单调增加。该方法使用的公式如下：
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.
该方法的问题在于，在两个时钟频率之间的转换期间，接收侧的抖动计算给出了无效的结果，如表2（附录A）所示。捕获和到达时间以秒为单位测量，从捕获第一个分组开始；时钟频率以Hz为单位测量；RTP时间戳不包括随机偏移；传输、抖动和平均抖动以时钟频率为单位。
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
1. 当前捕获时间=（当前时间戳-上一次时间戳）/当前时钟速率+上一次捕获时间
2. transit = current_clock_rate * (arrival_time - current_capture_time)
2. 运输=当前时钟速率*（到达时间-当前捕获时间）
3. previous_capture_time = current_capture_time
3. 上一次捕获时间=当前捕获时间
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.
除了不能使用RFC 3550中描述的抖动计算之外，该方法的主要问题在于它依赖于先前的RTP数据包，这些数据包可以在网络中重新排序或丢失。
An alternate way of generating the RTP timestamps is to use the following formula:
生成RTP时间戳的另一种方法是使用以下公式：
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.
使用该公式，抖动计算是正确的，但RTP时间戳值不再如表3（附录A）所示单调增加。RFC 3550指出，“采样瞬间必须从单调递增的时钟中导出……”，但它并没有说RTP时间戳必须单调递增。
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).
这种方法的优点是，只要使用正确的时钟频率，它就可以与RFC3550中描述的抖动计算一起工作。这似乎是大多数实现所使用的（基于SIPit26的调查和开源实现的调查，见附录C）。
The following subsections describe behavioral recommendations for RTP senders (with and without RTCP) and RTP receivers.
以下小节描述了RTP发送方（有和没有RTCP）和RTP接收方的行为建议。
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.
RTCP已打开的RTP发送器必须为每个不同的时钟速率使用不同的SSRC。如果时钟速率切换回RTP流中已经看到的值，则必须发送RTCP BYE并使用新的SSRC。
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.
为了加速lip同步，RTP发送方发送的下一个复合RTCP数据包必须包含多个SR数据包，第一个包含当前时钟速率的映射，随后的SR数据包包含上一时段内看到的其他时钟速率的映射。
The RTP extension defined by Perkins & Schierl [RFC6051] MAY be used to accelerate the synchronization.
Perkins&Schierl[RFC6051]定义的RTP扩展可用于加速同步。
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:
RTP关闭的RTP发送方（即，已将RTP发送方和RTP接收方带宽修饰符[RFC3556]设置为0）应为每个不同的时钟速率使用不同的SSRC，但只要按照以下说明计算RTP时间戳，则可以在同一SSRC上使用不同的时钟速率：
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
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:
对于第一个RTP数据包，使用以下值初始化值：
start_offset = random_initial_offset capture_start = capture_time
开始偏移=随机初始偏移捕获开始=捕获时间
After eventually updating these values, the RTP timestamp is calculated with the following formula:
最终更新这些值后，使用以下公式计算RTP时间戳：
timestamp = (capture_time - capture_start) * clock_rate
+ start_offset
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).
请注意，在所有公式中，capture_start是使用新时间戳速率的第一个瞬间。表4（附录A）举例说明了上述方法的输出。
An RTP Receiver MUST calculate the jitter using the following formula:
RTP接收器必须使用以下公式计算抖动：
D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j)
- (arrival_time_i * clock_rate_i - timestamp_i)
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.
RTP接收器必须能够处理包含多个SR数据包的复合RTCP数据包。
When the algorithm described in Section 4.1 is used, the security considerations described in RFC 3550 apply.
当使用第4.1节中描述的算法时，RFC 3550中描述的安全注意事项适用。
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.
第4.2节中描述的算法是新的，因此RFC 3550中未考虑其安全属性。尽管RTP时间戳像以前一样用随机值初始化，但时间戳值取决于当前和先前的时钟速率；这可能会也可能不会在协议中引入安全漏洞。
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.
感谢科林·帕金斯、阿里·C·贝根、哈拉尔·阿尔韦斯特朗、秦武、乔纳森·伦诺克斯、巴里·莱巴、大卫·哈林顿、斯蒂芬·法雷尔、斯宾塞·道金斯、瓦西姆·哈达德和马格努斯·韦斯特隆德的评论、建议和问题，帮助改进了本文件。
Thanks to Bo Burman, who provided the values in Table 4 of Appendix A.
感谢Bo Burman，他提供了附录A表4中的数值。
Thanks to Robert Sparks and the attendees of SIPit 26 for the survey on multiple clock rates interoperability.
感谢Robert Sparks和SIPit 26的与会者对多时钟频率互操作性的调查。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[AVT-VAR-RATE] Wenger, S. and C. Perkins, "RTP Timestamp Frequency for Variable Rate Audio Codecs", Work in Progress, October 2004.
[AVT-VAR-RATE]Wenger，S.和C.Perkins，“变速率音频编解码器的RTP时间戳频率”，正在进行的工作，2004年10月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556]Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, March 2009.
[RFC5450]Singer，D.和H.Desneni，“RTP流中的传输时间偏移”，RFC 54502009年3月。
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, March 2009.
[RFC5484]Singer，D.“将时间码与RTP流相关联”，RFC 5484，2009年3月。
[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.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051]Perkins，C.和T.Schierl，“RTP流的快速同步”，RFC 60512010年11月。
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 |
+-------+-------+-----------+---------+---------+--------+----------+
+-------+-------+-----------+---------+---------+--------+----------+
| 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
表2：单调时间戳
+-------+-------+-----------+---------+---------+--------+----------+
| 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 |
+-------+-------+-----------+---------+---------+--------+----------+
+-------+-------+-----------+---------+---------+--------+----------+
| 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
表3：非单调时间戳
+-------+-------+-----------+---------+---------+--------+----------+
| 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 |
+-------+-------+-----------+---------+---------+--------+----------+
+-------+-------+-----------+---------+---------+--------+----------+
| 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)
表4:RTP发送方的推荐方法（无RTCP）
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.
温格和帕金斯[AVT-VAR-RATE]提出了使用多个时钟频率解决问题的另一种方法。本文件建议定义统一的时钟速率，但该建议在IETF 61上被拒绝。
This library uses the formula described in Section 3.2.2.
该库使用第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).
请注意，此库使用gettimeofday（2），它不保证单调递增（例如，当时钟由NTP调整时）。
This library (which uses the oRTP library) uses the formula described in Section 3.2.2.
该库（使用oRTP库）使用第3.2.2节中描述的公式。
Note that in some environments this library uses gettimeofday(2), which is not guaranteed to increment monotonically.
请注意，在某些环境中，该库使用gettimeofday（2），这不能保证单调递增。
This library uses the formula described in Section 3.2.2.
该库使用第3.2.2节中描述的公式。
This library changes the SSRC each time the format changes, as described in Section 3.1.
如第3.1节所述，每次格式更改时，该库都会更改SSRC。
Authors' Addresses
作者地址
Marc Petit-Huguenin Impedance Mismatch
Marc Petit Huguenin阻抗失配
EMail: petithug@acm.org
EMail: petithug@acm.org
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
格伦·佐恩（编辑）网络禅227/358泰国曼谷Thnon Sanphawut Bang Na 10260
Phone: +66 (0) 8-1000-4155
EMail: glenzorn@gmail.com
Phone: +66 (0) 8-1000-4155
EMail: glenzorn@gmail.com