無論你是用微信進行視頻電話還是開Zoom視頻會議，按照OSI網絡七層參考模型，我們進行這些活動之前一般都要先建立一組會話。在建立會話的過程中，我們需要描述下會話的一些信息，描述這種會話能力時用到了SDP協議，也就是會話描述協議Session Description Protocol，協議詳細內容在RFC4566中規定。
這麼說可能不夠直白，大白話解釋就是：由於Web端、IOS、Android、PC、MAC端的差異性導致它們對音視頻的支持能力不同，所以我們進行一些音視頻會話之前，需要交互下彼此的音視頻編解碼能力、網絡帶寬和傳輸協議等信息，這些需要協商的信息需要用SDP來描述。
注意的是SDP雖然具備這些能力參數信息的描述功能，但是SDP並不是傳輸協議，需要用RTSP、SIP、HTTP等協議進行承載傳輸、交換，如果大家協調好了之後，就可以建立會話，完成真實的音視頻碼流傳輸，再完成解碼和播放。
這篇文章主要講下SDP協議格式和規範、具備哪些描述能力、最後再通過在RTSP和基於SIP的國標協議進行實例分析下，當然目前比較火的WebRTC在建立音視頻會話前也是通過這套協議描述會話信息的。SDP應用在任何場景和行業標準中，一般都進行了裁剪和進一步的規範，如果你要了解所有的SDP信息，你可以參考RFC4566文檔，如果需要了解在WebRTC中使用可以參考鏈接：https://www.ietf.org/archive/id/draft-nandakumar-rtcweb-sdp-08.txt
SDP格式和規範
SDP場景：
SDP一般用在媒體會話建立之前，可以適用於實時流媒體、點播、直播等領域，特別在音視頻通話、視頻會議、VoIP、視頻監控等領域應用較多。媒體碼流一般基於RTP傳輸，服務質量用RTCP協議保障。
但是SDP的交互不是所有音視頻會話建立時都是必須的，假如雙方提前約定好這些音視頻會話創建需要的信息就不用這個步驟來交互彼此的SDP信息，比如HTTP-FLV、RTMP-FLV直播和點播方案，因爲一旦採用了這套方案，這些音視頻會話建立需要的信息都是確定的，但是這樣會降低或者說沒有充分發揮端到端的音視頻能力，協商顯得更加靈活點。
SDP作用：
SDP作用包括以下一些方面1)建立會話的詳細信息，包括名稱，網絡，帶寬等信息3)包含在會話中的媒體信息，包括： 媒體類型(video, audio, etc) 傳輸協議(RTP/UDP/IP, H.320, etc) 媒體格式(H.261 video, MPEG video, etc) 多播或遠端（單播）地址和端口4)爲接收媒體而需的信息5)使用的帶寬信息6)可信賴的接洽信息
如果拓展，還可以描述會話的安全方案信息、服務質量信息等，其中WebRTC就在SDP的基礎上進行了繼續拓展，可以參考：
https://www.ietf.org/archive/id/draft-nandakumar-rtcweb-sdp-08.txt。
SDP格式：
標準的SDP規範主要包括SDP描述格式和SDP結構，其中SDP結構裏面最重要的兩項內容是會話描述信息和媒體描述信息。
說了這麼多，先上個SDP的示例，有個SDP的直觀認識：
SDP是由多個<type>=<value>這樣的表達式組成，其中是基於文本描述，這樣做的好處是便於問題排查和調試，同時type是一個字符，value是一個字符串，=兩邊沒有空格。
整個SDP 由這樣一行行的key-value字符串組成，同時整個字符串組成了會話信息描述和多個媒體級別描述。至於會話信息和媒體信息描述的key和value到底怎麼定義需要繼續分析下各個字段，其中有些字段是必須的有些是可選項。
會話描述和媒體描述，一般會話級描述從v=開始一直到第一個媒體描述爲止，媒體描述是從m=開始一直到下一個媒體描述m=的位置之前。也就是說SDP裏面一般先從會話信息v=開始，然後後面跟幾個m=的媒體描述組成。
1. 會話級的作用域是整個會話，其位置從v=開始到第一個媒體描述m=爲止；
2. 媒體級描述 是對單個媒體流即音頻流、視頻流和字幕流等的單個媒體描述，如果有多個流則用多組媒體級描述。其中每個媒體級描述就是從m=開始到下一個媒體描述m=爲止。
SDP結構：
上面瞭解了SDP的基本信息，下面看下各個字段含義，當然字段非常多，只看一些常用和必須的，對於有些場景下的字段你需要參看SDP的RFC4566文檔進一步瞭解，同時瞭解下各個行業的標準對這一塊的規定，後面示例分析會介紹完整的應用字段解釋。
會話描述部分：
1. v=
v就是protocol version，必選字段，表示了SDP的版本號但是不包含子版本號，一般就是v=0。2. o=
o是owner，必選字段，對會話發起者的一個信息描述，其中包含了用戶名、會話ID、網絡地址等信息。格式是：
o=<username> <session id> <version> <network type> <address >
3. s=
s即session name，表示的會話名稱，必選字段。在整個SDP裏面只有一個會話名稱，有且僅有一個這樣的字段。
4. t=
t即time the session is active，必選字段，表示的是該會話的開始到結束時間，如果是持久會話，則時間值填0，這樣的時間是NTP時間，單位是秒，格式是 ：
t=<start time> <stop time>。
媒體描述部分：
這部分字段非常多，也重點介紹幾個，其餘字段用到需要參考RFC文檔和後面的示例分析：1. m=
m就是media name and transport address，可選字段，但是一般音視頻會話至少有音頻流或者視頻流，所以一般也是都會有的，如果多個流則有多個，一般就是從這個m=到下個媒體會話m=結束，格式：
m=<media type> <port> <transport> <fmt list>
<media tyoe>：媒體類型， audio或者video
<port>：媒體端口，要麼是收流端口，要麼是發流端口，這樣我們就知道從哪個端口進行發流和收流。
<transport>：傳輸協議，表示碼流的傳輸協議是什麼，如果UDP則爲RTP/AVP代表碼流用RTP Over UDP，要麼是TCP/RTP/AVP即RTP Over TCP，表示用TCP傳輸RTP碼流。
<fmt list>:媒體格式，這裏表示的負載類型，一般表示的視頻的H.264 H.265等,音頻則是 G7xx、AAC、Opus等類型。
2. a=
a是attribute，可選字段，表示的媒體的屬性，進一步的描述媒體信息，可以有多個屬性，其中比較重要的屬性就是rtpmap和fmtp，格式是：
a=<type>
a=<type>:<value>
rtpmap屬性，表示媒體流傳輸協議的RTP具體內容：
a=rtpmap:<payload type> <encoding name>/<clock rate>[/encoding parameters]
rtpmap:是rtp map即RTP參數映射表
<payload type>：負載類型，對應表示RTP包中的音視頻數據負載類型，比如RTP的數據類型是H.264，那麼這裏就是96。
<encoding name>:編碼器名稱，這裏主要指的RTP承載音視頻編碼數據類型，當然可以是標準數據也可以私有數據，如VP8 VP9 H.264等。
<sample rate>:採樣率，音視頻裏面都有時間戳的概念，所以這裏表示的音視頻的採樣率，對音視頻同步非常重要。比如視頻的90000，音頻的8000、48000等。
<encoding parameters>：編碼參數，可以表示視頻的分辨率，幀率，音頻的單聲道雙聲道等信息。
fmtp屬性，在rtpmap基礎上進一步描述音視頻具體編碼參數信息：
格式：
a=fmtp:<payload type> <format specific parameters>
fmtp，格式參數，即 format parameters；
<payload type>：負載類型，同樣對應 RTP 包中的音視頻數據負載類型；
< format specific parameters>：指具體參數，或者說對音視頻編碼信息的一次處理。該信息從編碼器得到，比如視頻的SPS\PPS等，用於解碼端的播放器初始化。
SDP的字段非常多，在不同場景下約束不同，下面看下在RTSP、國標SIP協議、WebRTC中的具體示例。
示例分析：
RTSP中的SDP：
RTSP即Real Transport Stream Protocol實時流媒體傳輸協議，一般和RTP、RTCP搭配使用，該協議用來進行媒體的控制和會話的建立，比如開始、暫停、倍速控制媒體文件的播放，RTP協議用來進行碼流的傳輸，RTCP保障服務的Qos質量。該協議的應用場景在視頻監控最多，一般的視頻監控產品如攝像機、NVR等都原生支持RTSP協議，同時該協議在一些智能家居方面如智能音箱也有所使用，比如AWS Alexa在進行視頻投屏時就支持該協議。
這裏只探討下RTSP協議的創建媒體會話時，用SDP交互會話信息時的情況，順便給大家一個測試地址，然後用VLC播放視頻抓包就可以學習RTSP、RTP協議，RTSP協議默認端口554，測試地址：
rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov
這是抓包在DESCRIBE信令的SDP信息：
會話描述協議：
v=0
解釋：版本號，一般默認是0；
o=- 1422341101 1422341101 IN IP4 3.84.6.190
解釋：會話發起者信息會話名稱 網絡類型 IP地址等信息；
s=BigBuckBunny_115k.mov
解釋：會話名稱
c=IN IP4 3.84.6.190
解釋：
格式：c=<networktype> <address type> <connection address>
鏈接信息，包含網絡類型和IP地址等信息；
a=range:npt=0- 596.48
解釋：用來表示媒體流的長度爲596.48秒
音頻媒體描述信息：
m=audio 0 RTP/AVP 96
解釋：表示該路會話的的audio是通過RTP來格式傳送的，其payload值爲96但是傳送的端口還沒有定。
a=rtpmap:96 mpeg4-generic/12000/2
解釋：rtpmap的信息，表示音頻爲AAC的其sample採樣率爲12000雙通道音頻，其中mpeg4-generic代表了AAC的互聯網媒體類型。
a=fmtp:96 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1490
解釋：這裏面是AAC的詳細編碼和封裝信息：
profile-level-id=1;mode=AAC-hbr;
profile中指定1表示低複雜度類型，mode=AAC-hbr代表編碼模式；
sizelength=13;indexlength=3;indexdeltalength=3
涉及到AAC的AU Header,如果一個RTP包則只包含一個AAC包，則沒有這三個字段,有則說明是含有AU Header字段，具體參考RTP對音頻AAC的封裝。
AU-size由sizeLength決定表示本段音頻數據佔用的字節數
AU-Index由indexLength決定表示本段的序號, 通常0開始
AU-Index-delta由indexdeltaLength 決定表示本段序號與上一段序號的差值
;config=1490十六進制：1490
二進制：0001 0100 1001 0000
十進制：2、9、2
分別代表aac的profile是2、9代表採樣率是12000，通道個數是2立體聲，具體參考AAC的ADTS頭定義。
a=control:trackID=1
解釋：通過媒體流1來發送音頻；
視頻媒體描述信息：
m=video 0 RTP/AVP 97
解釋：表示該路會話的的audio是通過RTP來格式傳送的，其payload值爲97但是傳送的端口還沒有定。
a=rtpmap:97 H264/90000
解釋：表示該路會話的的Video是通過RTP來格式傳送的，其payload值爲97,編碼器是H264，採樣率90000。
a=fmtp:97 packetization-mode=1;profile-level-id=42C01E;sprop-parameter-sets=Z0LAHtkDxWhAAAADAEAAAAwDxYuS,aMuMsg==
解釋：這裏麪包含一些RTP封包模式，視頻質量等級，視頻的SPS、PPS等信息。
表示該路會話的的audio是通過RTP來格式傳送的，其payload值爲97。
當 packetization-mode 的值爲 1 時RTP打包H.264的NALU單元必須使用非交錯(non-interleaved)封包模式.
當 profile-level-id的值爲 42C01E 時， 第一個字節0x42表示 H.264 的 profile_idc類型Baseline profile , 第二字節代表profile_iop,各個Bit代表視頻序列遵循的條款，第三個字節表示 H.264 的 Profile 級別，0x1E即30代表了levle_idc爲3，即30/3，具體信息參考H.264的SPS PPS即可。
sprop-parameter-sets是SPS和PPS的的Base64之後的字符串，中間以逗號分割，後面會專門寫篇文章介紹下，主要描述了編碼器的參數信息，對初始化播放器有幫助；
a=cliprect:0,0,160,240
解釋：一些offer和answer的加密屬性；
a=framesize:97 240-160
解釋：RTP負載類型97，幀寬和高分別爲240*160
a=framerate:24.0
解釋：最大幀率速度爲24幀/s
a=control:trackID=2
解釋：通過媒體流1來發送視頻；
基於SIP協議國標GB28181中的SDP：
國標協議也是基於SIP協議開發的，所以這裏的SDP協議是在給前端設備下發INVITE信令的回覆中帶上來的，這裏的SDP主要是爲了不同的廠家，使用 GB 對接的時候，上級要能正常看下級推送過來的攝像頭的視頻，回放，以及球機控制等等的功能。
現在看一個抓包文件中INVITE回覆攜帶的SDP描述信息：
會話信息描述國標的規定：
1. v=0
v字段給出了 SDP 的版本，當前規範版本是 0，這個版本沒有小號版本。
2. o=
源（客戶端的SIP編號）<用戶名><會話 ID><會話版本><網絡類型><地址類型><單播地址>
如 32028100001320000001 0 0 IN IPV4 192.168.0.101
各個字段解釋：
<用戶名> 用戶登錄的源主機名字，如果不能提供則用"-"表示，用戶名不能包含空格。這
裏一般是攝像機的國標 ID
<會話 ID> 是一個字符串，<用戶名><會話 ID><網絡類型><單播地址>這個組合形成該會話
的唯一標識。用 0 標識的居多
<會話版本> 會話版本號，推薦使用 NTP 時間戳。用 0 標識的居多
<網絡類型> 目前是 IN 代表 internet，未來可能會有其他值。
<地址類型> 目前只有 IPV4 和 IPV6 兩種，目前主要是 IPV4,。
<單播地址> 創建會話的主機地址。一般爲媒體服務器的地址。
注意：有時候處於某種原因，用戶名和 IP 不想明確表示，只要保證 o 字段全球唯一，用戶名和 IP 可以隨機。
3. s=
請求媒體流的操作類型，play 代表實況；playback 代表回放。download 代表下載，Talk
代表語音。
4. u=
行應填寫視音頻文件的 URI。 該 URI 取值有兩種方式: 簡捷方式和普通方式。
簡捷方式常用 攝像機 ID：其他參數格式。如 32028100001320000001:10111
普通方式採用 http://存儲設備 ID[/文件夾]* /文件名, [/文件夾]* 爲 0-N 級文件夾。
簡捷方式中冒號後面文件類型，如果s=playback時，則0有時代表的全天錄像，1代表事件錄像等，一般默認爲3.有些海康平臺這裏進行了區分，如果值填錯會導致回放錄像失敗。
5. c=
<網絡類型><地址裂類型><鏈接地址>
如 IN IPV4 192.168.0.100
6.t=
t字段在回放和下載時，t 行值爲開始時間和結束時間。使用的時間爲 UNIX 時間戳，需要
用 UNIX 時間戳轉爲北京時間。如果是直播則是0.
媒體信息描述國標的規定：
1. m=
m 字段描述媒體類型，媒體端口，媒體協議，以及媒體負載方式
例：
m=video 6000 RTP/AVP 96------媒體類型視頻或視音頻，傳輸端口 6000，RTP over UDP，負載
類型 96
m=video 6000 TCP/RTP/AVP 96------媒體類型視頻或視音頻，傳輸端口 6000，RTP over TCP，負
載類型 96
m=audio 6000 RTP/AVP 8------媒體類型爲音頻，傳輸端口 6000，RTP over UDP，負載類型 8
2. a=
a=rtpmap: <payload type> <encoding name>/<clockrate> [/<encoding parameters> ] 中的<encoding name>這裏參考RTSP分析即可，要說的一點是這裏可以攜帶設備廠商的編碼類型，如果發現這裏不是標準的，則解碼和播放一般都存在問題；
a=downloadspeed: 下載倍速(取值爲整型) ；
a=filesize: 文件大小(單位:Byte) , a 字段可攜帶文件大小參數, 用於下載時的進度計算。
下面可以參考IETF RFC4571的規定，解析setup connection recvonly等屬性：
a=setup:TCP 連接方式(表示本 SDP 發送者在 RTP over TCP 連接建立時是主動還是被動發
起 TCP 連接, “active”爲主動, “passive”爲被動)
a=connection:new (表示採用 RTP over TCP 傳輸時新建或重用原來的 TCP 連接, 可固定採
用新建 TCP 連接的方式)
a=recvonly 只接受（收流端）只用於媒體，不用於控制協議
a=sendonly 只發送（發流端）只用於媒體，不用於控制協議
y 字段：由 10 位十進制整數組成的字符串，表示 SSRC 值
第一位爲 0 代表實況，爲 1 則代表回放， 第二位至第六位由監控域 ID 的第 4 位到第 8 位組成,最後 4位爲不重複的 4 個整數 ；
有了以上基礎分析國標SIP中的SDP信息就非常簡單了，不再贅述。
WebRTC中的SDP：
WebRTC中的SDP信息比較關鍵，是分析代碼流程和驅動整個業務運轉起來的關鍵，同時WebRTC規範也對SDP的RFC4566規範進行了進一步的規範，也已經成爲SDP草案，具體參考：https://www.ietf.org/archive/id/draft-nandakumar-rtcweb-sdp-08.txt
其中SDP包含了下面幾個板塊的內容，比RTSP和SIP中的更豐富更強大：
其中會話描述、網絡描述、媒體流描述和SDP的RFC4566規範是一致的，同時增加了安全描述和服務質量QOS描述，我們進行了P2P抓包：
WebRTC中的SDP 是由一個會話層和多個媒體層組成的， 而對於每個媒體層，WebRTC 又將其細劃爲四部分，即媒體流、網絡描述、安全描述和服務質量描述。
其中，安全描述起到兩方面的作用，一方面是進行網絡連通性檢測時，對用戶身份進行認證；另一方面是收發數據時，對用戶身份的認證，以免受到對方的攻擊；
服務質量描述指明啓動哪些功能以保證音視頻的質量，如啓動帶寬評估，當用戶發送數據量太大超過評估的帶寬時，要及時減少數據包的發送；啓動防擁塞功能，當預測到要發生擁塞時，通過降低流量的方式防止擁塞的發生等等，這些都屬於服務質量描述的範疇。
總結起來就是，SDP 是由一個會話層與多個媒體層組成，每個媒體層又分爲媒體流描述、網絡描述、安全描述和服務質量描述，而每種描述下面又需要你參考草案來解析和理解。
總結：
這篇文章主要介紹了下SDP協議的內容、格式和規範，以及通過RTSP、SIP、WebRTC中三個例子分析了下SDP中各個字段和應用。平時學習時有這個整體框架就行，一些文中沒出現的字段需要你查標準的RFC文檔進行學習和理解。
同時在GB28181協議中，由於各個廠家對有些字段理解不規範，導致有歧義經常會出現連接攝像頭失敗，拉流失敗等問題，需要在實踐中解決和兼容。