SDP（Session Description Protocol）模型介紹
如果有哪里描述有誤，或不準確，歡迎各位網(wǎng)友指正，可以及時討論并修正。
情態(tài)動詞術(shù)語解釋：
"MUST"，必須、一定要；
"MUST NOT"，禁止；
"REQUIRED"，需要；
"SHALL"、"SHOULD"，應(yīng)該；
"SHALL NOT"、"SHOULD NOT"，不應(yīng)該；
"RECOMMENDED"，推薦；
"MAY"，可以
以上情態(tài)動詞術(shù)語可參考RFC2119[3]，這些動詞要求我們在產(chǎn)品實現(xiàn)時，需要遵守或靈活變更約束。
術(shù)語
媒體流（Media Stream），或稱為媒體類型（Media Type），即我們通常所說的音頻流、視頻流等，所有通信實體要進行媒體交互之前都必須進行媒體注的協(xié)商
媒體格式（Media Format），每種媒體流都有不同的編碼格式，像音頻有G711、G712編碼，視頻有H261、H264等，像現(xiàn)在所謂的高清視頻采用是720P、1070P等。
單一會話（Unitcast Session）
多會話（Multicast Sessions）
單一媒體流（Unitcast Streams）
多媒體流（Multicast Streams）
SDP（Session Description Protocol）
SDP（會話描述協(xié)議），用于兩個會話實體之間的媒體協(xié)商，并達成一致，屬信令語言族，采用文本（字符）描述形式。rfc3264協(xié)議[1]主要概述一個請求/響應(yīng)模型（offer/answer，以下敘述采用英文），包括請求/響應(yīng)的實體和不同階段的操作行為，如初始協(xié)商過程和重協(xié)商過程，并簡單介紹消息中各種參數(shù)的含義。具體各個參數(shù)的詳細說明見rfc2327協(xié)議[2]。本文主要參照3264協(xié)議，大部分為直譯，附加自己經(jīng)驗和理解。
圖1 SDP模型組網(wǎng)圖
1實體、消息
Offer/Answer模型包括兩個實體，一個是請求主體Offerer，另外一個是響應(yīng)實體Answerer，兩個實體只是在邏輯上進行區(qū)分，在一定條件可以轉(zhuǎn)換。例如，手機A發(fā)起媒體協(xié)商請求，那么A就是Offerer，反之如果A為接收請求則為Offerer。
Offerer發(fā)給Answerer的請求消息稱為請求offer，內(nèi)容包括媒體流類型、各個媒體流使用的編碼集，以及將要用于接收媒體流的IP和端口。
Answerer收到offer之后，回復(fù)給Offerer的消息稱為響應(yīng)，內(nèi)容包括要使用的媒體編碼，是否接收該媒體流以及告訴Offerer其用于接收媒體流的IP和端口。
2 SDP各個參數(shù)簡單介紹
下面示例摘自3264協(xié)議[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映射表，各種編碼詳細描述參數(shù)，包括使用帶寬（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 初始協(xié)商的Offer請求
實體A <-> 實體B，實體首先發(fā)起Offer請求，內(nèi)容如2節(jié)所示，對于作何一個媒體流/媒體通道，這時實體A必須：
a. 如果媒體流方向標為recvonly/sendrecv，即a=recvonly或a=sendrecv，則A必須（MUST）準備好在這個IP和端口上接收實體B發(fā)來的媒體流；
b. 如果媒體流方向標為sendonly/inactive，即a=recvonly或a=sendrecv，則A不需要進行準備。
3.2 Answer響應(yīng)
實體B收到A的請求offer后，根據(jù)自身支持的媒體類型和編碼策略，回復(fù)響應(yīng)。
a. 如果實體B回復(fù)的響應(yīng)中的媒體流數(shù)量和順序必須（MUST）和請求offer一致，以便實體A進行甄別和決策。即m行的數(shù)量和順序必須一致，B不能（MUST NOT）擅自增加或刪除媒體流。如果B不支持某個媒體流，可以在對應(yīng)的端口置0，但不能不帶這個m行描述。
b. 對于某種媒體，實體B必須（MUST）從請求offer中選出A支持且自己也支持的該媒體的編碼標識集，并且可以（MAY）附帶自己支持的其它類型編碼。
c. 對于響應(yīng)消息中各個媒體的方向：
如果請求某媒體流的方向為sendonly，那么響應(yīng)中對應(yīng)媒體的方向必須為recvonly；
如果請求某媒體流的方向為recvonly，那么響應(yīng)中對應(yīng)媒體的方向必須為sendonly；
如果請求某媒體流的方向為sendrecv，那么響應(yīng)中對應(yīng)媒體的方向可以為sendrecv/sendonly/recvonly/inactive中的一種；
如果請求某媒體流的方向為inactive，那么響應(yīng)中對應(yīng)媒體的方向必須為inactive；
d. 響應(yīng)answer里提供IP和端口，指示Offerer本端期望用于接收媒體流的IP和端口，一旦響應(yīng)發(fā)出之后，Offerer必須（MUST）準備好在這個IP和端口上接收實體A發(fā)來的媒體流。
e. 如果請求offer中帶了ptime（媒體流打包間隔）的a行或帶寬的a行，則響應(yīng)answer也應(yīng)該（SHOULD）相應(yīng)的攜帶。
f. 實體B Offerer應(yīng)該（SHOULD）使用實體A比較期望的編碼生成媒體流發(fā)送。一般來說對于m行，如m=video 0 RTP/AVP 31 34，排充越靠前的編碼表示該實體越希望以這個編碼作為載體，這里示例31(H261)，34（H263）中H261為A更期望使用的編碼類型。同理，當(dāng)實體A收到響應(yīng)answer后也是這樣理解的。
3.3 實體收到響應(yīng)后的處理
當(dāng)實體A收到B回復(fù)的響應(yīng)后，可以（MAY）開始發(fā)送媒體流，如果媒體流方向為sendonly/sendrecv，
a. 必須（MUST）使用answer列舉的媒體類型/編碼生成媒體發(fā)送；
b. 應(yīng)該（SHOULD）使用answer中的ptime和bandwidth來打包發(fā)送媒體流；
c. 可以（MAY）立即停止監(jiān)聽端口，該端口為offer支持answer不支持的媒體所使用的端口。
4 修改媒體流（會話）
修改媒體流的offer-answer操作必須基于之前協(xié)商的媒體形式（音頻、視頻等），不能（MUST NOT）對已有媒體流進行刪減。
4.1 刪除媒體流
如果實體認定新的會話不支持之前媒商的某個媒體，新的offer只須對這種媒體所在m行的端口置0，但不能不描述這種媒體，即不帶對應(yīng)m行。當(dāng)answerer收到響應(yīng)之后，處理同初始協(xié)商一樣。
4.2 增加媒體流
如果實體打算新增媒體流，在offer里只須加上描述即可或者占用之前端口被置0的媒體流，即用新的媒體描述m行替換舊的。當(dāng)answerer收到offer請求后，發(fā)現(xiàn)有新增媒體描述，或者過于端口被置0的媒體行被新的媒體描述替換，即知道當(dāng)前為新增媒體流，處理同初始協(xié)商。
4.3 修改媒體流
修改媒體注主要是針對初始協(xié)商結(jié)果，如果有變更即進入修改流程處理，可能的變更包括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