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

WebRTC流媒体传输协议RTP点到点传输协议介绍，WebRTC为什么使用RTP协议传输音视频流？

article 2025/10/5 11:00:19

通过上一章《WebRTC工作原理详细介绍、WebRTC信令交互过程和WebRTC流媒体传输协议介绍》，我们知道WEBRTC在完成 SDP 协商和 ICE 候选交换信令后，双方就可以建立 RTP 流，开始传输音视频数据，这时，RTP 数据包就通过在 ICE 协商中选定的最佳网络路径（包含端口信息）进行传输。

WebRTC为什么使用RTP协议?

RTP协议一般使用在安防监控行业，比如rtsp协议使用rtp实时传输音视频。

WebRTC同样使用 RTP 协议也是因为 RTP 能够提供实时数据传输。

RTP协议介绍

RTP（Real-time Transport Protocol，实时传输协议）是一种用于在IP网络上传输音频、视频等实时数据的协议。它通常与RTCP（Real-time Transport Control Protocol，实时传输控制协议）一起使用，用于提供传输质量反馈和同步控制。RTP广泛应用于VoIP、视频会议、流媒体等应用中。

RTP协议能够提供如下能力：

低延迟：RTP 基于 UDP，避免了 TCP 的连接和重传机制，减少了延迟，适合实时通信。
时序控制：RTP 提供序列号和时间戳，确保音视频数据按正确顺序和时间进行同步。
支持多种编码格式：RTP 支持多种音频和视频编解码格式，非常适合 WebRTC 中的多媒体数据传输。
数据包丢失处理：通过 RTP 的顺序号，接收方可以检测丢包并采取适当的处理措施。
这些特性使 RTP 成为 WebRTC 中音视频实时通信的理想协议。

RTP协议的基本组成

RTP协议主要负责实时数据的传输，通常与UDP协议一起使用。它的基本功能包括：

数据包的传输：通过RTP封装音频、视频或其他实时数据的有效负载。
时间戳和序列号：RTP为每个数据包提供时间戳和序列号，确保接收方能够正确地重排和同步数据包。
负载类型：RTP支持多种负载类型（如音频编码和视频编码），并通过负载类型字段标识。
多路复用：RTP可以支持多种实时数据流在同一网络连接上的传输。

RTP数据包结构

RTP数据包由一个固定的头部和一个可变长度的负载组成。头部包含了控制数据，用于确保数据的正确性和时序。RTP头部的结构如下：

RTP头部格式：

 0  7  8 15 16 23 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|P|X|  CC  |M| PT  |   Sequence Number   |    Timestamp          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              SSRC (Synchronization source)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    CSRCs (Contributing sources)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V（Version，版本）：2位字段，指示RTP协议的版本。当前版本为2。
P（Padding，填充）：1位，表示数据包中是否有填充字节。
X（Extension，扩展）：1位，表示是否存在扩展头部。
CC（CSRC Count，CSRC计数）：4位，表示CSRC（贡献源标识符）的数量。
M（Marker，标记）：1位，通常用于标记某些特殊的RTP包（例如视频帧的关键帧）。
PT（Payload Type，负载类型）：7位，标识数据包的负载类型（即所承载的编码格式，如G.711、H.264等）。
Sequence Number（序列号）：16位，递增的序列号，用于检测数据包是否丢失。
Timestamp（时间戳）：32位，表示数据包的采样时刻，用于同步数据流。
SSRC（Synchronization Source，同步源标识符）：32位，标识源端的RTP会话，用于区分不同的数据源。
CSRC（Contributing Sources，贡献源）：最多15个32位字段，标识贡献源，在混音或转发的情况下使用。

RTP的工作原理

数据封装：RTP协议将音视频数据封装在数据包中，并为每个数据包分配一个唯一的序列号和时间戳，确保数据的顺序性和时效性。
传输：RTP数据包通过UDP协议发送，UDP的无连接和不可靠性特性适合实时数据流，因为实时应用通常能容忍少量的丢包。
接收与重组：接收端根据序列号重排数据包，使用时间戳来同步音视频流。RTP协议不处理丢包或错误修复，这些功能由RTCP协议提供，或者由应用程序本身处理。
RTCP配合使用：RTP常常与RTCP配合使用，RTCP提供数据包传输质量的反馈信息，如丢包率、时延、抖动等。这些反馈信息帮助调整传输质量和流量控制。

RTP的应用场景

VoIP（Voice over IP，语音通信）：RTP在VoIP中用于传输语音数据包，确保实时性和低延迟。
视频会议：RTP用于视频流的实时传输，与RTCP配合使用以保证视频会议中的音视频同步。
流媒体：RTP用于网络广播和流媒体服务中，能够有效地传输实时视频和音频流。

RTP与RTCP的关系

RTP负责数据的实际传输，而RTCP则负责对RTP数据流进行监控，提供传输质量的反馈，确保数据流的同步、时序和网络状况的监控。RTCP定期向参与者发送报告数据，帮助调整传输策略。常见的RTCP报告有：

SR（Sender Report）：发送者报告，包含发送的RTP包的统计信息。
RR（Receiver Report）：接收者报告，提供接收到的RTP包的统计信息。
SDES（Source Description）：源描述，提供源端的一些描述信息，如CNAME（Canonical Name）等。
BYE：终止通知，表示一个RTP流的离开。

RTP协议的优劣

优点：

低延迟：RTP采用UDP传输，避免了TCP协议的连接建立和重传机制，使得实时数据的延迟最小。
灵活性：支持多种媒体格式（音频、视频）和多种应用场景。
时序控制：通过时间戳和序列号控制数据的时序性和顺序。

不足：

无错误恢复：RTP本身不提供错误恢复和数据重传功能，这需要应用层或RTCP来处理。
网络拥塞管理：RTP依赖底层网络协议（如UDP）来提供实时性，容易受到网络拥塞的影响。

总结

通过上述，可以看出来RTP协议在实时通信和流媒体应用中起着至关重要的作用。
而WebRTC使用RTP作为音视频传输协议，主要还是因为对于实时性的要求。
RTP协议通过为每个数据包提供序列号、时间戳和负载类型，实现数据的可靠传输和时序控制。与RTCP结合使用时，RTP能够提供实时的反馈机制，确保音视频流的质量和同步。