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

WebRTC 通话原理：从协商到通信

news 来源：原创 2025/6/26 6:42:35

在实时音视频通信领域，WebRTC（Web Real-Time Communication）凭借其开源、无需插件且能在浏览器中直接实现高质量通信的特性，成为开发者的热门选择。本文将深入解析 WebRTC 通话原理，涵盖媒体协商、网络协商、网络穿越（STUN）、中继转发（TURN）以及一对一通话信令服务器时序等核心内容，助你揭开 WebRTC 通信的神秘面纱。

一、媒体协商：确定通信 “语言”

媒体协商是 WebRTC 通话的基石，其核心在于通信双方就媒体格式、编解码器、分辨率、帧率等关键参数达成共识，确保双方能够顺畅 “对话”。在 WebRTC 体系中，这一过程主要依托 SDP（Session Description Protocol，会话描述协议）来实现。

1. SDP 协议

本小节参考：

SDP协议是什么，详解SDP协议-CSDN博客

【音视频开发】： SDP协议-CSDN博客

SDP 采用纯文本格式，以结构化的方式描述多媒体会话属性，其内容由多个字段组成，每个字段都承载着特定的信息，其基本格式如下：

<type>=<value>

以下是几个关键字段及其作用：

v=：版本号字段，标识 SDP 协议的版本，目前常用版本为 0 。

v=0

o=：拥有者 / 创建者字段，包含用户名、会话 ID、会话版本等信息，用于唯一标识一个会话。

	o=<username> <sessionid> <version> <network type> <address type> <address>

s=：会话名称字段，描述会话的主题或用途，例如 “WebRTC 音视频通话”。

s=<sessionname>

c=：表示媒体的连接信息，会话级描述中或中媒体级描述必至少有一个”c=“。

c=<networktype> <address type> <connection address>

t=：会话时间字段，指明会话的开始时间和结束时间，在持久连接的 WebRTC 通话中，该字段通常设置为 0 0，表示会话无固定时间限制（单位秒）。

t=<start time>  <stop time>

m=：媒体描述字段，是媒体协商的核心部分。它会明确媒体类型（如 audio 表示音频，video 表示视频）、传输端口、传输协议（通常为 RTP/AVP，其中 AVP 代表 Audio/Video Profile），以及该媒体流支持的有效载荷类型（即编解码器）。例如 m=video 9 UDP/TLS/RTP/SAVPF 100 101 ，表示这是一个视频媒体流，使用 UDP 协议，基于 TLS 进行安全传输，采用 RTP 协议，支持 SAVPF（可扩展的音视频分布简档），有效载荷类型 100 和 101 对应不同的视频编解码器。

m=<media><port> <transport> <fmt list>

a=：属性字段，用于补充媒体描述的详细信息，如编码参数、带宽限制、媒体控制等。例如 a=rtpmap:100 VP8/90000 ，表示有效载荷类型 100 对应的是 VP8 视频编解码器，采样率为 90000Hz 。

a=rtpmap:<payload type><encoding name>/<clock rate>[/<encodingparameters>]

通过这些字段的组合，SDP 能够全面、准确地描述多媒体会话的各项属性，为媒体协商提供清晰的信息基础。

示例：

v=0
o=- 0 0 IN IP4 127.0.0.1
s=VLC media player
c=IN IP4 127.0.0.1
t=0 0
a=tool:vlc 2.2.4
m=video 5004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=Z0IAH5WoFAFuQA==,aM48gA==
a=control:streamid=0

2. Offer 与 Answer 的生成与交互细节

当 A 端发起通话请求时，会调用 WebRTC API 中的 createOffer 方法生成 SDP Offer。在生成过程中，浏览器或应用会根据设备硬件能力和软件配置，罗列出自身支持的媒体参数组合。例如，在视频方面，可能支持 VP8、VP9、H.264 等多种编码格式，每种格式又对应不同的分辨率和帧率选项；音频方面，可能支持 Opus、PCM 等编码格式，以及不同的采样率和声道数。这些信息都会被整合到 SDP Offer 中。

A 端生成 Offer 后，通过信令服务器将其发送给 B 端。B 端接收到 Offer 后，会对其中的媒体参数进行逐一分析。首先，B 端会检查自身设备和软件是否支持 Offer 中的媒体类型和编解码器。如果支持，B 端会根据自身的性能和资源情况，从支持的参数中选择最优的组合，然后调用 createAnswer 方法生成 SDP Answer。例如，如果 B 端设备性能有限，对于视频编码可能会选择相对低复杂度的 VP8，而不是 H.264 。

B 端生成 Answer 后，同样借助信令服务器将其返回给 A 端。A 端接收到 Answer 后，会对比 Answer 中的参数与自己 Offer 中的参数，确认双方是否就媒体参数达成一致。若存在不一致或无法支持的参数，可能需要重新发起协商，或者采取默认的兼容设置，以保证通话能够顺利进行。

3. 媒体协商过程中的异常处理与兼容性

在实际网络环境中，媒体协商并非总是一帆风顺，可能会遇到各种异常情况。比如，由于网络延迟或丢包，B 端可能无法完整接收 A 端发送的 Offer，导致解析失败。此时，B 端可以通过信令服务器向 A 端发送错误反馈，请求重新发送 Offer。

另外，不同浏览器或设备对 WebRTC 的支持程度存在差异，这也会影响媒体协商的结果。例如，某些老旧浏览器可能不支持最新的编解码器，或者对 SDP 协议的某些扩展字段解析存在问题。为了提高兼容性，开发者可以在协商过程中设置一些默认的、广泛支持的媒体参数作为保底选项。同时，还可以采用渐进式协商策略，先尝试使用高级的媒体参数进行协商，如果失败，则逐步降低参数要求，直至找到双方都支持的配置。

二、网络协商：规划数据传输路径

网络协商在 WebRTC 通话中至关重要，它的核心使命是为通信双方敲定数据传输的路径与方式，涉及网络地址、端口以及传输协议等关键要素的确定。WebRTC 采用 ICE（Interactive Connectivity Establishment，交互式连接建立）框架，通过系统化的流程与策略，实现高效、稳定的数据传输链路搭建（ICE 主要用于实现端到端的通信连接，尤其是在 P2P（Peer-to-Peer）协议中，通常与 STUN（Session Traversal Utilities for NAT）和 TURN（Traversal Using Relays around NAT）一起使用）。

1. ICE 框架的核心构成与工作机制

ICE 框架主要由三个关键部分组成：候选地址收集、候选地址交换、候选地址检查和连接建立。

候选地址收集：

ICE 会从多个渠道收集候选地址，为后续的连接尝试提供多种可能性。这些候选地址主要包括以下类型：

主机候选地址（Host Candidate）：即设备在本地网络中的真实 IP 地址和端口。例如，当设备连接到家庭局域网时，获取到的 192.168.1.x 这类内网 IP 地址及其对应的端口，就构成了主机候选地址。这是最直接的连接方式，若双方处于同一局域网内，使用主机候选地址进行连接能实现最低延迟的数据传输。

服务器反射候选地址（Server-Reflexive Candidate，简称 SRF 候选地址）：当设备处于 NAT（Network Address Translation，网络地址转换）设备之后时，设备自身无法直接获取其在公网中的地址。此时，设备会向 STUN（Session Traversal Utilities for NAT，NAT 会话遍历实用工具）服务器发送请求。STUN 服务器接收到请求后，根据 NAT 设备映射的公网地址和端口信息，将其返回给设备，这个返回的公网地址和端口就成为了服务器反射候选地址。例如，设备在内网的 IP 地址是 192.168.1.100:5000，经过 NAT 转换后，在公网的地址变为 123.123.123.123:6000，STUN 服务器将 123.123.123.123:6000 返回给设备，作为服务器反射候选地址。

中继候选地址（Relay Candidate）：在复杂网络环境下，当通过主机候选地址和服务器反射候选地址都无法建立连接时，就需要借助 TURN（Traversal Using Relays around NAT，使用中继穿越 NAT）服务器。TURN 服务器会为设备分配一个公网地址和端口，这个地址和端口就是中继候选地址。设备将数据发送给 TURN 服务器，再由 TURN 服务器转发给通信对方，实现数据的中继传输。

候选地址交换：

通过信令协议（如 SIP、WebRTC 等），每个端点将其候选地址发送给对方，确保双方都能得到彼此的候选地址。

候选地址收集与交换示意图如下：

候选地址检查：

收集到候选地址后，ICE 会对这些地址进行检查，判断其可用性。ICE 采用 “候选地址对” 的方式进行检查，即从两端设备的候选地址中各选取一个地址组成一对，然后使用 STUN 协议进行连通性测试。例如，A 端的一个候选地址与 B 端的一个候选地址组成一对，ICE 会尝试在这两个地址之间发送探测数据包（相对端上方发STUN Binding请求），根据是否能收到响应（STUN四次握手）来判断该地址对是否可用。在测试过程中，ICE 会遵循一定的优先级顺序（ICE规定了优先级计算方法，两端计算得到的优先级相同），优先测试主机候选地址，因为其理论上能提供最佳的传输性能；若主机候选地址测试失败，再依次测试服务器反射候选地址和中继候选地址。

连接建立：

经过候选地址检查，ICE 会从所有可用的候选地址对中，筛选出最优的一对来建立连接。最优地址对的选择通常基于连接的稳定性、延迟等因素。一旦确定了最优地址对，通信双方就会基于该地址对进行数据传输，正式建立起 WebRTC 通话的数据链路。

2. 网络协商与其他组件的协同工作

网络协商并非孤立进行，而是与 WebRTC 的其他组件紧密协作。在媒体协商阶段确定了媒体格式和编解码器后，网络协商要确保这些媒体数据能够顺利传输。例如，对于高码率的视频数据传输，网络协商需要选择带宽足够且稳定的传输路径；对于实时性要求极高的音频数据，网络协商要尽量降低传输延迟。

同时，网络协商与 STUN、TURN 服务器密切配合。当需要获取服务器反射候选地址时，ICE 会与 STUN 服务器交互；在使用中继候选地址进行数据传输时，则依赖 TURN 服务器的中继转发功能。此外，网络协商的结果也会反馈给信令服务器，信令服务器会将相关的网络连接信息传递给通信双方，确保双方都知晓数据传输的路径和方式，从而实现无缝的实时通信。

网络协商通过 ICE 框架的高效运作，结合 WebRTC 其他组件的协同配合，能够在复杂多变的网络环境中，为 WebRTC 通话规划出一条稳定、高效的数据传输路径，保障音视频数据的流畅传输。

三、网络穿越（STUN）：突破网络限制

在实际网络环境中，通信双方往往处于不同的网络环境，如 NAT（Network Address Translation，网络地址转换）后面。NAT 会隐藏内部网络设备的真实 IP 地址，导致外部设备无法直接与内部设备建立连接，这就需要网络穿越技术来解决。

STUN（Session Traversal Utilities for NAT，NAT 会话遍历实用工具）是 WebRTC 中常用的网络穿越技术。STUN 服务器的作用是帮助客户端获取其在公网中的 IP 地址和端口。客户端向 STUN 服务器发送请求，STUN 服务器接收到请求后，根据 NAT 设备映射的公网地址和端口信息，将其返回给客户端。客户端获取到公网地址后，就可以将该地址作为候选地址，与其他客户端进行连接尝试。这样，即使客户端位于 NAT 设备之后，也能实现与外部设备的通信。

四、中继转发（TURN）：保障通信畅通

当 STUN 无法实现直接连接时，就需要借助 TURN（Traversal Using Relays around NAT，使用中继穿越 NAT）服务器来进行中继转发。TURN 服务器充当数据中转站的角色，接收来自一端的数据，然后转发给另一端。

TURN 服务器不仅可以处理音视频数据，还能处理其他类型的媒体数据。虽然使用 TURN 服务器会增加一定的传输延迟和服务器负载，但在复杂的网络环境下，它是确保通信能够顺利进行的重要手段。例如，当双方都处于对称 NAT 后面，无法通过 STUN 直接建立连接时，TURN 服务器就成为了实现通信的关键。

有关STUN,TURN等详细细节请参考我的文章：WebRTC:去中心化网络P2P框架解析-CSDN博客

五、一对一通话信令服务器时序

信令服务器在 WebRTC 一对一通话中起着桥梁作用，负责传递双方的媒体协商信息、网络协商信息等。以下是一对一通话信令服务器时序的详细流程，通过时序图来直观呈现：

1. 连接初始化阶段

呼叫方 A 和接收方 B 首先分别与信令服务器建立连接。A 向信令服务器发送连接请求，携带自身用户 ID（如 userA），信令服务器接收请求后进行处理，为 A 分配唯一的会话 ID（如 session_123），并返回连接成功的响应。

紧接着，B 也向信令服务器发送连接请求，附带其用户 ID（如 userB），信令服务器同样为 B 分配会话 ID（如 session_456），并告知 B 连接成功。此时，信令服务器记录下 A 和 B 这两个在线用户的相关信息，为后续的通话交互做好准备。

2. 呼叫发起与接受阶段

A 决定发起呼叫，向信令服务器发送呼叫请求，明确指定呼叫的目标用户为 B。信令服务器接收到该请求后，迅速将其转发给 B，同时附上 A 的相关元数据（如用户标识、设备信息等）。

B 收到呼叫请求后，在其设备上展示来电提示（如响铃、显示来电界面等）。当 B 决定接受呼叫时，向信令服务器发送接受呼叫的响应。信令服务器收到 B 的响应后，及时转发给 A，通知 A 呼叫已被接受，双方即将进入通话流程。

3.媒体协商信令交互

A 在得知呼叫被接受后，调用相关 API 创建 SDP Offer，其中包含了自身提议的媒体参数，例如视频分辨率为 1080p，音频编码格式为 Opus，视频编码格式为 H.264 等。A 将生成的 SDP Offer 发送给信令服务器，信令服务器再将其转发给 B。

B 接收到 SDP Offer 后，对其中的参数进行解析，并结合自身设备和网络情况，选择合适的媒体参数，比如将视频分辨率调整为 720p，音频和视频编码格式保持为 Opus 和 H.264，然后创建 SDP Answer。B 将 SDP Answer 发送给信令服务器，信令服务器再转发给 A。至此，双方通过信令服务器完成了媒体协商，确定了最终使用 720p 分辨率，以及 H.264/Opus 编码格式进行音视频传输。

4. 网络协商信令交互

为了建立有效的网络连接，A 和 B 需要进行网络协商，交换 ICE 候选地址。A 先向 STUN 服务器发送请求，获取公网地址，即服务器反射候选地址（SRF 候选），STUN 服务器返回对应的公网 IP（如 1.2.3.4:5000 ）。在一些复杂的网络环境下，A 还会向 TURN 服务器请求中继地址（可选操作），TURN 服务器返回中继候选地址（如中继 IP: 5.6.7.8:6000 ）。A 将收集到的所有 ICE 候选地址整理成列表，发送给信令服务器。

同样地，B 也向 STUN 服务器请求公网地址，获取自身的 SRF 候选（如公网 IP: 9.8.7.6:5500 ），并在必要时向 TURN 服务器请求中继地址（如中继 IP: 4.3.2.1:6500 ），然后将自己的 ICE 候选地址列表发送给信令服务器。信令服务器分别将 A 和 B 的候选地址列表转发给对方，使得双方都获取到了彼此的网络连接候选地址信息。

5. ICE 连接建立阶段

在拥有了双方的 ICE 候选地址后，开始进行 ICE 连接建立过程。A 和 B 会依次遍历候选地址对进行测试。首先尝试使用主机候选地址（A - Host vs B - Host）进行连接测试，如果双方处于同一局域网内，直接连通成功，B 向 A 返回 ICE 响应，标记连接成功。

若在同一局域网测试失败，说明双方处于跨 NAT 网络环境，此时尝试使用 STUN 穿透，即使用服务器反射候选地址（A - SRF vs B - SRF）进行连接测试。如果 STUN 穿透成功，B 同样向 A 返回 ICE 响应，确认连接成功。

若 STUN 穿透也失败，表明网络环境较为复杂，属于对称 NAT 情况，此时 A 将数据发送给 TURN 服务器的中继地址，TURN 服务器再将数据转发给 B，通过中继方式建立连接。

6. 通话控制信令交互

当 ICE 连接成功建立后，通话进入媒体流传输阶段。A 开始向 B 发送视频流（采用 720p 分辨率、H.264 编码）和音频流（Opus 编码），同时 B 也向 A 发送相应的视频流和音频流，实现了音视频的双向实时传输，双方能够正常进行通话交流。

7. 通话结束阶段

当 A 想要结束通话时，向信令服务器发送挂断请求。信令服务器将该请求转发给 B，B 接收到请求后，停止媒体流的传输，并向信令服务器发送挂断确认。信令服务器再将 B 的挂断确认转发给 A，A 也停止媒体流传输。至此，双方的通话结束，整个一对一通话的信令交互流程完成。

一、媒体协商：确定通信 “语言”​

1. SDP 协议

2. Offer 与 Answer 的生成与交互细节​

3. 媒体协商过程中的异常处理与兼容性​

二、网络协商：规划数据传输路径​

1. ICE 框架的核心构成与工作机制​

2. 网络协商与其他组件的协同工作​

三、网络穿越（STUN）：突破网络限制​

四、中继转发（TURN）：保障通信畅通​

五、一对一通话信令服务器时序​

1. 连接初始化阶段​