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

在实时音视频通信领域，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 也停止媒体流传输。至此，双方的通话结束，整个一对一通话的信令交互流程完成。