SDP協議介紹
SDP全稱是Session Description Protocol，翻譯過來就是描述會話的協議。主要用于兩個會話實體之間的媒體協商。
什么叫會話呢，比如一次網絡電話、一次電話會議、一次視頻聊天，這些都可以稱之為一次會話。
那為什么要去發這個描述文本呢，主要是為了解決參與會話的各成員之間能力不對等的問題，如果參加本次通話的成員都支持高質量的通話，但是我們沒有去進行協議，為了兼容性，使用的都是普通質量的通話格式，這樣就很浪費資源了。所以SDP的作用還是很有必要的。
SDP協議結構
SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個字母，<值>是結構化的文本串，其格式依<類型>而定。
SDP的 文本信息包括：
- 會話名稱和意圖
- 會話持續時間
- 構成會話的媒體
- 有關接收媒體的信息
會話名稱和意圖描述
v = （協議版本）
o = （所有者/創建者和會話標識符）
s = （會話名稱）
i = * （會話信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號碼）
c = * （連接信息 ― 如果包含在所有媒體中，則不需要該字段）
b = * （帶寬信息）
時間描述
t = （會話活動時間）
r = * （0或多次重復次數）
媒體描述
m = （媒體名稱和傳輸地址）
i = * （媒體標題）
c = * （連接信息 — 如果包含在會話層則該字段可選）
b = * （帶寬信息）
k = * （加密密鑰）
a = * （0 個或多個會話屬性行）
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
WebRTC中的SDP
SDP協商利用的是里請求和響應這兩個模型（offer、answer）,Offerer發給Answerer的請求消息稱為請求offer，內容包括媒體流類型、各個媒體流使用的編碼集，以及將要用于接收媒體流的IP和端口。
Answerer收到offer之后，回復給Offerer的消息稱為響應，內容包括要使用的媒體編碼，是否接收該媒體流以及告訴Offerer其用于接收媒體流的IP和端口。
Offer/Answer模型包括兩個實體，一個是請求主體Offerer，另外一個是響應實體Answerer，兩個實體只是在邏輯上進行區分，在一定條件可以轉換。
在WebRTC連接流程中，在創建PeerConnectionA后，就會去創建一個offerSDP，并設置為localSDP。通過signaling發送 PeerB。 peerB收到peerA的SDP后，把收到的SDP設置為RemoteSDP。在設置完成后，PeerB再生成AnswerSDP，設置為localSDP，通過signaling通道發送給PeerA，PeerA收到后AnswerSDP后，設置為RemoteSDP，以上流程完成了SDP的交換。
參考文章：
https://blog.csdn.net/onlycoder_net/article/details/76702432
https://blog.piasy.com/2017/08/30/WebRTC-P2P-part1/#sdp
https://tools.ietf.org/id/draft-nandakumar-rtcweb-sdp-01.html
https://blog.csdn.net/dxpqxb/article/details/18706471
https://blog.csdn.net/liwf616/article/details/45719881
