rfc4588 RTP重传有效载荷格式
蚂蚱google中文翻译版
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重传有效载荷格式
本备忘录的状态
本文档为Internet社区指定了Internet标准跟踪协议，并请求讨论和改进建议。请参阅当前
版本的“Internet官方协议标准”（STD 1）查看标准化状态和该协议的状态。本备忘录的发
布是无限制的。
版权声明
版权所有（C）互联网协会（2006年）。
摘要
RTP重传是一种有效的丢包恢复技术，适用于具有宽松延迟界限的实时应用。该文档描述了用于
执行重传的RTP有效载荷格式。重传的RTP分组在与原始RTP流分开的流中发送。假设从接收器
到发送器的反馈是可用的。特别是，本备忘录中假设提供了实时传输控制协议（RTCP）反馈，
该RTCP反馈在基于RTCP的反馈（表示为RTP/AVPF）的扩展RTP配置文件中定义。
Rey, et al. Standards Track [Page 1]
RFC 4588 RTP Retransmission Payload Format July 2006
Table of Contents
1. 简介 .............................................................3
2. 术语 .............................................................3
3. 重传方案的需求和设计理由 ............................................4
3.1. 多路复用方案选择 ..............................................4
4. 重传有效载荷格式 ...................................................5
5. 重传流与原始流的关联 ................................................6
5.1. 重传会话共享 ..................................................6
5.2. CNAME使用 ....................................................7
5.3. 接收端关联 ....................................................7
6. 将扩展RTP配置用于基于RTCP的反馈 ......................................7
6.1. 发送端的RTCP .................................................7
6.2. RTCP接收端报告 ...............................................8
6.3. 重传请求 .....................................................8
6.4. 时间规则 .....................................................9
7. 拥塞控制 ..........................................................9
8. 重传有效载荷格式的MIME类型注册 .......................................9
8.1. 介绍 ........................................................9
8.2. 注册audio/rtx ..............................................10
8.3. 注册video/rtx ..............................................11
8.4. 注册text/rtx ...............................................12
8.5. 注册application/rtx ........................................13
8.6. 映射到SDP ..................................................14
8.7. 使用会话多路复用的SDP描述 .....................................14
8.8. 使用SSRC多路复用的SDP描述 ....................................15
9. RTSP注意事项 .....................................................15
9.1. 使用SSRC多路复用的RTSP控制 ...................................15
9.2. 使用会话复用的RTSP控制 .......................................16
9.3. 重传流的RTSP控制 ............................................16
9.4. 缓存控制 ....................................................16
10. 实现范例 ........................................................16
10.1. 最小接收器实现示例 ...........................................17
10.2. 多播中分层编码媒体的重传 ......................................17
11. IANA 注意事项 ...................................................18
12. 安全考虑因素 .....................................................18
13. 致谢 ...........................................................18
14. 参考 ...........................................................19
14.1. 规范性参考文献 ..............................................19
14.2. 信息参考文献 ................................................19
附录A. 如何控制每个分组的重传次数 .......................................20
Rey, et al. Standards Track [Page 2]
RFC 4588 RTP Retransmission Payload Format July 2006
1. 简介
RTP发送器和接收器之间的分组丢失可能显著降低所接收媒体的质量。可以考虑若干技术，例如
前向纠错（FEC），分组重传或交织，以增加分组丢失弹性。RFC 2354 [8]讨论了不同的选择。
在为特定应用程序选择修复技术时，必须考虑应用程序的可容忍延迟。在多媒体会议的情况下，
端到端延迟必须至多几百毫秒才能保证交互性，这通常不包括使用分组重传。
足够的延迟时间，可以提高修复方案的效率。发送方可以使用接收方反馈，以便在接收方的播放
时间之前对损失作出反应。
在多媒体流的情况下，用户可以容忍作为会话建立的一部分的初始等待时间，因此可以接受几秒
的端到端延迟。本文档中定义的RTP重传针对此类应用程序。
此外，这里定义的RTP重传方法适用于单播和（小）多播组。本文件定义了重传的RTP分组的有效
载荷格式，并为重传中涉及的发送方和接收方提供了协议规则。
此重传有效载荷格式设计用于扩展RTP配置文件，用于基于RTCP的反馈，AVPF [1]。它也可以
与将来定义的其他RTP配置文件一起使用。
AVPF配置文件允许更频繁的反馈和早期反馈。它定义了通用反馈消息，即NACK，以及编解码器
和特定于应用程序的反馈消息。有关详细信息，请参见[1]。
2. 术语
本文档中使用以下术语：
CSRC: 贡献来源。 见[3]。
原始数据包：一个RTP数据包，它携带RTP发送者第一次发送的用户数据。
原始流：原始数据包的RTP流。
重传数据包：接收器使用的替代丢失的原始分组的RTP数据包。据说这种重传分组与原始RTP分
组相关联。
重传请求：RTP接收器能够请求RTP发送器应该发送给定原始分组的重传分组的手段。通常，
[1]中指定的RTCP NACK分组用作丢失分组的重传请求。
重传流：与原始流相关联的重传分组流。
会话复用：将原始流和相关的重传流发送到两个不同的RTP会话的方案。
SSRC: 同步源。 见[3]。
SSRC复用：在具有不同SSRC值的相同RTP会话中发送原始流和重传流的方案。
Rey, et al. Standards Track [Page 3]
RFC 4588 RTP Retransmission Payload Format July 2006
本文件中的关键词“必须”，“不得”，“需要”，“应当”，“不应当”，“应该”，“不应该”，“推荐”，
“可以”和“可选” 按照RFC 2119 [2]中的描述进行解释。
3. 重传方案的需求和设计理由
在具有宽松延迟界限且不需要完全可靠性的场景中，在RTP中使用重传作为流媒体的修复方法是
适当的。更具体地说，RTP重传允许人们在可靠性与延迟之间进行权衡; 即，在给定的缓冲时间
过去之后，端点可以放弃重传丢失的分组。与TCP协议不同，没有由RTP重传引起的队列头阻塞。
实施者应该意识到，在需要完全可靠性或可以容忍更高延迟和抖动的情况下，应考虑TCP或其他
传输选项。
本文档中定义的RTP重传方案旨在满足以下要求：
1. 它不能破坏通用的RTP和RTCP机制。
2. 它必须适用于单播和小型多播组。
3. 它必须能够与混音器和翻译器一起使用。
4. 它必须适用于所有已知的有效负载类型。
5. 它不能阻止在会话中使用多个有效负载类型。
6. 为了支持最大种类的有效载荷格式，RTP接收器必须能够推导出由于接收到的RTP序列号中
的间隙而丢失了多少和哪些RTP分组。该要求称为序列号保存。如果没有这样的要求，就不
可能使用有效载荷格式的重传，例如会话文本[9]或大多数音频/视频流应用，它们使用RTP
序列号来检测丢失的数据包。
在设计用于RTP重传的解决方案时，可以考虑若干方法用于复用原始RTP分组和重传的RTP分组。
一种方法可以是以其原始序列号重传RTP分组，并在同一RTP流中发送原始和重传分组。然后，
重传分组将与原始RTP分组相同，即，相同的报头（并且因此相同的序列号）和相同的有效载荷。
但是，这种方法是不可接受的，因为它会破坏RTCP统计数据。因此，不符合要求1。正确的RTCP
统计要求对于RTP流中的每个RTP分组，序列号增加1。
另一种方法可以是使用不同的有效载荷类型值在相同的RTP流中复用原始RTP分组和重传分组。
利用这种方法，原始分组和重传分组将共享相同的序列号空间。结果，RTP接收器将无法推断丢
失了多少和哪些原始分组（哪个序列号）。
换句话说，该方法不满足序列号保留要求（要求6）。这反过来意味着不满足要求4。如果他们不
理解发送方RTP流中的这种新的重传有效载荷类型，则与混合器和转换器的互操作性也将更加困难。
由于这些原因，排除了基于相同RTP流中的原始分组和重传分组的有效载荷类型复用的解决方案。
最后，原始和重传分组可以在两个单独的流中发送。这两个流可以通过在两个不同的会话中发送
它们来进行多路复用，即，会话多路复用，或者在使用不同SSRC值的相同会话中，即SSRC多路
复用。由于原始数据包和重传数据包携带相同类型的媒体，因此RTP[3]第5.2节中对RTP复用的
反对意见不适用于此情况。
混音器和翻译器可以处理原始流，如果它们无法使用，则简单地丢弃重传流。
另一方面，在两个单独的流中发送原始数据包和重发数据包并不单独满足要求1和6。为此，本
文档包含重发数据包中的原始序列号。
以这种方式，使用两个单独的流满足本节中列出的所有要求。
3.1. 多路复用方案选择
会话复用和SSRC复用具有不同的优缺点：
Rey, et al. Standards Track [Page 4]
RFC 4588 RTP Retransmission Payload Format July 2006
会话复用基于在与原始流的RTP会话（如RTP [3]中定义的）不同的RTP会话中发送重传流;
即，原始和重传流被发送到不同的网络地址和/或端口号。单独的会话允许更多的灵活性。在多
播中，对原始流和重传流使用两个单独的会话允许接收器选择是否订阅携带重传流的RTP会话。
原始会话也可以是单源多播，而单独的单播会话用于向每个接收器传送重传，结果只接收它们请
求的重传分组。
单独会话的使用还有助于网络的差异处理，并且可以简化混音器、转换器和分组高速缓存中的处
理。
利用SSRC复用，原始和重传流需要单个会话。 这允许涉及大量并发会话的流服务器和中间件最
小化其端口使用。
该重传有效载荷格式允许会话复用和用于单播会话的SSRC复用。从实施的角度来看，这两种方法
之间几乎没有区别。因此，为了最大化互操作性，发送器和接收器应该支持两种多路复用方法。
对于多播会话，必须使用会话多路复用，因为如果SSRC多路复用与多播会话一起使用，原始流和
重传流的关联是有问题的（动机参见5.3节）。
4. 重传有效载荷格式
重传数据包的格式如下所示：
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP头使用情况如下：
在会话多路复用的情况下，必须将相同的SSRC值用于原始流和重传流。 在原始会话或重传会话中
发生SSRC冲突的情况下，RTP规范要求必须在发生冲突的会话中发送RTCP BYE数据包。 此外，
还必须在其自己的会话中为相关流发送RTCP BYE数据包。 获得新的SSRC标识符后，两个流的
SSRC必须设置为该值。
在SSRC复用的情况下，必须根据RTP的要求将两个不同的SSRC值用于原始流和重传流。如果检测到
原始流或重传流的SSRC冲突，则RTP规范要求必须为该流发送RTCP BYE分组。不得为关联的流发
送RTCP BYE数据包。因此，只有经历过SSRC冲突的流必须选择新的SSRC值。有关接收器上原始流
和重传流SSRC关联的含义，请参阅第5.3节。
Rey, et al. Standards Track [Page 5]
RFC 4588 RTP Retransmission Payload Format July 2006
对于任一复用方案，序列号具有标准定义; 即，它必须比重发流中发送的在前一分组的序列号大一。
重传分组时间戳必须设置为原始时间戳，即原始分组的时间戳。结果，重传流的第一个分组的初始
RTP时间戳不是随机的，而是等于重传的第一个分组的原始时间戳。有关安全隐患，请参阅本文档中
的“安全注意事项”部分。
实施者必须意识到重传流的RTCP抖动值不能反映实际的网络抖动，因为重传数据包的时间与其原始
时间戳之间几乎没有相关性。
有效负载类型是动态的。如果在原始流中存在使用重传的多个有效载荷类型，则对于这些中的每一个，
必须将动态有效载荷类型映射到重传有效载荷格式。有关如何使用会话描述协议（SDP）完成原始和
重传有效负载类型之间的映射的规范，请参阅第8.1节。
由于重传分组时间戳携带原始媒体时间戳，重传有效载荷类型使用的时间戳时钟速率必须与相关原始
有效载荷类型使用的时间戳相同。因此，如果RTP流携带不同时钟速率的有效载荷类型，则相关重传
流也将是这种情况。注意，RTP流通常不携带不同时钟速率的有效载荷类型。
RTP重传分组的有效载荷包括重传有效载荷头部，后跟原始RTP分组的有效载荷。重传有效载荷报头
的长度是2个八位字节。该有效载荷头仅包含一个字段OSN（原始序列号），该字段必须设置为相关
原始RTP分组的序列号。原始RTP分组有效载荷（包括特定于原始有效载荷类型的任何可能的有效载
荷报头）必须紧接在重传有效载荷报头之后。
对于支持多速率编码的有效载荷格式，发送方可以重传以较低速率编码的相同数据，而不是重发与原
始RTP分组相同的有效载荷。这旨在限制重传流的带宽使用。当这样做时，发送方必须确保接收方仍
然能够解码已经发送的原始分组的有效载荷，该原始分组可能已经基于丢失的原始分组的有效载荷进
行了编码。另外，如果发送方选择以较低的速率重新发送，则原始RTP分组的有效载荷报头中的值可
能不再适用于重发分组，并且可能需要在重发分组中修改以反映速率的变化。发送方应该将带宽使用
量的减少与因以较低速率重新发送而引起的质量下降进行权衡。
如果原始RTP报头携带任何特定于配置文件的扩展，则重传数据包应该包括紧跟在固定RTP报头之后的
相同扩展，正如在此配置文件下运行的应用程序所期望的那样。在这种情况下，重传有效载荷头必须
放在特定于配置文件的扩展之后。
如果原始RTP报头携带RTP报头扩展，则重传分组应该携带相同的报头扩展。此标头扩展必须紧跟在
固定RTP标头之后，如RTP [3]中所指定。在这种情况下，重传有效载荷头必须放在头扩展之后。
如果原始RTP数据包包含RTP位填充，则必须在构造重传数据包之前删除该填充。如果需要填充重传
分组，则必须像其他RTP分组一样执行位填充，并且必须设置填充位。
标记位（M），CSRC计数（CC）和原始RTP报头的CSRC列表必须“原样”复制到重发分组的RTP报头中。
5. 重传流与原始流的关联
5.1. 重传会话共享
在会话复用的情况下，重传会话必须映射到恰好一个原始会话; 即，相同的重传会话不能用于不同
的原始会话。
Rey, et al. Standards Track [Page 6]
RFC 4588 RTP Retransmission Payload Format July 2006
如果允许重传会话共享，则对于接收者来说这将是一个问题，因为他们将接收他们可能未加入的原始
会话的重传。例如，如果音频和视频会话共享相同的重传会话，则希望仅接收音频的接收器也将接收
重传的视频分组。
5.2. CNAME使用
在会话多路复用和SSRC多路复用情况下，发送方必须对原始流及其关联的重传流使用相同的
RTCP CNAME [3]。
5.3. 接收端关联
接收多个原始流和重传流的接收端需要将每个重传流与其原始流相关联。根据是使用会话复用还是
SSRC复用，以不同方式完成关联。
如果使用会话复用，则接收器将两个会话中具有相同SSRC的两个流相关联。注意，有效载荷类型字段
不能用于执行关联，因为若干媒体流可能具有相同的有效载荷类型值。这两个会话本身是带外关联的。
有关如何使用SDP完成两个会话的分组，请参阅第8节。
如果使用SSRC复用，接收器首先应该在会话中寻找具有相同CNAME的两个流。在某些情况下，CNAME
可能不足以确定关联，因为同一会话中的多个原始流可能共享相同的CNAME。例如，在同一视频会话
中可以存在映射到不同SSRC并且仍然使用相同CNAME并且可能使用相同有效载荷类型（PT）值的多个
视频流。这些流中的每个（或一些）可以具有关联的重传流。
在这种情况下，为了找出具有相同CNAME的原始流和重传流之间的关联，接收器应该表现如下。
当接收端接收到与之前发送的重传请求匹配的重传分组时，通常可以解决该关联。在接收到先前已经
请求了其原始序列号的重发分组时，接收端可以推导出重发分组的SSRC与之前发送请求分组的发送端
SSRC相关联。
但是，如果在会话的两个不同原始流中存在两个针对相同分组序列号的未完成请求，则该机制可能会失
败。注意，由于初始分组序列号是随机的，因此对相同分组序列号具有两个未完成请求的概率将非常小。
然而，为了避免单播情况下的模糊性，接收器在解决关联之前不得对两个不同原始流中的相同分组序列
号有两个未完成的请求。在多播中，不能完全避免这种模糊性，因为另一个接收器可能已经从另一个流
请求了相同的序列号。因此，SSRC复用绝不能用于多播会话。
如果接收方发现两个发送方正在使用相同的SSRC或接收到RTCP BYE数据包，它必须停止请求该SSRC
的重传。在接收到具有新SSRC的原始RTP分组时，接收器必须再次执行SSRC关联，如本节所述。
6. 将扩展RTP配置用于基于RTCP的反馈
本节给出了此有效载荷格式与基于RTCP的反馈的扩展RTP配置（表示为AVPF [1]）一起使用的
一般提示。请注意，除了AVPF配置引入的更改之外，RTP中指定的一般RTCP发送和接收规则，
以及RTCP数据包格式均适用。简而言之，AVPF配置文件放宽了RTCP时序规则，并指定了额外的
通用RTCP反馈消息。有关详细信息，请参见[1]。
6.1. 发送端的RTCP
在会话复用的情况下，根据RTP的规则，原始流的发送者报告（SR）分组在原始会话中发送，重
传流的SR分组在重传会话中发送。
Rey, et al. Standards Track [Page 7]
RFC 4588 RTP Retransmission Payload Format July 2006
在SSRC复用的情况下，根据RTP的规则，原始流和重传流的SR分组在同一会话中发送。就RTCP带
宽计算而言，原始流和重传流被看作属于相同RTP会话的独立发送者，因此均等地共享分配给发送
者的RTCP带宽。
请注意，在两种情况下，会话复用和SSRC复用，如RTP中指定的那样，必须为的两个流都发送BYE
分组。换句话说，仅为原始流发送BYE分组是不够的。
6.2. RTCP接收端报告
在会话多路复用的情况下，接收端将在属于单独的RTP会话的单独的接收端报告（RR）分组中发送
原始流和重传流的报告分组。在原始流上报告的RR分组在原始RTP会话中发送，而在重发流上报告
的RR分组在重传会话中发送。可以独立地选择这两个会话的RTCP带宽（例如，通过RTCP带宽修改
器[4]）。
在SSRC复用的情况下，接收端在同一RR分组中发送原始流和重传流的报告，因为只存在单个会话。
6.3. 重传请求
AVPF配置文件中定义的NACK反馈消息格式应该被接收器用来发送重传请求。接收器是否选择请
求分组是一个实现问题。实际的接收器实现应考虑诸如可容忍的应用延迟，网络环境和媒体类型
之类的因素。
接收方通常应评估重传的数据包在接收时是否仍然有用。可以根据由原始流中的丢失分组引起的
序列号间隙之前和/或之后的分组的时间戳来估计丢失分组的时间戳。在大多数情况下，对时间
戳的某种形式的线性估计已足够好。
此外，接收方应计算到发送方的往返时间（RTT）的估计。例如，这可以通过测量重传延迟，即
在为该分组发送NACK之后多久接收到重传分组来完成。该估计也可以从过去的观察中，例如
RTCP报告往返时间（如果可用），或任何其他手段获得。 接收方估计RTT的标准机制在“RTP控
制协议扩展报告（RTCP XR）”[11]中规定。
接收端不应该一检测到丢失的序列号就发送重传请求，而应该添加一些额外的延迟来补偿分组重
新排序耗费的时间。例如，该额外延迟可以基于过去对已经历的分组重新排序的观察。应当注意，
在分组重新排序很少或不发生的环境中，例如，如果基础数据链路层提供有序传送，则延迟可能
非常低或者甚至为零。在这种情况下，适当的“重新排序延迟”算法实际上可能不是基于定时器的，
而是基于分组的。例如，如果在检测到间隙之后接收到n个分组，则可以假设分组确实丢失而不是
乱序。与基于定时器的机制相反，在某些平台上作为非常短的固定FIFO分组缓冲器进行编码可能
更容易。
为了增加对NACK或重传分组的丢失的鲁棒性，接收器可以为相同的分组发送新的NACK。这被称
为多次重传。在为丢失的分组发送新的NACK之前，接收器应该依赖于定时器以合理地确定先前的
重传尝试已经失败并且因此避免不必要的重传。定时器值应基于观察到的往返时间。可以使用静
态或自适应值。例如，自适应定时器可以是随着对同一分组的每个新请求而改变其值的定时器。
本文档未提供有关如何计算此自适应值的指导，原因是因为尚未为如何找出它进行任何实验。
必须仅为原始RTP流发送NACK。否则，如果接收器想要通过在重传流中发送NACK来执行多次重传，
则它将不能知道其请求的分组的原始序列号和时间戳估计。
附录A给出了如何控制重传次数的一些指导。
Rey, et al. Standards Track [Page 8]
RFC 4588 RTP Retransmission Payload Format July 2006
6.4. 时间规则
根据AVPF [1]，NACK反馈消息可以在常规的完整复合RTCP分组或早期RTCP分组中发送。在早期
数据包中发送NACK可以更快地对给定的数据包丢失做出反应。然而，在这种情况下，如果在发送
早期RTCP分组之后立即发生新的分组丢失，则接收器将必须在早期分组之后等待下一个常规RTCP
复合分组。仅在常规RTCP复合分组中发送NACK会减少检测到原始数据包丢失与能够为该数据包发
送NACK之间的最大延迟。实现者应该为使用的应用程序考虑这个因素的可能影响。
此外，接收端可以利用常规RTCP复合分组之间的最小间隔。该间隔可用于将常规接收端报告降至
最小，同时仍允许接收端在需要更频繁反馈的时段期间发送早期RTCP分组，例如，发生更高分组
丢失率期间。请注意，虽然RTCP数据包可以因为不包含NACK而被抑制，但是需要提供与如果发送
时相同的RTCP带宽。有关如何使用最小间隔的详细信息，请参阅AVPF [1]。
7. 拥塞控制
RTP重传会增加网络拥塞的风险。在尽力而为的环境中，分组丢失是由拥塞引起的。在不降低原始
流的码率的情况下，通过重传旧数据来对丢失作出反应将进一步增加拥塞。实施应该遵循以下建议，
以便使用重传。
使用重传方案的RTP配置文件定义了不同环境中的恰当拥塞控制机制。遵循配置文件下的规则，
RTP应用程序可以确定其可接受的比特率和数据包速率，以对其他TCP或RTP流公平。
如果RTP应用程序使用重传，则可接受的分组速率和比特率包括原始数据和重传数据。这保证了
使用重传的应用程序实现了与不重传的应用程序相同的公平性。这样的规则在实践中会转化为以
下行动：
如果使用增强型服务，则应确保总比特率和数据包速率不超过所请求服务的比特率和数据包速率。
应进一步监测所请求的服务是否实际交付。在尽力而为的环境中，发送方不应该在不降低原始流
的分组速率和比特率的情况下发送重传分组（例如，通过以较低的速率编码数据）。
另外，发送方可以选择性地仅重传它认为重要的分组，并忽略其他分组的NACK消息以限制比特率。
这些拥塞控制机制应将丢包率保持在可接受的参数范围内。在拥塞控制的情况下，如果跨越相同
网络路径并且经历相同网络条件的TCP流将在合理的时间尺度上实现不小于RTP流所达到的平均吞
吐量，则认为分组丢失是可接受的。如果没有控制拥塞，那么不应该使用重传。
在某些情况下仍可以发送重传，例如，在数据包丢失不是由拥塞引起的无线链路中，如果服务器
（或发出重传请求的客户端）评估特定数据包或帧对于继续播放很重要， 或者假如已发出RTSP
PAUSE以允许填充缓冲区（RTSP PAUSE不影响重传分组的发送）。
最后，可能还需要调整传输速率（或订阅分层多播会话的层数），或者安排接收方离开会话。
8. 重传有效载荷格式的MIME类型注册
8.1. 介绍
本文档中引入了以下MIME子类型名称和参数：“rtx”，“rtx-time”和“apt”。
用rtpmap属性指示重传流到有效载荷类型值的绑定。绑定中使用的MIME子类型名称是“rtx”。
Rey, et al. Standards Track [Page 9]
RFC 4588 RTP Retransmission Payload Format July 2006
必须使用“apt”（关联的有效载荷类型）参数将重传有效载荷类型映射到关联的原始流有效载荷
类型。如果使用多个原始有效载荷类型，则必须包括多个“apt”参数以将每个原始有效载荷类型
映射到不同的重传有效载荷类型。
可选的有效载荷格式特定参数“rtx-time”表示发送方将其原始RTP分组保留在其可用于重传的
缓冲区中的最大时间。此时间从数据包的第一次传输开始计算。
语法如下：
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
其中
<number>: 表示在rtpmap属性中分配给重传有效载荷格式的动态有效载荷类型编号。
<apt-value>: 是与此重新传输流有效负载类型关联的原始流有效负载类型的值。
<rtx-time-val>: 指定发送方将RTP数据包保留在其可用于重新传输的缓冲区中的以毫秒
为单位的时间（从数据包首次发送的时间开始计算）。缺少重传流的rtx-time参数意味着
没有定义最大重传时间，但可以通过其他方式协商。
8.2. 注册audio/rtx
MIME type: audio
MIME subtype: rtx
必需参数：
rate: RTP时间戳时钟速率，等于重传媒体的RTP时间戳时钟速率。
apt: 关联的有效载荷类型。此参数的值是关联的原始流的有效载荷类型。
可选参数：
rtx-time: 表示发送方将RTP数据包保留在可用于重新传输的缓冲区中的以毫秒为单位的
时间（以数据包首次发送的时间为单位）。
编码注意事项：此类型仅定义为通过RTP传输。
安全注意事项：请参阅RFC 4588的第12节
互操作性考虑因素：无
发布规范：RFC 4588
使用此媒体类型的应用程序：多媒体流应用程序
附加信息：无
Rey, et al. Standards Track [Page 10]
RFC 4588 RTP Retransmission Payload Format July 2006
联系人和电子邮件地址以获取更多信息：
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
预期用途：COMMON
作者:
Jose Rey
David Leon
改变控制者:
IETF AVT WG delegated from the IESG
8.3. 注册video/rtx
MIME type: video
MIME subtype: rtx
必需参数：
rate: RTP时间戳时钟速率，等于重传媒体的RTP时间戳时钟速率。
apt: 关联的有效载荷类型。此参数的值是关联的原始流的有效载荷类型。
可选参数：
rtx-time: 表示发送方将RTP数据包保留在可用于重新传输的缓冲区中的以毫秒为单位的
时间（以数据包首次发送的时间为单位）。
编码注意事项：此类型仅定义为通过RTP传输。
安全注意事项：请参阅RFC 4588的第12节
互操作性考虑因素：无
发布规范：RFC 4588
使用此媒体类型的应用程序：多媒体流应用程序
附加信息：无
联系人和电子邮件地址以获取更多信息：
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
预期用途：COMMON
Rey, et al. Standards Track [Page 11]
RFC 4588 RTP Retransmission Payload Format July 2006
作者:
Jose Rey
David Leon
改变控制者:
IETF AVT WG delegated from the IESG
8.4. 注册text/rtx
MIME type: text
MIME subtype: rtx
必需参数：
rate: RTP时间戳时钟速率，等于重传媒体的RTP时间戳时钟速率。
apt: 关联的有效载荷类型。此参数的值是关联的原始流的有效载荷类型。
可选参数：
rtx-time: 表示发送方将RTP数据包保留在可用于重新传输的缓冲区中的以毫秒为单位的
时间（以数据包首次发送的时间为单位）。
编码注意事项：此类型仅定义为通过RTP传输。
安全注意事项：请参阅RFC 4588的第12节
互操作性考虑因素：无
发布规范：RFC 4588
使用此媒体类型的应用程序：多媒体流应用程序
附加信息：无
联系人和电子邮件地址以获取更多信息：
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
预期用途：COMMON
作者:
Jose Rey
David Leon
改变控制者:
IETF AVT WG delegated from the IESG
Rey, et al. Standards Track [Page 12]
RFC 4588 RTP Retransmission Payload Format July 2006
8.5. 注册application/rtx
MIME type: application
MIME subtype: rtx
必需参数：
rate: RTP时间戳时钟速率，等于重传媒体的RTP时间戳时钟速率。
apt: 关联的有效载荷类型。此参数的值是关联的原始流的有效载荷类型。
可选参数：
rtx-time: 表示发送方将RTP数据包保留在可用于重新传输的缓冲区中的以毫秒为单位的
时间（以数据包首次发送的时间为单位）。
编码注意事项：此类型仅定义为通过RTP传输。
安全注意事项：请参阅RFC 4588的第12节
互操作性考虑因素：无
发布规范：RFC 4588
使用此媒体类型的应用程序：多媒体流应用程序
附加信息：无
联系人和电子邮件地址以获取更多信息：
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
预期用途：COMMON
作者:
Jose Rey
David Leon
改变控制者:
IETF AVT WG delegated from the IESG
Rey, et al. Standards Track [Page 13]
RFC 4588 RTP Retransmission Payload Format July 2006
8.6. 映射到SDP
MIME媒体类型规范中携带的信息具有SDP [5]中字段的特定映射，SDP [5]通常用于描述RTP
会话。当SDP用于指定RTP流的重传时，映射完成如下：
- MIME类型（“video”），（“audio”），（“text”）和（“application”）在SDP“m=”
中作为媒体名称。
- MIME子类型（“rtx”）在SDP“a=rtpmap”中作为编码名称。“a=rtpmap”中的RTP时钟速率
必须是重传有效载荷类型的时钟速率。有关详细信息，请参阅第4节。
- AVPF特定于配置文件的参数“ack”和“nack”在SDP中表示为“a = rtcp-fb”。几个SDP
“a=rtcp-fb”用于几种类型的反馈。详细信息请参阅AVPF配置文件[1]。
- 重传有效载荷格式特定参数“apt”和“rtx-time”在SDP“a=fmtp”中作为以分号分隔的
parameter=value列表。
- 任何剩余参数都在SDP的“a=fmtp”属性中，通过直接从MIME媒体类型字符串复制它们作为
以分号分隔的parameter=value列表。
在以下部分中，将介绍一些SDP描述示例。在这些示例中的一些示例中，折叠长行以满足本文档
的列宽约束; 行尾的反斜杠（“\”）和后面的回车应该被忽略。
8.7. 使用会话多路复用的SDP描述
在会话多路复用的情况下，SDP描述的每个RTP会话包含一个媒体规范“m”行。SDP必须使用RFC
3388 [6]中定义的流标识（FID）语义，提供原始和相关重传会话的“m”行的分组。
以下示例分别在端口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
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=01010000012000884006682C2090A21F
Rey, et al. Standards Track [Page 14]
RFC 4588 RTP Retransmission Payload Format July 2006
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
SDP描述的特殊情况是仅包含一个原始会话“m”行和一个重传会话“m”行的描述，如何分组显而易
见，在这种特殊情况下可以省略FID语法。
这在以下示例中做了演示，该示例是单个原始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=01010000012000884006682C2090A21F
m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
8.8. 使用SSRC多路复用的SDP描述
以下是使用SSRC复用的RTP视频会话的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=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
9. RTSP注意事项
实时流协议（RTSP）RFC 2326 [7]，是一种应用程序级协议，用于控制具有实时属性的数据
传输。本节介绍控制支持分组重传的RTP会话所涉及的问题。
9.1. 使用SSRC多路复用的RTSP控制
在SSRC复用的情况下，“m”行包括原始和重传有效载荷类型，并且具有单个RTSP“control”属
性。接收器使用“m”行来请求整个媒体会话的SETUP和TEARDOWN。传输头中包含的RTP配置文件
必须是AVPF配置文件或允许扩展反馈的其他合适的配置文件。如果SSRC值包含在SETUP响应的
传输头中，则它必须是原始流的值。
Rey, et al. Standards Track [Page 15]
RFC 4588 RTP Retransmission Payload Format July 2006
为了控制会话原始媒体流的发送，接收器像往常一样向发送者发送PLAY和PAUSE请求以进行会
话。用于在PLAY响应中设置RTP特定参数的RTP-info报头必须根据原始流的RTP信息进行设置。
当接收器开始接收原始流时，它可以通过RTCP NACK请求重传，而无需额外的RTSP信令。
9.2. 使用会话复用的RTSP控制
在会话多路复用的情况下，每个SDP“m”行具有RTSP“control”属性。因此，当使用重传时，
原始会话和重传都具有它们自己的“control”属性。接收方可以通过第8节中规定的FID语义将
原始会话和重传会话相关联。
原始和重传流通过它们各自的媒体“control”属性分别建立和拆除。传输头中包含的RTP配置
文件必须是AVPF配置文件或其他合适的允许原始会话和重传会话扩展反馈的配置文件。
RTSP演示应该支持聚合控制，并且应该包含会话级RTSP URL。接收方应该对原始会话及其相
关的重传会话使用聚合控制。否则，将需要两个不同的“session-id”值，即原始会话和重传
会话的不同值，并且发送者将不知道如何关联它们。
通常使用会话级“control”属性来控制原始流的播放。当接收器开始接收原始流时，它可以通
过RTCP请求重传，而无需额外的RTSP信令。
9.3. 重传流的RTSP控制
由于重传的性质，重传数据包的发送不应该通过RTSP PLAY和PAUSE请求来控制。PLAY和
PAUSE请求不应该影响重传流。无论状态如何，重传分组都根据接收器在原始RTCP流中请求时
发送。
9.4. 缓存控制
重传流不应该被缓存。
在会话多路复用的情况下，“Cache-Control”头应该为重传流设置为“no-cache”。
在SSRC多路复用的情况下，RTSP不能为重传流指定独立的缓存，因为SDP中只有单个“m”行。
因此，实现者在决定是否缓存SSRC多路复用会话时，应该考虑这个事实。
10. 实现范例
本文档仅规定了互操作性所必需的发送方和接收方行为。此外还规定了某些可以增强重传效率算
法，例如针对特定环境时的速率控制或缓冲管理。
本节概述了本规范中允许的不同实现选项。
第一个示例描述了最小接收器实现。通过该实现，如果需要，可以重传丢失的RTP分组，有效地
检测重传分组的丢失，并执行多次重传。 大多数必要的处理都是在服务器上完成的。
第二个示例显示了如何在（小）多播组中结合分层编码使用重传。它说明重传和分层编码在技术
上可以是互补的。
Rey, et al. Standards Track [Page 16]
RFC 4588 RTP Retransmission Payload Format July 2006
10.1. 最小接收器实现示例
本节给出了支持多次重传的实现示例。发送方使用MPEG-4视频RTP有效载荷格式在RTP分组中发
送原始数据。假设使用NACK反馈消息，如[1]所示。下面给出使用了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
特定于格式的参数“rtx-time”表示服务器将在重发缓冲区中缓冲发送的数据包3.0秒，之后数
据包将从重发缓冲区中删除，永远不会再次发送。
在该实现示例中，处理重传所需的RTP接收器处理被减到最小。接收器从接收到的序列号中观察
间隙检测分组的丢失。它通过AVPF配置文件[1]中定义的NACK向发送方通知丢失的分组。接收
器应考虑已通知的发送器重传缓冲区长度，以确定自己的接收缓冲区长度。它还应该从缓冲区长
度导出可以重新请求重传分组的最大次数。
发送方应选择性地重新发送数据包; 即，它应该根据分组重要性，观察到的服务质量（QoS）和
到接收器的网络连接的拥塞状态来选择是否重传所请求的分组。显然，发送器处理随着接收器的
数量而增加，因为必须为每个接收器分配状态信息和处理负载。
10.2. 多播中分层编码媒体的重传
本节介绍如何在多播会话中将重新传输与分层编码相结合。请注意，重传框架仅适用于小型多播
应用。请参阅RFC 2887 [10]查找有关在大组可靠多播应用中因反馈流量引起的NACK爆炸，严
重拥塞问题的讨论。
重要性不同的分组在不同的RTP会话中传送。对应于不同层的重传流本身可以被视为不同的重传
层。不同重传流的相对重要性应反映不同原始流的相对重要性。
根据本文档的第5.3节，在多播中不允许对原始流和重传流进行SSRC复用。因此，必须使用会话
复用，在不同的RTP会话中发送重传流。
下面给出了分层编码媒体的多播重传的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
Rey, et al. Standards Track [Page 17]
RFC 4588 RTP Retransmission Payload Format July 2006
服务器和接收器可以实现先前示例中所示的重传方法。此外，他们可以根据其所属的层选择请求
和重新传输丢失的数据包。
11. IANA 注意事项
已经为四种不同的媒体类型注册了新的MIME子类型名称“rtx”，如下所示：“video”，“audio”，
“text”和“application”。还定义了附加的REQUIRED参数“apt”和OPTIONAL参数“rtx-time”。
详见第8节。
12. 安全考虑因素
使用本规范中定义的有效载荷格式的RTP分组遵从RTP [3]第9节中讨论的通用安全考虑。
在常见的流传输方案中都希望实现消息认证、数据完整性、重播保护和机密性。
缺少身份验证可能会导致中途人为修改数据攻击和重播攻击，这对RTP分组重传非常有害。例如：
被篡改的RTCP分组可能触发不适当的重传，显著地减少分配给原始数据流的实际比特率份额，
被篡改的RTP重传分组可能导致客户端的解码器崩溃，并且篡改的重传请求可能使本文第5节中描
述的SSRC关联机制失效。另一方面，重播的分组可能导致错误的重新排序和RTT测量（重传请求
策略所需），并可能导致接收器缓冲区溢出。
此外，为了确保数据的机密性，需要加密原始有效载荷数据。实际上不需要加密2字节重传有效载
荷报头，因为它没有提供关于数据内容的任何提示。
此外，建议用于此有效载荷格式的加密机制提供针对已知明文攻击的保护。RTP建议初始RTP时间
戳应该是随机的，以保护流免受已知的明文攻击。此有效载荷格式不遵循此建议，因为初始时间戳
将是第一个重新传输分组的媒体时间戳。但是，由于原始流的初始时间戳本身是随机的，如果原始
流被加密，则第一个重新发送的分组时间戳对于攻击者也是随机的。因此，保密性不会受到损害。
如果使用加密技术在原始流上提供安全服务，则必须在重传流上提供具有相同加密强度的相同服务。
对重传的流和原始流使用相同的密钥可能导致安全问题，例如，两次性密钥。有关两次性密钥的含
义以及如何避免它们的讨论，请参阅安全实时传输协议（SRTP）[12]的第9.1节。
在撰写本文档时，SRTP不提供所提及的所有安全服务。 至少有两个原因：1）两次性密钥的出现，
和2）这种有效载荷格式通常在RTP/AVPF配置文件下工作而SRTP仅支持RTP/AVP的事实。SRTP
的改编版本将在未来解决这些缺点。
使用重传的拥塞控制考虑因素在本文件的第7节中讨论。
13. 致谢
我们要感谢Carsten Burmeister参与本文件的制定。我们还要感谢Koichi Hata，Colin
Perkins，Stephen Casner，Magnus Westerlund，Go Hori和Rahul Agarwal的有益评
论。
Rey, et al. Standards Track [Page 18]
RFC 4588 RTP Retransmission Payload Format July 2006
14. 参考
14.1. 规范性参考文献
[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.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[7] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
14.2. 信息参考文献
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[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.
[11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
Rey, et al. Standards Track [Page 19]
RFC 4588 RTP Retransmission Payload Format July 2006
附录A. 如何控制每个分组的重传次数
找出每个分组的重传次数（rtxs）以实现可能的最优传输是一项艰巨的任务。当然，最小值应为1;
否则请勿使用此有效负载格式。此外，截至本文发布之日，作者尚未发现任何用于获得最佳性能的
每分组重传次数的研究。为了帮助实施者和研究人员，本节描述了实现给定数量的重传所需的缓冲
时间的估计。计算完这段时间后，可以通过SDP参数“rtx-time”将其传送给客户端，如本文档中
所定义。
A.1. 情景和假设
* 具有宽松延迟界限的流式场景。客户端和服务器具有缓冲空间，如SDP中的参数“rtx-time”
所示。
* 使用的RTP AVPF配置的SSRC复用重传方案：一个SSRC用于原始分组，另一个SSRC用于重传
分组。
* 默认RTCP带宽份额用于SR和RR报告，即SR+RR=0.05。我们有发送端（2）和接收端（1）。
接收端和发送端同等地获得RTCP带宽份额的1/3，因为发送方的比例大于会话成员的1/4。
* avg-rtcp-size近似为120个字节 这是2个SR的舍入平均值，每个SSRC一个，包含
40/8/28/32个字节，用于带有CNAME的IPv6/UDP/SR/SDES，因此每个共105个字节;
对于IPv6/UDP/2*RR/SDES，具有40/8/64/32字节的RR，共157个字节。由于发送端和接收
端共享RTCP带宽，因此avg-rtcp-size=(157+105+105)/3=117.3~=120字节。这个值的
重要特征是它超过100个字节，这似乎是典型配置的代表性数字。
* 使用的配置文件是AVPF [1]，使用通用NACK请求重传。这让每个NACK增加了16个字节的开销，
每个附加的NACK反馈控制信息（FCI）字段并且增加了4个字节的开销。
* 我们假设一种最坏情况，其中每个分组在被接收之前耗尽其对应的可用重传次数N。这意味着
如果请求分组重传最多2次，则相应的请求该特定分组的通用NACK报告请求 在两个连续的
RTCP复合包中发送。同样地，如果要求重传10次，则通用NACK被发送10次。该假设使得
RTCP分组大小在N*RTCP间隔（秒）之后大致恒定，即，对于
avg-rtcp-size=120+(receiver-RTCP-bw-share)*(12 + 4*N)。在我们的例子中，
接收器RTCP带宽份额是1/3，因此，avg-rtcp-size = 124 + 4*N/3。
* 两个延迟参数难以近似，并且可能依赖于实现。因此，我们在此明确列出它们而不为它们分配
特定值：一个是丢包检测时间（T2），另一个是反馈处理和重传排队时间（T5）。实施者应
为这两个参数分配适当的值。
Rey, et al. Standards Track [Page 20]
RFC 4588 RTP Retransmission Payload Format July 2006
从图形上看，我们有以下内容：
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
说明：
=======
DL: 下行链路（发送端->接收端）
UL: 上行链路（接收端->发送端）
时间单位是秒，s。
比特率单位是位每秒，bps。
下行链路传输时间: T1 = physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
丢包检测时间: T2 = pkt-loss-detect-time
报告丢包时间: T3 = time-to-next-rtcp-report
上行链路传输时间: T4 = physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter
重传处理时间: T5 = feedback-processing-time + rtx-queuing-time
A.2. 目标
为了得到缓冲时间T()的估计值，流服务器使用该值 为每个分组启用给定数量的重传N。如果假
设客户端在T1秒后开始缓冲，则该时间在服务器和客户端大致相等。
A.3. 解决方案
首先，我们找到1次重传的估计值，
T(1)=T:
T = T1 + T2 + T3 + T4 + T5
Rey, et al. Standards Track [Page 21]
RFC 4588 RTP Retransmission Payload Format July 2006
因为 T1 + T4 ~= RTT,
T = RTT + T2 + T3 + T5
T3的最坏情况是我们假设报告必须等待整个RTCP间隔并且应用最大随机因子1.5。因此，在采取
后续补偿以避免突发流量后（参见RTP [3]的附录A.7），我们得到
T3 = 1.5 / 1.21828 * RTCP-Interval。从而，
T = RTT + 1.2312*RTCP-Interval + T2 + T5
另一方面，RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS)。
在这种情况下：sender + receivers = 3; RR + RS是接收方报告加上发送方报告带宽份额，
在这种情况下，等于默认会话带宽bw的5％。 我们假设平均RTCP数据包大小，
avg-rtcp-size = 120字节。 从而，一次重传的时间为：
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
为了启用N次重传，流服务器或客户端中的可用缓冲时间大约为：
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
如上所述，
avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N)
= 120 + (1/3)*(12 + 4*N)
= 124 + 4*N/3.
Rey, et al. Standards Track [Page 22]
RFC 4588 RTP Retransmission Payload Format July 2006
A.4. Numbers
如果我们忽略T2和T5的影响，即假设立即检测到所有丢失，并且由于反馈处理或重传排队没有
额外的延迟，我们对于不同的N值有以下缓冲时间：
RTCP w/ several Generic NACKs; variable packet size = 124 + 4*N/3
bytes
|============|=====|======================================|
| 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,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
Rey, et al. Standards Track [Page 23]
RFC 4588 RTP Retransmission Payload Format July 2006
为了量化不考虑Generic NACKS的错误，我们可以用相同的数值，但忽略Generic NACK的
影响，avg-rtcp-size~ = 120字节。正如我们从下面看到的，对于较低的带宽值和较高的
重传次数场景，这可能导致1-1.5秒（5-10％）的缓冲区估计误差。在该场景下影响并不大。
不管怎么说，应针对特定情况仔细评估，这就是公式包含它的原因。
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
|============|=====|======================================|
| 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,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
Rey, et al. Standards Track [Page 24]
RFC 4588 RTP Retransmission Payload Format July 2006
Authors' Addresses
Jose Rey
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-134
Fax: +49-6103-766-166
EMail: jose.rey@eu.panasonic.com
David Leon
Consultant
EMail: davidleon123@yahoo.com
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
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
Phone: 1-972-374-1861
EMail: viktor.varsa@nokia.com
Rolf Hakenberg
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: rolf.hakenberg@eu.panasonic.com
Rey, et al. Standards Track [Page 25]
RFC 4588 RTP Retransmission Payload Format July 2006
完整的版权声明
版权所有（C）互联网协会（2006年）。
本文件受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.
知识产权
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.
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.
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.
致谢
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rey, et al. Standards Track [Page 26]
RFC 4588 RTP Retransmission Payload Format July 2006
