SDP 是什麼？有什麼用？

一、SDP 是什麼

      SDP（Session Description Protocal）說直白點就是用文本描述的通信各端（PC 端、Mac 端、Android 端、iOS 端等）的能力。這裡的能力指的是各端所支援的音頻編解碼器是什麼，這些編解碼器設定的參數是什 麼，使用的傳輸協定是什麼，以及包括的音視訊媒體是什麼等等。 下面讓我們來看一個真實的 SDP 片段：

v=0 o=- 3409821183230872764 2 IN IP4 127.0.0.1
 ... 
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 
...
a=rtpmap:111 opus/48000/2 
a=rtpmap:103 ISAC/16000 
a=rtpmap:104 ISAC/32000 
...
           

    如上面的 SDP 片段所示，該 SDP 中描述了一路音頻流，即m=audio，該音頻支援的 Payload ( 即資料負載 ) 類型包括 111、103、104 等等。 在該 SDP 片段中又進一步對 111、103、104 等 Payload 類型做了更詳細的描述，如 a=rtpmap:111 opus/48000/2 表示 Payload 類型為 111 的資料是 OPUS 編碼的音頻數 據，并且它的采樣率是 48000，使用雙聲道。以此類推，你也就可以知道 a=rtpmap:104 ISAC/32000 的含義是音頻資料使用 ISAC 編碼，采樣頻率是 32000，使用單聲道。 

二、SDP 作用

    前面的章節rtsp實驗我們用到的sdp描述服務端和客服端通信的端口等資訊。這裡先拓展說一些webrtc中用到的sdp。

     webrtc兩個用戶端 / 浏覽器進行 1 對 1 通話時，首先要進行信令互動，而互動的一 個重要資訊就是 SDP 的交換。 交換 SDP 的目的是為了讓對方知道彼此具有哪些能力，然後根據雙方各自的能力進行協 商，協商出大家認可的音視訊編解碼器、編解碼器相關的參數（如音頻通道數，采樣率 等）、傳輸協定等資訊。 舉個例子，A 與 B 進行通訊，它們先各自在 SDP 中記錄自己支援的音頻參數、視訊參數、 傳輸協定等資訊，然後再将自己的 SDP 資訊通過信令伺服器發送給對方。當一方收到對端 傳來的 SDP 資訊後，它會将接收到的 SDP 與自己的 SDP 進行比較，并取出它們之間的交 集，這個交集就是它們協商的結果，也就是它們最終使用的音視訊參數及傳輸協定了。

三、标準 SDP 規範 

      先放個官方檔案位址：https://datatracker.ietf.org/doc/html/rfc4566#page-24

    sdp資訊由多行"="組成，其中是一個字元串，是一個字元串，type表示類型，value的格式視type而定，整個協定區分大小寫，"="兩側不允許有空格！sdp會話描述包含一個會話級描述（session_level_description）和多個媒體級描述（media_level description）組成！會話級描述的作用域是整個會話，其位置從"v="行開始到第一個媒體描述為止；媒體級描述是對單個的媒體流進行描述，如傳輸過程中的視訊流資訊，從m=開始到下一個媒體描述為止，如下圖所示：

會話級描述主要包含以下字段：

v = （ 表示sdp的版本号，不包含次版本号）

o = （所有者/建立者和會話辨別符）

s = （Session Name會話名稱）

i = * （會話資訊）

u = * （URI 描述）

e = * （Email 位址）

p = * （電話号碼）

c = * （連接配接資訊 ― 如果包含在所有媒體中，則不需要該字段）

b = * （帶寬資訊）

時間描述

t = （會話活動時間）

r = * （0或多次重複次數）

媒體級描述主要包含以下字段：

m = （媒體名稱和傳輸位址）

i = * （媒體标題）

c = * （連接配接資訊 — 如果包含在會話層則該字段可選）

b = * （帶寬資訊）

k = * （加密密鑰）

a = * （0 個或多個會話屬性行）

SDP例子：

webrtc的例子(基于标準SDP做了修改擴充)

v=0
//sdp版本号，一直為0,rfc4566規定
o=- 7017624586836067756 2 IN IP4 127.0.0.1
// o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
//username如何沒有使用-代替，7017624586836067756是整個會話的編号，2代表會話版本，如果在會話
//過程中有改變編碼之類的操作，重新生成sdp時,sess-id不變，sess-version加1
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協商過程中需要的認證資訊
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包使用同一個端口來傳輸
//下面幾行都是對m=audio這一行的媒體編碼補充說明，指出了編碼采用的編号，采樣率，聲道等
a=rtpmap:111 opus/48000/2
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-3082310b2b7a
m=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.0
a=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:17
a=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=sendrecv
a=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-6f5f5806346d
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=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:17
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024
           

RTSP推流例子

v=0
o=- 1586545639954157 1586545639954157 IN IP4 192.168.1.63
s=Media Presentation
e=NONE
b=AS:5100
t=0 0
a=control:rtsp://192.168.1.63:554/
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=recvonly
a=x-dimensions:1920,1080
a=control:rtsp://192.168.1.63:554/trackID=1
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=420029; packetization-mode=1; sprop-parameter-sets=Z01AKI2NQDwBE/LgLcBAQFAAAD6AAAw1DoYACYFAABfXgu8uNDAATAoAAL68F3lwoA==,aO44gA==
m=audio 0 RTP/AVP 8
c=IN IP4 0.0.0.0
b=AS:50
a=recvonlya=control:rtsp://192.168.1.63:554/trackID=2
a=rtpmap:8 PCMA/8000
a=Media_header:MEDIAINFO=494D4B48010300000400000111710110401F000000FA000000000000000000000000000000000000;
a=appversion:1.0
v=0
o=34020000001320000010 0 0 IN IP4 192.168.1.202
s=Play
c=IN IP4 192.168.1.202
t=0 0
m=video 5500 RTP/AVP 96 97 98
a=rtpmap:96 PS/90000
a=rtpmap:97 MPEG4/90000
a=rtpmap:98 H264/90000
a=recvonly