当前位置：首页 > news >正文

音视频入门基础：RTCP专题（3）——RTCP协议简介（中）

news 来源：原创 2025/8/25 9:08:49

本文接着《音视频入门基础：RTCP专题（2）——RTCP协议简介（上）》，继续对RTCP协议进行简介。本文的一级标题从“九”开始。

九、Sender and Receiver Reports

本段内容对应《RFC 3550》的第6.4节。根据《RFC 3550》第29页，RTP 接收器（RTP receivers）使用 RTCP报告数据包提供接收质量反馈，报告数据包（report packets）有两种形式，取决于接收器是否同时也是发送器。除了数据包类型代码外，发送方报告 (sender report，SR) 和接收方报告 (receiver report，RR) 形式之间的唯一区别是，发送方报告包含一个20字节的发送方信息部分，供活动发送方使用。如果一个站点在上次或前一次报告发出后的时间间隔内发送了任何数据包，则发出SR报告，否则发出RR报告。

SR和RR两种形式都包括零个或多个接收报告块，自上次报告后，每个同步源（synchronization sources）都有一个接收报告块（reception report blocks），该接收器从这些同步源接收RTP数据包。对于CSRC列表中列出的贡献源（contributing sources），不发布报告。每个接收报告块都提供从该块所示特定源接收到的数据的统计信息。由于SR或RR 数据包中最多可容纳31个接收报告块，因此应根据需要在初始SR或RR数据包后堆叠附加RR数据包，以包含自上次报告后的间隔期间听到的所有信源的接收报告。如果信号源太多，无法在不超过网络路径MTU的情况下将所有必要的RR数据包放入一个复合 RTCP数据包中，则每个间隔中只应包含可放入一个MTU的子集。应在多个时间间隔内循环选择子集，以便报告所有来源。

《RFC 3550》接下来的章节将定义这两份报告的格式，如果应用需要额外的反馈信息，如何以特定配置文件的方式对其进行扩展，以及如何使用这些报告。《RFC 3550》第7节将详细介绍译码器（translators ）和混合器（mixers）的接收报告。

十、SR: Sender Report RTCP Packet

本段内容对应《RFC 3550》的第6.4.1节：

根据《RFC 3550》第30页，发送方报告数据包（sender report packet）由三个部分组成，后面可能还有第四个特定配置文件的扩展部分（profile-specific extension section，如果已定义）。

（一）第一部分

第一部分是报头（header），长度为8个八位字节。字段含义如下：

version (V)：占2位，标识RTP的版本。RTCP数据包中的版本与RTP 数据包中的版本相同，值都为2。

padding (P)：占1位，为填充位。如果设置了填充位，则该单个RTCP数据包在末尾包含一些额外的填充八位字节，这些八位字节不是控制信息的一部分，而是包含在长度（length）字段中。某些具有固定数据块大小的加密算法可能需要使用填充。在一个复合RTCP数据包中，由于复合数据包是作为一个整体按照《RFC 3550》第9.1节中的方法进行加密的，因此只需要在一个单独的数据包中添加填充。因此，必须只在最后一个单独数据包中添加填充，如果在该数据包中添加了填充，则必须只在该数据包中设置填充位。这一约定有助于进行《RFC 3550》附录A.2所述的包头有效性检查（header validity checks），并能检测出某些早期实现中错误设置第一个单独数据包的填充位并在最后一个单独数据包中添加填充的数据包。

reception report count (RC)：占5位。该数据包中包含的接收报告块（reception report blocks）的数量，值可以为0。

packet type (PT)：占8位。包含常数200，用于将其标识为RTCP SR数据包。

length：占16位。该RTCP数据包的长度（32 位字减去1），包括报头（header）和任何填充（padding）。(1的偏移使0成为有效长度，避免了扫描复合RTCP数据包时可能出现的无限循环，而计算32 位字则避免了对4的倍数进行有效性检查）。

SSRC：占32位。该SR数据包发起方的同步源标识符。

（二）第二部分

第二部分是发送方信息（sender information），长度为20个八位字节，存在于每个发送方报告数据包（sender report packet）中。它总结了该发送方的数据传输情况。字段含义如下：

NTP timestamp：占64位。表示发送此报告时的挂钟（wallclock ）时间（见《RFC 3550》第4节），以便与其他接收机接收报告（reception reports）中返回的时间戳结合使用，测量到这些接收机（receivers）的往返传播。接收方应注意，时间戳的测量精度可能远低于NTP时间戳的分辨率。在没有挂钟时间概念但有一些特定系统时钟（如“系统正常运行时间”）的系统上，发送方可以使用该时钟作为参考来计算相对NTP时间戳。选择一个常用的时钟非常重要，这样如果使用不同的实现来生成多媒体会话的各个数据流，所有实现都将使用相同的时钟。在2036年之前，相对时间戳和绝对时间戳在高位上会有差异，因此（无效）比较会显示很大的差异；希望到那时不再需要相对时间戳。没有挂钟或经过时间概念的发送方可以将NTP时间戳设为零。

挂钟时间（Wallclock time，绝对日期和时间）使用网络时间协议（NTP）的时间戳格式表示，其单位是相对于1900 年1 月1 日0h UTC的秒数。全分辨率NTP时间戳是一个64 位无符号定点数，整数部分在前 32 位，小数部分在后 32 位。在某些需要更紧凑表示的领域，只使用中间的 32 位，即整数部分的低 16 位和小数部分的高 16 位。整数部分的高 16 位必须独立确定。

要使用 RTP，执行程序不需要运行网络时间协议。可以使用其他时间源，或根本不使用时间源（参见RFC 3550》第6.4.1节中对NTP时间戳字段的描述）。不过，运行NTP可能有助于同步从不同主机传输的数据流。

NTP时间戳将在2036年的某个时候归零，但对于RTP而言，只使用NTP时间戳对之间的差值。只要可以假定这两对时间戳相差在68年以内，使用模块化算术进行减法和比较就不会出现绕零现象。

RTP timestamp：占32位。与NTP时间戳（上面的NTP timestamp）对应，但单位和随机偏移量与数据包中的RTP时间戳相同。这种对应关系可用于NTP时间戳同步的源的媒体内和媒体间同步，也可用于独立于媒体的接收器估算名义上的（nominal）RTP时钟频率。请注意，在大多数情况下，该时间戳并不等同于任何相邻数据包中的RTP时间戳。相反，必须利用RTP时间戳计数器与实时时间之间的关系，从相应的NTP时间戳中计算得出，而这种关系是通过在采样瞬间定期检查挂钟时间来维持的。

sender’s packet count：占32位。发送方从开始传输到生成此SR数据包为止传输的RTP数据包总数。如果发送方更改了SSRC标识，则应重置该计数。

sender’s octet count：占32位。发送方从开始传输到生成此SR数据包为止在RTP 数据包中传输的有效载荷（payload ）字节总数（即不包括报头或填充）。如果发送方更改了SSRC标识，则应重置该计数。该字段可用于估算平均有效负载数据速率。

（三）第三部分

第三部分包含0个或多个接收报告块（reception report blocks），取决于自上次报告以来该发件人听到的其他信号源的数量。每个接收报告块都传达了从单个同步源接收RTP数据包的统计数据。当信号源因碰撞而改变其SSRC标识时，接收方不应该继承统计数据。这些统计信息包括：

SSRC n (source identifier)：占32位。该接收报告块中的信息所涉及的源的SSRC标识符。

fraction lost：占8位。自上一个SR或RR数据包发送后，从源SSRC_n丢失的RTP 数据包的分数，以二进制点位于字段左边缘的定点数表示（相当于将丢失分数乘以256后取整数部分）。《RFC 3550》附录A.3列出了实现方法。如果由于重复数据包造成的丢失为负数，则丢失分数设为0。需要注意的是，接收方无法判断在收到最后一个数据包后是否有任何数据包丢失，而且如果在最后一次报告间隔期间从某一数据源发送的所有数据包均已丢失，则不会为该数据源发出接收报告块。

cumulative number of packets lost：占24位。自开始接收以来，从源SSRC_n丢失的RTP数据包总数。这个数字的定义是预期数据包数减去实际接收到的数据包数，其中接收到的数据包数包括任何延迟或重复的数据包。因此，延迟到达的数据包不计入丢失，如果有重复数据包，丢失（loss）可能为负数。预期数据包数的定义是：已收到的扩展最后序列号（定义见下文）减去已收到的初始序列号。计算方法见《RFC 3550》附录A.3。

extended highest sequence number received：占32位。低16位包含从源SSRC_n 接收到的RTP数据包中的最高序列号，最重要的16位用相应的序列号周期计数扩展该序列号，序列号周期计数（count of sequence number cycles）可根据《RFC 3550》附录A.1中的算法进行维护。请注意，如果同一会话中的不同接收方的开始时间相差很大，它们将生成不同的序列号扩展（extensions to the sequence number）。

interarrival jitter：32位。RTP数据包到达时间统计方差的估计值，以时间戳单位测量，用无符号整数表示。到达间抖动 J 定义为一对数据包的接收方与发送方数据包间距差D的平均偏差（smoothed absolute value，平滑绝对值）。如下式所示，这相当于两个数据包的 “相对传输时间（relative transit time） ”之差；相对传输时间是数据包的 RTP时间戳和接收器时钟在到达时的差值，以相同单位测量。

如果Si是数据包i的RTP时间戳（RTP timestamp），Ri是数据包i以 RTP时间戳为单位的到达时间，那么对于两个数据包i和j，D可以表示为：

D(i, j)=(Rj − Ri) − (Sj − Si)=(Rj − Sj ) − (Ri − Si)

从源SSRC_n接收到每个数据包i时，应连续计算到达间抖动（interarrival jitter），利用该数据包与前一个数据包i - 1的差值D，按到达顺序（不一定是先后顺序），计算公式为：

J(i) = J(i − 1) + (|D(i − 1, i)| − J(i − 1))/16

每当接收报告（reception report）发出时，J 的当前值就会被采样。抖动（jitter）计算必须符合此处指定的公式，以便独立于配置文件的监测器对来自不同实现的报告做出有效解释。该算法是最佳的一阶估计器，增益参数 1/16 在保持合理收敛速度的同时，还提供了良好的降噪比（noise reduction）。《RFC 3550》附录A.8展示了一个实现示例。关于不同数据包持续时间和传输前延迟的影响，请参见《RFC 3550》第6.4.4节。

last SR timestamp (LSR)：占32位。作为源SSRC_n 最近RTCP发送方报告 (SR) 数据包的一部分接收到的NTP时间戳（如《RFC 3550》第4节所述）64位中的中间32位。

delay since last SR (DLSR)：占32位。从源SSRC_n接收最后一个SR数据包到发送此接收报告块之间的延迟，单位为1/65536秒。如果尚未收到来自SSRC_n的SR数据包，则DLSR字段置0。

让SSRC_r表示发布该接收报告的接收者（receiver）。源SSRC_n可通过记录收到该接收报告块的时间A，计算到SSRC_r 的往返传播延迟。它使用最后SR时间戳（last SR timestamp，LSR）字段计算总往返时间A-LSR，然后减去该字段，得出往返传播延迟为（A-LSR-DLSR）。下图举例说明了这一点。时间显示为32位字段的十六进制表示法和等效的浮点十进制表示法。

虽然有些链路的延迟很不对称，但这可以作为群集接收器距离（cluster receivers）的近似度量。

十一、RR: Receiver Report RTCP Packet

本段内容对应《RFC 3550》的第6.4.2节：

根据《RFC 3550》第35页，接收方报告（RR）数据包的格式与SR数据包的格式相同，只是数据包类型字段包含常量201，且省略了五个发送方信息（sender information）字段（这些是NTP和RTP时间戳以及发送方数据包和八进制数）。其余字段的含义与SR数据包相同。

当没有数据发送或接收报告时，必须在复合RTCP数据包的头部放置一个空RR数据包（RC = 0）。

十二、Extending the Sender and Receiver Reports

本段内容对应《RFC 3550》的第6.4.3节。根据《RFC 3550》第35页，如果需要定期报告有关发送方或接收方的其他信息，则配置文件应定义发送方报告和接收方报告的特定配置文件扩展（profile-specific extensions）。应优先使用这种方法，而不是定义另一种RTCP数据包类型，因为它所需的开销较少：

1.数据包中的八位字节较少（无RTCP头或SSRC字段）；

2.扩展字段（extension fields）是发送方或接收方报告数据包中的第四部分，位于接收报告块（如有）之后的末尾。如果需要额外的发件人信息（additional sender information），那么对于发件人报告（sender reports），这些信息将首先包含在扩展部分，但对于收件人报告（receiver reports），这些信息将不会出现。如果要包含接收方信息，数据结构应为与现有接收报告块数组平行的块数组；也就是说，块数（the number of blocks）将由RC字段表示。

十三、Analyzing Sender and Receiver Reports

本段内容对应《RFC 3550》的第6.4.4节。根据《RFC 3550》第36页，预计接收质量反馈（reception quality feedback）不仅对发送方（sender）有用，而且对其他接收方（receivers）和第三方监测器（third-party monitors）也有用。发送方可根据反馈修改其传输；接收方可确定问题是局部的、区域性的还是全球性的；网络管理员（network managers）可使用只接收RTCP数据包而不接收相应RTP数据包的独立于配置文件的监控器（profile-independent monitors）来评估其网络的组播分发性能。

发送方信息（sender information）和接收方报告块（receiver report blocks）中都使用了累积计数（Cumulative counts），这样就可以计算任意两份报告之间的差值，从而对长短时间段进行测量，并提供防止丢失报告的复原力。最后收到的两份报告之间的差值可用来估计最近的分发质量。其中包含NTP时间戳（NTP timestamp），这样就可以根据两份报告之间的差值来计算速率（rates）。由于时间戳与数据编码的时钟速率无关，因此可以实现与编码和配置文件无关的质量监控器（quality monitors）。

一个计算实例是两次接收报告之间的数据包丢失率（packet loss rate）。累计丢包数的差值就是该时间间隔内的丢包数。最后收到的扩展序列号的差值给出了该时间间隔内的预期数据包数量。两者的比值就是该时间段内的数据包丢失率。如果两份报告是连续的，则该比率应等于丢失分数段，否则可能不相等。用丢失分数除以NTP时间戳的差值（以秒为单位），就可以得出每秒的丢失率。收到的数据包数是预期数据包数减去丢失的数据包数。预期数据包数也可用于判断任何损失估计的统计有效性。例如，5个数据包中丢失1个的重要性低于1000个数据包中丢失200个的重要性。

根据发送方信息，第三方监控器（third-party monitor）可计算出平均有效载荷数据速率（average payload data rate）和未接收数据的时间间隔内的平均数据包速率（average packet rate）。求出两者的比值，就得到了平均有效载荷大小（average payload size）。如果假定数据包丢失与数据包大小无关，那么特定接收器接收到的数据包数量乘以平均有效载荷大小（或相应的数据包大小）就得出了该接收器可用的表观吞吐量（apparent throughput）。

累积计数（cumulative counts）可利用不同报告之间的差异进行长期数据包丢失测量，除此之外，丢失分数字段（fraction lost field）还可通过单个报告进行短期测量。随着会话规模的扩大，可能无法为所有接收器保存接收状态信息，或者报告之间的间隔时间变长，某个特定接收器可能只收到一份报告，这一点就变得更加重要。

到达间抖动字段（interarrival jitter field）是衡量网络拥塞（network congestion）的第二个短期指标。数据包丢失跟踪（Packet loss tracks）的是持续性拥塞，而抖动测量跟踪（jitter measure tracks）的是瞬时性拥塞。抖动测量（jitter measure）可在导致数据包丢失之前显示拥塞情况。到达间抖动字段（interarrival jitter field）只是报告时抖动的一个快照，并不用于定量分析，而是用于比较一个接收器在一段时间内或多个接收器（如在一个网络内）在同一时间发出的多份报告。为便于比较不同接收器的抖动情况，所有接收器必须根据相同的公式计算抖动。

由于抖动计算（jitter calculation）基于RTP时间戳（RTP timestamp），而RTP时间戳代表数据包中第一个数据被采样的瞬间，因此采样瞬间与数据包传输时间之间延迟的任何变化都会影响计算出的抖动结果。这种延迟变化会出现在不同持续时间的音频数据包中。视频编码也会出现这种情况，因为一帧中所有数据包的时间戳都是相同的，但这些数据包并不是同时传输的。传输前的延迟变化确实会降低抖动计算本身作为网络行为测量的准确性，但考虑到接收器缓冲区必须容纳这种变化，将其包括在内是合适的。当使用抖动计算作为比较测量时，会减去传输前延迟变化造成的（常数）分量，这样就可以观察到网络抖动分量的变化，除非这种变化相对较小。如果变化较小，则可能无关紧要。