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。