RFC 3550 RTP(A Transport Protocol for Real-Time Applications) 实时应用的传输协议 (一)

实时传输协议（RTP）：面向实时应用的传输协议

网络工作组 请求评论文档：3550
哥伦比亚大学
替代文档：1889
类别：标准跟踪
Packet Design公司

H. Schulzrinne（哥伦比亚大学）
S. Casner（Packet Design公司）
R. Frederick（Blue Coat Systems公司）
V. Jacobson（Packet Design公司）
2003年7月

本文档状态

本文档规定了一种面向互联网社区的互联网标准跟踪协议，并征求改进意见和建议。有关该协议的标准化状态和状态信息，请参考最新版的《互联网官方协议标准》（STD 1）。本文档的分发不受限制。

版权声明

版权所有（C）互联网协会（2003年）。保留所有权利。

摘要

本文档描述了实时传输协议（RTP）。RTP提供适用于实时数据（如音频、视频或仿真数据）通过多播或单播网络服务传输的端到端网络传输功能。RTP不涉及资源预留，也不保证实时服务的服务质量（QoS）。数据传输通过控制协议（RTCP，实时传输控制协议）进行增强，该协议支持以可扩展到大型多播网络的方式监控数据交付，并提供基本的控制和标识功能。RTP和RTCP的设计独立于底层传输层和网络层协议，且支持使用RTP级别的转换器（translator）和混频器（mixer）。

本文档的大部分内容与被其替代的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 NAME：用户名SDES项 … 48
   6.5.3 EMAIL：电子邮件地址SDES项 … 48
   6.5.4 PHONE：电话号码SDES项 … 49
   6.5.5 LOC：用户地理位置SDES项 … 49
   6.5.6 TOOL：应用程序或工具名称SDES项 … 49
   6.5.7 NOTE：通知/状态SDES项 … 50
   6.5.8 PRIV：私有扩展SDES项 … 50
   6.6 BYE：再见（结束参与）RTCP数据包 … 51
   6.7 APP：应用程序定义的RTCP数据包 … 52
7. RTP转换器与混频器 … 53
   7.1 概述 … 53
   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
    作者联系方式 … 103
    完整版权声明 … 104

Schulzrinne 等 著
标准跟踪
[第2页]
RFC 3550
RTP
2003年7月

1. 引言

本文档规定了实时传输协议（RTP），该协议为具有实时特性的数据（如交互式音频和视频）提供端到端交付服务，这些服务包括负载类型标识、序列号编排、时间戳标记和交付监控。应用程序通常将RTP运行在UDP之上，以利用UDP的多路复用和校验和服务；这两种协议共同构成了传输协议的功能。不过，RTP也可与其他适用的底层网络层或传输层协议配合使用（见第11章）。若底层网络支持多播分发，RTP可将数据传输到多个目的地。

需注意，RTP本身不提供任何确保及时交付或保证其他服务质量（QoS）的机制，而是依赖底层协议实现这些功能。RTP不保证数据包交付，也不防止数据包乱序交付，同时不假设底层网络是可靠的且能按序交付数据包。RTP中包含的序列号允许接收方重建发送方的数据包序列，但序列号也可用于确定数据包的正确位置（例如在视频解码中），而无需按序解码所有数据包。

尽管RTP的设计初衷是满足多参与者多媒体会议的需求，但它并不局限于这一特定应用。连续数据存储、交互式分布式仿真、活动标识（active badge）以及控制与测量应用等，也可使用RTP。

本文档定义的RTP包含两个紧密关联的部分：

• 实时传输协议（RTP）：用于承载具有实时特性的数据；
• 实时传输控制协议（RTCP）：用于监控服务质量，并传递正在进行的会话中参与者的相关信息。RTCP的后一项功能可能足以支持“松散控制”的会话（即无需显式成员控制和建立过程的会话），但不一定能满足应用程序的所有控制通信需求。这种控制功能可能会全部或部分由独立的会话控制协议（超出本文档范围）承担。

RTP遵循Clark和Tennenhouse在文献[10]中提出的“应用层成帧”（application level framing）和“集成层处理”（integrated layer processing）原则，代表了一种新型协议设计风格。也就是说，RTP旨在具备灵活性，能够提供特定应用所需的信息，且通常会集成到应用程序处理过程中，而非作为独立层实现。RTP是一个故意设计为“不完整”的协议框架，本文档仅规定了所有适用RTP的应用程序共需的功能。与传统协议（通常通过提高协议通用性或添加需解析的选项机制来容纳额外功能）不同，RTP可根据需求通过修改和/或添加头部来适配特定场景，第5.3节和第6.4.3节给出了相关示例。

因此，除本文档外，为特定应用完整规范RTP还需一个或多个配套文档（见第13章）：

• 配置文件规范文档：定义一组负载类型代码及其与负载格式（如媒体编码）的映射关系。配置文件还可定义针对特定应用类别的RTP扩展或修改。通常，一个应用程序仅在一个配置文件下运行。音频和视频数据的配置文件可参考配套文档RFC 3551[1]；
• 负载格式规范文档：定义特定负载（如音频或视频编码）如何在RTP中承载。

有关实时服务及其实现算法，以及RTP部分设计决策的背景说明，可参考文献[11]。

1.1 术语

本文档中，“MUST”（必须）、“MUST NOT”（不得）、“REQUIRED”（必需）、“SHALL”（应）、“SHALL NOT”（不应）、“SHOULD”（建议）、“SHOULD NOT”（不建议）、“RECOMMENDED”（推荐）、“MAY”（可）和“OPTIONAL”（可选）等关键词的含义需按照BCP 14（RFC 2119[2]）的规定解释，它们表示符合RTP实现的需求级别。

2. RTP使用场景

以下章节描述RTP的部分使用场景。选择这些示例是为了说明应用程序使用RTP的基本操作，而非限制RTP的应用范围。在这些示例中，RTP基于IP和UDP传输，并遵循配套文档RFC 3551中规定的音视频配置文件约定。

2.1 简单多播音频会议

IETF的某个工作组通过互联网的IP多播服务进行语音通信，讨论最新的协议文档。工作组主席通过某种分配机制获取一个多播组地址和一对端口：一个端口用于音频数据传输，另一个用于控制（RTCP）数据包传输。该地址和端口信息会分发给目标参与者。若需隐私保护，可按照第9.1节的规定对数据和控制数据包进行加密，此时还需生成并分发加密密钥。这些分配和分发机制的具体细节超出RTP的范围。

每个会议参与者使用的音频会议应用程序会将音频数据分割成小块（例如20毫秒时长的块）发送。每个音频数据块前会添加一个RTP头部，RTP头部和数据共同封装在UDP数据包中。RTP头部会指明每个数据包中包含的音频编码类型（如PCM、ADPCM或LPC），这样发送方在会议过程中可更改编码——例如，为适配通过低带宽链路连接的新参与者，或响应网络拥塞指示。

与其他分组网络一样，互联网偶尔会发生数据包丢失、乱序，且数据包延迟会有波动。为应对这些问题，RTP头部包含时间戳信息和序列号，使接收方能够重建发送方生成的时序（例如，每20毫秒连续从扬声器播放音频块）。接收方会针对会议中每个RTP数据包源，分别执行时序重建。序列号还可被接收方用于估计数据包丢失数量。

由于工作组成员会在会议期间加入或离开，了解任意时刻的参与者名单以及他们接收音频数据的质量非常有用。为此，会议中的每个音频应用程序实例会定期在RTCP（控制）端口上多播“接收报告”以及用户名称。接收报告会表明当前发言者的音频被接收的质量，可用于控制自适应编码。除用户名外，在控制带宽限制范围内，还可包含其他标识信息。当某个站点离开会议时，会发送RTCP BYE数据包（见第6.6节）。

Schulzrinne 等 著
标准跟踪
[第6页]
RFC 3550
RTP
2003年7月

2.2 音视频会议

若会议中同时使用音频和视频媒体，它们会作为独立的RTP会话传输。也就是说，每种媒体的RTP和RTCP数据包会通过两对不同的UDP端口和/或多播地址传输。在RTP层面，音频和视频会话之间没有直接关联，但同时参与两个会话的用户应在两个会话的RTCP数据包中使用相同的标准名称（canonical name），以便关联这两个会话。

这种分离设计的一个目的是，允许会议中的部分参与者根据自身选择仅接收一种媒体。第5.2节提供了进一步说明。尽管会话是分离的，但通过两个会话的RTCP数据包中携带的时间戳信息，仍可实现同一源的音视频同步播放。

2.3 混频器与转换器

到目前为止，我们均假设所有站点希望以相同格式接收媒体数据，但实际情况并非总是如此。例如，某一区域的参与者通过低速率链路连接，而大多数会议参与者使用高速网络。此时无需强制所有人使用低带宽、低质量的音频编码，而是可在低带宽区域附近部署一个RTP级别的中继设备——混频器（mixer）。该混频器会重新同步输入的音频数据包，以重建发送方生成的20毫秒固定间隔音频流，将这些重建的音频流混合为单个流，将音频编码转换为低带宽格式，并通过低速链路转发低带宽数据包流。这些数据包可单播给单个接收方，或通过不同地址多播给多个接收方。RTP头部中包含混频器标识“贡献源”的机制——混频器会标识对混合数据包有贡献的源，以便接收方正确显示当前发言者。

部分音频会议的目标参与者可能使用高速链路连接，但无法直接通过IP多播访问（例如，位于不允许任何IP数据包通过的应用层防火墙之后）。对于这类站点，可能无需混频，此时可使用另一种RTP级别的中继设备——转换器（translator）。在防火墙两侧各部署一个转换器：外侧的转换器通过安全连接将接收到的所有多播数据包转发给防火墙内侧的转换器；内侧的转换器再将这些数据包以多播形式发送到仅限站点内部网络访问的多播组。

混频器和转换器可针对多种用途设计。例如，视频混频器可缩放各个独立视频流中的人物图像，并将其合成为单个视频流，以模拟群组场景。其他转换场景包括：将仅支持IP/UDP的主机组与仅理解ST-II协议的主机组连接，或对单个源的视频流进行逐包编码转换（无需重新同步或混合）。混频器和转换器的具体操作细节见第7章。

2.4 分层编码

多媒体应用应能调整传输速率，以匹配接收方的能力或适应网络拥塞。许多实现将速率自适应的责任交给发送方，但这种方式在多播传输中效果不佳——因为不同接收方的带宽需求可能相互冲突，最终往往导致“最小公分母”场景：网络中的最小带宽链路决定了整个实时多媒体“广播”的质量和保真度。

相反，可通过“分层编码+分层传输系统”的组合，将速率自适应的责任转移到接收方。在基于IP多播的RTP场景中，发送方可将分层表示信号的递进层分布到多个RTP会话中，每个会话通过独立的多播组承载。接收方可通过仅加入多播组的适当子集，适应网络异构性并控制自身的接收带宽。

RTP在分层编码中的使用细节见第6.3.9节、第8.3节和第11章。

3. 定义

• RTP负载（RTP payload）：RTP数据包中承载的数据（如音频采样或压缩视频数据）。负载格式及其解释超出本文档范围。
• RTP数据包（RTP packet）：由固定RTP头部、可选的贡献源（CSRC）列表（见下文）和负载数据组成的数据包。部分底层协议可能需要定义RTP数据包的封装方式。通常，底层协议的一个数据包包含一个RTP数据包，但在封装方式允许的情况下，也可包含多个RTP数据包（见第11章）。
• RTCP数据包（RTCP packet）：由与RTP数据包头类似的固定头部，以及随RTCP数据包类型变化的结构化元素组成的控制数据包。其格式定义见第6章。通常，多个RTCP数据包会组合成一个“复合RTCP数据包”，封装在底层协议的单个数据包中传输；这一机制通过每个RTCP数据包固定头部中的“长度字段”实现。
• 端口（Port）：“传输协议用于区分同一主机内多个目的地的抽象概念。TCP/IP协议使用小的正整数标识端口”[12]。OSI传输层使用的传输选择器（TSEL）与端口等效。RTP依赖底层协议提供类似端口的机制，以实现会话中RTP和RTCP数据包的多路复用。
• 传输地址（Transport address）：由网络地址和端口组成，标识传输层端点（如IP地址和UDP端口）。数据包从源传输地址发送到目的传输地址。
• RTP媒体类型（RTP media type）：可在单个RTP会话中承载的所有负载类型的集合。RTP配置文件会将RTP媒体类型映射到RTP负载类型。
• 多媒体会话（Multimedia session）：一组并发的RTP会话，参与者为同一群体。例如，视频会议（一种多媒体会话）可能包含一个音频RTP会话和一个视频RTP会话。
• RTP会话（RTP session）：使用RTP通信的一组参与者之间的关联。一个参与者可同时参与多个RTP会话。在多媒体会话中，除非编码本身将多种媒体复用到单个数据流中，否则每种媒体通常通过独立的RTP会话（含自身的RTCP数据包）承载。参与者通过“目的传输地址对”（由一个网络地址，以及一对分别用于RTP和RTCP的端口组成）区分多个RTP会话。RTP会话的所有参与者可共享同一个目的传输地址对（如IP多播场景），也可每个参与者使用不同的地址对（如单播场景，每个参与者使用独立的IP地址和端口对）。在单播场景中，一个参与者可通过同一端口对接收其他所有参与者的数据包，也可针对每个参与者使用独立的端口对。

RTP会话的显著特征是，每个会话维护独立完整的SSRC标识符空间（定义见下文）。某个RTP会话的参与者集合，是指那些能接收该会话中任一参与者通过RTP（作为SSRC或CSRC，定义见下文）或RTCP发送的SSRC标识符的节点。例如，考虑一个通过单播UDP实现的三方会议：每个参与者通过独立的端口对接收另外两个参与者的数据包。若每个参与者仅向数据发送方反馈RTCP接收报告，则该会议由三个独立的点对点RTP会话组成；若每个参与者向另外两个参与者均反馈RTCP接收报告，则该会议由一个多方RTP会话组成——后者模拟了三方通过IP多播通信的行为。

RTP框架允许上述场景的变化，但特定的控制协议或应用程序设计通常会对这些变化施加约束。

• 同步源（SSRC，Synchronization Source）：RTP数据包流的源，由RTP头部中携带的32位数值型SSRC标识符标识，不依赖网络地址。来自同一同步源的所有数据包属于同一时序和序列号空间，因此接收方会按同步源对数据包分组，以便播放。同步源的示例包括：从麦克风、摄像头等信号源生成数据包流的发送方，或RTP混频器（见下文）。同步源可随时间更改数据格式（如音频编码）。SSRC标识符是随机选择的值，旨在确保在特定RTP会话中全局唯一（见第8章）。一个参与者在多媒体会话的不同RTP会话中，无需使用相同的SSRC标识符；SSRC标识符之间的关联通过RTCP实现（见第6.5.1节）。若一个参与者在一个RTP会话中生成多个流（如来自多个摄像头），则每个流必须使用不同的SSRC标识。
• 贡献源（CSRC，Contributing Source）：对RTP混频器（见下文）生成的混合流有贡献的RTP数据包流源。混频器会将“对特定数据包生成有贡献的源的SSRC标识符列表”（称为CSRC列表）插入该数据包的RTP头部。例如，在音频会议中，混频器会列出所有参与音频混合的源的SSRC标识符，以便接收方正确显示当前发言者——即使所有音频数据包均包含混频器的SSRC标识符。
• 终端系统（End system）：生成待通过RTP发送的内容，和/或消费接收的RTP数据包内容的应用程序。一个终端系统在特定RTP会话中可作为一个或多个同步源，但通常仅作为一个。
• 混频器（Mixer）：一种中间系统，从一个或多个源接收RTP数据包，可能更改数据格式，以某种方式混合这些数据包，然后转发新的RTP数据包。由于多个输入源的时序通常不同步，混频器会调整各流的时序，为混合流生成自身的时序。因此，混频器生成的所有数据包均以混频器作为同步源标识。
• 转换器（Translator）：一种中间系统，转发RTP数据包时保留其同步源标识符。转换器的示例包括：无需混合的编码转换器、多播转单播的复制器，以及防火墙中的应用层过滤器。
• 监控器（Monitor）：接收RTP会话参与者发送的RTCP数据包（尤其是接收报告），并估计当前服务质量，用于分发监控、故障诊断和长期统计的应用程序。监控功能通常集成在参与会话的应用程序中，但也可由独立的“第三方监控器”实现——这类监控器不参与其他会话活动，也不发送或接收RTP数据包（因RTP数据包在独立端口传输）。第三方监控器也可接收RTP数据包，但不发送RTCP数据包，也不计入会话参与者。
• 非RTP方式（Non-RTP means）：除RTP外，提供可用服务可能需要的协议和机制。特别是在多媒体会议中，控制协议可能需要分发多播地址和加密密钥、协商要使用的加密算法，以及为无预定义负载类型值的格式定义RTP负载类型值与其负载格式的动态映射。这类协议的示例包括会话初始协议（SIP，RFC 3261[13]）、ITU-T H.323建议[14]，以及使用SDP（RFC 2327[15]）的应用程序（如RTSP，RFC 2326[16]）。对于简单应用，也可使用电子邮件或会议数据库。此类协议和机制的规范超出本文档范围。

4. 字节顺序、对齐方式与时间格式

所有整数字段均以网络字节顺序（即大端序，最高有效字节优先）传输。这种字节顺序的传输细节见文献[3]。除非另有说明，数值常量均为十进制（基数10）。

所有头部数据均按其自然长度对齐：16位字段对齐到偶数字节偏移量，32位字段对齐到能被4整除的字节偏移量，依此类推。标记为“填充”的字节值为0。

墙钟时间（绝对日期和时间）使用网络时间协议（NTP）的时间戳格式表示，即相对于1900年1月1日0时（UTC）的秒数[4]。完整分辨率的NTP时间戳是一个64位无符号定点数：前32位为整数部分，后32位为小数部分。在部分需要更紧凑表示的字段中，仅使用中间32位（即整数部分的低16位和小数部分的高16位）；整数部分的高16位需通过其他方式独立确定。

实现RTP不强制要求运行网络时间协议（NTP），也可使用其他时间源，或不使用任何时间源（见第6.4.1节中NTP时间戳字段的说明）。但运行NTP有助于同步来自不同主机的流。

NTP时间戳将在2036年左右溢出归零，但在RTP中仅使用NTP时间戳对之间的差值。只要可假设时间戳对之间的间隔不超过68年，使用模运算进行减法和比较即可忽略溢出问题。

5. RTP数据传输协议

5.1 RTP固定头部字段

RTP头部格式如下：

前12字节存在于所有RTP数据包中；贡献源（CSRC）标识符列表仅在混频器插入时存在。各字段含义如下：

• 版本（V）：2位
  标识RTP的版本。本文档定义的版本为2（版本1用于RTP的首个草案版本，版本0用于最初在“vat”音频工具中实现的协议）。

• 填充（P）：1位
  若填充位设为1，则数据包末尾包含一个或多个额外的填充字节，这些字节不属于负载。最后一个填充字节的值表示需忽略的填充字节数（包括自身）。某些具有固定块大小的加密算法，或在底层协议数据单元中承载多个RTP数据包时，可能需要填充。

• 扩展（X）：1位
  若扩展位设为1，则固定头部后必须紧跟一个头部扩展，其格式定义见第5.3.1节。

• CSRC计数（CC）：4位
  表示固定头部后跟随的CSRC标识符数量。

• 标记（M）：1位
  标记的含义由配置文件定义，旨在允许在数据包流中标记重要事件（如帧边界）。配置文件可定义额外的标记位，或通过更改负载类型字段的位数来指定无标记位（见第5.3节）。

• 负载类型（PT）：7位
  标识RTP负载的格式，决定应用程序对负载的解释方式。配置文件可指定负载类型代码与负载格式的默认静态映射；额外的负载类型代码可通过非RTP方式动态定义（见第3章）。音视频的默认映射集合见配套文档RFC 3551[1]。RTP源在会话过程中可更改负载类型，但不应使用该字段对独立的媒体流进行多路复用（见第5.2节）。接收方必须忽略负载类型无法识别的数据包。

• 序列号（sequence number）：16位
  每个RTP数据包包的序列号递增1，接收方可使用该字段检测数据包丢失并重建数据包序列。序列号的初始值应随机（不可预测）——即使源本身未按第9.1节的方法加密，也可降低加密的“已知明文攻击”风险（因数据包可能经过加密的转换器）。选择不可预测数值的技术见文献[17]。

• 时间戳（timestamp）：32位
  时间戳反映RTP数据包中第一个字节的采样时刻。采样时刻必须源自“单调且线性递增”的时钟，以支持同步和抖动计算（见第6.4.1节）。时钟分辨率必须足以满足预期的同步精度和数据包到达抖动测量需求（通常，视频帧每帧一个时钟滴答的分辨率不足）。时钟频率取决于负载承载的数据格式，由定义该格式的配置文件或负载格式规范静态指定，或由非RTP方式为动态定义的负载格式指定。若RTP数据包周期性生成，则使用采样时钟确定的“标称采样时刻”（而非系统时钟读数）。例如，对于固定速率音频，时间戳时钟通常每采样周期递增1；若音频应用程序从输入设备读取包含160个采样周期的块，则无论该块是否通过数据包传输或因静音丢弃，每个块对应的时间戳均增加160。

  与序列号类似，时间戳的初始值应随机。若多个连续RTP数据包在逻辑上同时生成（如属于同一视频帧），则它们的时间戳相同。若数据未按采样顺序传输（如MPEG插值视频帧），则连续RTP数据包的时间戳可能非单调（但传输的数据包序列号仍保持单调）。

  不同媒体流的RTP时间戳可能以不同速率递增，且通常具有独立的随机偏移。因此，尽管这些时间戳足以重建单个流的时序，但直接比较不同媒体的RTP时间戳无法有效实现同步。相反，对于每种媒体，需通过“将RTP时间戳与参考时钟（墙钟）时间戳配对”，建立RTP时间戳与采样时刻的关联——参考时钟时间戳表示对应RTP时间戳的数据被采样的时间。所有待同步的媒体共享同一参考时钟。时间戳对不会在每个数据包中传输，而是通过RTCP SR（发送方报告）数据包以较低频率传输（见第6.4节）。

  选择“采样时刻”作为RTP时间戳的参考点，是因为采样时刻对发送端点可知，且对所有媒体具有统一定义（与编码延迟或其他处理无关）。其目的是实现对“同时采样的所有媒体”的同步呈现。

  对于传输存储数据（而非实时采样数据）的应用程序，通常使用基于墙钟时间的“虚拟呈现时间线”，确定存储数据中每种媒体的下一帧或其他单元的呈现时机。此时，RTP时间戳反映每个单元的“呈现时间”——即每个单元的RTP时间戳与“该单元在虚拟呈现时间线上变为当前单元的墙钟时间”相关联。实际呈现会在接收方确定的某个后续时间进行。

  以下示例可说明选择“采样时刻”作为参考点的意义：对预录制视频进行实时音频旁白。在该场景中，视频会本地呈现给旁白者观看，同时通过RTP传输。RTP中传输的视频帧的“采样时刻”，通过将其时间戳与“视频帧呈现给旁白者的墙钟时间”关联来确定；包含旁白音频的RTP数据包的“采样时刻”，通过将其时间戳与“音频采样的同一墙钟时间”关联来确定。若两台主机的参考时钟通过NTP等方式同步，音频和视频甚至可由不同主机传输。接收方可通过RTCP SR数据包中的时间戳对，关联音频和视频数据包的RTP时间戳，从而实现同步呈现。

• 同步源（SSRC）：32位
  标识同步源。该标识符应随机选择，确保同一RTP会话中的两个同步源不会使用相同的SSRC标识符。生成随机标识符的示例算法见附录A.6。尽管多个源选择相同标识符的概率较低，但所有RTP实现必须准备好检测并解决冲突。第8章描述了冲突概率，以及基于SSRC标识符唯一性的“冲突解决与RTP级转发环路检测”机制。若源更改其传输地址，必须同时选择新的SSRC标识符，以避免被误认为是环路源（见第8.2节）。

• CSRC列表（CSRC list）：0至15项，每项32位
  标识对当前数据包负载有贡献的源。标识符数量由CC字段指定；若贡献源超过15个，仅能标识前15个。CSRC标识符由混频器插入（见第7.1节），使用贡献源的SSRC标识符。例如，在音频数据包中，列出所有参与混合生成该数据包的源的SSRC标识符，可让接收方正确显示当前发言者。

5.2 RTP会话的多路复用

根据“集成层处理”设计原则[10]，为提高协议处理效率，应尽量减少多路复用点数量。在RTP中，多路复用通过“目的传输地址”（网络地址+端口号）实现——每个RTP会话使用不同的目的传输地址。例如，在由单独编码的音频和视频媒体组成的电话会议中，每种媒体应通过独立的RTP会话传输，且每个会话使用自身的目的传输地址。

不应将独立的音频和视频流承载在单个RTP会话中，再通过负载类型或SSRC字段进行解复用。将不同RTP媒体类型的数据包（使用相同SSRC）交织传输会引发以下问题：

1. 若两个音频流共享同一RTP会话和SSRC值，且其中一个流更改编码（从而使用不同的RTP负载类型），则无法通过通用方式识别哪个流更改了编码；
2. SSRC的定义是“标识单个时序和序列号空间”。若交织传输多种负载类型，且媒体时钟速率不同，则需要不同的时序空间；若要区分哪种负载类型发生了数据包丢失，则需要不同的序列号空间；
3. RTCP发送方报告和接收方报告（见第6.4节）仅能描述每个SSRC对应的一个时序和序列号空间，且不包含负载类型字段；
4. RTP混频器无法将“不兼容媒体的交织流”合并为一个流；
5. 在单个RTP会话中承载多种媒体，会导致以下功能无法实现：在适用时使用不同的网络路径或网络资源分配；根据需求仅接收部分媒体（如视频带宽不足时仅接收音频）；接收方使用独立进程处理不同媒体（而使用独立RTP会话可支持“单进程”或“多进程”两种实现方式）。

若为每种媒体使用不同的SSRC，但在同一RTP会话中发送，可避免前三个问题，但无法解决后两个问题。

另一方面，在多播会话中，通过不同SSRC值在单个RTP会话中多路复用“同一媒体的多个相关源”是常见做法——上述问题在此场景中不适用：例如，RTP混频器可合并多个音频源，且所有源均适用相同处理方式。在其他“后两个问题不适用”的场景中，也可通过不同SSRC值在单个RTP会话中多路复用同一媒体的多个流。

5.3 RTP头部的配置文件特定修改

现有RTP数据包包头被认为已包含“所有适用RTP的应用类别共需的功能”，但遵循“应用层成帧”（ALF）设计原则，配置文件规范可通过修改或添加头部字段来适配特定需求，同时确保“与配置文件无关的监控和录制工具”仍能正常工作。具体方式如下：

1. 标记位和负载类型字段携带配置文件特定信息，但它们被置于固定头部中——因为许多应用可能需要这些字段，若不置于固定头部，可能需要额外添加32位字段来承载；配置文件可重新定义包含这些字段的字节，以满足不同需求（如增加或减少标记位数量）。若存在标记位，应将其中一位置于该字节的最高有效位——因为与配置文件无关的监控器可通过该位观察“数据包丢失模式与标记位的关联”；
2. 特定负载格式（如视频编码）所需的额外信息，应承载在数据包的负载部分——可在负载部分开头始终包含一个头部，或通过数据模式中的保留值标识；
3. 若某类应用需要“与负载格式无关”的额外功能，其对应的配置文件应定义“在现有固定头部的SSRC字段后立即添加额外固定字段”。这类应用可快速直接地访问额外字段，而与配置文件无关的监控器或录制工具仍可通过仅解析前12字节来处理RTP数据包。

若所有配置文件均需要某一额外功能，则应定义RTP新版本，对固定头部进行永久性修改。

5.3.1 RTP头部扩展

RTP提供头部扩展机制，允许个别实现尝试“需要在RTP数据包包头中携带额外信息”的“与负载格式无关”的新功能。该机制设计为：未扩展的互操作实现可忽略头部扩展。

需注意，此头部扩展仅用于有限场景——大多数潜在需求更适合通过前一节描述的方式实现。例如，“配置文件特定的固定头部扩展”的处理成本更低（无需判断条件，且位置固定）；特定负载格式所需的额外信息不应使用此头部扩展，而应承载在数据包的负载部分。

头部扩展格式如下：

若RTP头部的X位设为1，则RTP头部后必须附加一个变长头部扩展（若存在CSRC列表，则紧跟在CSRC列表后）。头部扩展包含一个16位长度字段，用于表示扩展部分的32位字数量（不包含4字节的扩展头部本身）——因此长度值为0是有效的。RTP数据包头仅能附加一个扩展。

为允许“多个互操作实现独立尝试不同头部扩展”，或“单个实现尝试多种头部扩展”，头部扩展的前16位留作“区分标识符或参数”，其格式由实现所遵循的配置文件规范定义。本文档本身不定义任何头部扩展。

6. RTP控制协议（RTCP）

实时传输控制协议（RTCP）基于“向会话所有参与者周期性传输控制数据包”的机制，使用与数据数据包相同的分发方式。底层协议必须支持数据与控制数据包的多路复用（例如，UDP使用不同端口号）。RTCP实现以下四项功能：

1. 主要功能：反馈数据分发质量
   这是RTP作为传输协议的核心功能之一，与其他传输协议的流量控制和拥塞控制功能相关（见第10章“拥塞控制需求”）。反馈信息可直接用于控制自适应编码[18,19]，但IP多播实验表明，接收方的反馈对于诊断分发故障也至关重要。将接收报告发送给所有参与者，可让“观察到问题的参与者”判断问题是本地还是全局的。对于IP多播等分发机制，网络服务提供商等“非会话参与实体”也可接收反馈信息，作为第三方监控器诊断网络问题。此反馈功能通过RTCP发送方报告（SR）和接收方报告（RR）实现，详见第6.4节。

2. 携带RTP源的持久传输级标识符（CNAME）
   RTCP携带称为“标准名称”（CNAME，canonical name）的标识符（见第6.5.1节），作为RTP源的持久传输级标识。由于SSRC标识符可能因冲突检测或程序重启而更改，接收方需要通过CNAME跟踪每个参与者；此外，接收方可能还需要通过CNAME关联“同一参与者在多个相关RTP会话中的多个数据流”（例如音频和视频同步）。跨媒体同步还需要数据发送方在RTCP数据包中包含的NTP时间戳和RTP时间戳。

3. 控制RTCP传输速率，支持大规模会话
   前两项功能要求所有参与者发送RTCP数据包，因此必须控制传输速率，才能让RTP支持大量参与者。每个参与者通过向所有其他参与者发送控制数据包，可独立观察参与者数量，并利用该数量计算数据包发送间隔（见第6.2节）。

4. 可选功能：传递基本会话控制信息
   例如，在用户界面中显示参与者标识。这在“松散控制”会话（参与者无需成员控制或参数协商即可加入/离开）中可能非常有用。RTCP提供了一个便捷的“全参与者可达”通道，但不一定能满足应用程序的所有控制通信需求——可能需要更高层的会话控制协议（超出本文档范围）。

功能1-3应在所有环境中使用，尤其是IP多播环境。RTP应用程序设计应避免“仅适用于单播模式、无法扩展到大规模场景”的机制。对于单向链路等“无法接收接收方反馈”的场景，可按第6.2节的描述，分别控制发送方和接收方的RTCP传输。

非规范性说明：在“源特定多播”（SSM，Source-Specific Multicast）路由方式中，每个“通道”（源地址+组地址对）仅存在一个发送方，且接收方（除通道源外）无法通过多播直接与其他通道成员通信。本文档的建议仅通过第6.2节中“完全关闭接收方RTCP”的选项适配SSM；未来的工作将指定RTCP针对SSM的适配方案，以维持接收方的反馈功能。

6.1 RTCP数据包格式

本文档定义了多种RTCP数据包类型，用于承载不同的控制信息：

• SR（Sender Report，发送方报告）：由活跃发送方发送，包含传输和接收统计信息；
• RR（Receiver Report，接收方报告）：由非活跃发送方发送，包含接收统计信息；活跃发送方也可使用RR报告超过31个源的统计信息；
• SDES（Source Description，源描述）：包含源描述项（如CNAME）；
• BYE（再见）：指示参与者结束会话参与；
• APP（Application-specific，应用特定）：用于应用程序自定义功能。

每个RTCP数据包均以与RTP数据包包头类似的固定头部开头，后跟“随数据包类型变化但必须对齐到32位边界”的结构化元素。固定头部中的“对齐要求”和“长度字段”使RTCP数据包支持“堆叠”——多个RTCP数据包可无间隔地拼接成一个“复合RTCP数据包”，封装在底层协议（如UDP）的单个数据包中传输。复合数据包中不包含“单个RTCP数据包数量”的显式计数，因为底层协议会提供总长度，用于确定复合数据包的结束位置。

复合数据包中的每个RTCP数据包可独立处理，对顺序或组合无要求，但为实现协议功能，需遵循以下约束：

1. 接收统计信息（包含在SR或RR中）应在带宽允许的情况下尽可能频繁地发送，以最大化统计信息的分辨率——因此，每个周期性传输的复合RTCP数据包必须包含一个报告数据包（SR或RR）；
2. 新接收方需要尽快获取源的CNAME，以标识源并开始关联媒体（如唇同步）——因此，每个复合RTCP数据包必须包含SDES CNAME项（除非复合数据包因部分加密而拆分，见第9.1节）；
3. 需限制“可作为复合数据包首个数据包的类型”，以增加“首个32位字中的固定位数量”，提高“将RTCP数据包与误发的RTP数据包或其他无关数据包区分开”的成功率。

因此，所有RTCP数据包必须以“至少包含两个单个数据包”的复合数据包形式发送，格式如下：

• 加密前缀（Encryption prefix）：若复合数据包需按第9.1节的方法加密，则必须在开头添加一个32位随机数（每个发送的复合数据包重新生成）；若加密需要填充，则填充字节必须添加到复合数据包的最后一个数据包中。
• SR或RR：复合数据包的第一个RTCP数据包必须是报告数据包（SR或RR），以便按附录A.2的方法验证头部——即使未发送或接收任何数据（此时需发送空RR），或复合数据包中仅包含一个BYE数据包，也需遵守此规则。
• 额外RR：若需报告的源数量超过31（单个SR或RR数据包的最大容量），则初始报告数据包后应紧跟额外的RR数据包。
• SDES：每个复合RTCP数据包必须包含一个“包含CNAME项的SDES数据包”（第9.1节所述场景除外）；若特定应用需要，在带宽限制范围内，也可包含其他源描述项。
• BYE或APP：其他RTCP数据包类型（包括未来定义的类型）可按任意顺序跟随，但BYE数据包应作为“具有特定SSRC/CSRC的最后一个数据包”发送；同一类型的数据包可出现多次。

为正确估计每个参与者的RTCP带宽（见第6.2节），单个RTP参与者在每个报告间隔内应仅发送一个复合RTCP数据包（第9.1节所述“复合数据包因加密拆分”的场景除外）。若需报告的源数量过多，导致所有必要的RR数据包无法在一个复合数据包中容纳（不超过网络路径的MTU），则每个间隔内仅包含“能容纳在一个MTU中的子集”，并通过多轮间隔“轮询选择子集”，确保所有源的信息均能被报告。

建议转换器和混频器在可行时，将“从多个源转发的单个RTCP数据包”合并为一个复合数据包，以减少数据包开销（见第7章）。若复合数据包的总长度超过网络路径的MTU，则应拆分为多个较短的复合数据包，通过底层协议的独立数据包传输——这不会影响RTCP带宽估计，因为每个复合数据包代表至少一个独立参与者。需注意，每个拆分后的复合数据包均必须以SR或RR数据包开头。

实现应忽略“类型未知的传入RTCP数据包”。新的RTCP数据包类型可按第15章的描述，向互联网号码分配机构（IANA）注册。

图1：RTCP复合数据包示例

Schulzrinne 等 著
标准跟踪
[第23页]
RFC 3550
RTP
2003年7月

6.2 RTCP传输间隔

RTP的设计目标之一是支持应用程序“自动适应会话规模”——从少数参与者到数千参与者。例如，在音频会议中，数据流量具有内在的自限制特性：同一时间通常只有一两人发言，因此通过多播分发时，任意链路的数据速率基本恒定，与参与者数量无关。但控制流量无此自限制特性：若每个参与者以固定速率发送接收报告，控制流量会随参与者数量线性增长。因此，必须通过“动态计算RTCP数据包发送间隔”来降低传输速率。

对于每个会话，假设数据流量受“会话带宽”（session bandwidth）这一总限制约束，该带宽在参与者之间分配。会话带宽可通过网络预留并强制执行；若未预留，则可能存在其他约束（取决于环境），这些约束确定会话的“合理最大带宽”，即会话带宽。会话带宽可根据成本或“会话可用网络带宽的先验知识”选择，与媒体编码有一定独立性，但编码选择可能受会话带宽限制。通常，会话带宽是“预期同时活跃的发送方的标称带宽之和”——例如，电话会议音频的会话带宽通常等于单个发送方的带宽；对于分层编码，每层是一个独立的RTP会话，各有其会话带宽参数。

会话带宽参数通常由“会话管理应用程序”在调用媒体应用程序时提供，但媒体应用程序也可根据“会话所选编码的单发送方数据带宽”设置默认值。应用程序还可根据多播范围规则或其他标准强制执行带宽限制。所有参与者必须使用相同的会话带宽值，以确保计算出相同的RTCP间隔。

控制流量和数据流量的带宽计算需包含底层传输层和网络层协议（如UDP和IP）——因为资源预留系统需要这些信息；应用程序通常也知晓所使用的底层协议。链路层头部不计入计算，因为数据包在传输过程中会封装不同的链路层头部。

控制流量的带宽应限制为“会话带宽的一小部分且已知”：“小部分”是为避免影响传输协议“承载数据”的核心功能；“已知”是为便于将控制流量纳入“向资源预留协议提供的带宽规范”，且让每个参与者能独立计算自身的带宽份额。控制流量带宽是“数据流量会话带宽”之外的额外部分。建议将RTCP占用的会话带宽比例固定为5%，且建议将RTCP带宽的1/4分配给“正在发送数据的参与者”——这样，在“接收方多、发送方少”的会话中，新加入的参与者能更快获取发送方的CNAME。若发送方比例超过参与者总数的1/4，则发送方按比例占用全部RTCP带宽。尽管间隔计算中的这些常量值并非绝对关键，但所有会话参与者必须使用相同值，以确保计算出相同的间隔——因此，这些常量应针对特定配置文件固定。

配置文件可指定“控制流量带宽”为“会话的独立参数”，而非“会话带宽的固定百分比”。使用独立参数可让“速率自适应应用程序”设置与“典型数据带宽”（低于会话带宽参数指定的最大带宽）匹配的RTCP带宽。

配置文件还可进一步指定“将控制流量带宽拆分为两个独立的会话参数”，分别对应“活跃数据发送方”和“非活跃数据发送方”，记为参数S和R。遵循“RTCP带宽的1/4分配给发送方”的建议，S和R的默认推荐值分别为1.25%和3.75%。若发送方比例超过参与者总数的S/(S+R)，则发送方按比例占用S+R的总和。使用两个参数可实现“完全关闭特定会话的RTCP接收报告”（将非发送方的RTCP带宽设为0，同时保持发送方的RTCP带宽非零，以便发送方报告仍能传输，支持跨媒体同步）。不建议关闭RTCP接收报告——因为第6章开头列出的功能（尤其是接收质量反馈和拥塞控制）需要接收报告；但在“单向链路”或“无需接收质量反馈/接收方活跃度检测，且有其他方法避免拥塞”的会话中，关闭接收报告可能是合适的。

计算出的“复合RTCP数据包发送间隔”还应设置下限——以避免“参与者数量少且流量未按大数定律平滑”时，数据包突发超出允许带宽；同时，也可避免“网络分区等临时故障”导致报告间隔过小，进而在分区恢复时延迟适配。应用程序启动时，应在发送第一个复合RTCP数据包前添加延迟——为接收其他参与者的RTCP数据包留出时间，使报告间隔更快收敛到正确值。此延迟可设为“最小间隔的一半”，以更快通知其他参与者“新参与者已加入”。固定最小间隔的推荐值为5秒。

实现可根据“会话带宽参数”按比例缩小最小RTCP间隔，但需遵守以下限制：

1. 对于多播会话，仅“活跃数据发送方”可使用缩小后的最小间隔计算复合RTCP数据包的发送间隔；
2. 对于单播会话，“非活跃数据发送方”也可使用缩小后的最小间隔，且发送首个复合RTCP数据包前的延迟可设为0；
3. 对于所有会话，计算“参与者超时间隔”（见第6.3.5节）时应使用“固定最小间隔”——避免“未使用缩小间隔发送RTCP数据包的实现”被其他参与者过早判定为超时；
4. 缩小后的最小间隔（单位：秒）推荐值为“360除以会话带宽（单位：千比特/秒）”——当带宽超过72千比特/秒时，此值小于5秒。

第6.3节和附录A.7描述的算法旨在实现本节所述目标，该算法通过计算“复合RTCP数据包发送间隔”，将“允许的控制流量带宽”分配给所有参与者。这使得应用程序既能为“小会话”提供快速响应（例如，快速识别所有参与者），又能自动适配“大会话”。该算法具有以下特性：

Schulzrinne 等 著
标准跟踪
[第26页]
RFC 3550
RTP
2003年7月

6.2 RTCP传输间隔（续）

该算法的核心特性如下：

• 间隔与成员数量线性相关：计算得出的RTCP数据包发送间隔随会话成员数量线性变化。正因为这一线性关系，所有成员的控制流量总和能保持恒定。
• 间隔随机化：为避免所有参与者的发送时机意外同步[20]，RTCP数据包的实际发送间隔会在“计算间隔的0.5倍至1.5倍”范围内随机波动。参与者加入会话后发送第一个RTCP数据包时，还需额外增加“最小RTCP间隔一半”的随机延迟。
• 动态估计平均包大小：自动计算“所有已发送和接收的复合RTCP数据包”的平均大小，以适应控制信息总量的变化。
• 启动期计时器调整（Timer Reconsideration）：若新用户加入现有会话，或大量用户同时加入新会话，新用户初期对成员数量的估计会不准确，导致RTCP发送间隔过短。为解决此问题，需采用“计时器调整”算法——通过简单的退避机制，在成员数量增长时延迟RTCP数据包发送。
• 成员减少时的反向调整（Reverse Reconsideration）：当用户通过发送BYE包或因超时离开会话时，成员数量减少，计算间隔应相应缩短。“反向调整”算法可让成员更快降低发送间隔，以适应成员数量的减少。
• BYE包的特殊处理：用户离开会话并希望发送BYE包时，可在下次计划发送RTCP数据包前提前发送，但BYE包需遵循退避算法——避免大量成员同时离开时出现BYE包“洪泛”。

该算法适用于“所有参与者均可发送数据”的会话。此时，会话带宽参数为“单个发送者带宽 × 参与者数量”，RTCP带宽为该值的5%。算法的具体操作细节将在后续章节说明，附录A.7提供了示例实现。

6.2.1 维护会话成员数量

RTCP数据包间隔的计算依赖于“会话参与站点数量的估计值”。当检测到新站点时，需将其加入计数，并在“以SSRC或CSRC标识符为索引的表”中创建条目以跟踪该站点（见第8.2节）。新条目需满足以下条件之一才视为有效：

1. 收到多个携带该新SSRC的数据包（见附录A.1）；
2. 收到包含该SSRC对应CNAME的SDES RTCP数据包。

当收到含对应SSRC标识符的RTCP BYE包时，理论上可从表中删除该条目，但需注意：BYE包发送后可能仍有“滞后数据包（straggler data packets）”到达，导致条目被重新创建。因此，正确做法是先将条目标记为“已收到BYE”，并在适当延迟后删除。

若某站点在“多个RTCP报告间隔（推荐为5个）”内未发送任何RTP或RTCP数据包，参与者可将该站点标记为“非活跃”，或在其条目未生效时直接删除——此举可提高对数据包丢失的容错性。为确保超时机制正常工作，所有站点必须使用相同的“间隔倍数”，且计算出的RTCP报告间隔需大致一致。因此，该倍数应针对特定配置文件固定。

对于参与者极多的会话，维护“包含所有SSRC标识符和状态信息的表”可能不现实。此时，实现可采用文献[21]中描述的“SSRC采样”机制减少存储需求，或使用其他性能相当的算法。核心要求是：所选算法不得严重低估成员数量（允许高估）。

6.3 RTCP数据包发送与接收规则

本节概述RTCP数据包的发送规则及接收后的处理流程。支持多播或多点单播环境的实现必须满足第6.2节的要求，可通过本节定义的算法或其他“性能等效或更优”的算法实现。仅支持双向单播的实现，仍应通过“随机化RTCP传输间隔”避免同一环境中多个实例的发送时机意外同步，但可省略第6.3.3、6.3.6、6.3.7节中的“计时器调整”和“反向调整”算法。

为执行这些规则，会话参与者需维护以下状态变量：

• tp：上次发送RTCP数据包的时间；
• tc：当前时间；
• tn：下次计划发送RTCP数据包的时间；
• pmembers：上次计算tn时估计的会话成员数量；
• members：最新估计的会话成员数量；
• senders：最新估计的会话发送者数量；
• rtcp_bw：RTCP目标带宽（所有会话成员用于RTCP数据包的总带宽，单位：字节/秒），为应用程序启动时配置的“会话带宽”的指定比例；
• we_sent：发送标识——若应用程序在“上上次发送RTCP报告后”发送过数据，则为true；
• avg_rtcp_size：该参与者“所有已发送和接收的RTCP数据包”的平均复合RTCP数据包大小（单位：字节），包含底层传输层和网络层协议头部（如UDP和IP，见第6.2节）；
• initial：初始标识——若应用程序尚未发送过RTCP数据包，则为true。

以下规则大多依赖“数据包发送的计算间隔”，其定义见下一节。

6.3.1 计算RTCP传输间隔

为保证可扩展性，参与者发送数据包的平均间隔需随成员数量动态调整，该间隔称为“计算间隔”。结合上述状态变量，计算间隔T的步骤如下：

1. 带宽分配判断

   • 若发送者数量≤成员总数（members）的25%：间隔需根据参与者是否为发送者（由we_sent标识）区分：
     • 发送者（we_sent=true）：常数C = 平均RTCP包大小（avg_rtcp_size） / RTCP带宽的25%（rtcp_bw × 0.25）；常数n = 发送者数量（senders）；
     • 非发送者（we_sent=false）：常数C = 平均RTCP包大小 / RTCP带宽的75%（rtcp_bw × 0.75）；常数n = 接收者数量（members - senders）。
   • 若发送者数量>成员总数的25%：发送者与接收者统一处理：常数C = 平均RTCP包大小 / 总RTCP带宽（rtcp_bw）；常数n = 成员总数（members）。

   如第6.2节所述，RTP配置文件可指定“RTCP带宽通过两个独立参数（记为S和R）分别定义发送者和非发送者的带宽”。此时，25%的比例替换为S/(S+R)，75%替换为R/(S+R)。需注意：若R=0，则发送者比例永远不会超过S/(S+R)，实现需避免除以零错误。

2. 最小间隔（Tmin）设定

   • 若参与者尚未发送过RTCP数据包（initial=true）：Tmin = 2.5秒；
   • 否则：Tmin = 5秒。

3. 确定性计算间隔（Td）
   Td = max(Tmin, n×C)（取Tmin和n×C中的较大值）。

4. 最终计算间隔（T）
   T为“Td的0.5倍至1.5倍”之间的均匀随机值。注：计时器调整算法最终会使RTCP带宽收敛到低于预期平均值，因此无需额外修正（公式中e⁻³/²≈1，可忽略）。

通过上述步骤，RTCP间隔虽为随机值，但平均而言：发送者至少占用25%的RTCP带宽，接收者占用剩余带宽；若发送者比例超过成员总数的25%，则所有参与者平均分配带宽。

6.3.2 初始化

参与者加入会话时，需执行以下初始化操作：

• 设置tp=0、tc=0、senders=0、pmembers=1、members=1、we_sent=false；
• 设置rtcp_bw为“会话带宽的指定比例”；
• 设置initial=true；
• 设置avg_rtcp_size为“应用程序后续将构造的第一个RTCP数据包的预估大小”；
• 按第6.3.1节计算间隔T，将第一个数据包的发送时间设为tn=T（即设置计时器在T时刻到期）；
• 将自身SSRC加入成员表。

6.3.3 接收RTP或非BYE类型的RTCP数据包

1. 若收到来自“SSRC未在成员表中”的参与者的RTP或RTCP数据包：
   • 待该参与者按第6.2.1节验证通过后，将其SSRC加入成员表，并更新members值；
   • 对于已验证的RTP数据包，其包含的每个CSRC也需执行上述操作（加入成员表并更新members）。
2. 若收到来自“SSRC未在发送者表中”的参与者的RTP数据包：
   • 将该SSRC加入发送者表，并更新senders值。
3. 对于每个收到的复合RTCP数据包，更新平均RTCP包大小：
   avg_rtcp_size = (1/16)×数据包大小 + (15/16)×当前avg_rtcp_size
   （其中“数据包大小”为刚收到的RTCP数据包的实际大小）。

6.3.4 接收RTCP BYE数据包

除第6.3.7节“需发送RTCP BYE包”的场景外，收到RTCP BYE包时需执行以下操作：

1. 检查BYE包中的SSRC是否在成员表中：若存在，删除该条目并更新members值；
2. 检查该SSRC是否在发送者表中：若存在，删除该条目并更新senders值。

此外，为使RTCP传输速率更适应成员数量变化，当收到“使members值小于pmembers”的BYE包时，应执行“反向调整”算法：

• 更新下次发送时间：(tn = tc + (members/pmembers) × (tn - tc))
• 更新上次发送时间：(tp = tc - (members/pmembers) × (tc - tp))
• 按新的tn重新设置计时器（此时tn更早，加快下次发送）；
• 将pmembers更新为members。

该算法无法完全避免“大量成员同时离开时，因过早超时导致成员数量估计短暂归零”的情况，但能让估计值更快恢复到正确值。此类场景较为罕见且影响较小，因此仅作为次要问题处理。

6.3.5 SSRC超时处理

参与者需定期检查其他参与者是否超时，频率至少为每个RTCP传输间隔一次，步骤如下：

1. 计算接收者的“确定性计算间隔”Td（即we_sent=false时的Td，见第6.3.1节）；
2. 对于成员表中的其他会话成员：若自(tc - M×Td)（M为超时常数，默认值为5）以来未收到其RTP或RTCP数据包，则判定为超时——从成员表中删除其SSRC，并更新members值；
3. 对发送者表执行类似检查：若自(tc - 2T)（过去两个RTCP报告间隔）以来未收到某发送者的RTP数据包，则从发送者表中删除其SSRC，并更新senders值。

若有任何成员超时，应执行第6.3.4节的反向调整算法。

6.3.6 传输计时器到期

当数据包传输计时器到期时，参与者需执行以下操作：

1. 按第6.3.1节（含随机化）计算传输间隔T；
2. 若(tp + T ≤ tc)：
   • 发送RTCP数据包；
   • 将tp更新为tc；
   • 重新计算T，并将tn设为(tc + T)；
   • 按新的tn设置计时器；
3. 若(tp + T > tc)：
   • 不发送RTCP数据包；
   • 将tn设为(tp + T)；
   • 按新的tn设置计时器；
4. 将pmembers更新为members。

若发送了RTCP数据包：

• 将initial设为false；
• 更新平均RTCP包大小：avg_rtcp_size = (1/16)×发送包大小 + (15/16)×当前avg_rtcp_size（“发送包大小”为刚发送的RTCP数据包的实际大小）。

6.3.7 发送BYE数据包

参与者离开会话时，需发送BYE数据包通知其他参与者。为避免大量成员同时离开时出现BYE包“洪泛”，若参与者决定离开时的成员数量>50，必须执行以下退避算法（此时members变量将用于计数BYE包，而非成员数量）：

1. 参与者决定离开时：
   • 将tp重置为当前时间tc；
   • 将members和pmembers初始化为1；
   • 将initial设为1（true）；
   • 将we_sent设为false；
   • 将senders设为0；
   • 将avg_rtcp_size设为“复合BYE数据包的大小”；
   • 计算间隔T，将BYE包的发送时间设为(tn = tc + T)。
2. 每次收到其他参与者的BYE包时：
   • 无论该参与者是否在成员表中，也无论是否启用SSRC采样，均将members加1；
   • 仅接收BYE包时更新avg_rtcp_size，接收其他RTCP或RTP包时不更新；
   • 收到RTP包时不更新senders（保持为0）。
3. 按“常规RTCP数据包的发送规则”发送BYE包。

该机制允许BYE包尽快发送，同时控制总带宽占用。最坏情况下，RTCP控制包的带宽可能达到正常情况的两倍（10%）——5%用于非BYE RTCP包，5%用于BYE包。

若参与者不愿等待上述机制，可直接离开会话且不发送BYE包，最终会被其他成员判定为超时。若参与者决定离开时的成员数量≤50，可立即发送BYE包，或选择执行上述退避算法。无论哪种情况，从未发送过RTP或RTCP数据包的参与者，离开时不得发送BYE包。

6.3.8 更新we_sent标识

we_sent标识的取值规则如下：

• 若参与者近期发送过RTP数据包，则为true；否则为false，判断逻辑与“管理发送者表中其他参与者”的逻辑一致。
• 若参与者在we_sent=false时发送RTP数据包：将自身加入发送者表，设we_sent=true，并执行第6.3.4节的反向调整算法（可能缩短发送SR包的延迟）。
• 每次发送新的RTP数据包时，更新发送者表中该参与者的“最后发送时间”。
• 对该参与者执行常规发送者超时检查：若自(tc - 2T)以来未发送RTP数据包，则从发送者表中删除自身，减少发送者计数（senders），并设we_sent=false。

6.3.9 源描述带宽分配

除必填的CNAME项外，本文档还定义了多个源描述（SDES）项（如NAME“用户名”、EMAIL“电子邮件地址”），并支持定义应用特定的RTCP包类型。应用程序在为这些额外信息分配控制带宽时需谨慎——过量占用会降低“接收报告和CNAME”的发送频率，影响协议性能。

建议：单个参与者用于承载额外信息的RTCP带宽，不应超过其分配到的RTCP带宽的20%。此外，无需在所有应用中包含所有SDES项；对于已包含的项，应根据其实用性分配带宽比例。推荐做法是：根据项的典型长度，将带宽比例静态转换为“报告间隔计数”，而非动态估计。

示例：某应用仅发送CNAME、NAME和EMAIL项，且NAME的优先级远高于EMAIL（NAME需在用户界面持续显示，EMAIL仅在请求时显示）。此时：

• 每个RTCP间隔发送“RR包 + 含CNAME项的SDES包”（小会话按最小间隔，平均每5秒一次）；
• 每3个间隔（15秒）在SDES包中增加1个额外项：其中7/8的次数增加NAME项，1/8的次数（每2分钟）增加EMAIL项。

若多个应用通过“参与者的公共CNAME”实现跨应用绑定（如多媒体会议中每种媒体对应一个RTP会话），额外的SDES信息可仅在一个RTP会话中发送，其他会话仅携带CNAME项。分层编码方案的多个会话（见第2.4节）尤其应采用此方式。

6.4 发送者报告与接收者报告

RTP接收者通过RTCP报告包提供接收质量反馈，报告包分为两种类型：发送者报告（SR）和接收者报告（RR），具体使用哪种取决于接收者是否同时为发送者。两者的唯一区别（除包类型码外）是：SR包包含一个20字节的“发送者信息”段，供活跃发送者使用。

• 若某站点在“上次报告后”或“上上次报告后”发送过任何数据包，则发送SR包；
• 否则发送RR包。

SR和RR包均包含0个或多个“接收报告块”——每个块对应“自上次报告以来收到过RTP数据包的同步源”（不对CSRC列表中的贡献源生成报告）。每个接收报告块提供该源的接收统计信息。由于单个SR或RR包最多可包含31个接收报告块，若需报告的源数量超过31，应在初始SR/RR包后堆叠额外的RR包，以容纳所有“自上次报告以来检测到的源”的报告。若所有必要的RR包无法在一个复合RTCP包中容纳（不超过网络路径的MTU），则每个间隔仅包含“能容纳在一个MTU中的子集”，并通过多轮间隔“轮询选择子集”，确保所有源的信息均能被报告。

以下章节将定义两种报告的格式、“配置文件特定的扩展方式”（若应用需额外反馈信息），以及报告的使用方法。转换器和混频器的接收报告细节见第7章。

6.4.1 SR：发送者报告RTCP数据包

SR包由三部分组成，若配置文件定义了扩展，还可包含第四部分“配置文件特定扩展段”。其结构如下（字段含义按 sections 依次说明）：

1. 头部（8字节）

字段	位数	含义
版本（V）	2	标识RTP版本，与RTP数据包一致，本文档定义为2。
填充（P）	1	若设为1，该RTCP包末尾包含额外填充字节（非控制信息，但计入长度字段）。最后一个填充字节的值为“需忽略的填充字节数（含自身）”，且为4的倍数（适配固定块大小的加密算法）。在复合RTCP包中，仅需对最后一个独立包添加填充（因复合包按第9.1节的方法整体加密），且仅在该包上设置P位。此约定有助于附录A.2的头部有效性检查，避免早期实现“在第一个包设P位但在最后一个包添加填充”的错误。
接收报告计数（RC）	5	该包中包含的接收报告块数量，0为有效值。
包类型（PT）	8	固定值200，标识为SR包。
长度	16	该RTCP包的“32位字数量减1”（含头部和填充）。减1使0为有效长度，避免扫描复合包时的无限循环；按32位字计数可省去“是否为4的倍数”的有效性检查。
SSRC	32	生成该SR包的同步源标识符。

2. 发送者信息（20字节，所有SR包均包含）

汇总该发送者的数据传输情况：

字段	位数	含义
NTP时间戳	64	指示发送该报告的墙钟时间（见第4章），可与“其他接收者返回的接收报告中的时间戳”结合，计算到这些接收者的往返传播延迟。接收者需注意：该时间戳的测量精度可能远低于NTP时间戳的分辨率，且不指示测量不确定性（可能未知）。 若系统无墙钟时间但有“系统运行时间”等特定时钟，发送者可使用该时钟计算“相对NTP时间戳”；需选择通用时钟，确保多媒体会话中不同实现的流使用同一时钟。2036年前，相对时间戳与绝对时间戳的最高位不同，可避免无效比较；预计届时将不再需要相对时间戳。 若系统无墙钟或流逝时间概念，可将NTP时间戳设为0。
RTP时间戳	32	与上述NTP时间戳对应，但单位和随机偏移与“数据数据包中的RTP时间戳”一致。对于“NTP时间戳已同步的源”，该字段可用于媒体内和跨媒体同步；媒体无关的接收者可通过该字段估计RTP时钟的标称频率。 注意：该时间戳通常不等于相邻数据数据包的RTP时间戳，而需通过“定期在采样时刻检查墙钟时间”，基于RTP时间戳计数器与实时时间的关系计算得出。
发送者数据包计数	32	发送者自开始传输至生成该SR包时，发送的RTP数据包包总数。若发送者更改SSRC标识符，需重置该计数。
发送者字节计数	32	发送者自开始传输至生成该SR包时，在RTP数据数据包中传输的“负载字节总数”（不含头部和填充）。若发送者更改SSRC标识符，需重置该计数。该字段可用于估计平均负载数据速率。

3. 接收报告块（0个或多个，数量由RC指定）

每个块对应一个同步源，包含该源的接收统计信息。若源因冲突更改SSRC标识符，接收者不应延续之前的统计信息。字段含义如下：

字段	位数	含义
SSRC_n（源标识符）	32	该接收报告块对应的源的SSRC标识符。
丢失比例（fraction lost）	8	自上次发送SR/RR包以来，从SSRC_n源接收的RTP数据包的丢失比例，用“二进制小数点在字段左边缘”的定点数表示（即丢失比例×256后取整数部分）。 丢失比例定义为“丢失数据包数/预期数据包数”（见下一段），实现示例见附录A.3。若因重复包导致丢失数为负，丢失比例设为0。 注意：接收者无法判断“最后一个接收包之后是否有包丢失”；若某源在最近报告间隔内发送的所有包均丢失，则不对该源生成接收报告块。
累计丢失数据包数	24	自开始接收以来，从SSRC_n源丢失的RTP数据包包总数，定义为“预期数据包数 - 实际接收数据包数”（接收数含迟到包和重复包，因此迟到包不计为丢失，重复包可能导致丢失数为负）。 预期数据包数定义为“扩展的最后接收序列号 - 初始接收序列号”，计算方法见附录A.3。
扩展的最高接收序列号	32	低16位为“从SSRC_n源接收的RTP数据包的最高序列号”；高16位为“序列号周期计数”（按附录A.1的算法维护）。 注意：同一会话中不同接收者的“序列号周期计数”可能不同（若启动时间差异较大）。
到达抖动（interarrival jitter）	32	RTP数据包到达时间间隔的统计方差估计值，以时间戳单位表示，为无符号整数。 到达抖动J定义为“一对数据包的‘接收端间隔’与‘发送端间隔’差值的平均偏差（平滑绝对值）”，等效于“两个包的相对传输时间差值”（相对传输时间指“数据包RTP时间戳 - 接收端到达时钟时间”，单位一致）。 设Si为包i的RTP时间戳，Ri为包i的到达时间（RTP时间戳单位），则包i和j的差值D为： (D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)) 每次从SSRC_n源接收数据包包i时，需按以下公式持续计算到达抖动（i和i-1为接收顺序，非序列号顺序）： (J(i)=J(i-1)+(
最后SR时间戳（LSR）	32	从SSRC_n源接收的“最近一个RTCP SR包”中NTP时间戳的中间32位（见第4章）。若尚未接收过SR包，设为0。
自上次SR以来的延迟（DLSR）	32	从接收SSRC_n源的最后一个SR包到发送该接收报告块的延迟，单位为1/65536秒。若尚未接收过SSRC_n源的SR包，设为0。

往返时间计算

设SSRC_r为发送该接收报告的接收者，SSRC_n源可按以下步骤计算到SSRC_r的往返传播延迟：

1. 记录接收该接收报告块的时间A；
2. 用LSR字段计算总往返时间A - LSR；
3. 减去DLSR字段，得到往返传播延迟：(A - LSR - DLSR)。

示例（图2）：时间以“32位字段的十六进制表示”和“等效浮点十进制表示”展示，冒号分隔“16位整数部分”和“16位小数部分”。该延迟可用于粗略衡量接收者的集群距离，但部分链路的双向延迟可能高度不对称。

[1995年11月10日 11:33:25.125 UTC] —— SR(n)发送
[1995年11月10日 11:33:36.5 UTC] —— A = 0xb710:8000（46864.500秒）

• LSR = 0xb705:2000（46853.125秒）
• DLSR = 0x0005:4000（5.250秒）
• 往返延迟 = A - LSR - DLSR = 0x0006:2000（6.125秒）

6.4.2 RR：接收者报告RTCP数据包

RR包的格式与SR包基本一致，仅存在两点区别：

1. 包类型字段（PT）的固定值为201；
2. 省略“发送者信息”的5个32位字（即NTP时间戳、RTP时间戳、发送者数据包计数、发送者字节计数）。

其余字段（头部、接收报告块、配置文件特定扩展）的含义与SR包完全相同。若无需报告任何数据传输或接收情况，可发送“接收报告计数RC=0”的RR包。

6.4.3 扩展发送者报告与接收者报告

若应用需定期报告“发送者或接收者的额外信息”，配置文件应定义发送者报告和接收者报告的“配置文件特定扩展”。该方式优于“定义新RTCP包类型”，因其开销更低：

• 包中字节数更少（无需RTCP头部或SSRC字段）；
• 解析更简单快速（该配置文件下的应用可直接在“接收报告块后的固定位置”读取扩展字段）。

扩展部分为报告包的第四部分，位于接收报告块之后（若存在）：

• 若需额外发送者信息，SR包的扩展部分应首先包含该信息，RR包则不包含；
• 若需包含接收者信息，该数据应组织为“与现有接收报告块并行的数组”——块数量由RC字段指定。

6.4.4 分析发送者报告与接收者报告

接收质量反馈不仅对发送者有用，对其他接收者和第三方监控器也具有价值：

• 发送者可根据反馈调整传输策略；
• 接收者可判断问题是本地、区域还是全局的；
• 网络管理员可使用“仅接收RTCP包、不接收RTP数据包”的“与配置文件无关的监控器”，评估网络的多播分发性能。

1. 累计计数的用途

发送者信息和接收报告块均使用累计计数，可通过“任意两次报告的差值”计算“短期和长期的测量结果”，并提高“报告丢失时的容错性”：

• 两次接收报告的“累计丢失数据包数差值”为“该间隔内的丢失数”；
• “扩展最高接收序列号差值”为“该间隔内的预期数据包数”；
• 两者的比值为“该间隔内的数据包丢失比例”（若两次报告连续，该比值应等于“丢失比例”字段的值，否则可能不等）；
• 丢失速率（每秒丢失数）= 丢失比例 / NTP时间戳差值（秒）；
• 接收数据包数 = 预期数据包数 - 丢失数据包数；
• 预期数据包数还可用于判断丢失估计的统计有效性（例如，5个包丢1个的显著性低于1000个包丢200个）。

2. 第三方监控器的计算

第三方监控器无需接收数据，即可通过发送者信息计算：

• 某间隔内的平均负载数据速率和平均数据包速率；
• 两者的比值为平均负载大小；
• 若假设“数据包丢失与包大小无关”，则“某接收者的接收数据包数 × 平均负载大小（或对应包大小）”为该接收者的表观可用吞吐量。

3. 短期测量指标

• 丢失比例字段：提供单次报告中的短期丢失测量结果。当会话规模大到“无法为所有接收者保存状态”，或报告间隔长到“仅能收到某接收者的一次报告”时，该字段尤为重要。
• 到达抖动字段：提供网络拥塞的短期测量结果。数据包丢失反映持续性拥塞，抖动反映瞬时拥塞——抖动可能在丢包前预示拥塞。该字段仅为“报告时的抖动快照”，不用于定量分析，而用于“同一接收者不同时间的报告对比”或“同一时间多个接收者的报告对比”（如同一网络内）。为确保跨接收者的可比性，所有接收者必须按同一公式计算抖动。

4. 抖动计算的影响因素

抖动计算基于“表示数据包首个数据采样时刻的RTP时间戳”，因此“采样时刻到数据包发送时刻的延迟变化”会影响抖动结果：

• 音频包时长变化会导致延迟变化；
• 视频编码中，同一帧的所有包时间戳相同但发送时间不同，也会导致延迟变化。

这种“发送前延迟变化”会降低“抖动作为网络行为衡量指标”的准确性，但考虑到接收端缓冲区需适配该变化，仍需纳入计算。当抖动用于对比测量时，“发送前延迟变化的固定分量”会相互抵消，因此仍可观察到网络抖动分量的变化（除非变化极小，此时通常无实际影响）。

6.5 SDES：源描述RTCP数据包

SDES包为三级结构：头部 + 0个或多个块（chunk） + 块内的多个项（item），每个块对应一个源，每个项描述该源的特定信息。其结构如下：

1. 头部（8字节）

字段	位数	含义
版本（V）	2	与SR包一致（见第6.4.1节），值为2。
填充（P）	1	与SR包一致：若设为1，包末尾含额外填充字节（非控制信息，计入长度字段），最后一个填充字节指示需忽略的填充数（含自身），且为4的倍数。
源计数（SC）	5	该SDES包中包含的SSRC/CSRC块数量，0为有效值但无实际意义。
包类型（PT）	8	固定值202，标识为SDES包。
长度	16	与SR包一致：该SDES包的“32位字数量减1”（含头部、块、项和填充）。

2. 块（chunk）

每个块对应一个SSRC/CSRC标识符，后跟0个或多个项，且块需对齐到32位边界。块的结构规则：

• 每个块以32位的SSRC/CSRC标识符开头；
• 每个项由“8位类型字段”“8位文本长度字段（不含该项的2字节头部）”和“文本内容”组成；
• 文本长度最大为255字节（限制RTCP带宽占用）；
• 文本采用RFC 2279[5]定义的UTF-8编码，US-ASCII为其子集，无需额外编码；多字节编码通过“字符最高位为1”标识；
• 项之间连续排列（不单独对齐到32位边界）；
• 每个块的项列表必须以一个或多个空字节结尾：第一个空字节的类型字段值为0（标识列表结束），其后无长度字段；若需对齐到下一个32位边界，需添加额外空字节（该填充与RTCP头部的P位无关）；
• 含0个项的块（4个空字节）为有效值但无实际意义。

3. 块的发送规则

• 终端系统发送的SDES包，仅包含“自身源标识符（与RTP固定头部的SSRC一致）”的一个块；
• 混频器发送的SDES包，需为“每个接收SDES信息的贡献源”包含一个块；若贡献源超过31个，需发送多个完整的SDES包（见第7章）。

4. SDES项类型（仅CNAME为必填项）

以下为当前定义的SDES项类型，部分项可能仅对特定配置文件有用，但所有项类型均来自同一命名空间，以促进共享使用并简化“与配置文件无关的应用”。新项类型可按第15章的描述向IANA注册。

6.5.1 CNAME：标准端点标识符SDES项

结构：

类型（CNAME=1）	长度	用户名@主机名（或仅主机名）…
8位	8位	可变长度（UTF-8编码）

CNAME的核心特性：

1. 由于随机分配的SSRC标识符可能因“冲突检测”或“程序重启”而更改，必须包含CNAME项，以建立“SSRC标识符与源（发送者或接收者）的固定绑定”；
2. 与SSRC标识符类似，CNAME标识符应在同一RTP会话的所有参与者中唯一；
3. 为实现“同一参与者在多个相关RTP会话中使用的多个媒体工具”的绑定，该参与者的CNAME应固定不变；
4. 为便于第三方监控，CNAME应便于程序或人员定位源。

CNAME格式（配置文件未指定其他语法/语义时）：

• 优先采用“user@host”格式；若为单用户系统无用户名，可仅用“host”格式；
• “host”可为以下两种形式之一：
  a. 实时数据来源主机的完全限定域名（FQDN），需符合RFC 1034[6]、RFC 1035[7]和RFC 1123[8]第2.1节的规则；
  b. RTP通信所用接口的“主机数字地址的ASCII表示”（如IPv4的点分十进制表示、IPv6的冒号分隔十六进制表示[23]）；
• 完全限定域名更便于人工观察，且可能无需额外发送NAME项，但在部分操作系统环境中可能难以可靠获取——此类环境中的应用应使用地址的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”“talk”等程序可识别的形式（通常为登录名，非个人姓名）；
• 主机名无需与参与者电子邮件地址中的主机名一致；
• 若应用允许用户从同一主机生成多个源，此语法无法保证每个源的CNAME唯一——需依赖SSRC进一步标识，或由该应用的配置文件指定CNAME的额外语法；
• 若多个应用独立创建CNAME，可能导致“同一参与者在多个相关RTP会话中使用的CNAME不一致”——若需跨媒体绑定，需通过协调工具为每个工具配置相同的CNAME；
• 私有网络地址（如RFC 1918[24]定义的10.0.0.0/8网段）可能非全局唯一，若携带此类地址的RTP包通过RTP级转换器转发到公网，可能导致CNAME重复。为此，应用可提供CNAME配置功能，转换器在需隐藏私有地址时，应将CNAME中的私有地址转换为公网地址（另见RFC 1627[25]）。

6.5.2 NAME：用户名SDES项

结构：

类型（NAME=2）	长度	源的常用名称…
8位	8位	可变长度（UTF-8编码）

含义：描述源的真实名称（如“John Doe, Bit Recycler”），格式由用户自定义。在会议等应用中，该名称最适合显示在参与者列表中，因此可能是“除CNAME外发送频率最高的项”——配置文件可定义此类优先级。NAME值在会话期间应保持不变，但不应依赖其在会话参与者中唯一。

6.5.3 EMAIL：电子邮件地址SDES项

结构：

类型（EMAIL=3）	长度	源的电子邮件地址…
8位	8位	可变长度（UTF-8编码）

格式：符合RFC 2822[9]的电子邮件地址格式（如“John.Doe@example.com”），在会话期间应保持不变。

6.5.4 PHONE：电话号码SDES项

结构：

类型（PHONE=4）	长度	源的电话号码…
8位	8位	可变长度（UTF-8编码）

格式：包含区号、分机号等信息（如“+1-555-123-4567 ext. 890”），格式由用户自定义，在会话期间应保持不变。

6.5.5 LOC：用户地理位置SDES项

结构：

类型（LOC=5）	长度	站点的地理位置…
8位	8位	可变长度（UTF-8编码）

格式：描述用户所在位置（如“123 Main St, Anytown, NY 10001, USA”），格式由用户自定义，在会话期间应保持不变。

6.5.6 TOOL：应用程序或工具名称SDES项

结构：

类型（TOOL=6）	长度	源应用程序/工具的名称和版本…
8位	8位	可变长度（UTF-8编码）

格式：标识生成RTP流的应用程序或工具（如“Vat 4.2”“QuickTime 7.0”），在会话期间应保持不变。该信息对故障诊断和兼容性验证有用。

6.5.7 NOTE：通知/状态SDES项

结构：

类型（NOTE=7）	长度	关于源的通知/状态信息…
8位	8位	可变长度（UTF-8编码）

用途：传递描述源当前状态的临时消息（如“正在通话，无法发言”“研讨会主题：RTP协议优化”）。不得常规发送（避免占用带宽，导致接收报告和CNAME的发送频率降低，影响协议性能）——尤其不应作为用户配置文件的默认项，或自动生成“每日一句”等内容。

发送规则：

• 若需优先发送NOTE项，可降低NAME等其他非CNAME项的传输频率，将带宽分配给NOTE；
• 临时消息失效后，应按原重复频率继续发送几次NOTE项（但文本长度设为0），以通知接收者“消息已失效”；
• 接收者若在“重复频率的小倍数（如20-30个RTCP间隔）”内未收到NOTE项，也应判定其失效。

6.5.8 PRIV：私有扩展SDES项

结构：

类型（PRIV=8）	长度	前缀（长度+字符串） + 扩展值…
8位	8位	可变长度（UTF-8编码）

用途：定义实验性或应用特定的SDES扩展，结构包含两部分：

1. 前缀：8位长度字段 + 字符串，用于标识扩展的唯一来源——定义者应选择“与其他PRIV项不冲突的名称”（如应用名+子类型，或基于自身实体的名称，并在内部协调使用）；
2. 扩展值：填充项剩余长度的字符串，承载具体扩展信息。

注意事项：

• 前缀会占用项的总长度（255字节），因此应尽量简短；
• 不得滥用该机制和有限的RTCP带宽——其设计目的并非满足所有应用的控制通信需求；
• IANA不注册SDES PRIV前缀；若某PRIV项被证明具有通用价值，应将其重新定义为常规SDES项并向IANA注册（无需前缀，简化使用并提高传输效率）。

6.6 BYE：再见RTCP数据包

BYE包用于指示“一个或多个源不再活跃”，其头部字段（版本V、填充P、长度）的含义与SR包一致（见第6.4.1节），其他字段如下：

字段	位数	含义
包类型（PT）	8	固定值203，标识为BYE包。
源计数（SC）	5	该BYE包中包含的SSRC/CSRC标识符数量，0为有效值但无实际意义。
SSRC/CSRC列表	32×SC	不再活跃的源的SSRC或CSRC标识符。
离开原因（可选）	可变	8位长度字段 + 对应长度的文本（UTF-8编码），描述离开原因（如“摄像头故障”“检测到RTP环路”）。若文本未填满“下一个32位边界”，需添加空字节填充（与RTCP头部的P位无关）；若填满则无需空终止符。

发送与转发规则：

• 混频器收到BYE包后，应保持SSRC/CSRC标识符不变并转发；
• 混频器关闭时，应发送BYE包，列出其处理的所有贡献源及自身的SSRC标识符。

6.7 APP：应用程序定义的RTCP数据包

APP包用于“新应用和新功能开发”的实验性场景，无需注册包类型值。若收到“名称未识别”的APP包，应忽略。测试完成且需广泛使用后，建议删除其子类型和名称字段，将其注册为常规RTCP包类型（向IANA申请包类型值）。其结构如下：

字段	位数	含义
版本（V）	2	与SR包一致，值为2。
填充（P）	1	与SR包一致：若设为1，包末尾含额外填充字节（非控制信息，计入长度字段），最后一个填充字节指示需忽略的填充数（含自身），且为4的倍数。
子类型（subtype）	5	用于“在同一名称下定义一组APP包”，或承载应用特定数据。
包类型（PT）	8	固定值204，标识为APP包。
长度	16	与SR包一致：该APP包的“32位字数量减1”（含头部、SSRC/CSRC、名称和应用数据）。
SSRC/CSRC	32	生成该APP包的源的SSRC或CSRC标识符。
名称（name）	32	ASCII编码的4字节字符串，用于标识APP包的类型（如“VAT”“QTV”）。
应用特定数据	可变	承载实验性功能的自定义数据，长度由“长度字段”间接确定。

• name（名称）：4字节
  由定义APP数据包集合的人员指定，需确保与该应用可能接收的其他APP数据包的名称唯一。应用创建者可选择使用应用名称，并协调为其他需要为该应用定义新数据包类型的人员分配子类型值。此外，建议其他人基于自身代表的实体选择名称，并在该实体内部协调名称的使用。名称被解析为4个ASCII字符序列，且大小写字符视为不同。

• application-dependent data（应用相关数据）：变长
  应用相关数据可能出现在APP数据包中，也可能不出现。该数据由应用程序解析，而非RTP协议本身解析。其长度必须是32位的整数倍。