Network Working Group D. Singer
Request for Comments: 5450 Apple Computer Inc.
Category: Standards Track H. Desineni
Qualcomm
March 2009
Network Working Group D. Singer
Request for Comments: 5450 Apple Computer Inc.
Category: Standards Track H. Desineni
Qualcomm
March 2009
Transmission Time Offsets in RTP Streams
RTP流中的传输时间偏移
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times.
本文档描述了当RTP数据包在其“标称”传输时间以外的时间传输时，通知实时传输协议（RTP）客户端的方法。它还提供了一种机制来提供来自客户端的改进的到达间抖动报告，该报告考虑了报告的传输时间。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3
3. Transmission Offset . . . . . . . . . . . . . . . . . . . . . . 3
4. Extended Jitter Reports . . . . . . . . . . . . . . . . . . . . 5
5. Signaling (Setup) Information . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3
3. Transmission Offset . . . . . . . . . . . . . . . . . . . . . . 3
4. Extended Jitter Reports . . . . . . . . . . . . . . . . . . . . 5
5. Signaling (Setup) Information . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
In the Real-time Transport Protocol (RTP) specification [RFC3550], network jitter calculations are based on the presumption that packets are transmitted essentially in accordance with their RTP timestamps. This must be true, of course, on average over longer time intervals, as the client is playing the packets out according to those timestamps. However, for individual packets, this may not be true under some circumstances, such as:
在实时传输协议（RTP）规范[RFC3550]中，网络抖动计算是基于分组基本上按照其RTP时间戳进行传输的假设。当然，在较长的时间间隔内，这必须是正确的，因为客户端根据这些时间戳播放数据包。但是，对于单个数据包，在某些情况下可能不是这样，例如：
o When the data rate of the stream is bursty, such as with video where I-frames may be significantly larger than P or B frames, traffic smoothing may need to be applied to maintain an appropriate data rate.
o 当流的数据速率是突发的时，例如对于I帧可能显著大于P帧或B帧的视频，可能需要应用业务平滑以保持适当的数据速率。
o In video that has forward-decode dependencies, frames may need to be transmitted in decoding order (the sequence number order) but with, of course, presentation timestamps. Under these circumstances, the transmission time of a frame sent early in sequence does not correspond to its RTP timestamp.
o 在具有前向解码依赖性的视频中，帧可能需要以解码顺序（序列号顺序）传输，但当然需要具有呈现时间戳。在这些情况下，序列中提前发送的帧的传输时间与其RTP时间戳不对应。
o When retransmissions are sent, the retransmitted packet clearly has a different actual transmission time from the original, even though they share the same timestamp.
o 当发送重传时，重传的数据包显然与原始数据包具有不同的实际传输时间，即使它们共享相同的时间戳。
Under some circumstances, it can help the receiver, or intermediate network elements, to know the actual transmission time of the packet. This RTP header extension element allows the communication of this information.
在某些情况下，它可以帮助接收器或中间网络元件了解数据包的实际传输时间。此RTP标头扩展元素允许此信息的通信。
The RTP specification does not define a transmission timestamp; nor does this specification. This specification merely provides information on the relationship between the relative transmission times and relative RTP timestamps.
RTP规范没有定义传输时间戳；本规范也不适用。本规范仅提供有关相对传输时间和相对RTP时间戳之间关系的信息。
This specification allows the transmitter to indicate to the receiver any known variation between the spacing of transmission times and the spacing of RTP timestamps; any unreported variation introduced at or after the point of measurement of the transmission time will be treated as network jitter by the receiver. The definition of the point where the transmission time is measured or defined is left to the transmitter, though it should, of course, be consistent from packet to packet.
本规范允许发射机向接收机指示传输时间间隔和RTP时间戳间隔之间的任何已知变化；在传输时间测量点处或之后引入的任何未报告的变化将被接收器视为网络抖动。测量或定义传输时间的点的定义留给发送器，尽管它当然应该在每个包之间保持一致。
This information can also be of use to report the inter-arrival jitter caused by the network, excluding that introduced by the source. A new RTP Control Protocol (RTCP) packet is defined to enable this reporting.
此信息也可用于报告由网络引起的到达间抖动，不包括源引入的抖动。定义了一个新的RTP控制协议（RTCP）数据包以启用此报告。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Classically, a pair of RTP packets with timestamps S2 and S1 are transmitted with a time interval between them of (S2 - S1). This specification permits sending an offset value O in each packet, O1 and O2. One characteristic of these offsets is that the original transmission interval can be deduced to be (S2 + O2) - (S1 + O1).
典型地，具有时间戳S2和S1的一对RTP分组以它们之间的时间间隔（S2-S1）被发送。本规范允许在每个分组O1和O2中发送偏移值O。这些偏移的一个特征是，原始传输间隔可以推断为（S2+O2）-（S1+O1）。
More precisely, the offset is defined as follows (with the function RtoN converting from RTP to Network Time Protocol (NTP) times, and NtoR doing the reverse):
更准确地说，偏移量定义如下（函数RtoN从RTP转换为网络时间协议（NTP）时间，NtoR做相反的操作）：
o Take an RTP stream that has a recent RTCP sender report relating RTP timestamp S0 to NTP timestamp N0;
o 获取具有与RTP时间戳S0到NTP时间戳N0相关的最近RTCP发送方报告的RTP流；
o Consider a packet sent after that with RTP timestamp S1. Nominally, this is sent at N1 = (N0 + RtoN(S1 - S0));
o 考虑RTP时间戳S1之后发送的数据包。名义上，这是在N1=（N0+RtoN（S1-S0））处发送的；
o If it was actually sent at a different time, Na, then the offset value O1 is O1 = NtoR(Na - N1).
o 如果它实际上是在不同的时间Na发送的，那么偏移值O1是O1=NtoR（Na-N1）。
The transmission time is signaled to the receiver in-band using the general mechanism for RTP header extensions [RFC5285]. The payload of this extension (the transmitted value) is a 24-bit signed integer. When added to the RTP timestamp of the packet, it represents the "effective" RTP transmission time of the packet, on the RTP timescale. The reported transmission time T1 of a packet with
使用RTP报头扩展的通用机制[RFC5285]，向带内接收器发送传输时间信号。此扩展的有效负载（传输值）是24位有符号整数。当添加到数据包的RTP时间戳时，它表示数据包在RTP时间尺度上的“有效”RTP传输时间。数据包的报告传输时间T1
timestamp S1 and an offset of O1, from the above equations, is T1 = S1+O1 (though of course the transmission time values only have meaning when two or more are compared).
来自上述等式的时间戳S1和偏移量O1为T1＝S1+O1（当然，传输时间值仅在比较两个或更多个时才有意义）。
The form of the transmission offset extension block is as follows:
传输偏移扩展块的形式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=2 | transmission offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=2 | transmission offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field takes the value 2 to indicate that 3 bytes follow.
长度字段的值为2，表示后面有3个字节。
The sign of the offset value depends greatly on the choice of the initial mapping of RTP to NTP times. In general, without scanning a stream entirely it is not possible to ensure that this mapping would keep all the offsets positive; therefore, this specification allows negative values.
偏移值的符号在很大程度上取决于RTP到NTP时间的初始映射的选择。通常，如果不完全扫描流，就不可能确保该映射将保持所有偏移为正；因此，本规范允许负值。
Imagine a stream with the following timestamps and sizes (in KB):
想象一个具有以下时间戳和大小（KB）的流：
200 2 KB 300 4 KB 400 2 KB 500 12 KB 600 ...effective end of stream
200 2 KB 300 4 KB 400 2 KB 500 12 KB 600…有效流结束
This has 20 KB spread over 400 time units, i.e., on average, 1 KB per 20 time units. We traffic-smooth this, and establish that given a transmission time of x for the first packet, we would transmit the following packets at the given intervals later:
这在400个时间单位上分布了20KB，即平均每20个时间单位1KB。我们对此进行了平滑处理，并确定，给定第一个数据包的传输时间x，我们将在以后以给定的间隔传输以下数据包：
x + 000 2 KB x + 040 4 KB x + 120 2 KB x + 160 12 KB x + 400 ...effective end of stream
x+000 2 KB x+040 4 KB x+120 2 KB x+160 12 KB x+400…有效流结束
The choice of x is essentially arbitrary: only relative values of timestamps matter. Now, let's say I claim on the first packet that it went out *at* its RTP timestamp, i.e., with an offset of 0, meaning that x is 200. Then the offset values are:
x的选择基本上是任意的：只有时间戳的相对值才重要。现在，让我们假设我在第一个数据包上声明它在其RTP时间戳发出，即偏移量为0，意味着x是200。那么偏移值是：
0 -60 -80 -140
0 -60 -80 -140
This is because in this case, I traffic-smooth by conceptually sending the small packets 'early'. But since only the relative values are significant, it is just as valid to say x is 400, whereupon the offset values are:
这是因为在这种情况下，我通过“提前”发送小数据包来平滑通信。但是，由于只有相对值是有效的，所以说x是400也是有效的，因此偏移值是：
200 140 120 60
200 140 120 60
In a stream where this extension is not in effect (i.e., not declared or negotiated), the actual transmission offset is therefore unknown. However, when the extension is in effect for the stream, it MAY be omitted in those packets for which the offset is 0 (zero); that is, packets sent at their nominal time do not need this to be tagged with this extension. Therefore, the implied transmission time of an un-tagged RTP packet depends on whether the extension is in effect for the stream (and therefore the transmission offset is 0) or not (whereupon the transmission offset is unknown).
因此，在该扩展未生效（即，未声明或协商）的流中，实际传输偏移是未知的。然而，当扩展对流有效时，可以在偏移量为0（零）的那些分组中省略扩展；也就是说，在其标称时间发送的数据包不需要使用此扩展标记。因此，未标记的RTP分组的隐含传输时间取决于扩展是否对流有效（因此传输偏移量为0）（因此，传输偏移量未知）。
The jitter calculations performed by an RTP client MUST NOT use these transmission offsets. In general, the sender (or intermediate network elements doing RTP analysis) cannot always know whether the offsets have been taken into account or not. Therefore, for consistency, the jitter calculation should continue to operate on the 'raw' reception times. However, see Section 4 on extended jitter reports, below.
RTP客户端执行的抖动计算不得使用这些传输偏移。通常，发送方（或进行RTP分析的中间网络元素）不能总是知道是否考虑了偏移量。因此，为了一致性，抖动计算应继续在“原始”接收时间上进行。但是，请参见下面关于扩展抖动报告的第4节。
There are no extensionattributes defined for this extension.
没有为此扩展定义ExtensionAttribute。
It is structurally possible to have more than one extension of the same type in a packet. However, this extension is only defined for the source to report. Intermediate network nodes that are not the source of the RTP session MUST NOT add this extension (whether or not it was previously present) and MUST NOT alter the existing transmission offset value in a packet, if the extension is already present.
从结构上讲，在一个数据包中可以有多个相同类型的扩展。但是，此扩展仅为要报告的源定义。非RTP会话源的中间网络节点不得添加此扩展（无论它以前是否存在），并且不得更改数据包中的现有传输偏移值（如果扩展已经存在）。
(Of course, it is clear that network elements that terminate an RTP flow, and are the source for a new RTP flow, can add a transmission offset extension header to the RTP packets of the new flow, if desired.)
（当然，很明显，如果需要，终止RTP流并作为新RTP流源的网元可以向新流的RTP分组添加传输偏移扩展报头。）
The inter-arrival jitter computed as defined in Section 6.4.1 of RFC 3550 provides inter-arrival jitter reports that include any source-introduced jitter (transmission time offsets). If it is desired to
根据RFC 3550第6.4.1节中的定义计算的到达间抖动提供了包括任何源引入抖动（传输时间偏移）的到达间抖动报告。如果需要
indicate the actual network jitter, excluding the source-introduced jitter, the new RTCP packet type defined here may be used.
指示实际网络抖动，不包括源引入的抖动，可使用此处定义的新RTCP数据包类型。
It has the following form:
其形式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
hdr |V=2|P| RC | PT=IJ=195 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
| inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
hdr |V=2|P| RC | PT=IJ=195 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
| inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If present, this RTCP packet must be placed after a receiver report (inside a compound RTCP packet), and MUST have the same value for RC (reception report count) as the receiver report. The content is exactly that number of inter-arrival jitter calculations, calculated using the same formula as for sender and receiver reports, but taking into account the transmission offsets for the streams (if any). That is, the formula uses the values T1=S1+O1, T2, etc., as defined above, instead of S1, S2, etc. (If no transmission offset information is given for a stream, then the value of inter-arrival jitter in this packet and in the receiver report will be identical).
如果存在，此RTCP数据包必须放在接收器报告之后（在复合RTCP数据包内），并且必须具有与接收器报告相同的RC（接收报告计数）值。内容就是到达间抖动计算的数量，使用与发送方和接收方报告相同的公式计算，但考虑到流的传输偏移（如果有）。也就是说，公式使用如上定义的值T1＝S1+O1、T2等，而不是S1、S2等（如果没有给出流的传输偏移信息，则该分组和接收机报告中的到达间抖动的值将是相同的）。
Precisely, the replacement equation for the equation in the RTP specification is as follows, where Rj is the most recent arrival time:
准确地说，RTP规范中公式的替换公式如下所示，其中Rj是最新到达时间：
D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi))
= (Rj - (Sj + Oj)) - (Ri - (Si + Oi))
D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi))
= (Rj - (Sj + Oj)) - (Ri - (Si + Oi))
The URI for declaring this header extension in an extmap attribute is "urn:ietf:params:rtp-hdrext:toffset". There is no additional setup information needed for this extension (no extensionattributes).
在extmap属性中声明此头扩展的URI是“urn:ietf:params:rtp hdrext:toffset”。此扩展不需要其他设置信息（无ExtensionAttribute）。
The given transmission offsets are only informative, and it is hard to see security considerations from associating them with media streams.
给定的传输偏移量只是信息性的，很难看出将它们与媒体流关联时的安全考虑。
The underlying security considerations of [RFC3550] should be taken into account.
应考虑[RFC3550]的基本安全考虑因素。
It is possible that malicious senders (or systems tampering with packets in transit) could send offsets that are implausible, could confuse the receiver, or result in calculated jitter values that might mislead the sender. Both the sender and receiver of the transmission offsets and jitter values should take care that such behavior does not result in denial of service or other problems.
恶意发送方（或在传输过程中篡改数据包的系统）可能会发送不可信的偏移量，可能会混淆接收方，或导致计算出的抖动值误导发送方。传输偏移和抖动值的发送方和接收方都应注意，此类行为不会导致拒绝服务或其他问题。
The RTCP packet type used for the adjusted inter-arrival jitter has been registered, in accordance with Section 15 of [RFC3550]. IANA has added a new value to the RTCP Control Packet types subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
根据[RFC3550]第15节，已注册用于调整到达间抖动的RTCP数据包类型。IANA已根据以下数据向实时传输协议（RTP）参数注册表的RTCP控制数据包类型子区添加了一个新值：
abbrev. name value Reference
------- ------------------------------------ ------ ---------
IJ Extended inter-arrival jitter report 195 RFC 5450
abbrev. name value Reference
------- ------------------------------------ ------ ---------
IJ Extended inter-arrival jitter report 195 RFC 5450
Additionally, IANA has registered a new extension URI to the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
此外，IANA已根据以下数据向实时传输协议（RTP）参数注册表的RTP Compact Header Extensions子区注册了一个新的扩展URI：
Extension URI: urn:ietf:params:rtp-hdrext:toffset
Description: Transmission Time offsets
Contact: singer@apple.com
Reference: RFC 5450
Extension URI: urn:ietf:params:rtp-hdrext:toffset
Description: Transmission Time offsets
Contact: singer@apple.com
Reference: RFC 5450
Ron Frederick, Colin Perkins, and Steve Casner all contributed substantially to this document, and their help and contributions helped turn an idea into a specification.
Ron Frederick、Colin Perkins和Steve Casner都对本文档做出了重大贡献，他们的帮助和贡献帮助将一个想法转化为规范。
[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月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]Singer，D.和H.Desneni，“RTP标头扩展的一般机制”，RFC 5285，2008年7月。
Authors' Addresses
作者地址
David Singer Apple Computer Inc. 1 Infinite Loop Cupertino, CA 95014 US
David Singer苹果计算机公司1无限循环库珀蒂诺，加利福尼亚州95014美国
Phone: +1 408 996 1010
EMail: singer@apple.com
Phone: +1 408 996 1010
EMail: singer@apple.com
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92121 US
美国加利福尼亚州圣地亚哥Morehouse大道5775号Harikishan Desinini高通公司，邮编92121
Phone: +1 858 845 8996
EMail: hd@qualcomm.com
Phone: +1 858 845 8996
EMail: hd@qualcomm.com