1、引入
在松耦合會議中，會話參數完全由會議建立者來确定，參與者能做的僅僅是根據這些會話參數來加入會議（當然也可以選擇不加入）。這種情況下，主要要做的就是會話描述，在這裡SDP本身就足夠了。
但是在更為普遍的兩方會話的情況下，由于使用者終端能力的差異，任何一方不能假設對方一定支援某種會話參數，是以必須雙方協商來最終就會話的參數達成一緻。顯然，SDP能做到準确的描述會話的參數，但是它缺少雙發如何根據各自提供的會話描述形成最終一緻的會話描述的語義及操作上的細節。
IETF RFC3264定義了一個基于SDP的簡單的提議/應答模型來實作這一點。
2、提議/應答操作概述
在提議/應答模型中，首先會話的一方（提議者）産生一個 SDP消息來描述它所期望的會話，這構成了一個提議（offer）。提議中主要包括提議者想使用的媒體流和codecs集，以及提議者用于接收媒體的IP位址和端口。
提議被傳送到另一方，收到這個提議後這一方可能會接受，也可能會拒絕這個提議。在前一種情況下，本方（應答者）根據收到的提議和自身的能力産生一個SDP消息來描述它所能接受的會話，這稱為應答（answer），應答中針對提議中的每個媒體流有一個比對流，訓示該媒體流是否被接受，同時伴随着要使用的codecs和應答者希望用于接收媒體的 IP 位址和端口。
在提議/應答的操作中需遵守以下原則：
- 在任何時候，任何一方都可能産生一個新的提議來更新會話。然而，如果它收到了一個提議還沒有應答或拒絕，則不能産生新的提議。
- 提議/應答交換是不可分的，如果應答被拒絕，會話恢複到提議前的狀态。
- 提議 (和應答) 必須是RFC 2327 中所定義的有效SDP消息。盡管 SDP 規範允許将多個會話描述串接在一起形成一個大的SDP 消息，但是在提議/應答模型中使用的SDP消息必須恰好包含一個會話描述。
在提議/應答模型中交換假定存在一個高層協定(比如SIP)，它能夠完成SDP消息的交換，并能維持某種上下文關系，将一個提議及其應答，和建立和更新同一個會話的多個提議/應答對關聯起來。
3、提議/應答交換例子
下面給出一個簡單的提議/應答交換的例子。
假設主叫A發送一個提議給被叫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不想發送和接收第一個視訊流，是以傳回以下SDP作為應答。（注意描述第一個視訊流的"m="行中端口設為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），是以産生以下的應答：
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的提議應答模型的實際實作需要依賴于某種呼叫信令協定，比如SIP、BICC等等，相比較而言，與提議應答模型這些協定的關系更為複雜。本部落格将有後繼博文介紹在SIP中應用SDP提議應答模型的情況。
1、引入
在松耦合會議中，會話參數完全由會議建立者來确定，參與者能做的僅僅是根據這些會話參數來加入會議（當然也可以選擇不加入）。這種情況下，主要要做的就是會話描述，在這裡SDP本身就足夠了。
但是在更為普遍的兩方會話的情況下，由于使用者終端能力的差異，任何一方不能假設對方一定支援某種會話參數，是以必須雙方協商來最終就會話的參數達成一緻。顯然，SDP能做到準确的描述會話的參數，但是它缺少雙發如何根據各自提供的會話描述形成最終一緻的會話描述的語義及操作上的細節。
IETF RFC3264定義了一個基于SDP的簡單的提議/應答模型來實作這一點。
2、提議/應答操作概述
在提議/應答模型中，首先會話的一方（提議者）産生一個 SDP消息來描述它所期望的會話，這構成了一個提議（offer）。提議中主要包括提議者想使用的媒體流和codecs集，以及提議者用于接收媒體的IP位址和端口。
提議被傳送到另一方，收到這個提議後這一方可能會接受，也可能會拒絕這個提議。在前一種情況下，本方（應答者）根據收到的提議和自身的能力産生一個SDP消息來描述它所能接受的會話，這稱為應答（answer），應答中針對提議中的每個媒體流有一個比對流，訓示該媒體流是否被接受，同時伴随着要使用的codecs和應答者希望用于接收媒體的 IP 位址和端口。
在提議/應答的操作中需遵守以下原則：
- 在任何時候，任何一方都可能産生一個新的提議來更新會話。然而，如果它收到了一個提議還沒有應答或拒絕，則不能産生新的提議。
- 提議/應答交換是不可分的，如果應答被拒絕，會話恢複到提議前的狀态。
- 提議 (和應答) 必須是RFC 2327 中所定義的有效SDP消息。盡管 SDP 規範允許将多個會話描述串接在一起形成一個大的SDP 消息，但是在提議/應答模型中使用的SDP消息必須恰好包含一個會話描述。
在提議/應答模型中交換假定存在一個高層協定(比如SIP)，它能夠完成SDP消息的交換，并能維持某種上下文關系，将一個提議及其應答，和建立和更新同一個會話的多個提議/應答對關聯起來。
3、提議/應答交換例子
下面給出一個簡單的提議/應答交換的例子。
假設主叫A發送一個提議給被叫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不想發送和接收第一個視訊流，是以傳回以下SDP作為應答。（注意描述第一個視訊流的"m="行中端口設為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），是以産生以下的應答：
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
![JAVA 系列——>開發工具IntelliJ IDEA的安裝以及配置、快捷鍵IDEA 簡介[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)