介绍

        近年来，通过互联网进行实时通信变得越来越流行，而 WebRTC 已成为通过网络实现实时通信的领先技术之一。WebRTC 使用多种协议，包括实时传输协议 (RTP) 和实时控制协议 (RTCP)。

        RTP负责通过网络传输音频和视频数据，而RTCP负责监控网络状况并向发送方提供反馈。RTP和RTCP在同一网络上通信，RTP使用偶数端口，RTCP使用奇数端口。这允许两种协议使用相同的网络资源而不会互相干扰。在这篇文章中，我们将讨论 RTP 和 RTCP 是什么以及它们如何协同工作以在 WebRTC 中实现实时通信。

实时传输协议 (RTP)

        实时传输协议（RTP）是一种设计用于通过互联网传输音频和视频数据的协议。RTP 用于实时传输媒体流，例如语音和视频。

        RTP 负责将媒体数据打包成小数据包并通过网络传输。每个RTP数据包都包含一个序列号和时间戳，用于确保数据包以正确的顺序和在正确的时间传送。RTP 数据包通过 UDP 传输，延迟低，非常适合实时通信。

实时控制协议 (RTCP)

        实时控制协议 (RTCP) 是一种旨在提供 RTP 流量服务质量 (QoS) 反馈的协议。RTCP 用于监视网络状况，例如数据包丢失和延迟，并向发送方提供反馈。RTCP 数据包定期发送，以提供有关 RTP 流质量的反馈。它们包含有关 RTP 流的统计信息，包括发送和接收的数据包数量、丢失的数据包数量以及数据包之间的延迟。此信息可用于调整 RTP 流以提高音频或视频的质量。

了解视频压缩

        我们不会深入研究视频压缩，但我们会足够了解为什么 RTP 是这样设计的。视频压缩将视频编码为一种新的格式，需要更少的比特来表示相同的视频。

有损和无损压缩

        视频可以编码为无损（没有信息丢失）或有损（信息可能丢失）。RTP 通常使用有损压缩来防止高延迟流和更多丢包，即使视频质量不太好。

帧内和帧间压缩

        视频压缩有两种类型：帧内压缩和帧间压缩。帧内压缩减少了用于描述单个视频帧的位数。相同的技术也用于压缩静态图片，例如 JPEG 压缩方法。另一方面，帧间压缩寻找不两次发送相同信息的方法，因为视频是由许多图片组成的。

帧间类型

帧间压缩共有三种帧类型：

• I 帧- 无需任何其他内容即可解码的完整图片。
• P 帧- 仅包含与前一张图片相比的变化的部分图片。
• B 帧- 部分图片，是对先前和未来图片的修改。

以下是三种帧类型的可视化。

        显然，视频压缩是一个有状态的过程，在通过互联网传输时会带来挑战。这让我们想知道，如果 I 帧的一部分丢失会发生什么？P 帧如何确定要修改的内容？随着视频压缩方法变得更加复杂，这些问题变得更加紧迫。尽管如此，RTP 和 RTCP 提供了一个解决方案。

RTP数据包结构

每个 RTP 数据包都具有以下结构，如RFC中所定义：

 0                   1                   2                   30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Synchronization Source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            Contributing Source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (V)

Version始终设置为2。

Padding (P)

Padding是一个布尔值，用于确定有效负载是否有填充。

有效负载的最后一个字节指示添加的填充字节数。

Extension (X)

        如果设置，RTP 标头将包含扩展。

CSRC Count (CC)

        指的是有效负载之后和之前的标识符CSRC Count的数量。CSRCSSRC

Marker

        该Marker位没有预定含义，可以根据用户的需要使用。

        在某些情况下，它可能指示用户何时说话，或者可能指示关键帧。

Payload Type (PT)

        这Payload Type是该数据包携带的编解码器的唯一标识符。

        对于 WebRTC，Payload Type是动态的，这意味着Payload Type一次调用中 VP8 的 可能与另一次调用中的 VP8 不同。Payload Types调用中的提供者确定到编解码器的映射Session Description。

Sequence Number

       用于Sequence Number对流中的数据包进行排序。每发送一个数据包，Sequence Number就会加一，RTP 是被设计为在有损网络上有用，这为接收方提供了一种检测数据包何时丢失的方法。

Timestamp

    Timestamp是该数据包的采样时刻。它不是一个全局时钟，而是代表媒体流中已经过去了多少时间。例如，如果多个 RTP 数据包都是同一视频帧的一部分，则它们可以具有相同的时间戳。

Synchronization Source（SSRC）

        An SSRC是该流的唯一标识符。这允许多个媒体流在单个 RTP 流上运行。

Contributing Source (CSRC)

        这是一个列表，用于传达哪些 SSRC 对此数据包做出了贡献。

        这通常用于谈话指标。例如，如果多个音频源在服务器端组合成单个 RTP 流，则该字段可用于指示哪些输入流在给定时刻处于活动状态。

Payload

        该字段包含实际的有效负载数据，如果设置了填充标志，则该数据可能以添加了多少填充字节的计数结束。

RTCP数据包结构

每个 RTCP 数据包都有以下结构：

0                   1                   2                   30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    RC   |       PT      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (V)

Version始终是2。

Padding (P)

    Padding是一个布尔值，用于控制有效负载中是否包含填充。

        有效负载的最后一个字节包括添加的填充字节的计数。

Reception Report Count (RC)

        这表示此数据包中包含的报告数量。单个 RTCP 数据包可能包含多个事件。

Packet Type (PT)

        这是 RTCP 数据包类型的唯一标识符。虽然 WebRTC 代理不一定需要支持所有这些类型，但代理之间的支持可能存在差异。一些常见的数据包类型包括：

• 192- 完整帧内请求 ( FIR)
• 193- 否定确认 ( NACK)
• 200- 发件人报告
• 201- 接收者报告
• 205- 通用 RTP 反馈
• 206- 有效负载特定反馈（包括PLI）

RTCP数据包类型详细信息

        RTCP 是一种灵活的协议，支持多种类型的数据包。下面详细介绍了一些最常用的数据包类型。

PLI（图像丢失指示）/FIR（完整帧内请求）

    FIR和消息都有PLI类似的目的，向发送者请求完整的关键帧。然而，PLI当解码器无法解码部分帧时专门使用，这可能是由于数据包丢失或解码器崩溃造成的。

        根据 RFC 5104，FIR当数据包或帧丢失时不应使用；这就是 的工作PLI。FIR用于出于其他原因请求关键帧，例如当新成员进入视频会议并需要完整关键帧来开始解码视频流时。解码器将丢弃帧，直到关键帧到达。

        然而，在实践中，处理PLI和FIR数据包的软件将向编码器发送信号，以在这两种情况下生成新的完整关键帧。

        通常，接收器会在连接后立即请求完整的关键帧，以最大限度地缩短第一帧出现在用户屏幕上的时间。

    PLI数据包是有效负载特定反馈消息的一部分。

NACK（Negative Acknowledgement）

        当接收方发出 时NACK，它会请求发送方重新传输单个 RTP 数据包。这通常是在数据包丢失或延迟时完成的。NACK比请求重新发送整个帧更好，因为 RTP 将数据包分成小块，并且接收方通常只丢失一小块。为了请求丢失的片段，接收器创建带有 SSRC 和序列号的 RTCP 消息。如果发送方没有重新发送所请求的 RTP 数据包，它将简单地忽略该消息。

发送者和接收者报告

        这些报告对于在代理之间传输统计数据至关重要。它们有效地传达接收到的数据包的确切数量以及抖动级别。

        此功能提供有价值的诊断信息并实现有效的拥塞控制。我们将在下面详细了解如何使用这些报告来克服不可靠的网络条件。

克服不可靠的网络

        实时通信严重依赖网络。在理想的情况下，带宽将是无限的，并且数据包将立即到达。不幸的是，网络是有限的，并且条件可能会发生意外变化，因此很难测量和观察网络性能。此外，不同的硬件、软件和配置可能会导致不可预测的行为。

        RTP/RTCP 运行在许多不同类型的网络上，因此发送方和接收方之间的某些通信丢失是很常见的。由于它建立在 UDP 之上，因此没有内置方法来重传数据包或处理拥塞控制。

测量和传达网络状态

        RTP/RTCP 在各种网络类型和拓扑上运行，因此发送方到接收方可能会发生通信丢失。由于它们建立在 UDP 之上，因此没有数据包重传或拥塞控制的固有机制。

        为了获得最佳的用户体验，我们必须评估网络路径质量并适应其随时间的变化。要监控的关键特征是可用带宽（在每个方向上，可能不对称）、往返时间和抖动（往返时间的变化）。我们的系统必须考虑数据包丢失，并随着网络条件的变化传达这些属性的变化。

该协议有两个主要目标：

1. 估计网络支持的可用带宽（在每个方向）。
2. 在发送方和接收方之间传达网络特征。

接收者报告/发送者报告

        接收方报告和发送方报告通过 RTCP 发送，并在RFC 3550中定义。它们在端点之间传递网络状态。接收器报告传达网络质量，包括数据包丢失、往返时间和抖动。这些报告与根据网络质量估计可用带宽的其他算法配合使用。

        发送方和接收方报告（SR 和 RR）共同描绘了网络质量。它们按每个 SSRC 的时间表发送，并用于估计可用带宽。发送方收到RR数据后估计可用带宽，其中包含以下字段：

• 丢失分数- 自上次接收器报告以来丢失的数据包百分比。
• 丢失数据包的累积数量- 整个呼叫期间丢失的数据包数量。
• 接收到的扩展最高序列号- 最后接收到的序列号以及已滚动的次数。
• 到达间隔抖动- 整个呼叫的滚动抖动。
• 最后发件人报告时间戳- 发件人的最后已知时间，用于计算往返时间。

        这些统计数据进一步输入带宽估计算法，例如 GCC（Google 拥塞控制），该算法估计可用带宽，进而驱动编码比特率和帧分辨率。

结论

        总之，RTP 和 RTCP 是 WebRTC 中实现实时通信的基本协议。RTP负责通过网络传输音频和视频数据，而RTCP负责监控网络状况并向发送方提供反馈。这些协议共同实现了互联网上的高质量实时通信。对于任何有兴趣使用 WebRTC 开发实时通信应用程序的人来说，了解 RTP 和 RTCP 如何协同工作至关重要。

参考

• RFC3550（RTP：实时应用传输协议）
• RFC5104（带反馈的 RTP 视听配置文件中的编解码器控制消息）
• RFC8888（用于拥塞控制的 RTP 控制协议 (RTCP) 反馈）

关于转载

转载此文请注明出处，“引用于新睿云.弘电脑”，否则请回避。