流媒体传输协议之 RTP （上篇）

介绍

Real-time transport protocol (RTP) is the protocol that provides end-to-end transmission services for real-time audio and video interactions. It includes functions such as payload type confirmation, sequence coding, timestamp recording, and quality monitoring. Traditionally, RTP has been paired with UDP as the default protocol for its multiplexing capabilities. However, RTP can also be combined with other suitable protocols when appropriate network conditions are met, enabling it to transmit data to multiple destinations if the underlying infrastructure supports such functionality.

需要注意的是，在RTP中，并没有提供任何机制来确保数据传输的实时性和QoS（质量-of-服务），而是依赖于底层服务来实现这些功能。因此，在这种情况下，并不能保证数据传输的可靠性和有序性。在接收端部分中，则可以根据接收到的数据包中的序列号来重组并恢复丢失的数据包。

RTP 与 RTCP

实时传输协议 (RTP)，传输具有实时特性的数据

RTCP 用于实时传输中的会话管理与 QoS 监控；该协议不具备明确的成员管理和 session 初始建立机制；然而这些机制对于较为宽松的 session 管理来说已经足够完善；该协议不需要嵌入所有应用程序所需的管理功能；RTCP 代表了一种新型实时传输控制协议；该协议遵循应用程序层帧构造和集成处理架构；即 RTP 容易扩展来支持特定内容的需求；同时能够方便地嵌入到某个具体的应用系统中；RTCP 设计上并非全面覆盖所有可能的功能模块

RTP 的使用场景

以下实例阐述了 RTP 的若干关键特征。所选实例旨在展示基于 RTP 应用的基本操作流程，并非专门针对某类特定应用场景进行设计限制。简单多媒体会议系统

一个团队决定通过网络开一场音频会议，并采用了基于IP的分组广播服务。根据某种分配策略，他们成功获得了该组播地址及对应的端口号。其中一端口专门用于传输音频数据，在此过程中另一端口则用于传输相关RTCP控制信息。该组播地址及对应端口号已分配给所有参会成员。若欲实施一定的安全措施，则需对所传输的数据包进行加密处理以确保信息的安全性，并将加密过程中使用的密钥分发给所有参会人员。

这个音频会议软件可能会持续不断地发送长度为20毫秒的音频数据包。每个真实的音频数据包都会以RTP头部分开，并通过UDP协议将其封装并发送出去。RTP包头部标识其类型以便消息发送器根据不同的传输情况相应地进行编码调整。例如对于带宽有限的参与者可以做一些相应的调节或者对网络拥塞作出反应。

像UDP这类网络类型，在某些情况下会出现丢包、乱序以及延迟不确定较长的时间段等问题。为了避免这些意外情况的发生,RTP包中包含有时间戳和序列号字段,这样接收端就可以通过这些信息来重新排列数据包的时间顺序。在以上案例中,我们就可以实现对每个20毫秒的音频数据按顺序播放的目的。在会议环境中处理每个数据源的RTP报文时序重排通常会独立完成,接收端也可以通过序列号来确定丢失了多少报文

由于本小组在开会期间可能会有成员加入或离开该网络会议,因此我们有必要明确具体是哪位成员加入会议,并确认其是否成功接收到了音频数据。每个参与网络会议的客户端会定期通过RTCP端口汇报参与者及其接收到的数据状态,如果发现某人未能正常接收数据,则可能需要相应地调整编码参数。除了参与者的名字之外还有一些附加信息用于调节带宽分配,而当有成员退出视频会议时还需要发送一个RTCP BYE报文

音频和视频会议

如果会议需要同时传送音频和视频信息时

RTP 协议之所以采用这种设计，在于一些与会者会选择仅接收特定类型的媒体数据（如音频数据）。即使这些媒体数据以不同的方式分发——即音频数据和视频数据分别以不同的路径传输——我们仍可通过引用RTCP协议中的时间戳信息来实现对它们的同步播放。

Mixers & Translators

到目前为止，在会议期间我们一直假设所有与会者都希望接收同一格式的媒体数据。值得反思的是，在实际场景中这一假设并不完全合理：其中一些与会者的网络速度较慢甚至难以满足基本需求, 而其他人的速度较快甚至能够轻松处理更高品质的内容. 应该避免强求统一, 而是转而采用RTP级别的中继节点（Mixer）为周边较低带宽用户分发所需的数据.

这个Mixer能够接收不同与会者的音频数据，并将其连接到一个单一的流中；随后将其以低带宽消耗的编码方式进行压缩；最后传递给那些具有低带宽需求的与会者。然后，在RTP头中添加一些特殊标识信息来说明该Mixer包具体连接了多少个与会者。

此外，在应用级防火墙后方的一些与会者可能无法仅依赖IP组播进行访问。在这种情况下，则使得Mixer就失去了作用；他们需要另一种基于RTP级别的中继（Translator）。为此，在防火墙两侧各安装一个Translator是必要的：外部Translator将接收所有来自组播的媒体数据，并通过一个安全通道转发给内部Translator；随后，内部Translator将这些媒体数据转发给内部网络中的与会者。

层编码

多媒体应用可以根据接发能力或网路拥塞状况进行传输速率调节。多数实现将码率管控职责固定于发送端。这与组播模式存在不适应性：由于各数据接发端的带宽状况各异，从而形成瓶颈效应：最狭窄带宽的数据接发方会严重影响整个会议通信质量

基于此, 应将带宽自适应功能分配给接收端. 发送端则需划分不同带宽下的媒体流 (500K, 2M, 5M), 每个指定的组播地址均与特定带宽范围相对应. 数据接收方则根据自身网络状况选择加入相应组播.

RTP payload：RTP 包中传输的数据，比如音频采样数据或者压缩过的视频数据。 RTP packet：由定长 RTP 头部，数据来源者的列表，RTP payload 组成的数据包。一些下层协议可能会自己定义 RTP 的封装格式。一般来说，一个下层协议包只包含一个 RTP 包，但是也有可能多个 RTP 包被合并到一起。 RTCP packet：RTP 控制报文，由定长的 RTC 头部开始，之后会跟着一些结构化的元素，它们在 RTCP 发挥不同功能时，会有不同的结构。通常多个 RTCP 包会被合在一起，通过一个下层协议包一起发送。 Port：传输层协议中用来区分某一主机下不同应用的抽象。RTP 协议依赖更底层网络提供端口机制，继而提供多播的 RTP 和 RTCP 报文。 Transport address：网络地址和端口的组合，用来定位传输层的节点。 RTC media type：一个 RTP Session 中所用到的所有 payload 类型的合集。 Multimedia Session：视频会议组中同时工作的一组 RTP Session。例如，视频会议中的 Audio Session 和 Video Session。 RTP Session：一组参与者利用 RTP 来通讯的组合。一个参与者可以同时加入到多个 RTP Session 中。在 Multimedia Session 中，除非特意将多媒体编码进同一数据流，否则，每个数据流会通过不同的 RTP Session 传输。与会者通过 Transport address 来区分不同的 RTP Session。同一 RTP Session 的不同与会者会共享同一个 Transport address，也可能每个与会者都有自己的 Transport address。在单播的情况时，一个与会者可能用同一对端口（RTP&RTCP）来接收所有其他与会者的数据，也可能对不同的与会者采用不同的端口对（RTP&RTCP）。 Synchronization source (SSRC)：RTP 报文流的一个 Source，由 RTP 头中定义的 32-bit 的 SSRC identifier 来标识，这样做是为了不依赖网络地址。同一个 SSRC 中发送的所有包都具有同一时序和序列号间隔，因此接收者可以通过 SSRC 将收到的数据包分组并排序。一个信号源（麦克风，摄像头，Mixer）的报文流会有由一个 SSRC 的发送器发送。一个 SSRC 可能会随着时间的变化，改变其数据格式，例如音频编码。SSRC 的身份识别码都是随机生成的，但是必须保证整个 RTP Session 中该身份识别码不会重复，这些工作是通过 RTCP 来完成的。如果一个与会者在一个 RTP Session 中发送不同的媒体数据流，那么每个流的 SSRC 必须不同。 Contributing source (CSRC)：RTP Mixer 所混合的所有数据对应的 SSRC 的列表。Mixer 会将一个 SSRC 列表写入 RTP 头中，该列表包含了这个混合报文中包含的所有来源 SSRC。 End system：一个生成 RTP payload 和消费收到的 RTP payload 的应用。一个 End system 可以扮演一个或者多个 SSRC 角色，但是通常是一个。 Mixer：一个中介系统，它接收一个或多个 Source 的数据，随后它可能会改变这些数据的格式，并将它们合并为一个新的 RTP packet。因为，多个输入源的时序通常来说都不一致，所以 Mixer 通常会同步不同源的时间，并生成一个自己的时序来处理合并数据流。所有从 Mixer 输出的数据包都会标记上该 Mixer 的 SSRC。 Translator：一个中介系统，它会转发 RTP packet 但是不改变其原本的 SSRC。 Monitor：一个在 RTP Session 中接收 RTCP 报文的应用，它会总结数据被接收的报告，并为当前分发系统评估 QOS，诊断错误，长期统计。Monitor 可以集成进会议应用中，也可以是独立的第三方应用，只接收 RTCP 报文，但是什么都不发送。 Non-RTP means：为了让 RTP 提供可用服务而加入的协议或者机制。特别是在多媒体会议中，需要一种控制协议来分发组播地址和加密密钥，协调加密算法，定义 RTP payload 格式和 RTP payload 类型的动态映射。

字节序，数据对齐，时间格式

所有整数字段均采用网络字节序（大端序）表示，默认情况下数字常量以十进制形式表示；除非特别说明，默认情况下数字常量以十进制形式表示

所有头部的数据都将在其原始长度的基础上进行对齐处理；例如，在16-bit的情况下，默认会将对齐偏移设置为偶数值；而对于32-bit的数据，默认会将对齐偏移设置为4的倍数；特别地，在填充操作中，默认使用的填充字节是零值。

Wall clock time（绝对日期与时间）采用网络时间协议（NTP）的时间格式来进行记录；它等价于自1900年1月1日零时起至当前为止的总秒数。其中将总时间刻录为一个包含64位无符号定点数值的形式；前32位字段用于存储整数值部分；而后剩下的32位字段则用于记录小数值部分。而RTP则采用了一种更为简化的数据表达方式；它仅利用NTP中64位数据中的中间值部分；即取其前16位来表示整数值；并以后16位来刻画小数值的变化情况。

NTP 标准时钟在2036年会重新回到零点，在此之前完成一次完整的计数周期被视为成功完成。然而RTP仅关注不同 NTP 标准时钟的时间差，并不会受到这一现象的影响。当两对时钟标记处于同一周期范围内时，在模块化的架构下进行相减或比较运算即可确保准确性无需考虑 NTP 的循环特性。

RTP 数据传输协议

RTP 的定长头字段

RTP 头的格式如下：

上图开头部分包含前 96-bit 的数据, 每个 RTP 包都会包含此部分数据. 其中 CSRC 部分仅限于 Mixer 发送的报文中存在. 各字段的意义如下:

Version字段（V）：2位；采用当前版本的是RTP版本号为1的方案；填充字段（P）：1位；填充字节用于报文末尾；最后一个填充字节指示应忽略的总填充字节数目；Padding字段可能被加密算法使用；Extension字段（X）：1位；拓展数据字段启用标志；CSRC计数字段（CC）：4位；标记字段（M）：1位；预设中的标记用于分隔报文帧边界；可定义附加标记以扩展payload类型长度或移除标记以增加其长度；payload类型字段（PT）：7位编码payload格式及意义映射关系；上层应用可动态定义payload类型编码方式；在一个RTP 会话中payload类型可变化但不应用于区分媒体流类型；序列号字段：16位递增计数器用于跟踪报文顺序并检测丢包情况初始值随机化以增强安全性时间戳字段（T）：32位线性增长时间戳必须足够精确支持高精度同步机制当采用采样时钟时应考虑每报文块的时间间隔初始值随机化且同一会话内生成的多个块可共享相同时间戳不同媒体流的时间戳增量步长独立随机化参考时钟同步机制需结合RTCP协议共享各流的时间基准以计算各流间的时间偏移量每一时间戳与参考时钟组成有序对供不同流间同步比较SSRC标识域（SSRC field）:32位唯一标识数据发送源必须随机生成确保同一会话内无重复标识冲突概率极低但客户端仍需持续监控防止冲突情况发生

学习地址

学习地址

文章福利

课程链接

福利内容

**

RTP Session 多路复用

在 RTP 技术中，多路复用功能通过目标传输地址（其中 address：port）来实现；每一个 RTP Session 都对应唯一的传输地址设置

独立的音频流和视频流不应被包含在同一RTP会话中；同样地，在区分不同流时也应避免使用payload类型或SSRC字段来加以区分。若采用同一SSRC字段发送了多路数据流，则可能导致以下问题出现：

假设有两个音频流共享了一个RTP会话，并且采用了相同的SSRC。
其中有一个需要更改编码。
从而引发了payload类型的变化。
然而，在协议中并没有提供一种机制或方法来通知接收端具体是哪个音频流发生了编码的变化

一个 SSRC 仅对应一个特定的时序和序列号配置。当存在多路数据流且每条流具有不同的时钟周期时，则需要为每条流分配独立的时序配置。此外，在这种情况下无法通过序列号来判别出具体是哪一个数据流存在丢包现象。

该RTCP发送者报告与接收者报告仅涉及时间戳与序列号而未包含任何payload类型数据

Mixer 无法将不兼容的两个流合并。

如果一个 RTP Session 中包含了多个媒体流后就会失去如下优势：

使用不同的网络路径或者分配网络资源

只接收某一种媒体数据（网络较差时只接收 audio）

接收方采用不同的处理方式对各类媒体进行区分；通过各自分配独特的SSRC号码并同时仍采用同一个RTP数据流发送的方式，在一定程度上解决了前三项相关问题；然而这种方法仍未能完全满足后两项需求。

预设可能对 RTP 头的改动

这些RTP报文头完全能满足一般应用的需求。如果有必要可以根据预定方案进行必要的调整以适应特定需求 并同时确保检测与统计功能的正常运行

RTP 头拓展

RTP 支持了一个功能模块,该模块允许上层应用程序将自定义信息存储在 RTP 报文头部。如果上层应用接收到无法解析的报文头拓展数据,则这些数据会被忽视。

考虑到这一点, 这个头部扩展功能存在一定的限制条件. 如果补充信息仅适用于特定的 payload 格式, 那么这些信息不应该包含在头部扩展功能中, 而应该放入 payload 部分.

当 RTP 头部中的某一位字段被设置为标志位时，则该头部紧跟一个可变长度的数据扩展段。后跟CSRC列表（若有），则会跟随相应的数据扩展信息。数据扩展段头部采用一十六进制编码来表示该数据扩展段所包含的数量字段的数量值，并排除了首层的数据扩展信息本身占用的空间。由于RTP协议规定每个头部仅允许紧跟单一的数据扩展段，在实际应用中可能存在多种不同类型的扩展数据包类型以供选择使用

每个参与者的 Session 会定期发送控制报文以协调活动安排，在 RTP 控制协议中这种协调机制同样采用组播方式实现高效传播。为了支持实时通信需求 下层协议需支持对数据包及伴随信息（如控制报文）进行多路传输，并需确保各端口能够可靠地将原始数据及伴随信息分隔传输而不发生混淆或丢失。RTCP 协议则具备以下四大核心功能：

核心功能在于提供数据分发质量的反馈信息。这也使得 RTP 作为传输协议的核心功能之一变得尤为重要。它的独特作用不仅与流量控制相关紧，并且紧密关联着拥塞控制机制。这些反馈信息可能直接影响自适应编码机制的运作。通过向所有参与者发送及时准确的信息……利用 IP 组播这样的高效传播机制，在不影响其自身角色的情况下（例如无需加入到特定会话中），网络服务提供商能够接收到有关数据分发问题的状态更新报告。无论是 RTCP 发送方还是接收方，在执行其职责时都会及时地进行状态更新报告提交

RTCP还会给每个RTP源分配了一个恒定的传输层身份标识符（CNAME）。由于SSRC可能在程序重启时发生变动,因此接收端必须依靠CNAME持续追踪每位参与者.此外,在同一个与会者的多路数据流之间建立了关联后，在接收端可以通过同步音频和视频进行实时互动.对于同一媒体内各路信息流的数据同步需求而言,在RTCP报头中包含了必要的NTP以及RTP时间戳标记.

由于这两个关键功能每个与会者都需要传输RTCP报文因此必须合理调节RTCP数据包的传输速率以便于RTP协议在众多终端设备同时加入时不出现故障

还有一个可有可无的功能，RTCP 可以用来共享小量的 Session 控制信息，例如辨认参与者的身份。通常来说，该功能会被那些管理比较松散的 Session 使用。RTCP 可以作为一个方便的与其他参与者沟通的通道，但是你也别期望 RTCP 可以满足一个应用的所有传输控制需求，这类需求往往是通过一个更高层的 Session 控制协议来满足。 这四个功能中，前三个应该会被所有应用场景使用（IP 组播机制下）。RTP 应用的设计者应该避免自己的应用只能工作在单播模式，RTP 应用应该设计成可拓展的，要考虑大量使用者并发时的情况。此外，RTCP 的传输应该根据发送者和接收者角色的不同而分别进行控制，例如一些单项连接，接收者的反馈信息就发不出来。

提醒：请注意：例如指定源组播路由（SSM），仅有一个参与者能够发送数据；其余接收者无法通过组播与其他参与者直接通信。针对这种情况，请考虑全面禁用各接收者的原始RTCP功能；然后，请为此SSM配置一个适配器以支持RTCP功能；以便能够接收到所有反馈信息。

RTCP 包格式

RTCP 定义了许多包类型来传输不同的控制信息：

SR：发送者报告，发送者数据发送和接收的统计。

RR：接收者报告，只接收数据的节点的接收统计。

SDES：Source 描述，包括 CNAME。

BYE：表示退出。

APP：上层应用定制化设置。每个RTCP包都包含一个与RTP类似的固定格式头部段落，在不同的RTCP类型中所携带的数据内容各不相同但都必须满足32-bit对齐的要求。该头部部分具有定长属性并在其中包含一个字段用于标识该块信息的具体大小因此可以方便地将多个这样的RTCP报文合并成一组发送而不必使用分隔符来进行单独分割处理。下层协议则会根据自身的具体需求选择将若干个这样的RTCP报文组合成一个完整的复合包进行传输

复合包中的每个独立 RTCP 报文都是无序的，并且可能以任意方式组合。为了确保协议功能的一致性和可靠性, 需遵循以下规定：

为了实现接收统计（SR|RR）的有效监测，在每个周期内必须确保RTCP复合包的发送频率达到指定的最大带宽；这些RTCP复合包应包含所有与接收统计相关的数据报文以确保准确反馈。

一个新来的接收者需要尽快地获得数据源的 CNAME，因为这有助于它识别每个数据源对应的人，并将这些数据源相互连接以实现同步。因此，在每一个 RTCP 复合包中都需要携带 SDES 标识符（除非该复合包被分割为一半加密另一半明文的内容，这部分内容将在后续章节中详细说明）。

在复合包中对包类型的数量施加限制能够降低错误分发或无关数据被误认为是RTCP包的可能性同时也能提升第一个字中固定比特位的数量这一规定因此要求每个复合包至少包含两种类型的RTCP报文其格式如下：

Encryption prefix: 当一个复合包需要加密时，在其头部插入一个随机生成的32位数作为前缀。若需对RTCP包进行填充，则需将其填充至该RTCP包之后。

SS 或 RR：复合包中第一个 RTCP 包应当是一个响应报文以加快头部数据的校验，在无 RTP 传输的情况下仍需发送空 RR 报文即使该复合包中的其他 RTCP 报文为 BYE 也需如此操作

Additional RRs：当接收的 RTP 数据源自大于 thirty-one 个不同的源时，在前 thirty-one 被记录到 SR 或 RR 报文中之后，则多余的接收报告应紧跟依据标准格式生成的标准报告报文（SR 或 RR）。

SDES：SDES包应包含CNAME标识符，并且每个复合包中都应包含一个完整的SDES报文。当上层应用有特殊需求时，则可适当增加其他类型的SDES报文内容（具体取决于网络带宽的限制）。

APP或BYE类型或其他未定义的RTCP包类型（包括协议中尚未定义的），可能会以任意顺序排列跟随SDES之后，并希望BYE包位于最后（BYE包需与SSRC/CSRC一同传输）。每个独立的RTP参与者在一个报告周期内应发送一个复合RTCP包，并根据带宽情况估算所需时间；若参与数据发送者数量过多，则无法仅靠增大MTU的方法将所有RR报文包含在一个复合包中，则一次只会将部分RR数据装入此复合包中而余下数据则不进行传输；为了确保所有源的所有接收方都能得到报告信息，在多个周期内采用环式循环的方式共享各源接收情况

为了降低数据包传输的成本，在减少资源消耗方面提出了一些建议：通常建议Translator和Mixer在任何情况下都应将来自多个源的RTCP报文合并成一个综合包。下图展示了一个Mixer生成的综合包的具体应用实例：

如果一个composite package（复用包裹）在传输过程中其长度超出下层网络协议的最大传输单元（MTU）限制的话，则会将其分割为多个较小的部分依次发送出去。这一过程将不会对实时通信控制协议（RTCP）中的带宽估计产生任何影响。因为即使Mixer生成并发送出一个较大的数据报被分割成多个较小的数据报发送出去时，在接收端依然必须满足每个数据报都携带响应或确认信息的要求。因此在接收端依然能够对应至少一个参与者以确保Mixer所生成的数据报数量与实际接收的数据报数量基本一致甚至更为紧密。

如果一个客户端接收到它无法解析的一种RTCP类型的包，则必须忽略该包。额外的RTCP包类型会被IANA机构注册。

RTCP 传输周期

RTP的设计思想在于其能够根据不同参与者的数量变化而进行动态调节。例如，在音频会议中同一时段内讲话的人数通常有限（这在内部上限制了音频数据量），因此可以看出组播数据分发所需的带宽资源与参与人数之间并无直接关联。控制信息传递与实时语音传输存在本质区别：每位参与者都会持续不断地发送RTCP报文；如果每个接收报告都是按统一周期发送的话，则RTCP报文传输所需资源将随着参与人数的增长呈线性放大趋势。由此可知，在参与人数增多的情况下应当相应地扩大RTCP报文发送的时间间隔

对于每一个 Session 来说，在线会议系统都会预先设定一个总的带宽限制（Session bandwidth），该值会被分派给每一个独立的与会者。然而，在整个网络系统中，并非所有的网络带宽都会被充分释放出来，在这种情况下系统也会采取硬性规定的方式对各参与者的可用带宽进行严格控制。即使在某些特殊情况下网络的实际可用带宽并没有被完全预留下来的情况下也有可能存在其他的限速措施 但这些限速措施都与当前的具体网络环境密切相关 最终系统将会计算出一个较为合理的 Session 最大使用带宽值 在评估时 可能需要参考实际使用的网络资源情况 或者根据当前 session 的剩余可用传输速率进行动态调整以确保会议的整体通信质量

这些都不涉及媒体数据的具体编码方案选择过程。但会依据带宽容量等因素来决定采用何种压缩格式。一般而言，在 typical audio calls 中, 通常估算 session 内可能同时存在的最大并发参与者数量, 然后基于这一数量推算出 session 所需的整体 bitrates 方法来进行 bandwidth 配置。在 typical audio calls 中, 由于只有一个参与者同时说话, 所以所需 bandwidth 一般与单个说话者的 bitrate 相近（一般情况下, 单个 channel 的 bitrate 在约8kbps 到48kbps之间）。对于采用 layered coding 方案的情况而言, 每一层都会独立地形成一个 RTP session, 这些 session 之间都有各自独立设定的 bandwidth limits.

为调整 RTP 会话中的带宽，在其中应配置一个管理应用程序。然而，在这些音频会议系统中，并非总是如此——它们通常会根据所选编码格式来设置相应的参数。当仅有一个发送者传输数据时，默认设定相应的带宽上限。此外这类音频会议系统也可能因组播网络或其他因素而导致带宽受限。为了确保所有参与者能够同步发送 RTCP 包件，在同一 RTP 会话中参与者必须采用相同的带宽限制。

Session 的带宽评估过程需要关注下层的传输介质和网络层面是否具备一些资源保留机制。同时上层应用同样需要了解 RTP 使用的具体协议类型但无需关心数据链路层面及以下使用的具体协议因为一旦到达数据链路层面的数据包头部就已经各具特色了。

控制报文的传输应当仅限于 Session 带宽极小的一部分以确保传输不受影响。建议将 RTCP 传输限定为 Session 带宽的 5%，因为如此设置可以使媒体数据发送者至少占 RTCP 宽度的四分之一从而保障实时性。在某些配置选项中若发送者数量超过四分之一可能会完全关闭接收报告即使 RTP 协议标准不鼓励这种做法但某些单向链路系统或无反馈需求系统通常会采取此措施以简化操作流程。

RTCP报文中通常会设置稍长的传输间隔以适应系统需求。这种做法的效果是，在参与者数量激增时也不会让报文数量超出带宽限制太多。在应用程序启动阶段，在等待一段时间（通常等于最小RTCP报文间隔的一半）之后才发送第一个RTCP报文。这种安排有助于使发送间隔计算更快地达到稳定状态。建议将RTCP报文中设置的最小间隔时间设定为5秒。

改写说明

在组播形式中使用的Session中，在这种情况下，在这种情况下，在这种情况下，在这种情况下，在这种情况下，
仅限于数据发送者的某些特定场景中，
而单播下的Session可能出现的情况是，
无论由谁发起通信，
都会有可能出现比标准RTCP发包周期更短的时间段，
并且在这种情况下，
可能会出现初始RTCP报文不等待的情况。
所有Session都应基于最小RTCP发包周期来设定参与者的时间超限。
推荐采用计算方法：将360千比特每秒除以带宽值。
这样当Session带宽超过72kb/s时，
RTCP发包周期将低于5秒。
此外，
现有的算法还具有如下特点：

RTCP 报文发送频率会随着参与的 Session 成员数量增加而呈线性递减趋势。为了防止大量参与者同时向系统发送 RTCP 包导致资源饱和现象发生，在 RTCP 发包之间通常会设置一定的间隔时间，并通过动态调整该间隔时间来优化系统性能。在 RTCP 复合包中所包含的控制报文数据量会根据实际收发情况不断变化以适应实时需求。由于 RTCP 包的时间间隔是基于当前已知参与者的数量信息计算得出的，在新的参与者加入现有 Session 时可能会导致对整个 Session 规模的误判进而选择一个较短的时间间隔作为 RTCP 发送周期这可能导致在 Session 规模持续增长的过程中出现部分 RTCP 包无法及时发送的情况因此就需要引入一个称为"重传时机重新安排"算法来进行优化工作以保证能够适当撤回一些过期不再需要的 RTCP 包提高整体系统的运行效率。当某个参与者通过发送 BYE 报文或者因超时退出当前 Session 时系统会自动缩短当前 RTCP 发送周期以此减少不再活跃参与者的占用资源从而提高系统的整体响应速度和处理能力.BYE 报文作为一种特殊类型的报文其主要特点在于可以在下一个数据传输周期之前就向相关接收端发送退出指令这对于减少资源浪费具有重要意义

维护 Session 成员的数量

我们已掌握，在确定 RTCP 发送间隔之前必须明确整个会话中的参与者数量。每当检测到一个新的成员时，则需将其纳入参与计数，并登记进一个 SSRC（CSRC）身份识别表中以便持续追踪此成员的信息。仅当接收该新成员的多条数据包或接收到其 SDES 包（CNAME）后才认为该新成员值得信赖。一旦某个节点发送BYE命令后其相关信息可能即将被移除为此类情况通常需预先进行处理以避免潜在的问题影响系统稳定性。于是将该事件标记为‘接收到BYE事件’随后等待一段时间若未接收到其后续消息则将其移除以防止误报导致的数据丢失问题发生

当某个节点连续超过一个RTCP周期未接收到来自另一方的报文时

对于那些参与者特别多的会话（Session），可能无法有效地管理一个SSRC（Sequence Numbered Resource Component）表来存储所有参与者的详细信息。常见的做法是将该表进行优化设计以减少所需存储空间和计算开销。需要注意的是，在进行任何优化时不能忽视参与者的总数，并且对总人数的估算可以在合理范围内进行调整以适应实际情况。

RTCP 报文的收发规则

首先，在RTCP间隔设置上存在统一要求的情况下，无论是采用组播机制还是多节点单播方式，在RTCP间隔设置上存在统一要求。为了确保RTCP报文能够正确收发并实现预期通信效果，在Session中所有参与方均需持续记录并传输相关信息。

TP：最后RTCP报文的发送时刻；TC：当前时刻；TN：下一个待发送RTCP报文的时间点；P-Members：用于计算下一个时间点之前Session成员数量的数据；Members：参与数据传输的参与者数量；Senders：负责数据传输的具体参与者数量；RTCP_BW：RTCP的目标带宽指标；WE_Sent：在倒数第二个RTCP报文之后是否存在后续数据发送记录；AVG_RTCP_Size：考虑传输层和网络层头部信息后的平均RTCP复合包大小；initial：当前Session是否处于无RTCP报文状态。

计算 RTCP 发送间隔

为了确保 RTP 协议的可伸缩性特性，在 RTCP 中设置发送速率与会话总数之间的动态关联关系。结合上述的关键状态信息来计算 RTCP 包间时间。

当媒体报道的数量低于总人数的25%，此时间隔与当前节点是否属于媒体报道相关（通过WE_Sent进行判断）。若当前节点是该媒体报道的一方，则其RTCP周期计算式可表示为Senders乘以AVG_RTCP_SIZE除以(25%乘以RTCP_BW)；而作为另一方，则其RTCP周期计算式则可表示为(Members减去Senders)乘以AVG_RTCP_SIZE除以(75%乘以RTCP_BW)。当媒体报道的数量超过25%，则该媒体报道与另一方将采用相同的RTCP周期处理方式。

当某个接收者尚未完整地发送完一个RTCP包时，在计算最小发送间隔（Tmin）时，默认设置将其设定为2.5秒；但如果该接收者已经成功地完成了至少一个完整的RTCP包传输，则将Tmin设定为5秒

决定的发送间隔（Td）会是第一步计算的值和 Tmin 中较大的那个。

发包时会在 Td 的基础上随机缩放 0.5~1.5 倍。

为了计算出最终的间隔值，则需将该值除以e^(-3/2)，即约等于1.21828。这一步骤是为了修正由于‘发送时机重整’算法所带来的误差（这是因为该算法会导致实际使用的RTCP带宽低于预期的带宽）。

初始化

当一个人首次加入Session时

接收 RTP 和 Non-BYE RTCP 包

当RTP或RTCP数据包被另一方（A）接收时，若对于A而言该数据包的SSRC标识未曾见过，则该SSRC将被记录于SSRC表中，并更新会话参与人数（Session Members）。对于每个CSRC也将执行类似的处理流程。

如果接收到了一个 RTP 报文，并且其关联的 SSRC 不在发送者 SSRC 表中，则会将其加入发送者 SSRC 表中，并更新发送者的总数（Senders）。

每当接收一个复合RTCP报文时, 其平均RTCP报文大小（AVG_RTCP_Size）的值将被更新. 计算公式如下: AVG_RTCP.Size = (1/16) × last_rtcp_package_size + (15/16) × previous_avg_rtcp_size.

接收 RTCP BYE 报文

当接收到RTCP BYE报文时，在成员列表中进行核实：如果发现相应的SSRC字段，则将其从成员列表中删除，并更新当前的成员总数（即Members）。与此同时，在发送者的SSRC表中也会执行类似的步骤：一旦找到该SSRC字段，则将其从发送者的SSRC表中删除，并相应地更新发送者的总数量（即Senders）。

为使 RTCP 的传输率自动根据 Session 中人数的变化而调整；当接收到 BYE 消息时触发：该算法运行。

TN 按照如下公式更新：TN = TC + (Members / P-Members) * (TN - TC) 。

TP 按照如下公式更新：TP = TC - (Members / P-Members) * (TC - TP) 。

下一个 RTCP 报文按照新的 TN 指示发送（比原来发的更早了）。

将 P-Members 参数设定为 Members 的值。该算法忽视了一个潜在的情况：当有大量而非全部用户同时退出会话时（而不是所有用户），会导致 RTCP 周期降至极低水平，并可能导致错误地判断 Timeout 事件发生。这种情况虽然偶尔会发生但通常不影响整体运行状态

SSRC 的超时

有时需要检查一下是否很久没有收到某个与会者的报文了；通常情况下，在每个 RTCP 周期内都必须进行确认。如果发现有超时的情况发生，则需要将这个 SSRC 从成员列表 Members & Senders 中删除，并重新计算当前人数

Member表：通常情况下，在连续5个发送周期后没有收到某位用户的消息将被视为已超时（除非考虑了随机扩环因素）。

Sender 表：一般是 2 个发送周期。

如果某个成员被确定为超时，上一步介绍的算法就操作起来了。

发送倒计时

我们已有了解每个RTCP都是定期发送的；一旦完成了一个RTCP报文的传输，则会基于TN建立一个倒计时；每当倒计时归零的时候就会反复执行以下步骤：

计算传输周期 T，引入随机缩放因素。

当TP加上T小于等于TC时，则马上发送一个RTCP报文，并将TP设置为TC；然后将TN设置为TC加T；之后，在TN时刻倒计时会归零。
当TP加上T大于TC时，则不会发送RTCP报文；然后计算并设置TN等于TC加T；之后再进行定时器的重置动作。

P-Member 被设置为 Members. 当发送 RTCP 报文时, initial 会被设置为 FALSE, 并且 AVG_RTCP_Size 按照以下公式更新:

AVG_RTCP_Size = (1 / 16) * last_rtcp_package_size + (15 / 16) * previous_avg_rtcp_size。

发送 BYE 报文

当一名用户决定退出当前的Session时,系统会向其他所有人发送一条BYE报文以通知他们 session 的结束。为了避免在Session人数激增的情况下出现大量BYE报文同时发送的问题,因此一旦Session的人数超过50,系统将采取以下措施:

当一个参与者想要离开时，在TP处会将该字段设置为TC值，在Members和P-Members字段中将数值设为1；初始状态设为1；we_send字段被设为false；发送者数目设为0；avg_rtcp_size字段将被设定为复合BYE报文的大小；随后计算RTCP发送间隔T值；下一个BYE报文将在TN=TC+T的时间段内发送

每当该成员收到他人发送的BYE报文时（无论他是否在当前名单中），他的成员数量会增加1。只有当该成员收到BYE报文时才会增加其成员数量。同样地,avg_rtcp_size仅与所接收的BYE报文大小相关,而发送者数目始终保持不变。

对于BYE报文而言，在状态值维护策略上有所变化的同时，在其他方面均与之前的方法一致。通过上述方案实施后，则可以确保BYE报文能够正确发送并有效管理整体带宽使用情况；即使在最糟糕的情况下（worst case scenario），也会仅导致RTCP报文中占有的Session总带宽比例为10%左右（approximately 10%）。此外，在某些情况下（situations），有一些参与者可能会选择不遵循上述方法发送数据而离开系统（exit）

当某个参与者决定离开时，若 Session 总人数降至 50 以下，则该参与者可能会向系统发送 BYE 报文；或者遵循前述步骤操作。

除此之外还有一个无论何时都必须要遵守的规定：如果一个用户在一个 RTP 报文或者 RTCP 报告都没提交过的话 那么当他离开该会话时绝对无法发出 BYE 告知报告

更新 WE_Sent

当某个参与者在其最近的一段时间内有过一次RTP的发送记录后,系统会将其WE_Sent字段设置为true,并将其加入到Senders表中。如果在超过两个RTCP周期的时间段内未发送任何RTP报文的情况下,则会将其从Senders表中移除,并将WE_Sent字段设置为false。

SDES 类报文的带宽分配

SDES 报文中除了必须包含的 CNAME 之外，并非仅有此一必要信息类别还包含如 NAME（个人名称）、EMAIL（电子邮箱）等其他信息项。上层应用可自行定义某些特定类型的报文格式但需特别注意避免过度地添加自定义信息从而影响整体运行速度建议将这些附加内容占用的比例限定在 RTCP 协议总带宽量的 20%以内为了避免不必要的额外配置上层应用应根据实际情况为这些数据项分配适当的传输容量通常会通过设置发送间隔来控制这部分传输所占比例

例如，在一个应用的 SDES 中通常仅包含 CNAME、NAME 和 EMAIL 其中 NAME 的带宽分配往往比 EMAIL 更为丰富由于 NAME 在所有情况下都会被显示而只有在查看详细信息时才会有EMAIL出现每次 RTCP 发送过程中 SDES 都会包含 CNAME 如果假设 RTCP 周期为5秒则每隔15秒 SDES 才会增添一条除CNAME之外的信息以两分钟为例其中大约有7条是携带NAME信息而仅有1条携带EMAIL信息