WebRTC SDP 詳解和剖析

WebRTC 是 Web Real-Time Communication，即網頁實時通訊的縮寫，是 RTC 協議的一種 Web 實現，專案由 Google 開源，並和 IETF 和 W3C 制定了行業標準。在國內 WebRTC 已經獲得了越來越多廠商的支援，應用前景變得更加廣闊，所以我們也開設專欄，分享阿里雲內部的 WebRTC 研究工作。

本篇是阿里雲視訊雲 WebRTC 技術專欄系列文章的第一篇，作者將從 WebRTC SDP 例子和關鍵屬性的角度為大家深度剖析解讀，其中也分享了阿里雲技術專家的一些實踐經驗，希望能對大家有所幫助或者啟發。

作者：

忘籬，阿里雲高階技術專家，負責阿里雲 RTC 伺服器研發；

泰一，阿里雲高階開發工程師，從事阿里雲 RTC 伺服器研發

Overview

狹義的說 WebRTC 是指瀏覽器端，瀏覽器端如何直接交換資料呢？肯定是沒法完全獨立完成的，必須得依靠伺服器。一般依賴幾種伺服器：

1. Signaling 信令伺服器，也就是交換房間和會議的媒體資訊，以及會議期間的訊息，媒體描述使用的是 SDP 協議，也就是本文剖析的重點。

2. ICE 伺服器，可以分為幫助兩個客戶端打洞建立 P2P 連線的 STUN 伺服器，還有如果連不通就直接轉發的 TURN 伺服器。ICE 的資訊叫 Candidate，可以通過 SDP 交換，或者通過 Trickle。

3. SFU 或 MCU 伺服器，如果多個人開會，每個端都向其他參會的端直接傳送資料叫 MESH，但是 MESH 明顯有侷限性，SFU 就是轉發可以讓客戶端只上行一路流轉給其他客戶端，而 MCU 更強大，可以上下行都只有一路流。

Note: WebRTC 除了傳輸，還有一個重要特性就是安全性，也就是 DTLS，而 DTLS 有些資訊就是通過 SDP 傳遞的，後面會有相關的技術文章來介紹 DTLS。

下面，我們正式介紹 SDP 協議。

What's SDP

本文開篇的 SDP 關鍵屬性圖，已經幫助我們以全域性的視角一窺 SDP 的模樣。SDP 描述了媒體會話，網路資訊、安全特性、傳輸策略等，圖中的每一個 SDP 屬性都在不同的應用場景下發揮著不同的作用，不可小覷。

接下來，我們進一步給出 SDP 的官方定義：SDP(Session Description Protocol) 是一種會話描述協議，基於文字，其本身並不屬於傳輸協議，需要依賴其它的傳輸協議（比如 SIP 和 HTTP）來交換必要的媒體資訊，用於兩個會話實體之間的媒體協商。

WebRTC 的 Offer 和 Answer 包含了 SDP。相關的 RFC 包括：

1. 1998, RFC2327

2. 2006, RFC4566

一個不錯的 WebRTC 的 SDP 例子分析

Offer and Answer

WebRTC 使用 Offer-Answer 模型交換 SDP，Offer 中有 SDP，Answer 中也有。例如 Alice 和 Bob 通過 WebRTC 通訊：

// Alice Offerv=0o=- 2397106153131073818 2 IN IP4 127.0.0.1s=-t=0 0a=group:BUNDLE videoa=msid-semantic: WMS gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LySm=video 9 UDP/TLS/RTP/SAVPF 96 97c=IN IP4 0.0.0.0a=rtcp:9 IN IP4 0.0.0.0a=ice-ufrag:l5KUa=ice-pwd:+Sxmm3PoJUERpeHYL0HW4/T9a=ice-options:tricklea=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:74a=setup:actpassa=mid:videoa=sendrecva=rtcp-muxa=rtcp-rsizea=rtpmap:96 VP8/90000a=rtcp-fb:96 goog-remba=rtcp-fb:96 transport-cca=rtcp-fb:96 ccm fira=rtcp-fb:96 nacka=rtcp-fb:96 nack plia=rtpmap:97 rtx/90000a=fmtp:97 apt=96a=ssrc-group:FID 2527104241a=ssrc:2527104241 cname:JPmKBgFHH5YVFyaJa=ssrc:2527104241 msid:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS c7072509-df47-4828-ad03-7d0274585a56a=ssrc:2527104241 mslabel:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LySa=ssrc:2527104241 label:c7072509-df47-4828-ad03-7d0274585a56
// Bob Answerv=0o=- 5443219974135798586 2 IN IP4 127.0.0.1s=-t=0 0a=group:BUNDLE videoa=msid-semantic: WMS uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVsm=video 9 UDP/TLS/RTP/SAVPF 96 97c=IN IP4 0.0.0.0a=rtcp:9 IN IP4 0.0.0.0a=ice-ufrag:MUZfa=ice-pwd:4QhikLcmGXnCfAzHDB++ZjM5a=ice-options:tricklea=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:DEa=setup:activea=mid:videoa=sendrecva=rtcp-muxa=rtcp-rsizea=rtpmap:96 VP8/90000a=rtcp-fb:96 goog-remba=rtcp-fb:96 transport-cca=rtcp-fb:96 ccm fira=rtcp-fb:96 nacka=rtcp-fb:96 nack plia=rtpmap:97 rtx/90000a=fmtp:97 apt=96a=ssrc-group:FID 3587783331a=ssrc:3587783331 cname:INxZnBV2Sty1zlmNa=ssrc:3587783331 msid:uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVs a3b297e7-cdbe-464e-a32c-347465ace055a=ssrc:3587783331 mslabel:uiZ7cB0hsFDRGgTIMNp6TajUK9dOoHi43HVsa=ssrc:3587783331 label:a3b297e7-cdbe-464e-a32c-347465ace055

Remark: 用 Chrome 瀏覽器，先開啟webrtc-internals，然後開啟 [Alice](https://ossrs.net/webrtc-web/p2p.initiator.html) 頁面點 Share 按鈕，接著開啟 [Bob](https://ossrs.net/webrtc-web/p2p.responder.html) 頁面點 Share，看到上面的 Offer 和 Answer。

交換完 SDP 後，會交換 Candidate：

// Alice Candidatecandidate: candidate:1912876010 1 udp 2122260223 30.2.220.94 52832 typ host generation 0 ufrag l5KU network-id 1 network-cost 10candidate: candidate:1015535386 1 tcp 1518280447 30.2.220.94 9 typ host tcptype active generation 0 ufrag l5KU network-id 1 network-cost 10
// Bob Candidatecandidate:1912876010 1 udp 2122260223 30.2.220.94 51551 typ host generation 0 ufrag MUZf network-id 1 network-cost 10

最後 Alice 和 Bob 通訊的 Candidate pair，選擇的是 UDP 通道：

Alice 傳送的 Video 的資訊：

Alice 收到的 (Bob 的) Video 資訊：

一般來說，推流方先發起 Offer，接收方給 Answer。比如客戶端推流到 SFU，客戶端發起 Offer 推流，SFU 給客戶端 Answer，客戶端將流推到 SFU，SFU 再轉發給其他客戶端。Licode 和 Janus 都是這種做法，這種方式下，如果客戶端需要拉取其他的客戶端的流，一般需要使用另外的 PeerConnection，接收 SFU 的 Offer，生成 Answer 後迴應給 SFU。

不過，推流方發起 Offer 不是必須的，接收方也可以給 Offer，推流方給 Answer。比如 MediaSoup 這種 SFU，客戶端先給一個 Offer 給 SFU，SFU 只是檢查這個 Offer 中的媒體特性，然後 SFU 會生成 Offer（包含會議中的其他客戶端的流，如果沒有人則沒有 SSRC）給客戶端，客戶端傳送 Answer 給 SFU。這種方式的好處是其他客戶端加入，以及流的變更（比如關閉視訊開啟視訊時），都可以使用 Reoffer，也就是統一由 SFU 發起新的 Offer，客戶端響應，SFU 和客戶端的互動模式只有一種。

SDP Structure

SDP 描述分為兩部分，分別是會話級別的描述（session level）和媒體級別的描述（media level），其具體的組成可參考 RFC4566 ，帶星號 (*) 的是可選的。常見的內容如下：

Session description（會話級別描述）         v=  (protocol version)         o=  (originator and session identifier)         s=  (session name)         c=* (connection information -- not required if included in all media)         One or more Time descriptions ("t=" and "r=" lines; see below)         a=* (zero or more session attribute lines)         Zero or more Media descriptions
Time description         t=  (time the session is active)
Media description（媒體級別描述）, if present         m=  (media name and transport address)         c=* (connection information -- optional if included at session level)         a=* (zero or more media attribute lines)

對照 Alice 的 Offer（只包含了視訊沒有開啟音訊）：

// Session descriptionv=0o=- 2397106153131073818 2 IN IP4 127.0.0.1s=-c=IN IP4 0.0.0.0
// Time descriptiont=0 0
// Session Attributesa=group:BUNDLE videoa=msid-semantic: WMS gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS
// Media descriptionm=video 9 UDP/TLS/RTP/SAVPF 96 97c=IN IP4 0.0.0.0a=rtcp:9 IN IP4 0.0.0.0a=ice-ufrag:l5KUa=ice-pwd:+Sxmm3PoJUERpeHYL0HW4/T9a=ice-options:tricklea=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:74a=setup:actpassa=mid:videoa=sendrecva=rtcp-muxa=rtcp-rsizea=rtpmap:96 VP8/90000a=rtcp-fb:96 goog-remba=rtcp-fb:96 transport-cca=rtcp-fb:96 ccm fira=rtcp-fb:96 nacka=rtcp-fb:96 nack plia=rtpmap:97 rtx/90000a=fmtp:97 apt=96a=ssrc-group:FID 2527104241a=ssrc:2527104241 cname:JPmKBgFHH5YVFyaJa=ssrc:2527104241 msid:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS c7072509-df47-4828-ad03-7d0274585a56a=ssrc:2527104241 mslabel:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LySa=ssrc:2527104241 label:c7072509-df47-4828-ad03-7d0274585a56

SDP Line 是順序相關的，比如 a=rtpmap:96 後面的都是它相關的設定，直到下一行是 a=rtpmap 或者其他屬性。

SDP Line 沒有統一的 Schema 描述，也就是沒有一個固定的規則能解析所有 Line， SDP Grammer 只是描述了 SDP 相關的屬性，具體每個屬性的表達需要根據屬性定義，定義在 [RFC 4566]( https://tools.ietf.org/html/rfc4566#section-6) ，例如：

a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

SDP 解析時，每個 SDP Line 都是以 key=... 形式，解析出 key 是 a 後，可能有兩種方式，可參考 RFC4566 ：

a=<attribute>a=<attribute>:<value>

比如 c=IN IP4 0.0.0.0，key 為 c。

比如 a=rtcp-mux，key 為 a，attribute 為 rtcp-mux，沒有 value。

比如 a=rtpmap:96 VP8/90000，key 為 a，attribute 為 rtpmap，value=96 VP8/90000。

有時候並非冒號 (:) 就一定是 <attribute>:<value> ，實際上 value 裡面也會有冒號，比如：

a=fingerprint:sha-256 7C:93:85:40:01:07:91:BEa=extmap:2 urn:ietf:params:rtp-hdrext:toffseta=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-timea=ssrc:2527104241 msid:gLzQPGuagv3xXolwPiiGAULOwOLNItvl8LyS

Session Level Field

會話級別的 SDP 描述欄位包括：v、o、s、c、b、t。

• v(version)

SDP 協議版本，值固定為 0。

• o(origin)

代表會話的發起者。

• s(session name)

會話的名稱，每個 SDP 中有且僅能有一個 s 描述，其值不能為空。

• c(connection data)

攜帶了會話的連線資訊，其實就是 IP 地址。

SDP 的會話級別描述可以包含該欄位，每一個媒體級別的描述也可以包含該欄位，如果會話級別和媒體級別都有 c line，那麼以媒體級別的 c line 為準。

因為 WebRTC 使用 ICE candidate 交換地址資訊，所以不會用到 c line，不過這並不代表 c line 沒有用，在 SIP 視訊會議場景中，c line 就必不可少了，文末會再次介紹該欄位。

• b (bandwidth)

表示會話或媒體使用的建議頻寬。

• t(timing)

指定了會話的開始和結束時間，如果開始和結束時間都為 0，那麼意味著這次會話是永久的。

關於會話級別欄位的更詳細的描述，請參考 RFC 4566 。

Media Codecs

會話級別描述完成後，後面就是零到多個媒體級別描述，比如：

// Session Descriptionv=0......
// Audio Media Descriptionm=audio 9 UDP/TLS/RTP/SAVPF 111......
// Video Media Descriptionm=video 9 UDP/TLS/RTP/SAVPF 96 97......

這個 SDP 描述了一個音訊和一個視訊，它的格式參考 RFC4566 :

m=<media> <port> <proto> <fmt> ...

其中，後面的一串數字 111 和 96 97 就是 fmt，分別代表音訊和視訊的 Media Codec，後面會跟著 rtpmap、rtcp-fb、fmtp 這些屬性來做進一步的詳細的描述。

m=audio 9 UDP/TLS/RTP/SAVPF 111a=mid:audioa=rtpmap:111 opus/48000/2a=rtcp-fb:111 transport-cca=fmtp:111 minptime=10;useinbandfec=1
m=video 9 UDP/TLS/RTP/SAVPF 96 97a=mid:videoa=rtpmap:96 VP8/90000a=rtcp-fb:96 goog-remba=rtcp-fb:96 transport-cca=rtcp-fb:96 ccm fira=rtcp-fb:96 nacka=rtcp-fb:96 nack plia=rtpmap:97 rtx/90000a=fmtp:97 apt=96

Remark: 當然，M line 的型別不是隻有 audio 和 video，還有 application(bfcp)、text 等媒體型別。

Remark: a=mid 屬性可以認為是每個 M 描述的唯一 ID。比如 a=mid:audio，那麼 audio 這個字串就是這個 M 描述的 ID。有的時候 mid 屬性值也可以用數字表示，比如 a=mid:0，那麼 0 也是這個 M 描述的 ID。mid 值一般和 grouping 傳輸屬性的 BUNDLE 策略結合來用，比如 a=group:BUNDLE audio video，代表本次會話將對 mid 為 audio 和 video 的 M 描述進行復用傳輸。

Remark: M line 的數字 9 代表該媒體型別的傳輸埠，在 RTC 場景中都是使用 ICE candidate 的地址資訊進行資料傳輸，所以 M line 的 port 並沒有用到。不過，在 SIP 的場景下，M line 的 port 就十分重要了，此時，port 代表 RTP 埠，而且必須是偶數。結合 SDP 會話級別描述中的 C line 中的 IP 地址，我們就可以知道 SIP 的這路媒體流的傳輸地址。

Remark: RTX 表示是重傳，比如 video 的 97，就是 apt=96 的重傳。也就是說如果用的是 97 這個編碼格式，它是在 96(VP8) 基礎上加了重傳功能。

而一共有多少媒體流，則是通過 SSRC 指定的：

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126a=ssrc:2582129002 cname:8Y1pmIKBijmWeALua=ssrc:2582129002 msid:34fD1qguf2v79436S1khLkth8Nb6LbedcF9H bab38910-40cd-4581-9a20-e3f558abb397a=ssrc:2582129002 mslabel:34fD1qguf2v79436S1khLkth8Nb6LbedcF9Ha=ssrc:2582129002 label:bab38910-40cd-4581-9a20-e3f558abb397
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124a=ssrc:565530905 cname:8Y1pmIKBijmWeALua=ssrc:565530905 msid:34fD1qguf2v79436S1khLkth8Nb6LbedcF9H 2c533cfe-b6bf-41a8-93f0-1ca031436702a=ssrc:565530905 mslabel:34fD1qguf2v79436S1khLkth8Nb6LbedcF9Ha=ssrc:565530905 label:2c533cfe-b6bf-41a8-93f0-1ca031436702

Remark: SSRC 就包含了需要傳送的媒體流，另外 Offer 和 Answer 中都可以包含 SSRC。比如客戶端和 MediaSoup 通訊時，MediaSoup 總是給客戶端發 Offer，MediaSoup 的 Offer 包含了 MediaSoup 要傳送（轉發其他客戶端的流給客戶端）的媒體流 SSRC，同時客戶端的 Answer 中也包含了自己要推送的 SSRC 流，他們的型別都是 sendrecv。

Remark: msid 對應了 NetStream.id ，也就是代表了不同的媒體源，這些 SSRC 可以是不同的媒體源。

如何確定最後的編碼？對方會在 Answer 中給出，比如上面 Offer 給出了多個編碼，在 Answer 中會選擇一個：

<code data-type="codeline">m=audio 9 UDP/TLS/RTP/SAVPF 111</code><code data-type="codeline">m=video 9 UDP/TLS/RTP/SAVPF 100 102 127 125 108 124</code><code data-type="codeline">a=rtpmap:100 H264/90000</code><code data-type="codeline">a=rtpmap:102 H264/90000</code><code data-type="codeline">a=rtpmap:127 H264/90000</code><code data-type="codeline">a=rtpmap:125 H264/90000</code><code data-type="codeline">a=rtpmap:108 red/90000</code><code data-type="codeline">a=rtpmap:124 ulpfec/90000</code>

雖然 Video 編碼有 100 到 125，但是他們都是 H.264，而 108 和 124 則是 FEC，基於 H.264。

PlanB and UnifiedPlan

上面的 MediaCodecs 中，沒有規定如何指定多條流。實際上 Audio 和 Video 都有多個 SSRC，每個 SSRC 的編碼可能相同但也可能不同。比如網際網路視訊會議，用移動端接入時，編碼可能都是 H.264，但是和其他終端接入時可能會有其他編碼。

如果 SSRC 的編碼不相同，那麼將這些 SSRC 放在同一個 M 描述就會有問題，這就是 PlanB 和 UnifiedPlan 的關鍵所在。對於 PlanB 只有一個 M(audio) 和 M(video)，他們的編碼要相同，當有多路媒體流時，則根據 SSRC 去區分。UnifiedPlan 則可以有多個 M(audio) 和 M(video)，每路流都有自己的 M 描述，這樣就可以支援不同的編碼。

PlanB 和 UnifiedPlan 其實就是 WebRTC 在多路媒體源（multi media source）場景下的兩種不同的 SDP 協商方式。如果引入 Stream 和 Track 的概念，那麼一個 Stream 可能包含 AudioTrack 和 VideoTrack，當有多路 Stream 時，就會有更多的 Track，如果每一個 Track 唯一對應一個自己的 M 描述，那麼這就是 UnifiedPlan，如果每一個 M line 描述了多個 Track(track id)，那麼這就是 Plan B。

Note: 當只有一路音訊流和一路視訊流時，Plan B 和 UnifiedPlan 的格式是相互相容的。

Remark: Chrome 早期支援的是 PlanB，目前最新版本也支援了 UnifiedPlan，參考 Need to implement WebRTC "Unified Plan" for multistream 。

PlanB 參考下圖：

UnifiedPlan 參考下圖：

Candidate

Candidate 就是傳輸的候選人，客戶端會生成多個 Candidate，比如有 host 型別的、有 relay 型別的、有 UDP 和 TCP 的，如下圖所示：

sdpMid: audio, sdpMLineIndex: 0, candidate:2213672593 1 udp 2122260223 30.2.228.19 51068 typ hostsdpMid: video, sdpMLineIndex: 1, candidate:2213672593 1 udp 2122260223 30.2.228.19 55061 typ host
sdpMid: audio, sdpMLineIndex: 0, candidate:3446803041 1 tcp 1518280447 30.2.228.19 9 typ hostsdpMid: video, sdpMLineIndex: 1, candidate:3446803041 1 tcp 1518280447 30.2.228.19 9 typ host
sdpMid: video, sdpMLineIndex: 1, candidate:150963819 1 udp 41885439 182.92.80.26 54400 typ relay raddr 42.120.74.91 rport 37714sdpMid: audio, sdpMLineIndex: 0, candidate:150963819 1 udp 41885439 182.92.80.26 59241 typ relay raddr 42.120.74.91 rport 49618

Remark： 我們去掉了後面的屬性，比如 generation 0 ufrag kce9 network-id 1 network-cost 10 ，這些屬於 Candidate 的描述，和連通性檢查等相關。

客戶端自己生成了 6 個 Candidates，3 個 Audio 和 3 個 Video，2 個 TCP 和 4 個 UDP，4 個 host 和 2 個 relay。當然對方也會有很多 Candidate，接下來就是自己的 Candidates 和對方的 Candidates 匹配連通（ICE Connectivity Checks），形成 CandidatePair 也就是傳輸通道。Candidate 還附帶了網路屬性，比如 network-cost 會在 ICE Connectivity Checks 時用到。

Remark: 關於 Candidate 的型別，還有 srflx 以及 prflx，關於這兩種 Candidate 型別的定義以及區分，後面會在 ICE 相關的技術文章中介紹。

Remark: 關於 ICE Connectivity Checks 我們會在後面給出詳細的分析，涉及到了 STUN 協議。下面會總結出 ICE 相關的 SDP 資訊。

SDP 和 Candidate 都是通過信令交換的。如果對方只給了 relay 的 Candidate，例如：

sdpMid: audio, sdpMLineIndex: 0, candidate:150963819 1 udp 41885439 182.92.80.26 51542 typ relay raddr 42.120.74.91 rport 56380

這種情況下，肯定最後連通的 CandidatePair 是 Relay 對 Relay，如下圖所示：

從這個圖中能看出來這個傳輸通道的傳送和接收位元速率、包的個數、RTT 和丟包率等資訊。

實際上，由於我們這個客戶端還有 host 型別的 Candidate，所以它會嘗試直接用 host 的這個 Candidate 和對方的 relay 直接連線：

sdpMid: audio, sdpMLineIndex: 0, candidate:2213672593 1 udp 2122260223 30.2.228.19 51068 typ host
Statistics Conn-audio-1-1googActiveConnection	false

當然，由於沒有連通所以這個 CandidatePair 就不可用。

Remark: WebRTC 是具備在多個 Candidate 之間切換的能力的，具體在 ICE Connectivity Checks 中我們再分析。

上面的 Candidates 自己生成了 2 個 Relay 的 Candidates，一個是 audio 的一個是 video 的，為何只用到了 audio 的呢？這就是下面的 BUNDLE 涉及的了。

Bundle and RTCP-MUX

傳輸時，可以複用媒體通道，一種是音訊和視訊的複用，一種是 RTCP 和 RTP 的複用。

RTCP 和 RTP 複用，表示 Sender 使用一個傳輸通道（單一埠）傳送 RTP 和 RTCP：

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126a=rtcp-mux
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124a=rtcp-mux

此時，Receiver 必須準備好在 RTP 埠上接收 RTCP 資料，並需要預留一些資源，比如 RTCP 頻寬。

音訊和視訊複用時，最後只會用一個 Candidate 傳輸，比如客戶端自己的 SDP Offer，和兩個 relay 的 Candidates：

a=group:BUNDLE audio video
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126a=mid:audio
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124a=mid:video

<code data-type="codeline">sdpMid: video, sdpMLineIndex: 1, candidate:150963819 1 udp 41885439 182.92.80.26 54400 typ relay raddr 42.120.74.91 rport 37714</code><code data-type="codeline">sdpMid: audio, sdpMLineIndex: 0, candidate:150963819 1 udp 41885439 182.92.80.26 59241 typ relay raddr 42.120.74.91 rport 49618</code>

這表示最終 audio 和 video 儘管可能有獨立的 Candidate，但是如果對方也是 BUNDLE，那麼最終只會用一個 Candidate。例如，如果對方的 Answer 是：

a=group:BUNDLE audio video
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126a=mid:audio
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124a=mid:video

sdpMid: audio, sdpMLineIndex: 0, candidate:150963819 1 udp 41885439 182.92.80.26 51542 typ relay raddr 42.120.74.91 rport 56380

最後它們只會用一個 Candidate 傳輸。如下圖所示：

rtcp-mux 將 RTP 和 RTCP 複用到單一的埠進行傳輸，這簡化了 NAT traversal，而 BUNDLE 又將多路媒體流複用到同一埠進行傳輸，這不僅使 candidate harvesting 等 ICE 相關的 SDP 屬性變得簡單，而且又進一步簡化了 NAT traversal。

rtcp-mux 是與 RTC 傳輸相關的重要的 SDP 屬性，關於它的 SDP 協商的原則如下：

1. 如果 Offer 攜帶 rtcp-mux 屬性，並且 Answer 方希望複用 RTP 和 RTCP 到單一埠，那麼 Answer 必須也要攜帶該屬性。

2. 如果 Offer 沒有攜帶 rtcp-mux 屬性，那麼 Answer 也一定不能攜帶 rtcp-mux 屬性，而且 Answer 方禁止 RTP 和 RTCP 複用單一埠。

3. rtcp-mux 的協商和使用必須是雙向的。

舉個例子。客戶端去訂閱伺服器的流，客戶端的 Offer 沒有攜帶 rtcp-mux 屬性，那麼伺服器會認為客戶端不支援 rtcp-mux，也不會走 rtcp 複用的流程。相反，伺服器會分別建立 RTP 和 RTCP 兩個傳輸通道，只有當兩個通道的 ICE 和 DTLS 都成功，才會認為本次訂閱的傳輸通道建立成功，繼而向客戶端發流。

試想，如果因為你的疏忽導致 Offer 漏掉了 rtcp-mux 屬性，那麼你將永遠等不到伺服器 Ready 的那一天。所以，SDP 看似只是一些文字，很簡單，但是隻有在專案的實戰中，多遇到幾個坑，才能更深切的體會到 SDP 屬性的含義以及這些屬性是如何在 RTC 場景中去發揮作用的。

Remark: 關於 rtcp-mux 更詳細的協商細節請參考 RFC 8035 。

Remark: 關於 rtcp-mux 場景下如何通過頭部欄位區分 rtp 和 rtcp，請參考 RFC 5761 。

ICE Connectivity

這裡我們只說明 SDP 中和 ICE Connectivity Checks 相關的資訊，具體的過程我們會在其他文章中單獨分析。

SDP 中和 ICE 相關的資訊包括：

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126a=ice-ufrag:kce9a=ice-pwd:M31WxfrwmrFvPws4+tPdbsCEa=ice-options:trickle
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124a=ice-ufrag:kce9a=ice-pwd:M31WxfrwmrFvPws4+tPdbsCEa=ice-options:trickle

ufrag 和 pwd 就是 ICE short-term 認證演算法用到的使用者名稱和密碼。而 trickle 說明 SDP 中沒有包含 candidate 資訊，Candidate 是通過信令單獨交換的，這樣可以做到 Connectivity checks 和 Candidate harvesting 並行處理，提高會話建立的速度。

DTLS

這裡我們只說明 SDP 中關於 DTLS 的資訊，具體的 DTLS 握手過程會在 DTLS 相關的技術文章中單獨分析。

SDP 中和 DTLS 相關的資訊包括：

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126B0:A2:B3:AB:0B:A3:44:22:B1:C8:69:52:ED:04:E8:5A:A4:C3:7A:A6:55:F3:BA:76:62:26:4B:F7:9F:DD:F1:BDa=setup:actpass
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124a=fingerprint:sha-256 B0:A2:B3:AB:0B:A3:44:22:B1:C8:69:52:ED:04:E8:5A:A4:C3:7A:A6:55:F3:BA:76:62:26:4B:F7:9F:DD:F1:BDa=setup:actpass

其中 fingerprint 是 DTLS 過程中的 Certificate 證書的簽名，防止客戶端和伺服器的證書被篡改。

另外，setup 指的是 DTLS 的角色，也就是誰是 DTLS Client(active)，誰是 DTLS Server(passive)，如果自己兩個都可以那就是 actpass。這裡我們是 actpass，那麼就要由對方在 Answer 中確定最終的 DTLS 角色：

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126a=fingerprint:sha-256 B1:FD:D6:2D:94:4E:33:A1:8C:9D:EF:ED:EB:AC:CC:2D:E2:37:15:9B:24:8C:BF:F2:7D:6A:B3:81:23:AA:13:54a=setup:active

對方是 active，也就是 DTLS Client，那麼自己就只能是 DTLS Server，會由對方發起 DTLS ClientHello 開始 DTLS 過程。

Stream Direction

媒體流的方向有四種，分別是 sendonly、recvonly、sendrecv、inactive，它們既可以出現在會話級別描述中也可以出現在媒體級別的描述中。

• sendonly 表示只發送資料，比如客戶端推流到 SFU，那麼會在自己的 Offer(or Answer) 中攜帶 senonly 屬性

• revonly 表示只接收資料，比如客戶端向 SFU 訂閱流，那麼會在自己的 Offer(or Answer) 中攜帶 recvonly 屬性

• sendrecv 表示可以雙向傳輸，比如客戶端加入到視訊會議中，既要釋出自己的流又要訂閱別人的流，那麼就需要在自己的 Offer(or Answer) 中攜帶 sendrecv 屬性

• inactive 表示禁止傳送資料，比如在基於 RTP 的視訊會議中，主持人暫時禁掉使用者 A 的語音，那麼使用者 A 的關於音訊的媒體級別描述應該攜帶 inactive 屬性，表示不能再發送音訊資料。

NOTE: RFC 4566 : senonly 和 recvonly 屬性僅應用於媒體，不用於媒體控制相關的協議。比如在基於 RTP 的媒體會話中，即使是 recvonly 模式，也仍然要傳送 RTCP 包，即使是 senonly 模式，也依然會接收並正常處理 RTCP 包。

媒體流方向的四個屬性很重要，在組裝 SDP 時要仔細校驗，保證流方向的正確性。

舉個例子，客戶端去訂閱伺服器的流。如果此時客戶端的 Offer 攜帶的屬性並不是 recvonly 而是 sendonly，那麼即使在信令層面的確是訂閱的語義，但是由於某些伺服器對 SDP 各屬性的校驗是十分全面和嚴格的（本該如此），這種場景下，伺服器將不會發送媒體流到客戶端，而且伺服器回覆的 Answer 可能根本不會攜帶 SSRC。

RTCP Feedback

下面，我們聊一下 rtcp-fb 這個媒體級別的 SDP 屬性，它能告訴我們媒體會話能夠對哪些 RTCP 訊息進行反饋，是一個和 QoS 相關的重要的 SDP 屬性。

<code data-type="codeline">m=video 9 UDP/TLS/RTP/SAVPF 96</code><code data-type="codeline">a=mid:video</code><code data-type="codeline">a=rtpmap:96 VP8/90000</code><code data-type="codeline">a=rtcp-fb:96 transport-cc</code><code data-type="codeline">a=rtcp-fb:96 ccm fir</code><code data-type="codeline">a=rtcp-fb:96 nack pli</code>

如上 SDP 資訊，這是一個視訊的 M 描述，VP8 編碼，payload type 是 96。最後的 3 個 rtcp-fb 屬性則說明了對於 96 這個 media codec 來講，在網路擁塞控制方面支援 twcc；在 ARQ 方面支援 nack 處理，能夠重傳丟失的 RTP 包；在關鍵幀方面支援 fir 和 pli 處理，有能力進行關鍵幀的傳送。

在做 SIP 的時候，遇到過一個坑：向某臺型號的 SIP 裝置傳送 PLI 請求後，並沒有收到關鍵幀，經過一番折騰，最後發現，這臺裝置的 rtcp-fb 描述如下：

m=video 16402 RTP/AVP  34a=rtpmap:34 H263/90000a=fmtp:34 CIF4=1;CIF=1;QCIF=1;SQCIF=1a=sendrecva=rtcp-fb:* ccm tmmbra=rtcp-fb:* ccm fir

也就是說這臺裝置只支援 FIR 請求，沒有處理 PLI 請求的能力（PS: 為什麼沒能早一些檢查 SDP 的 rtcp 反饋能力，淚目）。在此也想著重強調一下：對於一些很專業嚴謹的系統或者裝置而言，SDP 完全體現了它們所擁有的能力，也可以讓我們發現其不具備的能力。SDP 的每一個屬性都是有其存在意義的，萬萬不可忽略。

Note: rtcp-fb 不能用於會話級別的描述中，只能用於媒體級別的描述，而且其 M 描述的 proto 欄位一定要指定 AVPF。

Note: 存在這種格式，a=rtcp-fb:* ccm fir，星號是一個萬用字元，表示該 M 描述下的所有型別的 media codec 都支援 fir 的處理和關鍵幀的反饋。

Compare with SIP SDP

RTC 場景與 SIP 場景下的 SDP 描述的不同表現在傳輸、媒體、信令三個層面。

Transmission Level

1. 建連流程。RTC 場景下的音視訊媒體流建連流程一般是 ICE + DTLS，而 SIP 場景下沒有這套建連流程，所以也沒有 ICE/DTLS 相關的 SDP 屬性，比如 ufrag、pwd、setup、fingerprint 等。

1. 埠複用。RTC 場景下一般都是音視訊流以及 RTP/RTCP 複用單一埠，通過 SSRC 區分每一路流，通過資料包的頭部欄位值來區分 RTP/RTCP，而 SIP 場景下不會複用埠，因此沒有 rtcp-mux 屬性，也沒有 grouping 相關的屬性，比如 BUNDLE，且音視訊的 RTP 和 RTCP 都是獨立埠進行傳輸，共有四個，所以天然可以使用埠來區分流以及 RTP/RTCP，因此也沒有 SSRC 屬性。

1. 鏈路探測。RTC 場景下一般通過 ICE 的 STUN 探測環節來發現對端經過 NAT 對映之後的出口地址，稱為 srflx，而 SIP 場景下需要自己實現對端地址發現的功能，以獲取到 SIP 裝置經過 NAT 對映之後的出口地址。

1. 地址資訊。RTC 場景下通過 SDP 的 candidate 交換對端地址資訊，SIP 場景下通過 C line 的 ip 以及 M line 的埠來交換對端地址資訊。

// RTC 場景a=candidate:1 1 udp 2013266431 30.27.136.138 14306 typ host
// SIP 場景c=IN IP4 30.41.5.131m=audio 2352 RTP/AVP 107 108 114 104 105 9 18 8 0 101 123m=video 2374 RTP/AVP 97 126 96 34 123

Media Level

1. 螢幕共享。SIP 場景下通過 BFCP 協議來進行螢幕共享的協商，通過 a=content 屬性來區分主流（main）和共享流 （slides），而 RTC 場景下通過外部/業務信令來進行螢幕共享的協商，主流和共享流的 SDP 描述一致，不會區分。

2. Media Codec。目前，RTC 場景下的音視訊編碼普遍是 Opus + H.264/VP8，SIP 場景下，對於音訊編碼，有很多 SIP 裝置並不支援 Opus，而採用比較古老的音訊編碼，比如 G722、PCMA、PCMU，對於視訊編碼，普遍支援 H.264，一般不支援 VP8。

Signaling Level

1. SDP 交換。都是 Offer/Answer 模型，RTC 場景下主要通過 HTTP/TCP 協議交換 SDP，一般是在 HTTP body 中攜帶 SDP 資訊。SIP 場景下可以通過 UDP/TCP/TLS 協議交換 SDP，在 INVITE 和 200 OK 中攜帶 SDP 資訊。

Summary

其實，SDP 文字化的協議格式本身很簡單，其難點在於不同的應用場景（比如傳統 SIP 視訊會議或者 RTC 場景）下擴展出的紛繁複雜的屬性及其含義，這些 SDP 屬性散落在眾多的 RFC 以及草案之中，不下一定的功夫是很難做到全面理解與掌握的（PS：每當說到此處，心裡總是一萬個馬奔騰，WebRTC 的 RFC 太多了而且互相關聯互相引用，看完這些 RFC 要準備好視力下降 0.2 度）。

下一篇，我們會重點講一下 WebRTC ICE，包括連通性檢測、狀態切換、trickle 以及 nomination。感謝閱讀。