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