情態(tài)動(dòng)詞術(shù)語(yǔ)解釋

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í)，需要遵守或靈活變更約束。

術(shù)語(yǔ)

媒體流（Media Stream），或稱(chēng)為媒體類(lèi)型（Media Type），即我們通常所說(shuō)的音頻流、視頻流等，所有通信實(shí)體要進(jìn)行媒體交互之前都必須進(jìn)行媒體注的協(xié)商
媒體格式（Media Format），每種媒體流都有不同的編碼格式，像音頻有G711、G712編碼，視頻有H261、H264等，像現(xiàn)在所謂的高清視頻采用是720P、1070P等。
單一會(huì)話(huà)（Unitcast Session）
多會(huì)話(huà)（Multicast Sessions）
單一媒體流（Unitcast Streams）
多媒體流（Multicast Streams）

SDP（Session Description Protocol）

SDP（會(huì)話(huà)描述協(xié)議），用于兩個(gè)會(huì)話(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)和理解。

SDP模型組網(wǎng)圖

SDP各個(gè)參數(shù)簡(jiǎn)單介紹

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

v=0                                                                              
o=carol 28908764872 28908764872 IN IP4 100.3.6.6        //會(huì)話(huà)ID號(hào)和版本
s=-                                     //用于傳遞會(huì)話(huà)主題
t=0 0                                   //會(huì)話(huà)時(shí)間，一般由其它信令消息控制，因此填0
c=IN IP4 192.0.2.4              //描述本端將用于傳輸媒體流的IP
m=audio 0 RTP/AVP 0 1 3     //媒體類(lèi)型 端口號(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í)體行為、操作過(guò)程

初始協(xié)商的Offer請(qǐng)求

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

• 如果媒體流方向標(biāo)為recvonly/sendrecv，即a=recvonly或a=sendrecv，則A必須（MUST）準(zhǔn)備好在這個(gè)IP和端口上接收實(shí)體B發(fā)來(lái)的媒體流；
• 如果媒體流方向標(biāo)為sendonly/inactive，即a=recvonly或a=sendrecv，則A不需要進(jìn)行準(zhǔn)備。

Answer響應(yīng)

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

• 如果實(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行描述。
• 對(duì)于某種媒體，實(shí)體B必須（MUST）從請(qǐng)求offer中選出A支持且自己也支持的該媒體的編碼標(biāo)識(shí)集，并且可以（MAY）附帶自己支持的其它類(lèi)型編碼。
• 對(duì)于響應(yīng)消息中各個(gè)媒體的方向：
  如果請(qǐng)求某媒體流的方向?yàn)?code>sendonly，那么響應(yīng)中對(duì)應(yīng)媒體的方向必須為recvonly；
  如果請(qǐng)求某媒體流的方向?yàn)?code>recvonly，那么響應(yīng)中對(duì)應(yīng)媒體的方向必須為sendonly；
  如果請(qǐng)求某媒體流的方向?yàn)?code>sendrecv，那么響應(yīng)中對(duì)應(yīng)媒體的方向可以為sendrecv/sendonly/recvonly/inactive中的一種；
  如果請(qǐng)求某媒體流的方向?yàn)?code>inactive，那么響應(yīng)中對(duì)應(yīng)媒體的方向必須為inactive；
• 響應(yīng)answer里提供IP和端口，指示Offerer本端期望用于接收媒體流的IP和端口，一旦響應(yīng)發(fā)出之后，Offerer必須（MUST）準(zhǔn)備好在這個(gè)IP和端口上接收實(shí)體A發(fā)來(lái)的媒體流。
• 如果請(qǐng)求offer中帶了ptime（媒體流打包間隔）的a行或帶寬的a行，則響應(yīng)answer也應(yīng)該（SHOULD）相應(yīng)的攜帶。
• 實(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更期望使用的編碼類(lèi)型。同理，當(dāng)實(shí)體A收到響應(yīng)answer后也是這樣理解的。

實(shí)體收到響應(yīng)后的處理

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

• 必須（MUST）使用answer列舉的媒體類(lèi)型/編碼生成媒體發(fā)送；
• 應(yīng)該（SHOULD）使用answer中的ptime和bandwidth來(lái)打包發(fā)送媒體流；
• 可以（MAY）立即停止監(jiān)聽(tīng)端口，該端口為offer支持answer不支持的媒體所使用的端口。

修改媒體流（會(huì)話(huà)）

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

刪除媒體流

如果實(shí)體認(rèn)定新的會(huì)話(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地址、端口，媒體格式（編碼），媒體類(lèi)型（音、視頻），媒體屬性（ptime，bandwidth，媒體流方向變更等）。