?問題背景：

無論你是用微信進行視頻電話還是開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>：指具體參數，或者說對音視頻編碼信息的一次處理。該信息從編碼器得到，比如視頻的SPSPPS等，用于解碼端的播放器初始化。

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://http://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協議中，由于各個廠家對有些字段理解不規范，導致有歧義經常會出現連接攝像頭失敗，拉流失敗等問題，需要在實踐中解決和兼容。

---

往期文章回顧:

周末活動回顧：視頻質量主觀評價、實時RTC和AV1

視頻監控攝像頭的互聯網化實踐思路

在HTML5上開發音視頻應用的五種思路

音視頻封裝：MP4結構概述和分析工具

音視頻解封裝：MP4核心Box詳解及H264&AAC打包方案

音視頻基礎知識-時間戳的理解

音視頻封裝格式：AAC音頻基礎和ADTS打包方案詳解

從人類的第一次直播聊聊視頻監控行業

音視頻壓縮：H264碼流層次結構和NALU詳解

音視頻傳輸：RTP協議詳解和H.264打包方案

音視頻封裝：FLV格式詳解和打包H264、AAC方案（下）

音視頻封裝：FLV格式詳解和打包H264、AAC方案（上）

音視頻常見問題分析和解決：延時和抖動

---

今天就說這么多，祝您工作順利！

如果有疑問，你可以在公眾號后臺發消息咨詢我。

---

個人轉載內容至朋友圈和群聊天，無需特別申請版權許可。

引用轉載該訂閱號文章，注明文章來源即可。

記得右下角點“在看”，還可以關注該訂閱號，防止遺漏推送哦

總結

以上是生活随笔為你收集整理的rtsp 分辨率信息_SDP在RTSP、国标GB28181、WebRTC中的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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