从sdp开始到webrtc的通信过程
1. SDP
1.1 SDP的关键点
SDP（Session Description Protocol）通过分层、分类的属性字段，结构化描述实时通信会话的 会话基础、网络连接、媒体能力、安全策略、传输优化 等核心信息，每个模块承担特定功能：
1. 会话级别描述（全局会话元信息）
v=：协议版本（固定为0），标识 SDP 遵循的标准版本，确保解析兼容性。o=：会话发起者信息，格式为o=<用户名> <会话ID> <会话版本> <网络类型> <地址类型>，用于唯一标识会话（如多终端复用场景区分会话实例）。s=：会话名称/主题，简短描述会话内容（如s=视频会议），便于业务层识别。t=：会话时间范围，格式t=<起始时间> <结束时间>（UNIX 时间戳），用于预约会议或控制会话有效期。b=：带宽限制，格式b=<类型>:<带宽值>（如b=AS:1024表示总带宽 1024kbps），控制会话资源占用。
2. 网络描述（连通性与地址协商）
c=：默认网络连接信息，格式c=<网络类型> <地址类型>，定义会话级默认网络参数（媒体流可覆盖此配置），如c=IN IP4 0.0.0.0表示 IPv4 地址。a=candidate：ICE 候选地址，格式a=candidate:，用于交换 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 与具体编码（如<编码名>/<采样率> 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:，标记媒体流的唯一源（如<属性> 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同样通过信令回传给提议方。
- 媒体流数量与顺序：Answer 的
-
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 gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LySmsid-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配合使用。
- ICE 用户名，用于身份验证，与对端
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 中确定最终角色。
- DTLS 角色为
- 媒体流方向与复用
a=mid:video- 媒体流唯一标识（mid）为
video，与a=group:BUNDLE配合实现流复用。
- 媒体流唯一标识（mid）为
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）。
- Payload 97 映射为 RTX（重传编码），
- SSRC 与媒体源标识
a=ssrc-group:FID 2527104241- SSRC 组类型为
FID（流标识），关联 SSRC2527104241与媒体流。
- SSRC 组类型为
a=ssrc:2527104241 msid:...- MSID（媒体源 ID）为
gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS c7072509-df47-...，标识具体媒体源（如摄像头）。
- MSID（媒体源 ID）为
三、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，主动发起握手。 - 流程：
- Client 发送
Client Hello，携带加密套件、随机数。 - Server 回复
Server Hello，确认加密套件，返回证书指纹。 - 交换
Change Cipher（切换加密算法）和Finished（握手完成），协商出对称加密密钥。
- Client 发送
- SRTP 加密传输
DTLS 握手生成的密钥，用于 SRTP（安全实时传输协议） 加密媒体流：
- RTP 基础：媒体数据（如视频帧）封装为 RTP 包，携带时间戳、序列号。
- SRTP 加密：在 RTP 包中嵌入加密数据和完整性校验信息，确保传输安全。
- SrsSecurityTransport 的作用
图中SrsSecurityTransport是 Media Server（如 SRS）的安全传输模块，负责：
- 处理 DTLS 握手，协商加密密钥。
- 对 outgoing 媒体流用密钥加密（
Send Key），对 incoming 媒体流解密（Recv Key）。 - 实现
SRTP -> Security RTP转换，保障端到端加密。
四、完整通信流程总结
- 信令协商（SDP Offer/Answer）：通过信令服务器交换媒体能力、网络策略、安全配置。
- 网络穿透（ICE + STUN/TURN）：交换候选地址，测试连通性，选定最优传输路径。
- 安全传输（DTLS + SRTP）：握手协商加密密钥，加密媒体流并传输。
核心逻辑：
- 信令服务器是“协调员”，负责转发 SDP 和候选地址，但不处理媒体流。
- ICE 解决“网络不通”问题，DTLS/SRTP 解决“传输不安全”问题，SDP 是“协商语言”，共同支撑 WebRTC 通信。
简单说，就是 “信令协商规则 → 网络打通路径 → 加密保障安全” 的三层协同，让实时音视频通信在复杂网络环境下稳定、安全运行～