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提议应答模型的情况。
)
)
