Network Working Group J. Rey
Request for Comments: 4588 Panasonic
Category: Standards Track D. Leon
Consultant
A. Miyazaki
Panasonic
V. Varsa
Nokia
R. Hakenberg
Panasonic
July 2006
Network Working Group J. Rey
Request for Comments: 4588 Panasonic
Category: Standards Track D. Leon
Consultant
A. Miyazaki
Panasonic
V. Varsa
Nokia
R. Hakenberg
Panasonic
July 2006
RTP Retransmission Payload Format
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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo.
RTP重传是一种有效的数据包丢失恢复技术，适用于具有宽松延迟边界的实时应用。本文档描述了用于执行重传的RTP有效负载格式。重新传输的RTP数据包在与原始RTP数据流分开的数据流中发送。假设从接收者到发送者的反馈是可用的。特别是，假设本备忘录中提供了基于RTCP的反馈（表示为RTP/AVPF）的扩展RTP配置文件中定义的实时传输控制协议（RTCP）反馈。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements and Design Rationale for a Retransmission Scheme ...4
3.1. Multiplexing Scheme Choice .................................6
4. Retransmission Payload Format ...................................7
5. Association of Retransmission and Original Streams ..............9
5.1. Retransmission Session Sharing .............................9
5.2. CNAME Use ..................................................9
5.3. Association at the Receiver ................................9
6. Use with the Extended RTP Profile for RTCP-based Feedback ......11
6.1. RTCP at the Sender ........................................11
6.2. RTCP Receiver Reports .....................................11
6.3. Retransmission Requests ...................................12
6.4. Timing Rules ..............................................13
7. Congestion Control .............................................13
8. Retransmission Payload Format MIME Type Registration ...........15
8.1. Introduction ..............................................15
8.2. Registration of audio/rtx .................................16
8.3. Registration of video/rtx .................................17
8.4. Registration of text/rtx ..................................18
8.5. Registration of application/rtx ...........................19
8.6. Mapping to SDP ............................................20
8.7. SDP Description with Session-Multiplexing .................20
8.8. SDP Description with SSRC-Multiplexing ....................21
9. RTSP Considerations ............................................22
9.1. RTSP Control with SSRC-Multiplexing .......................22
9.2. RTSP Control with Session-Multiplexing ....................22
9.3. RTSP Control of the Retransmission Stream .................23
9.4. Cache Control .............................................23
10. Implementation Examples .......................................23
10.1. A Minimal Receiver Implementation Example ................24
10.2. Retransmission of Layered Encoded Media in Multicast .....25
11. IANA Considerations ...........................................26
12. Security Considerations .......................................26
13. Acknowledgements ..............................................27
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
Appendix A. How to Control the Number of Rtxs. per Packet .........29
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements and Design Rationale for a Retransmission Scheme ...4
3.1. Multiplexing Scheme Choice .................................6
4. Retransmission Payload Format ...................................7
5. Association of Retransmission and Original Streams ..............9
5.1. Retransmission Session Sharing .............................9
5.2. CNAME Use ..................................................9
5.3. Association at the Receiver ................................9
6. Use with the Extended RTP Profile for RTCP-based Feedback ......11
6.1. RTCP at the Sender ........................................11
6.2. RTCP Receiver Reports .....................................11
6.3. Retransmission Requests ...................................12
6.4. Timing Rules ..............................................13
7. Congestion Control .............................................13
8. Retransmission Payload Format MIME Type Registration ...........15
8.1. Introduction ..............................................15
8.2. Registration of audio/rtx .................................16
8.3. Registration of video/rtx .................................17
8.4. Registration of text/rtx ..................................18
8.5. Registration of application/rtx ...........................19
8.6. Mapping to SDP ............................................20
8.7. SDP Description with Session-Multiplexing .................20
8.8. SDP Description with SSRC-Multiplexing ....................21
9. RTSP Considerations ............................................22
9.1. RTSP Control with SSRC-Multiplexing .......................22
9.2. RTSP Control with Session-Multiplexing ....................22
9.3. RTSP Control of the Retransmission Stream .................23
9.4. Cache Control .............................................23
10. Implementation Examples .......................................23
10.1. A Minimal Receiver Implementation Example ................24
10.2. Retransmission of Layered Encoded Media in Multicast .....25
11. IANA Considerations ...........................................26
12. Security Considerations .......................................26
13. Acknowledgements ..............................................27
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
Appendix A. How to Control the Number of Rtxs. per Packet .........29
Packet losses between an RTP sender and receiver may significantly degrade the quality of the received media. Several techniques, such as forward error correction (FEC), retransmissions, or interleaving, may be considered to increase packet loss resiliency. RFC 2354 [8] discusses the different options.
RTP发送方和接收方之间的数据包丢失可能会显著降低所接收媒体的质量。可以考虑几种技术，例如前向纠错（FEC）、重传或交织，以提高分组丢失恢复能力。RFC 2354[8]讨论了不同的选项。
When choosing a repair technique for a particular application, the tolerable latency of the application has to be taken into account. In the case of multimedia conferencing, the end-to-end delay has to be at most a few hundred milliseconds in order to guarantee interactivity, which usually excludes the use of retransmission.
在为特定应用程序选择修复技术时，必须考虑应用程序的可容忍延迟。在多媒体会议的情况下，为了保证交互性，端到端延迟必须最多为几百毫秒，这通常不包括使用重传。
With sufficient latency, the efficiency of the repair scheme can be increased. The sender may use the receiver feedback in order to react to losses before their playout time at the receiver.
在有足够延迟的情况下，可以提高修复方案的效率。发送方可以使用接收方反馈，以便在其在接收方的播放时间之前对损失作出反应。
In the case of multimedia streaming, the user can tolerate an initial latency as part of the session set-up and thus an end-to-end delay of several seconds may be acceptable. RTP retransmission as defined in this document is targeted at such applications.
在多媒体流的情况下，用户可以容忍作为会话设置的一部分的初始延迟，因此可以接受几秒钟的端到端延迟。本文件中定义的RTP重传针对此类应用。
Furthermore, the RTP retransmission method defined herein is applicable to unicast and (small) multicast groups. The present document defines a payload format for retransmitted RTP packets and provides protocol rules for the sender and the receiver involved in retransmissions.
此外，本文定义的RTP重传方法适用于单播和（小）多播组。本文档定义了用于重新传输的RTP分组的有效载荷格式，并为参与重新传输的发送方和接收方提供了协议规则。
This retransmission payload format was designed for use with the extended RTP profile for RTCP-based feedback, AVPF [1]. It may also be used with other RTP profiles defined in the future.
此重传有效负载格式设计用于基于RTCP的反馈的扩展RTP配置文件AVPF[1]。它也可以用于将来定义的其他RTP配置文件。
The AVPF profile allows for more frequent feedback and for early feedback. It defines a general-purpose feedback message, i.e., NACK, as well as codec and application-specific feedback messages. See [1] for details.
AVPF配置文件允许更频繁的反馈和早期反馈。它定义了通用反馈消息，即NACK，以及编解码器和特定于应用程序的反馈消息。有关详细信息，请参见[1]。
The following terms are used in this document:
本文件中使用了以下术语：
CSRC: contributing source. See [3].
中国证监会：贡献来源。见[3]。
Original packet: an RTP packet that carries user data sent for the first time by an RTP sender.
原始数据包：一种RTP数据包，它承载RTP发送方首次发送的用户数据。
Original stream: the RTP stream of original packets.
原始流：原始数据包的RTP流。
Retransmission packet: an RTP packet that is to be used by the receiver instead of a lost original packet. Such a retransmission packet is said to be associated with the original RTP packet.
重传数据包：由接收方使用的RTP数据包，而不是丢失的原始数据包。这样的重传分组被称为与原始RTP分组相关联。
Retransmission request: a means by which an RTP receiver is able to request that the RTP sender should send a retransmission packet for a given original packet. Usually, an RTCP NACK packet as specified in [1] is used as retransmission request for lost packets.
重传请求：RTP接收方能够请求RTP发送方发送给定原始数据包的重传数据包的方法。通常，使用[1]中指定的RTCP NACK数据包作为丢失数据包的重传请求。
Retransmission stream: the stream of retransmission packets associated with an original stream.
重传流：与原始流关联的重传数据包流。
Session-multiplexing: scheme by which the original stream and the associated retransmission stream are sent into two different RTP sessions.
会话多路复用：将原始流和相关重传流发送到两个不同RTP会话的方案。
SSRC: synchronization source. See [3].
同步源。见[3]。
SSRC-multiplexing: scheme by which the original stream and the retransmission stream are sent in the same RTP session with different SSRC values.
SSRC多路复用：在同一RTP会话中以不同SSRC值发送原始流和重传流的方案。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
The use of retransmissions in RTP as a repair method for streaming media is appropriate in those scenarios with relaxed delay bounds and where full reliability is not a requirement. More specifically, RTP retransmission allows one to trade off reliability vs. delay; i.e., the endpoints may give up retransmitting a lost packet after a given buffering time has elapsed. Unlike TCP, there is thus no head-of-line blocking caused by RTP retransmissions. The implementer should be aware that in cases where full reliability is required or higher delay and jitter can be tolerated, TCP or other transport options should be considered.
在RTP中使用重传作为流媒体的修复方法适用于延迟范围较宽且不要求完全可靠性的场景。更具体地说，RTP重传允许人们权衡可靠性和延迟；i、 例如，在经过给定的缓冲时间之后，端点可以放弃重新传输丢失的分组。与TCP不同，因此不存在由RTP重传引起的线路头阻塞。实施者应意识到，在需要完全可靠性或可以容忍更高延迟和抖动的情况下，应考虑TCP或其他传输选项。
The RTP retransmission scheme defined in this document is designed to fulfill the following set of requirements:
本文件中定义的RTP重传方案旨在满足以下要求：
1. It must not break general RTP and RTCP mechanisms. 2. It must be suitable for unicast and small multicast groups. 3. It must work with mixers and translators. 4. It must work with all known payload types. 5. It must not prevent the use of multiple payload types in a session.
1. 它不能破坏一般RTP和RTCP机制。2.它必须适用于单播和小型多播组。3.它必须与混音器和翻译器配合使用。4.它必须适用于所有已知的有效负载类型。5.它不能阻止在会话中使用多种有效负载类型。
6. In order to support the largest variety of payload formats, the RTP receiver must be able to derive how many and which RTP packets were lost as a result of a gap in received RTP sequence numbers. This requirement is referred to as sequence number preservation. Without such a requirement, it would be impossible to use retransmission with payload formats, such as conversational text [9] or most audio/video streaming applications, that use the RTP sequence number to detect lost packets.
6. 为了支持最大种类的有效负载格式，RTP接收器必须能够得出由于接收到的RTP序列号中的间隙而丢失了多少RTP数据包以及哪些RTP数据包。此要求称为序列号保存。如果没有这样的要求，就不可能使用有效载荷格式的重传，例如会话文本[9]或大多数音频/视频流应用程序，这些应用程序使用RTP序列号来检测丢失的数据包。
When designing a solution for RTP retransmission, several approaches may be considered for the multiplexing of the original RTP packets and the retransmitted RTP packets.
当设计用于RTP重传的解决方案时，可以考虑几种方法来复用原始RTP分组和重传的RTP分组。
One approach may be to retransmit the RTP packet with its original sequence number and send original and retransmission packets in the same RTP stream. The retransmission packet would then be identical to the original RTP packet, i.e., the same header (and thus same sequence number) and the same payload. However, such an approach is not acceptable because it would corrupt the RTCP statistics. As a consequence, requirement 1 would not be met. Correct RTCP statistics require that for every RTP packet within the RTP stream, the sequence number be increased by one.
一种方法可以是重新传输具有其原始序列号的RTP分组，并在相同的RTP流中发送原始分组和重新传输分组。然后，重传分组将与原始RTP分组相同，即，相同的报头（因此相同的序列号）和相同的有效载荷。但是，这种方法是不可接受的，因为它会破坏RTCP统计数据。因此，将无法满足要求1。正确的RTCP统计信息要求RTP流中的每个RTP数据包的序列号增加1。
Another approach may be to multiplex original RTP packets and retransmission packets in the same RTP stream using different payload type values. With such an approach, the original packets and the retransmission packets would share the same sequence number space. As a result, the RTP receiver would not be able to infer how many and which original packets (which sequence numbers) were lost.
另一种方法可以是使用不同的有效负载类型值在同一RTP流中复用原始RTP分组和重传分组。通过这种方法，原始分组和重传分组将共享相同的序列号空间。因此，RTP接收器将无法推断丢失了多少原始数据包（哪些序列号）。
In other words, this approach does not satisfy the sequence number preservation requirement (requirement 6). This in turn implies that requirement 4 would not be met. Interoperability with mixers and translators would also be more difficult if they did not understand this new retransmission payload type in a sender RTP stream. For these reasons, a solution based on payload type multiplexing of original packets and retransmission packets in the same RTP stream is excluded.
换句话说，该方法不满足序列号保存要求（要求6）。这反过来意味着将无法满足要求4。如果混频器和翻译器不理解发送方RTP流中的这种新的重传有效负载类型，那么它们与混频器和翻译器的互操作性也将更加困难。出于这些原因，排除了基于相同RTP流中的原始分组和重传分组的有效负载类型复用的解决方案。
Finally, the original and retransmission packets may be sent in two separate streams. These two streams may be multiplexed either by sending them in two different sessions , i.e., session-multiplexing, or in the same session using different SSRC values, i.e., SSRC-multiplexing. Since original and retransmission packets carry media of the same type, the objections in Section 5.2 of RTP [3] to RTP multiplexing do not apply in this case.
最后，原始分组和重传分组可以在两个单独的流中发送。这两个流可以通过在两个不同会话（即会话多路复用）中发送来多路复用，或者在同一会话中使用不同的SSRC值（即SSRC多路复用）来多路复用。由于原始数据包和重传数据包携带相同类型的媒体，RTP[3]第5.2节中对RTP多路复用的异议不适用于这种情况。
Mixers and translators may process the original stream and simply discard the retransmission stream if they are unable to utilise it.
混频器和翻译器可以处理原始流，如果无法使用，则可以简单地丢弃重传流。
On the other hand, sending the original and retransmission packets in two separate streams does not alone satisfy requirements 1 and 6. For this purpose, this document includes the original sequence number in the retransmitted packets.
另一方面，在两个单独的流中发送原始和重传分组并不单独满足要求1和6。为此，本文件在重新传输的数据包中包括原始序列号。
In this manner, using two separate streams satisfies all the requirements listed in this section.
以这种方式，使用两个单独的流满足本节中列出的所有要求。
Session-multiplexing and SSRC-multiplexing have different pros and cons:
会话多路复用和SSRC多路复用有不同的优缺点：
Session-multiplexing is based on sending the retransmission stream in a different RTP session (as defined in RTP [3]) from that of the original stream; i.e., the original and retransmission streams are sent to different network addresses and/or port numbers. Having a separate session allows more flexibility. In multicast, using two separate sessions for the original and the retransmission streams allows a receiver to choose whether or not to subscribe to the RTP session carrying the retransmission stream. The original session may also be single-source multicast while separate unicast sessions are used to convey retransmissions to each of the receivers, which as a result will receive only the retransmission packets they request.
会话多路复用基于在与原始流不同的RTP会话（如RTP[3]中所定义）中发送重传流；i、 例如，原始和重传流被发送到不同的网络地址和/或端口号。有一个单独的会话允许更大的灵活性。在多播中，对原始和重传流使用两个单独的会话允许接收机选择是否订阅承载重传流的RTP会话。原始会话也可以是单源多播，而单独的单播会话用于向每个接收机传送重传，其结果将仅接收它们请求的重传分组。
The use of separate sessions also facilitates differential treatment by the network and may simplify processing in mixers, translators, and packet caches.
单独会话的使用还促进了网络的差异化处理，并且可以简化混频器、转换器和数据包缓存中的处理。
With SSRC-multiplexing, a single session is needed for the original and the retransmission streams. This allows streaming servers and middleware that are involved in a high number of concurrent sessions to minimise their port usage.
使用SSRC多路复用，原始流和重传流需要单个会话。这允许参与大量并发会话的流式服务器和中间件将其端口使用率降至最低。
This retransmission payload format allows both session-multiplexing and SSRC-multiplexing for unicast sessions. From an implementation point of view, there is little difference between the two approaches. Hence, in order to maximise interoperability, both multiplexing approaches SHOULD be supported by senders and receivers. For multicast sessions, session-multiplexing MUST be used because the association of the original stream and the retransmission stream is problematic if SSRC-multiplexing is used with multicast sessions(see Section 5.3 for motivation).
此重传有效负载格式允许单播会话的会话多路复用和SSRC多路复用。从实现的角度来看，这两种方法几乎没有什么区别。因此，为了最大限度地提高互操作性，发送方和接收方都应支持这两种多路复用方法。对于多播会话，必须使用会话多路复用，因为如果SSRC多路复用与多播会话一起使用，则原始流和重传流的关联是有问题的（动机见第5.3节）。
The format of a retransmission packet is shown below:
重传分组的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP header usage is as follows:
RTP头的用法如下所示：
In the case of session-multiplexing, the same SSRC value MUST be used for the original stream and the retransmission stream. In the case of an SSRC collision in either the original session or the retransmission session, the RTP specification requires that an RTCP BYE packet MUST be sent in the session where the collision happened. In addition, an RTCP BYE packet MUST also be sent for the associated stream in its own session. After a new SSRC identifier is obtained, the SSRC of both streams MUST be set to this value.
在会话多路复用的情况下，原始流和重传流必须使用相同的SSRC值。在原始会话或重传会话中发生SSRC冲突的情况下，RTP规范要求必须在发生冲突的会话中发送RTCP BYE数据包。此外，还必须在其自己的会话中为相关流发送RTCP BYE数据包。获得新的SSRC标识符后，必须将两个流的SSRC设置为该值。
In the case of SSRC-multiplexing, two different SSRC values MUST be used for the original stream and the retransmission stream as required by RTP. If an SSRC collision is detected for either the original stream or the retransmission stream, the RTP specification requires that an RTCP BYE packet MUST be sent for this stream. An RTCP BYE packet MUST NOT be sent for the associated stream. Therefore, only the stream that experienced SSRC collision MUST choose a new SSRC value. Refer to Section 5.3 for the implications on the original stream and retransmission stream SSRC association at the receiver.
在SSRC多路复用的情况下，根据RTP的要求，原始流和重传流必须使用两个不同的SSRC值。如果检测到原始流或重传流的SSRC冲突，RTP规范要求必须为此流发送RTCP BYE数据包。不得为关联流发送RTCP BYE数据包。因此，只有经历SSRC冲突的流必须选择新的SSRC值。参考第5.3节，了解对接收器处的原始流和重传流SSRC关联的影响。
For either multiplexing scheme, the sequence number has the standard definition; i.e., it MUST be one higher than the sequence number of the preceding packet sent in the retransmission stream.
对于任一复用方案，序列号具有标准定义；i、 例如，它必须比在重传流中发送的前一个分组的序列号高一个。
The retransmission packet timestamp MUST be set to the original timestamp, i.e., to the timestamp of the original packet. As a consequence, the initial RTP timestamp for the first packet of the retransmission stream is not random but equal to the original timestamp of the first packet that is retransmitted. See the Security Considerations section in this document for security implications.
重传分组时间戳必须设置为原始时间戳，即，设置为原始分组的时间戳。结果，重传流的第一分组的初始RTP时间戳不是随机的，而是等于被重传的第一分组的原始时间戳。有关安全影响，请参阅本文档中的安全注意事项部分。
Implementers have to be aware that the RTCP jitter value for the retransmission stream does not reflect the actual network jitter since there could be little correlation between the time a packet is retransmitted and its original timestamp.
实施者必须意识到，重传流的RTCP抖动值并不反映实际的网络抖动，因为数据包重传的时间与其原始时间戳之间可能几乎没有相关性。
The payload type is dynamic. If multiple payload types using retransmission are present in the original stream, then for each of these, a dynamic payload type MUST be mapped to the retransmission payload format. See Section 8.1 for the specification of how the mapping between original and retransmission payload types is done with Session Description Protocol (SDP).
有效负载类型是动态的。如果原始流中存在使用重传的多个有效负载类型，则对于其中的每一个，必须将动态有效负载类型映射到重传有效负载格式。有关如何使用会话描述协议（SDP）实现原始和重传有效负载类型之间映射的规范，请参见第8.1节。
As the retransmission packet timestamp carries the original media timestamp, the timestamp clockrate used by the retransmission payload type MUST be the same as the one used by the associated original payload type. Therefore, if an RTP stream carries payload types of different clockrates, this will also be the case for the associated retransmission stream. Note that an RTP stream does not usually carry payload types of different clockrates.
由于重发分组时间戳携带原始媒体时间戳，重发有效负载类型使用的时间戳时钟速率必须与关联的原始有效负载类型使用的时间戳时钟速率相同。因此，如果RTP流承载不同时钟速率的有效负载类型，则对于相关联的重传流也是如此。请注意，RTP流通常不携带不同时钟速率的有效负载类型。
The payload of the RTP retransmission packet comprises the retransmission payload header followed by the payload of the original RTP packet. The length of the retransmission payload header is 2 octets. This payload header contains only one field, OSN (original sequence number), which MUST be set to the sequence number of the associated original RTP packet. The original RTP packet payload, including any possible payload headers specific to the original payload type, MUST be placed right after the retransmission payload header.
RTP重传分组的有效载荷包括重传有效载荷报头，后跟原始RTP分组的有效载荷。重传有效负载报头的长度为2个八位字节。此有效负载报头仅包含一个字段OSN（原始序列号），必须将其设置为相关原始RTP数据包的序列号。原始RTP数据包有效负载，包括特定于原始有效负载类型的任何可能的有效负载报头，必须放在重传有效负载报头之后。
For payload formats that support encoding at multiple rates, instead of retransmitting the same payload as the original RTP packet the sender MAY retransmit the same data encoded at a lower rate. This aims at limiting the bandwidth usage of the retransmission stream. When doing so, the sender MUST ensure that the receiver will still be able to decode the payload of the already sent original packets that might have been encoded based on the payload of the lost original packet. In addition, if the sender chooses to retransmit at a lower rate, the values in the payload header of the original RTP packet may no longer apply to the retransmission packet and may need to be modified in the retransmission packet to reflect the change in rate. The sender SHOULD trade off the decrease in bandwidth usage with the decrease in quality caused by resending at a lower rate.
对于支持以多种速率编码的有效载荷格式，发送方可以重新传输以较低速率编码的相同数据，而不是重新传输与原始RTP分组相同的有效载荷。这旨在限制重传流的带宽使用。这样做时，发送方必须确保接收方仍然能够解码可能已经基于丢失的原始分组的有效载荷编码的已经发送的原始分组的有效载荷。此外，如果发送方选择以较低的速率重传，则原始RTP分组的有效载荷报头中的值可能不再适用于重传分组，并且可能需要在重传分组中修改以反映速率的变化。发送方应该权衡带宽使用量的减少和以较低速率重新发送导致的质量下降。
If the original RTP header carried any profile-specific extensions, the retransmission packet SHOULD include the same extensions immediately following the fixed RTP header as expected by applications running under this profile. In this case, the
如果原始RTP报头携带任何特定于配置文件的扩展，则重传数据包应包括紧跟在固定RTP报头之后的相同扩展，正如在此配置文件下运行的应用程序所期望的那样。在这种情况下
retransmission payload header MUST be placed after the profile-specific extensions.
重传有效负载报头必须放在配置文件特定扩展之后。
If the original RTP header carried an RTP header extension, the retransmission packet SHOULD carry the same header extension. This header extension MUST be placed right after the fixed RTP header, as specified in RTP [3]. In this case, the retransmission payload header MUST be placed after the header extension.
如果原始RTP报头带有RTP报头扩展，则重传数据包应带有相同的报头扩展。按照RTP[3]中的规定，此标头扩展必须放在固定RTP标头的正后方。在这种情况下，重传有效负载报头必须放在报头扩展之后。
If the original RTP packet contained RTP padding, that padding MUST be removed before constructing the retransmission packet. If padding of the retransmission packet is needed, padding MUST be performed as with any RTP packets and the padding bit MUST be set.
如果原始RTP数据包包含RTP填充，则在构造重传数据包之前必须删除该填充。如果需要对重传数据包进行填充，则必须像对待任何RTP数据包一样执行填充，并且必须设置填充位。
The marker bit (M), the CSRC count (CC), and the CSRC list of the original RTP header MUST be copied "as is" into the RTP header of the retransmission packet.
原始RTP报头的标记位（M）、CSC计数（CC）和CSC列表必须“按原样”复制到重传数据包的RTP报头中。
In the case of session-multiplexing, a retransmission session MUST map to exactly one original session; i.e., the same retransmission session cannot be used for different original sessions.
在会话多路复用的情况下，重传会话必须映射到恰好一个原始会话；i、 例如，同一重传会话不能用于不同的原始会话。
If retransmission session sharing were allowed, it would be a problem for receivers, since they would receive retransmissions for original sessions they might not have joined. For example, a receiver wishing to receive only audio would receive also retransmitted video packets if an audio and video session shared the same retransmission session.
如果允许重传会话共享，这对接收者来说将是一个问题，因为他们将为他们可能没有加入的原始会话接收重传。例如，如果音频和视频会话共享相同的重传会话，则希望仅接收音频的接收器也将接收重传的视频分组。
In both the session-multiplexing and the SSRC-multiplexing cases, a sender MUST use the same RTCP CNAME [3] for an original stream and its associated retransmission stream.
在会话多路复用和SSRC多路复用情况下，发送方必须对原始流及其关联的重传流使用相同的RTCP CNAME[3]。
A receiver receiving multiple original and retransmission streams needs to associate each retransmission stream with its original stream. The association is done differently depending on whether session-multiplexing or SSRC-multiplexing is used.
接收多个原始流和重传流的接收器需要将每个重传流与其原始流相关联。根据使用的是会话多路复用还是SSRC多路复用，关联的方式有所不同。
If session-multiplexing is used, the receiver associates the two streams having the same SSRC in the two sessions. Note that the payload type field cannot be used to perform the association as
如果使用会话多路复用，则接收机将两个会话中具有相同SSRC的两个流相关联。请注意，有效负载类型字段不能用于执行关联
several media streams may have the same payload type value. The two sessions are themselves associated out-of-band. See Section 8 for how the grouping of the two sessions is done with SDP.
多个媒体流可以具有相同的有效负载类型值。这两个会议本身是带外的。关于如何使用SDP对两个会话进行分组，请参见第8节。
If SSRC-multiplexing is used, the receiver should first of all look for two streams that have the same CNAME in the session. In some cases, the CNAME may not be enough to determine the association as multiple original streams in the same session may share the same CNAME. For example, there can be in the same video session multiple video streams mapping to different SSRCs and still using the same CNAME and possibly the same payload type (PT) values. Each (or some) of these streams may have an associated retransmission stream.
如果使用SSRC多路复用，接收器首先应查找会话中具有相同CNAME的两个流。在某些情况下，CNAME可能不足以确定关联，因为同一会话中的多个原始流可能共享同一CNAME。例如，在同一视频会话中，可以有多个视频流映射到不同的SSRC，并且仍然使用相同的CNAME和可能相同的有效负载类型（PT）值。这些流中的每个（或一些）可以具有相关联的重传流。
In this case, in order to find out the association between original and retransmission streams having the same CNAME, the receiver SHOULD behave as follows.
在这种情况下，为了找出具有相同CNAME的原始流和重传流之间的关联，接收器应如下操作。
The association can generally be resolved when the receiver receives a retransmission packet matching a retransmission request that had been sent earlier. Upon reception of a retransmission packet whose original sequence number has been previously requested, the receiver can derive that the SSRC of the retransmission packet is associated to the sender SSRC from which the packet was requested.
当接收器接收到与先前发送的重传请求相匹配的重传分组时，通常可以解析该关联。在接收到其原始序列号先前已被请求的重发分组时，接收机可导出重发分组的SSRC与从其请求分组的发送方SSRC相关联。
However, this mechanism might fail if there are two outstanding requests for the same packet sequence number in two different original streams of the session. Note that since the initial packet sequence numbers are random, the probability of having two outstanding requests for the same packet sequence number would be very small. Nevertheless, in order to avoid ambiguity in the unicast case, the receiver MUST NOT have two outstanding requests for the same packet sequence number in two different original streams before the association is resolved. In multicast, this ambiguity cannot be completely avoided, because another receiver may have requested the same sequence number from another stream. Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions.
但是，如果在会话的两个不同原始流中有两个针对相同数据包序列号的未完成请求，则此机制可能会失败。注意，由于初始分组序列号是随机的，因此对于相同分组序列号有两个未完成请求的概率将非常小。然而，为了避免单播情况下的模糊性，在解决关联之前，接收器不得在两个不同的原始流中具有对相同分组序列号的两个未完成请求。在多播中，这种歧义无法完全避免，因为另一个接收器可能已经从另一个流请求了相同的序列号。因此，SSRC多路复用不能用于多播会话。
If the receiver discovers that two senders are using the same SSRC or if it receives an RTCP BYE packet, it MUST stop requesting retransmissions for that SSRC. Upon reception of original RTP packets with a new SSRC, the receiver MUST perform the SSRC association again as described in this section.
如果接收方发现两个发送方使用相同的SSRC，或者如果接收到RTCP BYE数据包，则必须停止对该SSRC的重新传输请求。接收到带有新SSRC的原始RTP数据包后，接收器必须按照本节所述再次执行SSRC关联。
This section gives general hints for the usage of this payload format with the extended RTP profile for RTCP-based feedback, denoted AVPF [1]. Note that the general RTCP send and receive rules and the RTCP packet format as specified in RTP apply, except for the changes that the AVPF profile introduces. In short, the AVPF profile relaxes the RTCP timing rules and specifies additional general-purpose RTCP feedback messages. See [1] for details.
本节给出了将此有效负载格式与基于RTCP的反馈的扩展RTP配置文件（表示为AVPF[1]）一起使用的一般提示。请注意，RTP中指定的一般RTCP发送和接收规则和RTCP数据包格式适用，AVPF配置文件引入的更改除外。简而言之，AVPF配置文件放松RTCP定时规则，并指定附加的通用RTCP反馈消息。有关详细信息，请参见[1]。
In the case of session-multiplexing, Sender Report (SR) packets for the original stream are sent in the original session and SR packets for the retransmission stream are sent in the retransmission session according to the rules of RTP.
在会话多路复用的情况下，根据RTP的规则，在原始会话中发送原始流的发送方报告（SR）分组，在重传会话中发送重传流的SR分组。
In the case of SSRC-multiplexing, SR packets for both original and retransmission streams are sent in the same session according to the rules of RTP. The original and retransmission streams are seen, as far as the RTCP bandwidth calculation is concerned, as independent senders belonging to the same RTP session and are thus equally sharing the RTCP bandwidth assigned to senders.
在SSRC复用的情况下，根据RTP的规则，在同一会话中发送原始流和重传流的SR分组。就RTCP带宽计算而言，原始和重传流被视为属于同一RTP会话的独立发送方，因此平等地共享分配给发送方的RTCP带宽。
Note that in both cases, session- and SSRC-multiplexing, BYE packets MUST still be sent for both streams as specified in RTP. In other words, it is not enough to send BYE packets for the original stream only.
注意，在这两种情况下，会话多路复用和SSRC多路复用都必须按照RTP中的规定为两个流发送BYE数据包。换句话说，仅为原始流发送BYE数据包是不够的。
In the case of session-multiplexing, the receiver will send report blocks for the original stream and the retransmission stream in separate Receiver Report (RR) packets belonging to separate RTP sessions. RR packets reporting on the original stream are sent in the original RTP session while RR packets reporting on the retransmission stream are sent in the retransmission session. The RTCP bandwidth for these two sessions may be chosen independently (e.g., through RTCP bandwidth modifiers [4]).
在会话多路复用的情况下，接收器将在属于单独RTP会话的单独接收器报告（RR）分组中发送原始流和重传流的报告块。报告原始流的RR数据包在原始RTP会话中发送，而报告重传流的RR数据包在重传会话中发送。这两个会话的RTCP带宽可以独立选择（例如，通过RTCP带宽修饰符[4]）。
In the case of SSRC-multiplexing, the receiver sends report blocks for the original and the retransmission streams in the same RR packet since there is a single session.
在SSRC多路复用的情况下，由于存在单个会话，因此接收机在同一RR分组中发送原始和重传流的报告块。
The NACK feedback message format defined in the AVPF profile SHOULD be used by receivers to send retransmission requests. Whether or not a receiver chooses to request a packet is an implementation issue. An actual receiver implementation should take into account such factors as the tolerable application delay, the network environment, and the media type.
接收机应使用AVPF配置文件中定义的NACK反馈消息格式发送重传请求。接收方是否选择请求数据包是一个实现问题。实际的接收器实现应该考虑诸如可容忍的应用程序延迟、网络环境和媒体类型等因素。
The receiver should generally assess whether the retransmitted packet would still be useful at the time it is received. The timestamp of the missing packet can be estimated from the timestamps of packets preceding and/or following the sequence number gap caused by the missing packet in the original stream. In most cases, some form of linear estimate of the timestamp is good enough.
接收机通常应评估重发分组在接收时是否仍然有用。丢失分组的时间戳可以根据原始流中丢失分组引起的序列号间隔之前和/或之后的分组的时间戳来估计。在大多数情况下，时间戳的某种形式的线性估计就足够了。
Furthermore, a receiver should compute an estimate of the round-trip time (RTT) to the sender. This can be done, for example, by measuring the retransmission delay to receive a retransmission packet after a NACK has been sent for that packet. This estimate may also be obtained from past observations, RTCP report round-trip time if available, or any other means. A standard mechanism for the receiver to estimate the RTT is specified in "RTP Control Protocol Extended Reports (RTCP XR)" [11].
此外，接收方应计算到发送方的往返时间（RTT）的估计值。这可以例如通过测量重传延迟来实现，以在针对重传分组发送NACK之后接收该重传分组。该估计值也可通过过去的观察、RTCP报告往返时间（如可用）或任何其他方式获得。“RTP控制协议扩展报告（RTCP XR）”[11]中规定了接收机估计RTT的标准机制。
The receiver should not send a retransmission request as soon as it detects a missing sequence number but should add some extra delay to compensate for packet reordering. This extra delay may, for example, be based on past observations of the experienced packet reordering. It should be noted that, in environments where packet reordering is rare or does not take place, e.g., if the underlying datalink layer affords ordered delivery, the delay may be extremely low or even take the value zero. In such cases, an appropriate "reorder delay" algorithm may not actually be timer based, but packet based. For example, if n number of packets are received after a gap is detected, then it may be assumed that the packet was truly lost rather than out of order. This may turn out to be far easier to code on some platforms as a very short fixed FIFO packet buffer as opposed to the timer-based mechanism.
接收器不应在检测到丢失的序列号后立即发送重传请求，但应添加一些额外延迟以补偿数据包重新排序。例如，该额外延迟可以基于对经历的分组重新排序的过去观察。应当注意的是，在分组重新排序很少或没有发生的环境中，例如，如果底层数据链路层提供了有序交付，则延迟可能极低，甚至可能为零。在这种情况下，适当的“重新排序延迟”算法实际上可能不是基于计时器的，而是基于分组的。例如，如果在检测到间隙之后接收到n个分组，则可以假设分组确实丢失而不是无序。与基于计时器的机制相比，在某些平台上，作为非常短的固定FIFO数据包缓冲区进行编码可能要容易得多。
To increase the robustness to the loss of a NACK or of a retransmission packet, a receiver may send a new NACK for the same packet. This is referred to as multiple retransmissions. Before sending a new NACK for a missing packet, the receiver should rely on a timer to be reasonably sure that the previous retransmission attempt has failed and so avoid unnecessary retransmissions. The timer value shall be based on the observed round-trip time. A static or an adaptive value MAY be used. For example, an adaptive timer
为了增加对NACK或重传分组的丢失的鲁棒性，接收机可以为相同分组发送新的NACK。这称为多次重传。在为丢失的数据包发送新的NACK之前，接收器应该依靠计时器来合理地确保先前的重传尝试失败，从而避免不必要的重传。计时器值应基于观察到的往返时间。可以使用静态值或自适应值。例如，自适应计时器
could be one that changes its value with every new request for the same packet. This document does not provide any guidelines as to how this adaptive value should be calculated because no experiments have been done to find this out.
可以是一个随同一数据包的每个新请求而改变其值的数据包。本文档没有提供任何关于如何计算自适应值的指导，因为还没有进行任何实验来发现这一点。
NACKs MUST be sent only for the original RTP stream. Otherwise, if a receiver wanted to perform multiple retransmissions by sending a NACK in the retransmission stream, it would not be able to know the original sequence number and a timestamp estimation of the packet it requests.
NACK必须仅针对原始RTP流发送。否则，如果接收机想要通过在重传流中发送NACK来执行多个重传，则其将无法知道其请求的分组的原始序列号和时间戳估计。
Appendix A gives some guidelines as to how to control the number of retransmissions.
附录A给出了一些关于如何控制重传次数的指南。
The NACK feedback message may be sent in a regular full compound RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending a NACK in an early packet allows reacting more quickly to a given packet loss. However, in that case if a new packet loss occurs right after the early RTCP packet was sent, the receiver will then have to wait for the next regular RTCP compound packet after the early packet. Sending NACKs only in regular RTCP compound decreases the maximum delay between detecting an original packet loss and being able to send a NACK for that packet. Implementers should consider the possible implications of this fact for the application being used.
根据AVPF[1]，NACK反馈消息可以在常规全复合RTCP分组或早期RTCP分组中发送。在早期分组中发送NACK允许对给定分组丢失做出更快的反应。然而，在这种情况下，如果在发送早期RTCP数据包之后立即发生新的数据包丢失，则接收器将不得不等待早期数据包之后的下一个常规RTCP复合数据包。仅在常规RTCP复合中发送NACK可减少检测原始数据包丢失和能够为该数据包发送NACK之间的最大延迟。实现者应该考虑这个事实对应用程序的可能影响。
Furthermore, receivers may make use of the minimum interval between regular RTCP compound packets. This interval can be used to keep regular receiver reporting down to a minimum, while still allowing receivers to send early RTCP packets during periods requiring more frequent feedback, e.g., times of higher packet loss rate. Note that although RTCP packets may be suppressed because they do not contain NACKs, the same RTCP bandwidth as if they were sent needs to be available. See AVPF [1] for details on the use of the minimum interval.
此外，接收机可以利用常规RTCP复合分组之间的最小间隔。此间隔可用于将常规接收机报告降至最低，同时仍允许接收机在需要更频繁反馈的时段（例如，较高丢包率的时段）发送早期RTCP数据包。请注意，尽管RTCP数据包可能会被抑制，因为它们不包含NACK，但需要提供与发送时相同的RTCP带宽。有关使用最小间隔的详细信息，请参见AVPF[1]。
RTP retransmission poses a risk of increasing network congestion. In a best-effort environment, packet loss is caused by congestion. Reacting to loss by retransmission of older data without decreasing the rate of the original stream would thus further increase congestion. Implementations SHOULD follow the recommendations below in order to use retransmission.
RTP重传有增加网络拥塞的风险。在尽力而为的环境中，数据包丢失是由拥塞引起的。在不降低原始流速率的情况下，通过重新传输旧数据来应对丢失，将进一步增加拥塞。为了使用重传，实现应遵循以下建议。
The RTP profile under which the retransmission scheme is used defines an appropriate congestion control mechanism in different environments. Following the rules under the profile, an RTP application can determine its acceptable bitrate and packet rate in order to be fair to other TCP or RTP flows.
使用重传方案的RTP配置文件定义了不同环境中的适当拥塞控制机制。按照概要文件下的规则，RTP应用程序可以确定其可接受的比特率和数据包速率，以便对其他TCP或RTP流公平。
If an RTP application uses retransmission, the acceptable packet rate and bitrate include both the original and retransmitted data. This guarantees that an application using retransmission achieves the same fairness as one that does not. Such a rule would translate in practice into the following actions:
如果RTP应用程序使用重新传输，则可接受的分组速率和比特率包括原始数据和重新传输的数据。这保证了使用重传的应用程序实现与不使用重传的应用程序相同的公平性。这一规则将在实践中转化为以下行动：
If enhanced service is used, it should be made sure that the total bitrate and packet rate do not exceed that of the requested service. It should be further monitored that the requested services are actually delivered. In a best-effort environment, the sender SHOULD NOT send retransmission packets without reducing the packet rate and bitrate of the original stream (for example, by encoding the data at a lower rate).
如果使用增强服务，则应确保总比特率和数据包速率不超过所请求服务的比特率和数据包速率。应进一步监控请求的服务是否实际交付。在尽力而为的环境中，发送方不应在不降低原始流的分组速率和比特率的情况下发送重传分组（例如，通过以较低的速率编码数据）。
In addition, the sender MAY selectively retransmit only the packets that it deems important and ignore NACK messages for other packets in order to limit the bitrate.
此外，发送方可选择性地仅重传其认为重要的分组，并忽略其他分组的NACK消息以限制比特率。
These congestion control mechanisms should keep the packet loss rate within acceptable parameters. In the context of congestion control, packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve, on a reasonable timescale, an average throughput that is not less than the one the RTP flow achieves. If congestion is not kept under control, then retransmission SHOULD NOT be used.
这些拥塞控制机制应将丢包率保持在可接受的参数范围内。在拥塞控制的上下文中，如果跨越相同网络路径并经历相同网络条件的TCP流在合理的时间尺度上实现不小于RTP流实现的平均吞吐量，则认为分组丢失是可接受的。如果拥塞未得到控制，则不应使用重传。
Retransmissions MAY still be sent in some cases, e.g., in wireless links where packet losses are not caused by congestion, if the server (or the client that makes the retransmission request) estimates that a particular packet or frame is important to continue play out, or if an RTSP PAUSE has been issued to allow the buffer to fill up (RTSP PAUSE does not affect the sending of retransmissions).
在某些情况下，如果服务器（或发出重传请求的客户端）估计特定分组或帧对于继续播放很重要，或者如果已发出RTSP暂停以允许缓冲区填满，则重传仍然可以发送，例如，在包丢失不是由拥塞引起的无线链路中（RTSP暂停不影响发送重传）。
Finally, it may further be necessary to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or to arrange for the receiver to leave the session.
最后，可能还需要调整传输速率（或为分层多播会话预订的层数），或安排接收机离开会话。
The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time", and "apt".
本文档介绍了以下MIME子类型名称和参数：“rtx”、“rtx时间”和“apt”。
The binding used for the retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx".
用于重传流到有效负载类型号的绑定由rtpmap属性指示。绑定中使用的MIME子类型名称为“rtx”。
The "apt" (associated payload type) parameter MUST be used to map the retransmission payload type to the associated original stream payload type. If multiple original payload types are used, then multiple "apt" parameters MUST be included to map each original payload type to a different retransmission payload type.
“apt”（关联有效负载类型）参数必须用于将重传有效负载类型映射到关联的原始流有效负载类型。如果使用多个原始有效负载类型，则必须包括多个“apt”参数，以将每个原始有效负载类型映射到不同的重传有效负载类型。
An OPTIONAL payload-format-specific parameter, "rtx-time", indicates the maximum time a sender will keep an original RTP packet in its buffers available for retransmission. This time starts with the first transmission of the packet.
可选的有效负载格式特定参数“rtx时间”表示发送方将原始RTP数据包保留在其缓冲区中以供重新传输的最长时间。这一次从数据包的第一次传输开始。
The syntax is as follows:
语法如下：
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
where
哪里
<number>: indicates the dynamic payload type number assigned to the retransmission payload format in an rtpmap attribute.
<number>：表示在rtpmap属性中分配给重传有效负载格式的动态有效负载类型编号。
<apt-value>: is the value of the original stream payload type to which this retransmission stream payload type is associated.
<apt value>：与此重传流有效负载类型关联的原始流有效负载类型的值。
<rtx-time-val>: specifies the time in milliseconds (measured from the time a packet was first sent) that a sender keeps an RTP packet in its buffers available for retransmission. The absence of the rtx-time parameter for a retransmission stream means that the maximum retransmission time is not defined, but MAY be negotiated by other means.
<rtx time val>：指定发送方在其缓冲区中保留RTP数据包以供重新传输的时间（以毫秒为单位）（从数据包第一次发送时开始测量）。对于重传流不存在rtx时间参数意味着未定义最大重传时间，但可以通过其他方式协商。
MIME type: audio
MIME类型：音频
MIME subtype: rtx
MIME子类型：rtx
Required parameters:
所需参数：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
速率：RTP时间戳时钟速率等于重新传输的媒体的RTP时间戳时钟速率。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
apt：关联的有效负载类型。此参数的值是关联原始流的有效负载类型。
Optional parameters:
可选参数：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
rtx时间：表示发送方在其缓冲区中保留RTP数据包以供重新传输的时间（以毫秒为单位，从数据包第一次发送时算起）。
Encoding considerations: this type is only defined for transfer via RTP.
编码注意事项：此类型仅为通过RTP传输而定义。
Security considerations: see Section 12 of RFC 4588
安全注意事项：见RFC 4588第12节
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4588
已发布规范：RFC 4588
Applications which use this media type: multimedia streaming applications
使用此媒体类型的应用程序：多媒体流应用程序
Additional information: none
其他信息：无
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
联系人和电子邮件地址，以获取更多信息：jose。rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
预期用途：普通
Authors: Jose Rey David Leon
作者：何塞·雷伊·大卫·莱昂
Change controller: IETF AVT WG delegated from the IESG
变更控制员：IESG授权的IETF AVT工作组
MIME type: video
MIME类型：视频
MIME subtype: rtx
MIME子类型：rtx
Required parameters:
所需参数：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
速率：RTP时间戳时钟速率等于重新传输的媒体的RTP时间戳时钟速率。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
apt：关联的有效负载类型。此参数的值是关联原始流的有效负载类型。
Optional parameters:
可选参数：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
rtx时间：表示发送方在其缓冲区中保留RTP数据包以供重新传输的时间（以毫秒为单位，从数据包第一次发送时算起）。
Encoding considerations: this type is only defined for transfer via RTP.
编码注意事项：此类型仅为通过RTP传输而定义。
Security considerations: see Section 12 of RFC 4588
安全注意事项：见RFC 4588第12节
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4588
已发布规范：RFC 4588
Applications which use this media type: multimedia streaming applications
使用此媒体类型的应用程序：多媒体流应用程序
Additional information: none
其他信息：无
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
联系人和电子邮件地址，以获取更多信息：jose。rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
预期用途：普通
Authors: Jose Rey David Leon
作者：何塞·雷伊·大卫·莱昂
Change controller: IETF AVT WG delegated from the IESG
变更控制员：IESG授权的IETF AVT工作组
MIME type: text
MIME类型：文本
MIME subtype: rtx
MIME子类型：rtx
Required parameters:
所需参数：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
速率：RTP时间戳时钟速率等于重新传输的媒体的RTP时间戳时钟速率。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
apt：关联的有效负载类型。此参数的值是关联原始流的有效负载类型。
Optional parameters:
可选参数：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
rtx时间：表示发送方在其缓冲区中保留RTP数据包以供重新传输的时间（以毫秒为单位，从数据包第一次发送时算起）。
Encoding considerations: this type is only defined for transfer via RTP.
编码注意事项：此类型仅为通过RTP传输而定义。
Security considerations: see Section 12 of RFC 4588
安全注意事项：见RFC 4588第12节
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4588
已发布规范：RFC 4588
Applications which use this media type: multimedia streaming applications
使用此媒体类型的应用程序：多媒体流应用程序
Additional information: none
其他信息：无
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
联系人和电子邮件地址，以获取更多信息：jose。rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
预期用途：普通
Authors: Jose Rey David Leon
作者：何塞·雷伊·大卫·莱昂
Change controller: IETF AVT WG delegated from the IESG
变更控制员：IESG授权的IETF AVT工作组
MIME type: application
MIME类型：应用程序
MIME subtype: rtx
MIME子类型：rtx
Required parameters:
所需参数：
rate: the RTP timestamp clockrate is equal to the RTP timestamp clockrate of the media that is retransmitted.
速率：RTP时间戳时钟速率等于重新传输的媒体的RTP时间戳时钟速率。
apt: associated payload type. The value of this parameter is the payload type of the associated original stream.
apt：关联的有效负载类型。此参数的值是关联原始流的有效负载类型。
Optional parameters:
可选参数：
rtx-time: indicates the time in milliseconds (measured from the time a packet was first sent) that the sender keeps an RTP packet in its buffers available for retransmission.
rtx时间：表示发送方在其缓冲区中保留RTP数据包以供重新传输的时间（以毫秒为单位，从数据包第一次发送时算起）。
Encoding considerations: this type is only defined for transfer via RTP.
编码注意事项：此类型仅为通过RTP传输而定义。
Security considerations: see Section 12 of RFC 4588
安全注意事项：见RFC 4588第12节
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4588
已发布规范：RFC 4588
Applications which use this media type: multimedia streaming applications
使用此媒体类型的应用程序：多媒体流应用程序
Additional information: none
其他信息：无
Person & email address to contact for further information: jose.rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
联系人和电子邮件地址，以获取更多信息：jose。rey@eu.panasonic.com davidleon123@yahoo.com avt@ietf.org
Intended usage: COMMON
预期用途：普通
Authors: Jose Rey David Leon
作者：何塞·雷伊·大卫·莱昂
Change controller: IETF AVT WG delegated from the IESG
变更控制员：IESG授权的IETF AVT工作组
The information carried in the MIME media type specification has a specific mapping to fields in SDP [5], which is commonly used to describe RTP sessions. When SDP is used to specify retransmissions for an RTP stream, the mapping is done as follows:
MIME媒体类型规范中包含的信息与SDP[5]中的字段有特定的映射，SDP[5]通常用于描述RTP会话。当SDP用于指定RTP流的重传时，映射如下所示：
- The MIME types ("video"), ("audio"), ("text"), and ("application") go in the SDP "m=" as the media name.
- MIME类型（“视频”）、（“音频”）、（“文本”）和（“应用程序”）以SDP“m=”作为媒体名称。
- The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding name. The RTP clockrate in "a=rtpmap" MUST be that of the retransmission payload type. See Section 4 for details on this.
- MIME子类型（“rtx”）以SDP“a=rtpmap”作为编码名称。“a=rtpmap”中的RTP时钟速率必须为重传有效负载类型。有关这方面的详细信息，请参见第4节。
- The AVPF profile-specific parameters "ack" and "nack" go in SDP "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of feedback. See the AVPF profile [1] for details.
- AVPF配置文件特定参数“ack”和“nack”进入SDP“a=rtcp fb”。几种SDP“a=rtcp fb”用于几种类型的反馈。有关详细信息，请参见AVPF配置文件[1]。
- The retransmission payload-format-specific parameters "apt" and "rtx-time" go in the SDP "a=fmtp" as a semicolon-separated list of parameter=value pairs.
- 重传有效负载格式特定参数“apt”和“rtx时间”以分号分隔的参数=值对列表的形式出现在SDP“a=fmtp”中。
- Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
- 通过直接从MIME媒体类型字符串中以分号分隔的参数=值对列表形式复制其余参数，将其放入SDP“a=fmtp”属性中。
In the following sections, some example SDP descriptions are presented. In some of these examples, long lines are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows it should be ignored.
在以下部分中，将介绍一些示例SDP描述。在其中一些示例中，长行被折叠以满足本文档的列宽约束；应忽略行尾的反斜杠（\）和其后的回车符。
In the case of session-multiplexing, the SDP description contains one media specification "m" line per RTP session. The SDP MUST provide the grouping of the original and associated retransmission sessions' "m" lines, using the Flow Identification (FID) semantics defined in RFC 3388 [6].
在会话多路复用的情况下，SDP描述包含每个RTP会话的一个媒体规范“m”行。SDP必须使用RFC 3388[6]中定义的流标识（FID）语义，提供原始和相关重传会话“m”行的分组。
The following example specifies two original, AMR and MPEG-4, streams on ports 49170 and 49174 and their corresponding retransmission streams on ports 49172 and 49176, respectively:
以下示例分别指定端口49170和49174上的两个原始AMR和MPEG-4流以及端口49172和49176上相应的重传流：
v=0 o=mascha 2980675221 2980675778 IN IP4 host.example.net c=IN IP4 192.0.2.0 a=group:FID 1 2
v=0 o=IP4主机中的mascha 2980675221 2980675778.example.net c=IP4 192.0.2.0 a=group:FID 1 2
a=group:FID 3 4
m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack
a=mid:1
m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000
a=mid:2
m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=mid:3
m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
a=mid:4
a=group:FID 3 4
m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack
a=mid:1
m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000
a=mid:2
m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=mid:3
m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
a=mid:4
A special case of the SDP description is a description that contains only one original session "m" line and one retransmission session "m" line, the grouping is then obvious and FID semantics MAY be omitted in this special case only.
SDP描述的特例是仅包含一个原始会话“m”行和一个重传会话“m”行的描述，因此分组是明显的，并且仅在该特例中可以省略FID语义。
This is illustrated in the following example, which is an SDP description for a single original MPEG-4 stream and its corresponding retransmission session:
这在以下示例中说明，该示例是单个原始MPEG-4流及其对应的重传会话的SDP描述：
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
The following is an example of an SDP description for an RTP video session using SSRC-multiplexing with similar parameters as in the single-session example above:
以下是使用SSRC多路复用的RTP视频会话的SDP描述示例，该SSRC多路复用具有与上述单个会话示例中类似的参数：
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
0A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
The Real Time Streaming Protocol (RTSP), RFC 2326 [7], is an application-level protocol for control over the delivery of data with real-time properties. This section looks at the issues involved in controlling RTP sessions that use retransmissions.
实时流协议（RTSP）RFC 2326[7]是一种应用程序级协议，用于控制具有实时属性的数据传输。本节介绍控制使用重传的RTP会话所涉及的问题。
In the case of SSRC-multiplexing, the "m" line includes both original and retransmission payload types and has a single RTSP "control" attribute. The receiver uses the "m" line to request SETUP and TEARDOWN of the whole media session. The RTP profile contained in the Transport header MUST be the AVPF profile or another suitable profile allowing extended feedback. If the SSRC value is included in the SETUP response's Transport header, it MUST be that of the original stream.
在SSRC多路复用的情况下，“m”线包括原始和重传有效负载类型，并且具有单个RTSP“控制”属性。接收器使用“m”行请求设置和拆除整个媒体会话。传输报头中包含的RTP配置文件必须是AVPF配置文件或其他允许扩展反馈的合适配置文件。如果设置响应的传输头中包含SSRC值，则该值必须是原始流的值。
In order to control the sending of the session original media stream, the receiver sends as usual PLAY and PAUSE requests to the sender for the session. The RTP-info header that is used to set RTP-specific parameters in the PLAY response MUST be set according to the RTP information of the original stream.
为了控制会话原始媒体流的发送，接收方像往常一样向发送方发送会话的播放和暂停请求。用于在播放响应中设置RTP特定参数的RTP info标头必须根据原始流的RTP信息进行设置。
When the receiver starts receiving the original stream, it can then request retransmission through RTCP NACKs without additional RTSP signalling.
当接收器开始接收原始流时，它可以通过RTCP NACKs请求重新传输，而无需额外的RTSP信令。
In the case of session-multiplexing, each SDP "m" line has an RTSP "control" attribute. Hence, when retransmission is used, both the original session and the retransmission have their own "control" attributes. The receiver can associate the original session and the retransmission session through the FID semantics as specified in Section 8.
在会话多路复用的情况下，每个SDP“m”线都有一个RTSP“control”属性。因此，当使用重传时，原始会话和重传都具有它们自己的“控制”属性。接收方可以通过FID语义将原始会话和重传会话关联起来，如第8节所述。
The original and the retransmission streams are set up and torn down separately through their respective media "control" attribute. The RTP profile contained in the Transport header MUST be the AVPF profile or another suitable profile allowing extended feedback for both the original and the retransmission sessions.
原始流和重传流通过各自的媒体“控制”属性分别设置和分解。传输报头中包含的RTP配置文件必须是AVPF配置文件或另一个适当的配置文件，允许对原始会话和重传会话进行扩展反馈。
The RTSP presentation SHOULD support aggregate control and SHOULD contain a session-level RTSP URL. The receiver SHOULD use aggregate control for an original session and its associated retransmission session. Otherwise, there would need to be two different 'session-id' values, i.e., different values for the original and retransmission sessions, and the sender would not know how to associate them.
RTSP表示应支持聚合控制，并应包含会话级RTSP URL。接收方应对原始会话及其关联的重传会话使用聚合控制。否则，将需要两个不同的“会话id”值，即原始会话和重传会话的不同值，并且发送方将不知道如何关联它们。
The session-level "control" attribute is then used as usual to control the playing of the original stream. When the receiver starts receiving the original stream, it can then request retransmissions through RTCP without additional RTSP signalling.
然后像往常一样使用会话级别的“control”属性来控制原始流的播放。当接收器开始接收原始流时，它可以通过RTCP请求重新传输，而无需额外的RTSP信令。
Because of the nature of retransmissions, the sending of retransmission packets SHOULD NOT be controlled through RTSP PLAY and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect the retransmission stream. Retransmission packets are sent upon receiver requests in the original RTCP stream, regardless of the state.
由于重传的性质，不应通过RTSP播放和暂停请求来控制重传数据包的发送。播放和暂停请求不应影响重传流。在原始RTCP流中的接收器请求时发送重传数据包，而不管状态如何。
Retransmission streams SHOULD NOT be cached.
不应缓存重传流。
In the case of session-multiplexing, the "Cache-Control" header SHOULD be set to "no-cache" for the retransmission stream.
在会话多路复用的情况下，重传流的“缓存控制”报头应设置为“无缓存”。
In the case of SSRC-multiplexing, RTSP cannot specify independent caching for the retransmission stream, because there is a single "m" line in SDP. Therefore, the implementer should take this fact into account when deciding whether or not to cache an SSRC-multiplexed session.
在SSRC多路复用的情况下，RTSP不能为重传流指定独立缓存，因为SDP中只有一条“m”线。因此，在决定是否缓存SSRC多路复用会话时，实现者应该考虑这一事实。
This document mandates only the sender and receiver behaviours that are necessary for interoperability. In addition, certain algorithms, such as rate control or buffer management when targeted at specific environments, may enhance the retransmission efficiency.
本文档仅规定互操作性所需的发送方和接收方行为。此外，某些算法，例如针对特定环境的速率控制或缓冲区管理，可以提高重传效率。
This section gives an overview of different implementation options allowed within this specification.
本节概述了本规范中允许的不同实现选项。
The first example describes a minimal receiver implementation. With this implementation, it is possible to retransmit lost RTP packets, detect efficiently the loss of retransmissions, and perform multiple retransmissions, if needed. Most of the necessary processing is done at the server.
第一个示例描述了一个最小的接收器实现。通过这种实现，可以重新传输丢失的RTP数据包，有效地检测重新传输的丢失，并在需要时执行多次重新传输。大多数必要的处理在服务器上完成。
The second example shows how retransmissions may be used in (small) multicast groups in conjunction with layered encoding. It illustrates that retransmissions and layered encoding may be complementary techniques.
第二个示例显示了如何在（小）多播组中结合分层编码使用重传。它说明了重传和分层编码可以是互补技术。
This section gives an example of an implementation supporting multiple retransmissions. The sender transmits the original data in RTP packets using the MPEG-4 video RTP payload format. It is assumed that NACK feedback messages are used, as per [1]. An SDP description example with SSRC-multiplexing is given below:
本节给出了支持多次重传的实现示例。发送方使用MPEG-4视频RTP有效负载格式以RTP数据包的形式传输原始数据。根据[1]，假设使用了NACK反馈消息。下面给出了具有SSRC多路复用的SDP描述示例：
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
The format-specific parameter "rtx-time" indicates that the server will buffer the sent packets in a retransmission buffer for 3.0 seconds, after which the packets are deleted from the retransmission buffer and will never be sent again.
格式特定参数“rtx时间”表示服务器将在重传缓冲区中缓冲发送的数据包3.0秒，之后数据包将从重传缓冲区中删除，并且不再发送。
In this implementation example, the required RTP receiver processing to handle retransmission is kept to a minimum. The receiver detects packet loss from the gaps observed in the received sequence numbers. It signals lost packets to the sender through NACKs as defined in the AVPF profile [1]. The receiver should take into account the signalled sender retransmission buffer length in order to dimension its own reception buffer. It should also derive from the buffer length the maximum number of times the retransmission of a packet can be requested.
在该实施例中，处理重传所需的RTP接收机处理保持在最小。接收机从接收序列号中观察到的间隔检测分组丢失。它通过AVPF配置文件[1]中定义的NACK向发送方发送丢失数据包的信号。接收机应考虑信号发送方重传缓冲区的长度，以确定其自身接收缓冲区的尺寸。它还应该从缓冲区长度中得出可以请求数据包重传的最大次数。
The sender should retransmit the packets selectively; i.e., it should choose whether to retransmit a requested packet depending on the packet importance, the observed Quality of Service (QoS), and congestion state of the network connection to the receiver. Obviously, the sender processing increases with the number of receivers as state information and processing load must be allocated to each receiver.
发送方应选择性地重发数据包；i、 例如，它应该根据包的重要性、观察到的服务质量（QoS）和到接收器的网络连接的拥塞状态来选择是否重新传输请求的包。显然，发送方处理随着接收方数量的增加而增加，因为状态信息和处理负载必须分配给每个接收方。
This section shows how to combine retransmissions with layered encoding in multicast sessions. Note that the retransmission framework is offered only for small multicast applications. Refer to RFC 2887 [10] for a discussion of the problems of NACK implosion, severe congestion caused by feedback traffic, in large-group reliable multicast applications.
本节介绍如何在多播会话中将重传与分层编码结合起来。请注意，重传框架仅为小型多播应用程序提供。请参阅RFC 2887[10]，了解关于大型组可靠多播应用中NACK内爆、反馈流量导致的严重拥塞问题的讨论。
Packets of different importance are sent in different RTP sessions. The retransmission streams corresponding to the different layers can themselves be seen as different retransmission layers. The relative importance of the different retransmission streams should reflect the relative importance of the different original streams.
在不同的RTP会话中发送不同重要性的数据包。对应于不同层的重传流本身可以被视为不同的重传层。不同重传流的相对重要性应反映不同原始流的相对重要性。
In multicast, SSRC-multiplexing of the original and retransmission streams is not allowed as per Section 5.3 of this document. For this reason, the retransmission stream(s) MUST be sent in different RTP session(s) using session-multiplexing.
在多播中，根据本文件第5.3节，不允许对原始和重传流进行SSRC多路复用。因此，必须使用会话多路复用在不同的RTP会话中发送重传流。
An SDP description example of multicast retransmissions for layered encoded media is given below:
下面给出分层编码媒体的多播重传的SDP描述示例：
m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
The server and the receiver may implement the retransmission methods illustrated in the previous examples. In addition, they may choose to request and retransmit a lost packet depending on the layer it belongs to.
服务器和接收机可以实现在前面的示例中说明的重传方法。此外，他们可以根据丢失的数据包所属的层选择请求和重新传输丢失的数据包。
A new MIME subtype name, "rtx", has been registered for four different media types, as follows: "video", "audio", "text" and "application". An additional REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", are defined. See Section 8 for details.
新的MIME子类型名称“rtx”已注册为四种不同的媒体类型，如下：“视频”、“音频”、“文本”和“应用程序”。定义了一个额外的必需参数“apt”和一个可选参数“rtx时间”。详情见第8节。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3], Section 9.
使用本规范中定义的有效负载格式的RTP数据包应遵守RTP[3]第9节中讨论的一般安全注意事项。
In common streaming scenarios message authentication, data integrity, replay protection, and confidentiality are desired.
在常见的流式场景中，需要消息身份验证、数据完整性、重播保护和机密性。
The absence of authentication may enable man-in-the-middle and replay attacks, which can be very harmful for RTP retransmission. For example: tampered RTCP packets may trigger inappropriate retransmissions that effectively reduce the actual bitrate share allocated to the original data stream, tampered RTP retransmission packets could cause the client's decoder to crash, and tampered retransmission requests may invalidate the SSRC association mechanism described in Section 5 of this document. On the other hand, replayed packets could lead to false reordering and RTT measurements (required for the retransmission request strategy) and may cause the receiver buffer to overflow.
缺少身份验证可能导致中间人攻击和重播攻击，这对RTP重传非常有害。例如：被篡改的RTCP数据包可能会触发不适当的重新传输，从而有效降低分配给原始数据流的实际比特率份额，被篡改的RTP重新传输数据包可能会导致客户端解码器崩溃，被篡改的重传请求可能使本文件第5节中描述的SSRC关联机制失效。另一方面，重播的数据包可能导致错误的重新排序和RTT测量（重传请求策略所需），并可能导致接收器缓冲区溢出。
Furthermore, in order to ensure confidentiality of the data, the original payload data needs to be encrypted. There is actually no need to encrypt the 2-byte retransmission payload header since it does not provide any hints about the data content.
此外，为了确保数据的机密性，需要对原始有效载荷数据进行加密。实际上不需要加密2字节重传有效负载报头，因为它不提供有关数据内容的任何提示。
Furthermore, it is RECOMMENDED that the cryptography mechanisms used for this payload format provide protection against known plaintext attacks. RTP recommends that the initial RTP timestamp SHOULD be random to secure the stream against known plaintext attacks. This payload format does not follow this recommendation as the initial timestamp will be the media timestamp of the first retransmitted packet. However, since the initial timestamp of the original stream is itself random, if the original stream is encrypted, the first retransmitted packet timestamp would also be random to an attacker. Therefore, confidentiality would not be compromised.
此外，建议使用明文加密机制来防止明文攻击。RTP建议初始RTP时间戳应该是随机的，以保护流免受已知明文攻击。此有效负载格式不遵循此建议，因为初始时间戳将是第一个重传分组的媒体时间戳。然而，由于原始流的初始时间戳本身是随机的，因此如果原始流被加密，则第一个重传的数据包时间戳对攻击者来说也是随机的。因此，保密性不会受到损害。
If cryptography is used to provide security services on the original stream, then the same services, with equivalent cryptographic strength, MUST be provided on the retransmission stream. The use of
如果使用加密技术在原始流上提供安全服务，则必须在重传流上提供具有同等加密强度的相同服务。使用
the same key for the retransmitted stream and the original stream may lead to security problems, e.g., two-time pads. Refer to Section 9.1 of the Secure Real-Time Transport Protocol (SRTP) [12] for a discussion the implications of two-time pads and how to avoid them.
重传流和原始流的相同密钥可能导致安全问题，例如，两个时间pad。请参阅安全实时传输协议（SRTP）[12]第9.1节，了解两个时间PAD的含义以及如何避免它们的讨论。
At the time of writing this document, SRTP does not provide all the security services mentioned. There are, at least, two reasons for this: 1) the occurrence of two-time pads and 2) the fact that this payload format typically works under the RTP/AVPF profile whereas SRTP only supports RTP/AVP. An adapted variant of SRTP shall solve these shortcomings in the future.
在编写本文件时，SRTP并未提供所有提及的安全服务。至少有两个原因：1）出现两个时间焊盘，2）此有效负载格式通常在RTP/AVPF配置文件下工作，而SRTP仅支持RTP/AVP。SRTP的一种改进型将在未来解决这些缺点。
Congestion control considerations with the use of retransmission are dealt with in Section 7 of this document.
本文件第7节讨论了使用重传时的拥塞控制问题。
We would like to express our gratitude to Carsten Burmeister for his participation in the development of this document. Our thanks also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, Go Hori, and Rahul Agarwal for their helpful comments.
我们感谢Carsten Burmeister参与本文件的编制。我们还要感谢Hata Koichi、Colin Perkins、Stephen Casner、Magnus Westerlund、go Hori和Rahul Agarwal提供的有益评论。
[1] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP profile for Real-time Transport Control Protocol (RTCP)-Based feedback", RFC 4585, July 2006.
[1] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）反馈的扩展RTP配置文件”，RFC 45852006年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[4] Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[6] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[7] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[7] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[8] Perkins，C.和O.Hodson，“修复流媒体的选项”，RFC 2354，1998年6月。
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[9] Hellstrom，G.和P.Jones，“文本对话的RTP有效载荷”，RFC 4103，2005年6月。
[10] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[10] Handley，M.，Floyd，S.，Whetten，B.，Kermode，R.，Vicisano，L.，和M.Luby，“批量数据传输的可靠多播设计空间”，RFC 2887，2000年8月。
[11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[11] Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[12] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
Finding out the number of retransmissions (rtxs.) per packet for achieving the best possible transmission is a difficult task. Of course, the absolute minimum should be one (1); otherwise, do not use this payload format. Moreover, as of date of publication, the authors were not aware of any studies on the number of retransmissions per packet that should be used for best performance. To help implementers and researchers on this item, this section describes an estimate of the buffering time required for achieving a given number of retransmissions. Once this time has been calculated, it can be communicated to the client via SDP parameter "rtx-time", as defined in this document.
找出每个数据包的重传次数（RTX）以实现最佳传输是一项困难的任务。当然，绝对最小值应为一（1）；否则，请勿使用此有效负载格式。此外，截至发表之日，作者不知道有任何关于每个数据包的重传次数的研究，这些数据包应用于最佳性能。为了帮助实施者和研究者解决这一问题，本节描述了实现给定数量的重传所需的缓冲时间估计。一旦计算出该时间，就可以通过SDP参数“rtx时间”（如本文件中所定义）将其传达给客户机。
* Streaming scenario with relaxed delay bounds. Client and server are provided with buffering space as indicated by the parameter "rtx-time" in SDP.
* 具有宽松延迟边界的流式场景。客户端和服务器都有缓冲空间，如SDP中的参数“rtx时间”所示。
* RTP AVPF profile used with SSRC-multiplexing retransmission scheme: 1 SSRC for original packets, 1 for retransmission packets.
* RTP AVPF配置文件与SSRC多路复用重传方案一起使用：1个SSRC用于原始数据包，1个用于重传数据包。
* Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR = 0.05. We have senders (2) and receivers (1). Receivers and senders get equally 1/3 of the RTCP bandwidth share because the proportion of senders is greater than 1/4 of session members.
* SRs和RRs的默认RTCP带宽共享，即SR+RR=0.05。我们有发送方（2）和接收方（1）。由于发送方的比例大于会话成员的1/4，因此接收方和发送方同等获得RTCP带宽共享的1/3。
* avg-rtcp-size is approximated by 120 bytes. This is a rounded-up average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes. Since senders and receivers share the RTCP bandwidth equally, then avg-rtcp-size = (157+105+105)/3 = 117.3 ~= 120 bytes. The important characteristic of this value is that it is something over 100 bytes, which seems to be a representative figure for typical configurations.
* 平均rtcp大小约为120字节。这是2个SRs的四舍五入平均值，每个SSRC一个，包含40/8/28/32字节（对于带有CNAME的IPv6/UDP/SR/SDE），因此每个SRs包含105字节；对于IPv6/UDP/2*RR/SDES，RR为40/8/64/32字节，为157字节。由于发送方和接收方平均共享RTCP带宽，因此平均RTCP大小=（157+105+105）/3=117.3~=120字节。该值的重要特征是超过100字节，这似乎是典型配置的代表性数字。
* The profile used is AVPF [1] and Generic NACKs are used for requesting retransmissions. This adds 16 bytes of overhead for 1 NACK and 4 bytes more for every additional NACK Feedback Control Information (FCI) field.
* 使用的配置文件是AVPF[1]，通用nack用于请求重传。这为1个NACK增加了16字节的开销，为每个额外的NACK反馈控制信息（FCI）字段增加了4字节的开销。
* We assume a worst-case scenario in which each packet exhausts its corresponding number of available retransmissions, N, before it is received. This means that if a packet is requested for retransmission a maximum of 2 times, the corresponding generic NACK report block requesting that particular packet is sent in two
* 我们假设一种最坏的情况，在这种情况下，每个数据包在被接收之前都会耗尽其相应的可用重传次数N。这意味着，如果请求重发分组最多2次，则请求该特定分组的相应通用NACK报告块分两次发送
consecutive RTCP compounds; likewise, if it is requested for retransmission 10 times, then the generic NACK is sent 10 times. This assumption makes the RTCP packet size approximately constant after N*RTCP intervals (seconds), namely, to avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N). In our case, the receiver RTCP bandwidth share is 1/3; thus, avg-rtcp-size = 124 + 4*N/3.
连续RTCP化合物；类似地，如果请求重传10次，则通用NACK被发送10次。该假设使RTCP数据包大小在N*RTCP间隔（秒）后近似恒定，即，至平均RTCP大小=120+（接收器RTCP bw共享）*（12+4*N）。在我们的例子中，接收机RTCP带宽共享为1/3；因此，平均rtcp大小=124+4*N/3。
* Two delay parameters are difficult to approximate and may be implementation dependent. Therefore, we list them here explicitly without assigning them a particular value: one is the packet loss detection time (T2), and the other is feedback processing and queuing time for retransmissions (T5). Implementers shall assign appropriate values to these two parameters.
* 两个延迟参数很难近似，并且可能依赖于实现。因此，我们在这里明确列出它们，而不给它们分配特定的值：一个是丢包检测时间（T2），另一个是反馈处理和重传排队时间（T5）。实施者应为这两个参数分配适当的值。
Graphically, we have the following:
从图形上看，我们有以下内容：
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
Legend:
=======
DL: downlink (client->server)
UL: uplink (server->client)
Time unit is seconds, s.
Bitrate unit is bits per second, bps.
Legend:
=======
DL: downlink (client->server)
UL: uplink (server->client)
Time unit is seconds, s.
Bitrate unit is bits per second, bps.
DL transmission time: T1 = physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
DL transmission time: T1 = physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
Time to detect packet loss: T2 = pkt-loss-detect-time
检测数据包丢失的时间：T2=pkt丢失检测时间
Time to report packet loss: T3 = time-to-next-rtcp-report
报告数据包丢失的时间：T3=下一次rtcp报告的时间
UL transmission time: T4 = physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter
UL transmission time: T4 = physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter
Retransmissions processing time: T5 = feedback-processing-time + rtx-queuing-time
重传处理时间：T5=反馈处理时间+rtx排队时间
To find an estimate of the buffering time, T(), that a streaming server shall use in order to enable a given number of retransmissions for each packet, N. This time is approximately equal at the server and at the client, if one considers that the client starts buffering T1 seconds later.
找到流服务器应使用的缓冲时间T（）的估计值，以便为每个数据包启用给定次数的重新传输，N。如果认为客户端在T1秒后开始缓冲，则该时间在服务器和客户端大致相等。
First, we find the value of the estimate for 1 retransmission, T(1)=T:
首先，我们找到1次重传的估计值，T（1）=T：
T = T1 + T2 + T3 + T4 + T5
T = T1 + T2 + T3 + T4 + T5
Since T1 + T4 ~= RTT,
由于T1+T4~=RTT，
T = RTT + T2 + T3 + T5
T = RTT + T2 + T3 + T5
The worst case for T3 would be that we assume that reporting has to wait a whole RTCP interval and that the maximum randomization factor of 1.5 is applied. Therefore, after applying the subsequent compensation to avoid traffic bursts (see Appendix A.7 of RTP [3]), we have that T3 = 1.5/1.21828*RTCP-Interval. Thus,
T3的最坏情况是，我们假设报告必须等待整个RTCP间隔，并且应用最大随机化因子1.5。因此，在应用后续补偿以避免流量突发（见RTP[3]的附录A.7）后，我们得出T3=1.5/1.21828*RTCP间隔。因此
T = RTT + 1.2312*RTCP-Interval + T2 + T5
T = RTT + 1.2312*RTCP-Interval + T2 + T5
On the other hand, RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS). In this scenario: sender + receivers = 3; RR+RS is the receiver report plus sender report bandwidth share, in this case, equal to the default 5% of session bandwidth, bw. We assume an average RTCP packet size, avg-rtcp-size = 120 bytes. Thus:
另一方面，RTCP间隔=平均RTCP大小*8*（发送方+接收方）/（RR+RS）。在这种情况下：发送方+接收方=3；RR+RS是接收方报告加发送方报告带宽共享，在本例中，等于会话带宽的默认5%，bw。我们假设平均RTCP数据包大小，平均RTCP大小=120字节。因此：
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
for 1 retransmission.
用于1次重新传输。
For enabling N retransmissions, the available buffering time in a streaming server or client is approximately:
对于启用N次重传，流式服务器或客户端中的可用缓冲时间约为：
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
where, as per above,
其中，如上所述，
avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N) = 120 + (1/3)*(12 + 4*N) = 124 + 4*N/3.
平均rtcp大小=120+（接收器rtcp bw共享）*（12+4*N）=120+（1/3）*（12+4*N）=124+4*N/3。
If we ignore the effect of T2 and T5, i.e., assume that all losses are detected immediately and that there is no additional delay due to feedback processing or retransmission queuing, we have the following buffering times for different values of N:
如果我们忽略T2和T5的影响，即假设立即检测到所有丢失，并且由于反馈处理或重传队列没有额外延迟，则对于不同的N值，我们有以下缓冲时间：
RTCP w/ several Generic NACKs; variable packet size = 124 + 4*N/3
bytes
RTCP w/ several Generic NACKs; variable packet size = 124 + 4*N/3
bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,21 2,44 6,28 8,97 13,18 128000 0,05 0,63 1,27 3,27 4,66 6,84 256000 0,05 0,34 0,68 1,76 2,50 3,67 512000 0,05 0,19 0,39 1,00 1,43 2,09 1024000 0,05 0,12 0,25 0,63 0,89 1,29 5000000 0,05 0,06 0,13 0,33 0,46 0,66 10000000 0,05 0,06 0,11 0,29 0,41 0,58
64000 0,05 1,21 2,44 6,28 8,97 13,18 128000 0,05 0,63 1,27 3,27 4,66 6,84 256000 0,05 0,34 0,68 1,76 2,50 3,67 512000 0,05 0,19 0,39 1,00 1,43 2,09 1024000 0,05 0,12 0,25 0,63 0,89 1,29 5000000 0,05 0,06 0,13 0,33 0,46 0,66 10000000 0,05 0,06 0,11 0,29 0,41 0,58
64000 0,2 1,36 2,74 7,03 10,02 14,68 128000 0,2 0,78 1,57 4,02 5,71 8,34 256000 0,2 0,49 0,98 2,51 3,55 5,17 512000 0,2 0,34 0,69 1,75 2,48 3,59 1024000 0,2 0,27 0,55 1,38 1,94 2,79 5000000 0,2 0,21 0,43 1,08 1,51 2,16 10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 0,2 1,36 2,74 7,03 10,02 14,68 128000 0,2 0,78 1,57 4,02 5,71 8,34 256000 0,2 0,49 0,98 2,51 3,55 5,17 512000 0,2 0,34 0,69 1,75 2,48 3,59 1024000 0,2 0,27 0,55 1,38 1,94 2,79 5000000 0,2 0,21 0,43 1,08 1,51 2,16 10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 1 2,16 4,34 11,03 15,62 22,68 128000 1 1,58 3,17 8,02 11,31 16,34 256000 1 1,29 2,58 6,51 9,15 13,17 512000 1 1,14 2,29 5,75 8,08 11,59 1024000 1 1,07 2,15 5,38 7,54 10,79 5000000 1 1,01 2,03 5,08 7,11 10,16 10000000 1 1,01 2,01 5,04 7,06 10,08
64000 1 2,16 4,34 11,03 15,62 22,68 128000 1 1,58 3,17 8,02 11,31 16,34 256000 1 1,29 2,58 6,51 9,15 13,17 512000 1 1,14 2,29 5,75 8,08 11,59 1024000 1 1,07 2,15 5,38 7,54 10,79 5000000 1 1,01 2,03 5,08 7,11 10,16 10000000 1 1,01 2,01 5,04 7,06 10,08
To quantify the error of not taking the Generic NACKS into account, we can do the same numbers, but ignoring the Generic NACK contribution, avg-rtcp-size ~= 120 bytes. As we see from below, this may result in a buffer estimation error of 1-1.5 seconds (5-10%) for lower bandwidth values and higher number of retransmissions. This effect is low in this case. Nevertheless, it should be carefully evaluated for the particular scenario; that is why the formula includes it.
为了量化不考虑通用NACK的错误，我们可以使用相同的数字，但忽略通用NACK贡献，平均rtcp大小~=120字节。正如我们从下面看到的，对于较低的带宽值和较高的重传次数，这可能导致缓冲区估计误差为1-1.5秒（5-10%）。在这种情况下，这种影响很小。尽管如此，应针对特定情景仔细评估；这就是为什么公式中包含了它。
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,16 2,32 5,79 8,11 11,58 128000 0,05 0,60 1,21 3,02 4,23 6,04 256000 0,05 0,33 0,65 1,64 2,29 3,27 512000 0,05 0,19 0,38 0,94 1,32 1,89 1024000 0,05 0,12 0,24 0,60 0,83 1,19 5000000 0,05 0,06 0,13 0,32 0,45 0,64 10000000 0,05 0,06 0,11 0,29 0,40 0,57
64000 0,05 1,16 2,32 5,79 8,11 11,58 128000 0,05 0,60 1,21 3,02 4,23 6,04 256000 0,05 0,33 0,65 1,64 2,29 3,27 512000 0,05 0,19 0,38 0,94 1,32 1,89 1024000 0,05 0,12 0,24 0,60 0,83 1,19 5000000 0,05 0,06 0,13 0,32 0,45 0,64 10000000 0,05 0,06 0,11 0,29 0,40 0,57
64000 0,2 1,31 2,62 6,54 9,16 13,08 128000 0,2 0,75 1,51 3,77 5,28 7,54 256000 0,2 0,48 0,95 2,39 3,34 4,77 512000 0,2 0,34 0,68 1,69 2,37 3,39 1024000 0,2 0,27 0,54 1,35 1,88 2,69 5000000 0,2 0,21 0,43 1,07 1,50 2,14 10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 0,2 1,31 2,62 6,54 9,16 13,08 128000 0,2 0,75 1,51 3,77 5,28 7,54 256000 0,2 0,48 0,95 2,39 3,34 4,77 512000 0,2 0,34 0,68 1,69 2,37 3,39 1024000 0,2 0,27 0,54 1,35 1,88 2,69 5000000 0,2 0,21 0,43 1,07 1,50 2,14 10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 1 2,11 4,22 10,54 14,76 21,08 128000 1 1,55 3,11 7,77 10,88 15,54 256000 1 1,28 2,55 6,39 8,94 12,77 512000 1 1,14 2,28 5,69 7,97 11,39 1024000 1 1,07 2,14 5,35 7,48 10,69 5000000 1 1,01 2,03 5,07 7,10 10,14 10000000 1 1,01 2,01 5,04 7,05 10,07
64000 1 2,11 4,22 10,54 14,76 21,08 128000 1 1,55 3,11 7,77 10,88 15,54 256000 1 1,28 2,55 6,39 8,94 12,77 512000 1 1,14 2,28 5,69 7,97 11,39 1024000 1 1,07 2,14 5,35 7,48 10,69 5000000 1 1,01 2,03 5,07 7,10 10,14 10000000 1 1,01 2,01 5,04 7,05 10,07
Authors' Addresses
作者地址
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Jose Rey Panasonic研发中心德国有限公司Monzastr。4c D-63225兰根，德国
Phone: +49-6103-766-134
Fax: +49-6103-766-166
EMail: jose.rey@eu.panasonic.com
Phone: +49-6103-766-134
Fax: +49-6103-766-166
EMail: jose.rey@eu.panasonic.com
David Leon Consultant
大卫·利昂顾问
EMail: davidleon123@yahoo.com
EMail: davidleon123@yahoo.com
Akihiro Miyazaki Matsushita Electric Industrial Co., Ltd 1006, Kadoma, Kadoma City, Osaka, Japan
日本大阪市嘉道理市嘉道理宫崎松下电器工业有限公司1006
Phone: +81-6-6900-9172
Fax: +81-6-6900-9173
EMail: miyazaki.akihiro@jp.panasonic.com
Phone: +81-6-6900-9172
Fax: +81-6-6900-9173
EMail: miyazaki.akihiro@jp.panasonic.com
Viktor Varsa Nokia Research Center 6000 Connection Drive Irving, TX. USA
美国德克萨斯州欧文市维克多·瓦萨诺基亚研究中心6000连接车道
Phone: 1-972-374-1861 EMail: viktor.varsa@nokia.com
电话：1-972-374-1861电子邮件：维克多。varsa@nokia.com
Rolf Hakenberg Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Rolf Hakenberg松下研发中心德国有限公司Monzastr。4c D-63225兰根，德国
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: rolf.hakenberg@eu.panasonic.com
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: rolf.hakenberg@eu.panasonic.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。