如果有哪里描述有誤，或不準(zhǔn)確，歡迎各位網(wǎng)友指正，可以及時(shí)討論并修正。

"MUST"，必須、一定要；

"MUST NOT"，禁止；

"REQUIRED"，需要；

"SHALL"、"SHOULD"，應(yīng)該；

"SHALL NOT"、"SHOULD NOT"，不應(yīng)該；

"RECOMMENDED"，推薦；

"MAY"，可以

以上情態(tài)動(dòng)詞術(shù)語(yǔ)可參考RFC2119[3]，這些動(dòng)詞要求我們?cè)诋a(chǎn)品實(shí)現(xiàn)時(shí)，需要遵守或靈活變更約束。

媒體流（Media Stream），或稱為媒體類型（Media Type），即我們通常所說(shuō)的音頻流、視頻流等，所有通信實(shí)體要進(jìn)行媒體交互之前都必須進(jìn)行媒體注的協(xié)商

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

單一會(huì)話（Unitcast Session）

多會(huì)話（Multicast Sessions）

單一媒體流（Unitcast Streams）

多媒體流（Multicast Streams）

SDP（會(huì)話描述協(xié)議），用于兩個(gè)會(huì)話實(shí)體之間的媒體協(xié)商，并達(dá)成一致，屬信令語(yǔ)言族，采用文本（字符）描述形式。rfc3264協(xié)議[1]主要概述一個(gè)請(qǐng)求/響應(yīng)模型（offer/answer，以下敘述采用英文），包括請(qǐng)求/響應(yīng)的實(shí)體和不同階段的操作行為，如初始協(xié)商過(guò)程和重協(xié)商過(guò)程，并簡(jiǎn)單介紹消息中各種參數(shù)的含義。具體各個(gè)參數(shù)的詳細(xì)說(shuō)明見(jiàn)rfc2327協(xié)議[2]。本文主要參照3264協(xié)議，大部分為直譯，附加自己經(jīng)驗(yàn)和理解。

圖1 SDP模型組網(wǎng)圖

Offer/Answer模型包括兩個(gè)實(shí)體，一個(gè)是請(qǐng)求主體Offerer，另外一個(gè)是響應(yīng)實(shí)體Answerer，兩個(gè)實(shí)體只是在邏輯上進(jìn)行區(qū)分，在一定條件可以轉(zhuǎn)換。例如，手機(jī)A發(fā)起媒體協(xié)商請(qǐng)求，那么A就是Offerer，反之如果A為接收請(qǐng)求則為Offerer。

Offerer發(fā)給Answerer的請(qǐng)求消息稱為請(qǐng)求offer，內(nèi)容包括媒體流類型、各個(gè)媒體流使用的編碼集，以及將要用于接收媒體流的IP和端口。

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

下面示例摘自3264協(xié)議[1]

v=0                                                                              

o=carol 28908764872 28908764872 IN IP4 100.3.6.6        //會(huì)話ID號(hào)和版本

s=-                                     //用于傳遞會(huì)話主題

t=0 0                                   //會(huì)話時(shí)間，一般由其它信令消息控制，因此填0

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

m=audio 0 RTP/AVP 0 1 3     //媒體類型 端口號(hào) 本端媒體使用的編碼標(biāo)識(shí)（Payload）集

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

a=rtpmap:1 1016/8000

a=rtpmap:3 GSM/8000

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

a=ptime:20                           //說(shuō)明媒體流打包時(shí)長(zhǎng)

m=video 0 RTP/AVP 31 34

a=rtpmap:31 H261/90000

a=rtpmap:34 H263/90000

實(shí)體A <-> 實(shí)體B，實(shí)體首先發(fā)起Offer請(qǐng)求，內(nèi)容如2節(jié)所示，對(duì)于作何一個(gè)媒體流/媒體通道，這時(shí)實(shí)體A必須：

$1__VE_ITEM__a.       如果媒體流方向標(biāo)為recvonly/sendrecv，即a=recvonly或a=sendrecv，則A必須（MUST）準(zhǔn)備好在這個(gè)IP和端口上接收實(shí)體B發(fā)來(lái)的媒體流；

$1__VE_ITEM__b.       如果媒體流方向標(biāo)為sendonly/inactive，即a=recvonly或a=sendrecv，則A不需要進(jìn)行準(zhǔn)備。

實(shí)體B收到A的請(qǐng)求offer后，根據(jù)自身支持的媒體類型和編碼策略，回復(fù)響應(yīng)。

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

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

c. 對(duì)于響應(yīng)消息中各個(gè)媒體的方向：

如果請(qǐng)求某媒體流的方向?yàn)閟endonly，那么響應(yīng)中對(duì)應(yīng)媒體的方向必須為recvonly；

如果請(qǐng)求某媒體流的方向?yàn)閞ecvonly，那么響應(yīng)中對(duì)應(yīng)媒體的方向必須為sendonly；

如果請(qǐng)求某媒體流的方向?yàn)閟endrecv，那么響應(yīng)中對(duì)應(yīng)媒體的方向可以為sendrecv/sendonly/recvonly/inactive中的一種；

如果請(qǐng)求某媒體流的方向?yàn)閕nactive，那么響應(yīng)中對(duì)應(yīng)媒體的方向必須為inactive；

$1__VE_ITEM__d.       響應(yīng)answer里提供IP和端口，指示Offerer本端期望用于接收媒體流的IP和端口，一旦響應(yīng)發(fā)出之后，Offerer必須（MUST）準(zhǔn)備好在這個(gè)IP和端口上接收實(shí)體A發(fā)來(lái)的媒體流。

$1__VE_ITEM__e.       如果請(qǐng)求offer中帶了ptime（媒體流打包間隔）的a行或帶寬的a行，則響應(yīng)answer也應(yīng)該（SHOULD）相應(yīng)的攜帶。

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

當(dāng)實(shí)體A收到B回復(fù)的響應(yīng)后，可以（MAY）開(kāi)始發(fā)送媒體流，如果媒體流方向?yàn)閟endonly/sendrecv，

$1__VE_ITEM__a.       必須（MUST）使用answer列舉的媒體類型/編碼生成媒體發(fā)送；

$1__VE_ITEM__b.       應(yīng)該（SHOULD）使用answer中的ptime和bandwidth來(lái)打包發(fā)送媒體流；

$1__VE_ITEM__c.       可以（MAY）立即停止監(jiān)聽(tīng)端口，該端口為offer支持answer不支持的媒體所使用的端口。

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

如果實(shí)體認(rèn)定新的會(huì)話不支持之前媒商的某個(gè)媒體，新的offer只須對(duì)這種媒體所在m行的端口置0，但不能不描述這種媒體，即不帶對(duì)應(yīng)m行。當(dāng)answerer收到響應(yīng)之后，處理同初始協(xié)商一樣。

如果實(shí)體打算新增媒體流，在offer里只須加上描述即可或者占用之前端口被置0的媒體流，即用新的媒體描述m行替換舊的。當(dāng)answerer收到offer請(qǐng)求后，發(fā)現(xiàn)有新增媒體描述，或者過(guò)于端口被置0的媒體行被新的媒體描述替換，即知道當(dāng)前為新增媒體流，處理同初始協(xié)商。

修改媒體注主要是針對(duì)初始協(xié)商結(jié)果，如果有變更即進(jìn)入修改流程處理，可能的變更包括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