RTP：实时应用程序的传输协议
这份备忘录的状态
本文件规定了一个Internet标准跟踪协议
互联网社区，请求讨论和建议
改进。请参阅当前版本的“Internet”
官方协议标准“（STD 1）的标准化状态
和这个协议的状态。这份备忘录的分发是无限的。
版权声明
版权所有（C）互联网协会（2003）。版权所有。
抽象
这个备忘录描述了实时传输协议RTP。RTP
提供适合的端到端网络传输功能
应用程序传输实时数据，如音频，视频或
模拟数据，通过多播或单播网络服务。RTP
不解决资源保留，不保证
实时服务的服务质量。数据传输是
由控制协议（RTCP）增强以允许监视
以可扩展到大型多播网络的方式进行数据传送，
提供最小的控制和识别功能。RTP和
RTCP被设计成独立于底层传输和
网络层。该协议支持使用RTP级别
和各种级别的混合翻译。
大多数在这个备忘录的文本是相同的RFC 1889，它
淘汰了。线路上的数据包格式没有变化，
只改变了管理协议的规则和算法
用来。最大的变化是对可扩展定时器的增强
计算何时发送RTCP数据包的算法
尽量减少超过预期速率的传输
参与者同时加入会议。
Schulzrinne等人 标准跟踪[页1]
RFC 3550 RTP 2003年7月
目录
1。简介................................................ 4
1.1 术语............................................ 5
2。RTP使用场景.................................................. 5
2.1 简单组播音频会议.................................. 6
2.2 音视频会议.................... ......... 7
2.3 混音器和翻译器................................. 7
2.4 分层编码...................................... 8
3。定义................................................. 8
4。字节顺序，对齐方式和时间格式...................... 12
5。RTP数据传输协议.................................... 13
5.1 RTP固定标题字段...... ........................... 13
5.2 复用RTP会话................... ........... 16
5.3 对RTP头的特定文件修改............ 18
5.3.1 RTP头扩展............... ............. 18
6。RTP控制协议 - RTCP .................................. 19
6.1 RTCP数据包格式....... .............................. 21
6.2 RTCP传输间隔............................. 24
6.2.1 维护会话成员的人数....... 28
6.3 RTCP数据包发送和接收规则............................................................ 28
6.3.1 计算RTCP发送间隔.............................. 29
6.3.2 初始化.................................. 30
6.3.3 接收RTP或非BYE RTCP数据包... ...... 31
6.3.4 接收RTCP BYE包................................... 31
6.3.5 SSRC定时....... ....................... 32
6.3.6 发送定时器到期.................................. 32
6.3.7 发送BYE包...................... 。 33
6.3.8 更新we_sent ................................ 34
6.3.9 分配源说明带宽的.. ... 34
6.4 发送者和接收者报告........................... 35
6.4.1 SR：发送者报告RTCP分组.. ................. 36
6.4.2 RR：接收报告RTCP包.................................. 42
6.4.3 扩展发送者和接收者报告....... 42
6.4.4 分析发送者和接收者报告............ 43
6.5 SDES：源描述RTCP数据包................ 45
6.5.1 CNAME：规范的终点标识符SDES项目。46
6.5.2 名称：用户名称SDES项目........................................ 48
6.5.3 电子邮件：电子邮件地址SDES项目....... 。 48
6.5.4 电话：手机号码SDES项目................... 49
6.5.5 LOC：地理用户位置SDES项目......... 49
6.5.6 工具：应用程序或工具名称SDES项目........................................ 49
6.5.7 注意：通知/状态SDES项目................... 50
6.5.8 PRIV：专用扩展SDES项目........................................ 50
6.6 BYE：再见RTCP数据包................... ............ 51
6.7 APP：应用程序定义的RTCP数据包................... 52
7。RTP翻译器和混音器.................................. 53
7.1 概述........ ........................... 53
Schulzrinne等人 标准跟踪[第2页]
RFC 3550 RTP 2003年7月
7.2 翻译 器中的RTCP处理............................................................ 55
7.3混音器中的RTCP处理.................................... ................ 57
7.4 级联搅拌器.............................. .......... 58
8。SSRC标识符的分配和使用........................... 59
8.1 碰撞概率.............. .................................... 59
8.2 碰撞分辨率和回路检测................................... 60
8.3 使用分层编码.... ......................... 64
9。安全................................................. ... 65
9.1 保密........................................ 65
9.2 身份验证和消息完整性... ................ 67
10。拥塞控制.......................................... 67
11。网络和传输协议上的RTP .................... 68
12。协议常量摘要.............................. 69
12.1 RTCP包类型.......... ............................ 70
12.2 SDES类型.................. ........................... 70
13。RTP配置文件和有效负载格式规范.................................... 71
14。安全考虑.................................................. 73
15。IANA考虑............................................. 73
16。知识产权声明.............................. 74
17。致谢............................................. 74
附录A。算法........................................ 75
附录A.1 RTP数据头有效性检查.................. 78
附录A.2 RTCP报头有效性检查..................... .. 82
附录A.3 预期和失落......包容量的确定 83
附录A.4 生成RTCP SDES数据包................................................ 84
附录A.5 解析RTCP SDES数据包......... .............. 85
附录A.6 生成随机的32位标识符............. 85
附录A.7 计算的RTCP发送间隔。 ......... 87
附录A.8 估算间隔抖动................ 94
附录B。RFC 1889的变化............................. 95
参考文献............... ....................................... 100
规范性引用........ ....................................100
信息性参考.......................................... 100
作者的地址。 ............................................. 103
完整的版权声明。 ....................................... 104
Schulzrinne等人 标准跟踪[第3页]
RFC 3550 RTP 2003年7月
。
本备忘录规定了实时传输协议（RTP），
为实时数据提供端到端的交付服务
特点，如交互式音频和视频。那些服务
包括有效载荷类型标识，顺序编号，时间戳
和交付监控。应用程序通常在其上运行RTP
UDP来利用其复用和校验和服务; 都
协议提供了传输协议功能的一部分。
但是，RTP可以与其他合适的底层网络一起使用
运输协议（见第11节）。RTP支持数据传输
多个目的地使用多播分发，如果提供的
底层网络。
请注意，RTP本身不提供任何机制来确保及时
交付或提供其他服务质量保证，但依赖
在较低层的服务上这样做。它不保证交付或
防止无序交付，也不假定其基础
网络是可靠的，并按顺序发送数据包。序列
包含在RTP中的号码允许接收机重建
发送者的数据包序列，但是也可以使用序列号
确定数据包的正确位置，例如在视频中
解码，而不必按顺序解码分组。
虽然RTP主要是为了满足多用户的需求而设计的，
参与者多媒体会议，但不限于此
特定的应用。连续数据存储，交互式
分布式仿真，主动式徽章以及控制和测量
应用程序也可能会发现RTP适用。
本文件定义了RTP，由两个紧密相连的部分组成：
o实时传输协议（RTP），用于传输具有的数据
实时属性。
o RTP控制协议（RTCP），监视服务质量
并在进行中传达有关参与者的信息
会话。RTCP的后一方面可能足以“松散”
控制“会议，即没有明确的成员资格
控制和设置，但不一定打算支持
所有的应用程序的控制通信要求。这个
功能可能完全或部分归入单独的
会话控制协议，这是超出了这个范围
文件。
RTP代表遵循原则的新型协议
提出了应用级构架和集成层处理
Clark和Tennenhouse [ 10 ]。也就是说，RTP旨在具有延展性
Schulzrinne等人 标准跟踪[第4页]
RFC 3550 RTP 2003年7月
提供特定应用程序所需的信息
通常会被整合到应用程序处理中而不是
作为一个单独的层实现。RTP是一个协议框架
这是故意不完整的。这个文件指定了那些
预期在所有的应用程序中都有相同的功能
RTP将是适当的。不同于传统的协议
通过制定协议可能会提供更多的功能
更一般的还是通过增加一个需要的选择机制
解析，RTP旨在通过修改和/或定制
根据需要添加标题。示例在章节中给出
5.3和6.4.3。
所以除了这个文件外，还有一个完整的规范
对于特定应用程序的RTP将需要一个或多个同伴
文件（见第13节）：
o配置文件规范文件，它定义了一组有效载荷
类型代码及其到有效载荷格式的映射（例如，媒体
编码）。配置文件也可以定义扩展或修改
到特定于特定类别的应用程序的RTP。
通常一个应用程序只能在一个配置文件下运行 一个
音频和视频数据的配置文件可以在RFC
3551中找到 [ 1 ]。
o有效载荷格式规范文件，它定义了一个
特定的有效载荷，例如音频或视频编码将是
在RTP中进行。
为他们的实时服务和算法的讨论
实施以及一些RTP的背景讨论
设计决策可以在[ 11 ]中找到。
术语
关键词“必须”，“不得”，“需要”，“应该”，“不应该”，
“应该”，“不应该”，“推荐”，“可能”和“可选”
文件要按照BCP 14，RFC 2119 [ 2 ]
并指出符合RTP实施的要求级别。
。
以下部分描述了RTP使用的一些方面。该
例子被选来说明的基本操作
使用RTP的应用程序，而不是限制可能使用的RTP。在
这些例子，RTP是在IP和UDP之上进行的，并遵循
由指定的音频和视频配置文件建立的约定
在伴侣RFC 3551中。
Schulzrinne等人 标准跟踪[第5页]
RFC 3550 RTP 2003年7月
简单的多播音频会议
IETF的一个工作组开会讨论最新的协议
文件，使用互联网的IP多播服务进行语音
通信。通过一些分配机制的工作组
主席获得一个组播组地址和一对端口。一个端口
用于音频数据，另一个用于控制（RTCP）
数据包。这个地址和端口信息被分配给
有意参加者。如果需要隐私，数据和控制在这种情况下，
数据包可以按9.1节的规定进行加密
还必须生成和分发加密密钥。最正确
这些分配和分配机制的细节已经超出了
RTP的范围。
每个会议使用的音频会议应用程序
参与者以例如20ms持续时间的小块发送音频数据。
每个音频数据块之前都有一个RTP头，RTP头和
数据又被包含在UDP数据包中。RTP头部表示
包含什么类型的音频编码（如PCM，ADPCM或LPC）
在每个数据包中，以便发件人可以在一个过程中更改编码
会议，例如，以适应新的参与者
通过一个低带宽的链路连接或反应的指示
网络拥塞。
像其他分组网络一样，互联网偶尔也会失去
重新排序数据包并将其延迟不同的时间。至
应付这些损伤，RTP头包含时间
信息和允许接收者的序列号
重建来源所产生的时间，以便在此
例如，大量的音频是连续播放的扬声器
每20毫秒。这个时间重建是分开进行的
会议中每个RTP数据包的来源。序列号
也可以被接收器用来估计有多少分组
正在失去。
由于工作组成员在加入和离开期间
会议，知道谁在任何时候参与是有用的
以及他们如何收到音频数据。为了这个目的，
会议中音频应用程序的每个实例周期性地
在RTCP上多播一个接收报告加上它的用户名
（控制）端口。接待报告显示目前情况如何
扬声器正在被接收，并可能被用来控制自适应
编码。除了用户名，其他标识
信息也可能被包括在控制带宽限制之内。
站点在离开时发送RTCP BYE数据包（第6.6节）
会议。
Schulzrinne等人 标准跟踪[第6页]
RFC 3550 RTP 2003年7月
音频和视频会议
如果音频和视频媒体在会议中使用，则是
作为单独的RTP会话传输。就是说，单独的RTP和RTCP
使用两个不同的UDP端口为每个介质传输数据包
配对和/或多播地址。在这里没有直接的联结
音频和视频会话之间的RTP级别，除了用户
参加这两个会议应该使用相同的区分
（canonical）名称在RTCP数据包中，以便进行会话
可以关联。
这种分离的一个动机是允许一些参与者
会议只收到一个媒体，如果他们选择。进一步第5.2节
给出了解释。尽管分离，
可以实现源音视频的同步播放
使用RTCP分组中携带的定时信息
会话。
混音器和翻译器
到目前为止，我们已经假设所有网站都希望接收媒体数据
相同的格式。但是，这可能并不总是适当的。
考虑一个地区的参与者连接的情况
通过低速链接到大部分会议
享受高速网络接入的参与者。而不是强迫
每个人都使用较低带宽，质量较差的音频编码
称为混频器的RTP级别的中继器可以放置在低带宽附近
区。该混音器将传入的音频数据包重新同步到
重构发送器产生的恒定的20ms间隔，混合
这些重建的音频流成一个单一的流，翻译
将音频编码转换为较低带宽的音频，
通过低速链路的带宽分组流。这些包
可能是单播到单个接收者或多播在不同的
地址给多个收件人。RTP头包含一个方法
混合器来识别造成混合数据包的来源
可以在接收机处提供正确的讲话者指示。
音频会议中的一些预期参与者可能是
连接高带宽的链接，但可能不会直接
通过IP组播可达 例如，他们可能在一个后面
应用程序级防火墙不会让任何IP数据包通过。
对于这些网站，混合可能不是必要的，在这种情况下，另一个
可以使用称为翻译器的RTP级中继类型。二
翻译器安装在防火墙的两侧，一个
外部的一个通过a接收所有组播包
安全地连接到防火墙内的翻译器。该
防火墙内部的转换器将以组播数据包的形式再次发送
到一个限于该站点内部网络的多播组。
Schulzrinne等人 标准跟踪[第7页]
RFC 3550 RTP 2003年7月
混音器和翻译器可以设计用于各种目的。一个
例如是一个缩放个人图像的视频混合器
在单独的视频流中，并将它们合成为一个视频流
模拟一个组景。其他翻译的例子包括
连接一组主机只说IP / UDP的一组主机
只理解ST-II的主机，或者逐包编码
翻译来自个别来源的视频流
重新同步或混合。搅拌机的操作细节
译文在第7部分给出。
分层编码
多媒体应用程序应该能够调整传输
速率匹配接收器的容量或适应网络
拥塞。许多实现都将速率 -
来源的适应性。这对多播不起作用
由于带宽需求的冲突传输
异构接收器。结果往往是最不常见的
分母场景，网络中最小的管道网格
决定了整个现场多媒体的质量和保真度
“广播”。
相反，速率适应的责任可以放在这里
接收器通过将分层编码与分层传输相结合
系统。在RTP over IP组播的情况下，源可以
对分层表示的信号的渐进层进行条带化
跨多个RTP会话，每个会话都承载在自己的多播组上。
接收者可以适应网络异质性并控制它们
接收带宽只通过加入适当的子集
多播组。
在分层编码中使用RTP的细节在附录中给出
第6.3.9，8.3和11。
。
RTP有效载荷：RTP在数据包中传输的数据
示例音频样本或压缩视频数据。有效载荷
格式和解释超出了本文的范围。
RTP包：由固定的RTP头部组成的数据包，
可能是空的清单的贡献来源（见下文），和
净荷数据。一些底层协议可能需要一个
封装待定义的RTP包。通常是一个
底层协议的数据包包含单个RTP数据包，
但是如果允许，可以包含几个RTP包
封装方法（见第11节）。
Schulzrinne等人 标准跟踪[第8页]
RFC 3550 RTP 2003年7月
RTCP数据包：一个由固定标题部分组成的控制数据包
类似于RTP数据包，其次是结构化的
元素根据RTCP数据包类型而变化。该
格式在第6节中定义。通常，多个RTCP
数据包作为复合RTCP数据包一起发送
底层协议的数据包; 这是由长度启用
在每个RTCP分组的固定报头中。
端口：“传输协议使用的抽象
区分给定主机内的多个目的地
电脑。TCP / IP协议使用小正值来标识端口
整数“。[ 12 ] OSI使用的传输选择器（TSEL）
传输层相当于端口。RTP取决于
下层协议提供一些机制如端口来
复用会话的RTP和RTCP数据包。
传输地址：网络地址和端口的组合
标识传输级端点，例如IP
地址和一个UDP端口。数据包从源传输
传输地址到目的地传输地址。
RTP媒体类型：RTP媒体类型是有效载荷的集合
可以在单个RTP会话中携带的类型。RTP
配置文件将RTP媒体类型分配给RTP有效内容类型。
多媒体会话：一组并发的RTP会话
共同参与者的小组。例如，一个视频会议
（这是一个多媒体会话）可能包含一个音频RTP会话
和一个视频RTP会话。
RTP会话：一组参与者之间的关联
与RTP进行通信。参与者可能涉及多个
RTP会话。在多媒体会议中，每个会议
媒体通常是在一个单独的RTP会话中进行的
RTCP包，除非编码本身多路复用
媒体转换成单一的数据流。参与者区分
通过接收不同的会话使用多个RTP会话
不同的目标传输地址对，其中一对
的传输地址包括一个网络地址加一对
用于RTP和RTCP的端口。RTP会话中的所有参与者都可以
共享一个共同的目的地传输地址对，如在这种情况下
的IP组播，或者每对的配对可能不同
参与者，就像个人单播网络一样
地址和端口对。在单播情况下，参与者可以
从会议中的所有其他参与者使用相同的方式接收
一对端口，或者可以为每个端口使用一对不同的端口。
Schulzrinne等人 标准跟踪[第9页]
RFC 3550 RTP 2003年7月
RTP会话的显着特点是每个会话
保持SSRC标识符的完整，独立空间（定义
下一个）。包括在一个RTP会话中的一组参与者
由那些可以接收SSRC标识符传输的组成
由RTP中的任何一个参与者作为SSRC或CSRC
（也在下面定义）或RTCP。例如，
使用单播UDP实现第三方会议
参与者从另外两个端口对分别接收。
如果每个参与者发送有关从中接收的数据的RTCP反馈
另外一个参与者只能回到那个参与者那里
会议由三个独立的点对点RTP组成
会话。如果每个参与者提供有关RTCP的反馈
接收另一个参与者给另一个参与者
参与者，那么这个会议就是由一个多方组成的
RTP会话。后一种情况模拟了这种行为
与三者之间的IP组播通信发生
参与者。
RTP框架允许这里定义的变化，但是a
通常特定的控制协议或应用程序设计
对这些变化施加限制。
同步源（SSRC）：RTP流的源
数据包，由一个32位数字SSRC标识符进行标识
RTP头，以便不依赖于网络地址。
所有来自同步源的数据包都是同一个数据包的一部分
定时和序列号空间，所以一个接收者按组来分组
用于播放的同步源。同步的例子
源包括从a派生的数据包流的发送者
信号源如麦克风或照相机，或RTP混频器
（见下文）。同步源可能会更改其数据格式，
例如，音频编码，随着时间的推移。SSRC标识符是
随机选择的价值意味着在全球范围内独一无二的
特定的RTP会话（参见第8节）。参与者不需要
对于a中的所有RTP会话使用相同的SSRC标识符
多媒体会议; SSRC标识符的绑定是
通过RTCP提供（见第6.5.1节）。如果是参与者
在一个RTP会话中产生多个流，例如来自
单独的摄像机，每个摄像机都必须被识别为不同的摄像机
SSRC。
贡献源（CSRC）：RTP数据包流的来源
这对RTP产生的合并流有贡献
搅拌机（见下文）。混频器插入一个SSRC列表
有助于生成a的源的标识符
特定的数据包放入该数据包的RTP头中。这个清单
被称为中国证监会名单。一个示例应用程序是音频
会议在哪里混频器指示所有讲话者的讲话
Schulzrinne等人 标准跟踪[第10页]
RFC 3550 RTP 2003年7月
被组合起来产生传出包，允许接收者
表示当前的讲话者，即使所有的音频数据包
包含相同的SSRC标识符（混频器的标识符）。
结束系统：生成要发送的内容的应用程序
在RTP分组中和/或消耗接收到的RTP的内容
数据包。终端系统可以充当一个或多个同步
来源在特定的RTP会话中，但通常只有一个。
混音器：从中接收RTP数据包的中间系统
或更多的来源，可能会改变数据格式，结合起来
数据包，然后转发一个新的RTP数据包。以来
多个输入源之间的时间通常不会
同步，调音台之间会进行定时调节
并为合并的流生成自己的时间。
因此，来自混频器的所有数据分组将被识别
作为混音器作为他们的同步源。
转换器：转发RTP数据包的中间系统
同步源标识符保持不变。示例
翻译器包括转换编码而不混合的设备，
从多播到单播的复制器以及应用程序级别
过滤器在防火墙。
监视器：接收发送的RTCP数据包的应用程序
RTP会议的参与者，特别是接待
报告和估计目前的服务质量
分布式监测，故障诊断和长期统计。
监视器功能可能被构建到应用程序中，
参加会议，但也可能是单独的
应用程序不参与，不发送
或接收RTP数据包（因为它们是分开的
港口）。这些被称为第三方监视器。也是
可以接受第三方监视器接收RTP数据
数据包但不发送RTCP数据包或以其他方式计入
会话。
非RTP意味着：可能需要的协议和机制
除了RTP提供可用的服务。特别是对于
多媒体会议，控制协议可能会分发
组播地址和密钥进行加密，协商
要使用的加密算法，并定义动态映射
在RTP有效载荷类型值和它们的有效载荷格式之间
代表没有预定义有效载荷类型的格式
值。这样的协议的例子包括会话启动
协议（SIP）（RFC 3261 [ 13 ]），ITU建议H.323 [ 14 ]和
应用程序使用SDP（RFC 2327 [ 15 ]），如RTSP（RFC 2326
[ 16 ]）。为了简单
Schulzrinne等人 标准跟踪[第11页]
RFC 3550 RTP 2003年7月
应用程序，电子邮件或会议数据库也可能
用过的。这样的协议和机制的规范是
超出了本文的范围。
。
所有的整数字段都以网络字节顺序进行传输，也就是大部分
重要的字节（八位字节）首先。这个字节顺序通常被称为
大端。传输顺序在[ 3 ] 中详细描述。
除非另有说明，否则数字常量以十进制表示（以10为底）。
所有标题数据都对齐到其自然长度，即16位字段
在偶数偏移量上对齐，32位字段在偏移量上对齐
可以被四整除等。指定为填充的八位字节具有值
零。
Wallclock时间（绝对日期和时间）使用
网络时间协议（NTP）的时间戳格式
秒，相对于1900年1月1日0时UTC [ 4 ]。完整的
分辨率NTP时间戳是一个64位无符号定点数字
在前32位的整数部分和小数部分
最后32位。在一些更紧凑的代表性领域
合适的，只使用中间的32位; 也就是最低的16
整数部分的位和小数部分的高16位。
必须确定整数部分的高16位
独立。
执行不需要运行网络时间协议
为了使用RTP。可以使用其他时间源，或根本没有
（请参阅第6.4.1节中关于NTP时间戳字段的描述）。
但是，运行NTP可能对同步流有用
从不同的主机传输。
NTP时间戳将在一年中的某个时间回到零
2036，但是对于RTP的目的，只有NTP对之间的差异
时间戳被使用。只要时间戳对可以
假定在68年之内，使用模块化算术
对于减法和比较使得环绕无关。
Schulzrinne等人 标准跟踪[第12页]
RFC 3550 RTP 2003年7月
。
RTP固定标题字段
RTP头有以下格式：
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| V = 2 | P | X | CC | M | PT | 序号|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 时间戳|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 同步源（SSRC）标识符|
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
| 来源（CSRC）标识符|
| .... |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
前十二个八位字节出现在每个RTP数据包中
CSRC标识符列表仅在由调音台插入时出现。
这些字段具有以下含义：
版本（V）：2比特
该字段标识RTP的版本。版本定义
这个规范是两个（2）。（值1被第一个使用
草案版本的RTP和值0被协议使用
最初是在“大桶”音频工具中实现的。）
填充（P）：1位
如果填充位已设置，则数据包包含一个或多个
附加填充八位字节在不是的一部分
有效载荷。填充的最后八位字节包含如何计数
包括它本身在内的许多填充八位字节应该被忽略。填充
可能需要一些固定块大小的加密算法
或者用于在较低层协议数据中携带多个RTP分组
单元。
扩展名（X）：1位
如果扩展位被设置，则固定的头部必须跟在后面
正好有一个头扩展，具有5.3.1 节
定义的格式。
CSRC计数（CC）：4位
CSRC计数包含后面的CSRC标识符的数量
固定的标题。
Schulzrinne等人 标准跟踪[第13页]
RFC 3550 RTP 2003年7月
标记（M）：1位
标记的解释由配置文件定义。它是
旨在允许重要的事件，如框架边界
在数据包流中被标记。配置文件可以定义额外的
标记位或通过改变指定没有标记位
有效载荷类型字段中的位数（见5.3节）。
有效载荷类型（PT）：7比特
该字段标识RTP有效载荷的格式并确定
其应用程序的解释。配置文件可以指定一个
有效载荷类型码到有效载荷格式的默认静态映射。
额外的有效载荷类型代码可以通过动态定义
非RTP手段（见第3节）。一组默认映射
音频和视频在伴随RFC 3551 [ 1 ]中指定。一个
RTP源可以在会话期间改变有效载荷类型，但是这个
字段不应该用于复用单独的媒体流
（见第5.2节）。
接收者必须忽略包含有效载荷类型的数据包
理解。
序列号：16位
每个RTP数据包的序列号增加1
发送，并可能被接收方用来检测丢包和
恢复数据包序列。序号的初始值
应该是随机的（不可预知的）进行已知的明文攻击
在加密上比较困难，即使源码本身没有
根据9.1节的方法加密，因为
数据包可能会流经一个翻译器。技巧
在[ 17 ] 中讨论选择不可预测的数字。
时间戳：32位
时间戳反映了第一个八位字节的采样时刻
RTP数据包。采样瞬间必须来自a
时钟的增量单调和线性的时间允许
同步和抖动计算（见第6.4.1节）。该
时钟分辨率必须足够满足所需要的
同步精度和测量分组到达抖动
（每个视频帧一个tick通常是不够的）。时钟
频率取决于作为有效载荷携带的数据的格式
并在配置文件或有效负载格式中被静态指定
规范定义格式，或者可以指定
动态地为通过非RTP手段定义的有效载荷格式。如果
RTP包是周期性生成的标称采样
即时从采样时钟确定要使用，而不是一个
读取系统时钟。例如，固定速率音频
时间戳时钟可能会每增加一个
采样周期。如果音频应用程序读取块覆盖
Schulzrinne等人 标准跟踪[第14页]
RFC 3550 RTP 2003年7月
来自输入设备的160个采样周期，时间戳将是
每个这样的街区增加了160个，不管是否
块在数据包中传输或者静音。
时间戳的初始值应该是随机的，至于
序列号。几个连续的RTP数据包将会相等
时间戳，如果他们（逻辑）立即生成，例如属于
到相同的视频帧。连续的RTP包可能包含
如果数据未被传输，则时间戳不是单调的
按照它被采样的顺序，如MPEG插值的情况
视频帧。（发送的数据包的序列号
仍然是单调的。）
来自不同媒体流的RTP时间戳可能会提前
不同的费率，通常有独立的，随机的抵消。
因此，虽然这些时间戳足以重建
单个流的时间，直接比较RTP时间戳
来自不同媒体的同步效果不佳。
相反，对于每个媒体的RTP时间戳是相关的
通过将其与来自参考的时间戳配对来立即采样
时钟（wallclock）代表数据的时间
对应于RTP时间戳被采样。参考资料
时钟由所有媒体共享以进行同步。时间戳
对不是在每个数据包中传输，而是在较低的
RTCP SR数据包中的速率，如6.4节所述。
采样时刻被选择作为参考点
RTP时间戳，因为它是发送端点所知道的
对于所有媒体都有一个通用的定义，与编码无关
延误或其他处理。目的是允许同步
介绍所有同时采样的媒体。
应用程序传输存储的数据而不是数据采样
实时通常使用派生的虚拟演示时间线
从挂钟时间确定何时下一帧或其他单位
存储的数据中的每种介质都应该被呈现。在这
的情况下，RTP时间戳将反映的演示时间
每个单位。也就是说，每个单元的RTP时间戳将是
与单元当前的挂钟时间有关
虚拟展示时间线。实际的演示发生
一段时间后由接收器确定。
描述预录制视频的实况音频叙述的例子
说明了选择抽样时刻的意义
参考点。在这种情况下，视频将是
在当地呈现给叙述者查看并将是
同时使用RTP进行传输。a的“采样时刻”
在RTP中传输的视频帧将通过参考建立
Schulzrinne等人 标准跟踪[第15页]
RFC 3550 RTP 2003年7月
它的时间戳到了那个视频帧的时间
提交给解说员。音频RTP的采样时刻
包含叙述者言语的分组将由...建立
在音频采样时参考相同的挂钟时间。
音频和视频甚至可以由不同的主机传输
两台主机的参考时钟是同步的
意味着如NTP。接收者然后可以同步呈现
的音频和视频数据包的RTP时间戳
使用RTCP SR数据包中的时间戳对。
SSRC：32位
SSRC字段标识同步源。这个
标识符应该随机选择，意图是没有两个
在同一个RTP会话中的同步源将有
相同的SSRC标识符。一个算法生成一个例子
随机标识符见附录A.6。虽然
多个来源选择相同标识符的概率是
低，所有的RTP实现必须准备好检测和
解决冲突。 第8节描述的概率
碰撞和解决冲突的机制
检测RTP级别转发循环的唯一性
SSRC标识符。如果来源改变其来源运输
地址，它也必须选择一个新的SSRC标识符来避免
解释为一个循环的来源（见第8.2节）。
证监会名单：0-15项，每项32位
中国证监会的名单确定了有效载荷的贡献来源
包含在这个包里。标识符的数量由下式给出
CC领域。如果有超过15个来源，
只有15个可以被识别。CSRC标识符被插入
混频器（见第7.1节），使用SSRC标识符
来源。例如，对于SSRC的音频数据包
所有来源的标识符混合在一起创建一个
数据包被列出，允许正确的说话者指示
接收器。
复用RTP会话
为了有效协议处理，多路复用点的数量
应该最小化，如集成层处理中所述
设计原则[ 10 ]。在RTP中，复用是由... ...提供的
目的地传输地址（网络地址和端口号）哪个
对于每个RTP会话是不同的。例如，在电话会议中
由分别编码的音频和视频媒体组成，每个媒体
应该在一个单独的RTP会话中进行
运输地址。
Schulzrinne等人 标准跟踪[第16页]
RFC 3550 RTP 2003年7月
独立的音频和视频流不应该单独携带
RTP会话并基于有效载荷类型或SSRC进行解复用
领域。使用不同的RTP媒体类型交错数据包
使用相同的SSRC会带来几个问题：
如果两个音频流共享相同的RTP会话，
相同的SSRC值，一个是改变编码，从而获得
一个不同的RTP负载类型，不会有一般的方法
识别哪个流已经改变了编码。
2. SSRC被定义为识别单个时间和序列号
空间。交错多种有效载荷类型将需要
不同的时间空间，如果媒体时钟速度不同而且会
需要不同的序列号空间来告诉哪个有效载荷
类型遭受丢包。
3. RTCP发送者和接收者报告（见第6.4节）只能
描述每个SSRC的一个时序和序列号空间，而不是
携带有效载荷类型字段。
4.一个RTP混音器将不能组合交错流
不兼容的媒体合并成一个流。
在一个RTP会话中携带多个媒体排除：使用
不同的网络路径或网络资源分配
适当; 如果需要，接收媒体的一个子集
例如，如果视频超过可用带宽，则只是音频;
和接收器实现使用单独的进程的
不同的媒体，而使用单独的RTP会话许可
无论是单进程还是多进程实现。
每个媒体使用不同的SSRC，但发送相同的
RTP会话将避免前三个问题，但不是最后一个
二。
另一方面，复用多个相同的来源
在一个RTP会话中使用不同的SSRC值是正常的
多播会话。上面列出的问题不适用：RTP
调音台可以结合多个音源，例如和一样
所有的治疗都是适用的。这也可能是适当的
使用不同的SSRC值复用相同介质的流
在最后两个问题不适用的其他情况下。
Schulzrinne等人 标准跟踪[第17页]
RFC 3550 RTP 2003年7月
RTP头的特定于配置文件的修改
现有的RTP数据包头被认为是完整的
在所有应用程序中共同需要的一组功能
RTP可能支持的类。但是，与ALF保持一致
设计原则，标题可以通过修改或定制
在配置文件规范中定义的添加，同时仍然允许
独立于配置文件的监视和录制工具来运行。
标记位和有效载荷类型字段携带配置文件特定的
信息，但是由于许多信息被分配在固定标题中
应用程序预计需要他们，否则可能不得不
添加另一个32位字来保存它们。包含八位字节
这些字段可能会被一个配置文件重新定义，以适应不同的情况
要求，例如具有更多或更少的标记位。如果
有任何标记位，应该位于最多的位置
自配置文件独立监视器以来的八位字节的显着位
可能能够观察到分组丢失模式之间的相关性
和标记位。
o特定有效载荷所需的附加信息
格式，比如视频编码，应该在有效载荷中携带
包的一部分。这可能在总是一个头
出现在有效载荷部分的开始处，或者可能被指示
通过数据模式中的保留值。
o如果特定类别的应用程序需要额外的
独立于有效载荷格式的功能，下面的配置文件
这些应用程序运行应该定义额外的固定
在现有的SSRC领域之后立即跟随领域
固定标题。这些应用程序将能够快速和
在配置文件无关的情况下直接访问其他字段
监视器或录像机仍然可以处理RTP数据包
只解释前十二个八位字节。
如果事实证明，共同需要额外的功能
跨所有配置文件，那么应该定义一个新版本的RTP
对固定标题进行永久更改。
RTP头扩展
提供了一个扩展机制来允许个人
实现实验新的有效载荷格式无关
功能，需要额外的信息进行
RTP数据包头。这个机制是这样设计的
扩展头可能会被其他互操作忽略
尚未扩展的实现。
Schulzrinne等人 标准跟踪[第18页]
RFC 3550 RTP 2003年7月
请注意，这个扩展头仅用于有限的使用。
这个机制的大多数潜在用途会更好地做另一个
方式，使用上一节中描述的方法。对于
例如，固定标题的特定于配置文件的扩展名较少
处理起来很昂贵，因为它不是有条件的，也不是一个变量
位置。特定有效载荷所需的附加信息
格式不应该使用这个头扩展名，但应该进入
分组的有效载荷部分。
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头中的X位是一个可变长度的头
在CSRC列表之后，扩展名必须附加到RTP头
如果有的话。标题扩展名包含一个16位长度的字段
计算扩展名中32位字的数量，不包括
四个字节的扩展头（因此零是有效的长度）。只要
一个扩展名可以附加到RTP数据头。允许
多个互操作实现到每个实验
独立使用不同的头扩展，或允许一个
特殊的实现来试验多种类型的
头扩展，头扩展的前16位留下
打开区分标识符或参数。的格式
这16位是由profile配置文件定义的
这些实现正在运行。这个RTP规范呢
没有定义任何头扩展本身。
。
RTP控制协议（RTCP）基于周期性传输
的控制包给会话中的所有参与者，使用相同的方式
分配机制作为数据包。底层协议
必须提供数据和控制数据包的复用
例如使用与UDP分开的端口号。RTCP执行四个
功能：
主要功能是提供关于质量的反馈
数据分配。这是RTP作用的组成部分
传输协议，并与流量和拥塞有关
其他传输协议的控制功能（参见第10节）
拥塞控制的要求）。反馈可能是
用于自适应编码[控制直接有用18，19 ]，但
IP多播实验表明，它也是
Schulzrinne等人 标准跟踪[第19页]
RFC 3550 RTP 2003年7月
至关重要的是从接收器获得反馈来诊断故障
分布。向所有人发送接收反馈报告
参与者允许正在观察问题的人进行评估
无论这些问题是本地还是全球。随着分配
像IP组播这样的机制，对一个实体也是可能的
如没有涉及的网络服务提供商
在会议期间接收反馈信息并作为一个
第三方监视器来诊断网络问题。这个反馈
功能是由RTCP发送者和接收者报告执行的，
如6.4节所述。
2. RTCP为RTP携带一个持久的传输级标识符
来源称为规范名称或CNAME，第6.5.1节。以来
如果发现冲突，则SSRC标识符可能会更改
程序重新启动，接收器需要CNAME跟踪
每个参与者。接收者也可能需要CNAME
将来自集合中给定参与者的多个数据流相关联
相关的RTP会话，例如同步音频和
视频。媒体间同步也需要NTP和RTP
数据发送方包含在RTCP数据包中的时间戳。
3.前两个功能要求所有参与者发送RTCP
数据包，因此速率必须被控制以使RTP到达
扩大到大量的参与者。通过每个
参与者将其控制包发送给所有其他人，每个人都可以
独立观察参与者人数。这个数字是
用来计算数据包发送的速率，如
在6.2节中解释。
4.第四，可选功能是传达最小的会话控制
信息，例如参与者身份
显示在用户界面中。这很可能是有用的
在参与者进入的“松散控制的”会议中
离开没有会员控制或参数协商。RTCP
作为到达所有参与者的便利渠道，但是
不一定期望支持所有的控制
通信要求的应用程序。更高一级
会话控制协议，这是超出了这个范围
文件，可能是需要的。
功能1-3应该在所有环境中使用，特别是在
IP组播环境。RTP应用程序设计者应该避免
机制只能在单播模式下工作，不能扩展到
更大的数字。RTCP的传输可以单独控制
对于发送者和接收者，如在第6.2节中，例
例如来自接收器的反馈不是单向链路
可能。
Schulzrinne等人 标准跟踪[第20页]
RFC 3550 RTP 2003年7月
非规范性说明：在组播路由方法中
称为源特定多播（SSM），只有一个发送者
每个“通道”（源地址，组地址对），和
接收者（频道源除外）不能使用多播
与其他渠道成员直接沟通。该
这里建议适应SSM只能通过第6.2节的
完全关闭接收者的RTCP选项。未来的工作将会
指定适用于SSM的RTCP，以便从接收方反馈
可以维持。
RTCP数据包格式
这个规范定义了几个RTCP分组类型来携带一个
各种控制信息：
SR：发件人报告，用于发送和接收统计
参与者是主动发件人
RR：接收者报告，用于接收参与者的接收统计
那些不是主动的发送者，而是与SR的组合
主动发送者报告超过31个来源
SDES：来源说明项目，包括CNAME
BYE：表示参与结束
APP：应用程序特定的功能
每个RTCP数据包以与RTP数据类似的固定部分开始
数据包，然后是结构化元素，可能是可变的
长度根据数据包类型，但必须在32位结束
边界。对齐要求和固定长度字段
包含每个数据包的一部分以使RTCP数据包“可堆叠”。
多个RTCP数据包可以连接而不需要任何干预
分隔符来形成一个复合RTCP数据包，它是在一个单一的发送
下层协议的数据包，例如UDP。没有
显式计数复合包中的单个RTCP包
因为低层协议有望提供一个整体
确定复合包的结束长度。
可以处理复合分组中的每个单独的RTCP分组
独立，对订单或组合没有要求
数据包。但是，为了执行协议的功能，
下面的限制是强加的：
Schulzrinne等人 标准跟踪[第21页]
RFC 3550 RTP 2003年7月
o接收统计（在SR或RR中）应该经常发送
带宽限制将允许最大化的分辨率
统计，所以每个周期性地发送复合RTCP
分组必须包含一个报告分组。
o新接收者需要尽快接收源的CNAME
可能确定来源并开始关联媒体
目的如唇同步，所以每个复合RTCP数据包也必须
包括SDES CNAME，除了复合RTCP数据包时
按9.1节所述进行部分加密分割。
o化合物中可能首先出现的数据包类型的数量
数据包需要被限制以增加固定位的数量
在第一个字和成功验证的可能性
RTCP数据包针对错误的RTP数据包或其他数据包
无关的数据包。
因此，所有RTCP分组至少必须在一个复合分组中发送
两个单独的数据包，格式如下：
加密前缀：当且仅当复合数据包是
根据9.1节的方法加密，它必须是
以每个化合物的随机32位数量作为前缀
数据包传输。如果填充需要进行加密，则为
务必添加到复合包的最后一个包中。
SR或RR：复合包中的第一个RTCP包必须
始终是一个报告数据包，以方便标题验证
如附录A.2所述。即使没有数据，情况也是如此
发送或接收，在这种情况下，必须发送一个空的RR，甚至是
如果复合报文中唯一的其他RTCP报文是BYE。
额外的RR：如果接收的来源的数量
统计报告超过31个，将适合的数量
到一个SR或RR数据包中，那么附加的RR数据包应该遵循
最初的报告包。
SDES：必须包含一个包含CNAME项目的SDES数据包
在每个复合RTCP分组中，除了在9.1节中提到的以外。
其他来源的描述项目可以选择包括，如果
需要一个特定的应用程序，受带宽限制
约束条件（见6.3.9节）。
BYE或APP：其他RTCP数据包类型，包括那些尚未被使用的数据包
定义，可以按照任何顺序，除了BYE应该是
与SSRC / CSRC给定的最后一个数据包。数据包类型可能会出现
不止一次。
Schulzrinne等人 标准跟踪[第22页]
RFC 3550 RTP 2003年7月
个人RTP参与者应该只发送一个复合RTCP
数据包每报告间隔为了每个RTCP带宽
参与者被正确地估计（见第6.2节），除了什么时候
如上所述，复合RTCP分组被分割以进行部分加密
在9.1节。如果有太多的来源来适应所有的
必要的RR数据包合并为一个复合RTCP数据包而不超过
网络路径的最大传输单位（MTU）
将适合一个MTU的子集应该包含在每个中
间隔。子集应该跨多个循环选择
以便报告所有来源。
建议翻译人员和混音人员合并个人RTCP
来自多个来源的数据包被转发到一个
复合数据包在任何可行的情况下，以分摊数据包
开销（见第7节）。一个示例RTCP复合包可能
由混合器生产的如图1所示
一个复合包将超过网络路径的MTU，应该是这样的
被分割成多个较短的复合包进行传输
在底层协议的单独数据包中。这不会损害
由于每个复合分组表示RTCP带宽估计
至少有一个不同的参与者。请注意，每个化合物
分组必须以SR或RR分组开始。
一个实现应该忽略带有类型的传入RTCP数据包
它不知道。额外的RTCP数据包类型可以注册
互联网号码分配机构（IANA）的描述
第15节。
如果加密：随机的32位整数
|
| [---------数据包--------] [----------数据包----------] [ - 数据包]
|
| 接收器块大块
V报告项目项目项目项目
-------------------------------------------------- ------------------
R [SR #sendinfo＃site1＃site2] [SDES #CNAME PHONE #CNAME LOC] [BYE ## why]
-------------------------------------------------- ------------------
| |
| <-----------------------复合包----------------------- > |
| <-------------------------- UDP packet -------------------- -----> |
＃：SSRC / CSRC标识符
图1：一个RTCP复合包的例子
Schulzrinne等人 标准跟踪[第23页]
RFC 3550 RTP 2003年7月
RTCP传输间隔
RTP旨在允许应用程序自动缩放
会议规模从几个参与者到数千人不等。对于
例如，在音频会议中，数据业务本质上是自组织的，
限制，因为一次只有一两个人会说话，所以
多播分配，任何给定链路上的数据速率仍然保持
与参与者的数量无关。
但是，控制流量不是自我限制的。如果接待
每个参与者的报告都是以恒定的速度发送的
控制流量将随着参与者的数量呈线性增长。
因此，速率必须通过动态计算来缩小
RTCP数据包传输之间的时间间隔。
对于每个会话，都假定数据流量受到影响
一个称为“会话带宽”的聚合限制被分配
参与者们。这个带宽可能被保留，并且是有限的
由网络执行。如果没有保留，可能会有
其他限制，取决于环境，建立的
会议使用的“合理的”最大限度，这将是
会话带宽。会话带宽可以根据一些选择
成本或对可用网络带宽的先验知识
会话。它有些独立于媒体编码，但是
编码选择可能会受到会话带宽的限制。通常情况下，
会话带宽是发送者的标称带宽的总和
预计将同时活跃。对于电话会议音频，这个
数字通常是一个发送者的带宽。对于分层
编码，每一层都是一个单独的RTP会话与自己的会话
带宽参数。
会话带宽参数预计由a提供
会话管理应用程序在调用媒体应用程序时，
但媒体应用程序可能会根据单一发件人设置默认值
为会话选择的编码的数据带宽。该
应用程序也可以强制基于多播的带宽限制
范围规则或其他标准。所有参与者必须使用相同的
会话带宽的值，以便相同的RTCP时间间隔
被计算。
控制和数据流量的带宽计算包括：
层传输和网络协议（例如，UDP和IP）
是资源预留系统需要知道的。该
应用程序也可以被期望知道这些协议是哪一个
正在使用。链接级别标题不包含在计算中
该数据包将被封装为不同的链路层头
它旅行。
Schulzrinne等人 标准跟踪[第24页]
RFC 3550 RTP 2003年7月
控制流量应该限制在一个小的已知分数
的会话带宽：小，这样的主要功能
传输协议携带数据不受损害; 已知所以
控制流量可以包含在给定的带宽规范中
到资源预留协议，以便每个参与者都可以
独立计算其份额。控制流量带宽是
除了数据流量的会话带宽。它是
建议为RTCP添加会话带宽的一小部分
固定在5％。也建议使用RTCP的1/4
带宽专用于正在发送数据的参与者
在与大量的接收器，但少数的会议
发件人，新加入的参与者将更快收到
发送网站的CNAME。当发件人的比例是
超过1/4的参与者，发件人得到他们的
完整的RTCP带宽的比例。而这些和价值
区间计算中的其他常量并不重要
会话中的参与者必须使用相同的值
间隔将被计算。因此，这些常数应该是
固定为特定的配置文件。
配置文件可以指定控制流量带宽可能是a
会话的单独参数而不是严格的百分比
会话带宽。使用单独的参数，
自适应应用程序来设置RTCP带宽与a一致
“典型”数据带宽低于最大带宽
由会话带宽参数指定。
配置文件可以进一步指定控制流量带宽
可以分为两个单独的会话参数
参与者是活跃的数据发送者而不是那些;
让我们调用参数S和R.按照推荐
那RTCP带宽的四分之一专用于数据发送者
对于这两个参数，推荐的默认值是1.25％
和3.75％。发件人比例较大时
比参与者的S /（S + R），发件人得到他们的比例
这些参数的总和。使用两个参数允许RTCP
接待报告将完全关闭一个特定的会议
通过将非数据发送者的RTCP带宽设置为零
保持数据发送者的RTCP带宽不为零，以便发送者
报告仍然可以发送用于媒体间同步。车削
关闭RTCP接收报告是不推荐的，因为它们是需要的
对于第6节开头列出的功能，尤其如此
接收质量反馈和拥塞控制。但是，这样做
可能适用于在单向链路上运行的系统
对于不需要接收质量反馈的会话
或接收者的活泼，并有其他方法来避免
拥塞。
Schulzrinne等人 标准跟踪[第25页]
RFC 3550 RTP 2003年7月
计算复合RTCP的传输间隔
数据包还应该有一个下界，以避免有突发
当参与者数量超过允许的带宽时
规模小，交通不平顺，规模大
数字。它也保持报告间隔变得太小
在像网络分区这样的暂时中断期间
当分区愈合时适应被延迟。在应用程序
启动时，应在第一个复合RTCP之前施加一个延迟
分组被发送以允许从RTCP分组接收时间
其他参与者如此报告的时间间隔将会收敛到
正确的价值更快。这个延迟可能会被设置为一半
最小间隔允许更快通知新的
参加者在场。推荐值为固定的最小值
间隔是5秒。
实现可以将最小RTCP间隔缩小到更小
值与会话带宽参数成反比
有以下限制：
o对于多播会话，只有活动的数据发送者可以使用
减小最小值来计算传输间隔
复合RTCP数据包。
o对于单播会话，可以使用缩小的值
那些不是主动数据发送者的参与者，以及
在发送初始化合物RTCP包之前延迟可能为零。
○对于所有的会话，固定的最小值应该在什么时候使用
计算参与者超时间隔（参见第6.3.5节）
所以那些不使用减少值的实现
其他参与者不会超时发送RTCP数据包
过早。
o以秒为单位的最小值的推荐值为360
会话带宽除以千比特/秒。这最低限度
对于大于72kb / s的带宽，小于5秒。
设计了6.3节和附录A.7中
描述的算法
以达到本节所述的目标。它计算出
发送复合RTCP数据包之间的间隔来划分允许的
控制参与者之间的流量带宽。这允许一个
应用程序提供快速响应的小型会议，为
例如，所有参与者的身份是重要的，但
自动适应大型会议。算法合并
以下特点：
Schulzrinne等人 标准跟踪[第26页]
RFC 3550 RTP 2003年7月
计算的RTCP数据包之间的时间间隔线性变化
组中的成员数量。这是线性因素
在总结时允许控制流量不变
跨所有成员。
o RTCP数据包之间的间隔随机变化
范围[0.5,1.5]乘以计算的时间间隔以避免意外
同步所有参与者[ 20 ]。第一个RTCP数据包
加入会议后发送的也是随机变化的延迟
是最小RTCP间隔的一半。
○对平均复合RTCP分组大小的动态估计是
计算，包括所有收到和发送的数据包
自动适应控制量的变化
信息进行。
o由于计算的时间间隔取决于数量
观察组员，可能会有不良的启动效应
当一个新用户加入一个现有的会议，或许多用户
同时加入新的会议。这些新用户将在最初
有不正确的团体成员的估计，因此他们的
RTCP传输间隔太短。这个问题可以
如果许多用户同时加入会话，这是很重要 至
处理这个，一个叫做“定时器重新考虑”的算法是
采用。这个算法实现了一个简单的退避机制
这会导致用户阻止RTCP数据包的传输
团体人数正在增加。
o当用户离开会议时，或者用BYE或者超时，
组成员减少，从而计算出的间隔
应该减少。使用“反向重新考虑”算法
允许成员更快地缩短回应的时间间隔
组员的减少。
BYE数据包的处理方式与其他RTCP数据包不同。
当用户离开一个组，并希望发送一个BYE包时，
可以在其下一个调度的RTCP分组之前这样做。然而，
BYE的传输遵循避免的退避算法
BYE包的洪水应该是大量的成员
同时离开会议。
这个算法可以用于所有参与者的会话
允许发送。在这种情况下，会话带宽参数是
个人发送者的带宽乘以数量的乘积
参与者，而RTCP的带宽是5％。
该算法的操作细节在以下部分给出
跟随。 附录A.7给出了一个示例实现。
Schulzrinne等人 标准跟踪[第27页]
RFC 3550 RTP 2003年7月
维护会话成员的数量
RTCP数据包间隔的计算取决于一个估计值
参加会议的网站数量。新的网站是
当他们被听到时被添加到计数中，并且每个都应该输入
在由SSRC或CSRC标识符索引的表格中创建
8.2节）跟踪他们。可以考虑新的条目
直到有多个携带新的SSRC的数据包才有效
接收（见附录A.1），或直到一个SDES RTCP包包含
该SSRC的CNAME已收到。条目可以从中删除
当一个RTCP表与一个相应的SSRC的BYE包对照表时
标识符被接收，除了一些零散的数据包可能
在BYE之后到达并且导致条目被再造。代替，
该条目应该被标记为已经收到BYE，然后被删除
经过适当的延迟。
参与者可以标记另一个网站处于非活动状态，或者如果尚未删除
如果没有收到少量的RTP或RTCP数据包，则为有效
的RTCP报告间隔（推荐5）。这提供了一些
对数据包丢失的鲁棒性。所有网站必须具有相同的价值
对于这个乘数，必须计算大致相同的值
RTCP报告间隔，以便此超时正常工作。
因此，这个乘数应该是固定的一个特定的配置文件。
对于有大量参与者的会议，可能会是
维护一个表来存储SSRC标识符是不切实际的
所有这些状态信息。一个实现可以使用SSRC
采样，如[ 21 ]中所述，以减少存储要求。
一个实现可以使用任何其他类似的算法
性能。一个关键的要求是考虑任何算法
虽然它不应该大大低估组的大小
可能高估了。
RTCP数据包发送和接收规则
如何发送的规则，以及接收RTCP时的操作规则
数据包在这里列出。一个允许在其中运行的实现
多播环境或多点单播环境必须满足6.2节
的要求。这样的实现可以使用
算法在本节中定义，以满足这些要求，或者可以
只要提供等价的或更好的，就可以使用其他一些算法
性能。一个限于双方的实施
单播操作应该仍然使用RTCP的随机化
传输间隔可以避免多重意外同步
在相同环境中运行的实例，但可以省略“计时器”
重新考虑“和”反向重新考虑“算法
6.3.3，6.3.6和6.3.7。
Schulzrinne等人 标准跟踪[第28页]
RFC 3550 RTP 2003年7月
为了执行这些规则，会话参与者必须维护几个
件状态：
tp：RTCP数据包最后一次传输的时间;
tc：当前时间;
tn：RTCP分组的下一个调度传输时间;
会员：在时间tn会议成员的估计数量
最后重新计算;
成员：会议次数的最新估计
成员;
发件人：最新的发件人数量估计
会议;
rtcp_bw：目标RTCP带宽，即总带宽
该会话的所有成员将用于RTCP数据包，
以每秒八位字节为单位。这将是一个指定的分数
提供给应用程序的“会话带宽”参数
启动。
we_sent：如果应用程序发送了数据，则为true
自从第二个以前的RTCP报告被传送。
avg_rtcp_size：平均复合RTCP数据包大小，以八位组为单位，
通过此参与者发送和接收的所有RTCP数据包。该
大小包括低层传输和网络协议头
（如UDP和IP），如第6.2节所述。
initial：如果应用程序尚未发送，则为true的标志
一个RTCP数据包。
这些规则中的很多都利用了两者之间的“计算间隔”
数据包传输。这个时间间隔如下所述
部分。
计算RTCP传输间隔
为了保持可伸缩性，数据包之间的平均间隔由一个
会话参与者应按照组大小进行缩放。这个间隔
被称为计算间隔。它是通过组合一个
上述状态的数量。计算
间隔T然后如下确定：
Schulzrinne等人 标准跟踪[第29页]
RFC 3550 RTP 2003年7月
1.如果发件人的数量少于或等于25％
会员（会员）的间隔取决于是否
参与者是否为发件人（基于we_sent的值）。
如果参与者是发件人（we_sent为true），则常量C为
设置为平均RTCP数据包大小（avg_rtcp_size）除以25％
的RTCP带宽（rtcp_bw），常数n被设置为
发件人数量。如果we_sent不正确，则设置常量C.
到平均RTCP数据包大小除以RTCP的75％
带宽。常数n被设置为接收器的数量
（成员 - 发件人）。如果发件人的数量大于
25％，发件人和收件人一起处理。常数C
被设置为平均RTCP分组大小除以总RTCP
带宽和n被设置为成员总数。就像声明的那样
在6.2节中，RTP配置文件可以指定RTCP带宽
可以由两个独立的参数明确定义（称它们为S
和R）为发件人和那些参与者
不是。在这种情况下，25％的分数变成S /（S + R）
75％部分变成R /（S + R）。请注意，如果R是零，
发件人的百分比从不大于S /（S + R），并且
执行必须避免被零除。
2.如果参与者尚未发送RTCP数据包（变量
初始值为真），常数Tmin设置为2.5秒，否则
设置为5秒。
3.确定性计算间隔Td被设置为max（Tmin，n * C）。
4.计算出的间隔T被设定为均匀分布的数字
在确定性计算间隔的0.5和1.5倍之间。
5. T的结果值除以e-3/2 = 1.21828来补偿
定时器复议算法收敛到的事实
RTCP带宽的值低于预期的平均值。
这个过程导致了一个随机的间隔，但是这个间隔是
平均而言，RTCP带宽至少为发送方和服务器提供了25％的带宽
休息给接收者。如果发件人构成四分之一以上
的程序，这个程序之间平分带宽
所有的参与者，平均。
初始化
加入会话后，参与者将tp初始化为0，tc为
0，发件人为0，发件人为1，发件人为1，发件人为假，
rtcp_bw到会话带宽的指定分数，初始值
为true，avg_rtcp_size为第一个RTCP的可能大小
应用程序稍后将构建的数据包。计算
然后计算间隔T，并且计划第一个分组
Schulzrinne等人 标准跟踪[第30页]
RFC 3550 RTP 2003年7月
时间tn = T。这意味着发送定时器被设置
在时间T到期。请注意，应用程序可以使用任何需要的
实现这个计时器的方法。
参与者将其自己的SSRC添加到成员表中。
接收RTP或非BYE RTCP包
从SSRC的参与者收到RTP或RTCP数据包时
不在成员表中，SSRC被添加到表中，而
一旦参与者被验证，成员的价值就会被更新
如第6.2.1节所述。每个处理都发生相同的处理
证监会在一个经过验证的RTP数据包。
从SSRC不参与者收到RTP包时
在发件人表中，SSRC被添加到表中，并且值
发件人更新。
对于收到的每个复合RTCP数据包，avg_rtcp_size的值是
更新：
avg_rtcp_size =（1/16）* packet_size +（15/16）* avg_rtcp_size
其中packet_size是刚收到的RTCP包的大小。
接收RTCP BYE包
除了6.3.7节中描述的情况，当一个RTCP BYE是
如果收到的数据包是一个RTCP BYE数据包，则发送
SSRC是检查成员表。如果有的话，那就是
从表中删除，并更新成员的值。该
SSRC然后检查发件人表。如果存在，输入
将从表中删除，并更新发件人的值。
此外，为了使RTCP分组的传输速率更高
适应组员身份的变化，下面的“反向”
重新考虑“算法应该在BYE数据包执行时执行
收到，减少会员的价值低于pmembers：
o tn的值根据以下公式进行更新：
tn = tc +（会员/会员）*（tn - tc）
o tp的值根据以下公式进行更新：
tp = tc - （members / pmembers）*（tc - tp）。
Schulzrinne等人 标准跟踪[第31页]
RFC 3550 RTP 2003年7月
o下一个RTCP分组在tn时间重新调度传输，
现在是更早。
o pmembers的值等于成员。
该算法不会阻止来自组的大小估计
由于过早而不正确地降到零
当一个大会议的大多数参与者同时离开时超时
一些保持。该算法确实使估计返回到
正确的价值更迅速。这种情况是不寻常的，
后果是充分无害的，认为这个问题
只是次要的关注。
定时SSRC
偶尔间隔，参与者必须检查是否有任何
其他参与者超时。要做到这一点，参与者
计算确定性（没有随机因素）
计算出接收者的时间间隔Td，即we_sent为false。
任何其他会议成员，因为没有发送RTP或RTCP数据包
时间tc - MTd（M是超时乘数，默认为5）
时间到。这意味着其SSRC从成员列表中删除，
并更新成员。对发件人执行类似的检查
名单。发件人列表中尚未发送RTP数据包的任何成员
因为时间tc - 2T（在最后两个RTCP报告间隔内）是
从发件人列表中删除，并更新发件人。
如果有任何成员超时，则反向重新考虑算法
在6.3.4节中描述应该被执行。
参与者必须至少每个RTCP进行一次检查
传输间隔。
发送计时器到期
当分组传输定时器到期时，参与者执行
以下操作：
传输间隔T按6.3.1 节
所述计算，包括随机因子。
o如果tp + T小于或等于tc，则一个RTCP包是
传输。tp设置为tc，那么T的另一个值是
按上一步计算，tn设为tc + T
传输定时器被设置为在时间tn再次到期。如果tp + T
大于tc，则tn被设置为tp + T。没有RTCP分组
传输。传输定时器设置为在时间tn过期。
Schulzrinne等人 标准跟踪[第32页]
RFC 3550 RTP 2003年7月
会员设置为会员。
如果发送RTCP分组，则初始值设置为
假。此外，更新avg_rtcp_size的值：
avg_rtcp_size =（1/16）* packet_size +（15/16）* avg_rtcp_size
其中packet_size是刚传输的RTCP数据包的大小。
传输BYE包
当一个参与者希望离开一个会话时，一个BYE包是
传送给该事件的其他参与者。为了
当许多参与者离开时，避免BYE数据包的泛滥
系统，参与者必须执行以下算法
参与者选择的会员人数超过50人
离开。这个算法篡夺了成员变量的正常角色
要计算BYE数据包，而不是：
o当参与者决定离开系统时，tp被重置为
tc，目前的时间，会员和会员都初始化为1，
初始设置为1，we_sent设置为false，发件人设置为0，
avg_rtcp_size设置为复合BYE报文的大小。
计算出的间隔T。BYE包是
预定时间tn = tc + T
o每当收到来自其他与会者的BYE数据包时，
无论是否参加者，成员都会加1
是否存在于成员表中，以及SSRC采样是否存在
不管BYE SSRC是否包括在内，都可以使用
在样本中。其他RTCP数据包时，成员不增加
或收到RTP数据包，但仅用于BYE数据包。同样的，
avg_rtcp_size仅针对收到的BYE数据包进行更新。发件人
当RTP包到达时不更新; 它仍然是0。
o BYE包的传输遵循规则
如上所述发送常规的RTCP分组。
这允许BYE数据包立即被发送，但是控制它们
总带宽使用。在最坏的情况下，这可能会导致RTCP
控制数据包使用正常的两倍带宽（10％） - 5％
非BYE RTCP包和BYE的5％。
一个不想等待上述机制的参与者
允许BYE包的传输可以离开组
发送一个BYE。该参与者最终将被超时
由其他小组成员。
Schulzrinne等人 标准跟踪[页33]
RFC 3550 RTP 2003年7月
如果团体规模估算的成员小于50的时候
参与者决定离开，参与者可以发送BYE包
立即。或者，参与者可以选择执行
上面的BYE退避算法。
在任何情况下，都不会发送RTP或RTCP数据包的参与者
当他们离开组时，绝不能发送BYE包。
更新we_sent
如果参与者发送了RTP，则变量we_sent包含true
数据包最近，否则为false。这个决心是由
使用相同的机制来管理其他的一套
发件人列表中列出的参与者。如果参与者发送
一个RTP包，当we_sent为false时，它将自己添加到发件人
表并将we_sent设置为true。反向重新考虑
在6.3.4节中描述的算法应该可能被执行
减少发送SR包之前的延迟。每次都有另一个RTP
分组被发送，该分组的传输时间被保持
在桌子里。正常的发送者超时算法然后被应用于
参与者 - 如果一个RTP包没有被传送
时间tc - 2T，参与者从发件人表中删除自己，
递减发件人计数，并将we_sent设置为false。
源描述带宽的分配
本规范定义了几个源描述（SDES）项
除了必须的CNAME项目，如NAME（个人名称）
和EMAIL（电子邮件地址）。它也提供了一种定义新的方法
特定于应用程序的RTCP数据包类型。应用程序应该运行
谨慎分配控制带宽到这个额外的
信息，因为它会减慢接收的速度
报告和CNAME被发送，从而削弱了CNAME的性能
协议。建议不要超过20％的RTCP
分配给单个参与者的带宽用于承载
附加信息。而且，它并不是全部
SDES项目将被包括在每个应用程序中。那些是
包括应该被分配一部分带宽根据
他们的效用。它不是动态地估计这些分数
建议将百分比静态转换为
根据项目的典型长度报告间隔计数。
例如，应用程序可能被设计为仅发送CNAME，名称
和EMAIL，而不是其他任何人。NAME可能会更高
优先级高于EMAIL，因为NAME会连续显示
在应用程序的用户界面中，而EMAIL将被显示
只有在要求时。在每个RTCP时间间隔，一个RR数据包和一个
带有CNAME项目的SDES数据包将被发送。对于一个小会议
Schulzrinne等人 标准跟踪[页34]
RFC 3550 RTP 2003年7月
以最小时间间隔运行，即每5秒开启一次
平均。每隔三秒（15秒），一个额外的项目会
包含在SDES包中。八次中有七次会这样
成为名称的项目，每八（2分钟）它将是
电子邮件项目。
当多个应用程序使用交叉应用程序一致操作时
绑定通过一个共同的CNAME为每个参与者，例如在一个
由每个媒体的RTP会话组成的多媒体会议
额外的SDES信息只能在一个RTP会话中发送。该
其他会话将只携带CNAME项目。特别是这个
方法应该适用于分层的多个会话
编码方案（见第2.4节）。
发件人和收件人报告
RTP接收器使用RTCP报告提供接收质量反馈
根据是否可以采取两种形式之一的分组
接收者也是发件人。唯一的区别
发送者报告（SR）和接收者报告（RR）形式
类型代码，是发件人报告包含一个20字节的发件人
信息部分供主动发信人使用。如果一个
网站自发布以来已经发送了任何数据包
上次报告或上一次报告，否则发布“无线电规则”。
SR和RR格式都包含零个或多个接收报告
块，每个同步源一个这个
接收方自上次报告以来收到了RTP数据包。
报告不是针对中国证监会上市的来源
名单。每个接收报告块提供有关数据的统计信息
从该区块中指出的特定来源收到。由于a
最多31个接收报告块将适合SR或RR数据包，
额外的RR数据包应该在最初的SR或RR之后堆叠
数据包，以包含所有来源的接收报告
在上次报告以来的时间间隔内听到。如果也有
许多来源将所有必要的RR数据包合并到一个化合物中
RTCP数据包，不超过网络路径的MTU，那么只有
将适合一个MTU的子集应该包含在每个中
间隔。子集应该跨多个循环选择
以便报告所有来源。
接下来的部分将定义这两个报告的格式，它们可能如何
如果应用程序需要，可以以特定于配置文件的方式扩展
额外的反馈信息，以及如何使用这些报告。
译文和混音器的接收报告详情请参阅
第7节。
Schulzrinne等人 标准跟踪[第35页]
RFC 3550 RTP 2003年7月
SR：发送者报告RTCP分组
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
头| V = 2 | P | RC | PT = SR = 200 | 长度|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 发件人SSRC |
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
发件人| NTP时间戳，最重要的单词|
info + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| NTP时间戳，最低有效字|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| RTP时间戳|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 发件人的数据包数|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 发件人的八位字节计数|
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
报告| SSRC_1（SSRC第一来源）|
块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - +
1 | 分数损失| 累积的丢包数|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 扩展的最高序列号收到|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 到达间隔抖动|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 最后一个SR（LSR）|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 自上次SR（DLSR）|之后的延迟
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
报告| SSRC_2（第二来源SSRC）|
块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - +
2：...：
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
| 特定于文件的扩展|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
发送者报告包可能由三部分组成
如果定义了第四个特定于文件的扩展部分。
第一部分，标题长度是8个八位字节。田野有
以下含义：
版本（V）：2比特
标识RTP的版本，在RTCP数据包中是相同的
如在RTP数据包中一样。本规范定义的版本
是两（2）。
Schulzrinne等人 标准跟踪[第36页]
RFC 3550 RTP 2003年7月
填充（P）：1位
如果填充位被设置，则这个单独的RTCP分组包含
一些额外的填充八位字节在不是的一部分
控制信息但包含在长度字段中。该
填充的最后八位字节是多少个填充字节的计数
应该被忽略，包括它本身（这将是一个倍数
四）。某些加密算法可能需要填充
固定块大小。在一个复合RTCP数据包中，填充是唯一的
因为复合包是一个单独的包所需要的
加密作为一个整体的方法在9.1节。因此，填充
只能添加到最后一个单独的数据包，如果填充
被添加到该数据包中，填充位必须仅在该数据包上设置
包。这个约定有助于描述的头部有效性检查
在附录A.2中，允许从一些早期检测数据包
在第一个错误地设置填充位的实现
单独的数据包和添加填充到最后一个单独的数据包。
接收报告计数（RC）：5位
包中包含的接收报告块的数量。一个
零值是有效的。
分组类型（PT）：8比特
包含常量200以将其标识为RTCP SR数据包。
长度：16位
这个32位字的RTCP数据包的长度减1，
包括头和任何填充。（一个的偏移量
零有效长度并避免可能的无限循环
扫描复合RTCP数据包，同时计数32位字
避免了4的倍数的有效性检查。
SSRC：32位
这个发起者的同步源标识符
SR数据包。
第二部分，发件人信息，长度为20个八位字节
存在于每个发件人报告包中。它总结了这些数据
来自此发件人的传输。这些字段具有以下内容
含义：
NTP时间戳：64位本报告显示时
的时钟时间（请参阅第4节）
发送，以便它可以与时间戳结合使用
在接收报告中返回来自其他接收者的测量
往返传播给那些接收者。接收者应该
期望时间戳的测量准确性可能是
限于远低于NTP时间戳的分辨率。该
时间戳的测量不确定度不会被指示出来
Schulzrinne等人 标准跟踪[第37页]
RFC 3550 RTP 2003年7月
可能不知道。在一个没有wallclock概念的系统上
时间，但确实有一些系统特定的时钟，如“系统”
正常运行时间“，发件人可以使用该时钟作为参考来计算
相对NTP时间戳。一般选择一个是很重要的
使用时钟，以便如果使用单独的实现来生产
多媒体会话的各个流，全部
实现将使用相同的时钟。直到2036年，
相对和绝对时间戳会在高位有所不同
（无效）比较会显示出很大的差异; 那么一个
希望不再需要相对时间戳。发件人
没有挂钟或经过时间的概念可以设置NTP
时间戳为零。
RTP时间戳：32位
与上面的NTP时间戳同时对应，但是以
相同的单位和与RTP相同的随机偏移量
数据包中的时间戳。这个对应关系可以用于
媒体内和媒体间同步的NTP源
时间戳是同步的，并且可以由媒体独立使用
接收器来估计标称的RTP时钟频率。注意
在大多数情况下，这个时间戳不会等于RTP
时间戳在任何相邻的数据包中。相反，它必须是
从相应的NTP时间戳使用计算
RTP时间戳计数器和实时时间之间的关系
通过定期检查wallclock时间来维护
抽样即时。
发送者的包计数：32位
发送方发送的RTP数据包总数
因为直到这个SR数据包开始传输
产生。如果发件人更改其计数，计数应该被重置
SSRC标识符。
发送者的八位组数：32比特
有效载荷字节的总数（即不包括标题或
填充）由发送方自RTP发送的数据包
直到这个SR数据包开始传输
产生。如果发件人更改其计数，计数应该被重置
SSRC标识符。这个字段可以用来估计平均值
净荷数据速率。
第三部分包含零个或多个接收报告块
这取决于此发件人从其他来源收到的其他来源的数量
最后的报告。每个接收报告块传送统计信息
从单个同步源接收RTP数据包。
接收者不应该在源发生变化时进行统计
SSRC标识符由于碰撞。这些统计是：
Schulzrinne等人 标准跟踪[第38页]
RFC 3550 RTP 2003年7月
SSRC_n（源标识符）：32位
信息来源的SSRC标识符
接待报告块属于。
分数丢失：8位
自SSRC_n以来，RTP数据包的一部分丢失
先前的SR或RR包被发送，表示为固定点
编号与字段的左边缘的二进制点。（那
相当于乘以后的整数部分
损失分数除以256）。这个分数被定义为数字
丢失的数据包除以预期的数据包数量
在下一段定义。一个实现如图所示
附录A.3。如果由于重复造成的损失是负面的，那么
分数丢失被设置为零。请注意，一个接收器不能告诉
最后一个收到的包是否丢失
没有接收报告块的来源
如果来自该源的所有分组在上次报告期间发送
间隔已经丢失。
累计丢包数：24位
来自源SSRC_n的RTP数据包的总数
自接待开始以来已经失去。这个数字是
定义为数据包的数量少于预期的数量
实际收到的数据包，接收数据包的数量
包括任何迟到或重复。因此，数据包
迟到不计算在内，损失可能是负数
如果有重复。预期的数据包数量是
定义为收到的扩展的最后序列号，如
接下来定义，少于收到的初始序列号。这可能
按附录A.3所示进行计算。
扩展的最高序列号收到：32位
低16位包含在一个接收到的最高序列号
来自SSRC_n的RTP数据包，最重要的16个
位以相应的计数扩展该序列号
序列号周期，可以根据这个维护
算法见附录A.1。请注意，不同的接收器内
同一个会话将生成不同的扩展名
序列号，如果他们的开始时间差异显着。
到达间隔抖动：32位
RTP数据包统计方差的估计
到达间隔时间，以时间戳单位测量并表示为
无符号整数。间隔抖动J被定义为
差值D in的平均偏差（平滑的绝对值）
在接收端的数据包间隔与一对的发送端相比
的数据包。如下面的公式所示，这相当于
两个数据包的“相对传输时间”的差异;
Schulzrinne等人 标准跟踪[第39页]
RFC 3550 RTP 2003年7月
相对传输时间是数据包的RTP之间的差异
时间戳和到达时间的接收机时钟，
在相同的单位测量。
如果Si是数据包i的RTP时间戳，并且Ri是时间戳
到达分组i的RTP时间戳单元，然后是两个分组
我和j，D可以表示为
D（i，j）=（Rj-Ri） - （Sj-Si）=（Rj-Sj） - （Ri-Si）
到达间隔抖动应该连续计算
数据包i是从源SSRC_n接收的，使用它
该分组与前一个分组i-1的差值D
到达（不一定按顺序），根据公式
J（i）= J（i-1）+（| D（i-1，i）| - J（i-1））/ 16
每当接收报告发出时，J的当前值是
采样。
抖动计算必须符合这里指定的公式
以允许配置文件无关的监视器生效
对来自不同实施的报告的解释。
该算法是最优的一阶估计器和增益
参数1/16给出了一个很好的降噪比
保持合理的收敛速度[ 22 ]。一个样品
实现显示在附录A.8。参见6.4.4节的
讨论不同的数据包持续时间和延迟的影响
在传输之前。
最后一个SR时间戳（LSR）：32位
NTP时间戳中的64位中的中间32位（如中所述）
第4节）作为最新的RTCP发送者报告的一部分收到
（SR）数据包从源SSRC_n。如果尚未收到SR，
该字段设置为零。
自上次SR（DLSR）以来的延迟：32位
延迟时间以1/65536秒为单位表示
从源SSRC_n接收最后一个SR包并发送
接待报告块。如果还没有收到SR数据包
从SSRC_n，DLSR字段被设置为零。
让SSRC_r表示发送这个接收者报告的接收者。
源SSRC_n可以计算往返传播延迟
SSRC_r通过记录该接收报告块时的时间A.
接收。它使用的是计算总往返时间A-LSR
最后一个SR时间戳（LSR）字段，然后将该字段减去
（A-LSR-DLSR），将往返传播延迟留下。这个
Schulzrinne等人 标准跟踪[第40页]
RFC 3550 RTP 2003年7月
如图2所示。时间以十六进制显示
32位字段的表示和等效的浮点数
点十进制表示。冒号表示一个32位字段
分为16位整数部分和16位小数部分。
这可以用作距离群集的近似度量
接收器，尽管一些链路有非常不对称的延迟。
[1995年11月10日11：33：25.125 UTC] [1995年11月10日11：33：36.5 UTC]
n SR（n）A = b710：8000（46864.500 s）
-------------------------------------------------- -------------->
v ^
ntp_sec = 0xb44db705 v ^ dlsr = 0x0005：4000（5.250s）
ntp_frac = 0x20000000 v ^ lsr = 0xb705：2000（46853.125s）
（3024992005.125 s）v ^
rv ^ RR（n）
-------------------------------------------------- -------------->
| <-DLSR-> |
（5.250秒）
A 0xb710：8000（46864.500 s）
DLSR -0x0005：4000（5.250 s）
LSR -0xb705：2000（46853.125 s）
-------------------------------
延迟0x0006：2000（6.125秒）
图2：往返时间计算示例
Schulzrinne等人 标准跟踪[第41页]
RFC 3550 RTP 2003年7月
RR：接收者报告RTCP分组
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
头| V = 2 | P | RC | PT = RR = 201 | 长度|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 包发件人SSRC |
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
报告| SSRC_1（SSRC第一来源）|
块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - +
1 | 分数损失| 累积的丢包数|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 扩展的最高序列号收到|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 到达间隔抖动|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 最后一个SR（LSR）|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 自上次SR（DLSR）|之后的延迟
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
报告| SSRC_2（第二来源SSRC）|
块+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - +
2：...：
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
| 特定于文件的扩展|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
接收方报告（RR）报文的格式与
除了分组类型字段包含常量之外的SR分组
201和发件人信息的五个字被省略（这些是
NTP和RTP时间戳以及发送者的包和八位字节计数）。
其余字段与SR数据包的含义相同。
一个空的RR包（RC = 0）务必放在一个复合的头部
RTCP包没有数据传输或接收时
报告。
扩展发件人和收件人报告
配置文件应该为发件人定义配置文件特定的扩展名
报告和接收者报告，如果有额外的信息
需要定期报告发件人或收件人。这个
方法应该优先用于定义另一个RTCP数据包
键入，因为它需要较少的开销：
o数据包中较少的八位字节（没有RTCP头或SSRC字段）;
Schulzrinne等人 标准跟踪[第42页]
RFC 3550 RTP 2003年7月
更简单和更快速的解析，因为应用程序正在运行
配置文件将被编程为总是期望扩展字段
在接待报告后的直接访问地点。
分机是发信人或收信人报告中的第四部分
在接收报告阻塞之后到来的分组，如果
任何。如果需要额外的发件人信息，则发件人
报告它将首先包含在扩展部分，但是
接收者报告它不会出现。如果信息
接收者将被包括在内，那么数据应该被构造为一个
与现有接收报告阵列平行的块阵列
块; 即区块数目会由区域市政总署指明
领域。
分析发送者和接收者报告
预计接收质量反馈将不会有用
只适用于发件人，也适用于其他收件人和第三方
显示器。发件人可以根据其修改传输
反馈; 接收者可以确定问题是否是本地的，
区域或全球; 网络管理员可以使用配置文件无关
监视器只接收RTCP数据包，而不是相应的
RTP数据包来评估其网络的性能
组播分发。
累积计数用于发件人信息和
接收器报告块，以便可以计算差异
任何两份报告都可以在短期和长期内进行测量
期间，并提供抵御损失的报告。该
最近两次收到的报告之间的差异可以用来
估计最近的分配质量。NTP时间戳
被包括在内，以便可以从这些差异计算费率
在两个报告之间的间隔。由于时间戳是
独立于数据编码的时钟速率，这是可能的
实现编码和配置文件无关的质量监视器。
一个计算示例就是间隔内的丢包率
在两个接待报告之间。累积的差异
丢失的数据包数量会导致在该时间间隔内丢失的数字。
所收到的最后一个序列号的差异给出了
间隔期间预期的分组数量。的比例
这两个是间隔内的丢包率。这个比例
如果这两个报告是应该等于分数丢失的领域
连续的，但否则可能不会。每秒的损失率可以
通过将损失分数除以NTP的差值来获得
时间戳，以秒表示。收到的数据包的数量是
预期的分组数目减去丢失的数目。的数量
Schulzrinne等人 标准跟踪[第43页]
RFC 3550 RTP 2003年7月
预期的分组也可以用来判断统计有效性
的任何损失估计。例如，丢失的五个数据包中有一个有一个
比1000中的200低。
从发件人信息，第三方监视器可以计算出
平均有效载荷数据速率和平均数据包速率
间隔没有收到数据。以两者的比例
给出平均有效载荷大小。如果可以假设的话
丢失与数据包大小无关，然后是数据包数量
由特定接收机接收的平均有效负载大小（或
相应的分组大小）给出了表观吞吐量
可用于该接收器。
除了允许长期数据包的累积计数之外
使用报告之间的差异进行损失测量，分数
失去的领域提供一个单一报告的短期测量。
随着会议规模的扩大，这变得更加重要
接收状态信息可能不会保留给所有的接收者
或报告之间的时间间隔变得足够长，只有一个
报告可能是从一个特定的接收器收到的。
到达间隔抖动字段提供了第二个短期测量
网络拥塞。数据包丢失跟踪持续拥塞
抖动测量跟踪瞬态拥塞。抖动测量
可能会导致拥塞，导致数据包丢失。该
到达间隔抖动场只是抖动的一个快照
报告的时间，而不是定量的。
相反，它是用来比较来自多个报告的
一个接收器随着时间的推移或从多个接收器，例如，在一个
单一的网络，在同一时间。允许比较
接收机，重要的是抖动按照计算
所有接收器都使用相同的公式。
因为抖动计算是基于RTP时间戳的
表示分组中的第一个数据被采样的瞬间，
在采样时刻和时间之间的任何延迟的变化
数据包的传输将会影响抖动
计算。音频数据包会出现这种延迟的变化
持续时间不同 视频编码也会出现这种情况，因为
对于一个帧的所有分组，时间戳是相同的
数据包并不是全部同时传输。中的变化
延迟直到传输确实降低了抖动的准确度
计算作为网络本身的行为的度量，
但是考虑到接收缓冲区是合适的
必须适应它。当抖动计算被用作a
比较测量，由于变化的（恒定）分量
延迟，直到传输消失，使一个变化
Schulzrinne等人 标准跟踪[第44页]
RFC 3550 RTP 2003年7月
然后可以观察网络抖动分量，除非它是相对的
小。如果变化很小，那很可能是
无关紧要的。
SDES：源描述RTCP包
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
头| V = 2 | P | SC | PT = SDES = 202 | 长度|
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
大块| SSRC / CSRC_1 |
1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - +
| SDES项目|
| ... |
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
大块| SSRC / CSRC_2 |
2 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| SDES项目|
| ... |
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
SDES包是一个三层结构，由一个头部和一个头部组成
零或多个块，每个块都由描述的项目组成
在该块中标识的来源。这些项目被描述
分别在随后的部分。
版本（V），填充（P），长度：
如SR数据包所述（见第6.4.1节）。
分组类型（PT）：8比特
包含常量202以将其标识为RTCP SDES数据包。
源数（SC）：5位
包含在这个SDES包中的SSRC / CSRC块的数量。一个
零值是有效的，但是没用。
每个块由一个SSRC / CSRC标识符组成，后跟一个列表
零或多个项目，其中载有关于SSRC / CSRC的信息。
每个块在32位边界上开始。每个项目包括一个8-
位类型字段，一个8位八位字节计数描述的长度
文本（因此不包括这个双字节标题）和文本
本身。请注意，文本不能超过255个八位字节，但是
这与限制RTCP带宽消耗的需要是一致的。
Schulzrinne等人 标准跟踪[第45页]
RFC 3550 RTP 2003年7月
文本根据RFC
2279 [ 5 ]中规定的UTF-8编码进行编码。US-ASCII是这种编码的一个子集，不需要
额外的编码。多字节编码的存在是
通过设置一个字符的最重要的位来表示
价值之一。
项目是连续的，即项目不是单独填充到a
32位边界。文本不是空终止的，
八位字节编码包括空字节。每个块中的项目列表
必须由一个或多个空字节终止，其中第一个是
解释为零的项目类型以表示列表的结尾。
空项目类型八位字节之后没有长度字节，但是额外的空值
必须包括八位字节，直到下一个32位为止
边界。请注意，此填充与表示的填充是分开的
RTCP头中的P位。一个有零项的块（四个空值
八位字节）是有效的，但是没用。
终端系统发送一个包含自己的源的SDES数据包
标识符（与固定RTP报头中的SSRC相同）。搅拌机
发送包含每个贡献源的块的一个SDES包
从中收到SDES信息，或多个完整的
上述格式的SDES包如果有31个以上的话
来源（见第7节）。
目前定义的SDES项目将在下一节中介绍。
只有CNAME项是强制性的。这里显示的一些项目可能是
只对特定配置文件有用，但是项目类型是全部的
从一个共同的空间分配，以促进共享使用和简化
简介独立的应用程序。其他项目可能被定义在
通过在IANA中注册类型号码来进行配置文件的描述
第15节。
CNAME：规范的终点标识符SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| CNAME = 1 | 长度| 用户和域名...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
CNAME标识符具有以下属性：
o因为随机分配的SSRC标识符可能会改变，如果一个
发现冲突或者程序重新启动时，CNAME
必须包括项目以提供来自SSRC的绑定
标识符与源（发送者或接收者）的标识符
保持不变。
Schulzrinne等人 标准跟踪[第46页]
RFC 3550 RTP 2003年7月
o与SSRC标识符一样，CNAME标识符也应该是
在一个RTP会话中的所有参与者中是唯一的。
o提供跨多个媒体工具的绑定
参与一组相关的RTP会话，CNAME应该是
为该参与者固定。
o为了方便第三方监控，CNAME应该是合适的
无论是一个程序或一个人来定位来源。
因此，CNAME应该算法导出而不是
尽可能手动输入。为了满足这些要求，
应使用以下格式，除非配置文件指定了
备用语法或语义。CNAME项目应该有格式
如果用户名不可用，则为“user @ host”或“host”
用户系统。对于这两种格式，“主机”是完全合格的
实时数据来源主机的域名，
根据RFC 1034 [ 6 ]，RFC 1035
[ 7 ]和RFC 1123的第2.1节 [ 8 ]中规定的规则进行格式化; 或标准的ASCII
在所使用的接口上表示主机的数字地址
用于RTP通信。例如，标准的ASCII
IP版本4地址的表示也是“点分十进制”
称为虚线四，IP版本6，地址是文本
以冒号分隔的十六进制数字组（以
如RFC 3513 [ 23 ]中详述的变化）。其他地址类型是
希望具有相互独特的ASCII表示。该
完全合格的域名对于观察者来说更为方便
并且可以避免另外发送名称项目的需要，但是可能是这样
在一些操作中难以或不可能获得可靠的
环境。可能在这样的环境中运行的应用程序
应该使用地址的ASCII表示。
例子是“doe@sleepy.example.com”，“doe@192.0.2.89”或者
对于多用户系统，“doe @ 2201：056D :: 112E：144A：1E24”。在一个系统上
没有用户名，例子就是“sleepy.example.com”，
“192.0.2.89”或“2201：056D :: 112E：144A：1E24”。
用户名应当以“finger”之类的程序的形式存在
“谈话”可以使用，即它通常是登录名而不是
个人的名字。主机名不一定完全相同
一个在参与者的电子邮件地址中。
如果是，则此语法将不会为每个源提供唯一的标识符
应用程序允许用户从一个生成多个来源
主办。这样的申请将不得不依靠SSRC进一步
识别来源，或该应用程序的配置文件将具有
指定CNAME标识符的附加语法。
Schulzrinne等人 标准跟踪[第47页]
RFC 3550 RTP 2003年7月
如果每个应用程序独立创建其CNAME，则生成
CNAME可能与提供绑定所需的内容不同
跨多个属于一个参与者的媒体工具
相关的RTP会话。如果需要跨媒体绑定，则可能是
每个工具的CNAME需要外部配置
协调工具的价值是相同的。
应用程序编写者应该知道专用网络地址
例如RFC 1918 [ 24 ]中提出的Net-10分配，
可能会创建不是全球唯一的网络地址。这个
会导致非唯一的CNAME如果主机与私人地址和
没有直接的IP连接到公共互联网的RTP
数据包通过RTP级别转发到公共Internet
翻译。（另见RFC 1627 [ 25 ]。）为了处理这种情况，
应用程序可以提供一种手段来配置一个唯一的CNAME，但是
翻译人员将CNAME翻译成私人文件的负担
地址公共地址，如果有必要保持私人地址
从被暴露。
名称：用户名称SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| NAME = 2 | 长度| 通用名称的来源...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
这是用来形容来源的真实名称，例如“John Doe，
位再循环器“，它可以是用户想要的任何形式
会议等应用，这种形式的名称可能是最多的
希望在参与者列表中显示，因此可能是
最常发送CNAME以外的项目。配置文件可能
确定这样的重点。NAME值预计将保持不变
至少在会议期间不变。它不应该
依靠在本届会议的所有与会者中都是独一无二的。
电子邮件：电子邮件地址SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| EMAIL = 3 | 长度| 来源的电子邮件地址...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
电子邮件地址根据RFC 2822 [ 9 ] 格式化
例如，“John.Doe@example.com”。预计EMAIL值
在会议期间保持不变。
Schulzrinne等人 标准跟踪[第48页]
RFC 3550 RTP 2003年7月
PHONE：电话号码SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| PHONE = 4 | 长度| 电话号码的来源...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
电话号码应该用加号来代替格式
国际接入码。例如，“+1 908 555 1212”为一个
在美国的数字。
LOC：地理用户位置SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| LOC = 5 | 长度| 网站的地理位置...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
取决于应用程序，不同程度的细节
适合这个项目。对于会议应用程序，字符串
像“新泽西州美利山”可能就足够了，而对于一个
积极的徽章系统，像“房间2A244，AT＆T BL MH”可能是字符串
适当。细节的程度留给实施
和/或用户，但格式和内容可以由配置文件规定。
LOC值预计在a的持续时间内保持不变
会话，除了移动主机。
工具：应用程序或工具名称SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| TOOL = 6 | 源程序的长度|名称/版本。...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
一个字符串，提供应用程序的名称和可能的版本
生成流，例如“录像工具1.2”。这个信息可能
对于调试目的是有用的，并且类似于邮件程序或
邮件系统版本SMTP头。预计TOOL值
在会议期间保持不变。
Schulzrinne等人 标准跟踪[第49页]
RFC 3550 RTP 2003年7月
注意：通知/状态SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 注= 7 | 长度| 请注意有关来源...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
为这个项目建议以下语义，但这些或
其他语义可以由配置文件显式定义。笔记
项目用于描述当前状态的瞬态消息
的来源，例如“在电话中，不能说话”。或者，在一个
研讨会，这个项目可能被用来表达对话的标题。它
应该只用来携带特殊的信息，不应该
被所有参与者定期包括在内，因为这会慢
降低接收报告和CNAME发送的速率
损害协议的性能。特别是，它应该
不作为一个项目包含在用户的配置文件也不包括在内
自动生成，如今天的报价。
由于NOTE项目在激活时可能很重要，
其他非CNAME项目（如NAME）的传输速率
可能会减少，所以NOTE项可以占用RTCP的那部分
带宽。当瞬态消息变为无效时，注意
项目应该继续传送几次相同
重复率但用一串长度为零的信号来表示
接收器。但是，接收者也应该考虑注意项目
如果没有收到一小部分重复，则无效
速率，或者20-30 RTCP间隔。
PRIV：私有扩展SDES项目
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| PRIV = 8 | 长度| 前缀长度|前缀字符串...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
... | 值字符串...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
此项目用于定义实验或特定于应用程序的SDES
扩展。该项目包含由长度字符串组成的前缀
随后是填充项目其余部分的值字符串
并携带所需的信息。前缀长度字段是8
位长。前缀字符串是由人员定义的名称
该PRIV项目是独一无二的其他PRIV项目
应用可能会收到。应用程序创建者可能会选择
使用应用程序名称加上附加的子类型标识
Schulzrinne等人 标准跟踪[第50页]
RFC 3550 RTP 2003年7月
需要。或者，建议其他人选择一个名字
基于它们所代表的实体，然后协调使用
该实体内的名称。
请注意，前缀会消耗项目总数中的一些空间
长度为255个八位字节，所以前缀应该保持为短
可能。这个设施和受约束的RTCP带宽应该
不要超载; 并不是要满足所有的控制
所有应用程序的通信要求。
SDES PRIV前缀不会由IANA注册。如果某种形式的
PRIV项目被证明是通用的，它应该是
指定了一个定期的SDES项目类型在IANA注册，所以没有
前缀是必需的。这简化了使用并增加了传输
效率。
BYE：再见RTCP分组
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| V = 2 | P | SC | PT = BYE = 203 | 长度|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| SSRC / CSRC |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
：...：
+ = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = +
（opt）| 长度| 离开的原因 ...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
BYE数据包表示一个或多个源不再
活性。
版本（V），填充（P），长度：
如SR数据包所述（见第6.4.1节）。
分组类型（PT）：8比特
包含常量203以将其标识为RTCP BYE分组。
源数（SC）：5位
此BYE包中包含的SSRC / CSRC标识符的数量。
计数值为零是有效的，但是没用。
应该发送BYE包的规则在中指定6.3.7和8.2
节。
Schulzrinne等人 标准跟踪[第51页]
RFC 3550 RTP 2003年7月
如果BYE包被混频器接收到，混频器应该转发
具有SSRC / CSRC标识符的BYE分组不变。如果一台搅拌机
关闭，它应该发送一个BYE数据包列出所有的贡献
它处理的来源，以及它自己的SSRC标识符。（可选）
BYE包可能包含一个8位八位字节计数，然后是许多
指示离开原因的文本的八位字节，例如“相机”
故障“或”检测到RTP回路“，字符串相同
如SDES所描述的编码。如果字符串填充数据包
到下一个32位的边界，字符串不是空终止的。如果
不是，BYE包必须用空的八位字节填充到下一个32位字节，
位边界。该填充与P所示的填充是分开的
位在RTCP头。
APP：应用程序定义的RTCP数据包
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
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| V = 2 | P | 子类型| PT = APP = 204 | 长度|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| SSRC / CSRC |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 名称（ASCII）|
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| 应用程序依赖的数据...
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
APP数据包旨在作为新的应用程序的实验使用
并且开发了新的功能，而不需要包类型值
注册。具有无法识别名称的APP数据包应该被忽略。
经过测试，如果更广泛的使用是合理的，建议
每个APP包都被重新定义，而没有子类型和名称字段
使用RTCP数据包类型向IANA注册。
版本（V），填充（P），长度：
如SR数据包所述（见第6.4.1节）。
子类型：5位
可以用作子类型来允许一组APP数据包
在一个唯一的名称下定义，或者用于任何依赖于应用程序
数据。
分组类型（PT）：8比特
包含常量204以将其标识为RTCP APP分组。
Schulzrinne等人 标准跟踪[页52]
RFC 3550 RTP 2003年7月
名称：4个八位字节
定义一组APP数据包的人选择的名字
对于这个应用程序可能的其他APP数据包是唯一的
接收。应用程序创建者可能会选择使用
应用程序名称，然后协调子类型的分配
值给其他想要定义新数据包类型的人
应用。或者，建议其他人选择
基于它们所代表的实体的名称，然后协调使用
该实体内的名称。名字被解释为a
四个ASCII字符序列，大写和小写
被视为不同的字符。
应用程序相关数据：可变长度
应用程序相关的数据可能会或可能不会出现在APP数据包中。
它由应用程序解释，而不是RTP本身。它必须
是32位长的倍数。
。
除了终端系统之外，RTP还支持“翻译员”的概念，
和“搅拌机”，可以被视为“中间系统”
RTP级别。虽然这种支持增加了一些复杂性
议定书，对这些职能的需求已经明确确定
通过在多播音频和视频应用中的实验
互联网。第
2.3 节中给出的翻译器和混音器的使用例子来自防火墙和低带宽
连接，这两者都可能保持。
概述
RTP转换器/混频器连接两个或更多的传输级别
“云”。通常，每个云由一个公共网络定义
传输协议（如IP / UDP）加上一个多播地址和
传输级别目标端口或一对单播地址和
端口。（网络级协议翻译器，如IP版本4到
IP版本6，可能无法在RTP中呈现在云中）
系统可以作为多个RTP的翻译器或混音器
会议，但每个会议都被视为一个逻辑上独立的实体。
为了避免在翻译器或混音器时产生循环
安装，必须遵守以下规则：
o由翻译器和混音器连接的每个云
参与一个RTP会话必须与所有的不同
至少其中一个参数（协议，地址，
端口），或者必须与其他网络隔离。
Schulzrinne等人 标准跟踪[第53页]
RFC 3550 RTP 2003年7月
o第一条规则的衍生物不能是多重的
翻译器或混音器并联，除非有一些
他们安排他们划分要转发的来源的集合。
同样，所有可以通过一个或多个通信进行通信的RTP终端系统
更多的RTP转换器或混音器共享相同的SSRC空间，也就是说，
所有这些终端系统中的SSRC标识符必须是唯一的。
8.2节描述了由哪个碰撞解决算法
SSRC标识符保持唯一，并检测到循环。
可能有许多品种的翻译和搅拌机设计
不同的目的和应用。一些例子是添加或
删除加密，更改数据或底层的编码
协议，或在多播地址和一个或多个地址之间复制
单播地址。译员和混音师之间的区别是
翻译者通过不同的数据流
分别来源，而混音器结合起来，形成一个新的
流：
转换器：使用SSRC标识符转发RTP数据包
完整; 这使接收机能够识别
即使来自所有来源的数据包通过
通过同一位译者并携带翻译者的网络
源地址。有些翻译会通过翻译
数据不变，但其他人可能会改变数据的编码
因此RTP数据净荷类型和时间戳。如果有多个数据
数据包被重新编码为一个，反之亦然，一个翻译器必须
分配新的序列号到传出的数据包。损失
传入的分组流可能引起相应的间隙
传出序号。接收器无法检测到存在
除非他们通过其他手段知道什么有效载荷
类型或传输地址被原始源使用。
混音器：接收来自一个或多个RTP数据包的流
来源，可能会改变数据格式，合并流入
以某种方式，然后转发组合的流。自从
多个输入源之间的时序通常不会
同步，调音台之间会进行定时调节
并为合并流生成自己的时间，所以它
是同步源。因此，所有的数据包转发
由混频器必须标记混频器自己的SSRC标识符。
为了保留原始来源的身份
有助于混合包，搅拌机应该插入他们的
SSRC标识符进入CSRC标识符列表后的固定
数据包的RTP头。搅拌机也是自己的
某些数据包的贡献源应该明确地包含它
在该CSRC列表中拥有SSRC标识符。
Schulzrinne等人 标准跟踪[第54页]
RFC 3550 RTP 2003年7月
对于某些应用来说，混音器可能不被接受
确定中国证监会名单上的来源。不过，这个介绍了
涉及这些来源的循环的危险无法被发现。
一个混音器的优点，而不是翻译器的应用程序
音频是输出带宽被限制到一个源的输出带宽
即使在输入端有多个源是活动的。这可能是
对于低带宽链路很重要。缺点是这样的
输出端的接收器不能控制哪个接收器
来源是通过或静音，除非有一些机制
实施用于调音台的远程控制。再生的
混音器的同步信息也意味着接收器不能
做原始流的媒体间同步。多层次
媒体混音器可以做到。
[ E1 ] [E6]
| |
E1：17 | E6：15 |
| | E6：15
V M1：48（1,17）M1：48（1,17）V M1：48（1,17）
（M1）-------------> <T1> -----------------> <T2> --------- -----> [E7]
^ ^ E4：47 ^ E4：47
E2：1 | E4：47 | | M3：89（64,45）
| | |
[E2] [E4] M3：89（64,45）|
| 传说：
[E3] --------->（M2）----------->（M3）------------ | [结束系统]
E3：64M2:12（64）^（混合器）
| E5：45 <译者>
|
[E5]来源：SSRC（中国证监会）
------------------->
图3：带终端系统，混音器和转换器的示例RTP网络
混合器和翻译器的集合如图3所示
说明它们对SSRC和CSRC标识符的影响。在图中，
最终系统显示为矩形（名为E），译者为
三角形（名为T）和混合器（椭圆形）（名为M）。符号“M1：
48（1,17）“表示发起混频器M1的数据包，由标识
M1的（随机）SSRC值48和两个CSRC标识符1和17，
从E1和E2的分组的SSRC标识符中复制。
翻译器中的RTCP处理
除了转发数据包，也许是修改过的翻译
混音器也必须处理RTCP数据包。在很多情况下，他们会
把从终端系统接收到的复合RTCP分组拆开
Schulzrinne等人 标准跟踪[第55页]
RFC 3550 RTP 2003年7月
聚合SDES信息并修改SR或RR数据包。
该信息的重传可以由分组触发
到达或通过翻译器或混音器的RTCP间隔定时器
本身。
不修改数据包的翻译器，例如一个
只是在多播地址和单播之间进行复制
地址，也可以简单地转发RTCP数据包。一个
翻译器以某种方式转换有效载荷必须做出
在SR和RR信息中进行相应的转换使之成为可能
仍然反映了数据和接待的特点
质量。这些转换器不能简单地转发RTCP数据包。在
一般来说，翻译者不应该从中聚合SR和RR数据包
不同的来源到一个数据包，因为这会减少
基于LSR和LSR的传播时延测量精度
DLSR字段。
SR发件人信息：译员不会自行生成
发送者信息，但转发从一个接收到的SR数据包
云对其他人。SSRC保持不变，但发件人
如果翻译需要，信息必须修改。如果一个
翻译者改变数据编码，它必须改变“发件人的
字节计数“字段，如果它也将几个数据包合并成的话
一个输出包，它必须改变“发送者的包计数”
领域。如果它改变时间戳频率，它必须改变
SR包中的“RTP时间戳”字段。
SR / RR接收报告块：转换器转发接收
从一个云收到的报告给其他人。请注意这些
流向与数据相反的方向。SSRC离开了
完整。如果一个翻译器将多个数据包合并为一个
输出数据包，因此改变序列号，它必须
对数据包丢失字段进行逆操作
“扩展的最后序号”字段。这可能是复杂的。在
极端的情况下，可能没有有意义的翻译方式了
接待报告，所以翻译可能没有接收
根据自己的接待报告或综合报告。
一般的规则是做一些有意义的事情
翻译。
翻译者不需要自己的SSRC标识符，但是
可以选择分配一个用于发送报告
关于它收到了什么。这些将被发送到所有的
连接云，每个对应的翻译
数据流发送到该云，因为接收报告
通常多播给所有参与者。
Schulzrinne等人 标准跟踪[第56页]
RFC 3550 RTP 2003年7月
SDES：翻译者通常在不改变SDES的情况下转发
他们收到的信息从一个云到另一个，但可能，
例如，如果决定过滤非CNAME SDES信息
带宽有限。CNAME必须被转发以允许SSRC
标识符碰撞检测工作。一位翻译
生成自己的RR数据包必须发送SDES CNAME信息
关于它自己到相同的云发送那些RR数据包。
BYE：转换器转发BYE数据包不变。翻译者
即将停止转发数据包应发送BYE数据包
到包含所有SSRC标识符的每个连接的云
以前被转发到那个云，包括
翻译者自己的SSRC标识符，如果它发送自己的报告。
APP：翻译器转发APP数据包不变。
混音器中的RTCP处理
由于混音器自己产生一个新的数据流，所以没有
通过SR或RR数据包，而不是产生新的
双方信息。
SR发送者信息：调音台不通过发送者
来自它所混合的来源的信息，因为这些特征
的源流在混合中丢失。作为同步
源，混频器应该与发送者生成自己的SR数据包
有关混合数据流的信息并将其发送到相同的位置
方向作为混合流。
SR / RR接收报告块：一个混频器产生它自己的
接收每个云中源的报告并将其发送出去
只对同一个云。它不能发送这些接收报告
到其他云端，不得转发接收报告
一个云，因为来源不会是SSRC
那里（只有中国证监会）。
SDES：搅拌机通常在没有改变SDES的情况下前进
他们收到的信息从一个云到另一个，但可能，
例如，如果决定过滤非CNAME SDES信息
带宽有限。CNAME必须被转发以允许SSRC
标识符碰撞检测工作。（中国证监会的一个标识符
由混频器生成的列表可能与SSRC标识符冲突
由一个终端系统生成）。混音器必须发送SDES CNAME
关于它自己的信息到它发送SR或RR的相同的云
数据包。
Schulzrinne等人 标准跟踪[第57页]
RFC 3550 RTP 2003年7月
由于混频器不转发SR或RR数据包，它们通常会
从复合RTCP数据包中提取SDES数据包。至
尽量减少开销，可以聚合来自SDES分组的块
转换成单个SDES分组，然后将其堆叠在SR或RR上
来自混音器的数据包。一个混合器，聚合SDES
数据包将使用比单个源更多的RTCP带宽
因为复合包将会更长，但是
因为混合器代表多个来源。
类似地，一个混合器按原样穿过SDES包
收到的将会传输高于RTCP的数据包
单一来源的速率，但是这也是正确的，因为数据包
来自多个来源。RTCP数据包速率可能不同
在搅拌机的每一边。
不插入CSRC标识符的混音器也可以不做
从转发SDES CNAMEs。在这种情况下，SSRC标识符
两个云中的空间是独立的。如前面提到的，
这种操作模式会产生循环不能的危险
检测。
BYE：混音器必须转发BYE数据包。一个即将到来的混音器
停止转发数据包应该向每个发送一个BYE数据包
所连接的云包含所有的SSRC标识符
以前被转发到该云，包括混音器
如果它发送自己的报告，则拥有SSRC标识符。
APP：通过混音器处理APP数据包是特定于应用程序的。
级联搅拌机
RTP会话可能涉及一系列混音器和翻译器
如图3所示。如果两个混频器级联，如M2和M3中
这个数字，混音器收到的数据包可能已经混合在一起了
并且可以包括具有多个标识符的CSRC列表。第二
调音台应该建立传出的数据包使用CSRC列表
来自已经混合的输入数据包和SSRC的CSRC标识符
标识符来自未混合的输入数据包。这在输出中显示
来自M3中标记为M3：89（64,45）的混频器M3。正如在这种情况下
如果由此产生的CSRC清单有更多，则不会级联
超过15个标识符，其余不能包含在内。
Schulzrinne等人 标准跟踪[页码58]
RFC 3550 RTP 2003年7月
。
在RTP头和各个字段中携带的SSRC标识符
的RTCP数据包是一个随机的32位数字是必需的
在RTP会话中是全球唯一的。这个数字是至关重要的
请慎重选择，以便参与者在同一个网络上
同时开始不可能选择相同的号码。
这是不足以使用本地网络地址（如一个
IPv4地址）作为标识符，因为地址可能不是
独特。由于RTP转换器和混音器能够实现互操作
具有不同地址空间的多个网络，分配
在两个空间内的地址模式可能会导致很多
与随机分配相比，更高的碰撞率。
在一台主机上运行的多个源也会发生冲突。
简单地通过获得SSRC标识符也是不够的
调用random（）而不仔细初始化状态。一个
介绍如何生成一个随机标识符的例子
附录A.6。
碰撞的可能性
由于标识符是随机选择的，所以有可能是两个或者两个
更多的来源将选择相同的号码。碰撞发生了
所有来源同时开始的最高概率
例如某些会话管理自动触发
事件。如果N是来源的数量和L的长度
标识符（这里是32位），两个来源的概率
独立选取相同的值可以近似为大N
[ 26 ]如1 - EXP（-N **2分之2**（L + 1））。对于N = 1000，概率是
大约10 ** - 4。
典型的碰撞概率远低于最坏的情况
以上。当一个新的源加入一个RTP会话时，
其他来源已经有唯一的标识符的概率
碰撞只是空间中使用的数字的一小部分。
再次，如果N是来源的数量和L的长度
标识符，碰撞的概率是N / 2 ** L。对于N = 1000，
概率大概是2 * 10 ** - 7。
机会进一步减少了碰撞的可能性
用于接收来自其他参与者的数据包的新来源
发送它的第一个数据包（数据或控制）。如果新来源
跟踪其他参与者（通过SSRC标识符），然后
Schulzrinne等人 标准跟踪[第59页]
RFC 3550 RTP 2003年7月
在发送第一个数据包之前，新的源可以验证
它的标识符不会与任何已经收到的相冲突，或者
否则再选择。
碰撞分辨率和回路检测
尽管SSRC标识符冲突的概率很低，但所有的RTP
实现必须准备好检测碰撞并采取行动
采取适当的行动来解决它们 如果一个来源发现任何
另一个来源正在使用与其相同的SSRC标识符
自己，它必须发送一个RTCP BYE包的旧标识符和
选择另一个随机的。（如下所述，这一步是采取的
只有一次，如果一个循环。）如果一个接收器发现了另外两个
来源正在冲突，它可以保持来自一个和丢弃的数据包
来自其他的数据包时，这可以被检测到不同的
源传输地址或CNAME。预计这两个来源
解决冲突，使情况不会持续下去。
因为随机的SSRC标识符是全局唯一的
RTP会话，它们也可以用来检测可能的循环
由混音师或翻译员介绍。循环导致重复
数据和控制信息，无论是未修改的还是可能的混合的
在下面的例子中：
o转换器可能会错误地将数据包转发到相同的地方
从中接收到数据包的多播组
直接或通过一连串的翻译。在这种情况下，
相同的数据包出现几次，源自不同
网络来源。
o两名译员错误地并行设置，即与
两边相同的组播组都会转发报文
从一个多播组到另一个多播组。单向翻译器
会产生两份; 双向翻译将形成一个
循环。
o调音台可以通过发送到相同的传输器来关闭一个循环
直接或间接接收数据包的目的地
通过另一个混音器或翻译器。在这种情况下，一个来源可能
在一个数据包和一个混合的CSRC中都显示SSRC
数据包。
源可能会发现它自己的数据包正在循环，或者
来自另一个来源的数据包正在循环（第三方循环）。
循环和碰撞在随机选择一个源
标识符导致分组以相同的SSRC标识符到达
但是一个不同的源码传输地址，可能是这个地址的
终端系统始发数据包或中间系统。
Schulzrinne等人 标准跟踪[页码60]
RFC 3550 RTP 2003年7月
因此，如果源更改其源传输地址，则可能
也选择一个新的SSRC标识符，以避免被解释为一个
循环的来源。（这不是必须的，因为在RTP的一些应用中
来源可能会在会议期间改变地址。）注意
如果翻译者重新启动并因此改变源
传输地址（例如，更改UDP源端口号）
它转发数据包，然后所有这些数据包将出现在接收者
由于SSRC标识符是由原始的应用而被循环的
来源并不会改变。保持这个问题是可以避免的
在重新启动时固定的源传输地址，但无论如何
将在接收器超时后解决。
在翻译者或者翻译者的另一边出现循环或者碰撞
如果全部使用源传输地址，则不能检测到混频器
数据包的副本通过翻译器或混音器，但是，
当来自两个RTCP SDES的块时仍可能检测到冲突
数据包包含相同的SSRC标识符但不同的CNAME。
为了检测和解决这些冲突，一个RTP实现必须
包括一个类似于下面描述的算法，虽然
实现可以选择一个不同的包来自哪个策略
相冲突的第三方来源保存。所描述的算法
下面忽略来自与源相冲突的新源或循环的数据包
确定来源。它解决了与参与者的冲突
通过为旧的标识符发送一个RTCP BYE来拥有SSRC标识符
选择一个新的。但是，当碰撞被诱导时
循环参与者自己的数据包，算法将选择一个
新的标识符只有一次，然后忽略数据包
循环源传输地址。这是为了避免洪水
的BYE数据包。
这个算法需要保留一个由源索引的表
标识符并包含源传输地址
第一RTP分组和用该标识符接收的第一RTCP分组，
连同其他国家的来源。两源运输
因为例如UDP源端口，所以需要地址
RTP和RTCP数据包的号码可能不同。但是，它可能是
假定两个源传输中的网络地址是相同的
地址。
在RTP或RTCP包中收到的每个SSRC或CSRC标识符是
在源标识符表中查找，以便处理它
数据或控制信息。源传输地址
数据包与中对应的源传输地址进行比较
该表检测循环或碰撞，如果他们不匹配。对于
控制数据包，每个元素都有自己的SSRC标识符
例如SDES块，需要单独的查找。（SSRC
接收报告块中的标识符是一个例外，因为它
Schulzrinne等人 标准跟踪[页码61]
RFC 3550 RTP 2003年7月
确定了记者听到的来源，以及SSRC标识符
与发送的RTCP数据包的源传输地址无关
由记者。）如果SSRC或证监会没有找到，一个新的条目是
创建。这些表项在RTCP BYE包被删除时被删除
接收到相应的SSRC标识符并经过验证
匹配源传输地址，或在没有数据包到达之后
相对较长时间（见第6.2.1节）。
请注意，如果同一主机上的两个信号源正在传输
在接收机开始操作时，它是相同的源标识符
将有可能收到的第一个RTP包来自其中一个
第一个RTCP数据包收到来自另一个来源。
这会导致错误的RTCP信息与
RTP数据，但是这种情况应该足够罕见和无害
这可能会被忽视。
为了跟踪参与者自己的数据包的循环，
实现也必须保留一个单独的源码传输列表
地址（而不是标识符）已经被发现有冲突。
如源标识符表中那样，有两个源传输地址
务必保持分开跟踪冲突的RTP和RTCP数据包。
请注意，冲突的地址列表通常应该很短
空。此列表中的每个元素都存储源地址加
接收到最近冲突的数据包的时间。一个
元素可以在没有冲突的分组时从列表中移除
10 RTCP报告的顺序来自该来源一段时间
间隔（见第6.2节）。
对于所示的算法，假定参与者自己的
源标识符和状态被包括在源标识符中
表。该算法可以重构，首先做一个单独的
与参与者自己的源标识符进行比较。
如果（SSRC或CSRC标识符未在源中找到
标识符表）{
创建一个存储数据或控制源的新条目
运输地址，SSRC或者CSRC等国家;
}
/ *标识符在表格中找到* /
否则如果（表项是在收到控制包时创建的
这是第一个数据包，反之亦然）{
从这个包中存储源传输地址;
}
否则如果（来自数据包的源传输地址不匹配
保存在这个标识符的表项中的那个）{
Schulzrinne等人 标准跟踪[第62页]
RFC 3550 RTP 2003年7月
/ *标识符冲突或循环被指示* /
如果（源标识符不是参与者自己的）{
/ *可选的错误计数器步骤* /
如果（源标识符来自RTCP SDES块
包含与CNAME不同的CNAME项目
在表格中）{
计算第三方碰撞;
} else {
统计第三方循环;
}
中止数据包或控制元素的处理;
/ *可以选择不同的政策来保持新的来源* /
}
/ *参与者自己的数据包的冲突或循环* /
否则如果（源传输地址在列表中找到
冲突的数据或控制源传输
地址）{
/ *可选的错误计数器步骤* /
如果（源标识符不是来自RTCP SDES块
包含一个CNAME项目或CNAME是
参与者自己的）{
统计自己的交通事件的发生;
}
在冲突的地址列表条目中标记当前时间;
中止数据包或控制元素的处理;
}
/ *新的碰撞，更改SSRC标识符* /
else {
日志发生碰撞;
在冲突的数据或控件中创建一个新条目
源传输地址列表并标记当前时间;
用旧的SSRC标识符发送一个RTCP BYE包;
选择一个新的SSRC标识符;
在源标识符表中创建一个新条目
旧的SSRC加上源传输地址
正在处理的数据或控制分组;
}
}
在这个算法中，来自新冲突的源地址的数据包
将被忽略，并且来自原始源地址的分组将被忽略
保持。如果没有数据包从原始源到达扩展
期间，表格条目将被超时并且新的来源将是
Schulzrinne等人 标准跟踪[页63]
RFC 3550 RTP 2003年7月
能够接管。如果原始来源检测到这可能会发生
碰撞和移动到一个新的源标识符，但在平时
如果一个RTCP BYE包将从原始源接收到
删除状态而不必等待超时。
如果通过混音器接收到原始源地址（即，
作为中国证监会学习），后来直接收到同一来源，
建议接收方切换到新的源地址
除非混合中的其他来源将会丢失。而且，因为
诸如移动电话之类的应用，诸如电话
实体可能会在RTP会话过程中更改地址，
RTP实现应该修改碰撞检测
算法来接受来自新源传输地址的分组。
为了防止地址之间的翻转如果真的
碰撞确实发生，算法应该包括一些手段
检测到这种情况并避免切换。
当由于碰撞而选择新的SSRC标识符时，
候选人标识符应首先在源代码中查找
标识符表来查看它是否已经被其他人使用
资源。如果是这样，则必须生成另一个候选者和过程
重复。
数据包到组播目的地的循环会导致严重
网络泛滥。所有的混音器和转换器必须执行一个循环
像这样的检测算法，以便它们可以打破循环。
这应该限制多余的流量不超过一个重复
原始流量的副本，这可能会让会话继续
这样可以找到并修复循环的原因。但是，在
极端的情况下，混音器或翻译不能正确地打破
循环和高流量水平的结果，可能是必要的
系统完全停止传输数据或控制数据包。这个
决定可能取决于应用程序。一个错误条件应该
应适当表明。传输可能会再次尝试
定期在一个漫长的随机时间之后（大约几分钟）。
使用分层编码
对于在单独的RTP会话中传输的分层编码（请参阅
第2.4节），一个单一的SSRC标识符空间应该被使用
应该使用所有图层和核心（基础）层的会话
用于SSRC标识符分配和冲突解决。当一个
源发现它已经发生了冲突，它发送一个RTCP BYE
数据包仅在基本层上，但将SSRC标识符更改为
所有层面的新价值。
Schulzrinne等人 标准跟踪[页码64]
RFC 3550 RTP 2003年7月
。
低层协议可能最终提供所有的安全性
包括RTP应用程序可能需要的服务
认证，完整性和机密性。这些服务有
在[ 27 ]中被指定为IP 。自从最初的音频和视频
在此之前，使用RTP的应用程序需要保密服务
服务可用于IP层，保密服务
在下一节中描述的被定义为与RTP和RTCP一起使用。
这里的描述包含在现有的实践中。新
RTP的应用可以实现这个RTP特有的机密性
为了向后兼容服务，和/或他们可以实现
替代安全服务。在RTP协议上的开销
这个保密服务是低的，所以罚款将是最小的
如果这个服务将来被其他服务所淘汰。
或者，其他服务，服务的其他实现
其他算法可能在未来为RTP定义。在
特别是一个名为安全实时传输协议的RTP配置文件
（SRTP）[ 28 ]正在开发中，以提供RTP的机密性
有效载荷，同时使RTP头部保持清晰，以便链路级别
头压缩算法仍然可以运行。预计
SRTP将是许多应用程序的正确选择。SRTP是基于的
在高级加密标准（AES）和提供更强大的
安全性比这里描述的服务。没有人声称是
这里介绍的方法适用于特定的安全性
需要。配置文件可以指定哪些服务和算法应该是
由应用程序提供，并可能为其提供指导
适当的使用。
密钥分发和证书不在此范围之内
文件。
保密
机密性意味着只有预期的接收机才能解码
接收到的数据包; 对于其他人来说，数据包没有用处
信息。内容的保密性是通过
加密。
当需要根据该方法对RTP或RTCP进行加密时
在本节中指定，将被封装的所有八位字节
在一个单一的低层数据包传输作为一个加密
单元。对于RTCP，必须为每个单元重新绘制一个32位的随机数
在加密之前添加到本机。对于RTP，没有前缀
前置; 而是序列号和时间戳字段
用随机偏移初始化。这被认为是一个弱点
Schulzrinne等人 标准跟踪[第65页]
RFC 3550 RTP 2003年7月
初始化矢量（IV）由于随机性较差。在
此外，如果后来的领域，SSRC，可以被操纵
敌人，加密方法还有进一步的弱点。
对于RTCP，一个实现可以分离单独的RTCP数据包
在一个复合RTCP包中分成两个独立的复合RTCP包，
一个要加密，一个要明文发送。例如，
接收报告发送时，SDES信息可能会被加密
明确地容纳不知道的第三方监视器
到加密密钥。在这个例子中，如图4所示，SDES
信息必须附加到没有报告的RR数据包（和
随机数）来满足所有复合RTCP的要求
数据包以SR或RR数据包开始。SDES CNAME项目是
需要在加密或未加密的数据包中，但不能同时使用。
相同的SDES信息不应该被携带在两个数据包中
这可能会危及加密。
UDP数据包UDP数据包
----------------------------- --------------------- ---------
[random] [RR] [SDES #CNAME ...] [SR #senderinfo＃site1＃site2]
----------------------------- --------------------- ---------
加密不加密
＃：SSRC标识符
图4：加密和未加密的RTCP数据包
加密的存在和使用正确的密钥是
由接收器通过报头或有效载荷有效性检查来确认。
给出了RTP和RTCP头的这种有效性检查的例子
在附录A.1和A.2中。
与现有的初始实现一致
在RFC 1889中规定了RTP ，默认的加密算法是
数据加密标准（DES）算法在密码块链中
（CBC）模式，如RFC 1423 [ 29 ] 第1.1节所述，除了
填充到8个八位字节的倍数如P所述
位于5.1节。初始化矢量因为随机而为零
值在RTP头部或由随机前缀提供
复合RTCP分组。有关使用CBC初始化的详细信息
载体，参见[ 30 ]。
支持这里指定的加密方法的实现
应该始终支持CBC模式下的DES算法作为默认值
密码为这个方法最大化互操作性。这个方法是
因为它已被证明是简单实用的
用于实验音频和视频工具的操作上
互联网。然而，从那以后，DES被发现太容易被破坏。
Schulzrinne等人 标准跟踪[页码66]
RFC 3550 RTP 2003年7月
推荐使用更强的加密算法，如
使用Triple-DES代替默认算法。此外，
安全的CBC模式要求每个数据包的第一个块被异或
与密码块大小相同的随机独立IV
尺寸。对于RTCP，这是（部分）通过预先分配来实现的
数据包与一个32位随机数，每个独立选择
包。对于RTP，时间戳和序列号从随机开始
值，但连续的数据包不会被独立随机化。
应该指出，在这两种情况下的随机性（RTP和RTCP）
是有限的。高安全性的应用程序应该考虑其他，更多
常规，保护手段。其他加密算法可以
通过非RTP方式为会话动态指定。尤其是，基于AES
的SRTP协议[ 28 ]正在开发中
帐户已知的明文和CBC明文操作的担忧，和
将是未来的正确选择。
作为IP级别或RTP级别加密的替代方案
如上所述，配置文件可以定义额外的有效载荷类型
加密的编码。这些编码必须指定如何填充和
加密的其他方面将被处理。这种方法
允许只加密数据，同时保留头文件
在需要的地方清除应用程序。这可能是特别的
有用的硬件设备，将处理解密和
解码。这对链接级别的应用程序也很有价值
RTP和下层头部的压缩是期望的
有效载荷的机密性（但不是地址）就足够了
因为标题的加密排除了压缩。
身份验证和消息完整性
身份验证和消息完整性服务没有定义在
RTP级别，因为这些服务没有没有直接的可行性
关键的管理基础设施 预计认证
完整性服务将由低层协议提供。
。
Internet上使用的所有传输协议都需要解决
拥塞控制在某种程度上[ 31 ]。RTP不是例外，但是
因为通过RTP传输的数据通常是非弹性的（生成的
以固定或控制的速度），控制拥堵的手段
RTP可能与其他传输协议的RTP很不相同
如TCP。从某种意义上说，非弹性降低了风险
拥塞，因为RTP流不会扩展到消耗全部
可用带宽作为TCP流可以。但是，也是非弹性的
意味着RTP流不能任意减少其负载
网络在发生拥塞时消除。
Schulzrinne等人 标准跟踪[第67页]
RFC 3550 RTP 2003年7月
由于RTP可能在许多应用中被广泛使用
不同的上下文，没有单一的拥塞控制机制
这将为所有人工作。所以拥塞控制应该是
在每个RTP配置文件中定义。对于一些配置文件，它
可能足以包含适用性声明的限制
将该配置文件用于避免拥塞的环境
通过工程。对于其他配置文件，具体方法如数据
可能需要基于RTCP反馈的速率适配。
。
本部分描述了在内部携带RTP数据包的具体问题
特定的网络和传输协议。以下规则
除非在此之外被特定于协议的定义取代
规范。
RTP依赖底层协议来提供多路分解
RTP数据和RTCP控制流。对于UDP和类似的协议，
RTP应该使用一个偶数目的端口号和相应的
RTCP流应该使用下一个更高（奇数）的目的端口号。
对于将单个端口号作为参数的应用程序和
如果是奇数，则从该数字派生RTP和RTCP端口对
被提供，那么应用程序应该用该替换该数字
下一个较低（偶数）作为端口对的基础。对于
RTP和RTCP目标端口号的应用程序
通过明确的，单独的参数指定（使用信令
协议或其他方式），应用程序可能会忽略
限制端口号是偶数/连续的
尽管使用偶数/奇数端口对仍然受到鼓励。该
RTP和RTCP端口号不能相同，因为RTP依赖
用于解复用RTP数据和RTCP控制的端口号
流。
在单播会话中，两个参与者都需要识别一个端口对
用于接收RTP和RTCP数据包。两位参与者都可以使用
相同的端口对。参与者不得假定源端口
传入的RTP或RTCP数据包可以用作目的地
端口用于传出RTP或RTCP数据包。当RTP数据包是
在两个方向发送，每个参与者的RTCP SR数据包
必须发送到其他参与者指定的端口
接收RTCP。RTCP SR数据包组合了发送者信息
为传出数据加接收报告信息
传入数据。如果一方不主动发送数据（见第
6.4 节），则发送一个RTCP RR数据包。
建议分层编码应用程序（见第
2.4 节）使用一组连续的端口号。端口号必须是
由于现有经营中普遍存在的缺陷而显着
Schulzrinne等人 标准跟踪[页码68]
RFC 3550 RTP 2003年7月
阻止使用同一个端口与多个多播的系统
地址，而对于单播，只有一个允许的地址。
因此，对于层n，数据端口是P + 2n，控制端口是P
+ 2n + 1。当使用IP多播时，地址必须也是
因组播路由和组成员资格被管理而不同
在地址粒度。但是，分配连续的IP
多播地址不能被假定，因为一些组可能需要
不同的范围，因此可以从不同的分配
地址范围。
前一段与SDP规范（RFC 2327
[ 15 ]）冲突，该规范说明多个地址和多个地址都是非法的
在同一会话描述中指定多个端口
因为地址与端口的关联可能是模糊的。
这个限制的目的是在修改版本时放宽
RFC 2327允许相同数量的地址和端口
隐含的一对一映射指定。
RTP数据包不包含长度字段或其他描述，
因此RTP依赖底层协议来提供一个
长度指示。RTP包的最大长度是有限的
由底层协议。
如果RTP数据包将被携带在一个底层协议中
提供了连续八位字节流的抽象，而不是
消息（数据包），RTP数据包的封装必须是
定义为提供一个框架机制。如果还需要构筑
底层的协议可能会包含填充以便扩展的范围
RTP负载无法确定。框架机制不是
这里定义。
配置文件可以指定即使在RTP时也使用的成帧方法
进行协议，提供框架，以便允许
在一个低层协议数据单元中携带几个RTP分组，
如UDP数据包。在一个网络或者一个网络中携带几个RTP数据包
传输分组减少了头部开销并且可以简化
不同流之间的同步。
。
本部分包含在中定义的常量的总结列表
这个规范。
RTP负载类型（PT）常量在配置文件中定义
比这个文件。但是，RTP头的八位字节是哪个
包含标记位和有效载荷类型务必避免保留
值200和201（十进制）来区分来自RTCP的RTP数据包
用于所描述的头部验证过程的SR和RR分组类型
Schulzrinne等人 标准跟踪[页码69]
RFC 3550 RTP 2003年7月
在附录A.1。对于一个标记位和a的标准定义
7位有效载荷类型字段，如本规范所示
限制意味着有效载荷类型72和73被保留。
RTCP分组类型
缩写。名称值
SR发件人报告200
RR接收器报告201
SDES源描述202
BYE再见203
APP应用程序定义204
这些类型值被选择在200-204范围内进行改进
RTCP包的报头有效性检查与RTP包相比较
其他不相关的数据包。当比较RTCP分组类型字段时
到RTP头的相应字节，这个范围对应
标记位为1（通常不在数据包中）
并且标准有效载荷类型字段的高位是1（因为
静态有效载荷类型通常定义在低一半）。
这个范围也被选为从0和数字的一些距离
255，因为全零和全是通用的数据模式。
由于所有复合RTCP分组必须以SR或RR开始，这些代码
被选为偶数/奇数对以允许RTCP有效性检查
用掩码和值测试最大位数。
额外的RTCP数据包类型可能通过IANA注册（见
第15节）。
SDES类型
缩写。名称值
SDES列表0的END结束
CNAME规范名称1
NAME用户名2
EMAIL用户的电子邮件地址3
PHONE用户的电话号码4
LOC地理用户位置5
工具名称的应用程序或工具6
注意有关来源的通知7
PRIV专用扩展8
其他SDES类型可以通过IANA注册（参见第
15 节）。
Schulzrinne等人 标准跟踪[页70]
RFC 3550 RTP 2003年7月
。
一个完整的规范RTP为特定的应用程序将
需要一个或多个这里描述的两种类型的伴随文件：
配置文件和有效负载格式规范。
RTP可以用于多种应用，但有些不同
要求。适应这些要求的灵活性是
通过在主协议中允许多种选择来提供
规范，然后选择适当的选择或定义
在特定环境和应用程序类别的扩展
一个单独的配置文件。通常应用程序将运行
在一个特定的RTP会话中只有一个配置文件，所以没有
在RTP协议本身内部明确指示哪个
个人资料正在使用中。音频和视频应用程序的配置文件可能是
在伴侣RFC 3551中找到。配置文件通常标题为“RTP”
个人资料...“。
第二种伴随文档是有效载荷格式
规范，它定义了一种特定类型的有效载荷数据，
如H.261编码的视频，应该在RTP中携带。这些
文件通常标题为“XYZ的RTP有效载荷格式”
音频/视频编码“。有效载荷格式可能在多个下有用
配置文件，因此可以独立于任何特定来定义
个人资料。配置文件然后负责分配一个
如果需要，将该格式的默认映射到有效载荷类型值。
在本规范中，下列项目已被确定
在配置文件中可能的定义，但这个列表并不意味着
详尽：
RTP数据头：RTP数据头中包含的八位字节
标记位和有效载荷类型字段可以由a重新定义
配置文件，以适应不同的要求，例如与更多或
更少的标记位（5.3节，第18页）。
有效载荷类型：假设包含有效载荷类型字段，
该配置文件通常会定义一组有效载荷格式（例如，
媒体编码）以及这些格式的默认静态映射
有效载荷类型值。一些有效载荷格式可能被定义
通过参考单独的有效载荷格式规范。每个
有效载荷类型定义，配置文件必须指定RTP时间戳
时钟频率（第5.1节，第14页）。
RTP数据头添加：附加字段可以附加到
固定的RTP数据头，如果一些额外的功能是
跨越个人资料的独立的应用程序类别
有效载荷类型（5.3节，第18页）。
Schulzrinne等人 标准跟踪[页码71]
RFC 3550 RTP 2003年7月
RTP数据头扩展名：前16位的内容
RTP数据头扩展结构必须定义如果使用
这个机制是允许的
特定于实现的扩展（第5.3.1节，第18页）。
RTCP数据包类型：新的特定于应用程序类的RTCP数据包
类型可以被定义并向IANA注册。
RTCP报告间隔：一个配置文件应该指定的值
在第6.2节中提到的常量用于
将使用RTCP报告间隔的计算。那些是
会话带宽的RTCP部分，最小报告
间隔以及发送者和接收者之间的带宽分配。
一个配置文件可以指定替代值，如果他们已经
表现出可扩展的工作方式。
SR / RR扩展：可以为扩展部分定义扩展部分
RTCP SR和RR数据包，如果有附加信息的话
应定期报告发件人或收件人
（第6.4.3节，第42和43页）。
SDES使用：配置文件可以指定相对优先级
RTCP SDES项目完全传输或排除（第
6.3.9 节）; CNAME项目的替代语法或语义
（6.5.1节）; LOC项目的格式（第6.5.5节）; 该
注释项的语义和使用（6.5.7节）; 或新的SDES
要向IANA注册的项目类型。
安全：配置文件可以指定哪些安全服务和
算法应该由应用程序提供，并且可以提供
指导其适当使用（第9节，第65页）。
字符串到键映射：配置文件可以指定用户提供的方式
密码或密码短语被映射到加密密钥。
拥塞：配置文件应该指定拥塞控制
适合该配置文件的行为。
底层协议：使用特定的底层网络或
传输层协议可能需要携带RTP包。
传输映射：RTP和RTCP到传输级别的映射
地址，例如UDP端口，而不是标准映射
在第11节中定义。68可能被指定。
Schulzrinne等人 标准跟踪[页码72]
RFC 3550 RTP 2003年7月
封装：可以定义RTP封装的封装
允许在一个较低层携带多个RTP数据包
数据包或提供不支持的底层协议的帧
已经这样做了（第11节，第69页）。
预计每个人都不需要一个新的配置文件
应用。在一个应用程序类中，最好是
扩展现有的配置文件，而不是做一个新的
促进应用程序之间的互操作
通常只在一个配置文件下运行。简单的扩展，如
附加有效载荷类型值或RTCP分组类型的定义可以
通过IANA注册并发布它们来完成
描述在配置文件的附录或有效负载格式中
规范。
。
RTP遭受与底层相同的安全责任
协议。例如，冒名顶替者可以伪造来源或目的地
网络地址，或更改标头或有效负载。在RTCP中，
CNAME和NAME信息可能被用来冒充另一个
参与者。另外，RTP可以通过IP多播发送，
没有提供发送者知道所有接收者的直接手段
数据发送，因此没有措施的隐私。没错，
用户可能对音频和视频的隐私问题更为敏感
沟通比以往更传统的形式
网络通信[ 33 ]。所以使用安全
RTP机制很重要。这些机制在讨论中
第9节。
可以使用RTP级别的转换器或混合器来允许RTP流量
到达防火墙后面的主机。适当的防火墙安全
原则和做法，这超出了这个范围
文件，在设计和安装这些应该遵循
设备和在RTP应用程序的入场许可之后使用
防火墙。
。
额外的RTCP数据包类型和SDES项目类型可以被注册
通过互联网号码分配机构（IANA）。由于这些
号码空间很小，允许不受限制地注册新的
价值观不会审慎。方便审查请求和
促进多种应用程序，请求中的新类型的共享使用
新值的注册必须在RFC或其他文件中记录
永久的和现成的参考，如产品
另一个合作标准组织（如ITU-T）。其他请求可能
也可以在“指定专家”的建议下被接受。
Schulzrinne等人 标准跟踪[页码73]
RFC 3550 RTP 2003年7月
（请联系IANA获取当前专家的联系信息。）
RTP配置文件规范应该向IANA注册一个名称
以“RTP / xxx”的形式表示，其中xxx是简短的缩写
个人资料标题。这些名称供上级控制使用
协议，如会话描述协议（SDP），RFC 2327
[ 15 ]，来引用传输方法。
。
IETF对任何的有效性或范围不作任何表态
知识产权或其他可能要求的权利
属于实施或使用所述的技术
本文件或在此权利下的任何许可证的程度
可能或可能不可用; 它也不代表它
已经努力确定任何这样的权利。有关的信息
IETF关于标准跟踪权的程序
标准相关的文件可以在BCP-11中找到。副本
权利主张可以发表和任何保证
可用的许可证，或尝试的结果
获得一般许可或使用许可
本规范的实现者或使用者的专有权利可以
从IETF秘书处获得。
IETF邀请任何有关方面提请其注意
版权，专利或专利申请或其他专有权利
权利可能涵盖可能需要实践的技术
这个标准。请向IETF执行官提供信息
导向器。
。
本备忘录基于IETF音频/视频内的讨论
运输工作组由Stephen Casner和Colin Perkins主持。
目前的协议起源于网络语音协议
和分组视频协议（Danny Cohen和Randy Cole）等
协议实施的增值税申请（范雅各布森和史蒂夫
McCanne）。Christian Huitema提供了随机标识符的想法
发电机。定时器的广泛的分析和模拟
Jonathan Rosenberg完成了复议算法。该
Michael Speer和Michael指定了分层编码的补充
史蒂夫·麦凯恩
Schulzrinne等人 标准跟踪[页码74]
RFC 3550 RTP 2003年7月
附录A - 算法
我们提供了RTP发送方和接收方的C代码示例
算法。可能有其他的实现方法
在特定的操作环境下更快或具有其他优点。
这些实现说明仅供参考
是为了澄清RTP规范。
以下定义用于所有示例; 为了清晰和
简洁，结构定义只适用于32位big-
endian（最重要的八位字节第一）体系结构。位字段是
假定以大端位顺序紧紧包装，没有
额外的填充。修改将需要构建一个
便携式实施。
/ *
* rtp.h - RTP头文件
* /
#include <sys / types.h>
/ *
*下面的类型定义适用于32位体系结构和
*可能需要调整为16位或64位体系结构。
* /
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef short int16;
/ *
*当前的协议版本。
* /
#define RTP_VERSION 2
#define RTP_SEQ_MOD（1 << 16）
#define RTP_MAX_SDES 255 / * SDES的最大文本长度* /
typedef enum {
RTCP_SR = 200，
RTCP_RR = 201，
RTCP_SDES = 202，
RTCP_BYE = 203，
RTCP_APP = 204
} rtcp_type_t;
typedef enum {
RTCP_SDES_END = 0，
RTCP_SDES_CNAME = 1，
Schulzrinne等人 标准跟踪[页码75]
RFC 3550 RTP 2003年7月
RTCP_SDES_NAME = 2，
RTCP_SDES_EMAIL = 3，
RTCP_SDES_PHONE = 4，
RTCP_SDES_LOC = 5，
RTCP_SDES_TOOL = 6，
RTCP_SDES_NOTE = 7，
RTCP_SDES_PRIV = 8
} rtcp_sdes_type_t;
/ *
* RTP数据头
* /
typedef struct {
无符号整数版本：2; / *协议版本* /
unsigned int p：1; / *填充标志* /
unsigned int x：1; / *标题扩展标志* /
unsigned int cc：4; / *证监会统计* /
无符号整数m：1; / *标记位* /
unsigned int pt：7; / *有效载荷类型* /
unsigned int seq：16; /* 序列号 */
u_int32 ts; / *时间戳* /
u_int32 ssrc; / *同步源* /
u_int32 csrc [1]; / *可选的CSRC名单* /
} rtp_hdr_t;
/ *
* RTCP公共标题字
* /
typedef struct {
无符号整数版本：2; / *协议版本* /
unsigned int p：1; / *填充标志* /
无符号整数计数：5; / *因数据包类型而异* /
unsigned int pt：8; / * RTCP数据包类型* /
u_int16长度; / * pkt len在文字中，没有这个词* /
} rtcp_common_t;
/ *
*版本，填充位和分组类型对的大端掩码
* /
#define RTCP_VALID_MASK（0xc000 | 0x2000 | 0xfe）
#define RTCP_VALID_VALUE（（RTP_VERSION << 14）| RTCP_SR）
/ *
*接待报告块
* /
typedef struct {
u_int32 ssrc; / *正在报告数据源* /
无符号整数分数：8; / *自上次SR / RR丢失的分数* /
Schulzrinne等人 标准跟踪[页码76]
RFC 3550 RTP 2003年7月
诠释失落：24; / * cumul。没有。丢失（签名！）* /
u_int32 last_seq; / *延长最后一个seq。没有。收到* /
u_int32抖动; / *到达间隔抖动* /
u_int32 lsr; / *来自此源的最后一个SR数据包* /
u_int32 dlsr; / *自上次SR数据包以来的延迟* /
} rtcp_rr_t;
/ *
* SDES项目
* /
typedef struct {
u_int8类型; / *项目类型（rtcp_sdes_type_t）* /
u_int8长度; / *项目的长度（以字节为单位）* /
char数据[1]; / *文本，不以null结尾* /
} rtcp_sdes_item_t;
/ *
*一个RTCP数据包
* /
typedef struct {
rtcp_common_t common; / *公共标题* /
联合{
/ *发件人报告（SR）* /
struct {
u_int32 ssrc; / *发件人生成这个报告* /
u_int32 ntp_sec; / * NTP时间戳* /
u_int32 ntp_frac;
u_int32 rtp_ts; / * RTP时间戳* /
u_int32 psent; / *发送的数据包* /
u_int32 osent; / *八位组发送* /
rtcp_rr_t rr [1]; / *可变长度列表* /
} sr;
/ *接待报告（RR）* /
struct {
u_int32 ssrc; / *接收器产生这个报告* /
rtcp_rr_t rr [1]; / *可变长度列表* /
} rr;
/ *源描述（SDES）* /
struct rtcp_sdes {
u_int32 src; / *第一次SSRC / CSRC * /
rtcp_sdes_item_t item [1]; / * SDES项目清单* /
} sdes;
/ * BYE * /
struct {
u_int32 src [1]; / *来源清单* /
Schulzrinne等人 标准跟踪[页码77]
RFC 3550 RTP 2003年7月
/ *由于原因，不能表达结尾的文本* /
再见;
} r;
} rtcp_t;
typedef struct rtcp_sdes rtcp_sdes_t;
/ *
*每个源的状态信息
* /
typedef struct {
u_int16 max_seq; / *最高seq。看到的数字* /
u_int32个周期; / *移位的seq计数。数字周期* /
u_int32 base_seq; / *基地序号* /
u_int32 bad_seq; / *最后'坏'seq号码+ 1 * /
u_int32缓刑; / * sequ。包到源有效* /
u_int32收到; / *收到的数据包* /
u_int32 expected_prior; / *预计在最后的时间间隔* /
u_int32 received_prior; / *最近一次收到的数据包* /
u_int32过境 / * prev pkt的相对传输时间* /
u_int32抖动; / *估计的抖动* /
/ * ... * /
} 资源;
RTP数据报头有效性检查
RTP接收机应该检查RTP报头的有效性
传入的数据包，因为它们可能被加密或可能来自一个
不同的应用程序碰巧是错误的。同样，如果
根据章节9中描述的方法进行加密，
头部有效性检查是需要验证传入的数据包
已被正确解密，尽管头部失败
有效性检查（例如，未知的有效载荷类型）可能不一定
指示解密失败。
只有对来自某个RTP数据包的弱有效性检查是可能的
以前没有听过的来源：
o RTP版本字段必须等于2。
o有效载荷类型必须是已知的，特别是不能
等于SR或RR。
o如果P位置位，那么数据包的最后一个八位组必须
包含有效的八位字节计数，特别是小于总数
数据包长度减去头部大小。
Schulzrinne等人 标准跟踪[页码78]
RFC 3550 RTP 2003年7月
如果配置文件没有指定，则X位必须为零
可以使用头扩展机制。否则，扩展名
长度字段必须小于总包大小减去
固定的头部长度和填充。
o数据包的长度必须与CC和有效载荷一致
类型（如果有效载荷具有已知的长度）。
最后三项检查有些复杂，并不总是可能的，
只留下前两个总共只有几位。如果SSRC
然后，数据包中的标识符是之前已经接收到的标识符
该数据包可能是有效的，并检查序列号是否是
在预期的范围内提供进一步的验证。如果SSRC
标识符之前没有被看见，然后数据包承载
标识符可能被认为是无效的，直到其中的一小部分
以连续的序号到达。那些无效的数据包可能
被丢弃，或者一旦验证，它们可以被存储和交付
如果由此造成的延误是可以接受的
下面显示的例程update_seq确保声明一个源
只有在收到MIN_SEQUENTIAL包后才有效
序列。它也验证了一个新的序列号seq
接收到的数据包并更新数据包的序列状态
来源于s点的结构。
当第一次听到新的来源，即SSRC
标识符不在表格中（见第8.2节）和每个来源
状态被分配给它，s->缓刑被设置为数量
在声明源有效之前需要顺序数据包
（参数MIN_SEQUENTIAL）和其他变量被初始化：
init_seq（s，seq）;
s-> max_seq = seq-1;
s->缓刑= MIN_SEQUENTIAL;
一个非零的s->缓刑标志着来源尚未有效，所以
状态可能会在短暂超时而不是长时间之后被丢弃，
如6.2.1节所述。
在源被认为有效之后，序列号被考虑
如果在s-> max_seq之前不超过MAX_DROPOUT，则为有效
比MAX_MISORDER落后。如果新的序列号超前
max_seq取模RTP序号范围（16位），但是
小于max_seq，它已经绕过和（移位）的计数
序号循环的次数递增。值为1返回
以指示有效的序列号。
Schulzrinne等人 标准跟踪[第79页]
RFC 3550 RTP 2003年7月
否则，返回零值以指示验证
失败，并且存储了错误的序号加1。如果下一个
接收到的数据包携带下一个更高的序列号
考虑了推测可能导致的新分组序列的有效开始
通过延长丢失或重新启动。由于多个完整
丢失的序列号周期可能已经丢失
统计被重置。
显示参数的典型值，基于最大值
以50包/秒和最大值2秒的无序次数
辍学1分钟。丢失参数MAX_DROPOUT应该是a
给出一个16位序列号空间的小部分
重新启动后的新序列号的合理可能性
不在可接受的范围之内
重新开始。
void init_seq（source * s，u_int16 seq）
{
s-> base_seq = seq;
s-> max_seq = seq;
s-> bad_seq = RTP_SEQ_MOD + 1; / * so seq == bad_seq为false * /
s-> cycles = 0;
s-> received = 0;
s-> received_prior = 0;
s-> expected_prior = 0;
/ *其他初始化* /
}
int update_seq（source * s，u_int16 seq）
{
u_int16 udelta = seq - s-> max_seq;
const int MAX_DROPOUT = 3000;
const int MAX_MISORDER = 100;
const int MIN_SEQUENTIAL = 2;
/ *
*直到MIN_SEQUENTIAL包与源无效
*已经收到序列号。
* /
如果（s->缓刑）{
/ *包是按顺序* /
if（seq == s-> max_seq + 1）{
S-> probation--;
s-> max_seq = seq;
if（s-> probation == 0）{
init_seq（s，seq）;
S->接收++;
返回1;
Schulzrinne等人 标准跟踪[第80页]
RFC 3550 RTP 2003年7月
}
} else {
s->缓刑= MIN_SEQUENTIAL - 1;
s-> max_seq = seq;
}
返回0;
} else if（udelta <MAX_DROPOUT）{
/ *为了允许差距* /
if（seq <s-> max_seq）{
/ *
*包装的序列号 - 计算另一个64K周期。
* /
s-> cycles + = RTP_SEQ_MOD;
}
s-> max_seq = seq;
} else if（udelta <= RTP_SEQ_MOD - MAX_MISORDER）{
/ *序列号跳转非常大* /
if（seq == s-> bad_seq）{
/ *
*两个连续的数据包 - 假设对方
*重新启动而不告诉我们只是重新同步
*（即假装这是第一个数据包）。
* /
init_seq（s，seq）;
}
else {
s-> bad_seq =（seq + 1）＆（RTP_SEQ_MOD-1）;
返回0;
}
} else {
/ *重复或重新排序的数据包* /
}
S->接收++;
返回1;
}
有效性检查可以做得更强，需要两个以上
数据包顺序。缺点是数量较多
初始数据包将被丢弃（或在队列中被延迟）
高包丢失率可能会阻止验证。但是，因为
如果一个RTCP数据包是RTCP头验证相对较强
从数据包之前收到一个数据包，计数就可以了
调整，以便只有两个数据包是必需的顺序。如果
初始数据丢失几秒钟是可以容忍的，一个应用程序
可以选择丢弃来自源的所有数据包直到有效
已经从该源收到RTCP数据包。
Schulzrinne等人 标准跟踪[页码81]
RFC 3550 RTP 2003年7月
根据应用和编码，算法可能会被利用
关于有效载荷格式的额外知识以进一步验证。
对于所有时间戳增量相同的有效内容类型
数据包，时间戳值可以从之前的预测
数据包使用序列号从同一个源接收
差异（假设有效载荷类型没有变化）。
由于可能性很高，因此可以进行强有力的“快速路径”检查
新收到的RTP数据的头部中的前四个八比特组
数据包将与之前数据包的数据包相同
相同的SSRC，但序列号将增加1。
类似地，单条目缓存可以用于更快的SSRC查找
在通常从一个来源接收数据的应用程序中
时间。
RTCP报头有效性检查
以下检查应该应用于RTCP数据包。
o RTP版本字段必须等于2。
o化合物中第一个RTCP数据包的有效载荷类型字段
数据包必须等于SR或RR。
o填充位（P）应该为0的第一个数据包
复合RTCP数据包，因为填充只能应用，如果它
是需要的，到最后一个数据包。
o单个RTCP数据包的长度字段必须加起来
接收到的复合RTCP分组的总长度。这个
是一个相当强大的检查。
下面的代码段执行所有这些检查。包
类型不会检查后来的数据包，因为未知的数据包类型
可能存在，应该被忽略。
u_int32 len; / *以字为单位的复合RTCP分组的长度* /
rtcp_t * r; / * RTCP标头* /
rtcp_t * end; / *复合RTCP数据包的结尾* /
如果（（*（u_int16 *）r＆RTCP_VALID_MASK）！= RTCP_VALID_VALUE）{
/ *数据包格式错误* /
}
end =（rtcp_t *）（（u_int32 *）r + len）;
do r =（rtcp_t *）（（u_int32 *）r + r-> common.length + 1）;
while（r <end && r-> common.version == 2）;
Schulzrinne等人 标准跟踪[第82页]
RFC 3550 RTP 2003年7月
if（r！= end）{
/ *数据包格式错误* /
}
确定预期和丢失的数据包数量
为了计算丢包率，RTP数据包的数量
预期和实际上从每个来源接收需要知道，
使用struct source中定义的每个源的状态信息
在下面的代码中通过指针s引用。数据包的数量
收到的数据包就是数据包的数量，包括任何数据
延迟或重复的数据包。数据包的数量可以是
由接收机计算出最高的差值
接收的序列号（s-> max_seq）和第一个序列号
收到（s-> base_seq）。由于序列号只有16位
并将环绕，有必要延长最高的顺序
编号与（移位的）序列号重叠计数
（S->个循环）。接收到的数据包数和周期数
维护附录A.1中的RTP头部有效性检查程序。
extended_max = s-> cycles + s-> max_seq;
expected = extended_max - s-> base_seq + 1;
丢包的数量被定义为包的数量
预计实际收到的数据包数量减少：
丢失=预期 - s->收到;
由于这个有符号的数字是在24位进行的，所以应该被钳位
在0x7fffff为正面损失或0x800000为负面损失
比包裹。
在上一个报告间隔期间丢失的数据包部分
（自从之前的SR或RR分组被发送）是从中计算的
在预期的和收到的数据包计数的差异
间隔，其中expected_prior和received_prior是值
以前的接收报告生成时保存：
expected_interval =预期 - s-> expected_prior;
s-> expected_prior =预期;
received_interval = s-> received - s-> received_prior;
s-> received_prior = s->收到;
lost_interval = expected_interval - received_interval;
if（expected_interval == 0 || lost_interval <= 0）fraction = 0;
else fraction =（lost_interval << 8）/ expected_interval;
得到的分数是二进制的8位定点数
指向左边缘。
Schulzrinne等人 标准跟踪[页码83]
RFC 3550 RTP 2003年7月
生成RTCP SDES包
这个函数将一个SDES块建立到由argc组成的缓冲区b中
以数组类型，值和长度提供的项目。它返回一个
指向b中下一个可用位置的指针。
char * rtp_write_sdes（char * b，u_int32 src，int argc，
rtcp_sdes_type_t类型[]，char *值[]，
int length []）
{
rtcp_sdes_t * s =（rtcp_sdes_t *）b;
rtcp_sdes_item_t * rsp;
int i;
int len;
int pad;
/ * SSRC标头* /
s-> src = src;
rsp =＆s-> item [0];
/ * SDES项目* /
for（i = 0; i <argc; i ++）{
rsp-> type = type [i];
len = length [i];
if（len> RTP_MAX_SDES）{
/ *长度无效，可能要采取其他行动* /
len = RTP_MAX_SDES;
}
rsp-> length = len;
memcpy（rsp-> data，value [i]，len）;
rsp =（rtcp_sdes_item_t *）＆rsp-> data [len];
}
/ *以结束标记结束并填充到下一个4字节边界* /
len =（（char *）rsp） - b;
pad = 4 - （len＆0x3）;
b =（char *）rsp;
while（pad--）* b ++ = RTCP_SDES_END;
回报b;
}
Schulzrinne等人 标准跟踪[页码84]
RFC 3550 RTP 2003年7月
解析RTCP SDES数据包
这个函数解析一个SDES包，调用函数find_member（）
找到给会员的信息指针
SSRC标识符和member_sdes（）来存储新的SDES信息
为那个成员。这个函数需要一个指向头部的指针
RTCP数据包。
void rtp_read_sdes（rtcp_t * r）
{
int count = r-> common.count;
rtcp_sdes_t * sd =＆r-> r.sdes;
rtcp_sdes_item_t * rsp，* rspn;
rtcp_sdes_item_t * end =（rtcp_sdes_item_t *）
（（u_int32 *）r + r-> common.length + 1）;
源* s;
while（--count> = 0）{
rsp =＆sd-> item [0];
if（rsp> = end）break;
s = find_member（sd-> src）;
for（; rsp-> type; rsp = rspn）{
rspn =（rtcp_sdes_item_t *）（（char *）rsp + rsp-> length + 2）;
if（rspn> = end）{
rsp = rspn;
打破;
}
member_sdes（s，rsp-> type，rsp-> data，rsp-> length）;
}
sd =（rtcp_sdes_t *）
（（u_int32 *）sd +（（（char *）rsp - （char *）sd）>> 2）+1）;
}
if（count> = 0）{
/ *无效的数据包格式* /
}
}
生成一个随机的32位标识符
以下子程序使用随机生成一个32位标识符
在RFC 1321 [ 32 ]中发布的MD5例程。系统例程可能
不是在所有的操作系统上都存在，而是应该作为
提示可以使用什么样的信息。其他系统
可能适当的呼叫包括
Schulzrinne等人 标准跟踪[页85]
RFC 3550 RTP 2003年7月
o getdomainname（），
getwd（）或者
o getrusage（）。
“现场”视频或音频样本也是随机的一个很好的来源
数字，但必须小心避免使用关闭
麦克风或盲目相机作为来源[ 17 ]。
建议使用这个或类似的程序来生成
产生RTCP的随机数发生器的初始种子
期间（如附录A.7所示）），以生成初始值
序列号和时间戳，并生成SSRC值。
由于这个例程很可能是CPU密集型的，所以它的直接使用
生成RTCP时段是不合适的，因为可预测性不是
一个问题。请注意，此例程产生相同的结果
重复的呼叫，直到系统时钟的值改变，除非
为类型参数提供了不同的值。
/ *
*生成一个随机的32位数量。
* /
#include <sys / types.h> / * u_long * /
#include <sys / time.h> / * gettimeofday（）* /
#include <unistd.h> / * get ..（）* /
#include <stdio.h> / * printf（）* /
#include <time.h> / * clock（）* /
#include <sys / utsname.h> / * uname（）* /
从RFC 1321 #include“global.h”/ * * /
#include“md5.h”/ * RFC 1321 * /
#define MD_CTX MD5_CTX
#define MDInit MD5Init
#define MDUpdate MD5Update
#define MDFinal MD5Final
静态u_long md_32（char *字符串，int长度）
{
MD_CTX上下文;
联合{
char c [16];
u_long x [4];
} 消化;
u_long r;
int i;
MDInit（＆context）;
Schulzrinne等人 标准跟踪[页86]
RFC 3550 RTP 2003年7月
MDUpdate（＆context，string，length）;
MDFinal（（unsigned char *）＆digest，＆context）;
r = 0;
for（i = 0; i <3; i ++）{
r ^ = digest.x [i];
}
返回r;
} / * md_32 * /
/ *
*返回随机无符号的32位数量。如果使用'type'参数
*您需要紧密连续生成几个不同的值。
* /
u_int32 random32（int型）
{
struct {
int类型;
结构timeval电视;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
gettimeofday（＆s.tv，0）;
UNAME（＆s.name）;
s.type = type;
s.cpu = clock（）;
s.pid = getpid（）;
s.hid = gethostid（）;
s.uid = getuid（）;
s.gid = getgid（）;
/ *还有：系统正常运行时间* /
返回md_32（（char *）＆s，sizeof（s））;
} / * random32 * /
计算RTCP传输间隔
以下功能实现了RTCP的发送和接收6.2节中
描述的规则。这些规则被编码在几个
功能：
rtcp_interval（）计算确定性的计算间隔，
以秒为单位。参数在6.3节中定义。
Schulzrinne等人 标准跟踪[页码87]
RFC 3550 RTP 2003年7月
OnExpire（）在RTCP传输定时器到期时被调用。
OnReceive（）在接收到RTCP数据包时被调用。
OnExpire（）和OnReceive（）都有事件e作为参数。这是
该参与者的下一个计划事件，即RTCP报告
或BYE包。假定以下功能是
可供选择：
o时间表（时间t，事件e）安排事件e在时间t发生。
当时间t到达时，函数OnExpire被称为e
论据。
o重新计划（时间t，事件e）重新计划先前的计划
事件e的时间t。
SendRTCPReport（事件e）发送一个RTCP报告。
SendBYEPacket（事件e）发送一个BYE包。
TypeOfEvent（event e）如果事件正在返回EVENT_BYE
处理的是一个BYE包发送，否则返回
EVENT_REPORT。
PacketType（p）返回PACKET_RTCP_REPORT，如果数据包p是一个RTCP
报告（不是BYE），PACKET_BYE如果是BYE RTCP包，
PACKET_RTP，如果它是一个常规的RTP数据包。
ReceivedPacketSize（）和SentPacketSize（）返回的大小
以八比特组为单位的引用分组。
o如果发送数据包p的参与者是，则NewMember（p）返回1
目前不在成员列表中，否则为0。注意这个功能
因为每个中国证监会都是不够的
RTP包中的标识符和BYE包中的每个SSRC
被处理。
o如果发送数据包p的参与者是，则NewSender（p）返回1
目前不在成员列表的发件人子列表中，0
除此以外。
AddMember（）和RemoveMember（）添加和删除参与者
成员列表。
AddSender（）和RemoveSender（）添加和删除参与者
成员列表的发件人子列表。
Schulzrinne等人 标准跟踪[第88页]
RFC 3550 RTP 2003年7月
这些功能将不得不延长执行
允许发送者和非发送者的RTCP带宽分数是
指定为显式参数而不是25％的固定值
75％。rtcp_interval（）的扩展实现将需要
如果其中一个参数为零，则避免被零除。
双rtcp_interval（int成员，
int发件人，
双rtcp_bw，
int we_sent，
双avg_rtcp_size，
int初始）
{
/ *
*来自本站点的RTCP数据包之间的最短平均时间（in
*秒）。这个时候可以防止“聚集”报告
*会议规模小，大量的法律没有帮助
*消除流量。它也保持报告间隔
*在短暂的停电期间变得可笑的小
*网络分区。
* /
double const RTCP_MIN_TIME = 5。
/ *
*活跃的RTCP带宽共享部分
*发件人。（这个分数被选中，以便在一个典型的
*与一个或两个主动发送者的会话，计算的报告
*时间大致等于最小报告时间
*我们不会不必要地拖慢收件人的报告
*接收器分数必须是1 - 发件人分数。
* /
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION =（1-RTCP_SENDER_BW_FRACTION）;
/ *
/ *为了弥补“定时器重新考虑”收敛到一个
*值低于预期的平均值。
* /
double const COMPENSATION = 2.71828 - 1.5;
成对的东西; / *间隔* /
double rtcp_min_time = RTCP_MIN_TIME;
int n; / *不。成员计算* /
/ *
*应用程序启动时的第一个通话使用半分钟
*延迟更快的通知，同时仍然允许一段时间
*报告随机前和了解其他
*来源，所以报告间隔会收敛到正确的
*间隔更快。
Schulzrinne等人 标准跟踪[第89页]
RFC 3550 RTP 2003年7月
* /
如果（初始）{
rtcp_min_time / = 2;
}
/ *
*将RTCP带宽的一小部分分配给发送者，除非
*发件人的数量足够大，他们的份额是
*超过这个分数。
* /
n =成员;
如果（发件人<=成员* RTCP_SENDER_BW_FRACTION）{
if（we_sent）{
rtcp_bw * = RTCP_SENDER_BW_FRACTION;
n =发件人;
} else {
rtcp_bw * = RTCP_RCVR_BW_FRACTION;
n - =发件人;
}
}
/ *
*站点的有效数量乘以平均数据包大小
*每个站点发送报告时发送的八位字节总数。
*除以有效带宽给出的时间
*必须发送这些数据包的时间间隔
*满足带宽目标，最低强制执行。在那里面
*我们发送一份报告的时间间隔，所以这次也是我们的
*报告之间的平均时间。
* /
t = avg_rtcp_size * n / rtcp_bw;
如果（t <rtcp_min_time）t = rtcp_min_time;
/ *
*避免流量突然意外同步
*其他网站，我们然后选择我们的实际下一个报告间隔作为一个
*随机数均匀分布在0.5 * t和1.5 * t之间。
* /
t = t *（drand48（）+ 0.5）;
t = t /补偿;
返回t;
}
void OnExpire（event e，
int成员，
int发件人，
双rtcp_bw，
int we_sent，
double * avg_rtcp_size，
Schulzrinne等人 标准跟踪[第90页]
RFC 3550 RTP 2003年7月
int *初始，
time_tp tc，
time_tp * tp，
int * pmembers）
{
/ *这个函数负责决定是否发送一个
*现在RTCP报告或BYE包，或重新安排传输。
*它也负责更新pmembers，initial，tp，
*和avg_rtcp_size状态变量。这个功能应该是
调用Schedule（）使用的事件计时器到期。
* /
成对的东西; / *间隔* /
双tn; / *下一次传输时间* /
/ *在BYE的情况下，使用“定时器重新考虑”
*必要时重新安排BYE的传输* /
if（TypeOfEvent（e）== EVENT_BYE）{
t = rtcp_interval（成员，
发件人，
rtcp_bw，
我们发送，
* avg_rtcp_size，
*初始）;
tn = * tp + t;
如果（tn <= tc）{
SendBYEPacket（E）;
出口（1）;
} else {
附表（tn，e）;
}
（else）if（TypeOfEvent（e）== EVENT_REPORT）{
t = rtcp_interval（成员，
发件人，
rtcp_bw，
我们发送，
* avg_rtcp_size，
*初始）;
tn = * tp + t;
如果（tn <= tc）{
SendRTCPReport（E）;
* avg_rtcp_size =（1./16.)*SentPacketSize（e）+
（15./16.)*(*avg_rtcp_size）;
* tp = tc;
/ *我们必须重画间隔。不要重复使用
Schulzrinne等人 标准跟踪[第91页]
RFC 3550 RTP 2003年7月
一个以上计算，因为它不是实际
分发一样，因为我们是有条件的
它是足够小，导致一个数据包
被发送* /
t = rtcp_interval（成员，
发件人，
rtcp_bw，
我们发送，
* avg_rtcp_size，
*初始）;
附表（T + TC，E）;
* initial = 0;
} else {
附表（tn，e）;
}
* pmembers =成员;
}
}
void OnReceive（packet p，
事件e，
int *成员，
int * pmembers，
int *发送者，
double * avg_rtcp_size，
双* tp，
双tc，
双tn）
{
/ *我们做什么取决于我们是否已经离开了这个组织
*等待发送一个BYE（TypeOfEvent（e）== EVENT_BYE）或一个RTCP
*报告。p表示刚收到的数据包。* /
if（PacketType（p）== PACKET_RTCP_REPORT）{
if（NewMember（p）&&（TypeOfEvent（e）== EVENT_REPORT））{
使用addMember（P）;
*会员+ = 1;
}
* avg_rtcp_size =（1./16.)*ReceivedPacketSize（p）+
（15./16.)*(*avg_rtcp_size）;
} else if（PacketType（p）== PACKET_RTP）{
if（NewMember（p）&&（TypeOfEvent（e）== EVENT_REPORT））{
使用addMember（P）;
*会员+ = 1;
}
if（NewSender（p）&&（TypeOfEvent（e）== EVENT_REPORT））{
Schulzrinne等人 标准跟踪[第92页]
RFC 3550 RTP 2003年7月
AddSender（P）;
*发件人+ = 1;
}
} else if（PacketType（p）== PACKET_BYE）{
* avg_rtcp_size =（1./16.)*ReceivedPacketSize（p）+
（15./16.)*(*avg_rtcp_size）;
if（TypeOfEvent（e）== EVENT_REPORT）{
if（NewSender（p）== FALSE）{
RemoveSender（P）;
*发件人 - = 1;
}
if（NewMember（p）== FALSE）{
RemoveMember（P）;
*会员 - = 1;
}
if（* members <* pmembers）{
tn = tc +
（（（double）* members）/（* pmembers））*（tn - tc）;
* tp = tc -
（（（double）* members）/（* pmembers））*（tc - * tp）;
/ *重新安排时间tn的下一个报告* /
重新安排（tn，e）;
* pmembers = *会员;
}
（else）if（TypeOfEvent（e）== EVENT_BYE）{
*会员+ = 1;
}
}
}
Schulzrinne等人 标准跟踪[第93页]
RFC 3550 RTP 2003年7月
估计到达间隔抖动
下面的代码段实现了6.4.1 节
给出的算法用于计算的统计方差的估计
RTP数据到达间隔时间被插入到间隔抖动中
接待领域的报道。输入是r-> ts，来自的时间戳
传入的数据包和到达，当前时间在相同的单位。
这里要指出来源; s->中转持有亲属
前一个数据包的传输时间，以及s-> jitter保存
估计抖动。接收报告的抖动字段是
以时间戳单位测量并表示为无符号整数，但是
抖动估计保持在浮点。作为每个数据包
到达时，抖动估计值被更新：
int transit = arrival - r-> ts;
int d = transit - s-> transit;
s-> transit = transit;
如果（d <0）d = -d;
s-> jitter + =（1./16。）*（（double）d - s-> jitter）;
接收报告块（rr点数）生成时
这个成员，当前的抖动估计被返回：
rr-> jitter =（u_int32）s-> jitter;
或者，抖动估计可以保持为整数，但是
缩小以减少舍入误差。除了计算是相同的
最后一行：
s-> jitter + = d - （（s-> jitter + 8）>> 4）;
在这种情况下，接收报告的估计值被采样为：
rr-> jitter = s-> jitter >> 4;
Schulzrinne等人 标准跟踪[第94页]
RFC 3550 RTP 2003年7月
附录B - RFC 1889的变化
这个RFC的大部分与RFC 1889相同。有没有变化
线上的数据包格式，只改变规则和
管理如何使用协议的算法。最大的变化是
对可扩展定时器算法进行增强以计算何时
发送RTCP数据包：
计算RTCP传输间隔的算法
在6.2节和6.3节中有规定，并在附录A.7中说明
被增加以包括“重新考虑”以最小化传输
当许多参与者加入时，超过预期的费率
会议同时进行，“逆向重新考虑”减少
虚假参与者超时的发生率和持续时间
参与者人数迅速下降。反向重审是
也用于在发送RTCP SR之前可能缩短延迟
当从被动接收器转换到主动发送器模式时。
o 第6.3.7节指定新的规则控制RTCP BYE时
应该发送数据包，以避免数据包泛滥
许多参与者同时离开会议。
o要求为非活动的参与者保留状态
足够长的时间跨越典型的网络分区被删除
来自第6.2.1节。在许多参与者加入的会议中
短暂的时间和不能发送BYE，这个要求会导致一个
显着高估了参与者的人数。该
本修订中增加的复议算法可以补偿
当大量的新参与者同时加入时
分区治愈。
应该指出，这些增强只有一个重要的
当会议参与者数量很大时（千）
大部分参与者同时参加或离开。这个
使现场网络测试困难。但是，算法
进行了彻底的分析和模拟验证
性能。此外，增强算法的设计
与RFC 1889中的算法互操作，
在一个步骤中减少过多的RTCP带宽是成比例的
到实施增强的参与者的一小部分
算法。两种算法的互操作性已得到验证
在实时网络上进行实验。
其他功能变化是：
o 第6.2.1节指定实现可能只存储一个
对参与者的SSRC标识符进行抽样以允许缩放
非常大的会议。算法在RFC 2762 [ 21 ] 中指定。
Schulzrinne等人 标准跟踪[第95页]
RFC 3550 RTP 2003年7月
o在6.2节，规定了RTCP发送者和非发送者
带宽可以被设置为会话的单独参数
比会话带宽的严格百分比，并且可以被设置
归零。RTP会话必须使用RTCP
使用IP多播被放宽。然而，澄清也是
补充说，关闭RTCP不推荐。
○在第6.2，6.3.1和附录A.7，它是指定的
参与者的分数低于发送者的专用RTCP
带宽从固定1/4变化到基于RTCP的比率
发送者和非发送者带宽参数。
在那里没有带宽专用于发件人的条件
没有发件人被删除，因为这是预期的
过渡状态。它也让非发件人使用发件人
RTCP带宽时，这是不是打算。
o也在第6.2节也规定了最小的RTCP时间间隔
对于高带宽会话可以缩放到更小的值，并且
对于单播，初始RTCP延迟可能被设置为零
会话。
o指定参与者的时间应以不活动为基础
的使用接收方RTCP计算的RTCP报告间隔
即使对于主动发送者也是如此。
o 7.2和7.3节规定了译员和混音师应该这样做
发送BYE数据包为他们不再转发的来源。
o分层编码的规则更改在2.4节中定义，
6.3.9,8.3和11.在最后这些，注意到
地址和端口分配规则与SDP冲突
规范，RFC 2327 [ 15 ]，但它的目的是这样的
在RFC 2327的修订中将会放宽限制。
o在RTP和RTCP中使用偶数/奇数端口对的惯例
第11条澄清了指的是目的港。该
如果使用偶数/奇数端口对的要求被删除
端口是明确指定的。对于单播RTP会话，
可用于两个端部不同的端口对（第3，7.1
和11）。
o增加了新的第10节来解释要求
使用RTP的应用程序拥塞控制。
o在8.2节中，新SSRC标识符必须是的要求
每当源传输地址被改变时被选择
轻松地说可以选择一个新的SSRC标识符。
相应地，澄清了一个实现可能
Schulzrinne等人 标准跟踪[第96页]
RFC 3550 RTP 2003年7月
选择保留新的源地址而不是数据包
现有的源地址在两个SSRC冲突发生之间
其他参与者，并应该这样做的应用程序，如
电话，其中一些来源，如移动实体可能会改变
RTP会话过程中的地址。
o 在伪造代码的RFC 1889打印中的缩进错误8.2节中
的碰撞检测和解决算法
已经通过将语法翻译成伪C语言来纠正，
并修改了算法以消除这个限制
RTP和RTCP必须从相同的源端口号发送。
o对RTCP数据包的填充机制的描述是
澄清，并指定填充必须只适用于
复合RTCP分组的最后一个分组。
o在A.1节中，base_seq的初始化被纠正为seq
而不是seq - 1，文字纠正说不好
序号加1存储。max_seq的初始化
和其他变量的算法是从文本中分离出来的
要明确这个初始化必须除了做
调用init_seq（）函数（并在RFC 1889中丢失了一些单词
当处理文件从源文件到输出文件时
恢复）。
o在A.3节中丢失的数据包数量被纠正为
使用正面和负面的限制。
o RTCP SR中“相对”NTP时间戳的规范
现在将这些时间戳定义为基于最多的时间戳
常见的系统专用时钟，比如系统正常运行时间，而不是
在会议上经历的时间将不会是相同的多个
应用程序在不同的时间在同一台机器上启动。
非功能性更改：
o指定接收者必须忽略有效载荷的数据包
类型它不明白。
o在图2中，浮点NTP时间戳值被校正，
一些丢失的前导零被添加在一个十六进制数和UTC
时区被指定。
o NTP时间戳在一年中的不合时宜
2036解释。
Schulzrinne等人 标准跟踪[第97页]
RFC 3550 RTP 2003年7月
o RTCP分组类型和SDES类型的注册策略
在新的第15条中得到澄清 IANA考虑事项。该
建议实验者注册他们需要的数字
那么取消注册那些证明不需要的东西已被删除
赞成使用APP和PRIV。配置文件名称的注册是
也指定了。
o UTF-8字符集的引用从
X / Open初步规范是RFC 2279。
o RFC 1597的参考更新为RFC 1918和RFC 2543的
参考更新为RFC 3261。
RFC 1889中
引入的最后一段，
警告实施者限制在互联网上的部署
被删除，因为它被认为不再相关。
o关于使用与特定源相关的RTP的非规范性说明
组播（SSM）在第6节中添加。
o 第3节中“RTP会话”的定义扩展到了
承认单个会话可能会使用多个目标
运输地址（翻译者总是如此）
混音器），并解释一个RTP的显着特点
会话是每个对应于一个单独的SSRC标识符
空间。增加了“多媒体会议”的新定义
减少对“会话”一词的混淆。
o“采样即时”的含义已经详细解释为
部分RTP头部的时间戳字段的定义
第5.1节。
o在几个地方对文本作了小的澄清，
有的回答了读者的提问。尤其是：
- 在RFC 1889中，第2.2节第二句的前五个单词
在处理源文件到文档时丢失了
输出形式，但现在恢复。
-在溶液中加入一种“RTP媒体类型”的定义第3节至
允许在5.2 节中
解释复用RTP会话方面更加清楚
媒体。这部分现在也解释了复用
基于SSRC标识符的相同介质的多个来源
可能是适当的，并且是组播会话的标准。
- “非RTP手段”的定义扩大到包括
构成非RTP手段的其他协议的例子。
Schulzrinne等人 标准跟踪[页98]
RFC 3550 RTP 2003年7月
- 扩展了会话带宽参数的描述
在第6.2节，包括说明控制权
流量带宽是除了会话带宽之外的
数据流量。
- 不同的数据包持续时间对抖动计算的影响
在第6.4.4节中有解释。
- 终止和填充一系列SDES项目的方法
在第6.5节中得到澄清。
- 在SDES的描述中添加了IPv6地址示例第6.5.1节中的
CNAME 代替了“example.com”
其他示例域名。
- 安全部分现在增加了对IPSEC的正式引用
它是可用的，并说保密的方法
在本规范中定义的主要是编纂现有的
实践。建议更强的加密
诸如Triple-DES之类的算法可用于代替默认值
算法，并指出基于AES的SRTP配置文件将是
未来的正确选择。对弱点谨慎
添加了作为初始化向量的RTP头。它
还注意到有效载荷加密是必要的
允许标题压缩。
- 明确了RTCP的部分加密方法; 在
特别是，SDES CNAME只在一个部分被携带
复合RTCP分组被拆分。
- 明确只有一个复合RTCP数据包应该是
发送每个报告间隔，如果有太多
报告的主动来源适合MTU，然后是一个子集
的来源应该选择多轮循环
间隔。
- 附录A.1中增加了一个说明，可以保存数据包
在RTP头部验证期间，并在成功后交付。
- 7.3节现在解释一个混合器聚合SDES数据包
由于更长的数据包和混频器，使用更多的RTCP带宽
通过RTCP自然发送的数据包高于
单一的来源率，但这两种行为是有效的。
- 第13节澄清了一个RTP应用程序可能使用多个
配置文件，但通常只有一个给定的会话。
Schulzrinne等人 标准跟踪[页99]
RFC 3550 RTP 2003年7月
- 术语必须，应该，可以等，如RFC
2119中所定义。
- 参考书目分为规范和信息
引用。
浙公网安备 33010602011771号