从sdp开始到webrtc的通信过程

1. SDP

1.1 SDP的关键点

SDP（Session Description Protocol）通过分层、分类的属性字段，结构化描述实时通信会话的 会话基础、网络连接、媒体能力、安全策略、传输优化 等核心信息，每个模块承担特定功能：

1. 会话级别描述（全局会话元信息）

v=：协议版本（固定为 0），标识 SDP 遵循的标准版本，确保解析兼容性。
o=：会话发起者信息，格式为 o=<用户名> <会话ID> <会话版本> <网络类型> <地址类型> <IP> ，用于唯一标识会话（如多终端复用场景区分会话实例）。
s=：会话名称/主题，简短描述会话内容（如 s=视频会议 ），便于业务层识别。
t=：会话时间范围，格式 t=<起始时间> <结束时间>（UNIX 时间戳），用于预约会议或控制会话有效期。
b=：带宽限制，格式 b=<类型>:<带宽值>（如 b=AS:1024 表示总带宽 1024kbps），控制会话资源占用。

2. 网络描述（连通性与地址协商）

c=：默认网络连接信息，格式 c=<网络类型> <地址类型> <IP> ，定义会话级默认网络参数（媒体流可覆盖此配置），如 c=IN IP4 0.0.0.0 表示 IPv4 地址。
a=candidate：ICE 候选地址，格式 a=candidate:<foundation> <component-id> <proto> <priority> <IP> <port> <type> ，用于交换 P2P 连接的候选地址（如主机地址、中继地址），实现 NAT 穿越。

3. 媒体级别描述（单流能力协商）

m=：媒体流基础定义，格式 m=<媒体类型> <端口> <传输协议> <编码Payload列表> ，如 m=video 9 UDP/TLS/RTP/SAVPF 96 97 表示视频流、端口 9、SRTP 传输、支持 Payload 96/97 。
a=rtpmap：编码映射，格式 a=rtpmap:<Payload> <编码名>/<采样率> ，关联 Payload 与具体编码（如 a=rtpmap:96 VP8/90000 表示 Payload 96 对应 VP8 编码，采样率 90000Hz ）。
a=fmtp：编码参数扩展，传递编码特定配置（如 a=fmtp:97 apt=96 表示 RTX 编码（Payload 97 ）关联主编码 VP8（Payload 96 ））。
a=extmap：RTP 扩展头定义，用于传递自定义元数据（如视频帧类型、时间戳修正）。
a=sendrecv/a=sendonly/a=recvonly/a=inactive：媒体流方向，控制收发策略（如订阅流用 recvonly ，推流用 sendonly ）。
a=ssrc：同步源标识，格式 a=ssrc:<SSRC> <属性> ，标记媒体流的唯一源（如 a=ssrc:1234 cname:user@domain 关联 SSRC 与用户标识）。

4. 安全描述（加密与身份验证）

a=crypto：加密算法配置，格式 a=crypto:<加密套件> <主密钥> ，定义 SRTP 加密参数（如 a=crypto:1 AES_CM_128_HMAC_SHA1_80 ）。
a=ice-ufrag/a=ice-pwd：ICE 认证信息，用于 ICE 连通性检查的身份验证（如 a=ice-ufrag:abc 、a=ice-pwd:def ）。
a=fingerprint：DTLS 证书指纹，格式 a=fingerprint:<哈希算法> <指纹值> ，验证 DTLS 证书合法性（如 a=fingerprint:sha-256 12:34:56... ）。

5. DTLS 角色（加密通道协商）

a=setup：DTLS 连接角色，取值 active（主动发起连接）、passive（被动监听）、actpass（自动协商），控制 DTLS 握手流程（如 a=setup:actpass 表示支持主动或被动模式）。

6. ICE 策略（P2P 连接优化）

a=ice-options:trickle：Trickle ICE 模式，允许分批次传输候选地址，加速会话建立（无需等所有候选生成再交换）。
a=ice-lite：轻量 ICE 模式，适用于服务端（如 SFU ），减少 ICE 检查开销（仅响应客户端检查）。
a=ice-option:renomination：ICE 提名优化，允许更换更优候选地址，动态调整传输路径。

7. QoS、Grouping 传输描述（流管理与优化）

a=rtcp-fb：RTCP 反馈机制，定义拥塞控制、丢包重传策略（如 a=rtcp-fb:96 transport-cc 启用传输层拥塞控制）。
a=group：多流复用，格式 a=group:<类型> <媒体标识> ，如 a=group:BUNDLE video audio 将音视频流复用同一传输通道。
a=rtcp-mux：RTP/RTCP 复用，使 RTP（媒体数据）和 RTCP（控制信令）共享同一端口，简化 NAT 配置。

1.2 核心模型 offer-answer模型

SDP（Session Description Protocol，会话描述协议）的 Offer - Answer 模型是实时多媒体通信（如结合 SIP、WebRTC 等场景）里用于协商会话参数的核心机制
一、是什么：模型基本定义与角色

核心逻辑：
两通信实体借助 SDP 交互，一方（提议方，Offerer）先发送包含自身期望会话参数的 Offer ，描述想建立的多媒体会话（如支持的媒体类型、编码、网络地址等）；另一方（应答方，Answerer）依据自身能力筛选匹配参数，回复 Answer ，最终达成双方都认可的会话参数共识。
典型场景：常见于 SIP（会话初始协议）、WebRTC 等音视频通话流程，解决“通信双方如何协商媒体能力、网络参数”问题，让不同终端（浏览器、服务器、硬件设备）能统一“会话规则” 。

二、为什么需要：解决的通信痛点

终端能力差异：不同设备支持的媒体编码（如 VP8/H.264 ）、传输协议（UDP/TCP ）、网络环境（NAT 类型不同）千差万别。比如手机浏览器和 PC 浏览器，编码支持侧重不同，需通过协商找到“交集” 。
会话参数双向确认： unicast（单播）会话里，完整会话视图需要双方信息（如双端都要告知对方自己的网络地址）；而 multicast（组播）虽有全局视图，但单播场景必须双向协商才能建立连接，Offer - Answer 模型就是为补齐 SDP 在单播会话里的协商“语义和操作细节”而生。
动态会话调整：通话中可能需要增减媒体流（如关闭视频保留音频）、修改编码（弱网切换低码率编码），模型支持通过再次交换 Offer - Answer 动态调整，让会话适配网络或需求变化。

三、怎么用：流程与规则（以简单音视频通话为例）
1. 基本流程（Unicast 单播场景）

Step 1：生成 Offer（Offerer 主动发起）
提议方（如用户 A 的浏览器）构建 SDP Offer，包含会话基础信息（v= 版本、o= 发起者标识）、媒体流描述（m= ，如音频/视频类型、端口、支持的编码）、网络连接信息（c= ，自身 IP 等）、安全配置（如 DTLS 指纹 a=fingerprint ）等。示例片段：

v=0
o=userA 12345 67890 IN IP4 192.168.1.100  # 会话发起者信息
s=-  # 会话名称（无内容用 - 占位）
c=IN IP4 192.168.1.100  # 网络连接默认地址
t=0 0  # 会话时间范围（永久有效）
m=audio 5000 RTP/AVP 97 98  # 音频流：端口5000，支持编码97（AMR）、98（AMR - WB）
a=rtpmap:97 AMR/16000/1  # 映射编码97为AMR，采样率16000
m=video 6000 RTP/AVP 32  # 视频流：端口6000，支持编码32（MPV）
a=rtpmap:32 MPV/90000  # 映射编码32为MPV，时钟频率90000

通过信令协议（如 SIP 的 INVITE 消息、WebRTC 的信令服务器）发给应答方（用户 B ）。

Step 2：生成 Answer（Answerer 响应）
应答方（如用户 B 的浏览器）解析 Offer，按规则筛选参数：
- 媒体流数量与顺序：Answer 的 m= 行数量、顺序必须与 Offer 一致（保证双方对应媒体流匹配）。
- 编码与端口：每个媒体流的编码选 Offer 里的子集，端口设为非 0 表示接受，设为 0 表示拒绝。
  假设用户 B 只接受音频流、选编码 97，回复 Answer 片段：
```
v=0
o=userB 67890 12345 IN IP4 192.168.1.200  # 应答方会话标识
s=-  
c=IN IP4 192.168.1.200  
t=0 0  
m=audio 5001 RTP/AVP 97  # 接受音频流，端口5001（与Offer不同，协商双端收发端口），选编码97
a=rtpmap:97 AMR/16000/1  
m=video 0 RTP/AVP 32  # 拒绝视频流，端口设0  
```
同样通过信令回传给提议方。
Step 3：确认与建立连接
提议方收到 Answer 后，验证参数是否符合预期（如媒体流接受/拒绝逻辑），双方基于协商的编码、网络地址，通过 ICE（Interactive Connectivity Establishment ，互动连接建立）完成网络连通性检查，最终建立媒体传输通道（如 RTP 传输音频视频）。

关键规则（RFC 3264 定义核心约束）

Offer 生成规则：
必须包含 SDP 强制字段（v=、o=、s=、c=、t= ）；媒体流（m= ）按优先级列编码，若支持 codec 太多，优先列最可能被接受的。
Answer 生成规则：
- m= 行数量、顺序严格匹配 Offer ，保证媒体流对应关系；
- 端口 0 表示拒绝该媒体流，非 0 表示接受；
- 编码必须是 Offer 编码的子集，动态编码（如 RTX ）双端编号可不同，但通常选一种编码。
会话修改规则：
双方可发起新的 Offer - Answer 交换调整会话（如增减媒体流、改编码）；修改时，o= 里的版本号要么不变（表示 SDP 未变）、要么 +1（表示新参数需解析）；新增媒体流放 m= 列表末尾，删除则设对应端口为 0 但保留 m= 行，方便后续协商。

一般是由信令服务器为中继服务器,来进行交换sdp

2 实战

#offer
v=0
o=- 2397106153131073818 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:l5KU
a=ice-pwd:+Sxmm3PoJUERpeHYL0HW4/T9
a=ice-options:trickle
a=fingerprint:sha-256
7C:93:85:40:01:07:91:BE:DA:64:A0:37:7E:61:CB:9D:91:9B:44:F6:C9:AC:3B:37:1C:00
:15:4C:5A:B5:67:74
a=setup:actpass
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID 2527104241
a=ssrc:2527104241 cname:JPmKBgFHH5YVFyaJ
a=ssrc:2527104241 msid:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS c7072509-df47-
4828-ad03-7d0274585a56
a=ssrc:2527104241 mslabel:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS
a=ssrc:2527104241 label:c7072509-df47-4828-ad03-7d0274585a56
#answer
v=0
o=- 5443219974135798586 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVs
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:MUZf
a=ice-pwd:4QhikLcmGXnCfAzHDB++ZjM5
a=ice-options:trickle
a=fingerprint:sha-256
2A:5A:B8:43:66:05:B3:6A:E9:46:36:DF:DF:20:11:6A:F6:11:EA:D9:4E:26:E3:CE:5A:3A
:C6:8D:03:49:7B:DE
a=setup:active
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID 3587783331
a=ssrc:3587783331 cname:INxZnBV2Sty1zlmN
a=ssrc:3587783331 msid:uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVs a3b297e7-cdbe-
464e-a32c-347465ace055
a=ssrc:3587783331 mslabel:uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVs
a=ssrc:3587783331 label:a3b297e7-cdbe-464e-a32c-347465ace055

一、会话级别字段解析

协议版本（v=）

字段：v=0
说明：固定值，表示 SDP 协议版本为 0，遵循 RFC 4566 规范。

会话发起者（o=）

字段：o=- 2397106153131073818 2 IN IP4 127.0.0.1
结构：
- username：-（无用户名，用 - 占位）
- sess-id：2397106153131073818（会话 ID，通常为 NTP 时间戳）
- sess-version：2（会话版本，数据变更时递增）
- nettype：IN（网络类型为 Internet）
- addrtype：IP4（地址类型为 IPv4）
- unicast-address：127.0.0.1（发起者 IP，本地回环地址，可能为测试环境）
作用：唯一标识会话，确保多终端协商时的唯一性。

会话名（s=）

字段：s=-
说明：会话名称为空，用 - 占位，符合“无有意义名称时设为 -”的规范。

会话时间（t=）

字段：t=0 0
说明：会话永久有效（起始时间和结束时间均为 0），适用于实时通信场景。

附加属性（a=）

a=group:BUNDLE video
- 作用：将视频流复用同一传输通道（BUNDLE 机制），减少 Candidate 数量和 NAT 配置复杂度。
a=msid-semantic: WMS gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS
- msid-semantic：声明媒体源标识（MSID）的语义为 WMS（WebRTC Media Source）。
- gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS：媒体源 ID，用于关联流与终端设备。

二、媒体级别字段解析（m=video）

媒体描述（m=）

字段：m=video 9 UDP/TLS/RTP/SAVPF 96 97
结构：
- media：video（媒体类型为视频）
- port：9（传输端口，在 WebRTC 中实际使用 ICE 候选地址，端口可能为占位符）
- proto：UDP/TLS/RTP/SAVPF（传输协议为 UDP，基于 TLS 加密，使用 SRTP 协议，支持 RTCP 反馈）
- fmt：96 97（Payload 类型列表，96 为 VP8 编码，97 为 RTX 重传编码）
作用：定义视频流的基础参数，协商时接收方需从中选择支持的编码。

连接数据（c=）

字段：c=IN IP4 0.0.0.0
说明：网络类型为 IPv4，地址为 0.0.0.0（表示未指定具体地址，依赖媒体级或 ICE 候选地址）。

RTCP 配置（a=rtcp:）

字段：a=rtcp:9 IN IP4 0.0.0.0
说明：RTCP（实时传输控制协议）端口为 9，与 RTP 端口相同，结合 a=rtcp-mux 可复用同一端口。

ICE 相关属性

a=ice-ufrag:l5KU
- ICE 用户名，用于身份验证，与对端 ice-pwd 配合使用。
a=ice-pwd:+Sxmm3PoJUERpeHYL0HW4/T9
- ICE 密码，与用户名组成认证凭证。
a=ice-options:trickle
- 启用 Trickle ICE 模式，允许分批次传输 Candidate，加速会话建立。

DTLS 安全配置

a=fingerprint:sha-256 ...
- DTLS 证书指纹（SHA-256 哈希值），用于验证证书合法性，防止中间人攻击。
a=setup:actpass
- DTLS 角色为 actpass（主动/被动均可），由对端在 Answer 中确定最终角色。

媒体流方向与复用

a=mid:video
- 媒体流唯一标识（mid）为 video，与 a=group:BUNDLE 配合实现流复用。
a=sendrecv
- 流方向为双向传输（发送+接收），适用于视频通话场景。
a=rtcp-mux
- 复用 RTP/RTCP 到同一端口，简化 NAT 穿越。

编码与反馈配置

a=rtpmap:96 VP8/90000
- Payload 96 映射为 VP8 编码，采样率 90000Hz。
a=rtcp-fb:96 goog-remb
- 启用 Google 拥塞控制反馈（goog-remb），优化弱网下的码率调整。
a=rtpmap:97 rtx/90000
- Payload 97 映射为 RTX（重传编码），a=fmtp:97 apt=96 表示其关联主编码为 VP8（96）。

SSRC 与媒体源标识

a=ssrc-group:FID 2527104241
- SSRC 组类型为 FID（流标识），关联 SSRC 2527104241 与媒体流。
a=ssrc:2527104241 msid:...
- MSID（媒体源 ID）为 gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS c7072509-df47-...，标识具体媒体源（如摄像头）。

三、Offer 的核心功能与协商目标

能力声明
Offer 向对端展示本端支持的：

编码能力：VP8 视频编码，支持 RTX 重传。
网络策略：Trickle ICE 模式、BUNDLE 流复用、RTCP-MUX 端口复用。
安全配置：DTLS 证书指纹、ICE 认证信息。

协商目标

对端（Bob）需从 fmt 列表（96/97）中选择支持的编码，通常选首个优先级最高的编码（VP8）。
确认 ICE 候选地址（通过信令单独交换，如 a=candidate），完成连通性检查。
确定 DTLS 角色（如 Bob 在 Answer 中设为 active，本端则为 passive）。

四、与 Answer 的关键差异对比

字段	Offer（Alice）	Answer（Bob）	说明
`o=`	Alice 的会话 ID	Bob 的会话 ID	标识应答方会话
`ice-ufrag/ice-pwd`	`l5KU`/`+Sxmm3Po...`	`MUZf`/`4QhikLcmGX...`	应答方 ICE 认证信息
`setup`	`actpass`	`active`	Bob 确定 DTLS 角色为主动
`ssrc`	`2527104241`（Alice 的流）	`3587783331`（Bob 的流）	应答方媒体源 ID

3 总结

在这里插入图片描述

一、信令阶段（SDP 协商：Offer/Answer 模型）
核心目标：交换双方媒体能力（编码、分辨率等）和网络协商参数（ICE 策略、DTLS 安全配置），为后续连接做准备。

Client 生成 Offer（SDP）
Client（如浏览器）先构建 SDP Offer，包含：

会话元信息：v=0（协议版本）、o=（会话 ID/发起者）、s=-（会话名）、t=0 0（会话时长）。
媒体描述：m=video（视频流）、a=rtpmap:96 VP8/90000（支持 VP8 编码）、a=rtcp-fb（拥塞控制反馈策略）。
网络与安全：a=ice-ufrag/a=ice-pwd（ICE 认证）、a=fingerprint:sha-256（DTLS 证书指纹）、a=setup:actpass（DTLS 角色协商）。

通过信令服务器（如 WebSocket 通道），将 Offer 转发给 Media Server。

Media Server 回复 Answer（SDP）
Media Server 解析 Offer 后，筛选双方共同支持的参数（如确认使用 VP8 编码、匹配 ICE 策略），生成 SDP Answer：

媒体流确认：保留 m=video 结构，确认编码 96（VP8），拒绝不支持的编码（若有）。
安全与网络响应：a=setup:active（确定 DTLS 角色为主动）、替换 ice-ufrag/ice-pwd 为自身认证信息。

通过信令服务器，将 Answer 回传给 Client。

信令服务器的作用

“中转站”：不处理 SDP 内容，仅负责转发 Offer/Answer，确保两端交换协商信息。
状态协调：可辅助管理会话状态（如房间内用户列表、媒体流路由），但核心是传递 SDP 信令。

二、网络穿透阶段（ICE + STUN/TURN）
核心目标：找到 Client 与 Media Server 之间可连通的网络路径（穿透 NAT/防火墙），为媒体流传输铺路。

收集 ICE 候选地址
Client 和 Media Server 各自生成候选地址（Candidate），包含：

Host 候选：设备内网 IP（如 192.168.1.100），优先级最高。
Srflx 候选：通过 STUN 服务器获取的公网映射地址（如 203.0.113.1），用于直连穿透。
Relay 候选：通过 TURN 服务器获取的中继地址（如 turn:xxx.com:3478），保底方案（直连失败时用）。

交换候选地址（Trickle ICE）
双方通过信令服务器交换候选地址（a=candidate 字段），支持分批次传输（Trickle ICE 模式），加速连接建立。
连通性检查（ICE 打洞）
Client 和 Media Server 基于候选地址，用 STUN 请求/响应 测试连通性：

优先尝试 Host 候选（内网直连），若成功则无需中继。
失败则尝试 Srflx 候选（STUN 打洞），获取公网映射地址直连。
仍失败则用 Relay 候选（TURN 中继），确保复杂网络下连通。

选定最佳路径
ICE 会为候选地址动态排序（直连地址优先级 > 中继地址），最终选定最优路径（如 Host 或 Srflx 候选），用于后续媒体流传输。

三、安全传输阶段（DTLS 握手 + SRTP 加密）
核心目标：建立加密通道，确保媒体流（音频/视频）传输安全，防止窃听/篡改。

DTLS 握手（密钥协商）
Client 和 Media Server 基于 SDP 中的 a=setup 和 a=fingerprint，进行 DTLS 握手：

Client 角色：Offer 中 a=setup:actpass，表示可主动或被动发起握手。
Server 角色：Answer 中 a=setup:active，主动发起握手。
流程：
1. Client 发送 Client Hello，携带加密套件、随机数。
2. Server 回复 Server Hello，确认加密套件，返回证书指纹。
3. 交换 Change Cipher（切换加密算法）和 Finished（握手完成），协商出对称加密密钥。