6. RTP 控制协议 —— RTCP (RTP Control Protocol -- RTCP)
RTP 控制协议 (RTCP) 基于: 使用与数据报相同的分发机制, 向会话中所有参与者周期性地传输控制包。下层协议 MUST 提供数据与控制包的多路分解 (multiplexing), 例如配合 UDP 使用独立的端口号。RTCP 履行四项功能:
-
首要功能是提供关于数据分发质量的反馈。这是 RTP 作为传输协议角色的一个完整组成部分, 并与其他传输协议的流量与拥塞控制功能相关 (见关于拥塞控制要求的第 10 节)。该反馈对于自适应编码的控制可能直接有用 [18,19], 但 IP 多播实验表明, 它对于从接收方获取反馈以诊断分发中的故障同样关键。将接收反馈报告发送给所有参与者, 使得观察到问题的一方能够评估这些问题是局部的还是全局的。借助像 IP 多播这样的分发机制, 诸如网络服务提供商这样、原本未参与会话的实体, 也可以接收到反馈信息, 并作为第三方监视器 (third-party monitor) 来诊断网络问题。这一反馈功能由 RTCP 的发送方报告与接收方报告履行, 详见下文第 6.4 节。
-
RTCP 为一个 RTP 源携带一个持久性的传输层标识符, 称为规范名称 (canonical name) 或 CNAME, 见第 6.5.1 节。由于 SSRC 标识符在发现冲突或程序重启时可能改变, 接收方需要 CNAME 来跟踪每个参与者。接收方也可能需要 CNAME, 以在某组相关的 RTP 会话中, 关联来自某个给定参与者的多个数据流, 例如用以同步音频和视频。媒体间 (inter-media) 同步还需要由数据发送方包含在 RTCP 包中的 NTP 与 RTP 时间戳。
-
前两项功能要求所有参与者都发送 RTCP 包, 因此必须对速率加以控制, 以使 RTP 能够扩展到大量参与者。通过让每个参与者将其控制包发送给所有其他参与者, 每个参与者都能独立地观察到参与者的数量。该数量被用于计算包发送速率, 如第 6.2 节所述。
-
第四项 OPTIONAL (可选) 功能, 是传递最少量的会话控制信息, 例如要在用户界面中显示的参与者标识。这在 "松散控制 (loosely controlled)" 的会话中最可能有用, 此类会话中参与者无需成员控制或参数协商即可进出。RTCP 作为到达所有参与者的便捷通道, 但不一定预期它能支持一个应用的全部控制通信需求。一个更高层次的会话控制协议 (超出本文档范围) 可能是必需的。
功能 1-3 SHOULD 在所有环境中使用, 但特别是在 IP 多播环境中。RTP 应用设计者 SHOULD 避免仅能在单播模式下工作、且无法扩展到更大数量的机制。如第 6.2 节所述, 对于像单向链路那样无法从接收方获得反馈的情形, RTCP 的传输 MAY 针对发送方和接收方分别进行控制。
资料性 (non-normative) 注释: 在称为源特定多播 (Source-Specific Multicast, SSM) 的多播路由方式中, 每个 "频道" (一个源地址、组地址对) 只有单一的发送方, 并且接收方 (频道源除外) 无法使用多播与其他频道成员直接通信。此处的建议仅通过第 6.2 节中 "完全关闭接收方 RTCP" 的选项来容纳 SSM。未来的工作将规定 RTCP 针对 SSM 的适配, 以保留来自接收方的反馈。
6.1 RTCP 包格式 (RTCP Packet Format)
本规范定义了若干种 RTCP 包类型, 以承载各类控制信息:
SR: 发送方报告 (Sender report), 用于来自活跃发送方的传输与接收统计。
RR: 接收方报告 (Receiver report), 用于来自非活跃发送方的接收统计, 并与 SR 结合用于活跃发送方报告超过 31 个源的情形。
SDES: 源描述项 (Source description), 包括 CNAME。
BYE: 指示参与的结束。
APP: 应用特定的功能。
每个 RTCP 包以一个类似于 RTP 数据报的固定部分开始, 其后跟随结构化元素, 这些元素 MAY 根据包类型而长度可变, 但 MUST 结束于 32 位边界。固定部分中的对齐要求和长度字段, 被纳入以使得 RTCP 包能够 "堆叠 (stackable)"。多个 RTCP 包可以无间隔地拼接, 形成一个复合 RTCP 包 (compound RTCP packet), 在单个下层协议 (如 UDP) 包中发送。复合包中没有单独的 RTCP 包计数, 因为预期下层协议提供整体长度以确定复合包的结束。
复合包中的每个独立 RTCP 包都可以被独立处理, 对包的顺序或组合没有要求。然而, 为了履行协议的功能, 施加如下约束:
o 接收统计 (在 SR 或 RR 中) 应当尽可能频繁地发送, 只要带宽约束允许, 以最大化统计的分辨率, 因此每个周期性发送的复合 RTCP 包 MUST 包含一个报告包。
o 新接收方需要尽快接收到某个源的 CNAME, 以识别该源并开始诸如唇形同步 (lip-sync) 之类的媒体关联, 因此每个复合 RTCP 包 MUST 也包含 SDES CNAME, 除非该复合 RTCP 包为了部分加密而如第 9.1 节所述被拆分。
o 可以出现在复合包首位的包类型的数量需要被限制, 以增加首字 (first word) 中常数位的数量, 以及成功地将 RTCP 包针对错址的 RTP 数据报或其他无关包进行验证的概率。
因此, 所有 RTCP 包 MUST 以至少两个独立包组成的复合包形式发送, 格式如下:
加密前缀 (Encryption prefix): 当且仅当该复合包要按照第 9.1 节的方法被加密时, 它 MUST 以一个随机的 32 位量作为前缀, 该量对每个被传输的复合包重新抽取。如果加密需要填充, 填充 MUST 被添加到复合包的最后一个包。
SR 或 RR: 复合包中的第一个 RTCP 包 MUST 始终是一个报告包, 以便于如附录 A.2 所述的头部验证。即使没有发送或接收任何数据 (此时 MUST 发送一个空的 RR), 甚至即使复合包中唯一的另一个 RTCP 包是 BYE, 也是如此。
额外的 RR: 如果正被报告接收统计的源的数量超过了 31 (即一个 SR 或 RR 包所能容纳的数量), 那么额外的 RR 包 SHOULD 跟随在初始报告包之后。
SDES: 包含 CNAME 项的 SDES 包 MUST 被包含在每个复合 RTCP 包中, 第 9.1 节注明者除外。如果某个特定应用有需要、并受带宽约束 (见第 6.3.9 节), 其他源描述项 MAY 可选地包含在内。
BYE 或 APP: 其他 RTCP 包类型, 包括那些尚未定义的类型, MAY 以任意顺序跟随, 但 BYE SHOULD 是带有给定 SSRC/CSRC 的最后一个被发送的包。包类型 MAY 出现不止一次。
一个独立的 RTP 参与者 SHOULD 每个报告间隔只发送一个复合 RTCP 包, 以使每个参与者的 RTCP 带宽能够被正确估计 (见第 6.2 节), 除非该复合 RTCP 包为了部分加密而如第 9.1 节所述被拆分。如果源太多, 以至于无法将所有必要的 RR 包装入一个复合 RTCP 包而不超过网络路径的最大传输单元 (MTU), 那么每个间隔 SHOULD 只包含在单一 MTU 内能容纳的子集。这些子集 SHOULD 跨多个间隔以轮转 (round-robin) 方式选择, 以便所有源都被报告到。
RECOMMENDED 转换器和混合器在可行时, 将来自它们所转发的多个源的独立 RTCP 包组合成一个复合包, 以分摊包开销 (见第 7 节)。图 1 展示了一个可能由混合器产生的 RTCP 复合包示例。如果某个复合包的总体长度会超过网络路径的 MTU, 它 SHOULD 被分段为多个较短的复合包, 在下层协议的独立包中传输。这并不损害 RTCP 带宽估计, 因为每个复合包至少代表一个不同的参与者。注意, 每个复合包 MUST 以 SR 或 RR 包开始。
实现 SHOULD 忽略那些其类型它未知的入站 RTCP 包。额外的 RTCP 包类型 MAY 按照第 15 节所述, 在互联网编号分配机构 (IANA) 注册。
if encrypted: random 32-bit integer | |[--------- packet --------][---------- packet ----------][-packet-] | | receiver chunk chunk V reports item item item item
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
| | |<----------------------- compound packet ----------------------->| |<-------------------------- UDP packet ------------------------->|
#: SSRC/CSRC identifier
Figure 1: Example of an RTCP compound packet
6.2 RTCP 传输间隔 (RTCP Transmission Interval)
RTP 被设计为允许一个应用自动地跨从几个参与者到数千人的会话规模进行扩展。例如, 在音频会议中, 数据流量本质上是自限的 (self-limiting), 因为一次只有一两个人发言, 因此通过多播分发, 任意给定链路上的数据速率保持相对恒定, 与参与者数量无关。然而, 控制流量并非自限的。如果每个参与者的接收报告都以恒定速率发送, 控制流量将随参与者数量线性增长。因此, 必须通过动态计算 RTCP 包传输之间的间隔, 将速率按比例调低。
对于每个会话, 假定数据流量受一个称为 "会话带宽 (session bandwidth)" 的总量限制, 并要在参与者之间分配。该带宽可能是被预留、并由网络强制执行的。如果没有预留, 则可能根据环境存在其他约束, 确立了会话可使用的 "合理 (reasonable)" 最大值, 那将是 该会话带宽。会话带宽 MAY 基于会话可用网络带宽的某些开销或先验知识来选择。它在某种程度上独立于媒体编码, 但编码的选择可能受到会话带宽的限制。通常, 会话带宽是预期同时处于活跃状态的发送方的标称带宽之和。对于电话会议音频, 这个数通常是一个发送方的带宽。对于分层编码, 每一层都是一个独立的 RTP 会话, 拥有其自身的会话带宽参数。
会话带宽参数预期由会话管理应用在其调用媒体应用时提供, 但媒体应用 MAY 基于为该会话所选编码的单发送方数据带宽设定一个默认值。应用 MAY 也基于多播作用域 (scope) 规则或其他准则来强制执行带宽限制。所有参与者 MUST 为会话带宽使用相同的值, 以计算出相同的 RTCP 间隔。
控制与数据流量的带宽计算包含下层传输与网络协议 (如 UDP 和 IP), 因为资源预留系统需要知道这些。应用也可以预期知道其中哪些协议正在使用。链路层头部不计入计算, 因为包在传输过程中会被封装以不同的链路层头部。
控制流量应当被限制为会话带宽的一个小的、已知的比例: 小, 是为了不损害传输协议承载数据这一主要功能; 已知, 是为了使控制流量能够包含于交给资源预留协议的带宽规格中, 并使每个参与者能够独立地计算其份额。控制流量带宽是数据流量会话带宽之外的额外部分。RECOMMENDED 为 RTCP 所增加的会话带宽比例固定为 5%。也 RECOMMENDED 将 RTCP 带宽的 1/4 专用于正在发送数据的参与者, 这样在接收方多而发送方少的会话中, 新加入的参与者将更快地接收到发送站点的 CNAME。当发送方的比例大于参与者的 1/4 时, 发送方获得完整 RTCP 带宽中属于它们的比例。虽然间隔计算中这些常量及其他常量的值并不关键, 但会话中的所有参与者 MUST 使用相同的值, 以计算出相同的间隔。因此, 这些常量 SHOULD 针对某个特定配置文件固定下来。
一个配置文件 MAY 规定, 控制流量带宽可以是会话的一个独立参数, 而非会话带宽的严格百分比。使用独立参数, 使得速率自适应应用能够设置一个与 "典型" 数据带宽相一致的 RTCP 带宽, 该值低于由会话带宽参数所指定的最大带宽。
配置文件 MAY 进一步规定, 控制流量带宽可以被划分为两个独立的会话参数, 分别针对处于活跃数据发送状态的参与者与非发送状态的参与者; 我们称这两个参数为 S 和 R。遵循 "RTCP 带宽的 1/4 专用于数据发送方" 的建议, 这两个参数的 RECOMMENDED 默认值分别为 1.25% 和 3.75%。当发送方的比例大于参与者的 S/(S+R) 时, 发送方获得这两个参数之和中属于它们的比例。使用两个参数, 可以通过把非数据发送方的 RTCP 带宽设为零、同时保持数据发送方的 RTCP 带宽非零, 来为某个特定会话完全关闭 RTCP 接收报告, 从而发送方报告仍能发送以供媒体间同步之用。关闭 RTCP 接收报告是 NOT RECOMMENDED (不推荐的), 因为它们是第 6 节开头所列功能所必需的, 特别是接收质量反馈与拥塞控制。然而, 对于运行在单向链路上的系统, 或那些不需要关于接收质量或接收方存活状况的反馈、且具备其他避免拥塞手段的会话, 这样做可能是恰当的。
复合 RTCP 包传输之间的计算间隔 SHOULD 还有一个下限, 以避免在参与者数量很少、流量未依据大数定律被平滑时, 出现包突发超过允许带宽。它也使报告间隔在网络分区等瞬时中断期间不至于变得过小, 进而导致分区愈合时适应被延迟。在应用启动时, SHOULD 在发送第一个复合 RTCP 包之前施加一个延迟, 留出时间从其他参与者处接收到 RTCP 包, 使报告间隔更快地收敛到正确值。这个延迟 MAY 被设为最小间隔的一半, 以更快地通知新参与者的存在。固定最小间隔的 RECOMMENDED 值为 5 秒。
实现 MAY 将最小 RTCP 间隔按以下限制缩小为与会话带宽参数成反比的更小值:
o 对于多播会话, 只有活跃的数据发送方 MAY 使用缩小后的最小值来计算复合 RTCP 包的传输间隔。
o 对于单播会话, 非活跃数据发送方的参与者 MAY 也使用该缩小后的值, 并且发送初始复合 RTCP 包之前的延迟 MAY 为零。
o 对于所有会话, 在计算参与者超时间隔 (见第 6.3.5 节) 时 SHOULD 使用固定的最小值, 以便那些在传输 RTCP 包时不使用缩小值的实现, 不会被其他参与者过早地判定为超时。
o 缩小后最小值的 RECOMMENDED 值 (秒) 为 360 除以以千比特/秒计的会话带宽。对于大于 72 kb/s 的带宽, 该最小值小于 5 秒。
第 6.3 节及附录 A.7 中所描述的算法, 旨在满足本节概述的目标。它计算发送复合 RTCP 包之间的间隔, 以在参与者之间分配所允许的控制流量带宽。这使得一个应用能够为小型会话 (例如其中所有参与者的标识都很重要) 提供快速响应, 同时又能自动适应大型会话。该算法包含以下特性:
o 计算的 RTCP 包间隔随组中成员数量线性地缩放。正是这一线性因子, 使得在所有成员求和时控制流量保持恒定。
o RTCP 包之间的间隔在 [0.5,1.5] 倍计算间隔范围内随机变化, 以避免所有参与者的非预期同步 [20]。加入会话后发送的第一个 RTCP 包也以最小 RTCP 间隔一半的随机变化被延迟。
o 计算复合 RTCP 包平均大小的动态估计, 包括所有已接收和已发送的包, 以自动适应所承载控制信息量的变化。
o 由于计算的间隔依赖于观测到的组成员数量, 当新用户加入一个既存会话、或许多用户同时加入一个新会话时, 可能出现不良的启动效应。这些新用户最初会对组成员做出错误估计, 因此他们的 RTCP 传输间隔会过短。如果许多用户同时加入会话, 这个问题可能很严重。为应对此问题, 采用了一种称为 "定时器重新考虑 (timer reconsideration)" 的算法。该算法实现了一个简单的退避 (back-off) 机制, 在组规模增大时使得用户暂缓 RTCP 包的传输。
o 当用户离开会话时 (无论是通过 BYE 还是超时), 组成员数量减少, 因此计算的间隔应当减小。一种 "反向重新考虑 (reverse reconsideration)" 算法被用于让成员更迅速地减小其间隔, 以响应组成员数量的下降。
o BYE 包所受到的对待不同于其他 RTCP 包。当用户离开组并希望发送 BYE 包时, 它可以在其下一个预定的 RTCP 包之前这样做。然而, BYE 的传输遵循一种退避算法, 以避免在大量成员同时离开会话时产生 BYE 包的洪泛。
该算法可用于所有参与者都被允许发送的会话。在这种情况下, 会话带宽参数是单个发送方带宽乘以参与者数量, RTCP 带宽为其 5%。
算法运作的细节在后续各节中给出。附录 A.7 给出了一个示例实现。
6.2.1 维护会话成员数量 (Maintaining the Number of Session Members)
RTCP 包间隔的计算依赖于对参与会话的站点数量的估计。当听到新站点时, 它们被加入计数, 并且 SHOULD 在按 SSRC 或 CSRC 标识符索引的表中 (见第 8.2 节) 为每一个创建一个条目以跟踪它们。新条目 MAY 被认为在收到携带新 SSRC 的多个包之前 (见附录 A.1), 或在收到包含该 SSRC 的 CNAME 的 SDES RTCP 包之前, 尚未有效。当收到带有相应 SSRC 标识符的 RTCP BYE 包时, MAY 从表中删除条目, 只是某些迟到的数据报可能在 BYE 之后到达并导致该条目被重建。取而代之, 该条目 SHOULD 被标记为已收到 BYE, 然后在适当的延迟之后被删除。
如果一个参与者在少量 RTCP 报告间隔内 (RECOMMENDED 为 5) 没有收到任何 RTP 或 RTCP 包, 它 MAY 将另一站点标记为非活跃, 或若其尚未有效则删除它。这提供了一些针对丢包的健壮性。所有站点 MUST 对该乘数使用相同的值, 并且 MUST 对 RTCP 报告间隔计算出大致相同的值, 以使此超时正常工作。因此, 该乘数 SHOULD 针对某个特定配置文件固定下来。
对于具有极大量参与者的会话, 维护一张表来存储所有参与者的 SSRC 标识符和状态信息可能是不切实际的。实现 MAY 使用如 [21] 所述的 SSRC 抽样 (SSRC sampling), 来减少存储需求。实现 MAY 使用任何具有类似性能的其他算法。一个关键要求是, 任何被考虑的算法 SHOULD NOT 大幅低估组规模, 尽管它 MAY 高估。
6.3 RTCP 包发送与接收规则 (RTCP Packet Send and Receive Rules)
此处概述了如何发送 RTCP 包、以及收到 RTCP 包时该做什么的规则。一个允许在多播环境或多点单播环境中运行、且 MUST 满足第 6.2 节要求的实现, MAY 使用本节所定义的算法来满足那些要求, 或者使用其他算法, 只要它提供等同或更好的性能。一个被限定为两方单播运行的实现 SHOULD 仍然使用 RTCP 传输间隔的随机化, 以避免在同一环境中运行的多个实例发生非预期同步, 但 MAY 省略第 6.3.3、6.3.6 和 6.3.7 节中的 "定时器重新考虑" 和 "反向重新考虑" 算法。
要执行这些规则, 一个会话参与者必须维护若干项状态:
tp: 上一次传输 RTCP 包的时间;
tc: 当前时间;
tn: 下一个预定的 RTCP 包传输时间;
pmembers: 上次重新计算 tn 时估计的会话成员数量;
members: 对会话成员数量最新、最当前的估计;
senders: 对会话中发送方数量最新、最当前的估计;
rtcp_bw: 目标 RTCP 带宽, 即本会话所有成员用于 RTCP 包的总带宽, 单位为字节/秒 (octets per second)。这将是启动时提供给应用的 "会话带宽 (session bandwidth)" 参数的一个规定比例;
we_sent: 一个标志位, 若自从上一个 (倒数第二个) RTCP 报告传输以来应用已经发送了数据, 则为 true;
avg_rtcp_size: 本参与者发送和收到的所有 RTCP 包的平均复合 RTCP 包大小, 单位为字节。该大小包含下层传输与网络协议头 (如 UDP 和 IP), 如第 6.2 节所述;
initial: 一个标志位, 若应用尚未发送过 RTCP 包则为 true。
这些规则中有许多使用了包传输之间的 "计算的间隔 (calculated interval)"。该间隔在下一节中描述。
6.3.1 计算 RTCP 传输间隔 (Computing the RTCP Transmission Interval)
为保持可扩展性, 一个会话参与者发出的包之间的平均间隔应随组规模而伸缩。这个间隔称为计算的间隔 (calculated interval)。它由上文描述的若干状态项组合得到。计算得到的间隔 T 按如下方式确定:
-
如果发送方数量小于或等于成员数 (members) 的 25%, 则间隔取决于该参与者是否为发送方 (基于 we_sent 的值)。如果参与者是发送方 (we_sent 为 true), 常数 C 被设为平均 RTCP 包大小 (avg_rtcp_size) 除以 RTCP 带宽 (rtcp_bw) 的 25%, 常数 n 被设为发送方数量。如果 we_sent 不为 true, 常数 C 被设为平均 RTCP 包大小除以 RTCP 带宽的 75%。常数 n 被设为接收方数量 (members - senders)。如果发送方数量大于 25%, 则发送方与接收方一同处理。常数 C 被设为平均 RTCP 包大小除以总 RTCP 带宽, n 被设为成员总数。如第 6.2 节所述, 一个 RTP 配置文件 MAY 规定 RTCP 带宽可由两个独立的参数 (称之为 S 和 R) 显式定义, 分别针对发送方和非发送方的参与者。在这种情况下, 25% 的比例变为 S/(S+R), 75% 的比例变为 R/(S+R)。注意如果 R 为零, 发送方所占百分比永远不会大于 S/(S+R), 且实现 MUST 避免除以零。
-
如果参与者尚未发送过 RTCP 包 (变量 initial 为 true), 常数 Tmin 被设为 2.5 秒, 否则被设为 5 秒。
-
确定性的计算间隔 Td 被设为 max(Tmin, n*C)。
-
计算的间隔 T 被设为一个在确定性计算间隔的 0.5 到 1.5 倍之间均匀分布的数。
-
得到的 T 值除以 e-3/2=1.21828, 以补偿定时器重新考虑 (timer reconsideration) 算法会收敛到低于预期平均值的 RTCP 带宽这一事实。
这一流程产生一个随机的间隔, 但平均而言, 它至少把 RTCP 带宽的 25% 分配给发送方, 其余分配给接收方。如果发送方占成员数的四分之一以上, 该流程平均地在与会者之间平分带宽。
6.3.2 初始化 (Initialization)
在加入会话时, 参与者将 tp 初始化为 0, tc 初始化为 0, senders 初始化为 0, pmembers 初始化为 1, members 初始化为 1, we_sent 初始化为 false, rtcp_bw 初始化为会话带宽的指定比例, initial 初始化为 true, avg_rtcp_size 初始化为应用之后将构造的第一个 RTCP 包的可能大小。然后计算计算的间隔 T, 并将第一个包安排在
时间 tn = T。这意味着设置一个传输定时器, 它在时间 T 到期。注意一个应用 MAY 使用任何期望的方式来实现这个定时器。
参与者将自己的 SSRC 加入成员表。
6.3.3 收到一个 RTP 或非 BYE 的 RTCP 包 (Receiving an RTP or Non-BYE RTCP Packet)
当从一个其 SSRC 不在成员表中的参与者收到 RTP 或 RTCP 包时, 该 SSRC 被加入表中, 并且在该参与者如第 6.2.1 节所述被验证之后, members 的值被更新。对于每个经验证的 RTP 包中的每个 CSRC, 也进行相同的处理。
当从一个其 SSRC 不在发送方表中的参与者收到 RTP 包时, 该 SSRC 被加入表中, 并且 senders 的值被更新。
对于收到的每个复合 RTCP 包, avg_rtcp_size 的值被更新:
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
其中 packet_size 是刚收到的 RTCP 包的大小。
6.3.4 收到一个 RTCP BYE 包 (Receiving an RTCP BYE Packet)
除第 6.3.7 节针对要传输 RTCP BYE 的情形所述之外, 如果收到的包是 RTCP BYE 包, 则将该 SSRC 与成员表比对。如果存在, 该条目被从表中移除, members 的值被更新。然后该 SSRC 与发送方表比对。如果存在, 该条目被从表中移除, senders 的值被更新。
此外, 为使 RTCP 包的传输速率更适应组成员数量的变化, 当收到的 BYE 包使 members 减小到一个小于 pmembers 的值时, SHOULD 执行以下 "反向重新考虑 (reverse reconsideration)" 算法:
o tn 的值按下式更新:
tn = tc + (members/pmembers) * (tn - tc)
o tp 的值按下式更新:
tp = tc - (members/pmembers) * (tc - tp)。
o 下一个 RTCP 包被重新安排在时间 tn 传输, 该时间现在更早。
o pmembers 的值被设为等于 members。
该算法并不能防止组规模估计由于大量参与者同时离开而仅余少数时、因过早超时而在短时间内错误地降到零。该算法确实使估计更迅速地回到正确值。这种情况足够罕见, 且其后果足够无害, 因此此问题仅被视为次要关切。
6.3.5 使一个 SSRC 超时 (Timing Out an SSRC)
在偶发的间隔, 参与者 MUST 检查是否有其他参与者超时。为此, 参与者计算一个接收方的确定性 (不含随机化因子) 计算间隔 Td, 即 we_sent 为 false 的情形。任何自时间 tc - MTd (M 是超时乘数, 默认值为 5) 起一直没有发送 RTP 或 RTCP 包的其他会话成员被认为超时。这意味着它的 SSRC 被从成员列表中移除, members 被更新。对发送方列表执行类似的检查。发送方列表上任何自时间 tc - 2T (在最近两个 RTCP 报告间隔内) 起一直没有发送 RTP 包的成员, 被从发送方列表移除, senders 被更新。
如果有任何成员超时, SHOULD 执行第 6.3.4 节所述的反向重新考虑算法。
参与者 MUST 至少在每个 RTCP 传输间隔执行一次此检查。
6.3.6 传输定时器到期 (Expiration of Transmission Timer)
当包传输定时器到期时, 参与者执行以下操作:
o 如第 6.3.1 节所述计算传输间隔 T, 包含随机化因子。
o 如果 tp + T 小于或等于 tc, 则传输一个 RTCP 包。tp 被设为 tc, 然后如前一步骤再计算一个 T 值, tn 被设为 tc + T。传输定时器被设为在时间 tn 再次到期。如果 tp + T 大于 tc, 则 tn 被设为 tp + T。不传输任何 RTCP 包。传输定时器被设为在时间 tn 到期。
o pmembers 被设为 members。
如果传输了一个 RTCP 包, initial 的值被设为 FALSE。此外, avg_rtcp_size 的值被更新:
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
其中 packet_size 是刚传输的 RTCP 包的大小。
6.3.7 传输一个 BYE 包 (Transmitting a BYE Packet)
当一个参与者希望离开会话时, 传输一个 BYE 包以将该事件通知其他参与者。为避免当许多参与者离开系统时产生 BYE 包的洪泛, 当参与者选择离开时若成员数量大于 50, 该参与者 MUST 执行以下算法。该算法挪用 members 变量的正常角色来转而计数 BYE 包:
o 当参与者决定离开系统时, tp 被重置为 tc (当前时间), members 和 pmembers 被初始化为 1, initial 被设为 1, we_sent 被设为 false, senders 被设为 0, avg_rtcp_size 被设为复合 BYE 包的大小。计算得到的间隔 T 被算出。BYE 包随后被安排在时间 tn = tc + T。
o 每收到另一个参与者发来的一个 BYE 包, members 就加 1, 无论该参与者是否存在于成员表中, 并且在使用 SSRC 抽样时, 无论该 BYE 的 SSRC 是否会被包含在样本中。当收到其他 RTCP 包或 RTP 包时, members 不增, 仅对 BYE 包才增。类似地, avg_rtcp_size 仅为收到的 BYE 包而更新。senders 在收到 RTP 包时不被更新; 它保持为 0。
o BYE 包的传输随后遵循上述传输常规 RTCP 包的规则。
这使得 BYE 包能够被立即发送, 同时又控制其总带宽使用。在最坏情况下, 这可能导致 RTCP 控制包使用两倍于正常的带宽 (10%) —— 5% 用于非 BYE 的 RTCP 包, 5% 用于 BYE 包。
一个不愿等待上述机制允许发送 BYE 包的参与者 MAY 完全不发 BYE 就离开组。该参与者最终将被其他组成员超时。
如果当参与者决定离开时, 组规模估计 members 小于 50, 该参与者 MAY 立即发送一个 BYE 包。或者, 该参与者 MAY 选择执行上述 BYE 退避算法。
无论哪种情况, 一个从未发送过 RTP 或 RTCP 包的参与者在离开组时 MUST NOT 发送 BYE 包。
6.3.8 更新 we_sent (Updating we_sent)
变量 we_sent 在参与者最近发送过 RTP 包时包含 true, 否则为 false。这一判定通过使用与管理发送方表中列出的其他参与者集合相同的机制做出。如果参与者在 we_sent 为 false 时发送了一个 RTP 包, 它把自己加入发送方表, 并将 we_sent 设为 true。第 6.3.4 节所述的反向重新考虑算法 SHOULD 被执行, 以可能缩短发送 SR 包之前的延迟。每发送另一个 RTP 包, 该包的传输时间就被维护在表中。随后对参与者应用常规的发送方超时算法 —— 如果自时间 tc - 2T 以来没有传输过 RTP 包, 参与者将自己从发送方表中移除, 将发送方计数减一, 并将 we_sent 设为 false。
6.3.9 源描述带宽的分配 (Allocation of Source Description Bandwidth)
本规范定义了除强制的 CNAME 项之外的若干源描述 (source description, SDES) 项, 如 NAME (个人姓名) 和 EMAIL (电子邮件地址)。它还提供了一种定义新的应用特定 RTCP 包类型的方式。应用在把这些额外信息的控制带宽分配上应当谨慎, 因为它会降低接收报告和 CNAME 的发送速率, 从而损害协议的性能。RECOMMENDED 把分配给单个参与者的 RTCP 带宽中不超过 20% 用于承载这些额外信息。此外, 并非所有 SDES 项都意图被包含进每个应用。那些被包含的 SHOULD 根据其实用性分配一部分带宽。与其动态地估计这些比例, 不如建议将这些百分比根据项的典型长度静态地转化为报告间隔计数。
例如, 一个应用可以被设计为只发送 CNAME、NAME 和 EMAIL, 而不发送其他项。NAME 可能被赋予比 EMAIL 高得多的优先级, 因为 NAME 会在应用的用户界面中持续显示, 而 EMAIL 仅在被请求时才显示。在每个 RTCP 间隔, 会发送一个 RR 包和一个带有 CNAME 项的 SDES 包。对于一个以最小间隔运行的小型会话, 平均而言那就是每 5 秒一次。每第三个间隔 (15 秒), SDES 包中会包含一个额外的项。八次中有七次这会是 NAME 项, 而每八次 (2 分钟) 则是 EMAIL 项。
当多个应用通过为每个参与者使用共同 CNAME 的跨应用绑定协同工作时 (例如在一个由每个媒体一个 RTP 会话组成的多媒体会议中), 额外的 SDES 信息 MAY 只在某一个 RTP 会话中发送。其他会话只承载 CNAME 项。特别地, 这一方法应当应用于分层编码方案的多个会话 (见第 2.4 节)。
6.4 发送方与接收方报告 (Sender and Receiver Reports)
RTP 接收方使用 RTCP 报告包提供接收质量反馈, 报告包有两种形式, 取决于接收方是否同时也是发送方。发送方报告 (sender report, SR) 和接收方报告 (receiver report, RR) 两种形式之间, 除包类型码之外, 唯一的区别在于发送方报告包含一个供活跃发送方使用的 20 字节发送方信息段。如果一个站点自发出上一个报告或上一个报告以来、在该间隔内发送过任何数据报, 则发出 SR, 否则发出 RR。
SR 和 RR 两种形式都包含零个或多个接收报告块, 每个块对应自上一个报告以来、该接收方收到过 RTP 数据报的每一个同步源。对于 CSRC 列表中列出的贡献源不发出报告。每个接收报告块提供关于该块中所指示的特定源所接收数据的统计。由于一个 SR 或 RR 包中最多只能容纳 31 个接收报告块, SHOULD 在初始的 SR 或 RR 包之后按需堆叠额外的 RR 包, 以包含自上一个报告以来所听到的所有源的接收报告。如果源过多, 无法在不超出网络路径 MTU 的情况下将所有必要的 RR 包装入一个复合 RTCP 包, 则每个间隔 SHOULD 只包含在单个 MTU 中能装下的子集。这些子集 SHOULD 跨多个间隔以轮询 (round-robin) 方式选取, 以使所有源都被报告到。
接下来的几节定义这两种报告的格式、如果应用需要额外的反馈信息它们如何以配置文件特定的方式扩展、以及这些报告如何使用。翻译器和混合器进行接收报告的细节在第 7 节给出。
6.4.1 SR: 发送方报告 RTCP 包 (SR: Sender Report RTCP Packet)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ sender | NTP timestamp, most significant word | info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
发送方报告包由三个段组成, 如果定义了第四个配置文件特定扩展段, 则可能在其后跟随。第一段, 即头 (header), 长 8 字节。各字段含义如下:
version (V): 2 比特 标识 RTP 的版本, 与 RTP 数据报中的版本相同。本规范所定义的版本为二 (2)。
padding (P): 1 比特 如果设置了填充位, 则这个独立的 RTCP 包在末尾包含一些额外的填充字节, 它们不属于控制信息, 但被计入长度字段。填充的最后一个字节是一个计数, 表示有多少个填充字节应当被忽略, 包括它自身 (其应为 4 的倍数)。某些具有固定块大小的加密算法可能需要填充。在一个复合 RTCP 包中, 只需在一个独立的包上填充, 因为对于第 9.1 节的方法, 复合包是作为一个整体加密的。因此, 填充 MUST 只添加到最后一个独立的包, 并且如果该包被添加了填充, 填充位 MUST 只设置在那个包上。这一约定有助于附录 A.2 中描述的头有效性检查, 并能检测出某些早期实现中错误地在第一个独立包上设置填充位、又在最后一个独立包上添加填充的包。
reception report count (RC): 5 比特 本包中包含的接收报告块的数量。值为零是合法的。
packet type (PT): 8 比特 包含常量 200 以标识这是一个 RTCP SR 包。
length: 16 比特 本 RTCP 包的长度, 以 32 位字为单位减一, 包含头和任何填充。(偏移一使得零成为合法长度, 并避免在扫描复合 RTCP 包时出现可能的无限循环, 而按 32 位字计数则避免了对 4 的倍数的有效性检查。)
SSRC: 32 比特 该 SR 包发起者的同步源标识符。
第二段, 即发送方信息 (sender information), 长 20 字节, 出现在每个发送方报告包中。它汇总了该发送方的数据传输。各字段含义如下:
NTP timestamp: 64 比特 指示本报告被发送时的挂钟时间 (wallclock time, 见第 4 节), 以便它可以与其他接收方返回的接收报告中的时间戳结合使用, 来测量到那些接收方的往返传播时间。接收方应当预计到该时间戳的测量精度可能远低于 NTP 时间戳的分辨率。时间戳的测量不确定度未被指示, 因为它可能不为人知。在一个没有挂钟时间概念、但拥有某些系统特定时钟 (如 "系统正常运行时间 (system uptime)") 的系统上, 发送方 MAY 使用该时钟作为参考来计算相对的 NTP 时间戳。选择一种常用时钟很重要, 这样如果采用独立实现来产生多媒体会话的各个流, 所有实现都将使用同一时钟。直到 2036 年, 相对时间戳与绝对时间戳在高位上会有差别, 因此 (无效的) 比较会显示出很大的差异; 到那时, 人们希望相对时间戳将不再需要。一个没有挂钟或流逝时间概念的发送方 MAY 将 NTP 时间戳设为零。
RTP timestamp: 32 比特 与 NTP 时间戳 (上) 对应同一时刻, 但采用与数据报中 RTP 时间戳相同的单位和相同的随机偏移。这一对应关系可用于 NTP 时间戳同步的那些源的媒体内 (intra-media) 与媒体间 (inter-media) 同步, 并可供与媒体无关的接收方用来估计标称的 RTP 时钟频率。注意在大多数情况下, 该时间戳不会等于任何相邻数据报中的 RTP 时间戳。相反, 它 MUST 利用 RTP 时间戳计数器与真实时间之间的关系、通过周期性地在采样时刻检查挂钟时间来维持, 从对应的 NTP 时间戳计算得到。
sender's packet count: 32 比特 自开始传输直到生成此 SR 包之时, 发送方传输的 RTP 数据报总数。如果发送方改变其 SSRC 标识符, 该计数 SHOULD 被重置。
sender's octet count: 32 比特 自开始传输直到生成此 SR 包之时, 发送方在 RTP 数据报中传输的负载字节 (即, 不含头或填充) 总数。如果发送方改变其 SSRC 标识符, 该计数 SHOULD 被重置。该字段可用于估计平均负载数据速率。
第三段包含零个或多个接收报告块, 取决于自上一个报告以来该发送方听到的其他源的数量。每个接收报告块传达关于从单一同步源接收 RTP 数据报的统计。接收方 SHOULD NOT 在源因冲突而改变其 SSRC 标识符时沿用统计。这些统计是:
SSRC_n (source identifier): 32 比特 本接收报告块中的信息所针对的源的 SSRC 标识符。
fraction lost: 8 比特 自上一个 SR 或 RR 包发送以来, 来自源 SSRC_n 的 RTP 数据报中丢失的比例, 以二进制小数点位于字段左边缘的定点数表示。(这等价于将丢失比例乘以 256 后取整数部分。) 此比例定义为丢失的包数除以期望的包数, 如下一段所定义。一种实现见附录 A.3。如果由于重复包而导致丢失为负, fraction lost 被设为零。注意, 接收方无法判断在收到的最后一个包之后是否有任何包丢失, 并且如果在上一个报告间隔内来自该源的所有包都已丢失, 则不会发出该源的接收报告块。
cumulative number of packets lost: 24 比特 自开始接收以来, 来自源 SSRC_n 的 RTP 数据报中已丢失的总数。该数定义为期望的包数减去实际收到的包数, 其中收到的包数包含任何迟到或重复的包。因此, 迟到的包不被计为丢失, 而如果存在重复包, 丢失数可能为负。期望的包数定义为如下定义的扩展的最高序列号减去初始收到的序列号。这可按附录 A.3 所示计算。
extended highest sequence number received: 32 比特 低 16 位包含从源 SSRC_n 收到的 RTP 数据报中的最高序列号, 而最高有效 16 位用相应的序列号循环 (cycle) 计数来扩展该序列号, 该计数可根据附录 A.1 中的算法维护。注意, 同一会话内不同的接收方, 如果其启动时间差异显著, 会为序列号生成不同的扩展。
interarrival jitter: 32 比特 对 RTP 数据报到达间隔时间的统计方差的估计, 以时间戳单位度量, 表示为无符号整数。到达间隔抖动 J 定义为对于一对包, 接收方处包间隔与发送方处相比的差值 D 的平均偏差 (平滑的绝对值)。如下式所示, 这等价于这两个包的 "相对传输时间 (relative transit time)" 之差;
相对传输时间是包的 RTP 时间戳与到达时接收方时钟之差, 以相同单位度量。
若 Si 是包 i 的 RTP 时间戳, Ri 是包 i 以 RTP 时间戳单位计的到达时间, 则对于两个包 i 和 j, D 可表示为
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
到达间隔抖动 SHOULD 随着来自源 SSRC_n 的每个数据报 i 的到达被连续计算, 对该包和前一个包 i-1 (按到达顺序, 不一定按序列顺序) 使用该差值 D, 依据公式
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
每当发出一个接收报告, 就对 J 的当前值进行采样。
抖动计算 MUST 符合此处规定的公式, 以便与配置文件无关的监视器能够对来自不同实现的报告做出有效解释。该算法是最优的一阶估计器, 增益参数 1/16 在保持良好的噪声抑制比的同时维持了合理的收敛速率 [22]。一个示例实现见附录 A.8。关于传输前包时长与延迟变化的影响的讨论见第 6.4.4 节。
last SR timestamp (LSR): 32 比特 从源 SSRC_n 收到的最近一次 RTCP 发送方报告 (SR) 包中、作为其中一部分的 NTP 时间戳 (如第 4 节所述) 的 64 位中的中间 32 位。如果尚未收到 SR, 该字段被设为零。
delay since last SR (DLSR): 32 比特 从收到源 SSRC_n 的最后一个 SR 包到发送此接收报告块之间的延迟, 以 1/65536 秒为单位表示。如果尚未从 SSRC_n 收到 SR 包, DLSR 字段被设为零。
令 SSRC_r 表示发出此接收方报告的接收方。源 SSRC_n 可以通过记录收到此接收报告块的时刻 A 来计算到 SSRC_r 的往返传播延迟。它利用 last SR timestamp (LSR) 字段计算总往返时间 A-LSR, 然后减去此字段, 得到往返传播延迟为 (A - LSR - DLSR)。这在图 2 中说明。时间同时以 32 位字段的十六进制表示和等价的浮点十进制表示显示。冒号表示一个 32 位字段被分为 16 位整数部分和 16 位小数部分的划分。
这可用作对接收方进行聚类的距离的近似度量, 尽管某些链路具有非常不对称的延迟。
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 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 ^ r v ^ RR(n) ----------------------------------------------------------------> |<-DLSR->| (5.250 s)
A 0xb710:8000 (46864.500 s) DLSR -0x0005:4000 ( 5.250 s) LSR -0xb705:2000 (46853.125 s)
delay 0x0006:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation
6.4.2 RR: 接收方报告 RTCP 包 (RR: Receiver Report RTCP Packet)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
接收方报告 (RR) 包的格式与 SR 包相同, 只是包类型字段包含常量 201, 并且省略了五个字的发送方信息 (即 NTP 与 RTP 时间戳, 以及发送方的包计数和字节计数)。其余字段的含义与 SR 包相同。
当没有要报告的数据传输或接收时, MUST 将一个空的 RR 包 (RC = 0) 放在复合 RTCP 包头部。
6.4.3 扩展发送方与接收方报告 (Extending the Sender and Receiver Reports)
如果一个配置文件需要关于发送方或接收方定期报告额外信息, 它 SHOULD 定义对发送方报告和接收方报告的配置文件特定扩展。应当优先使用这种方法, 而不是定义另一种 RTCP 包类型, 因为它需要的开销更小:
o 包中更少的字节 (没有 RTCP 头或 SSRC 字段);
o 更简单快速的解析, 因为在该配置文件下运行的应用会按程序被设定为总是期望在接收报告之后的直接可访问位置出现这些扩展字段。
该扩展是发送方或接收方报告包中的第四个段, 位于接收报告块 (如有) 之后结束时。如果需要额外的发送方信息, 那么对于发送方报告, 它们会首先被包含进扩展段, 而对于接收方报告则不会存在。如果要包含关于接收方的信息, 该数据 SHOULD 被结构化为一个与现有接收报告块数组平行的块数组; 也就是说, 块的数量由 RC 字段指示。
6.4.4 分析发送方与接收方报告 (Analyzing Sender and Receiver Reports)
期望接收质量反馈不仅对发送方有用, 也对其他接收方和第三方监视器有用。发送方可以基于反馈修改其传输; 接收方可以判断问题是局部的、区域性的还是全局的; 网络管理员可以使用与配置文件无关的监视器, 这些监视器只接收 RTCP 包而不接收相应的 RTP 数据报, 以评估其网络在组播分发方面的性能。
在发送方信息和接收报告块中都使用了累计计数, 以便可以在任意两个报告之间计算差值, 从而既能在短时间段也能在长时间段上进行测量, 并能在某个报告丢失时提供韧性。最后收到的两个报告之间的差值可用于估计近期分发的服务质量。包含 NTP 时间戳是为了能够根据两次报告之间的间隔由这些差值计算出速率。由于该时间戳独立于数据编码的时钟速率, 因此可以实现与编码和配置文件无关的服务质量监视器。
一个示例计算是两次接收报告之间间隔内的丢包率。累计丢失包数的差值给出了该间隔内丢失的包数。扩展的最后收到序列号的差值给出该间隔内期望的包数。两者的比值就是该间隔内的丢包比例。如果两个报告是连续的, 该比值应当等于 fraction lost 字段, 否则可能不等。丢包率 (每秒) 可由丢包比例除以以秒表示的 NTP 时间戳差值得到。收到的包数等于期望的包数减去丢失的包数。期望的包数也可用于判断任何丢包估计的统计有效性。例如, 5 个包中丢 1 个, 其意义低于 1000 个包中丢 200 个。
从发送方信息, 第三方监视器可以在不接收数据的情况下计算出某个间隔内的平均负载数据速率和平均包速率。取二者之比即得平均负载大小。如果可以假定丢包与包大小无关, 那么某个特定接收方收到的包数乘以平均负载大小 (或相应的包大小), 就给出了该接收方可用的表观吞吐量。
除了允许利用报告间差值进行长期丢包测量的累计计数之外, fraction lost 字段还提供了来自单个报告的短期测量。随着会话规模扩大到足以使接收状态信息可能无法为所有接收方保留、或报告间的间隔长到可能只收到某个接收方的一份报告时, 这一点变得更加重要。
interarrival jitter 字段提供了网络拥塞的第二个短期度量。丢包跟踪持续性拥塞, 而抖动度量跟踪瞬态拥塞。抖动度量可能在导致丢包之前就指示出拥塞。interarrival jitter 字段只是报告时刻抖动的一个快照, 不打算被定量地解读。相反, 它意在用于跨某个接收方随时间发出的多份报告、或跨多个接收方 (例如在同一网络内、同一时刻) 进行比较。为允许跨接收方比较, 所有接收方都按照同一公式计算抖动这一点很重要。
由于抖动计算基于 RTP 时间戳 (它表示包中第一个数据被采样到的时刻), 在该采样时刻与包被传输的时刻之间任何延迟上的变化都会影响计算所得的抖动。这种延迟变化会发生在时长可变的音频包上。对于视频编码也会发生, 因为同一帧的所有包时间戳相同, 但这些包并非同时传输。在传输之前的延迟变化确实会降低抖动计算作为网络自身行为度量的准确性, 但将其包含在内是恰当的, 因为接收方缓冲必须容纳它。当抖动计算被用作一种比较度量时, 由传输前延迟变化带来的 (恒定的) 分量会被抵消掉, 从而可以观察到网络抖动分量的变化, 除非它相对较小。如果变化很小, 那么它很可能无关紧要。
6.5 SDES: 源描述 RTCP 包 (SDES: Source Description RTCP Packet)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_1 | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_2 | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
SDES 包是一个三级结构, 由头以及零个或多个块 (chunk) 组成, 每个块由描述该块中标识的源的项组成。这些项在后续各节中分别描述。
version (V)、padding (P)、length: 如 SR 包中所述 (见第 6.4.1 节)。
packet type (PT): 8 比特 包含常量 202 以标识这是一个 RTCP SDES 包。
source count (SC): 5 比特 本 SDES 包中包含的 SSRC/CSRC 块的数量。值为零是合法的但无用。
每个块由一个 SSRC/CSRC 标识符后跟一个零个或多个项的列表组成, 这些项携带关于该 SSRC/CSRC 的信息。每个块从 32 位边界开始。每个项由一个 8 位类型字段、一个 8 位字节计数 (描述文本的长度, 因此不包含这个两字节的头) 以及文本本身组成。注意文本长度不能超过 255 字节, 但这与限制 RTCP 带宽消耗的需要是一致的。
文本按照 RFC 2279 [5] 中规定的 UTF-8 编码进行编码。US-ASCII 是该编码的一个子集, 不需要额外编码。多字节编码的存在通过将一个字符的最高有效位设为一来指示。
项是连续的, 即各项不单独填充到 32 位边界。文本不以 null 结尾, 因为某些多字节编码会包含 null 字节。每个块中的项列表 MUST 由一个或多个 null 字节终止, 其中第一个被解释为一个类型为 0 的项, 表示列表结束。null 项类型字节之后不跟长度字节, 但如果有必要, MUST 包含附加的 null 字节以填充到下一个 32 位边界。注意这种填充与 RTCP 头中 P 位所指示的填充是分开的。一个包含零个项的块 (四个 null 字节) 是合法的但无用。
终端系统发送一个包含自身源标识符 (与固定 RTP 头中的 SSRC 相同) 的 SDES 包。一个混合器发送一个 SDES 包, 其中包含它正从中接收 SDES 信息的每个贡献源的块, 或者, 如果有超过 31 个这样的源, 则按上述格式发送多个完整的 SDES 包 (见第 7 节)。
当前已定义的 SDES 项在接下来几节中描述。只有 CNAME 项是强制的。这里展示的某些项可能只对特定的配置文件有用, 但项类型都从同一个公共空间分配, 以促进共享使用并简化与配置文件无关的应用。附加项可以在一个配置文件中通过按第 15 节所述向 IANA 注册类型号来定义。
6.5.1 CNAME: 规范端点标识符 SDES 项 (CNAME: Canonical End-Point Identifier SDES Item)
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 | length | user and domain name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CNAME 标识符具有以下属性:
o 由于随机分配的 SSRC 标识符可能在发现冲突或程序重启时改变, MUST 包含 CNAME 项以提供从 SSRC 标识符到一个对源 (发送方或接收方) 恒定不变的标识符的绑定。
o 与 SSRC 标识符一样, CNAME 标识符 SHOULD 在一个 RTP 会话内的所有参与者之间也保持唯一。
o 为在一个参与者在一组相关 RTP 会话中使用的多个媒体工具之间提供绑定, CNAME 对该参与者 SHOULD 是固定的。
o 为便利第三方监视, CNAME SHOULD 适合程序或人用来定位该源。
因此, 在可能的情况下, CNAME SHOULD 按算法推导而非手动输入。为满足这些要求, 除非某个配置文件规定了另一种语法或语义, 否则 SHOULD 使用如下格式。CNAME 项 SHOULD 采用 "user@host" 的格式, 或者在如单用户系统那样没有可用用户名时采用 "host" 格式。对于这两种格式, "host" 或者是实时数据源自的主机的完全限定域名, 按照 RFC 1034 [6]、RFC 1035 [7] 以及 RFC 1123 [8] 第 2.1 节规定的规则格式化; 或者是该主机用于 RTP 通信的接口上其数字地址的标准 ASCII 表示。例如, IP 版本 4 地址的标准 ASCII 表示是 "点分十进制 (dotted decimal)" (也称为 dotted quad), 而对于 IP 版本 6, 地址以冒号分隔的十六进制数字组文本表示 (细则见 RFC 3513 [23])。预期其他地址类型具有彼此互不相同的 ASCII 表示。完全限定域名对人工观察更方便, 并且可能免去再发送一个 NAME 项的必要, 但在某些运行环境中它可能难以或无法可靠地获得。可能在此类环境中运行的应用 SHOULD 转而使用地址的 ASCII 表示。
例子有, 对多用户系统: "[email protected]"、"[email protected]" 或 "doe@2201:056D::112E:144A:1E24"。在没有用户名的系统上, 例子是 "sleepy.example.com"、"192.0.2.89" 或 "2201:056D::112E:144A:1E24"。
用户名 SHOULD 采用诸如 "finger" 或 "talk" 这类程序可用的形式, 即它通常是登录名而非个人姓名。主机名不一定与该参与者的电子邮件地址中的相同。
如果一个应用允许用户从一台主机产生多个源, 这种语法将无法为每个源提供唯一标识符。这样的应用将不得不依赖 SSRC 来进一步标识源, 或者该应用的配置文件必须为 CNAME 标识符规定附加语法。
如果每个应用独立地创建其 CNAME, 所产生的 CNAME 可能并不相同, 而为一个参与者在一组相关 RTP 会话中多个媒体工具之间提供绑定则要求它们相同。如果需要跨媒体绑定, 可能有必要由一个协调工具为每个工具的 CNAME 外部配置为相同的值。
应用编写者应当意识到, 诸如 RFC 1918 [24] 中提议的 Net-10 分配之类的私有网络地址分配, 可能产生并非全局唯一的网络地址。如果拥有私有地址且没有直接连接到公共互联网的源, 其 RTP 包通过一个 RTP 级翻译器转发到公共互联网, 这就会导致非唯一的 CNAME。(另见 RFC 1627 [25]。) 为处理这种情况, 应用 MAY 提供配置一个唯一 CNAME 的手段, 但如果需要保持私有地址不被暴露, 翻译器负有将 CNAME 从私有地址翻译为公共地址的责任。
6.5.2 NAME: 用户姓名 SDES 项 (NAME: User Name SDES Item)
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 | length | common name of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
这是用于描述源的实名, 例如 "John Doe, Bit Recycler"。它可以是用户期望的任何形式。对于诸如会议之类的应用, 这种姓名形式可能是参与者列表中最适合显示的, 因此可能是除 CNAME 之外那些项中被发送得最频繁的。配置文件 MAY 建立这样的优先级。NAME 值预期至少在会话期间保持恒定。它 SHOULD NOT 被依赖为在会话所有参与者间唯一。
6.5.3 EMAIL: 电子邮件地址 SDES 项 (EMAIL: Electronic Mail Address SDES Item)
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 | length | email address of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
电子邮件地址按照 RFC 2822 [9] 格式化, 例如 "[email protected]"。EMAIL 值预期在会话期间保持恒定。
6.5.4 PHONE: 电话号码 SDES 项 (PHONE: Phone Number SDES Item)
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 | length | phone number of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
电话号码 SHOULD 用加号取代国际接入码来格式化。例如, 美国的号码格式为 "+1 908 555 1212"。
6.5.5 LOC: 地理用户位置 SDES 项 (LOC: Geographic User Location SDES Item)
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 | length | geographic location of site ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
取决于应用, 对此项适合的详细程度不同。对于会议应用, 像 "Murray Hill, New Jersey" 这样的字符串可能就足够, 而对于一个活动徽章系统, 像 "Room 2A244, AT&T BL MH" 这样的字符串可能是合适的。详细程度留由实现和/或用户决定, 但格式和内容 MAY 由某个配置文件规定。LOC 值预期在会话期间保持恒定, 移动主机除外。
6.5.6 TOOL: 应用或工具名 SDES 项 (TOOL: Application or Tool Name SDES Item)
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 | length |name/version of source appl. ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
一个给出正在生成该流的、应用名称以及可能还有版本号的字符串, 例如 "videotool 1.2"。这一信息可能对调试有用, 类似于 SMTP 的 Mailer 或 Mail-System-Version 头。TOOL 值预期在会话期间保持恒定。
6.5.7 NOTE: 通知/状态 SDES 项 (NOTE: Notice/Status SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NOTE=7 | length | note about the source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
本项为该条目建议了如下语义, 但这些或别的语义 MAY 由某个配置文件显式定义。NOTE 项意在承载描述源当前状态的瞬时消息, 例如 "on the phone, can't talk" (正在通话, 无法交谈)。或者, 在研讨会期间, 该项可能被用来传达演讲的标题。它只 SHOULD 被用来承载例外信息, 而不 SHOULD 被所有参与者例行地包含, 因为那会降低接收报告和 CNAME 的发送速率, 从而损害协议性能。特别地, 它 SHOULD NOT 作为用户配置文件中的一个项被包含, 也不 SHOULD 像 "每日一句 (quote-of-the-day)" 那样自动生成。
由于 NOTE 项在其处于活动状态时可能很重要而需要显示, 其他非 CNAME 项 (如 NAME) 的发送速率可能会降低, 以便 NOTE 项能占用那部分 RTCP 带宽。当该瞬时消息变为不活动时, NOTE 项 SHOULD 继续以相同的重复速率发送若干次, 但附带一个长度为零的字符串以向接收方发出信号。然而, 如果接收方在重复速率的较小倍数 (或者可能 20–30 个 RTCP 间隔) 内没有收到 NOTE 项, 它们 SHOULD 也将其视为不活动。
6.5.8 PRIV: 私有扩展 SDES 项 (PRIV: Private Extensions SDES Item)
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 | length | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
本项用于定义实验性的或应用特定的 SDES 扩展。该项包含一个由长度-字符串对组成的前缀, 后跟填充该项剩余部分并携带所需信息的 value 字符串。前缀长度字段为 8 比特长。前缀字符串由定义该 PRIV 项的人选择一个名称, 该名称针对此应用可能收到的其他 PRIV 项保持唯一。如果需要, 应用创建者可以选择使用应用名称再加上一个附加的子类型标识。
或者, RECOMMENDED 其他人基于他们所代表的实体选择一个名称, 然后在该实体内协调该名称的使用。
注意前缀会消耗该项总共 255 字节长度中的一部分, 因此前缀应当尽量短。这一机制和受限的 RTCP 带宽 SHOULD NOT 被过度使用; 它并非意在满足所有应用的所有控制通信需求。
SDES PRIV 前缀不会由 IANA 注册。如果某种形式的 PRIV 项被证明具有普遍用途, 则 SHOULD 转而为其分配一个在 IANA 注册的常规 SDES 项类型, 从而不需要前缀。这简化了使用并提高了传输效率。
6.6 BYE: 告别 RTCP 包 (BYE: Goodbye RTCP Packet)
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 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BYE 包指示一个或多个源不再活跃。
version (V)、padding (P)、length: 如 SR 包中所述 (见第 6.4.1 节)。
packet type (PT): 8 比特 包含常量 203 以标识这是一个 RTCP BYE 包。
source count (SC): 5 比特 本 BYE 包中包含的 SSRC/CSRC 标识符的数量。计数值为零是合法的但无用。
关于何时应当发送 BYE 包的规则在第 6.3.7 节和第 8.2 节中规定。
如果一个 BYE 包被一个混合器收到, 该混合器 SHOULD 原样转发该 BYE 包, 其中的 SSRC/CSRC 标识符保持不变。如果一个混合器关闭, 它 SHOULD 发送一个 BYE 包列出它所处理的所有贡献源, 以及它自身的 SSRC 标识符。可选地, BYE 包 MAY 包含一个 8 位字节计数, 后跟那么多字节的文本, 指示离开的原因, 例如 "camera malfunction" (摄像头故障) 或 "RTP loop detected" (检测到 RTP 环路)。该字符串采用与 SDES 中描述的相同编码。如果字符串恰好填满到下一个 32 位边界, 则字符串不以 null 结尾。如果不是, BYE 包 MUST 用 null 字节填充到下一个 32 位边界。这种填充与 RTCP 头中 P 位所指示的填充是分开的。
6.7 APP: 应用定义的 RTCP 包 (APP: Application-Defined RTCP Packet)
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| subtype | PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application-dependent data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
APP 包用于实验目的, 随着新应用和新特性的开发, 而不需要注册包类型值。名称未被识别的 APP 包 SHOULD 被忽略。在测试之后, 如果证明有更广泛的用途, RECOMMENDED 将每个 APP 包重新定义为不带 subtype 和 name 字段、并使用一个 RTCP 包类型向 IANA 注册。
version (V)、padding (P)、length: 如 SR 包中所述 (见第 6.4.1 节)。
subtype: 5 比特 可用作子类型, 以允许在一组唯一名称下定义一组 APP 包, 或用于任何应用特定的数据。
packet type (PT): 8 比特 包含常量 204 以标识这是一个 RTCP APP 包。
name: 4 字节 由定义这组 APP 包的人选择的一个名称, 针对此应用可能收到的其他 APP 包保持唯一。应用创建者可以选择使用应用名称, 然后协调将 subtype 值分配给那些想要为该应用定义新包类型的人。或者, RECOMMENDED 其他人基于他们所代表的实体选择一个名称, 然后在该实体内协调该名称的使用。该名称被解释为一个由四个 ASCII 字符组成的序列, 大写和小写字符被视为不同。
application-dependent data: 可变长度 应用特定的数据在一個 APP 包中可能出现也可能不出现。它由应用而非 RTP 本身解释。它 MUST 是 32 比特长度的整数倍。, 在该采样时刻与包被传输的时刻之间任何延迟上的变化都会影响计算所得的抖动。这种延迟变化会发生在时长可变的音频包上。对于视频编码也会发生, 因为同一帧的所有包时间戳相同, 但这些包并非同时传输。在传输之前的延迟变化确实会降低抖动计算作为网络自身行为度量的准确性, 但将其包含在内是恰当的, 因为接收方缓冲必须容纳它。当抖动计算被用作一种比较度量时, 由传输前延迟变化带来的 (恒定的) 分量会被抵消掉, 从而可以观察到网络抖动分量的变化, 除非它相对较小。如果变化很小, 那么它很可能无关紧要。