課程地址：零聲學院 WebRTC入門與提高 https://ke.qq.com/course/435382?tuin=137bb271
技術(shù)支持QQ群：782508536
簡介
SDP 完全是一種會話描述格式 ― 它不屬于傳輸協(xié)議 ― 它只使用不同的適當?shù)膫鬏攨f(xié)議窗慎，包括會話通知協(xié)議（SAP）纽什、會話初始協(xié)議（SIP）逻族、實時流協(xié)議（RTSP）、MIME 擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTP）础钠。SDP協(xié)議是也是基于文本的協(xié)議排监，這樣就能保證協(xié)議的可擴展性比較強仇奶，這樣就使其具有廣泛的應用范圍捻艳。SDP 不支持會話內(nèi)容或媒體編碼的協(xié)商驾窟，所以在流媒體中只用來描述媒體信息。媒體協(xié)商這一塊要用RTSP來實現(xiàn)．
當發(fā)起多媒體電話會議认轨，IP語音呼叫時绅络，流媒體視頻或其他會話，需要傳達媒體細節(jié)嘁字，傳輸?shù)刂泛推渌麜捗柙獢?shù)據(jù)給參與者恩急。SDP 為此類信息提供了標準。SDP純粹是會話描述的格式,它不包含傳輸協(xié)議纪蜒。
WebRTC 會話就是由 SDP 描述的衷恭。對于 WebRTC 來說，最重要的是 SDP 中的媒體和傳輸信息纯续。
媒體信息包括：
媒體類型（視頻匾荆，音頻）
傳輸協(xié)議（RTP/UDP/IP，H.320等）
媒體格式（H.261視頻杆烁，MPEG視頻等）
傳輸信息包括：
媒體的遠程地址
媒體的遠程傳輸端口
該地址和端口取決于媒體和傳輸協(xié)議定義牙丽。但需要注意的是，因為存在網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）和防火墻兔魂，所以傳輸過程比較復雜烤芦，在 SDP 中沒有定義相關(guān)的實現(xiàn)。WebRTC 中使用 ICE 協(xié)議來解決 NAT 的問題析校。
SDP 格式
SDP會話描述是由多行文本組成表格构罗。由會話級部分（session-level）和多個媒體級（media-level）部分組成。會話級部分以”v =”行開始智玻，到第一個媒體級部分結(jié)束遂唧。每個媒體級部分以”m =”行開始，持續(xù)到下一個媒體級吊奢。
下面是所有的字段描述盖彭，可選項目標有”*”。
會話描述
v =（協(xié)議版本）
o =（發(fā)起者和會話標識符）
s =（會話名稱）
i = *（會話信息）
u = *（描述的URI）
e = *（電子郵件地址）
p = *（電話號碼）
c = *（連接信息 - 如果包含在內(nèi)页滚，則不需要所有媒體）
b = *（零個或多個帶寬信息行）
一個或多個時間描述（"t ="和"r ="行;見下文）
z = *（時區(qū)調(diào)整）
k = *（加密密鑰）
a = *（零個或多個會話屬性行）零個或多個媒體描述
時間描述
t =（會話活動時間）
r = *（零個或多個重復次數(shù)）
媒體描述
m =（媒體名稱和傳輸?shù)刂罚?i = *（媒體標題）
c = *（連接信息 - 如果包含在內(nèi)召边，則為可選項會話級別）
b = *（零個或多個帶寬信息行）
k = *（加密密鑰）
a = *（零個或多個媒體屬性行）
下面是一個基本的 SDP 描述：
v=0
o=- 3925575362227037542 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 735174861
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:KZ8M
a=ice-pwd:NZ1R3TFbpF9ZqEyg5PNSoM85
a=fingerprint:sha-256 7B:0B:B7:6C:C2:82:77:D2:70:18:3F:DD:18:98:AB:22:07:0E:5D:5B:6D:30:C0:05:42:50:C0:D7:53:AF:3E:9F
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
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:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:889008008 cname:JQsS3I1VR6oT0wUw
a=ssrc:889008008 msid:735174861 6446c8d1-1db2-4024-b0bd-1e03304810fe
a=ssrc:889008008 mslabel:735174861
a=ssrc:889008008 label:6446c8d1-1db2-4024-b0bd-1e03304810fe
m=video 9 UDP/TLS/RTP/SAVPF 98 96 100 127 99 97 101
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:KZ8M
a=ice-pwd:NZ1R3TFbpF9ZqEyg5PNSoM85
a=fingerprint:sha-256 7B:0B:B7:6C:C2:82:77:D2:70:18:3F:DD:18:98:AB:22:07:0E:5D:5B:6D:30:C0:05:42:50:C0:D7:53:AF:3E:9F
a=setup:active
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-holmer-rmcat-transport-wide-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:98 H264/90000
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtpmap:100 red/90000
a=rtpmap:127 ulpfec/90000
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=ssrc-group:FID 687692313 4175760292
a=ssrc:687692313 cname:JQsS3I1VR6oT0wUw
a=ssrc:687692313 msid:735174861 54bc6a42-f281-4d75-ac41-ab709717abdb
a=ssrc:687692313 mslabel:735174861
a=ssrc:687692313 label:54bc6a42-f281-4d75-ac41-ab709717abdb
a=ssrc:4175760292 cname:JQsS3I1VR6oT0wUw
a=ssrc:4175760292 msid:735174861 54bc6a42-f281-4d75-ac41-ab709717abdb
a=ssrc:4175760292 mslabel:735174861
a=ssrc:4175760292 label:54bc6a42-f281-4d75-ac41-ab709717abdb
"
s=-
會話名，沒有的話使用-代替
a=group
需要共用一個傳輸通道傳輸?shù)拿襟w裹驰，如果沒有這一行隧熙，音視頻，數(shù)據(jù)就會分別單獨用一個udp端口來發(fā)送
在同一個RTP會話中多路復用幾個媒體流,也就是在后面以”m =”開始的媒體段
a=msid-semantic
WMS是WebRTC Media Stream簡稱幻林，這一行定義了本客戶端支持同時傳輸多個流贞盯，一個流可以包括多個track音念。
在PeerConnection生命周期內(nèi)為 WebRTC Media Stream (WMS) 定義一個唯一的標識符，用于確定其他獨立的RTP媒體流（下面以”m = “開始的媒體段）屬于該 WMS躏敢。
接下來是三個以 “m = “開始的媒體段闷愤，分別是audio、video父丰、application肝谭。
m =
后面跟著四個參數(shù)
是媒體類型，包括audio, video, text, application, message
是發(fā)送媒體流的傳輸端口
是傳輸協(xié)議
是媒體格式說明蛾扇，有效負載類型
有效負載類型可以看 這篇文檔攘烛。其中0-95是靜態(tài)負載類型，96-127是動態(tài)負載類型镀首，需要使用”a = rtpmap：”屬性指定格式參數(shù)坟漱。
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
m=audio說明本會話包含音頻，9代表音頻使用端口9來傳輸更哄，但是在webrtc中一現(xiàn)在一般不使用芋齿，如果設(shè)置為0，代表不傳輸音頻,UDP/TLS/RTP/SAVPF是表示用戶來傳輸音頻支持的協(xié)議成翩，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
c 字段中包含了連接數(shù)據(jù)栅炒，但這一個地址不會被實際使用，只有 ICE 候選項中的 IP 地址和端口才會用于建立對話术羔。
a=rtcp:9 IN IP4 0.0.0.0
用來傳輸rtcp地地址和端口赢赊，webrtc中不使用
a=ice-ufrag
a=ice-pwd
指定了用于ICE的用戶名片段和密碼，不同的媒體段會使用不同的用戶名和密碼级历。
a=fingerprint
指紋是用于建立DTLS連接的自簽名證書的SHA-256散列释移，這行是dtls協(xié)商過程中需要的認證信息
a=setup:active
以上這行代表本客戶端在dtls協(xié)商過程中，可以做客戶端也可以做服務(wù)端寥殖，參考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
參數(shù)為 <payload type> <encoding name> / <clock rate> [/ <encoding parameters>]
對于 a=rtpmap:111 opus/48000/2 扛禽，就是對應”m =”中的有效負載111锋边，使用Opus編解碼器，采樣頻率48kHz编曼，立體聲。
一般每個媒體段會有多條”a=rtpmap”字段剩辟，位于前面的編解碼器具有較高的優(yōu)先級掐场。
a=fmtp:111 minptime=10;useinbandfec=1
這里講一下a=fmtp:參數(shù)設(shè)置往扔，這里講音頻的
將有效負載111，即 Opus 數(shù)據(jù)包的最短分時時間設(shè)置為10ms熊户，且使用in-band FEC（前向糾錯編碼）
a=rtcp-fb:111 transport-cc
以上這行說明opus編碼支持使用rtcp來控制擁塞萍膛，參考https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=rtcp-fb
反饋消息，接收方向發(fā)送方發(fā)送的反饋消息
a=ssrc
同步源標識符嚷堡，用于在使用多個源時表示不同源的屬性
a=extmap
RTP 擴展項蝗罗，接收者可以自己解碼獲取里面的數(shù)據(jù)
a=rtcp-mux
支持對RTP的同一端口多路復用RTCP
b=
該屬性在上面沒有列出，可以自己添加
格式為<bwtype>:<bandwidth>
可以為CT或AS蝌戒，CT是所有媒體的總帶寬上限串塑，AS是指定單個媒體的帶寬
a=ssrc:18509423 cname:sTjtznXLCNH7nbRw
cname用來標識一個數(shù)據(jù)源，ssrc當發(fā)生沖突時可能會發(fā)生變化北苟，但是cname不會發(fā)生變化桩匪，也會出現(xiàn)在rtcp包中SDEC中，用于音視頻同步
a=ssrc:18509423 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C 15598a91-caf9-4fff-a28f-3082310b2b7a
以上這一行定義了ssrc和WebRTC中的MediaStream,AudioTrack之間的關(guān)系友鼻，msid后面第一個屬性是stream-d,第二個是track-id
m=video 9 UDP/TLS/RTP/SAVPF 98 96 100 127 99 97 101
是對視頻的編碼設(shè)置傻昙，在這里，你可以指定是使用H264編碼還是使用VP8編碼彩扔。如96代表VP8編碼妆档，98代表H264編碼，如果你要指定編碼方式為VP8就將96放在前面虫碉，指定H264贾惦，就將98放在前面
a=rtpmap:98 H264/90000
每個codec都有類似的描述都有以下類似的描述
a=rtcp-fb:98 ccm fir
ccm是codec control using RTCP feedback message簡稱，意思是支持使用rtcp反饋機制來實現(xiàn)編碼控制蔗衡，fir是Full Intra Request
簡稱纤虽，意思是接收方通知發(fā)送方發(fā)送幅完全幀過來
a=rtcp-fb:98 nack
支持丟包重傳，參考rfc4585
a=rtcp-fb:98 nack pli
支持關(guān)鍵幀丟包重傳,參考rfc4585
a=rtcp-fb:98 goog-remb
支持使用rtcp包來控制發(fā)送方的碼流
a=rtcp-fb:98 transport-cc
參考上面opus
注意
- 由于H264的rtp中不能區(qū)分視頻流中是否每一幀的圖像都連續(xù),對于丟幀的情況無法處理,所以fec+nack會導致fec包丟失后,nack去申請重傳fec的包.造成帶寬的浪費绞惦。
- WebRTC對FEC的冗余度計算是動態(tài)的, 會根據(jù)丟包情況和網(wǎng)絡(luò)帶寬估計(BWE)的結(jié)果動態(tài)調(diào)整冗余度,
內(nèi)部會維護一個靜態(tài)的冗余度表. 冗余度范圍: 0-255.(255相當于100%冗余度) - ULPFEC: Uneven Level Protection FEC.
將需要保護的媒體流按照重要性分成若干區(qū)域（section）逼纸，
不同的區(qū)域使用不同的保護級別（levels），每個ulpfec可以攜帶多個級別的保護區(qū)域济蝉。
