SDP簡介

在WebRTC的通信過程中，SDP是其中重要的協議。SDP（Session Description Protocol）全稱是會話描述協議。主要用于兩個會話實體之間的媒體協商。WebRTC引入SDP來描述媒體信息，用于媒體協商時決定雙方是否可以進行通信，以及用何種方式進行通信。SDP作為WebRTC的信令系統的一部分，驅動著WebRTC的運轉。從這個角度來說，SDP是WebRTC的靈魂。

標準SDP規范

標準SDP結構由一個會話級描述和多個媒體級描述組成，通常SDP中都會包含一個音頻媒體描述和一個視頻媒體描述。

每條描述信息都是 <type> = <value> 的形式(“=” 兩側不允許有空格存在。)。其中，<type>是描述的目標，它由單個字符構成；<value>是對<type>的解釋或約束。會話和媒體都有各自的<type>，另外還有一些公共的<type>。

常見的<type>如下：

會話級

v=(protocol version,協議版本) o=(owener/creator and session identifier,會話的創建者) s=(session name,會話名稱) t=(time the session is active,會話存活時間)

媒體級

m=(media,媒體）

公共

c=(connection information,網絡信息) a=(attribute,屬性)

這是一個典型簡化后的的SDP示例：

v=0 o=- 5910110687297165449 2 IN IP4 127.0.0.1 s=- t=0 0 ...//第一個媒體流，音頻流 m=audio 54797 UDP/TLS/RTP/SAVPF 8 ...//第2個媒體流，視頻流 m=video 9 UDP/TLS/RTP/SAVPF 125 ...

WebRTC中的SDP

WebRTC對標準SDP規范做了一些調整，按功能分成會話描述和媒體描述。其中，會話描述屬于標準SDP中的內容，通常我們不需要了解它。媒體描述中有WebRTC增加的內容，需要了解一下的。媒體描述的內容可以分成四個大類：媒體信息、網絡描述、安全描述、和服務質量描述。如圖所示：

媒體信息

媒體信息是標準SDP的內容，屬于SDP中的核心內容。其格式如下所示：

m=<media> <port>/<numbers> <transport> <fmt>

• <media>：媒體類型，audio、video等。
• <port>/<numbers>：端口，通常不會被使用。
• <transport>：傳輸協議，UDP、TCP等。
• <fmt>：媒體數據類型，通常為PayloadType列表。其具體含義需要在“a=rtpmap”中說明。

這里有幾個重要的屬性說明一下：

a=ssrc

ssrc是媒體源的唯一標識，每一路媒體流都有唯一的ssrc來標識它。另外，在ssrc這一行中有時還能看到cname，這是就是該媒體流的別名。ssrc不同的媒體流可以有相同的cname，表示他們屬于同一個媒體流（比如，重傳流的cname就和原始流的相同）。

a=rtpmap

rtpmap是一張PayloadType與編碼器的映射表。其格式如下所示：

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

• <payload type>：負載類型，與m line中的fmt中的對應。
• <encoding name>：端口，編碼器名稱，如VP8，VP9，OPUS等。
• <clock rate>：采樣率。
• <encodingparameters>：編碼參數，如音頻的聲道數信息。

a=fmtp

fmtp用于指定媒體數據格式。其格式如下所示：

a=fmtp:<payload type> <format specific parameters>

• <payload type>：負載類型，與m line中的fmt中的對應。
• <format specific parameters>：參數信息，其含義需要參考相關草案。

網絡描述

網絡描述也是標準SDP的內容。其中記錄了傳輸媒體數據時使用的網絡信息。下面幾個是其中比較重要的屬性：

a=candidate

描述了候選地址信息，是一個已經被廢棄的屬性，但因一些流媒體服務器上海有使用，所以WebRTC依然做了兼容

a=group:BUNDLE

指明哪些媒體數據可以復用同一個傳輸通道，以節約ICE資源。

a=rtcp-mux

指明RTP與RTCP是否復用同一端口，也是用以節約ICE資源。

a=rtcp-rsize

指明在用戶帶寬不足時，縮減RTCP非關鍵包的大小。

a=ice-options

指明WebRTC收集ICE Candidate的策略。一般默認為trickle（只要有可用的Candidate就進行交換，不需要等待所有的Candidate收集完成才交換）。

安全描述

這部分內容是WebRTC新增到SDP規范中去的。WebRTC的媒體通信提供了一套很好的安全機制。下面幾個是其中比較重要的屬性：

a=ice-ufrag和a=ice-pwd

指明ICE的賬號和密碼，用于驗證用戶的合法性。

a=fingerprint

指明DTLS握手時的證書指紋，用于驗證加密證書的有效性。

a=setup:(active/passive/actpass)

指明終端的角色，決定DTLS時是作為主動握手方還是被動連接方或是都可以。

服務質量

這部分內容也是WebRTC新增到SDP規范中去的。這個內容只控制WebRTC中很小一部分服務質量的開關。WebRTC中還包含有非常多的服務質量內容。只有以下一個屬性：

a=rtcp-fb

在媒體協商過程中，發起方的SDP中指明要開啟哪些RTCP反饋，而應答方則在回復的SDP中確認可以開啟哪些RTCP反饋。例如：

• nack：丟包重傳
• fir：申請關鍵幀
• transport-cc、goog-remb：擁塞控制算法。

Plan B和Unified Plan

目前，WebRTC中的SDP包含兩種規格，Plan B和Unified Plan。其中，Plan B是由標準SDP演化而來的，而Unified Plan是用來代替Plan B的新規格。兩者會在表達傳輸多路同類媒體流的時候格式會有區別。

在Plan B中，只有兩個媒體描述（m line），即音頻媒體描述（m=audio…）和視頻媒體描述（m=video…）。如果有多路同類媒體流則需要通過其媒體描述中的SSRC來區分。
而在Unified Plan中，每個媒體流都有一個媒體描述（m line）。

WebRTC SDP示例

v=0 //sdp版本號，一直為0,rfc4566規定 o=- 7017624586836067756 2 IN IP4 127.0.0.1 //username，沒有的話使用-代替，7017624586836067756是整個會話的編號，2表明會話版本 s=- //會話名，沒有的話使用-代替 t=0 0 //兩個值分別是會話的起始時間和結束時間，這里都是0表明沒有限制 a=group:BUNDLE audio video data //須要共用一個傳輸通道傳輸的媒體，若是沒有這一行，音視頻，數據就會分別單獨用一個udp端口來發送 a=msid-semantic: WMS h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C //WMS是WebRTC Media Stream簡稱，這一行定義了本客戶端支持同時傳輸多個流，一個流能夠包括多個 //track,通常定義了這個，后面a=ssrc這一行就會有msid,mslabel等屬性m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 //m=audio說明本會話包含音頻，9表明音頻使用端口9來傳輸，在webrtc中通常不使用， //若是設置為0，表明不傳輸音頻,UDP/TLS/RTP/SAVPF是表示用戶來傳輸音頻支持的協議， //udp、tls、rtp表明使用udp來傳輸rtp包，并使用tls加密； //SAVPF表明使用srtcp的反饋機制來控制通訊過程, //111 103 104 9 0 8 106 105 13 126表示本會話音頻支持的編碼，后臺幾行會有詳細補充說明c=IN IP4 0.0.0.0 //這一行表示你要用來接收或者發送音頻使用的IP地址，webrtc使用ice傳輸，不使用這個地址 a=rtcp:9 IN IP4 0.0.0.0 //用來傳輸rtcp地地址和端口，webrtc中不使用a=ice-ufrag:khLS a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ //以上兩行是ice協商過程當中的安全驗證信息 a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17 //以上這行是dtls協商過程當中需要的證書指紋，用來驗證DTLS證書的有效性a=setup:actpass //以上這行表明本客戶端在dtls協商過程當中，能夠作客戶端也能夠作服務端，參考rfc4145 rfc4572 a=mid:audio //在前面BUNDLE這一行中用到的媒體標識 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level //上一行指出我要在rtp頭部中加入音量信息，參考 rfc6464 a=sendrecv //上一行指出我是雙向通訊，另外幾種類型是recvonly,sendonly,inactive a=rtcp-mux //上一行指出rtp,rtcp包使用同一個端口來傳輸 a=rtpmap:111 opus/48000/2 //a=rtpmap都是對m=audio這一行的媒體編碼補充說明，指出了編碼采用的編號，采樣率，聲道等 a=rtcp-fb:111 transport-cc //以上這行說明opus編碼支持使用rtcp來控制擁塞，參考https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=fmtp:111 minptime=10;useinbandfec=1 //對opus編碼可選的補充說明,minptime表明最小打包時長是10ms，useinbandfec=1表明使用opus編碼內置fec特性 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=ssrc:18509423 cname:sTjtznXLCNH7nbRw //cname用來標識一個數據源，ssrc當發生沖突時可能會發生變化，可是cname不會發生變化，也會出現在rtcp包中SDEC中， //用于音視頻同步 a=ssrc:18509423 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C 15598a91-caf9-4fff-a28f-3082310b2b7a //以上這一行定義了ssrc和WebRTC中的MediaStream,AudioTrack之間的關系，msid后面第一個屬性是stream-d,第二個是track-id a=ssrc:18509423 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C a=ssrc:18509423 label:15598a91-caf9-4fff-a28f-3082310b2b7am=video 9 UDP/TLS/RTP/SAVPF 100 101 107 116 117 96 97 99 98 //參考上面m=audio,含義相似c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0a=ice-ufrag:khLS a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17a=setup:actpass a=mid:video a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:4 urn:3gpp:video-orientation a=extmap:5 http://www.ietf.org/id/draft-hol ... de-cc-extensions-01 a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=sendrecva=rtcp-mux a=rtcp-rsize a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir //ccm是codec control using RTCP feedback message簡稱，意思是支持使用rtcp反饋機制來實現編碼控制， //fir是Full Intra Request簡稱，意思是接收方通知發送方發送幀過來 a=rtcp-fb:100 nack //支持丟包重傳，參考rfc4585 a=rtcp-fb:100 nack pli //支持關鍵幀丟包重傳,參考rfc4585 a=rtcp-fb:100 goog-remb //支持使用rtcp包來控制發送方的碼流 a=rtcp-fb:100 transport-cc //參考上面opus a=rtpmap:101 VP9/90000 a=rtcp-fb:101 ccm fir a=rtcp-fb:101 nack a=rtcp-fb:101 nack pli a=rtcp-fb:101 goog-remb a=rtcp-fb:101 transport-cc a=rtpmap:107 H264/90000 a=rtcp-fb:107 ccm fir a=rtcp-fb:107 nack a=rtcp-fb:107 nack pli a=rtcp-fb:107 goog-remb a=rtcp-fb:107 transport-cc a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f //h264編碼可選的附加說明 a=rtpmap:116 red/90000 //fec冗余編碼，通常若是sdp中有這一行的話，rtp頭部負載類型就是116，不然就是各編碼原生負責類型 a=rtpmap:117 ulpfec/90000 //支持ULP FEC，參考rfc5109 a=rtpmap:96 rtx/90000 a=fmtp:96 apt=100 //以上兩行是VP8編碼的重傳包rtp類型 a=rtpmap:97 rtx/90000 a=fmtp:97 apt=101 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=107 a=rtpmap:98 rtx/90000 a=fmtp:98 apt=116 a=ssrc-group:FID 3463951252 1461041037 //在webrtc中，重傳包和正常包ssrc是不一樣的，上一行中前一個是正常rtp包的ssrc,后一個是重傳包的ssrc a=ssrc:3463951252 cname:sTjtznXLCNH7nbRw a=ssrc:3463951252 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C ead4b4e9-b650-4ed5-86f8-6f5f5806346d a=ssrc:3463951252 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C a=ssrc:3463951252 label:ead4b4e9-b650-4ed5-86f8-6f5f5806346d a=ssrc:1461041037 cname:sTjtznXLCNH7nbRw a=ssrc:1461041037 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C ead4b4e9-b650-4ed5-86f8-6f5f5806346d a=ssrc:1461041037 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C a=ssrc:1461041037 label:ead4b4e9-b650-4ed5-86f8-6f5f5806346dm=application 9 DTLS/SCTP 5000c=IN IP4 0.0.0.0a=ice-ufrag:khLS a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17a=setup:actpass a=mid:data a=sctpmap:5000 webrtc-datachannel 1024

總結

以上是生活随笔為你收集整理的WebRTC中的SDP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。