SDP

一SDP介紹

1. SDP的核心功能

• 會話描述：定義會話的名稱、創建者、時間范圍、連接地址等全局信息。
• 媒體協商：明確媒體流的類型（如音頻、視頻）、傳輸協議（如RTP/UDP）、編碼格式（如H.264、Opus）及端口信息。
• 網絡參數：指定單播或多播地址、帶寬限制、加密密鑰等網絡相關配置。
• 兼容性支持：通過文本格式的靈活擴展，適配不同傳輸協議（如SIP、RTSP、WebRTC）。

2. SDP的協議結構

SDP由會話級描述和媒體級描述兩部分組成，采用<type>=<value>的文本格式，每行以單個字母表示類型，如v（版本）、m（媒體）等。

（1）會話級描述（Session-Level）

• 必選字段：
  • v=：協議版本（固定為v=0）。
  • o=：會話創建者信息，格式為o=<用戶名> <會話ID> <版本號> <網絡類型> <地址類型> <地址>。
  • s=：會話名稱，若未命名則用-占位。
  • t=：會話的起止時間（NTP時間戳）。
• 可選字段：
  • c=：連接信息（如c=IN IP4 192.168.1.1）。
  • b=：帶寬限制（如b=AS:500表示單媒體最大帶寬500kbps）。
  • a=：擴展屬性（如加密方式a=crypto:1 AES_CM_128_HMAC_SHA1_80）。

（2）媒體級描述（Media-Level）

每個媒體流以m=行開頭，描述具體參數：

• 必選字段：
  • m=：媒體類型（如audio/video）、端口、傳輸協議、負載類型列表（如m=audio 5004 RTP/AVP 96）。
• 關鍵屬性：
  • a=rtpmap：動態負載類型與編碼格式的映射（如a=rtpmap:96 H264/90000）。
  • a=fmtp：編碼參數的詳細配置（如a=fmtp:96 profile-level-id=42801f）。
  • a=sendrecv：媒體流方向（sendonly/recvonly/inactive）。

---

3. SDP在流媒體中的應用場景

1. 實時通信（WebRTC）
   在WebRTC中，SDP通過Offer/Answer模型交換雙方的媒體能力（如支持的編解碼器），并配合ICE協議完成網絡穿透。

2. 視頻會議與直播
   描述多路音視頻流的傳輸參數，支持多播地址分配和分層編碼（如H.264的分辨率適配）。

3. 流媒體傳輸（RTSP）
   RTSP協議通過SDP在DESCRIBE響應中傳遞媒體信息（如文件格式、時間范圍），客戶端據此發起播放請求。

4. 網絡電話（VoIP）
   協商音頻編碼格式（如G.711、Opus）和傳輸地址，確保通話雙方兼容。

---

4. SDP的示例與解析

以下是一個簡化的SDP示例：

v=0
o=- 123456789 2 IN IP4 192.168.1.1
s=Example Session
c=IN IP4 192.168.1.1
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 OPUS/48000/2
a=sendrecv
m=video 5006 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01f

• 會話級：定義版本、創建者IP和會話名稱。
• 音頻流：使用Opus編碼，采樣率48kHz，雙向傳輸。
• 視頻流：H.264編碼，支持特定分辨率配置。

---

5. SDP的局限性

• 無協商能力：僅描述媒體信息，編碼協商需依賴RTSP等協議。
• 靜態配置：不支持動態調整參數（如帶寬自適應），需結合其他協議實現。

二 會話管理 與SDP

1. RTSP（Real Time Streaming Protocol

(1) 是否需要建立會話？

• 需要顯式會話。
  RTSP 是基于會話的協議，客戶端與服務端通過 SETUP、PLAY、TEARDOWN 等命令明確控制會話生命周期。
  • 會話標識：通過 Session 頭字段維護會話狀態（如 Session: 12345678）。

(2) 是否需要 SDP？

• 需要 SDP。
  RTSP 使用 SDP（Session Description Protocol）在 DESCRIBE 響應中描述媒體流的詳細信息：

  m=video 0 RTP/AVP 96
  a=rtpmap:96 H264/90000
  a=control:track1
  

  • 作用：定義媒體類型（視頻/音頻）、編碼格式、傳輸協議（RTP）、控制路徑等。

---

2. RTMP（Real-Time Messaging Protocol）

(1) 是否需要建立會話？

• 通過隱式連接管理會話。
  RTMP 不顯式聲明會話，但通過以下機制維護邏輯會話：
  • NetConnection：客戶端與服務端建立持久 TCP 連接（類似會話）。
  • NetStream：在連接內創建多個流通道（如 stream ID=1），每個流獨立傳輸數據。

(2) 是否需要 SDP？

• 不需要 SDP。
  RTMP 通過以下方式傳遞媒體參數：
  • 元數據（onMetaData）：客戶端在發布流時發送元數據（分辨率、編碼格式等）。

    > onMetaData: { width: 1280, height: 720, videocodecid: 7 (H.264) }
    

  • 編碼協商：客戶端在 connect 命令中聲明支持的編解碼能力（如 videoCodecs: 128）。

---

3. HTTP流媒體（如HLS、DASH）

(1) 是否需要建立會話？

• 無顯式會話。
  HTTP流媒體基于無狀態的HTTP協議，通過請求-響應模式獲取媒體分片：
  • HLS：客戶端通過HTTP GET請求獲取 .m3u8 索引文件和 .ts 分片。
  • DASH：客戶端獲取 .mpd 清單文件并請求 .m4s 分片。

(2) 是否需要 SDP？

• 不需要 SDP。
  媒體參數通過以下方式描述：
  • 清單文件：如HLS的 .m3u8 或DASH的 .mpd，包含碼率、分辨率、分片URL等信息。

    #EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
    stream_360p.ts
    

---

對比總結

協議	會話管理	媒體描述方式	典型場景
RTSP	顯式會話（SETUP/PLAY）	SDP（DESCRIBE響應）	視頻監控、IPTV
RTMP	隱式會話（NetConnection）	元數據（onMetaData）	直播推流、低延遲交互
HTTP流媒體	無會話（無狀態HTTP）	清單文件（m3u8/mpd）	自適應流（HLS/DASH）

---

關鍵區別解釋

1. 會話管理

• RTSP：需要顯式控制會話狀態（如播放、暫停），適合需要精細控制的場景。
• RTMP：通過長連接維護隱式會話，適合持續流傳輸（如直播）。
• HTTP流媒體：無會話，每次請求獨立，適合CDN分發和自適應碼率。

2. 媒體參數傳遞

• RTSP：依賴SDP標準化描述，確保跨平臺兼容性。
• RTMP：通過私有元數據和命令協商參數，靈活性高但標準化較弱。
• HTTP流媒體：通過清單文件靜態描述，支持動態切換碼率。

---

適用場景建議

• 低延遲控制：RTMP（1-3秒）或 RTSP（配合RTP）。
• 高兼容性分發：HTTP（HLS/DASH）。
• 設備控制：RTSP（如攝像頭PTZ控制）。