1、引入

在松耦合會議中，會話參數(shù)完全由會議創(chuàng)建者來確定，參與者能做的僅僅是根據(jù)這些會話參數(shù)來加入會議（當(dāng)然也可以選擇不加入）。這種情況下，主要要做的就是會話描述，在這里SDP本身就足夠了。

但是在更為普遍的兩方會話的情況下，由于用戶終端能力的差異，任何一方不能假設(shè)對方一定支持某種會話參數(shù)，所以必須雙方協(xié)商來最終就會話的參數(shù)達成一致。顯然，SDP能做到準(zhǔn)確的描述會話的參數(shù)，但是它缺少雙發(fā)如何根據(jù)各自提供的會話描述形成最終一致的會話描述的語義及操作上的細節(jié)。

IETF RFC3264定義了一個基于SDP的簡單的提議/應(yīng)答模型來實現(xiàn)這一點。

2、提議/應(yīng)答操作概述

在提議/應(yīng)答模型中，首先會話的一方（提議者）產(chǎn)生一個 SDP消息來描述它所期望的會話，這構(gòu)成了一個提議（offer）。提議中主要包括提議者想使用的媒體流和codecs集，以及提議者用于接收媒體的IP地址和端口。

提議被傳送到另一方，收到這個提議后這一方可能會接受，也可能會拒絕這個提議。在前一種情況下，本方（應(yīng)答者）根據(jù)收到的提議和自身的能力產(chǎn)生一個SDP消息來描述它所能接受的會話，這稱為應(yīng)答（answer），應(yīng)答中針對提議中的每個媒體流有一個匹配流，指示該媒體流是否被接受，同時伴隨著要使用的codecs和應(yīng)答者希望用于接收媒體的 IP 地址和端口。

在提議/應(yīng)答的操作中需遵守以下原則：

• 在任何時候，任何一方都可能產(chǎn)生一個新的提議來更新會話。然而，如果它收到了一個提議還沒有應(yīng)答或拒絕，則不能產(chǎn)生新的提議。
• 提議/應(yīng)答交換是不可分的，如果應(yīng)答被拒絕，會話恢復(fù)到提議前的狀態(tài)。
• 提議 (和應(yīng)答) 必須是RFC 2327 中所定義的有效SDP消息。盡管 SDP 規(guī)范允許將多個會話描述串接在一起形成一個大的SDP 消息，但是在提議/應(yīng)答模型中使用的SDP消息必須恰好包含一個會話描述。

在提議/應(yīng)答模型中交換假定存在一個高層協(xié)議(比如SIP)，它能夠完成SDP消息的交換，并能維持某種上下文關(guān)系，將一個提議及其應(yīng)答，和創(chuàng)建和更新同一個會話的多個提議/應(yīng)答對關(guān)聯(lián)起來。

3、提議/應(yīng)答交換例子

下面給出一個簡單的提議/應(yīng)答交換的例子。

假設(shè)主叫A發(fā)送一個提議給被叫B。提議中包含一個雙向的音頻流和兩個雙向的視頻流，分別使用H.261 (凈荷類型31) 和MPEG(凈荷類型32)。

提議的SDP如下：

v=0

o=alice 2890844526 2890844526 IN IP4 host.anywhere.com

s=

c=IN IP4 host.anywhere.com

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

m=video 51372 RTP/AVP 31

a=rtpmap:31 H261/90000

m=video 53000 RTP/AVP 32

a=rtpmap:32 MPV/90000

被叫B不想發(fā)送和接收第一個視頻流，所以返回以下SDP作為應(yīng)答。（注意描述第一個視頻流的"m="行中端口設(shè)為0，這表示拒絕這個媒體流）。

v=0

o=bob 2890844730 2890844730 IN IP4 host.example.com

s=

c=IN IP4 host.example.com

t=0 0

m=audio 49920 RTP/AVP 0

a=rtpmap:0 PCMU/8000

m=video 0 RTP/AVP 31

m=video 53000 RTP/AVP 32

a=rtpmap:32 MPV/90000

之后的某一時刻，B決定改變其接收音頻流的端口(從49920 改為65422)，同時，增加另一個“僅接收”的音頻流（注意其屬性為recvonly），使用 RTP 凈荷類型 events 。

B提供了以下SDP作為提議：

v=0

o=bob 2890844730 2890844731 IN IP4 host.example.com

s=

c=IN IP4 host.example.com

t=0 0

m=audio 65422 RTP/AVP 0

a=rtpmap:0 PCMU/8000

m=video 0 RTP/AVP 31

m=video 53000 RTP/AVP 32

a=rtpmap:32 MPV/90000

m=audio 51434 RTP/AVP 110

a=rtpmap:110telephone-events/8000

a=recvonly

A接受這個新增的媒體流（注意在其屬性為sendonly），所以產(chǎn)生以下的應(yīng)答：

v=0

o=alice 2890844526 2890844527 IN IP4 host.anywhere.com

s=

c=IN IP4 host.anywhere.com

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

m=video 0 RTP/AVP 31

a=rtpmap:31 H261/90000

m=video 53000 RTP/AVP 32

a=rtpmap:32 MPV/90000

m=audio 53122 RTP/AVP 110

a=rtpmap:110telephone-events/8000

a=sendonly

4、后繼

基于SDP的提議應(yīng)答模型的實際實現(xiàn)需要依賴于某種呼叫信令協(xié)議，比如SIP、BICC等等，相比較而言，與提議應(yīng)答模型這些協(xié)議的關(guān)系更為復(fù)雜。本博客將有后繼博文介紹在SIP中應(yīng)用SDP提議應(yīng)答模型的情況。

總結(jié)

以上是生活随笔為你收集整理的基于SDP的提议/应答（offer/answer）模型简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。