SDP（Session Description Protocol）模型介紹

如果有哪里描述有誤，或不準確，歡迎各位網友指正，可以及時討論并修正。

情態動詞術語解釋：

"MUST"，必須、一定要；

"MUST NOT"，禁止；

"REQUIRED"，需要；

"SHALL"、"SHOULD"，應該；

"SHALL NOT"、"SHOULD NOT"，不應該；

"RECOMMENDED"，推薦；

"MAY"，可以

以上情態動詞術語可參考RFC2119^[3]，這些動詞要求我們在產品實現時，需要遵守或靈活變更約束。

術語

媒體流（Media Stream），或稱為媒體類型（Media Type），即我們通常所說的音頻流、視頻流等，所有通信實體要進行媒體交互之前都必須進行媒體注的協商

媒體格式（Media Format），每種媒體流都有不同的編碼格式，像音頻有G711、G712編碼，視頻有H261、H264等，像現在所謂的高清視頻采用是720P、1070P等。

單一會話（Unitcast Session）

多會話（Multicast Sessions）

單一媒體流（Unitcast Streams）

多媒體流（Multicast Streams）

SDP（Session Description Protocol）

SDP（會話描述協議），用于兩個會話實體之間的媒體協商，并達成一致，屬信令語言族，采用文本（字符）描述形式。rfc3264協議^[1]主要概述一個請求/響應模型（offer/answer，以下敘述采用英文），包括請求/響應的實體和不同階段的操作行為，如初始協商過程和重協商過程，并簡單介紹消息中各種參數的含義。具體各個參數的詳細說明見rfc2327協議^[2]。本文主要參照3264協議，大部分為直譯，附加自己經驗和理解。

圖1 SDP模型組網圖

1實體、消息

Offer/Answer模型包括兩個實體，一個是請求主體Offerer，另外一個是響應實體Answerer，兩個實體只是在邏輯上進行區分，在一定條件可以轉換。例如，手機A發起媒體協商請求，那么A就是Offerer，反之如果A為接收請求則為Offerer。

Offerer發給Answerer的請求消息稱為請求offer，內容包括媒體流類型、各個媒體流使用的編碼集，以及將要用于接收媒體流的IP和端口。

Answerer收到offer之后，回復給Offerer的消息稱為響應，內容包括要使用的媒體編碼，是否接收該媒體流以及告訴Offerer其用于接收媒體流的IP和端口。

2 SDP各個參數簡單介紹

下面示例摘自3264協議[1]

v=0                                                                              

o=carol 28908764872 28908764872 IN IP4 100.3.6.6        //會話ID號和版本

s=-                                     //用于傳遞會話主題

t=0 0                                   //會話時間，一般由其它信令消息控制，因此填0

c=IN IP4 192.0.2.4              //描述本端將用于傳輸媒體流的IP

m=audio 0 RTP/AVP 0 1 3     //媒體類型 端口號 本端媒體使用的編碼標識（Payload）集

a=rtpmap:0 PCMU/8000 //rtpmap映射表，各種編碼詳細描述參數，包括使用帶寬（bandwidth）

a=rtpmap:1 1016/8000

a=rtpmap:3 GSM/8000

a=sendonly     //說明本端媒體流的方向，取值包括sendonly/recvonly/sendrecv/inactive

a=ptime:20                           //說明媒體流打包時長

m=video 0 RTP/AVP 31 34

a=rtpmap:31 H261/90000

a=rtpmap:34 H263/90000

3 實體行為、操作過程

3.1 初始協商的Offer請求

實體A <-> 實體B，實體首先發起Offer請求，內容如2節所示，對于作何一個媒體流/媒體通道，這時實體A必須：

a.       如果媒體流方向標為recvonly/sendrecv，即a=recvonly或a=sendrecv，則A必須（MUST）準備好在這個IP和端口上接收實體B發來的媒體流；

b.       如果媒體流方向標為sendonly/inactive，即a=recvonly或a=sendrecv，則A不需要進行準備。

3.2 Answer響應

實體B收到A的請求offer后，根據自身支持的媒體類型和編碼策略，回復響應。

a. 如果實體B回復的響應中的媒體流數量和順序必須（MUST）和請求offer一致，以便實體A進行甄別和決策。即m行的數量和順序必須一致，B不能（MUST NOT）擅自增加或刪除媒體流。如果B不支持某個媒體流，可以在對應的端口置0，但不能不帶這個m行描述。

b. 對于某種媒體，實體B必須（MUST）從請求offer中選出A支持且自己也支持的該媒體的編碼標識集，并且可以（MAY）附帶自己支持的其它類型編碼。

c. 對于響應消息中各個媒體的方向：

如果請求某媒體流的方向為sendonly，那么響應中對應媒體的方向必須為recvonly；

如果請求某媒體流的方向為recvonly，那么響應中對應媒體的方向必須為sendonly；

如果請求某媒體流的方向為sendrecv，那么響應中對應媒體的方向可以為sendrecv/sendonly/recvonly/inactive中的一種；

如果請求某媒體流的方向為inactive，那么響應中對應媒體的方向必須為inactive；

d.       響應answer里提供IP和端口，指示Offerer本端期望用于接收媒體流的IP和端口，一旦響應發出之后，Offerer必須（MUST）準備好在這個IP和端口上接收實體A發來的媒體流。

e.       如果請求offer中帶了ptime（媒體流打包間隔）的a行或帶寬的a行，則響應answer也應該（SHOULD）相應的攜帶。

f.        實體B Offerer應該（SHOULD）使用實體A比較期望的編碼生成媒體流發送。一般來說對于m行，如m=video 0 RTP/AVP 31 34，排充越靠前的編碼表示該實體越希望以這個編碼作為載體，這里示例31(H261)，34（H263）中H261為A更期望使用的編碼類型。同理，當實體A收到響應answer后也是這樣理解的。

3.3 實體收到響應后的處理

當實體A收到B回復的響應后，可以（MAY）開始發送媒體流，如果媒體流方向為sendonly/sendrecv，

a.       必須（MUST）使用answer列舉的媒體類型/編碼生成媒體發送；

b.       應該（SHOULD）使用answer中的ptime和bandwidth來打包發送媒體流；

c.       可以（MAY）立即停止監聽端口，該端口為offer支持answer不支持的媒體所使用的端口。

4 修改媒體流（會話）

修改媒體流的offer-answer操作必須基于之前協商的媒體形式（音頻、視頻等），不能（MUST NOT）對已有媒體流進行刪減。

4.1 刪除媒體流

如果實體認定新的會話不支持之前媒商的某個媒體，新的offer只須對這種媒體所在m行的端口置0，但不能不描述這種媒體，即不帶對應m行。當answerer收到響應之后，處理同初始協商一樣。

4.2 增加媒體流

如果實體打算新增媒體流，在offer里只須加上描述即可或者占用之前端口被置0的媒體流，即用新的媒體描述m行替換舊的。當answerer收到offer請求后，發現有新增媒體描述，或者過于端口被置0的媒體行被新的媒體描述替換，即知道當前為新增媒體流，處理同初始協商。

4.3 修改媒體流

修改媒體注主要是針對初始協商結果，如果有變更即進入修改流程處理，可能的變更包括IP地址、端口，媒體格式（編碼），媒體類型（音、視頻），媒體屬性（ptime，bandwidth，媒體流方向變更等）。

參考文檔

[1] RFC3264，An Offer/Answer Model with the Session Description Protocol (SDP)

[2] RFC2327，SDP: Session Description Protocol

[3] RFC2119，Key words for use in RFCs to Indicate Requirement Levels