從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（握手完成），協商出對稱加密密鑰。