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
