1、SDP的引入
SDP最初用于Mbone（组播骨干网）上的多媒体会议。Mbone 是Internet 的一部分，它的主要特征是对IP组播技术的使用。IP组播技术比较适合实现多方会话。
基于组播的会议称为松耦合会议（loosely coupled conferences），它的主要特点是：1）基于组播地址完成多方之间的媒体传送，每个参与方都向指定的组播地址发送媒体，并且都能接收到发往该组播地址上的媒体；2）参与方之间没有紧密的信令关系，没有控制中心点或会议服务器。
松耦合会议的建立过程比较简单，基本上完全由会议创建者来完成，具体来说分两步：1）申请会议所需的组播地址，并确定会议的媒体构成以及每个媒体的格式的连接端口号；2）以某种形式描述这些信息，发布出去，参与者获得这些信息后，即可据此加入这个会话。
显然在松耦合会议的建立过程中，对会话信息的描述是非常重要一步。必须要有一种标准规范的形式来进行会话描述，这样才能保证会议创建者和参与者能够对一个会话描述有一致的认识。在IETF RFC2327中定义了SDP（会话描述协议），用来完成对会话的描述。通常，将基于SDP描述的会话信息称为SDP描述。SDP描述中包含了构成会话的媒体，媒体流的连接地址等信息。根据一个SDP描述，用户即可加入一个会话。
具体来说，一个SDP描述主要包括：会话名、会话目的、会话有效时间、构成会话的媒体及接受这些媒体的信息 (地址、端口、格式)等等 。
一个简单的SDP描述的例子如下：
v=0
s=SDP Seminar
c=IN IP4 224.2.17.12/127
t=3034423519 3042462419
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
这个例子描述了这样一个会话：会议的标题是“SDP Seminar”，即“SDP研讨会”；会议使用连接地址是一个IP播组地址：224.2.17.12；会议的开始时间是3034423519，结束时间是3042462419；会议由音频和视频两种媒体构成，使用的传输端口分别是49170和51372。
得到这个SDP描述后，参与者只需加入到播组地址（224.2.17.12）指定的多播组中，并以指定的媒体格式向指定的端口上发送音频和视频即可参加会议。
在松耦合会议中，完成了会话描述后，会话描述的发布相对比较简单，实际上在不同的情况下可有有多种方法可用，例如HTTP、MIME扩展的Email等等。
2、SDP规范简介
SDP会话描述完全是纯文本的，使用ISO 10646 字符集，UTF-8 编码。
形式上一个SDP 会话描述包含若干行以下形式的文本：<type>=<value>
<type> 恰好是一个字符，并且是大小写敏感的。<value> 一个结构化的文本字符串，其格式依赖于<type>。它通常也是大小写敏感的，除非特定的域有明确定义。通常 <value> 或者是若干以单个空格分界的字段，或者是一个自由格式的字符串。
内容上，一个会话描述包括一个会话级部分，后面跟随0个或多个媒体级部分。会话级部分以 `v=' 行开始，直到第一个媒体级部分。媒体描述以 `m=' 行开始，直到下一个媒体描述或整个会话描述的结束。
具体来说一个会话描述的构成如下：
注意，一些描述行是必需的，一些描述行是可选的，但是所有的出现的行必须以上面给出的顺序出现。可选描述行以`*'标记。
下面介绍一下主要的描述行。
"v=" 行：给出SDP的版本。例如 v=0
"s=" 行：给出会话名。每个会话描述中必须有且仅有一个会话名。例如 s=SDP Seminar
"o=" 行：给出会话的发起者信息(用户名、主机地址)，以及会话标识和会话版本号。具体形式为：o=<username> <session id> <version> <network type> <address type> <address>。其中：
- <network type> 文本串给出网络类型。最初定义的是"IN"，含义是指"Internet"。<address type> 文本串，给出之后的地址的类型。最初定义了 "IP4" 和 "IP6"两种类型。
- <address> 是创建会话的机器的地址。
- <username> 是登录在发起主机上的用户的名。
- <session id> 是一个数字串。<session id> 的分配方法取决于会话描述的创建工具，但是SDP规范建议使用NTP时间戳以保证其唯一性。
五元组 <username>, <session id>, <network type>, <address type> 和 <address> 形成了一个全局唯一的会话标识。
- <version> 是会话描述的版本号。同样，它的使用取决于会话描述创建工具，只要保证修改会话数据时<version>是递增的即可。同样，推荐使用NTP时间戳。
一般来说，"o=" 域唯一的标识了本会话描述的当前版本。
"c=" 行：给出连接参数。具体形式为：c=<network type> <address type> <connection address>。其中：
- <network type>是网络类型。最初定义的是"IN"，含义是指"Internet"。
- <address type> 是地址类型。这允许SDP被用于不是基于IP的会话。当前只定义了IP4。
- <connection address>是连接地址。可选的附加子域可以加在连接地址后面，这取决于 <address type> 域的值。地址类型是 IP4 的情况，典型的连接地址将会是D类的 IP 多播组地址。使用IP多播组地址作为连接地址时必须增加有一个会话的存活时间 (TTL) 值TTL 值范围是 0-255。。TTL 和IP多播组地址一起定义了会议中的多播包发送的范围。会话的TTL加在地址的后面，通过一个斜杠分隔。
一个例子：c=IN IP4 224.2.1.1/127。
"m="行：给出对媒体流的描述。其形式为：m=<media> <port> <transport> <fmt list>。其中：
- <media>给出媒体的类型。目前已定义的媒体类型有 "audio"、"video"、 "application"、 "data" 和 "control"。将来可能会由于新的通信形式(例如, telepresense)的出现而扩展新的媒体类型。
- <port>给出接受媒体流传输端口。传输端口的含义取决于在相关的"c=" 行中指定的网络类型，后面的<transport>中给出的传输协议。比如，对于基于UDP的端口，端口值范围为[1024 ~65535] 。为了符合RTP，应该是偶数。例如：m=video 49170/2 RTP/AVP 31 指定49170端口 和 49171端口形成一个 RTP/RTCP 对，49172 端口 和 49173 端口形成第二个 RTP/RTCP 对。
- <transport> 给出传输协议。传输协议值依赖于 "c=" 域的地址类型。对于 IP4，绝大多数媒体流通过 RTP/UDP传送。
- <fmt list> 给出媒体的格式列表。对于 audio 和 video，通常会有媒体净荷类型在 RTP Audio/Video Profile 中定义。当一个格式列表被给出时，这暗示了其中指定的格式的可能被用于这个会话，但是第一个格式是这个会话的缺省格式。例如 m=audio 49230 RTP/AVP 96 97 98 中给出了三种媒体格式96 97 98。
3、总结与后继
SDP最初被用于描述基于多播会话的松耦合会议中，但目前更广泛地应用于点到点的两方会话中。
在松耦合会议中，会话参数完全由会议创建者来确定，参与者能做的仅仅是根据这些会话参数来加入会议（当然也可以选择不加入）。这种情况下，主要要做的就是会话描述，在这里SDP本身就足够了。
但是在更为普遍的两方会话的情况下，由于用户终端能力的差异，任何一方不能假设对方一定支持某种会话参数，所以必须双方协商来最终就会话的参数达成一致。显然，SDP能做到准确的描述会话的参数，但是它缺少双方如何根据各自提供的会话描述形成最终一致的会话描述的语义及操作上的细节。在RFC3264中定义了一个基于SDP的简单的提议/应答模型来实现这一点。
本博客将会有后继的文章介绍基于SDP的提议/应答模型，敬请关注。
基于SDP的提议/应答（offer/answer）模型简介
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:110 telephone-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:110 telephone-events/8000
a=sendonly
4、后继
基于SDP的提议应答模型的实际实现需要依赖于某种呼叫信令协议，比如SIP、BICC等等，相比较而言，与提议应答模型这些协议的关系更为复杂。本博客将有后继博文介绍在SIP中应用SDP提议应答模型的情况。
SIP中的SDP offer/answer交换初探
1.引言
SDP的offer/answer模型本身独立与于利用它的高层协议。SIP是使用offer/answer模型的应用之一。RFC 3264 定义了offer/answer模型，但没有规定使用哪个SIP消息来携带一个offer或answer。
理论上，任何SIP消息的正文中都可以包含会话描述部分。但是，一个SIP中的会话描述并不一定是一个offer或一个answer,只有符合在SIP标准RFCs中所描述的规则的会话描述才会被解释为一个offer或一个answer。目前，关于如何在SIP中处理offer/answer模型的规则被定义在SIP基本部分（RFC3261）及其扩展RFCs中。
SDP的offer/answer模型定义会话的更新。在SIP中，对话（dialog）用于将offer/answer交换及其要更新的会话联系起来。换句话说，只有在某个SIP对话中进行的offer/answer交换，才能更新该对话所管理的会话。
2、六种Offer/Answer交换模式
在SIP消息中承载offer/answer的规则定义在RFC 3261, RFC 3262 以及RFC 3311中。
在这些RFCs中定义了六种在SIP消息中交换offer/answer的模式。
模式1和模式2是在RFC3261中定义的，用于不支持100rel（可靠临时响应消息扩展）的SIP实体之间的会话建立。
模式1：UAC在INVITE请求中携带一个offer, UAS在200 INVITE响应中返回answer。这是最常用的一种模式。
模式2：UAC在INVITE请求中没有携带offer。UAS在200 INVITE响应中携带一个offer，UAC通过ACK返回answer。这种模式通常用于3PCC中。
模式3、模式4、模式5都是在RFC3262中定义的，可用在支持100rel的SIP实体之间。其中模式3、模式4可用于会话建立。模式5只能用于会话参数更新。它们利用1xx-rel响应消息来携带offer或answer来建立会话。
模式3：UAC在INVITE请求中携带一个offer, UAS在1xx-rel响应中返回answer。这样，在呼叫完成之前（UAC没有收到200 INVITE消息）会话已建立。此后，会话参数还可以被更新，具体见模式5及模式6。
模式4： UAC在INVITE请求中没有携带offer。UAS在1xx-rel可靠响应中携带一个offer，UAC通过PRACK返回answer。同样地，在呼叫完成之前（UAC没有收到200 INVITE消息）会话已建立。此后，会话参数还可以被更新，具体见模式6。
模式5：当UAC与UAS采用模式3建立会话后，呼叫并未完成（见模式3）。之后，可以使用模式5对已建立的会话参数进行更新：UAC在PRACK请求中携带一个新的offer, UAS在200 PRACK响应中返回answer。这样，会话参数便被更新。
模式6在RFC3311中定义，主要用于在早期对话中更新已建立的会话参数，会话可能是通过模式3，也可能是通过模式4建立的。
模式6还可以对会话进行多次更新。例如，之前已通过模式5更新过的会话还可以使用模式6更新；甚至通过模式6更新过的会话还可以再次使用模式6更新。
模式6：UAC（或UAS）发送UPDATE请求其中携带一个新的offer, AS（或UAC）在200 UPDATE中返回一个offer。这样，会话参数便被更新。注意，UAS或UAC在发送UPDATE进行会话更新之前，必须保证之前的会话更新过程已经完成。也就是说，发出的offer已经收到answer，或者收到的offer已经产生了answer。
3.总结
INVITE方法提供了会话建立过程。
在没有100rel选项时，会话建立过程非常简单，只能使用“200 ”响应消息传送会话描述，这些会话描述可能是answer(模式1),也可能是offer（模式2）。无论使用何种模式，会话都只能呼叫完成后才能建立，在呼叫完成之前和呼叫完成之后只能有一个会话 – 用于最终通话的常规会话，因而，不能建立所谓的“早期媒体会话”。
在引入100rel选项后，会话建立过程变得复杂，通过可靠的临时消息消息也可以传送会话描述，这些会话描述可能是answer(模式3),也可能是offer（模式4）。模式3和模式4都能够在呼叫完成前建立会话。并且在呼叫完成之前，这些会话还可以被更新。这样就能够建立与常规会话不同的“早期媒体会话”，完成回铃音的产生等功能。
PRACK方法可用于更新已建立的会话的参数（模式5）
UPDATE方法可用于多次更新已建立的会话的参数（模式6），发起更新的可以是UAC也可以是UAS。